Originally posted on GitHub gist and sent privately to many friends, moved here on 04/13/2024. If you find this somehow and find it useful, please let me know! I was originally nervous about posting publicly because the tone is a little blithe, please remember I wrote this to send to friends originally.

Note: This was written in a particular context around interviewing in early 2022, contemporary job markets might not match these expectations

How much prep did you do for the technical interviews?

I get asked this a lot so I thought I’d write it up to share. For context, I was interviewing for staff+ individual contributor roles at tech companies.

Technical Interviews

I was preparing to do some amount of live coding interviews, and some amount of pairing interviews.

Tech setup check-in

My friend T offered to do a pairing interview with me, which I also used to check my Zoom / screenshare setup. I screen shared from my 2019 XPS 13 for the pairing, but also had Zoom on an ipad for video/audio. I used Airpods for audio. This setup actually worked great, but it was nice to dial in some of the specifics–mic feedback from dialing in from two places, and just practice my schpiel about explaining what I was doing to the other person. Probably not useful for you unless you too, have Linux problems.

Pairing interview practice

The pairing interview we did together was exploring some of the features of the frontend codebase of a company that he was contracting at. This was useful for me because I’m not a frontend dev by trade, so it forced me to “debug” certain behaviors in the console, check out the codebase together, etc. and ask some questions about how React worked–all true to life for both a real job and an interview. This actually ended up having resonances with a frontend debugging interview I did at a small company.

Live coding practice

For live coding, I have some baggage/trauma from never having (previously) passed an interview that included a live coding section, so I knew that I needed to practice to get my jitters out. I’d also been primarily coding in Typescript (at RC) and Hack (at Slack) for the last few years, so I had a question of what interview language to choose. I ruled out Hack/PHP as a lot of live coding websites don’t support Hack for syntax formatting and I’m not familiar with PHP7+ language features. I ruled out Typescript b/c TBH I don’t actually know it that well yet. So…I went back to something comfortable for myself and decided to do interviews in Go.

  • I did a few weeks of Advent of Code in December in Go, which was helpful to remind myself of “interview programming” constructs, you know, reading in from standard in and printing. I was also doing it for fun at the time.
  • I chose some number of problems from this Leetcode Cramming blogpost. I was aiming to do one / day for a week, I think I ended up doing all of the cram level 1 and one of the cram level 2. https://jeremyaguilon.me/blog/ranking_interview_questions_by_cram_score
  • I did Id allocator and Game of Life from here: https://github.com/insideofdrop/Dropbox-Interview-Prep . I intended to do token bucket and a graph traversal problem, but ran out of time. I intentionally chose these b/c I was targeting a few companies that had ex-Dropbox leadership so I knew they would have Dropbox-ish style interviews.
  • I had a copy of Elements of Programming Interviews already, so I wrote down all the chapter topics and identified which ones scared me. I used that to choose some of the leetcode problems from the above links. I never did get around to doing a graph traversal problem……..which I ended up seeing in a real interview, oops. It was also helpful to read some of this book just as a refresher around big O and how people talk about algorithms in interviews.
  • Note, I have a background in doing “competition programming” from undergrad, so a lot of this is actually fun for me, and I used to be very good at all of this, 14 years ago. A different type of refresher might make sense for you if you don’t have that background.
  • One of the three companies I ended up doing onsites at didn’t end up giving me any technical interviews–they do a homework for the technical component, and they skipped me through the homework b/c of open source code. I think the homework instead of technical interviews is pretty common at Series A/B companies these days.

Systems design interview practice

I basically didn’t do this at all, so don’t have recommendations, although if you feel nervous about this, I think prepping is a good idea, over half of my technical interviews were of this flavor. I did re-read some of the technical blog posts / book chapters I’ve written, so I could remember my own past history and lean on it.

Non-technical interview practice

I actually think this was the biggest payoff for me, in terms of return on time. I pulled some common situational questions from a blogpost and wrote out some stories from my experience so I could be crisp about them. I ended up actually only answering two questions, lol, but I used both of them frequently in interviewing!

  • Describe a decision you made that was unpopular and how you handled implement
  • Tell me about a time when you delegated a project to others effectively.

Most importantly, get really clear (max two sentences) about what you’re prioritizing in your next job. You’re going to end up saying it over and over again, trust me, you mgiht be bored of saying it but the person you’re talking to hasn’t heard you say it yet. Lara Hogan’s worksheet is a good resource here.