What worked in my job search, round by round
How I prepared for each interview round as a senior engineer, what worked and what didn’t, and the resources I used.
I just started a new role at Annapurna Labs. Before this move, I interviewed outside for a while: about 25 to 30 applications, callbacks from about eight companies, and two offers. Then I decided to move internally instead. More on that at the end.
This post is the guide I’d give a friend who’s starting a search: each round, how I prepared for it, what worked and what didn’t, and the resources I used, so you can follow the same steps.
System design was the round I prepared for the most, and it was also the round I failed the most. I’ll get to why.
- Applied Roles I applied to 25–30
- Heard back About 3 in 10 applications 8
- Passed the phone round 6 of the 8 6
- Offers 2 of the 6 2
Applying for jobs
I applied three ways: to roles tagged security (my background from AWS Security Incident Response), through referrals, and at random. I expected referrals to give me the best chance of a callback. They didn’t. I heard back more often from the security roles, and that surprised me.
- Relevant role Tagged security, my background Best
- Referral Someone inside put my name forward Next
- Random Anything else that looked interesting Lowest
So the best bet is both together:
- Find the roles you’re relevant for Where your recent work is an obvious match (security, for me)
- Get a referral into those Relevance plus a referral gives you the best chance of a callback
Worth a look
- Tech Interview Handbook: resume guide Free, practical advice on a software engineer’s resume
- Levels.fyi Levels and pay by company, so you apply at the right level
Problem solving (data structures and algorithms)
My competitive programming background helped here. After a few days of solving problems I got the groove back, and soon I was solving hard ones again. This was my routine:
- Revise the concepts NeetCode, one pattern at a time
- Practice the company’s questions LeetCode, by company tag
- Move up to hard problems Once the groove is back
If competitive programming isn’t part of your background, give this round more time than I did.
What I used
Also worth a look
- Grind 75 Free plan you can fit to the weeks you have, by the author of Blind 75
- LeetCode Top Interview 150 Free study plan of classic interview questions
- Beyond Cracking the Coding Interview The 2025 sequel to the classic book, with free sample chapters
Behavioral
I spent some time writing down examples before my interviews, then practiced them. My prep was three steps:
- Write the stories down High-impact projects, challenging situations and conflicts, leadership moments
- Add what you learned For every story
- Run mock interviews I used Claude
The second step is the one I’d stress. It’s important to note what you learned for every example. Here’s a simple way to write each story:
| Part | What to write |
|---|---|
| What happened | The situation, and what you owned |
| What you did | The steps you took |
| The result | What changed, with numbers if you have them |
| What you learned | What you’d do again, or differently |
What I used
- My own story notes The three groups above, with what I learned from each
- Claude Mock interviews, to practice telling the stories
Also worth a look
- Tech Interview Handbook: behavioral guide Free, with common questions to write stories for
- Amazon’s Leadership Principles The themes Amazon asks about, and a good checklist for your stories
- Aced (formerly Exponent) Peer mock interviews with other candidates (Pramp is part of it now)
- interviewing.io Paid mock interviews with engineers from big tech companies
System design
I had never done a system design interview before, so this is where most of my preparation went.
- Learn the material Hello Interview, Alex Xu’s System Design Interview book, YouTube
- Practice every day One problem a day
- Research the company Before each round. This is the step I missed.
It was also the round I failed the most. Looking back, the main reason was my tech choices. When there were two good options, I’d pick the one the company didn’t use, or the interviewer wasn’t familiar with. Then I had to spend time explaining it to the interviewer, and that time came out of the deep dives. So for any choice that could go either way, here’s what I’d do now:
- Find out what they run Their engineering blog and job postings are good places to look
- Pick the one they use If A and B would both work and they use A, pick A
- Justify it properly Never just “because you use it.” Give the real reasons it fits; a smaller learning curve for their team is a good point too.
A few examples of what that research turns up:
| Company | Safe picks |
|---|---|
| Amazon, AWS | DynamoDB as the database, Kinesis for streaming |
| Meta | PostgreSQL |
| Airbnb | PostgreSQL |
| Kafka for streaming, which started at LinkedIn |
Meta and Airbnb both run MySQL in production, so MySQL is just as safe a pick there.
What I used
- Hello Interview Guides to the common problems and the building blocks behind them
- Alex Xu’s System Design Interview The book that walks through classic design problems step by step
- YouTube Walkthroughs of design problems
Also worth a look
- Designing Data-Intensive Applications The deeper book on how databases and distributed systems work; second edition, 2026
- The System Design Primer Free guide on GitHub, covering the core building blocks
- Engineering blogs, to research a company: Amazon Builders’ Library, Meta, LinkedIn, Airbnb
How it ended
I ended up with two offers. Then I decided to move internally to Annapurna Labs instead, to be closer to hardware. Now I work on inference for AWS’s AI chips.
If you’re searching right now, good luck. If you have any questions or need anything from me, connect with me on LinkedIn and send me a message there.