Preparing for technical interviews

Introduction

I recently spent a little over 150 hours preparing as a candidate for technical interviews. This post contains everything that I learned during that time. If you're interested in watching the prep process, I streamed it live on Twitch; here are the unedited videos (there's no longer any Twitch chat shown 😢).

Given the length of this post, I suggest just skimming through the headers to see what's interesting to you. I intentionally don't cover everything, e.g. the structure of the interviews, how to negotiate your compensation, how to build good study habits, etc.

Big Tech jobs (AKA "FAANG" or "Big N companies")

"Big Tech" refers to companies like Apple and Google that are typically at the top of the earnings across all tech companies. These companies have very similar interview processes that can be broken down into three main categories:

1. Coding questions (e.g. algorithms and data structures)
2. System-design questions (e.g. "design the infrastructure for Twitter")
3. Behavioral questions (e.g. "what's a time you overcame difficulty working with someone?")

I am explicitly not advocating for every developer to set their sights on a Big Tech company; without going into detail, I'll just say that they're not for everyone. However, if you are looking to get hired at one of these companies or if a company that you're interested in uses the same interviewing process, then this blog post should be helpful for you.

Regarding the process itself: my opinion is that studying for this specific interview style won't necessarily make you better on the job. For example, just because you can crank out the answers to algorithm-based questions doesn't mean you'll write maintainable code. As a result, I think you should be careful about how much time you spend preparing, since if you don't get the job, it may not have helped you toward anything meaningful.

This is also why it's important to determine why you want to work for a Big Tech company. Whether or not there actually is a strong correlation between interview performance and job performance is something that I've been debating for a while. However, that conclusion doesn't matter for one simple fact: if you want to work for one of these companies, you have to follow their process!

The biggest motivator for me to spend so much time preparing was this document titled "Welcome to the Coding Interview. You Suck." (warning: NSFW language). It's a 61-page document that essentially boils down to this: you don't just have to be "good enough" to get a Big Tech job, you have to be better than the other candidates. As such, it means that you may have to put in more time than you think; as people become better candidates, the bar raises for everyone.

Moishe Lettvin did a talk called "What I Learned Doing 250 Interviews at Google". One key takeaway from that for me is that for any particular candidate, there exists a team of interviewers who will hire that candidate and an anti-team who would never hire that candidate. I agree with this concept. Some interviewers will help you fill in the blanks, and others may not develop a rapport or they may facilitate more miscommunications.

Along the lines of that "luck" factor, I only ended up interviewing with two Big Tech companies, and while I got both jobs, I want to mention survivorship bias in this blog post. I may just have had the perfect team of interviewers at both places. I may have effectively studied. I may not have needed to study at all. Who knows? Take my whole blog post with a grain of salt.

My own notes

I took a copious amount of notes during the last few months about all of these topics. Most are located in the "Misc" section, e.g.:

• Misc → Engineering interview prep
• Misc → System design
• Misc → Amazon leadership-principle stories v2
• Coding → Dynamic programming

(note: paths or titles of these notes may change)

Coding interviews (algorithms and data structures)

Just to be clear: coding questions are something along the lines of what you'd find on LeetCode or HackerRank, e.g. "write an algorithm to invert a binary tree".

Process

I think there are two general phases that happen while you're preparing for coding interviews:

1. You're learning for the first time that various algorithms or data structures even exist.
2. You've encountered enough breadth where there's very little new information.

Phase #1 is going to be pretty obvious while you're practicing. If you've never done a shortest-path algorithm in your life before, then it's somewhat unlikely that you're going to stumble on a good algorithm for it while practicing. For that reason, it's good to put a time limit on how long you attempt a problem on your own so that you don't end up having to reinvent the wheel while prepping. In general, I would try to continue for as long as I felt that I was making progress toward a solution.

In phase #2, the goal is to discover patterns and heuristics for coming to the right solutions faster or more accurately. For example, you may have a hint to do something in O(log(N)) time, which steers you toward a binary search or a tree-based solution. As much as you can, consciously identify these patterns and try to write them down (you'll find some in my notes).

It's easy to burn out if you're doing hours of coding prep every day, so try to mix it up a bit with other areas of practice: system design, behavioral questions, mock interviews, etc. Once you're in phase #2, you should be ready for mock interviews.

Tips

• Look at other people's solutions after attempting a problem (even if you solved the problem yourself). This is how you'll discover other techniques or approaches that could help you in the future.
• Try not to memorize code. Your goal should be to get to the point where you can reasonably come up with the code given enough direction. The closest I came to memorizing code was to remember how particular algorithms may be implemented. For example, for a binary search, you typically keep track of left and right values (or low and high); knowing that you need two variables is important, so that's something I tried to remember.
• While practicing, I found it helpful to write unit tests. I did this so frequently that I made a snippet for VSCode to essentially paste in the test function below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// This is the function you're tasked with writing:
function findLargestNumberInArray(numbers) {
  // your algo goes here, e.g. return Math.max(...numbers);
}

