Understanding your interviewer is critical to your success during an interview. You need to listen actively to what they say and how they say it. Don’t brush off this advice as self-evident. When caught in the moment, you can miss what the interviewer has said.
This article complements the chapter on "Listening" in my class How to Pass a Coding Interview.
The curse of focus
Many of us become focused while writing code. Our brain shuts off external stimuli and concentrates entirely on the problem at hand. We greet noises with a curt nod and continue working. Not listening is a great way to fail the interview.
While resistance to interruption may be an essential skill to work in a noisy office, it is counter-productive when in an interview. This is not the time to get lost in flow. An interview is an interactive situation, and it’s essential you hear every word the interviewer says.
The moment an interviewer speaks, pause your coding and focus on what they are saying. In person, or over a video call, look at the interviewer. Body language and tone reveal a lot about what the interviewer is thinking.
“But wait,” you say, “they’re interrupting me.” You’ll find that if you’re going in the right direction, making good progress, and explaining yourself well, that the interviewer will fall silent. Or they’ll nod their head and say things like “good”, “okay”, or “mhmmm”. Those are good signs.
Anything else is a clear sign you’re going off track. Stop what you’re doing and listen to the prompts.
Read between the lines
The interviewer’s words will be ambiguous. There’s an expected level of politeness in interviews, so they may temper negative criticism. If you’ve veered too far from the expected answer, the interviewer may become confused. They may be bad at vocalizing their thoughts, or they may even be uncertain about their own comment.
Watch the interviewer, listen to their tone, and determine the context and intent of their comments. In all cases, let them speak fully and do not interrupt them. I find it extremely frustrating when candidates don’t let me speak. And it reflects poorly on them, as they’ve showed it is difficult to work with them.
Identify why a comment is being made:
- There is an error in your approach, and they are trying to help you correct it.
- They don’t understand something you’ve done and would like an explanation.
- They want to check your understanding of something you’ve done.
- You’ve done something well, and they wish to challenge you further.
- They have an anecdote they feel the need to share.
Understanding why they’ve prompted you helps you determine how you should respond. It may sound like you’re expected to be a mind reader, but this isn’t true. Look at your work, think for a moment, and hopefully the comments will make sense.
If you don’t understand, ask for clarification. Practice active listening, where you repeat what the interviewer said with new phrasing. This confirms you’ve understood and ensures you are reacting to the prompt correctly.
There are some highly rated books on Active Listening, and though I've not read them personally, I'm sure you can get more information there. Let me know if you find a good one. I'll add the basics of the technique in a future article.
Don’t be aggressive or clever
Accept criticism and be happy for it. At all costs avoid being defensive and trying to justify the approach you’ve taken. Make the assumption that the interviewer has seen every solution to a problem before, both good and bad. If they don’t understand what you’re doing, the greatest likelihood is because you are doing something wrong.
On rare occasion I’ve had a candidate do something I found unintelligible, yet turned out to be correct. The good candidates immediately understood my concern and clarified quickly. If you can’t do this, then you’re better off following the interviewer’s approach. Otherwise, you’ll continue down a path of murky understanding.
If you’re being asked a question, either to explain your code or a related concept, make sure you answer the question. It’s good to identify leading questions, but you must still answer the direct question.
You may get a question like “How does a vector accomplish what you need here?” Chances are that is a rhetorical question. The interviewer believes you to be using the wrong type and wants you to correct it. But they could also be genuinely asking: your approach may confuse them, or they are checking your knowledge. There’s no way to know for sure. Thus, you must answer the direct question and then follow-up by acting on the rhetorical one.
Don’t waste your effort
Ensure your answers are interactive, not that you’ve gone off into a long winded explanation. Pause at the end of thoughts, or sentences, and give your interviewer a chance to respond. They may let you continue, stop you, or change the direction of their inquiry.
This is another reason to accept their views and change your code accordingly. It buys you valuable time and makes a better impression. Spending your time arguing, or justifying your work, both means you may not finish, plus the interviewer will consider you combative.
Many people run out of time in my interviews. Not always, but often this is due to them not giving me a chance to give comments. They continue working in the wrong direction or ramble away the clock.
A good interviewer is using prompts to help you navigate the interview. There is a lot to cover in a limited amount of time. When you go off track, it’s a waste of time. It’s okay when it happens, but you must let the interviewer guide you back to what they are expecting.
Listen carefully to your interviewer to improve your chances of getting a positive evaluation.
Originally posted on Interview.Codes
Top comments (0)