I've conducted many interviews. There are many reasons why I reject people, but there are recurring themes. I want to give a list of the most common problems. A few of these things I once thought were obvious, while others are perhaps less so.
Don't know the basics of coding
This one troubles me a lot.
It should not be a challenge to create lists, split them, and iterate over them. Functions, classes, variables, the basic structures of a language should be no trouble at all for you. Stumbling on these is the quickest way to earn my rejection.
I have zero expectation that you know the entire language, and it's standard library by heart. However, I'm talking about the basics. There's no reason you should be looking up loop syntax during an interview. I've also found that the more somebody knows, the faster they code. Being fluent in a language reduces stress, freeing your brain to think about the problem rather than the syntax.
Perhaps you work with a lot of languages, and many technologies. I understand this. I do as well, and I often forget how to do something in a particular language. It's not an excuse though. If you're picking the language for the interview, you need to review the basics before starting. I know the basics are harder in C++ than Python, but I expect you to know the language you chose.
When I do live coding, I create a cheat sheet for the language. A quick reference of all the things I may need -- I don't want to stumble on a for-loop in front of viewers! You can do the same thing, and then memorize it before the interview. As long as you know the language in advance, there is no excuse. None.
Don't speak, speak poorly, or be disinterested
Interviews are about talking, and it should be no surprise that how you talk is vital.
If I ask an open-ended question, it's because I want more than a few words as an answer. Take the opportunity to talk. Provide short pauses in between some sentences; it gives me time to understand and interrupt if I want.
While you're coding, I expect you to talk about what you're doing. I don't want to read the code on the screen. Tell me about why you've chosen that code, or what your current goal is. If I don't know what you're thinking, I can't help you. I have no desire to sit there and watch you struggle. If you speak up, I can help you focus, and guide you to the right answer. If you don't say anything, you risk wasting time on something irrelevant, or on a misunderstanding of the problem.
Learn how to speak well. I've had some people that said "hmm" and "ah" so often that I had a hard time understanding them. Nobody is expecting world class oration, but clean speech is easier on the listener. You want the interviewer thinking about the meaning of your words, not trying to decipher what you're saying. Practice is your friend here. It doesn't take much effort to make noticeable improvements.
Closely related to speaking poorly is sounding disinterested. It's an absolute turn-off to hear somebody who's dead inside and their job is like a prison. It can also be taken as disrespectful. I'm taking the time to interview you, and I expect you to show some modicum of interest in the process.
Speak clearly and with interest.
Overthink and complicate the question
Interviews aren't long, and all the work you need to do should fit comfortably inside the allocated time. If you have an hour-long coding interview, you'll likely only have 35-40 minutes of coding time. We need time to talk, not only code.
I'm not going to give you a problem that takes too long. Indeed, the initial question I give only requires 10-20 minutes of coding time. I prefer to ask followup questions rather than one big question. However, even when you've been given one substantial question, you have to assume it's solvable in the short interview.
Complicating the problem, asking too many what-ifs, and going off on tangents, will all eat up your precious time. Focus on the problem at hand. Don't look for hidden trickery, nor try to design the perfect system. That is also why vocalizing your thoughts is essential. It gives the interviewer a chance to keep you on track.
Solve the problem as it's given.
Know nothing about your last job
I always ask about previous work experience. Not only general history, but I want to hear about your specific role. I want to hear that you know how you fit into the team. I'll judge your level of interest by how well you can describe the product and the processes involved in developing it.
I'm listening for specific technologies. Great, you were a full-stack developer, but what does that mean? Did you use NodeJS and Angular? How did you communicate with the server? Which database did you use? Moreover, which parts did you actually work on? I want to understand your level of involvement.
If you can't provide specifics, I'll assume it's because you're either inflating your position, or you weren't vested in the project. Either way, it reflects negatively on you.
I also use this information to guide the rest of the interview. If you come across as a top developer, I'll hold back on helpful prompts, giving you more space to work on your own. If you're a newcomer, I'll be more liberal with my help to avoid unnecessary stress.
Write sloppy code
It's an interview. I'm not expecting you to achieve perfectly clean code. However, there's a big difference between acceptable code and sloppy code.
My biggest gripe is poor variable names. Why are you calling the variable n? You're in a live interview and trying to communicate with me. Clear names help me understand your code.
If this is an online interview, or I've given you the equipment, I tend to be forgiving of some formatting issues. Some interviewing editors make it challenging to indent correctly or fix things. But I do see consistency issues, like where the braces and semicolons are.
Rarely have I failed somebody solely due to sloppiness. However, on numerous occasions, I've seen lousy code slow down the interview: either the candidate struggles to understand their code, or I have to ask what's going on.
Insult something or somebody
Just don't do it!
Regardless of your opinion or experience, don't say anything negative about anything. You have absolutely no idea about me, the interviewer, or my background. You don't know what concepts I think are good or bad. You don't know whom I've worked with, or whom I regularly talk to.
Negative points that contradict the interviewer's world view immediately hurt their impression of you. Even if I agree with the point you make, it's not the right time to make it. I'm an open-minded person, but the mere fact you've chosen this time to complain about something reflects negatively on you. I don't want to work with negative people. You're here to promote yourself, not disparage others.
What if you're asked to talk about something bad? These questions can come up, directly as "what's wrong with X," or the silly "What's your worst experience?" This is when you swallow your pride and talk about learning experiences, differences, and group struggles. You talk humbly and focus on the positives. I love when people can spin lousy situations into a positive story. These are people I like working with.
Conclusion: Lots of soft skills
A coding interview is an interactive session. You need to work together with the interviewer. This is true even if your interviewer isn't good. Even interviewers without training will tend to speak and try to help you. Plus, as many criteria on the list are standard social skills, everybody is judging them. It's perhaps even worse for people not trained in interviewing, as they may be less likely to overlook interview stress.
If you've read my book, you'll know that I place a great deal of value on people skills. You can see how many of these failures relate to soft skills. But, if you wish to pass the interview, you still need to have code that solves the problem.
Everything in this article works towards getting a good solution. By ensuring the interview is smooth, you make the most of your time. You get helpful feedback and can focus on writing the right code. I know some interviews will be rocky regardless of what you do. But still, try your best, and definitely, don't make them any worse.
If you happen to be making one of these mistakes? Fix it. These are all skills that can be practiced and improved.
Read my book What is Programming? and learn what it takes to be a great programmer. I look at the People, the reason software exists, the code at the heart of that software, and you, the person behind the keyboard.
Top comments (25)
My current position did not have a "technical" interview. The CTO and Manager interviewed me personally and we just talked. At the end of the day are you hiring someone based on how they code right now in a bubble or the ability to learn and be part of a great team? I'm not saying they had the right way or wrong way, but it set an expectation of trust and collaboration from the get go. Idk food for thought perhaps. Great post by the way.
This is why I place a lot of value in the feedback during the interview. While it's important that they come up with a working solution, it's their behaviour that determines whether that will happen.
I will often have people who could not solve the problem on their own, but by listening to their thoughts and reading their code, I can guide them towards a working solution. This fulfills the requirements I think you want: can this person learn and grow.
Well said, thank you for the reply.
I think that can totally work, but it's also true that some people are much better at talking the talk than walking the walk. Having a session where you can spend an hour or so working with someone to see how they organize their thoughts and solve problems can be quite illuminating. If a person you're considering hiring already has a decent amount of experience, and maybe they can point to a body of code that they've written, it may be less crucial to actually do a coding interview, and just a get-to-know-you session is good enough.
How do you deal with false positives? Where a programmer has these issues only in the moment because of social anxiety?
I try to create an environment to minimize interview stress, and I think I'm an okay judge of character. However, that said, there are two, rather cold, views on this.
A) There's enough candidates that you don't have to worry about failing somebody incorrectly. It's better to accidentally reject qualified people than to occassionally accept unqualified people. The quantity of applications makes it harder for individual applicants.
B) It's part of the job. The skills you use during the interview will be required again while you are working. If the pressure, or anxiety, hurts your performance in the interview, should I not assume it might also hurt your performance in a job? I know the interview tends to exacerbate issues, but I don't think it fundamentally creates them.
As an interviewer you try your best to see through interview stress, but you won't be perfect. The unfortunate truth is that interviews aren't merely an assessment of your abilities, they are a competition. And you have to train to win at them. I'd prefer this weren't the case, and I try to minimize it, but it's still the reality we face now. :(
Not a direct answer to your question, but maybe this can lead to some meaningful conversation.
Before I switched to becoming full time developer, I used to be a musician. One thing I never quite got over from HS was stage fright. After years of dealing with this, I noticed a couple of trends that would trigger my stage fright. Often times I feel like it was brought on or enhanced by a lack of preparedness on my part. Knowing that, I was able to lessen the effects of stage fright but over time I learned, it never really goes away.
The stage fright is always there. The thing is, you get comfortable with being uncomfortable. You learn to sort of work around it. From my experience, the only way you can develop this level of comfortability is by putting yourself in the "spotlight" often.
Practice interviewing with other people. Try to change it up and maybe schedule an interview with someone you're not so familiar with. Give yourself some real stakes. Make it as close a simulation to the real thing as possible. I exposed myself to situations like that often enough that I knew exactly how I was going to feel and how I should counteract it or at least minimize my stage fright.
very well said: i guess i will print and frame it :-)
Not to be contrary, but for some folks with social anxiety, no amount of practice is going to fix that. What I would frame from these responses is the complete lack of empathy that a person could be a badass but have a genuine disorder, which makes them worthy of rejection.
I think even people with severe social anxiety can improve their ability to deal with interviews, although in some cases it may not be a good idea to do it alone. For some, it may be wise to get some professional help from a psychologist who specializes in that area.
Not everyone has to be thoroughly extroverted, but in many professional environments it's important to be able to interact effectively with other people.
I have worked as CTO and some other leadership positions and done my handful of interviews. In those cases, I have always tried to strike a conversation with the person, see what he likes about the software world and try to make him feel at ease (taking into account that it is an interview). If the person is especially anxious, going out to have a friendly coffee works too because it's a more neutral ground.
I completely agree with most of the points here, especially "don't know the basics of coding". When I started interviewing people, I was surprised how much difficulty most people have with writing a single loop and a conditional statement.
That said, I'm not entirely convinced about "overthink and complicate the question". In general, you shouldn't look for things that "aren't there" but in some cases it's desired for the candidate to try to understand the problem better before coding. We used to have a simple assignment rooted in a real business scenario and I always valued it when people asked questions about how the business really works instead of making rush assumptions.
By overthink I really mean overthink, not just understanding the problem. If you don't understand, or are uncertain, then ask. By overthink I mean things like planning for future requirements or making extension points that are unnecessary. These are things you shouldn't be doing in normal coding either.
I agree it's not a well defined line, but there is difference between understanding the problem, and complicating the problem.
Totally agree with you, sometimes we focus only in complexity things and we forget the simple ones.
Some months ago I took a lot of interviews and at the beginning it was so hard (first because my English is bad, second to be honest I didn't have a good level), but one think that I hate is that recruiters didn't give me ANY feedback about what I did wrong (even if I asked them, they said we can not give you the feedback now, I didn't ask about the feed back, I asked about a recommendation how to improve, because how Can I do it good if I don't know what is wrong with me?).
Feedback is so important to improve.
Hiring laws, relating to discrimination, can make it tricky for companies to provide honest feedback. It's unfortunate.
Sites that provide prescreening and practice interviews are a bit more flexible.
Why not bring a cheat sheet or two to an interview? When I develop/test I use checklists for my work. Shouldn't that be allowed during an interview? It won't give the person the answers, but I always struggle with syntax as I bounce around many languages.
A simple cheat sheet might be good, especially if all it does is keep your thoughts focused.
There are certain items a person could bring to an interview that would be a plus in my book.
I'd not be opposed to this. It's still better to have them memorized, for time reasons, but a nicely organized cheat sheet could definitely help. If you're capable of using the reference quickly, then when not. If you don't know the language at all, a cheat sheet is unlikely to help you.
How can you pay attention to braces and semicolons knowing they don't have a formatter running? :/
Sorry if this is precisely nitpicking, but I found that line rather hypocritical.
I'm not so concerned about misalignment, but there's still room to be inconsistent, like putting some braces on a new line, and some not. Languages like JS have optional semi-colons. C++ allows if statements with braces, or single line ones without.
Overall, this type of thing is a minor consideration. It's highly unlikely my evaluation would be affected, but it is something I will point out in the feedback.
They might have a method to their madness that you don't immediately understand.
I feel like it's mandatory they at least once ask "can I use my editor to format" or "complain" about the interview editor not having a formatter :)
Shows that they are about the good practices and not the bikeshedding.
Asking "can I change the formatter settings" would be worrying though xD
Most candidates seem to have some experience, even in junior positions. It may be an internship, or short-term job they had. Though, the more junior somebody is the less I consider experience. Letting them talk about their position usually helps though, even if it was only for a few months.
Don't lie about what you did, give an honest assessment, or factual, of how you saw your position. It's easy to see through bravado and nonsense. Plus, you want the interviewer to understand where you are now.
"While you're coding, I expect you to talk about what you're doing."
I was "almost" rejected once because I spoke a lot instead of writing the code.
Soft skills are so underrated, yet 90% of daily interactions depend on them.
See personally a problem I can have in interviews is freezing up on questions that I know the answers to.
Any recommendation for that?
I would say the single best thing you can do for yourself is to put yourself into that situation repeatedly. It will be very uncomfortable at first, but it will get easier as time goes on. Human beings are very adaptable!