// This is a unit-test function that I would make:
function test(numbers, expectedOutput) {
  // It calls the function we have to write...
  const actual = findLargestNumberInArray(numbers);

  // It then checks if we got the expected output
  if (actual !== expectedOutput) {
    console.log('numbers: ' + JSON.stringify(numbers));
    console.log('actual: ' + JSON.stringify(actual));
    console.log('expectedOutput: ' + JSON.stringify(expectedOutput));
    assert(false);
  }
}

// Now you just have to write your test cases!
const assert = require('assert');
test([4,3,5,2], 5);
test([-100,10], 10);

• Avoid fixing symptoms. Picture this scenario: you start a problem, you come up with an algorithm, you code it, and then you find that you're getting an unexpected result. You modify some code and it works, but now another test case is failing. If you find this pattern happening to you frequently, then it's usually an indication that you messed up the algorithm and that you're trying to quickly fix it by just changing true → false or removing "+1" from something. When this happened to me, I tried to go back to the algorithm and run tests on my pseudo-code rather than my actual code, that way I could identify which equivalence class of test cases I wasn't covering.
• There's usually no need to write the bodies of "obvious" functions. For example, if your language doesn't have a built-in way to find the largest number in an array, then you can usually ask your interviewer "is it okay to assume that findMaxNumInArray exists and runs in O(N) time?"
• Different companies have different interviewing practices. For example, if you're coding online, you may not be allowed to use syntax highlighting. For that reason, you should practice in an environment that emulates the real interview as closely as possible (you can find out about the real interview by asking your recruiter).

System-design questions

System-design questions are something along the lines of "design a key-value store for a search engine"; they can span anything from infrastructure (e.g. "there's a load balancer in front of a web layer with an in-memory cache") down to the code itself ("there are these three APIs and customers will hit them 1000 times per second").

The answer to all system-design questions is "it depends". While this sounds a bit silly, it's an accurate view of the mindset you should have for system-design problems—there is almost never just one solution, so the process is all about weighing trade-offs.

A major component of system-design questions is prioritization. From what I've seen, the interviewer will usually steer you toward the high-priority part of the task, but it's of course better if you can identify it by yourself. You'll get better at finding this core by practicing, but don't be afraid to ask during the interview what they'd like you to focus on.

Something that was difficult for me to grasp at first was the fact that large systems are just sets of smaller systems, and you don't necessarily have to drill into the smaller systems. For example, in most web-facing systems, you'll have a load balancer. The load balancer itself isn't just one computer somewhere; it's usually at least two, that way you don't have a single point of failure. Once you have two, you likely need some replication between them. You may talk about whether whether one or both are handling traffic. All of those avenues can be explored if they are important enough to the problem or to the interviewer, but it's usually safe to just leave it as "load balancer" on your diagram. To be clear: my struggle was that I was trying to design all parts of a system when some of these would be their own entire system-design questions.

For more specifics, don't forget to check out my notes (in the "Misc" section); the ones I took on system design were quite helpful.

Behavioral questions

Behavioral questions are questions like "what's a time you had difficulty working with someone?" The most important part of these questions is figuring out the true intent of the question. In this particular case, answering the question literally would likely be a red flag; the interviewer doesn't want to hear you complain about a co-worker you had. Remember that the overall question that the company is always trying to answer is "should we hire this person?" Try to spin your experiences positively and focus on how you can provide value to the company.

What's difficult about these questions for me is just remembering what I even did in my last X years. To that end, I spent a bunch of time brainstorming important stories and seeing how they would correlate to common interview questions. I did this specifically for Amazon in my notes (see "Amazon leadership-principle stories v2" in the "Misc" section).

When you're actually in the interview, you'll find that you could use many of your stories for any particular question, but they'll rarely fit without modifications. I think it's okay to use something that mostly fits, but I've found that the story should be impactful on its own even if you need to add or remove minor details. For example, if your end result from some story is that you improved customer retention by 37%, then that will likely speak louder than the exact situation that you paint.

Interviewing the company

The interview time isn't just for the company to figure out if you're a good fit, it's also for you to figure out if you would like the company, team, and the job itself. In my notes under Misc → Engineering interview prep → Questions to ask a company, I have lists of questions that I found helpful. Some of my favorites are below:

• What's your [least] favorite thing about working here?
• How often do you work late or on weekends?
• Knowing what you know now, what are things you wish you knew before you started?

Résumé, cover letter, and portfolio

In my experience, all of these only exist to get you to the interview; they're not used very much during an interview.

Quick résumé tips:

• Don't undersell yourself, but also don't lie
• Be able to talk about everything that you wrote
• Keep it to 1 page unless you're very senior. I started cutting the size of the margins down if I felt that I wanted a couple more lines to fit.
• Make sure to run your résumé by other people; this is one of the most important parts since they will help you discover what stands out and what doesn't.

