I Interviewed 200+ Engineers. Coding Challenges Are Still the Best Way to Hire.

I've done over 100 interviews at Google and over 100 at Autonoma building the founding team. I hired 6 engineers out of those 100+ at Autonoma. I consider myself one of the worst engineers on my own team, and I think that's one of the best things I've ever accomplished.

I want to talk about hiring from the perspective of a CTO, because there are a lot of things that look stupid from the candidate's side. Why do we ask LeetCode-style questions? Why do we give take-home assignments? What are we actually looking for in a cultural interview? I want to answer all of those, walk you through our exact process, and share the unexpected things I found along the way.

The biggest one: it's binary. There is an absurdly high correlation between the people who do well and the people who don't. There's almost no middle ground.

Everything I Learned NOT to Do at Google

Google's hiring process was garbage in many ways.

The screening was bad. Too many unqualified candidates made it through to the full interview loop. The interviews themselves were too hard for what the job actually was. You'd go through 2 months of background checks, 4 rounds of interviews, pre-screens, committees, and for what? To have that person write Python scripts for stupid migrations. Wasted potential.

The process was too pretentious. Google acted like they were selecting astronauts, and then they'd sit the astronauts in front of a spreadsheet. The bar was misaligned with the actual work.

There were two things Google did right, though. The "Googliness" evaluation, which was essentially a cultural fit check that actually worked. And the structured evaluation framework, how they scored and compared candidates consistently. We stole both of those.

When we started hiring at Autonoma, we said something like: "We need someone who can write code. We don't need a senior architect. Let's make a simple interview." Coming from Google, I had a ton of experience with overcomplicated hiring. We didn't want to be corpo. We didn't want a multi-week process. We just wanted to know if the person could think.

So we made it simple. One interview. A couple of coding questions and a product conversation. That was it.

It didn't stay that way.

The Process We Ended Up With (and Why)

We didn't plan to have a multi-step process. We were forced into it because we kept catching problems too late. Each step was added after we realized we needed it.

Step 1: Screening (added after we realized the first 5 minutes told us everything)

The technical interview was originally an hour. The problem was, within the first 5 minutes of the coding exercise, I could already tell whether the person was going to pass or not. For the bad candidates, we were losing the remaining 55 minutes every single time.

So we added a quick screening round: 3 simple questions, under 15 minutes. And I mean simple. Here's one of them, verbatim. "What is this function doing?"

def function(value: str) -> bool:
    if len(value) == 1 or len(value) == 0:
        return True
    if value[0] != value[-1]:
        return False

    return function(value[1:-1])

It's a recursive palindrome check. That's it. Can you read code and tell me what it does? The other two were the same level of difficulty: "what's the output of this function?" for a loop that sums rows in a matrix, and "what's the time and space complexity of this binary search?"

People still failed.

Step 2: Technical interview (the original step)

If you passed the screening, you moved on to the real coding problem. The probability of passing at this point was already high, because the screening was doing its job.

Step 3: Take-home (added on the recommendation of a senior colleague)

At first, we didn't see the point. A more senior colleague recommended it, and we trusted him. It turned out to be one of the most important filters. More on this later.

Step 4: Cultural interview (always existed, but became more deliberate)

Originally this was just a product conversation. Over time, it became its own step because we kept catching red flags here that the technical interviews missed entirely.

The Problem That Reveals Everything

Here's the coding challenge. You get a matrix of 1s and 0s. Find a path from the top-left corner to the bottom-right corner. You can only move down or right. You can only step on 1s.

That's the whole problem. When we designed it, we thought it was the easiest thing we could possibly ask. It turned out to be completely impossible for the average candidate. For the good ones, it was trivial.

The people who solve it well start by thinking. They say something like: "Okay, I could stand on the first spot and look at both directions. If I can go right, I go right. If I can go down, I go down. If I can't go either way, I backtrack." It's how you'd explain it to a 10-year-old. Then they realize recursion makes this clean, and they write it. 5 to 10 minutes, done.

I remember one candidate in particular. When we explained the problem, they just sat there for a moment with this look of "what's the catch?" There had to be something harder. There wasn't. The person was just very good.

Our first hire ever solved it in Excalidraw. Not even code. Pseudocode on a whiteboard tool. And it was perfectly clear and correct. He also showed up to the interview with a half-baked version of our product because he was so enthusiastic about the company. At that point, I was 90% sold and just hoping he'd ace the rest. He did.

The people who don't solve it? They all start the same way:

for () {
    for () {

    }
}

I almost always say something like "hey, this might be easier with recursion." They ignore it and keep going with the double for loop. I honestly don't know if there's even a reasonable way to solve this problem with nested loops. It's incredibly convoluted if it's possible at all.

They start there because every time they've seen a 2D array in their career, it was to print it or render it in a table. They never actually had to think about the data structure. They memorized a pattern and tried to paste it onto a problem it doesn't fit.

This is the thing people get wrong about coding challenges: it's not about the problem. The specific problem doesn't matter. What matters is whether the person has to think about it or whether they just know how to approach problems. The good engineers don't have to think about this the same way you don't have to think about how to use a microwave. It's not a challenge for them. It's trivially obvious. And for the people who can't do it, it's a mental puzzle they can't crack in an hour.

