Job hunt 4.0: five weeks of senior and staff interviews, and what I got wrong

In June, a crypto company pulled my offer at the last minute. Big oof! Things had been bad in the crypto world for a while, and from where I was sitting the crypto winter looked like it was here to stay. I had been at Uber for three years and had already resigned, so suddenly I had no next job lined up.

The first thing I wrote in my notes was that I’d been /r/woosh’d. The second was the actual decision: take some time, make sure the next place is a good organisation, and play a long game.

Then I did what I do with everything these days and made it a project in Obsidian, called “Job hunt 4.0”. I’ve been through this a few times, from zero campus placements to Adobe in 2014 to leaving Adobe without an offer in 2017, but never with this much paperwork. :’)

The first call was on 18 June, and by 22 July most of the rounds were done. So this post is the retro. But it really starts eight months earlier.

A warm-up in November 2021

Last November I went through loops at two companies, plus an exploratory call with a hiring manager at a third. It had been a while since I sat on this side of the table, and it showed. That month got its own note: one heading per company, one sub-heading per round, and a verdict and learnings written right after each round, while it still stung (or felt good).

There was a take-home first, a small HTTP storage service in Python with the standard library only. The second company’s behavioural and hiring manager rounds went really well, and I picked my examples from Shuttl, Synaptic and other places I’d worked. But most of what I learned came from one Wednesday, 17 November: low-level design at 10am and high-level design at noon for the first company, then a technical round for the second company at 3pm. Yep, three in one day.

A coding question I turned into a system

The low-level design prompt, generalised: records for different product features live in different datastores (MySQL, SQL Server, Mongo, Redshift and so on), and a module has to gather them and persist everything into one MySQL database.

In the hour I built a config map of connection strings, a Kafka message class, an ingestion worker, an if/elif chain to pick a connection per datastore and a FeatureMapper class with one private method per feature. The map() method, the one that was supposed to do the actual work, ends at a lone if. That’s where the hour ran out. Oops.

My verdict: “Went average at its best. I kept getting distracted towards outside problems. This was a pure coding question, I made it complex with random stuff.” The round wanted clean, working code for the mapping, and the mapping is the part I never wrote.

The design round that went well

An hour later: design the thing in a browser that warns you before you open a suspicious or malicious website. This one clicked! Here’s the board I drew in Excalidraw during the round:

The board from the November 2021 high-level design round, drawn in Excalidraw during the hour.

A SuspicionResolver on the client checks every URL against a small local LRU cache of hashes and either lets the request through or redirects to a safety page. A backend DB of known-bad URLs refreshes a distributed “global” list on every update, an async worker in the browser syncs the local cache from it, and a metrics worker sends hit counts back.

My verdict: “Went really well. The interviewer was really cool about a lot of ideas that I threw on him in a relatively small amount of time.” Even so, I wrote down two learnings: “Clear the scope well before jumping in the problem” and “Let the interviewer speak.” Both come from the habit the verdict describes. I fired a lot of ideas at him, when I should have asked more questions first and left him room to talk.

Islands, three days after I bookmarked them

At 3pm: some technical discussion, STAR behavioural questions, a deep dive into my projects, and the standard “count the islands in a grid” problem, with a twist where 0s count as part of an island if they’re surrounded by 1s.

Funny timing: three days earlier I had started a note with the Blind 75 list. Number of Islands is on it. Every checkbox in that note was still empty. Yeah. My verdict was “let’s say 90th percentile”, but I stumbled in the coding part.

What I took from it

A pure coding question wants working code first. Ask before you design, and let the interviewer talk. Code more, and a Blind 75 note with no ticks doesn’t count as practice. And Go: I’d written Go at work since joining Uber, but all the code for those loops was Python, so the note to myself said “get wildly comfortable with golang” and read gopl.io fully.

So when the crypto offer fell through in June, at least I knew where I was weak.

The setup

One note, one heading per company, and the status right in the heading: Offer, Offer Declined, Got Ghosted, Applied, Not interested. Under each heading, a table like this:

Discussion	Type	Notes
Recruiter	Intro call	link to the call note
Hiring manager	Behavioural	Strong Hire
Engineer	System design	Lean Hire
Engineer	Coding	Nope

Every call got its own note in my Zettelkasten, usually written right after I hung up: what the company does, how the loop works, what I was asked (in general terms here) and a self-assessment. The verdict column is my guess at the interviewer’s scorecard, in their vocabulary. Strong Hire, Lean Hire, Hire, and once, after a coding round, just “Nope”. 😅

Because the verdict went down before any feedback arrived, I could check my read of each round against what came back. And a couple of rounds I felt good about came back weaker than I’d guessed.

By the end the note had about 40 companies on it, and the Zettelkasten had picked up more than 40 notes in those five weeks.

How it went

Most companies never got past “Applied” or a first call. The rest:

