The Top 3 Coding Interview Questions People Bomb
I give a lot of coding interviews for my company. College students looking for an internship, college graduates looking for their first job, experienced programmers looking for a career change; I interview ‘em all. These aren’t full interviews, just a phone screen to determine if it’s worth pursuing the candidate further. And the format is pretty much identical for all of them: I give them a very simple problem, let them code it up in their favorite language (and their favorite code editor), and we talk about it.
90% of the candidates fail. These are the questions I ask that tend to do it:
1. Does this work?
I ask this when it looks like they’ve stopped coding. I want to see if they can actually think through their code and justify if it works and why (without running it).
The answer is usually something like “Uh… maybe?” It amazes me how many candidates can’t logically think through their own code. Of course running your code to make sure it works is a good idea, but you can’t let that be a crutch. Even as a student you should have some idea of why your code works, some mental model of what each line of code is doing in the machine.
2. Why did you do that?
I ask this after they change their code with no explanation.
I’m looking for two things here. The first is pretty much the same as the last: are you methodically thinking through what your code is doing? Most candidates can’t give a good answer to this question because they have no real understanding of their own code, they’re hoping to stumble upon the right solution as you might if you’re repeatedly running your code until it looks right.
The other thing I’m looking for is if they have an understanding of the fundamentals of their chosen language. As I said, the problems I give are very simple, so most candidates get a working solution very quickly. But when I ask why they solved it in that way, I discover that many candidates take their programming language for granted. They give some half-hearted explanation or fall back on experience, saying they’ve used that kind of code before.
Maybe they have an intuitive understanding of the language, which is great, but that’s not enough. Professional programmers need to communicate. They need to explain, to justify, to argue.
3. Is there any other way to do that?
This is the real killer. Even when their program works and they can explain why it works, I follow up with this question. The answer is usually shocked silence.
Here’s the thing: if you only know one way to code something, you don’t really
know how to code it. People who don’t get this are the kind of programmers that
write a 500 line if/else
chain because they never bothered to learn about
for
loops. They’re the kind of programmers who fill their programs with global
variables because they don’t have the time to read about that dependency
injection thing. “My code works, why should I care?”
I always clarify: I’m not asking for a “better” solution. Literally any other program that accomplishes the same task would do, but they still can’t think of anything. This is aboslutely crucial as a programmer, because programming is a creative act, programming is problem solving. If you aren’t creative, you will fail. What will you do when the only solution you can think of doesn’t work?
Conclusion
When they bomb my interview, many candidates ask for feedback. I usually say something like “practice your problem solving skills”, or “focus on fundamentals”. But the real problem seems to be more basic than that. The real problem isn’t even specific to programming.
If I was hiring a house painter, I would want them to know that painting isn’t as simple as choosing a color. The type of paint, the material being painted, the tool being used, the humidity; all of these things matter. I don’t necessarily expect them to be an expert in all aspects of painting, but if they don’t even demonstrate concern for the nuances of their field, I’m liable to end up with splotchy, peeling walls.
A house painter doesn’t have to have any persontal investment in the house that they’re painting. It’s just a job, and it’s someone else’s house. But they need to care about paint. Because that’s what they’re being paid for.