How to prepare for a live coding interview

It's impossible to know what they will ask on a pairing interview. But there are good practices that can be followed on your next interview.

Communicate!

Many people think the most important thing in this kind of interview is the code delivered by the end. But actually, the code is only one part of the process.

Think about interviews as small samples of how you work.

When you're pairing with someone on your team, what's essential for a good session?

Pairing is a exchange, not a monologue. Put yourself on the interviewers' shoes: if you don't say something, only focusing on the code, would that be a good experience?

Now imagine pairing with someone who asks relevant questions, feedback, exchange knowledge... That's a lot better, don't you think?

One of the things that tends to be evaluated is how you break the problem down into smaller pieces. I've heard of companies that present the challenge in a generic way on purpose just to see if the candidate asks questions to dig deeper.

Remember when I said that interviews are simulations of work situations? So, this is a very common one.

Let's say a problem came up without many details of why it's happening and you're assigned to solve it. You would have to search for these types of information: context of the problem, root cause, what's needed to solve it and avoid it to happen again (or temporary workaround vs. tech debt), etc.

If on the interview you don't get the challenge and don't ask subsequent questions to better understand it, this will be interpreted as a signal that on the situation above, you wouldn't be able to handle alone.

The challenge might look simple, but it doesn't hurt to make sure you understood: "From what I understood, I have to do this, this and then this, correct?".

I also recommend to always think out loud. It's a bit embarrassing to be with someone (both only and in-person) for several minutes without anyone speaking a word. Besides, there's the possibility that the interviewer got left behind at some point on your code while you were programming in silence.

If you think out loud, you bring the interviewer closer on your rationale. By doing that, there's good things for both sides: you get to show your framing of the solution, your tech knowledge and the interviewer can keep up with you and have more inputs to evaluate your skills.

The best interviews don't feel like interviews, they feel like a conversation between two coworkers. That's what you should aim for in any interview (technical or not).

Another tip that might be obvious but it happens a lot is to not interrupt the interviewer. That goes beyond job interviews, you could apply that on your daily life.

Wait until the interviewer stops talking before responding.

On the other hand, the interviewer has a free pass to interrupt you in a few specific situations envolving time, for example (and that's better for you):

  • The alloted time for the interview is running out and it would be great if a few specific topics got covered for more evaluation inputs later on;
  • The candidate got stuck for quite a while now and it looks like it's not evolving anytime soon, the interview must step forward and nudge or give a tip;
  • The candidate focused too much in irrelevant stuff (i.e bikeshedding) and a feedback is needed to draw back to the main points of the challenge;

Those situations can prevent the candidate from trying to solve the challenge for several minutes (but didn't understand the challenge properly) and the interviewer feels bad or avoids giving feedback/interrupting saying that the challenge is actually focused on other things.

That leads to the second skill to assess: openness to feedback.

How do you deal with feedback?

A pairing session is a constant exchange of feedback:

Person 1: “we could do it that way."

Person 2: “that probably won't work because of that, but let me try it.”

You shouldn't take technical feedback personally, assuming that the other engineer has the best intentions. Instead, you both should solve the problem the best way: that's one of the signals that companies look for in candidates.

Having critical sense is also something positive. Does that really make sense? Have I fully understood what the interviewer said? Again, you should ask clarifying questions if something is not 100% clear.

Let's imagine an ideal interaction in the interview:

You're programming everything in a single function.

Interviewer: “What if you split the business logic in other functions?”

You: “Yeah, that's probably better. I didn't even realize that it was all in a single function, if I split this using the single responsibility principle it would definitely be cleaner."

Non-ideal situation:

You're programming everything in a single function.

Interviewer: “What if you split-”

You: “Oh yeah, I know it's all in a single function and it's not ideal. I have over 10 years of experience…”

Even if you're fully aware of what you're doing, imagine interviewing someone that on the first feedback reacts that way. You probably don't want to work with this person, right?

They're aware that you're probably nervous from being interviewed and everything that revolves looking for a new job, but that's a red flag that this person doesn't handle feedback very well.

Remember that the interviewer doesn't know you and their only interaction with you will be at the interview. What kind of impression do you want to leave?

If the job opening requires senior level, what can be evaluated is how you mentor other less experienced teammates.

It's possible that they'll ask you how your implementation of the problem works under the hood, or ask to explain to them as if they've never heard of that technique/technology.

It's expected from someone senior the knowledge sharing, willingness to help developing and mentoring teammates and be a technical reference in the team (either formally or not).

Technical knowledge

Besides all the behavioral part, obviously the technical knowledge is evaluated too.

There are a few ways to demonstrate your knowledge, even if time is short.

The first one is thinking out loud as I previously mentioned. While you're thinking on how to solve the problem, you can share your rationale and step-by-step of what you're planning to do.

A lot of technology companies don't expect that you solve in the most elegant, extensible way possible (it would be ideal, of course), most of the time, the important thing is to solve it even if through brute force and then keep working towards the optimal way.

When your time is running out, tell them how you would evolve your code, the pros and cons of your approach, how would you test it, files structure, separation of concerns…

These are my tips that you can apply at any pair programming/live coding interview.

What I know that a lot of companies expect but not all of them:

  • Big O notation;
  • TDD;
  • Good practices;
  • Design patterns;
  • Algorithms.

Good luck on your next interview!