In the first 5 minutes, watching how someone approaches the problem, I can tell you if they'll be hired or not. It's that binary.

Why We Ask What We Ask

People love to complain about coding challenges. "This isn't real work." "I'll never use a graph traversal at my job." "Just look at my GitHub."

Here's the thing: every question in our interview is a component of our actual product.

Our product is an engine that navigates through mobile app hierarchies. It's basically a tree of elements that we parse spatially. The matrix problem? That IS our product, simplified. Our architecture question about designing a plugin system? That IS our product. We literally built a plugin system. The async queue question we sometimes ask? We don't build APIs. We build engines that do complex async work, sometimes with threads in other languages. We need people who can think at that level.

We're not asking trivia. We're asking "can you think about the kind of problems you'll actually face here?"

The Take-Home That Separates Builders from Shoppers

The task is simple: build and deploy a chat interface like ChatGPT with standard features. It's very easy. You could vibe-code it in a day.

This is where a huge portion of candidates who pass the technical interview drop off. And I believe the drop-off tells you everything. If the person's internal monologue is "they're trying to make me work for free without even hiring me," I don't want them on the team. I'm also investing time in you. I want to see that you have skin in the game. If you can't vibe-code a simple chat app because you don't care enough, this isn't the right fit.

The AI cheater. We had a candidate on the technical interview who was supposed to be solving the problem on a shared Google Doc. We don't care about running code. We care about how people think. We've had people pass with pseudocode. We've had people pass with Excalidraw drawings.

This guy joined the call, we explained the problem, and then he left the meeting. Came back with a complete solution pasted into the doc. Said something like "sorry, my internet cut out." We asked where the complete solution came from. His answer, as if we were born yesterday: "I scaffolded the problem with AI and then did the implementation."

I don't care what you can produce with AI. My mom can solve this problem with AI. I care about whether you can think as an individual. You'll have every AI tool available if you work for us. Right now I need to see YOUR brain.

I said something like "I think we should end the interview here." He went off. Started gaslighting us about how we're an AI company refusing to let people use AI. Missing the entire point with the confidence of someone who thinks they're the smartest person in the room.

The microservices guy. This one passed the technical interview with minor caveats. During the conversations, he mentioned multiple times how he loved building microfrontends, scalable architectures, and optimizing things. We were two people on the engineering team. There was not going to be any micro-anything. We were lucky to have CI/CD. We were upfront about this.

For the take-home, he asked if he could submit a project he'd built for another company's interview instead of doing ours. It wasn't ideal because we want a fair baseline, but we said fine. It was trash. A yellow UI that queried the GitHub API and showed your projects. That's it.

We wanted to give him a second chance. He'd said he loved building product, so we told him: show us that skill. Take this project and build something cool on top of it. He added a search bar.

When we told him we couldn't move forward, he said something like: "Maybe what you need is someone more of a vibe-coder, not someone like me who optimizes stuff."

My guy. You submitted a yellow GitHub browser with one search bar after being asked to show product skills. That's not optimizing. That's not building. That's just not caring.

The Cultural Interview (Where Corpo Engineers Go to Die)

The cultural interview is a conversation. We're looking for people who have grit and want to build something meaningful. We don't want corpo engineers.

We don't want people who want to build microservices. We don't want people obsessed with code quality more than product quality. We don't want people who think the customer is an idiot. We don't want people whose primary motivation is a higher salary. We don't want people who see this as just a job.

What we want is people who are obsessed with building an incredible product. People who code on weekends because they enjoy it, not because someone told them to. People who have side projects. People who try things out. People who get excited about solving problems.

I know this is a controversial stance. People will say it's a recipe for burnout, that it excludes great engineers with families, that it's unsustainable. I disagree.

I'm not in favor of crunch culture. I've done it and it absolutely causes burnout. I've lived through periods of not sleeping because of unrealistic timelines that we committed to clients, and it was either deliver or break the company. That causes burnout.

The burnout doesn't come from writing code. It comes from high stress and being unable to escape that situation. You don't burn out from eating, cooking, or walking. You don't burn out from a hobby. For the people I want, coding IS the hobby. I code personal projects on weekends. I work on my blog. I try things out. I might poke at a work problem because it's interesting, not because someone told me to. That's what I want. People who can't turn it off because they don't want to.

People confuse "coding on weekends" with "working on weekends." They're not the same thing.

What Great Looks Like

I'll leave you with this: our first hire came to the interview with a half-built version of our product. He didn't ask us what to prepare. He didn't study LeetCode. He went to our website, tried the product, got excited, and started building something similar because he wanted to understand how it worked. He solved the coding problem in Excalidraw because the thinking was more important than the syntax. He was genuine and curious and hungry.

That's the bar. And from the other side, if I can give candidates one piece of advice: try to work for someone you genuinely want to work for. Don't optimize for the biggest company or the highest salary. Work for people doing something that excites you, and let that excitement show. It's obvious when someone cares. It's even more obvious when they don't.

And for the love of god, don't try to work at Google. It's a waste of time and you'll learn nothing other than politics. Trust me on that one.

If you have thoughts on this, find me on Twitter.