The purpose of this page is to help you be the best candidate you can be in an interview, based on the handful of times I’ve interviewed for a new role in tech. Possibly some of this is applicable to other industries.

The point is not to “game” the interview by knowing the right answers to every question - it’s more about making sure that interviewers can see your strongest skills, and get a sense of how you really are as a possible teammate.

General advice

Luck is involved, and you can try again

Interviewing is stressful, and it can feel very personal when you get rejected. Although we’d like to believe that interviewing and humans are completely objective and accurate, the reality is that neither are:

  • You could get that one coding question you don’t know very well.
  • For whatever reason, you might just not gel with your interviewer.

These things happen! It’s important to take it in stride:

  • Talk to the recruiter and see what you could have done differently.
  • Do some self reflection on where the issue was, and find resources to help.
  • See if it’s okay to try again at some point in the future.
  • Implement some changes based on the above.

And move on to the next job hunt. A rejection is painful, but getting terribly emotional on every failure will make the process all that more stressful.

Coding

Coding Interviews

Many companies do some form of data structures and algorithm interview.

I think a lot of people think this is just straight “leetcode” - solving the problem is all that matters, pass or fail. In my experience as an interviewer at Google and Zillow, it’s more than that. There are some companies that only care about whether you solve the puzzle, but in my experience that’s a minority.

Here’s my high level advice:

  • Listen to your interviewer! They are generally there to help you. If they’re giving you hints, don’t ignore them. Engage in the conversation at least.
  • Try to think out loud: it helps the interviewer understand you better.
    • Are there any tradeoffs to your approach?
  • Code like you’re coding for production, but quickly:
    • Use good variable naming.
    • Follow proper design (object-oriented programming as needed, pure functions as much as possible).
    • Include some light comments if the algorithm is complicated.
  • Test your code.
    • Walk through a couple test cases (one happy path and edge case as necessary).
  • Do practice leetcode! It’s helpful to practice in a time-constrained environment and re-familiarize yourself with the standard library of your language of choice.

I recommend leetcode medium, as well as running through cracking the coding interview.

Things that could help specifically:

  • remembering boilerplate code to avoid time spent not focusing on the specific algorithm challenge.

Using leetcode to practice

  1. read the problem statement. Consider edge cases before reading the examples.
  2. check the examples. See if you captured all of the edge cases.

Design Interviews

For design interviews, I recommend reading up on Grokking the system design interview.

Tips include:

  • Have a checklist memorized to run through the basics including:
    • verifying assumptions (usage patterns, load requirements, geolocation of users).
    • estimating capacity, regionalization requirements.
    • authoring a high level architecture diagram.
      • discuss the tradeoffs you’re making.
    • working through the end-to-end request workflow and clarifying missing details.

Try to deep dive on the areas you know well: the main goal of design interviews is to understand your expertise and experience in tackling these problems.

Engineering Management

For engineering management, think about and have examples for:

  • How to grow your team.
  • How to approach a larger difficult strategy problem.
    • breaking it down, identifying the problem (technical? organizational?)
  • How to measure impact.
  • How to address underperforming team members.

Behavioral Questions

  • Only use stories that you remember well and can speak to! Most interviewers will drill down into one of your stories, and you won’t know which.
  • Have 5-6 stories around your experiences in the STAR format.
  • Have some stories around projects that didn’t go as well as expected. Showing reflection and growth is important.