Nailing the live coding interview
The objective behind a live coding interview, from the interviewer’s point of view, is usually to get a feeling of what having the interviewee on your team. That is done in the live interview by trying to get a feeling of their coding abilities and what it's like to talk to them about code. The devil is in the details, as usual. How much it is split between those two objectives? What tools are allowed? In which parts does the interviewer help solve the problem or gives more food for thought? All those vary, but don't lose hope just yet. There's a common pattern.
You have to talk.
Talk.
Talk. Talk. Talk.
If you improve on that axis, you might increase your chances of a successful interview.
By talking you give the interviewer a chance to see how you think.
By talking you give the interviewer a chance to help you.
By talking you give the interviewer a chance to talk with you.
So how do we turn you into a radio star? Ready to talk non-stop but also ready to be interrupted with questions, without stopping the show. Talking about your thoughts is definitely a different skill from having them in the first place.
If you were making a presentation about a train of thought, you would probably not structure it the way it actually happened. You would change the narrative such that it tells a story, because stories are engaging.
But in a live setting you don't have the luxury of going through things and later turning it into a story. So we have to do the other way around. You adapt your way of thinking to let the story unfold.
The story of your interview is how it goes from zero to the challenge solved, with a nice conversation had along the way. This will feel more natural once we lay out the story arc:
The problem is presented
Understand the problem and the relevant concerns
Decide on the approach to tackle the problem
Start solving
1. The problem is presented
The interviewer will tell / show you what the problem is about or present you with a problem statement for you to read. Pay attention to what they are saying. Interrupt with questions when you are two steps behind. Otherwise, let them continue.
When a problem is presented, a lot of times it goes like “and Blob is made out of Foo”, when they have explained Blob but not Foo. Give the interviewer a chance to explain Foo before you jump in asking what it is. Allow yourself to be one step behind. If you are two steps behind, then you are at risk of losing the train. Interrupt then.
You can phrase your question like: “I’m sorry, can we please take a step back? I’m not sure if I fully understood Foo.” Then repeat in your own words what you understood about it. That will help the interviewer help you.
2. Understand the problem and the relevant concerns
At this stage you’ve been given the goal of the game you’re about to play, but not the rules of the game. You should clarify the scope of concerns to take into account.
Example questions:
Do I need to think of concurrency?
Is storage part of the scope of the problem
Is the API meant to be optimised for read or write?
A couple of questions to test the waters should help you get closer to the mental model of the interviewer.
3. Decide on the approach to tackle the problem
If you had the goal of helping a fellow developer tackle a task, it’s likely that before letting that person write code you would think of the easiest way to tackle the problem. Do the same thing here, double checking with the interviewer.
Example questions:
The existing tests seem to be in increasing order of complexity. I’ll turn them from red to green, going top to bottom. Is that ok?
There seem to be specific concerns we should have when the API is designed. Could I start from there?
4. Start solving
At this point you’ve set the stage for what’s happening next. You are now ready to take the first step and start talking through the code you are writing. You have all of the context you previously built, ready to be leveraged in the conversation. It’s okay to not literally talk and write at the same time. You can talk between lines of code. You can also write code comments with notes to come back to. It’s easier to talk while writing a comment, because you’re writing in plain English, so you can say the sentence as you write.
Follow the steps you created for yourself and unfold your narrative into your happy ever after.
Bonus tip:
You can practice by yourself by writing code while talking about what you are doing. This helps you get into the headspace of narrating as you go.
Interviews are hard. Good luck out there!