Succeeding at tech interviews: How I got offers from Citadel, Square, Amazon, and six other startups

Ever felt like this guy? Me too.

This three-step process will change your life!

Just know these three things:

1. Algorithm interview questions
2. Systems design
3. Behavioral questions

And have this:

4. Luck

I cannot stress enough how much of the process is luck, and at the end of the day, you’re playing a numbers game. However, focus on what you can control, and you may find yourself getting a bit luckier the more you prepare.

This is a “I don’t want your whole life story” post — I’m just going to share what resources I used and highlight important details. Sharing how long I spent on each of these parts probably isn’t helpful — we learn things at different rates, what comes easily for you might not have for me (and vice versa).

** None of these are affiliate links, just buy whatever you need and thank me by liking this post ;) **

Algorithm interview questions

1. Building Foundations

Do The Blind Curated 75 problems: https://leetcode.com/list/xoqag3yj/ When I say “Do” them, I suggest this process:

• Honestly attempt the problem for 20 minutes. If you’re stuck and have no idea how to do it, read the hints if there are any, or scan the discussion section of the problem to see what high-level approaches people are talking about.
• Understand where your failure to solve the problem came from: A) A lack of *foundational* material, e.g. you didn’t know what a breadth-first search was, or B) You missed a critical detail in the question. If A), be intellectually honest with yourself here — if you need to understand the concept, watch Youtube tutorials, read textbooks, do whatever you need to fill the gap. If B), take a deep breath and try not to make the same mistake again :)
• Speed is important too. Some companies (looking at you, Facebook) have an emphasis on solving problems correctly *and* quickly, but luckily they tend to draw from a smaller pool of questions, making it easier to prepare for.

Once you’ve finished those and want more practice, get Elements of Programming Interviews (they have language-specific versions) and work through them.

You’re looking to build pattern recognition. Leetcode does not test for raw intelligence — it tests for preparation. It is equivalent to studying for a test. Once you have mastery of the subjects and understand how to map problems to classes of solutions, you’ll be in good shape.

2. Company-specific preparation

Filter questions by company and do them. I did ~every tagged question for the companies I interviewed for.

This does require Leetcode premium. Unless you’re in a serious financial crunch, the $159 it’ll cost (at the time of writing) is pennies compared to how much you’re aiming to increase your compensation by, so I’d recommend getting it.

This doesn’t cover everything though. Citadel threw me curveballs and luckily I was able to wiggle my way through to a correct solution for the problems.

3. Programming “style”

Knowing how to solve the problem is necessary but not sufficient. I’ve also conducted > 200 technical interviews at my last company and rejected candidates who weren’t able to articulate their thought process. I use this process:

• Always start slow. Read through the problem carefully, even if you think you’ve seen it before.
• Explain the gist of the problem back to the interviewer — build trust and a pattern of feedback early. Ask questions. You want them to recognize your trait of being able to detect edge cases and ask thoughtful questions.
• Ask for a few moments to think of a solution.
• Usually a question has a brute force solution. Explain that first, e.g. “I see an easier way of doing this — I could just brute force this by doing X.” This is a crucial step because some companies don’t care about efficiency and just want a working solution.
• Normally though, the O(N²) approach won’t do though, so now you say something like “Okay, the other idea I have is to use a <data structure> to speed this up.” Describe your solution at a high-level and ask the interviewer if that seems reasonable — this is the most important step! Hopefully the interviewer gives you some feedback on whether this is the right path — if not, at least you’ve opened up room for a conversation to happen.
• Start coding. Narrate what you’re doing — think out loud!
• After you’re done, proactively run through test cases yourself. If none were provided, come up with your own — start with easier ones and then build edge cases on top of them.
• Ask the interviewer if they want to know the runtime and space complexity as well.

Square’s interview questions were more like pair programming, so being able to articulate what you’re thinking, where you’re stuck, or what you’ll be writing up next is *crucial.*

Systems design

System design primer. This is light and doesn’t go deep enough, but it’s meant to introduce you to the high-level concepts.

Designing Data Intensive Applications is your holy grail for information. Once you’ve identified knowledge gaps (see a theme?) dig into the relevant chapters and internalize the information here. Interviewers will often ask probing questions to see whether you really understand the concept or if you’re just reciting something from a blog post ;)

Company talks and blogs. For example, Netflix’s. If you want to understand how to design a system like Netflix or Instagram or Uber, why not go to the company blog itself? How impressive would it be if you could say to the interviewer, “Well, actually, I read Netflix’s engineering post about how to design a low-latency streaming service, and…”

There are plenty of frameworks on how to solve these questions effectively, but most importantly you want to clarify what the constraints of the problem are. How many users are there? Is this read or write heavy? How long of a time horizon are we designing for, e.g. is this going to grow significantly over the next five or ten years? At what rate? Again, you want to make this a conversation — be honest about what you do or don’t know, and always explain your thought process.

Behavioral questions

This is probably where a lot of candidates underinvest, so *please* make sure you prepare adequately for talking about your past work experience and future goals. Amazon in particular would ask a significant number of these questions, so I’d do the following to prepare:

• Identify a list of 3–5 projects that you made meaningful contributions to. Be prepared to talk about them in technical depth, e.g. one of my interviewers had be draw out the entire system architecture of what I was working on, how many users there were, peak QPS, how we identified and resolved failures. Focus on impact!
• Identify *leadership* moments in your jobs. You want to be able to identify particular initiatives that you led — were you able to work cross-functionally and bring alignment across multiple stakeholders? This is particularly important for senior+ roles.
• Some other common questions to prepare for include: What was your biggest takeaway from the project? What would you do differently if you could go back in time? Tell us about a time you disagreed with your manager (ideally you can come up with moments where both you and your manager were right in some ways and came to a compromise).
• Know the company. Why are you applying to them (even if just for the compensation, you need to sell that that’s not the case ;)). What are you looking for in your next role?

It’s important to be genuine in your answers here. Be humble, identify where you can improve, but also be confident in what *your* contributions were. Several managers will followup with explicitly what *your* part of the project was — be prepared for this.

Luck

I will die on this hill — technical interviews and your success rate is very much dependent on luck. Let me give you a few examples…

• On a technical screening, I struggled through two technical questions with five minutes to spare. The interviewer said there was one more question and asked if I wanted to see it — turns out it was a problem I had just done the previous day. I wrote up the solution in three minutes and I’m fairly confident that’s what got me to the onsite.
• For a final round, the interview involved sending HTTP requests to an API endpoint. I had just been working with a library to do this for the take-home project of a different company that ultimately ended up rejecting me. Had I not gone through that other company’s process, there’s no way I would’ve been able to pass this final round interview.
• Citadel asked me a question about IP addresses — I had to dig into my memories from college when I took a networking class. Had I not taken that class, I would’ve failed that question.

Sometimes you’ll get interviewers in bad moods and no matter what you try to do or say, they just won’t be on your side, and there’s nothing you can do about it. Sometimes you’ll get extra friendly interviewers who really want you to succeed — even if you have a mediocre performance, you’ll be moving onto the next round because you got along really well with them.

The most important thing is to just keep going. There’s always a light at the end of the tunnel. Even if you fail an interview for your dream company, ask what the cooldown period is and apply again.

That’s all for now. Let me know if you have anything you want me to dig deeper into :)

For more articles like this, follow me on Medium. Not a member yet? Join the community.
Want more software engineering interview guides and coding question tips? Check out all of my writing organized by topic in this article.

If you have any requests for what I should write, please let me know!