Once you’ve passed the resume screen, the number one factor that determines whether you’ll get that coveted offer letter or not is how you performed in the technical interview.
To pass the interview, you need technical skill, but technical skill itself is not sufficient. You can think you aced the interview… and still fail. And since most companies don’t give feedback, it can be next to impossible to figure out what went wrong. That being said, here are some common reasons for failing and interview and some guidelines to think about when diagnosing a failed interview:
1. You didn’t make enough progress on the problem
Note that I didn’t say, “You didn’t solve the problem.” You don’t always need to solve a problem and write out the code to pass the interview. For some questions that are particularly difficult, you may end up only having enough time to sketch a general approach.
At the very least, however, you should have gotten to a general approach for solving the problem. By this, I mean that you proposed a solution that is better than brute force, or you’ve established that you can’t do better than the brute force approach. Failing to do so is basically a death sentence for your interview chances.
2. You were too slow and didn’t get through all of the problems.
At a Bay Area startup (starts with a “P”) interview, I solved the problem, but I took so long to answer the question that there was no time to answer the remaining questions.
This is the hardest to diagnose, since you can never really know if this is the reason why you failed the interview. As a rule of thumb, I’ve found that interviews usually have more than 1 question, where the first is a warm-up.
3. Your solution is complicated
This issue is closely related to reasons 1 and 2. Complicated solutions require writing complicated code, which takes longer and is more prone to bugs.
After you solve a problem and write the code, compare your code with a reference and see if their approach or code is simpler.
4. You didn’t communicate well enough with the interviewer
While you are hard at work thinking about how to solve the problem, all the interviewer hears on the other side is static. Imagine if you had a conversation with a friend that went like this:
(You): “Where do you want to eat?”
(Friend): [Dead silence]
(Friend): [Stares pensively at a whiteboard that appeared out of nowhere]
(Friend): [Pulls out whiteboard marker and crosses arm]
Fifteen minutes later…
(Friend): I think I’ll have leftovers at home.
Standing there thinking in silence is just awkward for the interviewer. Even worse, by the time you articulate your solution, the interviewer might have no idea what you’re talking about. Dude, I asked you where you wanted to eat; how did you get to eating leftovers at home???
You need to tell the interviewer what you are thinking about, from brainstorming general approaches for the problem to running test cases through your code. Keeping your thoughts to yourself will not help the interviewer understand your thought process at all. As an added bonus, the interviewer can bring you back on track if your approach is going nowhere.
5. You ignored the interviewer’s feedback.
If the interviewer gives you a hint, take it. Ignoring it shows that you are stubborn and a poor listener.
It’s not enough to know how to solve the problem; you have to solve it while demonstrating that you are thoughtful, a good communicator, and open to feedback.