• Eight full loops. Most ended in an offer, but two came back a level below the staff role I had interviewed for, and I said no to both.
• Three offers I turned down. Two were startups, and one would have meant moving to another country.
• Five applications I withdrew and marked “Not interested”.
• Two ghostings. One recruiter went quiet before a call was even set up. The other went quiet after I had shared time slots and sent a reminder.
• One rejection, after a first technical conversation I thought went great. I asked for feedback.
• One “not shortlisted”.
• One rescinded offer, which is where all of this started.

The roles were spread across Bengaluru, remote, Amsterdam, Singapore and North America, so for a while I was also weighing whether to move countries at all.

The prep

I wrote the prep up separately in Interview prep, senior edition, with the system design checklist, a backtracking template and the rubrics. The short version: the Blind 75 list again (the same note I’d started in November), Cracking the Coding Interview, company-tagged LeetCode questions, Grokking the System Design Interview, the System Design Primer and DDIA.

The recruiter prep calls were just as useful! Several recruiters walked me through how each round is graded, and two lines from those notes stuck:

• In coding rounds, efficacy is speed, accuracy and independence, and independence means not needing hints.
• In design rounds at this level, cover every component, then go deep on at least two.

The same mistake, eight months apart

Remember the November round where I turned a coding question into a system, and the “clear the scope” learning? In July 2022 a design round came back as a strong yes, with this as the growth area: “Could have made something smaller and simpler before growing!”

So I had the lesson written down and still made the same mistake. 🤦‍♂️ Next time: build the smallest thing that works, say out loud that it’s deliberately small, and grow it when the interviewer pushes.

What I got wrong

Static typing slowed me down

One loop had a 75 minute API implementation round: a class with a handful of methods, a written spec, and the expectation of a working solution by the end. My self-assessment says I designed the classes well, followed SOLID and optimised for runtime complexity. It also says I was slow, mostly because of static typing, and didn’t finish all the endpoints. I knew what to build. I just couldn’t type it out fast enough, and the note to myself was to practise more.

I shared more than my design

In one system design round my screen was being shared, and I opened LinkedIn and Obsidian. In front of the interviewer. Yup.

Since then I share a single window and close everything else before the call.

A shared doc is a bad whiteboard

Some companies run design rounds in a plain shared document, diagram included. About twelve days before one of those I had tweeted that Excalidraw is my go-to tool for anything whiteboarding, and it’s what I’d used for the November board above. In the round I got a word processor’s drawing tool instead. The whole learning section of my note on that round is: practise the drawing feature beforehand, because it’s terrible. (Two of the design problems from this hunt are written up here as generic problems.)

The failure question

In a behavioural round I got the classic “tell me about a failure” and it caught me off guard. The example I reached for was a bad one, and my self-assessment for that round says “Lean Hire?”. The fix is boring: walk in with one real failure story ready, including what I changed afterwards. That’s exactly what my STAR story bank is for.

The details I skipped

One low-level design round came back as a weak no, after I had put it down as somewhere between Lean and Strong Hire. The feedback was a list of things I hadn’t covered: dumping the logs, the ordering of writes, the order of reads and writes around a snapshot, checksums and race conditions. I didn’t raise any of them myself. At this level I think they want to hear those without having to ask.

Long answers

In a leadership round, the feedback was that my communication was strong, but my answers were long and turned into stories, and they wanted to ask more questions. Small, straightforward answers, and let them pull for more. Yes, it’s the November 2021 “let the interviewer speak” lesson again.

What went right

The take-home

The guidance was three to five hours and a few hundred lines, reviewed the way a real code review would be. I built all six features in Python. The feedback called out the README, the API and architecture design, the abstractions, the extensive test coverage and a “pleasant review exp”. 🙌 Treat a take-home like a pull request you want merged.

Walking through a project

Hiring manager and tech lead rounds kept coming back to a deep dive on one project. After one of the first calls I wrote down how I should tell it: PRD → ERD → milestones → agile sprints → testing → enhancements → release → iterate. The whole lifecycle gets airtime, and the architecture is just one stop on it.

Behavioural answers with a process

For questions like a low-confidence release or too many late-night meetings, I had process answers ready instead of stories, and the round where I used them came back well. They’re in the prep post too.

The questions I asked startups

Interviews go both ways, and for startups I had a short list of questions for the founders and VPs I spoke to:

• What’s the moat? What stops a big platform from building this as a feature?
• What are your plans for this year, and how do you plan to grow engineering?
• How’s the business? Revenue, and how much runway?

The answers went straight into the notes. One company had spent a long time growing organically from zero into a cash-positive business, which I wrote down as a good sign.

Highly paid at a small company, or on level at a big one

This was the real decision, and it’s a line from my notes on one of the startup offers:

being highly paid in a small company <<< being paid on level in a FAANG.

The pulled crypto offer is a big part of why I feel that way. A big number from a small company only holds while the funding holds, and this year the market turned. A role at the right level at a large, stable company is the long game I wrote about on day one, and that’s what I went with: I’ve accepted an offer from Atlassian! 🎉

If you’re in the middle of this right now: make it a project, write your verdict down before the feedback comes, and keep your answers short. Good luck!