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.