An interview is just a test. Like any tests there are false positives and false negatives. There is a trade off between having more false positives/negatives and generally when it comes to hiring, a false positive is much more expensive than a false negative so many interview processes will end up rejecting good developers.
An interview can’t tell the company whether or not you are a good developer or a bad one. It can only say you can demonstrate certain skills to a certain level under interview conditions which means you are pretty likely to be a good developer.
It’s tough when you get rejections but because of the above factors, unfortunately it’s not enough to be a good developer to pass interviews a lot of the time. You also have to be good at interviewing. The good news is like any skill it can be practiced and if you’re already a good developer it shouldn’t really take much effort to become good at interviewing but it does require practice.
That’s my take anyway. Keep your head up, practice interviewing and you’ll be alright.
Whenever I speak with students/new grads about interviewing I actually specifically advise them that an interview is not a test. Yes, you need to have a certain level of base skills, but beyond that, an interview is much more like a date than a test. I say this because you can do everything right and still be rejected. It doesn’t mean that you did anything wrong or there’s anything with wrong with you, but rather there just wasn’t a match between you and the company you were interviewing with at that point in time. There are so many factors entirely outside of your control that determine if you’re given an offer or are rejected to the point that I find it really tough to consider it a “test” in the academic sense where you need to score a certain value to pass or fail it.
Likewise, it’s incredibly common for students/new grads to focus heavily on the technical skills while completely ignoring the soft skills. The best thing you can do in an interview is make the interviewer like you and want to work with you. It’s amazing how many people will overlook subpar technical skills either consciously or subconsciously if they feel comfortable with you (the amount of borderline incompetent people I’ve seen hired that are otherwise smooth talkers is astounding). It seems like the author of the linked to article here might be falling into that trap too. He writes about his technical experience heavily but does not touch on the soft skills at all, even questioning at one point that he may simply be bad at interviewing which is a strong sign to me that he’s not presenting himself well in the interview.
This is something that transcends software engineering. If you’re a sociable and likeable person you’ll go far further in life than the person that is quietly a genius but doesn’t work well with others. I wish more people folks in this industry would focus on that side of the coin instead of simply saying “grind Leetcode more to get more offers.”
Very true and completely agree with your post. I didn’t mean a test in the exam sense more like a COVID test in terms of test design.
I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.
I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.
At one of my favourite places to work, the owner had a sticky note on the side of his monitor that read “Hire for attitude, train for skill, reward for excellence.”
During one of our training sessions (I was teaching him Excel), I noticed that the sticky note was a different colour. I asked him about it and he said he rewrites it every Monday on a different colour so that it’s always visible and always fresh in his mind because it’s too easy to forget, even though he thought it was the secret to running a successful business.
The most successful interview I had I’d had a few shots ahead of time, and got into a (respectful) argument with the CTO about the pros/cons of their implementation of agile as I saw it.
Like, not to roast our man here, but he comes off as a competent Eeyore, even while writing from the safest of places, where he can take the time to craft whatever image he wants.
An interview is just a test. Like any tests there are false positives and false negatives. There is a trade off between having more false positives/negatives and generally when it comes to hiring, a false positive is much more expensive than a false negative so many interview processes will end up rejecting good developers.
An interview can’t tell the company whether or not you are a good developer or a bad one. It can only say you can demonstrate certain skills to a certain level under interview conditions which means you are pretty likely to be a good developer.
It’s tough when you get rejections but because of the above factors, unfortunately it’s not enough to be a good developer to pass interviews a lot of the time. You also have to be good at interviewing. The good news is like any skill it can be practiced and if you’re already a good developer it shouldn’t really take much effort to become good at interviewing but it does require practice.
That’s my take anyway. Keep your head up, practice interviewing and you’ll be alright.
Whenever I speak with students/new grads about interviewing I actually specifically advise them that an interview is not a test. Yes, you need to have a certain level of base skills, but beyond that, an interview is much more like a date than a test. I say this because you can do everything right and still be rejected. It doesn’t mean that you did anything wrong or there’s anything with wrong with you, but rather there just wasn’t a match between you and the company you were interviewing with at that point in time. There are so many factors entirely outside of your control that determine if you’re given an offer or are rejected to the point that I find it really tough to consider it a “test” in the academic sense where you need to score a certain value to pass or fail it.
Likewise, it’s incredibly common for students/new grads to focus heavily on the technical skills while completely ignoring the soft skills. The best thing you can do in an interview is make the interviewer like you and want to work with you. It’s amazing how many people will overlook subpar technical skills either consciously or subconsciously if they feel comfortable with you (the amount of borderline incompetent people I’ve seen hired that are otherwise smooth talkers is astounding). It seems like the author of the linked to article here might be falling into that trap too. He writes about his technical experience heavily but does not touch on the soft skills at all, even questioning at one point that he may simply be bad at interviewing which is a strong sign to me that he’s not presenting himself well in the interview.
This is something that transcends software engineering. If you’re a sociable and likeable person you’ll go far further in life than the person that is quietly a genius but doesn’t work well with others. I wish more people folks in this industry would focus on that side of the coin instead of simply saying “grind Leetcode more to get more offers.”
Very true and completely agree with your post. I didn’t mean a test in the exam sense more like a COVID test in terms of test design.
I actually think in some ways it’s a good thing to overlook the technical side to a degree as well because technical skills are generally a lot easier to teach than the people skills. Assuming the fundamentals are there at least.
At one of my favourite places to work, the owner had a sticky note on the side of his monitor that read “Hire for attitude, train for skill, reward for excellence.”
During one of our training sessions (I was teaching him Excel), I noticed that the sticky note was a different colour. I asked him about it and he said he rewrites it every Monday on a different colour so that it’s always visible and always fresh in his mind because it’s too easy to forget, even though he thought it was the secret to running a successful business.
The most successful interview I had I’d had a few shots ahead of time, and got into a (respectful) argument with the CTO about the pros/cons of their implementation of agile as I saw it.
Like, not to roast our man here, but he comes off as a competent Eeyore, even while writing from the safest of places, where he can take the time to craft whatever image he wants.