loading...
Interview Cake

Why you're hitting dead ends in whiteboard interviews

gameguy43 profile image Parker Phinney Originally published at interviewcake.com ・4 min read

Listening vs. holding your train of thought

Finally! After a while of shooting in the dark and frantically fiddling with sample inputs on the whiteboard, you've came up with an algorithm for solving the coding question your interviewer gave you.

Whew. Such a relief to have a clear path forward. To not be flailing anymore.

Now you're cruising, getting ready to code up your solution.

When suddenly, your interviewer throws you a curve ball.

"What if we thought of the problem this way?"

You feel a tension we've all felt during the coding interview:

"Try to listen to what they're saying...but don't lose your train of thought...ugh, I can't do both!"

This is a make-or-break moment in the coding interview. And so many people get it wrong.

Most candidates end up only half understanding what their interviewer is saying. Because they're only half listening. Because they're desperately clinging to their train of thought.

And it's easy to see why. For many of us, completely losing track of what we're doing is one of our biggest coding interview fears. So we devote half of our mental energy to clinging to our train of thought.

To understand why that's so wrong, we need to understand the difference between what we see during the coding interview and what our interviewer sees.

The programming interview maze

Working on a coding interview question is like walking through a giant maze.

You don't know anything about the shape of the maze until you start wandering around it. You might know vaguely where the solution is, but you don't know how to get there.

A maze with a mouse at one corner labeled "You" and a piece of cheese at the opposite corner labeled "An Answer." Only a small section of the maze directly surrounding the mouse is revealed, showing two possible paths to the cheese.

As you wander through the maze, you might find a promising path (an approach, a way to break down the problem). You might follow that path for a bit.

The same maze with the mouse further along, nearing the cheese.

Suddenly, your interviewer suggests a different path:

Now the mouse has turned around in the same spot, and an arrow points the mouse back towards the beginning of the maze to a new path.

But from what you can see so far of the maze, your approach has already gotten you halfway there! Losing your place on your current path would mean a huge step backwards. Or so it seems.

That's why people hold onto their train of thought instead of listening to their interviewer. Because from what they can see, it looks like they're getting somewhere!

But here's the thing: your interviewer knows the whole maze. They've asked this question 100 times.

I'm not exaggerating: if you interview candidates for a year, you can easily end up asking the same question over 100 times.

So if your interviewer is suggesting a certain path, you can bet it leads to an answer.

Following the new path, the mouse has made it to the cheese at the end of the maze.

And your seemingly great path? There's probably a dead end just ahead that you haven't seen yet:

Now the entirety of the maze is revealed, showing that the mouse's original path through the maze lead to a dead end.

Or it could just be a much longer route to a solution than you think it is. That actually happens pretty often—there's an answer there, but it's more complicated than you think.

Again the maze is revealed, showing an alternate scenario in which the mouse's original path eventually lead to the cheese but in a much more complicated way.

Hitting a dead end is okay. Failing to listen is not.

Your interviewer probably won't fault you for going down the wrong path at first. They've seen really smart engineers do the same thing. They understand it's because you only have a partial view of the maze.

They might have let you go down the wrong path for a bit to see if you could keep your thinking organized without help. But now they want to rush you through the part where you discover the dead end and double back. Not because they don't believe you can manage it yourself. But because they want to make sure you have enough time to finish the question.

But here's something they will fault you for: failing to listen to them. Nobody wants to work with an engineer who doesn't listen.

So when you find yourself in that crucial coding interview moment, when you're torn between holding your train of thought and considering the idea your interviewer is suggesting...remember this:

Listening to your interviewer is the most important thing.

Take what they're saying and run with it. Think of the next steps that follow from what they're saying.

Even if it means completely leaving behind the path you were on. Trust the route your interviewer is pointing you down.

Because they can see the whole maze.


Get the free coding interview crash course

Don't leave your interviews to chance. I'll teach you the underlying patterns behind the clever algorithms you'll need to come up with during tricky coding interview questions.

Send me coding interview tips »


Discussion

pic
Editor guide
Collapse
guifroes profile image
Guilherme Froes

This is excellent advice!

Being an interviewer myself I value personality traits like good listening, being able to collaborate and open mindedness way more than having having some specific knowledge.

Candidates often assume that they're only being evaluated for what they know or don't which is a mistake. To me, the kind of person and professional they are is way more important.

Collapse
gameguy43 profile image
Collapse
gmartigny profile image
Guillaume Martigny

Hi Parker,

Being asked to throw some code on a whiteboard isn't some kind of red flag though ?
First of, as you mention, it's hard to focus when under stress from the interview. Then, company should be looking for people knowing how to learn not people knowing one solution.

Collapse
gameguy43 profile image
Parker Phinney Author

I think the whiteboard coding interview can be quite successful /if it is done well/. Which it unfortunately often isn't.

It ought to feel like a collaboration. Your interviewer's goal should be to get a taste for what it would feel like if they were stuck on a problem and asked you to grab a whiteboard with them and map it out together.

In that configuration, it's not about the candidate having all the answers right away. It's about their ability to communicate and take little ideas that you feed them and build on them.