The Big Tech Coding Interview Framework - Pt 1. Inspect

The 1st part in a 4 part series on how to approach every programming interview, regardless of the topic.

This is the first part of a four-part series. For those who want to jump ahead, here is a link to the entire framework

Inspect

For every single interview question, you should start with an inspection step. Spending 5 minutes here shows the interviewer that you critically think about problems before just diving in. It also buys you time to come up with a proper solution.

Each step in the inspect section has something that should be written on the board. Below we walk through each of the steps and provide an example.

Did I explicitly state what the input was?

What are the inputs to the function? How many are there? What are their types? What does each input represent?

Example

For a problem that has one arrary of string and one integer input:

 Input: n(arr<str>), k(int)

Did I clarify what the desired output was?

What is the expected output of the function? What is its type?

Example

For a problem that has a boolean as an output:

Output: bool

Did I construct a simple example that could be solved by hand?

Create a small and simple example of the problem and solve it by hand.

Example

For a problem that wanted to know whether any values in `n` appear more than `k` times:

Example:
input: n = ["a","b","a","c","a"], k = 2
output: true

Did I write out all Axioms?

Sometimes, there is critical information hiding in the constraints of the problem. Ask questions about the inputs, and their bounds.

Example:

Asking questions like: “Can strings be multi-character?” can provide you with critical information to the problem.

Axiom: Strings in the array cannot be multi-character

Did I write out and derive all intelligent assumptions?

Writing out your assumptions can help you keep your code cleaner. You can also use assumptions to narrow down the problem if you are stuck.

Example:

Its always good to make assumptions that your input variables will make sense

Assumption: k will always be a positive integer

Final

That’s it! At this point your creative juices will be flowing, you’ll have a high-level grasp on the problem and you’ll be able to identify any obvious gotchya’s! You are now ready to move on to creating an efficient strategy for solving the problem.

Remember, you should be writing this off to the side of the whiteboard.

Example output on the whiteboard

Input: n(arr<str>), k(int)
Output: bool

Example:
input: n = ["a","b","a","c","a"], k = 2
output: true

Axiom: Strings in the array cannot be multi-character
Assumption: k will always be a positive integer

(P.S feel free to use shorthand for the axioms and assumptions)

In Part 2, we will look at the hardest part of the interview, actually coming up with the strategy you will use to solve the problem.

Learn System Design

I’m actively tweeting about building LeetDesign, a massive list of interactive system design problems to help you learn system design faster.

If you are interested in the all of the lessons and wacky bugs I encounter building the product, give me a follow: https://twitter.com/DannyHabibs