The Big Tech Coding Interview Framework - Pt 2. Strategy

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

(Here is a link to the first part)

Strategy

Now that you’ve inspected your problem, it’s time to start developing a strategy to actually solve it.

If you develop your strategy correctly, the coding portion of the interview will be very straightforward. This is the hardest part of your interview. If nail this portion, it should be smooth sailing until the end.

The goal of this section is to help you come up with a consistent way to solve complicated programming problems.

Unlike the previous section, not every section is meant to be written on the board unless specified with a code block. This section is where you really lean on your Datastrucures and Algorithm studying.

Note: Anytime I reference writing on the board, you should write that in a comment for a virtual interview

Did I brainstorm a Brute Force solution?

The first step is trying to figure out a way to technically solve the problem. If you can’t come up with any solution, even a slow one, you are in a bad spot. Most problems have a very slow, very aggressive solution that is obvious. You should explicitly state this solution, explain how it works, and dive into its runtime

Exceptions: There are plenty of exceptions to this where there is only one possible way to solve the problem. Graph traversal and Linked List problems tend to fall in this category

Did I analyze the runtime of my Brute Force solution?

Analyze the runtime of this Brute Force solution and write it on the board

Ex:

BF - Runtime: O(N^2)

Did I analyze the space requirement of my Brute Force solution?

Analyze the space complexity of this Brute Force solution and write it on the board

BF - Space: O(N)

Did I ask if the input problem set would be small enough for this to suffice?

At this point, you should ask the question: “Is the input set small enough for this solution, or should I work to optimize it?“.

Your interviewer will usually respond with, “lets try to optimize it” or you can do better, but sometimes they say, this approach works! If this solution is deemed to be good enough, skip to “Was I confident when I started coding”

Was I able to come up with a better more sophisticated solution?

This step is usually where you have to start getting creative and really leaning on your programming fundamentals, techniques, and practice problems.

My biggest tip here is to identify the runtime of your brute force and see if there is a way to improve it to the next level. During programming interviews, there are only a few different runtimes you will typically see:

In order of slowest to fastest(not an exhaustive list, just the most common):

n^n, n!, n^3,n^2, nlogn, n,logn,1

Take a look at the runtime and space complexities of your brute force solution, and try to move it one or two steps down the line. You can’t “Hack” this part, this is where all of your practice comes into play

Did I analyze the time complexity of this solution?

Analyze the runtime of this optimized solution and write it on the board

Ex:

Solution - Runtime: O(N^2)

Did I analyze the space complexity of this solution?

Analyze the space complexity of this optimized solution and write it on the board

Ex:

Solution - Space: O(1)

Did I compare it directly to my initial simple solution?

A quick reference back to how you improved the initial brute force solution is a good way to show your thinking. Even if you didn’t get the most optimal solution here, you still showed your thought process and were able to improve on a slow solution. This implies with more time, you would have improved your algorithm even further

Was I confident when I started coding?

Consider this step a gut check. You should know exactly what the code is going to be before you write a single line. Write out pseudo-code functions to explain the major steps of your algorithm and describe what you plan to do from start to finish.

Did I think through all approaches that come to mind?

When you state something out loud in front of an interviewer, you now need to either pursue it or discredit it, anything else makes it look like you don’t know how to invalidate certain approaches.

Did I explicitly write out my desired strategy?

I liked to write steps on the board

Ex.

1. Check the input for invalid values
2. Sort the array
3. conduct binary search to find the value
4. return true if the value is found

Did I explicitly consider base cases?

You should always consider what the base cases are, what happens when the values get really small, hit 0 or 1, or get really large. Sometimes your algorithm can’t handle a few specific values on the edges and you can write out simple conditionals that handle those base cases.

How well did I handle getting stuck?

When you got stuck, did you freeze up or did you start to get creative?

You never want to look like you got caught or don’t know what to do.

Final

That’s it! If you did this part of the interview correctly, you’ve gotten through the hardest part of the interview and now it should be smooth sailing from here on out.

Join the community

I run a private study group for engineers who are serious about getting jobs in Big Tech, apply here.

Need advice on how to break into Big Tech? Join the discord

Twitter: @dannyhabibs