# Tricks for getting unstuck during a coding interview

### Parker Phinney Jun 11 '18 ă»5 min read

Getting stuck during a coding interview is rough.

If you werenât in an interview, you might take a break or ask Google for help. But the clock is ticking, and you donât have Google.

You just have an empty whiteboard, a smelly marker, and an interviewer whoâs looking at you expectantly. And all you can think about is how stuck you are.

You need a lifeline for these momentsâlike a little box that says âIn Case of Emergency, Break Glass.â

*Inside* that glass box? A list of tricks for getting unstuck. Hereâs that list of tricks.

## When youâre stuck on getting started

**1) Write a sample input on the whiteboard and turn it into the correct output "by hand."** Notice the *process* you use. Look for patterns, and think about how to implement your process in code.

Trying to reverse a string? Write âhelloâ on the board. Reverse it âby handââdraw arrows from each characterâs current position to its desired position.

Notice the pattern: it looks like weâre *swapping* pairs of characters, starting from the outside and moving in. Now weâre halfway to an algorithm.

**2) Solve a simpler version of the problem.** Remove or simplify one of the requirements of the problem. Once you have a solution, see if you can adapt that approach for the original question.

Trying to find the k-largest element in a set? Walk through finding the *largest* element, then the *second largest*, then the *third largest*. Generalizing from there to find the k-largest isnât so bad.

**3) Start with an inefficient solution.** Even if it feels *stupidly inefficient*, itâs often helpful to start with *something* thatâll return the right answer. From there, you just have to optimize your solution. Explain that this is only your first idea, and that you suspect there are faster solutions.

Suppose you were given two lists of sorted numbers and asked to find the median of both lists combined. Itâs messy, but you could simply:

- Concatenate the arrays together into a new array.
- Sort the new array.
- Return the value at the middle index.

Notice that you couldâve *also* arrived at this algorithm by using trick (2): Solve a simpler version of the problem. âHow would I find the median of *one* sorted list of numbers? Just grab the item at the middle index. Now, can I adapt that approach for getting the median of *two* sorted lists?â

## When youâre stuck on finding optimizations

**1) Look for repeat work.** If your current solution goes through the same data multiple times, youâre doing unnecessary repeat work. See if you can save time by looking through the data just once.

Say that inside one of your loops, thereâs a brute-force operation to find an element in an array. Youâre repeatedly looking through items that you donât have to. Instead, you could convert the array to a lookup table to dramatically improve your runtime.

**2) Look for hints in the specifics of the problem.** Is the input array sorted? Is the binary tree balanced? Details like this can carry huge hints about the solution. If it didnât matter, your interviewer wouldnât have brought it up. Itâs a strong sign that the best solution to the problem exploits it.

Suppose youâre asked to find the first occurrence of a number in a sorted array. The fact that the array is *sorted* is a strong hintâtake advantage of that fact by using a binary search.

Sometimes interviewers leave the question deliberately vague because they want you to *ask questions* to unearth these important tidbits of context. So ask some questions at the beginning of the problem.

**3) Throw some data structures at the problem.** Can you save time by using the fast lookups of a hash table? Can you express the relationships between data points as a graph? Look at the requirements of the problem and ask yourself if thereâs a data structure that has those properties.

**4) Establish bounds on space and runtime.** Think *out loud* about the parameters of the problem. Try to get a sense for how fast your algorithm *could possibly* be:

- âI have to at least look at all the items, so I canât do better than timeâ.
- âThe brute force approach is to test all possibilities, which is time. So the question is whether or not I can beat that time.â
- âThe answer will contain n
^{2}items, so I must at least spend that amount of time.â

## When All Else Fails

**1) Make it clear where you are.** State what you know, what youâre trying to do, and highlight the gap between the two. The clearer you are in expressing *exactly* where youâre stuck, the easier it is for your interviewer to help you.

**2) Pay attention to your interviewer.** If she asks a question about something you just said, thereâs probably a hint buried in there. Donât worry about losing your train of thoughtâdrop what youâre doing and dig into her question.

##
Relax. Youâre *supposed* to get stuck.

Interviewers choose hard problems on purpose. They want to see how you poke at a problem you donât immediately know how to solve.

Seriously. If you *donât* get stuck and just breeze through the problem, your interviewerâs evaluation might just say âDidnât get a good read on candidateâs problem-solving processâmaybe sheâd already seen this interview question before?â

On the other hand, if you *do* get stuck, use one of these tricks to get unstuck, and communicate clearly with your interviewer throughout...*thatâs* how you get an evaluation like, âGreat problem-solving skills. Hire.â

## 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 Â»**

(open source and free forever â€ïž)

You're a great guy, Parker! Thanks for all the tips and stuff :)