Slowing Down the Technical Interview

Technical interview challenges can be incredibly nerve wracking. Having someone watch you code is scary! One way that I've seen engineers be successful is by sowing things down. Let's talk about some strategies that I've seen be pretty effective.

All too often, when facilitating interviews, I see candidates take the technical question and immediately roll with it. This may work for folks that are really comfortable in a technical interview setting, but for the rest of us that's a sure way have the interview quickly unravel.

There's a few key things that I'm looking for when I interview a candidate, all of them important in your day-to-day as a developer. Sure, solving the problem is important, but so are communication, planning, information gathering, checking your assumptions, and asking questions. Intentionally slowing down the interview can do wonders in showcasing each of those core competencies, and guess what? It can also help you solve the problem!

Slowing it down

The first thing you should do once the interviewer(s) present you with the challenge is stop and think, do not code. Take a moment to internalize the problem, ask clarifying questions even if they're a bit obvious, and really make sure that you fully understand what it is that you're being asked to solve. Then, repeat the goal of the challenge back to the interviewer(s). This will either get you confirmation on your way forward or they'll help you correct course.

From there, start writing comments in your editor and outlining step by step what it is what you'll be doing. This will do a few things for you, primarily giving you a great blueprint to follow and check your assumptions. This will also show them how you think, how you communicate, and it lets them give you feedback before you even start, which hopefully they do!

Now that you have a clear understanding of the problem space and a blueprint on how you'll be solving the problem... you still shouldn't write real code! It's gonna be so tempting to start hacking away at it at this point, but resist!

What you should be doing at this point is writing pseudocode. If you haven't done this before I highly recommend practicing it a few times. Pseudocode doesn't have to be pretty. Think of it as scratch notes for ideas you have. Just follow your blueprint and lay out some fake code. This can help expose flaws in your thinking before you even start writing code!

Solving the challenge

Finally, it's time to solve the challenge. That's ultimately what our goal is, right? But here's the thing. In many cases I see engineers try to solve the problem with the best solution and often run out of time. It's important to remember that solving the problem is more important than trying to do so with the "best" approach and running out of time.

So nest those loops, throw memoization out the window, forget about pesky rerenders. Your primary goal is to solve the problem. Worry about optimizing and making it better only after you've arrived at a solution. Remember the old adage "make it work, make it right, make it fast"? It definitely still applies in an interview.