Regarding the portfolio, I think this is going to be largely ignored by big companies, but small companies seemed to appreciate it. For example, I made a quick video summing up my last 5 years and I was given incredibly positive feedback on this. My goal was to keep it as short as possible and really polish the presentation.

Mock interviews

To me, mock interviews are all about empowerment. If you do well, then you know that you're on-track for the real interview. If you don't do well, then you'll be given feedback specific to your situation that can help you learn! This is why it's important to do many mock interviews, because the people conducting them may not be experienced interviewers, so you'll want enough feedback so that you can see commonalities.

Even by simply being in the interview, you're likely doing something to address your anxiety since the environment mimics the real interview. It can also just be an opportunity to practice questions.

All in all, I think mock interviews are a great way to spend your time once you feel you have enough of the basics down. It can also be helpful to conduct mock interviews even if you're the one looking for a job so that you can see what it's like to be on the other side of interviewing.

I found my specific interviewers through word of mouth, but here are some resources that people suggested to me (which I've never used):

• https://www.pramp.com/
• https://interviewing.io/

Miscellaneous learnings

Follow your practice

Whatever you do while preparing should be the same process you do during the interview. During one mock interview, I skipped writing pseudo-code, but I'd never skipped that step before, so I felt lost during the rest of the problem.

Watching others

For me specifically, I don't think I benefited from watching other people doing their own interview prep, e.g. on YouTube. Instead, I was streaming the whole process and learning from my audience as I tackled problems. As a result, I asked them what they found helpful about watching.

In general, it was being able to see the real process and how I went through it, and also to get the resources that I was using. What I mean by the "real" process is that sometimes on YouTube, you see people explaining how they arrived at the correct solution. In my videos, I was tackling these problems from the point of view of someone who'd never seen them, so I sometimes wouldn't get the solution, but I still had my own thought process behind it. Also, broadcasting the mock interviews was helpful (you'll find those in this playlist).

Virtual interviews

I was looking for a job during COVID-19 times, so everything was virtual, which was a huge advantage since I tend to type what I'm saying aloud anyway. This made it way easier for interviewers to follow my thought process, and I didn't have to break my hand due to writing with a marker on a white board.

Frameworks

Come up with a framework for answering all types of questions. If you could only memorize 2-3 things, then your frameworks should be in that list! For example, here were my frameworks for answering technical questions:

• Coding question:
  • Understand the problem
  • Write an algorithm and test it (while it's just an algorithm)
  • Write pseudo-code and test it (while it's still pseudo-code)
  • Write code and test it
• System-design question:
  • Understand the problem
  • Identify the core of the problem (to make sure you're prioritizing the right thing)
  • Design at a high level
  • Design at a low level (prioritizing what's important)
  • Identify bottlenecks, single points of failure, and improvements that can be made

Tips during an interview

• Think aloud as much as possible. If you're stuck but you're not vocalizing anything, then the interviewer can't nudge you in the right direction or give you bonus points for exploring possibilities (even if they wouldn't have worked).
• Be positive and keep trying. I kept getting really dejected even while practicing when a solution wouldn't come to me quickly, but you have to try to fight that as much as possible. What I did to help the positivity was to tackle easier problems after failing to solve one. For example, if I was on LeetCode, I would revert from medium to easy so that I could feel good about myself.
• If the interview spans lunch, then don't do what I did and have a gigantic lunch. I felt sluggish in the afternoons and noticed that I wasn't thinking as clearly as I should have been.

Tips about nerves/anxiety

• Realize that the people interviewing you are just people. One of the Google prep videos that I watched mentioned that a good interview from their perspective will feel like it's just two engineers talking.
• Mock interviews should help greatly with this, especially if it's with strangers.
• Streaming is really good for this too if you've never streamed before (although I suppose that having an audience is what simulates the nerves of being in an interview).

Conclusion

My biggest learnings were as follows:

• I'm not sure that my coding prep was the best; I feel like it was the weakest part of my interviews even though I spent the longest on it (100+ hours). I don't know what exactly should have been improved though. Plus, I got the jobs in the end, so maybe I'm being too critical.
• The system-design prep that I did was the most insightful (and the most fun!). I spent about 40 hours on it.
• If I hadn't written down compelling stories about my own work experience, then I never would have had any answers for the behavioral questions. I spent about 10 hours compiling that list.
• The mock interviews I did were amazingly helpful. As I mentioned, they uncovered my own shortcomings and allowed me to focus on addressing those. For example, I worked "identify the core of the problem" directly into my system-design framework since I would sometimes keep talking about breadth instead of depth.

Be mindful about your own goals and make sure that a company with such a rigorous interview process would be worth it to you; there's no guarantee that you'd be happy at a Big Tech company even if you're making lots of money!