Getting stuck in a coding interview is not game-over.

I repeat. If you find yourself seemingly unable to move forward on a coding problem, you have way more options at your disposal than you probably think.

You see, there's lots of reasons engineers get stuck. Some are technical and some are psychological. Some are obvious and some are sneaky. And it's so tempting to throw your hands in the air, assume the problem is beyond your skill-level, and panic. Don't.

Here's what you should do instead — so you might find yourself passing even when all hope seems lost.

Related: 6 technical interview woes solved entirely by practice – not genius

Rewrite the question in your own language

There have been times when I've read an interview question repeatedly and remained completely baffled as to what it was asking. It's as though the words just didn't compute at all, and I sat there thinking I must be stupid.

Turns out, what really happened was a misalignment of expectations, which can manifest in a few different ways.

For example, if you're a front-end developer, you might expect to see problems that look something like those you'd see in actual front-end work. But instead, you get something like this:

Write a function that, given n, returns the nth Fibonacci number.

If you have a strong math background, this might seem like child's play. But if you just graduated from a mobile bootcamp, you might not even remember what a Fibonacci number is. And if you don't remember (or don't really get math speak) the question itself doesn't even really make all that much sense.

If there's something in it you don't understand, ask your interviewer. It's ok to ask "to be refreshed" about the "precise definition" of a Fibonacci number. It's ok to ask the interviewer to rephrase the question a different way to help you understand what it's asking. Sure, some interviewers might be judgmental, but that's not something you can control. And even if they are, it's better to get clarity quick and make progress on the problem rather than burn time and make little to know progress.

Likewise, you might run into problems that seem totally and utterly pointless in real life, which might make you question whether what's being asked is seriously being asked. Once, I was asked to implement a word processor in a terminal. As someone who does a lot of iOS front-end work, I was pretty baffled by this question. My first thought was that it was way more complex than what was actually being asked because I could never imagine a word processor anyone would ever want to use being implemented in a terminal. My disbelief actually prevented me from accepting the problem for what it was.

The point is, when you encounter a problem that baffles you to this degree, try as best as you can to accept it for face value. If you're unclear about what's being asked, start a discussion with your interviewer and don't be afraid to confirm the details and ask probing questions. Interview questions are frequently contrived, because they're designed for interviews. It's not that the questions are inherently bad, they're just unnaturally small in scope and definitionally not practical in the way real problems are. Talking with your interviewer about the details will help you build a picture of what they intend for you to do much faster than staring at it on your own trying to guess.

Solve in bytes, not batches

If you're given a multi-step programming problem, it may be tempting to want to fully digest the entire problem before starting on the first step.

I strongly encourage you to resist this temptation.

There's nothing wrong with wanting to get a lay of the land. A little planning ahead and clarification of where you're headed is perfectly fine and reasonable.

However, this becomes maladaptive when you insist on thoroughly and completely understanding all steps before you allow yourself to proceed. Candidates frequently convince themselves, for example, that they are stuck because they don't understand some aspect of step 3, when they haven't even started steps 1 and 2. In reality, working through the first steps might help them understand the third in a way that makes the it seem a lot more obvious. On the other hand, they might be surprised to find that the interviewer doesn't even expect them to complete step 3 and was more interested in their process. And there they are, having made little to no progress because they think they're stuck!

The point is, strike a balance between time-sensitivity and the ideal circumstances for problem-solving. Problems lasting only thirty minutes to an hour require a different mindset than those which you have days to complete. Adapt your process to be strategic for these circumstances rather than falling into the habits you utilize in production.

Allow yourself to treat each step as it's own digestible chunk. Take advantage of engineering best-practices to avoid coding yourself into a corner, while also avoiding the tendency to over-engineer. For example, it may make sense to set things up so your underlying data structure is able to grow arbitrarily if need be. Or better yet, if that's a non-trivial task, ask your interviewer whether it would need to grow arbitrarily and proceed based on they're feedback. This way, you get to demonstrate that you take such factors into consideration while saving precious minutes not having to actually implement it!

Chances are, you're overthinking the problem

As Triplebyte CEO Ammon Bartram points out, "A startlingly high percentage of interview questions reduce to breadth-first search or the use of a hash table to count uniques."

Chew on that for a second.

That means the solution to the problem you're stuck on might be a lot simpler than you think.

It's all too common for candidates to gloss over obvious solutions like this in favor of more elaborate or sophisticated solutions from scratch. But in doing so, they burn time and often fail to complete problems.

I've seen so many candidates set ridiculously high expectations for themselves, only to be surprised when I've said the thing they thought they needed to do wasn't even necessary or desired in the context of the interview. A lot of coding interview questions are set to take something like thirty minutes or an hour. That is not enough time to divine a perfectly optimized solution for a highly complex problem.

The point is, you're not in an academic setting. Even if your coding question is academic in style, your interviewer isn't necessarily looking for you to reinvent the wheel.

So when you're stuck, take a step back, and consider whether there's a simple way of reaching your goal. Explain your thinking to your interviewer, offer a simpler approach, and ask whether that would be acceptable. And if you want, you might score brownie points by roughly mentioning a more advanced approach while being practical about your actual choices on a time-sensitive problem.

Start rubber ducking (at your interviewer)

A coding interview is unusual in that you have a captive audience while you code: your interviewer(s). That makes it a uniquely great opportunity for one of the best problem-solving techniques of all time: rubber ducking.

Rubber ducking (aka rubber duck debugging) is a powerful technique for solving especially hard programming problems. When you get into a rut, you find an audience, and force yourself to verbalize all of your assumptions and approaches to solving it. In the process of doing so, the answer typically "leaps off the screen" without your audience ever even having to say a word. This is one of the most effective, yet underutilized, techniques in all of software engineering (as I explain in detail here).

This could not be a more perfect technique for getting unstuck in a coding interview. The interviewer is already fully familiar with your problem, so there's no awkwardness when you're explaining your thinking. Further, they are inclined to listen and engage with you, because your explanations are giving vital insight into your problem-solving style, which helps them more readily identify strengths. Finally, they are able to offer assistance if they desire, which can take the form of little hints or strong direction to change course. And even if they offer no assistance, you are markedly more likely to solve the problem on your own just by virtue of articulating it.

So, when you're stuck in an interview, don't hesitate to start quacking.

Double-check language-specific assumptions

If you find your code is not behaving as expected, it might not be your logic at all. In fact, I've seen hundreds of candidates bomb coding interviews because of the programming language itself!

That is, in coding interviews, candidates often choose programming languages other than the ones they used day-to-day. Python is popular, for example, because of its flexibility and expressiveness, even for candidates who primarily code in C or Java.

This means such candidates aren't as familiar with the subtleties of the languages particular idiosyncrasies and memory management model, which can lead to the sneakiest problems (like returning unexpected values from simple data structures).

And even if you are very familiar with the language, coding interviews often require you do kinds of problems you are less familiar with, leading you to run into edge cases with your language you never experienced before.

In short, if you've checked your logic and just can't see a problem, open your mind to a class of problems you might not as often consider: language quirks.

Don't prematurely rule out tools

A lot of candidates are hesitant to use tools and debugging techniques they're familiar with, because they mistakenly treat the interview like they're taking the SAT. That is, they assume helper tools and techniques are cheating.

For example, I've had candidates ask whether they're allowed to use the debugger installed in their chosen editor, and even whether they're allowed to print to the console.

The fact of the matter is that different coding interviews have different rules and requirements, so don't make assumptions that needlessly limit your options. Some interviews are indeed restrictive, but others want to give you every opportunity to succeed.

When in doubt, ask your interviewer. You may want to install some small library before the timer begins, or when you run into a problem in real-time. You may want to use a debugger, or quickly switch editors, or open some other app that helps narrow down some problem. You may want to use a pen and paper to organize your thoughts, or your iPad with Apple Pencil, or the whiteboard in the room. Don't assume, just ask, especially if you're stuck. If they say no, ask about a similar alternative. If they say yes to even a suboptimal option, you may get an advantage that materially increases your performance.

Let go of fear

It's no secret that fear absolutely cripples your ability to think clearly, but letting go of it is much easier said than done. Fortunately, there's lots of reasons to let go of fear in the context of technical interviews that you probably haven't thought of. The more at peace you are during the interview, the more clearly you will be able to notice details and see solutions to problems that you are perfectly capable of completing.

Next steps

These are just some of the steps you can take the next time you get stuck in a coding interview. Some of them are pretty straightforward, while others might take a little contemplation before they start to make sense. There’s lots of nuance here to consider, and some of the principles apply to a variety of circumstances that weren’t directly addressed. Remember, coding interviews are a skill that can be learned and enhanced. Feel free to pick and choose your tactics, and experiment to discover what works for you.

Discussion

Categories
Share Article

Continue Reading