When I interview people, the same problem comes up again and again: They try to jump straight to an optimized solution.

Sometimes that works for them, but more often than not, they end up falling flat on their face. You know why?

Because they don’t understand the problem.

I don’t mean that they don’t understand generally what they’re supposed to do. They have a vague idea. I mean after all, I did spend several minutes explaining to them what I expected them to do.

But when it comes right down to it, they don’t internalize the problem. They lose the forest for the trees. Many people I’ve seen will start creating variables for all these different things or writing loops or initializing data structures, without actually knowing what the output is going to be.

Eventually, they’re up shit creek because they decided to use a HashSet, but the output is supposed to be sorted. Or they use a LinkedList but need constant time random access.

Sometimes I see even worse happen: They get so deep into the weeds that there is no rescue. When it gets to that point, I have to walk them back onto the right path, and that is a major demerit in my book.

So how can you avoid this tragic fate? Well if you read the title, then you already know. Start by finding a brute force solution to the problem being asked.

Always start your interview by finding a brute force solution to the problem.

The brute force solution makes you really understand the problem without worrying about optimizing your solution. You know what your input will be and exactly how it needs to be modified to get to the output.

You also have solution. Even a bad solution is way better than no solution. Sometimes I ask tricky questions where the interviewee can pass as long as they code up some solution, even if it’s wildly inefficient.

Last but not least, a brute force solution gives you a jumping off point that you can optimize from. Once you have a brute force solution, you can use many different techniques to improve your time and/or space complexity (ideas here).

At the end of the day, your interview is 50% how you solve a problem and 50% how you code up that solution. Don’t miss the coding part because you got stuck on solving the problem.

Always start by finding a brute force solution and you’ll never get totally stuck.

How to find a brute force solution (with examples)

So how do you actually find a brute force solution? The technique I love works for any problem where you are asked to generate all of “X” that meets some property: generate every possibility, then check which ones are valid.

Example: the staircase problem

Say you have a staircase of length N and you can take steps of length one, two, or three, and you want the total number of combinations of steps. With brute force you don’t need to be clever yet — you can validate any given set of steps by checking that the distance between each step is no more than three. Then you just recursively generate all the combinations and count the valid ones.

Example: the 0-1 knapsack problem

The same approach works for the knapsack problem. As you recursively build combinations of items, you continually check that their total weight stays under the knapsack’s maximum weight. Generate the possibilities, keep the ones that fit.

In both cases, once you have a working brute force solution you can optimize it — often with dynamic programming. But the brute force version is what gets you to a correct answer first, which is exactly what your interviewer needs to see.