There you stand, alone staring at a whiteboard with the hiring manager standing behind you.

They ask you to solve a problem you’ve never seen before.

Have you ever had the experience of freezing after being given a particularly hard problem?

This is common for engineers (myself included) and the reason for this is something called an Amygdala Hijack, one of the many blockers we talk about during Outco. In short, this is when the fear center of the brain takes over higher functions of the brain and prevents us from being able to think clearly and effectively problem-solve.

The technical interview is one of the most grueling parts of an engineers job search.

You have to be ready to answer any question - whether you’ve seen it or not, but there’s a hidden gem you can utilize to make any question easier to answer.

What is that, you might ask? The simple act of asking a question.

How to Utilize Questions Effectively

After being given the prompt to any problem, start by asking questions about it. It doesn’t matter if you’re just working on the problem by yourself or if an interviewer is asking you.

This is all about establishing an understanding of the problem, and to constrain your thinking about it.

Start by Asking Yourself Some Questions

• Does this look like a problem you’ve seen before?

• What do you remember about similar problems?

• What immediately stands out about it to you?

Begin to think through time and space constraints. Knowing this will help you rule out solutions that run too inefficiently, or it will give you a hint of how many auxiliary data structures or loops you need.

Interview Questions About Arrays

If you have an array, for example, ask if it’s sorted.

• Does it contain only numbers?

• Are those numbers integers?

• Can they be negative, or just positive?

Ask if there is a max length, or range of input sizes.

Interview Questions About Strings

For strings, ask if there is a distinction between upper/lower case.

• Are there spaces?

• Is there punctuation?

Ask about edge cases, like empty strings, empty arrays, very large or very small inputs etc.

Asking Language Specific Questions

• Can you use certain libraries?

• How should you handle errors?

• What kinds of inputs should your function handle?

Asking Questions in a Pair Programming Situation

• Can you google syntax and docs?

• Can you run your code with examples?

• Will the interviewer be able to answer certain questions?

Try to figure out what other guarantees there are in the problem.

Again, it’s all about putting constraints on your thinking and finding parameters that will focus your attention towards a smaller solution space.

What if the Interviewer Doesn’t Give You An Answer?

Keep in mind time and space complexities might not always be given. They might just say ‘do the best you can.’

This shouldn’t deter you, but it also means there could be several ways to solve this problem, and some are better than others.

The point is that there are a ton of conditions and constraints that will help focus your thinking and can hint at the direction you need to go in.

At the most basic level you are gathering data.

With all this said, keep this portion of the interview short, maybe just a couple minutes of discussion or thinking.

Don’t frame it as you looking for hints. Frame it as you trying to understand the problem better.

Also remember you can ask questions later on as they come up, so don’t stress about trying to nail EVERY constraint now.

In summary, asking questions is all about gathering more information making sure you are solving the correct problem.

It would shock you how often people start solving different problems than the one I asked, all because they didn’t clarify what they were supposed to be doing.

Let’s use an example to practice.

The Tower of Hanoi Problem

By Trixx (I designed this using http://thewalnut.io/) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Problem: Tower of Hanoi

The Tower of Hanoi is a puzzle with three pegs, and a variable number of discs. The discs are stacked with the largest ones on the bottom and the smallest on top. Each time a disc is moved from one peg to another peg, counts as one step, regardless of if the new peg is adjacent to the old one.

The goal of the puzzle is to move the whole tower from one peg to another peg in the smallest number of steps.

Your task is to write a function that takes an integer as the input and outputs another integer that represents the minimum number of steps necessary to move a tower of that size from one peg to another.

Input: Integer (discs)Output: Integer

In this example the questions you should be asking are about the nature of the discs, and the answers will provide you with constraints you can use later on:

• Can you move more than one at a time?

• Can you put larger ones on smaller ones?

• Is there a maximum number of discs for this problem to be solvable?

• What should the time complexity of the solution be?

You should also be asking if you actually have to simulate the motion of the discs themselves.

This isn’t an immediately obvious question to ask, but it’s a very important one. A lot of students start devising data structures and disc swapping algorithms they’ll need to solve this problem, when in reality they’ve already failed the interview.

The solution only asks for the NUMBER OF MOVES, not for you to actually create the SEQUENCE OF MOVES. This is a BIG difference, one which simplifies the problem tremendously.

This is something all interviewees should be on the look out for when they are asking questions.

Often times the problem description will appear deceptively difficult, or conversely, deceptively simple. Asking more questions about it will help shed light on whether the problem is straight forward, or if there are hidden subtleties.

Document All Question Answers or Constraints

All the answers to these questions should go somewhere, whether that’s on a whiteboard, or on a shared text editor, or even a piece of paper.

You should also write down everything that comes to mind: patterns you notice, constraints you are given or things you observe. Any hunches, ideas or thoughts should all go somewhere.

This might be like identifying important features of the problem.

• For example, is the max/min element relevant?

• Does there seem to be some kind of pattern between input size and output size?

• Can you rule out certain approaches based on constraints, like using built in methods or certain libraries?

These are the building blocks of your solution. Think of this as a brain dump.

You want to get everything down so you can go back to it later. You can only hold so much in your head at a time, and this will help lighten some of that cognitive load.

Additionally, the process of writing things down and thinking of how to express them in another way is what helps your brain move closer to a solution. It’s the same as how the simple act of talking out loud about a problem can help you solve it. There’s something that happens when your brain translates ideas from one format to another, that makes you gain a deeper understanding of those ideas.

Again, the goal here is to simply get everything written down somewhere.

It doesn’t need to be super organized, but it should be legible and you should be able to make sense of it. This step is meant to be a tool for you to use later one when you are solving your problem.

/*Here are the constraints:Only move one disc at a timeOnly smaller discs on larger discsNo max number of discs Number of discso won't be negativeDo the best you can on space and timeNo need to simulate moves, just output total number*/

If you have any questions or comments on this process please leave them below in the comments.

Want to see Outco’s live 5-week program in action? You can now drop-in on a free class with one of our technical mentors.

Learn how to solve a dynamic programming problem and receive multiple optimizations and solutions with a free visitor class.