Six Steps of Mental Framework to Nail A Coding Interview
By: Grace Huang
Tags: Interview Questions, Software Development, Coding, Interview, Software Engineering

Six Steps of Mental Framework to Nail A Coding Interview

Take A Breath. This Will Work.

Comic by Elijah Manor — “Technical Interview”

Now you have practiced hundreds of coding questions on HackerRank and LeetCode for weeks. When the interviewer finally reveals the coding problem, you are still feeling nervous. For a split second, you almost get lost and don’t know where to start. Suddenly you notice the 45-minute clock has been ticking, so your mind goes blank again.

I have been there, and I know that feeling.

Throughout my career, I have interviewed hundreds of software engineer candidates, when working for big tech companies and also hiring for my own company Roxy. I have found that stellar interview candidates have something in common — they have a consistent mental framework to solve problems within a limited amount of time. This mental framework can be reused almost for every coding problem.

In this article, I will walk you through these 6 steps of the mental framework. At each step, I will use this coding interview question “convert a number to English words”, to illustrate how to apply this framework during a coding interview.

Step 1. Write down the problem (1 minute)

Most of the time, interviewers just verbally describe the question, but you need to write it down. This helps you internalize what this problem is. At the same time, you can use it to “force” the interviewer to confirm your understanding. This is the power of writing.

If you are in a phone interview, you can type down the whole question on the online shared editor (such as CollabEdit). If you are doing it on the whiteboard, write it down on the board.

In case that what you’ve written down is different from what the interviewer wants you to do, they should let you know before your solution deviates too much from the problem.

Write a function to convert a given number to English words. For example, the input is 123, and the output is “one hundred twenty three”.

Step 2. Clarify the problem space (5 minutes)

It is very rare that the problem that the interviewer presents to you is complete. Yes, you read it right. Some edge cases may miss definitions. The scope of the problem may be much bigger than it sounds. The problem statement is often the bait in a trap.

Interviewers want to see whether you make assumptions easily, whether you can communicate the requirement gaps, and whether you make good judgment.

For example, for the number problem, here is a list of questions you can ask to clarify -

1.What is the range of the input number? 0? 1–999? 1–999,999?

2. Can the input be negative?

3. Can the input be fractional?

4. Does the output have dashes? e.g. “twenty-three”

5. Does the output have “and” between hundred and the rest? e.g. “one hundred and thirty one”

The interviewer has been waiting for your clarifying questions, so they will provide concrete answers, for example -

“the range will be 1 to 999”

“only positive whole number”

“No dashes”

“no ‘and’ word”

Unfortunately, 5 out of 10 candidates that I have met do not clarify problems and jump to code immediately. The final solution will definitely be affected. Even though the candidate later realizes the missing cases and try to patch them into the logic, the code may not look pretty or clean by then.

Step 3. Write down test cases (5 minutes)

Wait! We haven’t started coding yet. But, right, before writing a single line of code, you should list all the test cases, both common cases, and corner cases. Having test cases ready before coding actually paints a better picture than the actual product requirements about what you want to build. It materializes the problem space.

Here are all the possible types of test cases for the example question —

1…9 → one…nine

10…19 → ten…nineteen

20, 30,…90 → twenty, thirty,…ninety

21 → twenty one

100 → one hundred

101…109 → one hundred one…one hundred nine

110…119 → one hundred ten…one hundred nineteen

120 → one hundred twenty

123 → one hundred twenty three

200 → two hundred

999 → nine hundred ninety nine

First of all, from a number to words, you need a dictionary. From the test cases above, you can get an exhaustive list of unique words you will need for this dictionary. As you enumerate all the possible cases, your mind starts to pick up some patterns.

Many candidates don’t test at all. Many candidates test in the end. Many candidates only test the good cases. Only a few that I have met start with an exhaustive list of test cases before coding.

Step 4. Describe and write down the algorithm (15 minutes)

Some interviewers may ask you to elaborate on how you would solve the problem, or describe the algorithm before coding. Some may just watch how you will do — will you jump to code, or have a clear solution ready before coding?

From my observations of all the past candidates, the ones who jumped to code immediately likely either did not end up solving the problem in time, or had a working solution that was difficult to follow. Only the ones who had formed a clear idea before the implementation was able to solve the problem with precise and readable code.

Based on the test cases, craft a solution with appropriate data structures and algorithms.

You may notice that, in the example, before the number 20, all the words are unique words, such as “one”, “five”, “ten”, and “thirteen”. After 20, there is a pattern to combine unique words. Here is the 1st draft of my algorithm -

1. Create a dictionary for all the unique words (one … ten, eleven … nineteen, twenty, thirty, forty, … ninety)

2. Check the boundaries: <1 and > 999

3. Check simple unique words: <20

4. Check ones: if ones, look up the word in dictionary; otherwise, do nothing

5. Check tens: if tens, look up the word in dictionary; otherwise, do nothing

6. Check hundreds: if hundreds, look up the word in dictionary, plus “<space>hundred”; otherwise, do nothing

7. Put all the words together

All roads lead to Rome. Multiple ways solve one problem. I noticed that the solution above did not flow smoothly, because, in English, hundreds word comes first, then tens and ones. I immediately noticed that I need to do #6, then #5 and #4, as follows -

1. Create a dictionary for all the unique words (one … ten, eleven … nineteen, twenty, thirty, forty, … ninety)

2. Check the boundaries: <1 and > 999

3. Check simple unique words: <20

4. Check hundreds: if hundreds, look up the word in dictionary, plus “<space>hundred”; otherwise, do nothing

5. Check tens: if tens, look up the word in dictionary; otherwise, do nothing

6. Check ones: if ones, look up the word in dictionary; otherwise, do nothing

7. Put all the words together

Interestingly, a book about why stellar engineers (often Russian) on Wall Street are so good at problem-solving in interviews also mentions a similar process. However, it was the result of a unique history.

Russians had a reputation for being the best programmers on Wall Street, and Serge thought he knew why: They had been forced to learn to program computers without the luxury of endless computer time. Many years later, when he had plenty of computer time, Serge still wrote out new programs on paper before typing them into the machine. “In Russia, time on the computer was measured in minutes,” he said. “When you write a program, you are given a tiny time slot to make it work. Consequently we learned to write the code in ways that minimized the amount of debugging. And so you had to think about it a lot before you committed it to paper. . . . The ready availability of computer time creates this mode of working where you just have an idea and type it and maybe erase it ten times. Good Russian programmers, they tend to have had that one experience at some time in the past — the experience of limited access to computer time.” — Michael Lewis. Flash Boys: A Wall Street Revolt

Step 5. Start coding (5 minutes)

After you have done all the previous steps, the actual coding is the easiest part. Based on the algorithm you have come up with at Step 4, you turn it into code. It should not take much time at this point, and the code will be very easy to follow. Having a clear mind is also a confidence boost.

It took me 5 minutes to type all the code below and get it running.

Step 6. Test (5 minutes)

After you finish the code, it is time to test your code with the test cases you provided in Step 3.