Stop Interviewing Engineers for the Part the Model Already Does

I have run somewhere north of two hundred engineering interviews. Scaling a team from 4 engineers to 31 means you spend a lot of your life in a room asking people to reverse a linked list. I got good at it. I also got good at ignoring the result, because after about the fortieth hire I noticed the coding screen had almost no correlation with who turned out to be worth their salary.

The ones who mattered were the ones who told me no.

Sean Goedecke wrote a piece last week called you have to beat the models at something, and it names the thing precisely. Models write competent code cheaply now. What they still fumble is deep context about your specific system, the discipline to pick the boring option, and the ability to explain a tradeoff to someone who doesn't write code. He's writing to engineers about how to stay employable. I want to flip it and write to you, because you're the one about to spend your largest line item hiring for the commoditized half.

What I actually do now, solo

Here's my current first-hand evidence, not a prediction.

I build MVPs by myself with these tools. Real ones, in production, for founders paying real money. Work that in 2019 would have needed two engineers and a quarter now takes me weeks. The code-writing part of my job has genuinely collapsed. I type an intent, I get a plausible implementation, I read it, I fix the two things that are wrong.

The part that did not collapse is deciding what goes in and what stays out. That's most of my day now. Which of your five features is load-bearing and which three are you asking for because a competitor has them. Whether this thing needs a queue or just a database column with a status field. Whether we're building auth or renting it. Whether the thing you called "simple reporting" is actually a data warehouse in a trench coat.

Models are cheerfully bad at that. Ask one to build a notification system and it will build you a notification system, with a worker pool, a retry policy, a template engine, and a provider abstraction layer. It will not say "you have 40 users, send the email from the request handler and revisit this in a year." It has no stake in your runway. It doesn't know you're pre-product-market-fit. It has read a million enterprise codebases and it will regress to the mean of them.

That mean will bankrupt a seed-stage company slowly, in maintenance cost, and you will not see it happening.

Your coding test measures the cheap half

So think about what you're doing when you screen your founding engineer with a take-home exercise.

You're asking a candidate to demonstrate the ability to produce working code from a specification. That is the exact capability that got cheap. You're paying a top-of-market salary and probably meaningful equity to secure a skill you could rent for a rounding error. Worse, you're selecting for the wrong trait, because the candidates who ace a clean, well-specified exercise are often the ones most comfortable in a world where somebody else decides what to build.

I'm not saying hire someone who can't code. Somebody has to read what the model produced and know it's wrong, and you can't fake that. But code fluency has moved from a differentiator to a floor. A twenty-minute conversation about a repo they actually shipped clears that floor. Stop spending your whole process there.

The durable skills, in the order I'd now weight them:

• Judgment about your system. Not systems in general. Yours, with your constraints, your users, your money.
• The discipline to choose the simple option when the complicated one is more fun to build.
• The ability to explain a tradeoff to you, a non-technical founder, in language that lets you actually make the call.

That third one is not a soft skill. It is the entire safety mechanism on your company. If your one technical person cannot explain to you why they want three weeks for something you thought was a two-day job, you have no way to govern your largest expense. You'll either rubber-stamp everything or fight everything, and both are fatal.

The interview I'd run instead

Stop asking "can you build this?" Ask "what would you refuse to build, and why?"

Concretely: send the candidate your actual product deck, your actual constraints, and your actual roadmap. Not a sanitized version. Runway, headcount, current user count, the feature list your board wants. Give them a day with it. Then spend an hour on three questions.

First: which three things on this roadmap would you cut or defer, and what happens if you're wrong? Listen for whether they cut anything at all. A candidate who agrees with your whole roadmap is either not paying attention or is afraid to disagree with you, and the second one is more dangerous.

Second: pick the feature you think we're most likely to overbuild. Describe the cheap version and the expensive version, and tell me what the cheap version costs us in six months. This is the tradeoff-communication test. If you cannot follow their answer, that is their failure, not yours. Say so out loud and see how they recover. The recovery is the signal.

Third: what would you need to see in the codebase in your first two weeks to change your mind about any of this? Good engineers have a plan for being wrong. Great ones tell you what evidence would move them.

Nobody writes a line of code in that hour, and you'll learn more than you would from four take-homes.

The uncomfortable part

If you run this interview honestly, some candidates will refuse to build the thing you're most excited about. Do not treat that as a red flag. That's the interview working. You're hiring a brake as much as an engine, because the model is already a very enthusiastic engine and it has no brake at all.

I've been on both sides of this. I've hired people who dazzled in a technical screen and then spent four months building infrastructure nobody asked for. And I now sit in the seat where a founder tells me what they want and my main value is telling them which forty percent of it to throw away. That job did not exist as a standalone role in 2019. It's most of the job in 2026.

If you're about to make this hire and you want a second opinion on the person before you sign, or you'd rather test the roadmap first and hire against a scoped plan, that's what the two-week sprint is for. Or just book thirty minutes and tell me what you're trying to build.

Hire for the no. The yes is already commoditized.