Problem-Solving Framework for Technical Interview Questions Part 1: Understanding the Problem

*This is based off of Anthony D. Mays’s technical interview question framework located here. Did some work on my own based on this and felt what I came up with also adds value.

*This article also assumes prior knowledge of data structures and algorithms

Technical Interviewing can be quite intimidating. It calls upon skills that many Software Engineers may not have nurtured and is far removed from their day-to-day work. One of those major skills is the ability to answer technical interview questions. These are usually algorithmic-based (though this is not guaranteed) and tends to be of a very theoretical nature. When answering a Technical Interview Question, there are two attributes you are trying to put on display:

1. Display a trained, repeatable and systematic process of solving technique questions of any form.
2. Display a favorable understanding of Software Engineering skills and techniques during the course of solving the question.

A lot of the time, even as an experienced Engineer, answering these questions are non-trivial and improperly leveraging the given information can lead to a ‘failing grade’ for the interview and cost you that job opportunity.

This framework is an attempt to simplify the collecting and leveraging of that information.

The framework has 4 main parts:

1. Ensure you understand the problem (Define the solution space)
2. Brainstorm solutions and select one (Navigate the solution space to find a solution)
3. Implement solution
4. Test your implementation

Ensure you understand the problem (Define the solution space)

This is probably the easiest thing to get wrong and doing so costs precious time which you may not be able to recover from. The framework’s primary purpose is to standardize the collection of information from the question so that you can make the best decision. At the end of this process, what is produced is a list of tests that both you and your interviewer can agree on.

The test cases themselves serve two crucial purposes. It validates to your interviewer that you understand what the problem requires but most importantly it helps reduce the solution space. The tests act like a border that helps define the solution space and so in essence, the problem now becomes writing a solution that solves all the test cases. While technically not true, this makes the mental gymnastics of solving the problem significantly easier to manage. Please note that it is recommended that the tests be physically written out to be able to refer to them later and so that your interviewer can see them.

This is the process I use to accomplish this goal:

1. Repeat the question aloud in your own words - This helps ensure you understand what the question is asking of you and communicates your understanding or misunderstanding to your interviewer.
2. Ask clarifying questions and check assumptions - This is where the bulk of the data-gathering happens and helps show you know how to reduce ambiguity in a given assignment. Here is some basic information to start gathering:
   • Clarify intended input
   • Clarify intended output
   • Ask about edge cases
   • Ask about performance constraints
   From these questions, other clarifying questions are likely to come up which will help flesh out your understanding of the problem. Please feel free to add other questions based on your own experience and knowledge.
3. Use real examples and validate your understanding - This is where the test cases are produced. For each clarification, you’ll likely be able to create a test case or integrate that case into another test case. The test cases do not need to be formal but need to be valid so they can effectively test your solution.

In the next article of this series, we will discuss using this information to brainstorm solutions.

Until then, have a good one!