The 9-Round Interview
Eight interviews over ten weeks led to an offer with a ninth round still to come, and I decided to decline.
At least two years ago, before AI coding tools were part of my work, I interviewed at a large software company. Eight interviews stretched over about ten weeks. That was about eighteen hours of my time, and more than fifteen people on their side.
They made an offer, and then the recruiter told me there’d be a ninth round after I signed. It was a team-fit interview, before they’d put me on a team. The total compensation was good, but the base was below what I wanted then, and nine rounds was too much for this job, so I turned it down. By that point I was also having trouble imagining myself doing the work the process had led me to expect.
Signing unlocksRound 9: Team Fit
- DECLINE
- ACCEPT
The rounds
I don’t remember every minute, but this is close enough.
| Round | Time | What it was | What they wanted |
|---|---|---|---|
| Recruiter | 30 min | Recruiter screen. Talk through what I’d built. | Whether to send me on. Background, interest, logistics. |
| Karat | 1 hour | LeetCode-style coding challenges with a Karat interviewer. | Keep solving until time runs out. The interviewer didn’t work at the company. |
| Refactoring | 1 hour | Live refactor of a small piece of existing code. | Can you read someone else’s code and talk through a change. |
| Data structures | 1 hour | Whiteboard problems. | Fundamentals. Can you write a function with someone watching. |
| System design | 1 hour | Sketch a service and defend the choices. | How you think about architecture and tradeoffs. |
| Principles | 45 min | Behavioral interview they called principles. | Culture and conflict. Tell me about a time you disagreed with a manager. |
| Manager | 30 min | Manager conversation. | How I’d work on a team I wasn’t on yet. |
| Principles (again) | 45 min | Second behavioral. Added after round six came back mixed. | Another look at the same questions. Recruiter said they don’t normally do this. |
| Team fit | after signing | Would have been with the team I’d join. | Which team to put me on. I never did this one. |
The Karat round was an hour of LeetCode-style problems with someone who didn’t even work at the company. I finished the first one in ten or fifteen minutes and asked how many there were. He said they just keep going until the time runs out, so that’s what we did: another problem, then another, until the hour was up.
The first conversation that felt much like the job was system design. It gave me room to explain how I thought, instead of racing a timer or walking a linked list on a whiteboard.
Round eight only existed because round six came back mixed. The recruiter said, “we don’t normally do this,” and they added it, and after that they made the offer. I’d already done coding, design, a behavioral, and a manager conversation, and I still hadn’t met the people I’d actually work with.
What I took from it
I don’t know how that company shipped software. An interview isn’t enough to establish that. It does tell you something about how they reach a decision, though, and this one made me expect more coordination and less direct ownership than I wanted.
My concern was that I’d be joining a place where lots of people could stop a change and almost nobody could greenlight one. I could see a version of that in a loop this long, especially when mixed feedback meant another interview. That’s an inference from the process. I never worked there, so I can’t prove it.
They were testing real things. Coding and system design were a big part of it, not just whether I’d get along with people. I wasn’t objecting to being assessed. I was trying to decide whether I wanted the job the assessment seemed to describe.
Working inside a large, slow-moving team is a real kind of engineering work. It takes patience and a willingness to spend time getting people aligned. Someone else could have taken that offer and liked the job. I didn’t expect to.
Why I said no
At the time I wanted to own more of a product and move quickly on it, but I couldn’t yet see a viable version of owning a product myself. AI coding tools later made that feel possible for me. That’s a change in what I can take on, not a claim that nobody ran a product alone before.
I had less clarity about the alternative then, which is part of why I stayed in the process. I was considering the job seriously. Each conversation gave me something else to weigh.
By the offer, the compensation and the process were both reasons to walk. The base was below what I wanted, and I’d already spent about eighteen hours interviewing with another round still required. I didn’t need to decide that their way of working was wrong. I needed to decide whether I wanted to spend my days working that way, and I didn’t.
Now that I’m hiring
I hire people now, and looking back at this loop I still want a lot of the same signals. Can you do the work? Can you do system design? Do you understand data structures? Can you refactor code? Can you get through a code challenge? I’d like to know those things. The cost of finding them out this way is ridiculous, especially for the person trying to get the job.
The interviews alone add up to almost a full workday. Preparing takes way more than that, because doing the job doesn’t prepare you for a lot of these questions. You have to go grind code challenges, which is a separate activity from building software. If you’re already working, that time has to come from somewhere.
Karat was the first real technical screen, and it included the kind of problem where water fills up at the lowest point and you have to work out how much gets trapped. That’s an interesting brain teaser once. Doing another one, then another one, until the clock runs out is fucking ridiculous. Give someone a few options, let them pick one, and ask them to walk through how they’d solve it. Maybe write some pseudocode. You can talk about the data structures and what happens with different inputs without making them get every solution running until the hour dies.
There’s a signal in that exercise, but making it a timed endurance test mostly tells you who’s had the most time off to practice puzzles. That is not the same as knowing who can do the work.
As an experienced developer, I trust a conversation about something you’ve actually built much more. What did you try? What didn’t work? What choices did you have to defend once it was in production? Draw the system. Show me where the data goes and explain why you represented it that way. There’s room for system design and data structures in that conversation, attached to decisions you actually had to live with.
I wish hiring worked like a video game, where I could pull up a datasheet and read someone’s stats. It doesn’t. I still have to make a judgment, and adding another interview doesn’t get me out of that.
I also have to think about who will agree to the process. People looking for a startup, a small team, big problems, and end-to-end ownership aren’t generally looking for nine rounds of approval before they can start. Often the people who will put up with all of it are people who badly need any job. I stayed as long as I did because I was seriously considering this one. That doesn’t make the time cheap, or willingness to spend it a useful hiring signal.
I can’t tell you whether every change at that company got challenged until almost nothing got done. The interview process made me worry that I’d spend my days that way. If I want to hire people who take ownership and get things built, I don’t want my process giving them the same reason to leave.
This is Post 2.5 of the AI-Native Engineering Revolution series. Post 1: The Product Engineer. Post 2: The Collapsing Middle. Post 3 covers why large organizations struggle to adopt AI-native development.