Hackpack Blog

How to study

The Big Tech Coding Interview Framework - Pt 2. Strategy

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


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)


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


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


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


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


  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.


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.

Are you ready for your FAANG interview?

Find out if you are ready for your Big Tech interview after taking our free quiz!

Take the free quiz


Join the Community

Looking for a study partner? Hackpack is the most active community of engineers studying for programming interviews. We hold each other accountable, provide support, and fight burnout to study more efficiently and get the job faster.

Related questions