The Machine Runs, the Driver Decides: How I'd Hire Engineers Now

By Sam Wen, CEO & Founder of XInfer.AI — August 1, 2026

I hired engineers for twenty-one years around a single question. It is now the wrong question, and the interview I'd run tomorrow doesn't contain it.

From 1998 to 2019 I was co-founder and CTO of Seawolf Technologies, running a distributed team of 20 to 30 developers across the United States and China. I hired most of them.

Every one of those interviews reduced to the same question, however I dressed it up: can you write good code?

Sometimes it was a whiteboard. Sometimes a take-home. Sometimes a hard problem and a request to think out loud while typing. The form changed a dozen times over twenty-one years. The question never changed once.

I would not ask it today. Not as the main question, and probably not at all.

What I was already overriding

I should be honest about something: I knew that question was a poor instrument long before any of this.

Twenty-one years of interviews taught me the coding exercise had a false-negative problem I could never fix. Good people froze at a whiteboard. People who could recite an algorithm cleanly turned out to need a year of supervision. More than once I hired someone the exercise said no to, and I was right often enough to keep doing it, and uncomfortable enough about it to know I was working around my own test rather than improving it.

I never had a name for what I was overriding it with. I do now, and it's why I'm writing this.

What I was reading was how someone reasons about a system they don't yet understand — whether they check or assume. That was always the thing worth hiring for. The coding test was a proxy for it, and a decent one, because writing code and understanding a system used to be the same activity.

They aren't the same activity anymore. The tool didn't break my interview. It removed the proxy and left the real thing standing there by itself.

What happened at my desk

In October 2025 I started building XInfer's agent platform. Nine months later the repository holds 2,323 commits across 253 active days, 1,291 merged pull requests, about 458,000 lines of source, and 3,513 tests. One product on four channels, multi-tenant, with billing and a Shopify app.

And two mobile apps that passed App Store and Play Store review. I put that last because it is the only item in the list somebody other than me had to approve.

The platform is running at xinfer.ai — the channels, the billing, the storefront agent, all of it live. The repository numbers you have to take from me. The product you can go and use.

Every number about the platform in this essay is frozen at 27 July 2026, the end of those nine months, and the line count excludes generated clients, lockfiles and vendored code. I'm saying so because a figure you can't recount isn't evidence, it's decoration.

I built it alone, and I typed almost none of it. I've edited code by hand a handful of times. I don't read most of what gets written. I could not recite the tenant-isolation guard from memory.

What I wrote were the requirements. Tests first is a requirement. Tenants must never cross is a requirement. Knowledge comes only through retrieval is a requirement. The gates exist because I insisted the system be unable to ship without them.

I measured what that bought and published the arithmetic separately — about five and a half times the code output per working day against the same kind of product I built in 2024, and about forty-seven times per calendar day. The counting rules, and every reason to doubt them, are in The Model Codes, the Gates Decide.

What needs no arithmetic is this. I have never shipped anything close to this in my career, and I did it without writing the code.

And here is what that means for hiring:

The person I became over those nine months would have failed the interview I used to run.

I'm slower at a whiteboard than I was in 2015. I've forgotten API signatures I once knew cold. Hand me a blank editor and a timer and I'll turn in mediocre work.

If my own interview would reject the most productive version of me I've ever been, the interview is broken. Not my standards — the instrument.

The runner and the car

We used to hire runners. Speed, endurance, form. The best runner covered the most ground, and covering ground was the job.

Then someone handed everyone a car.

The obvious mistake is to keep running the same tryouts and hire the fastest sprinter. The subtler one is to assume the car makes the job easier and the bar lower. It doesn't. It makes the job different, and the failure modes worse. A runner who trips scrapes a knee. A driver who's wrong is wrong at seventy miles an hour — a wrong choice now arrives fully implemented before you finish doubting it. On day two of this project I adopted an ORM. On day fourteen I ripped it out. The speed was the reason for both.

So: not a lower bar. A different one, tested at the speed the work runs at. Airlines don't evaluate pilots by making them flap their arms. They put them in a simulator and break things, because the skill under test is judgment while the machine does the flying.

What happened to running

The analogy has a second half, and it's the part I actually want to say.

Running didn't die when the car arrived. Far more people run now than when running was how you got somewhere. Global road-running finishers were up 17 percent year over year in 2024 — 4.67 million across 600 established races in 44 countries.

What ended was running as logistics. Nobody moves freight on foot, and nobody mourns that. Running became something people do on purpose, and it has never been healthier.

Chess makes the same point where it's harder to wave away, because chess is thinking rather than running. Deep Blue beat Kasparov in 1997, and that was supposed to be the end of it. Twenty-nine years later, FIDE's rating list carries more than 560,000 players with a standard rating — I downloaded the August 2026 list and counted. The engine didn't kill the game; it became the training partner. But notice what nobody does: hire a grandmaster to compute a position.

So, stated plainly enough that it can't be softened into nothing:

Typing code isn't dying. It's being reclassified — from how the work gets done to something people do on purpose, because it's satisfying. Hand-built software will be a craft, with its own pride and its own devotees, the way letterpress printing and hand-planed furniture are crafts. Good ones. Worth doing. Just not how the freight moves.

I don't think that lands everywhere in five years. I think it has already happened in a few places, mine among them, and it spreads the way these things always spread: unevenly, then suddenly, then it's just how it's done.

The half nobody says out loud

There's a second obsolescence in that sentence, and it gets less attention because it sounds like a virtue: reviewing code by reading it.

A model writes code more than ten times faster than I can read it. If every line has to pass my eyes before it ships, I've taken a tool that removed a bottleneck and carefully installed myself as the new one. Reading the diff doesn't make the work safe. It makes it slow, and then it makes it sloppy, because nobody reads the thirty-third diff of the week with the attention they gave the first. Thirty-three a week is what my repository actually runs at.

Asking is O(1). Reading is O(n). Only one of those survives the volume.

So I don't read the code. I ask about it and cross-examine the answers: what happens if the call drops mid-checkout, which paths can touch the ledger, what does this do when the tenant is missing. A question costs me one sentence. Reading costs me an hour and finds less.

Then I check whether the running system agrees. I place the order. I start the call. I break the checkout. I read the logs.

What the old interview measures now

Once you accept that, the standard interview stops being merely old-fashioned and becomes actively misleading.

The take-home now measures the model, not the candidate. A four-hour exercise takes three minutes. Every submission comes back clean, idiomatic, and tested. You cannot tell the strongest candidate from the weakest, because you're grading the same tool five times.

The whiteboard tests recall that stopped being scarce. Memorized API surface is the barefoot part of the runner.

And the ban is worse than either. Plenty of companies now tell candidates not to use AI during the interview. I understand the instinct and I think it's exactly backwards. If the tool is how the work is done, the tool belongs in the test.

Using AI in my interview isn't cheating. Refusing to is failing the exam.

And here is what I won't test at all: memorized syntax, algorithms from scratch, typing speed. Anything that measures how you'd do with the tool taken away, which is a condition that will not occur.

The interview I'd run

None of what follows is a new idea, and I want to be plain about that. Andrej Karpathy made the same argument in the spring of 2026: that coding puzzles no longer measure anything, and that the way to evaluate an engineer now is to hand them a real project and an agent and watch what they do with it. He got there by thinking about where the field is going. I got there by shipping a product for nine months and keeping the logs. Same conclusion, two routes, and the second one is the only one I can offer — which is worth more to me than being first would have been.

Which makes it worth saying where we part, so that nobody reads him as endorsing me. He lists inspecting diffs among the things a human still does; I've stopped, because at thirty-three merged pull requests a week a question costs a sentence and reading costs an hour. He thinks the models' weakness at simplification is temporary — he hopes it improves, and puts it down to the labs not having trained for it yet. If he's right, then taste about structure — whether two similar functions are the same idea or two ideas that happen to rhyme — is an advantage on a clock. And he thinks the old ten-times-engineer number is now far too small, where I measured five and a half on code output and forty-seven on the calendar, and published the arithmetic for both.

What follows is one way to run this, not the way, and the mechanics are the least durable part of it. Four things underneath are what I'd actually defend:

• The tool is in the room, because it's in the room on the job.
• The work is real. A puzzle grades the model. A posted issue in a codebase nobody has memorized grades the person.
• Nothing is taken on trust, including what I tell them. The wrong diagnosis is mine. The green checkmark is one I handed them.
• The process is the artifact, not the output. The diff is the model's work. The transcript is theirs.

Everything below is one way of making those four concrete. Someone whose version gets at them differently has a better interview than mine, because theirs fits their codebase.

Two screens, then.

Screen one: thirty minutes, no computer. What must never happen?

I describe a feature. Multi-tenant, takes payment, talks to a customer. Then: tell me what must never be true of this system, and how you'd make it impossible rather than merely unlikely.

Tenants must never cross. The customer must never be charged twice. The agent must never state a fact that didn't come from retrieval.

Only the first of those became a build gate: a 226-line guard that scans every raw SQL query for a missing tenant predicate and fails the build rather than filing a warning. The second is enforced by idempotency tests, which is weaker — a test proves the case you thought of. The third is enforced by a judge that runs in development, point in time, which is weaker still. I'm spelling out the difference because the gap between an invariant you can state and an invariant the build can prove is the whole of this job, and I have three sentences and one gate.

That's the requirements muscle, and it's the part of my job that grew rather than shrank. It needs no repository and no tooling, which is why it goes first, and half an hour is enough to find out whether someone thinks in invariants.

Screen two: two hours, a repository, and the tool.

A codebase, an agent, and a piece of real work — built, running, and ready to touch before they sit down. Setting it up from scratch sounds like part of the test and isn't: what goes wrong is a toolchain download or a stale lockfile, variance that measures nothing about the person.

So it opens on verification instead. Here it is, running. Before you change anything: run the suite, and make it do one real thing in front of you. Someone who says "looks fine" and starts typing has just trusted a green checkmark I handed them.

The work is a well-known open-source project — Redis, SQLite, something with real decisions in it and far too much code to bluff — and a task that already exists: a small feature, or an issue somebody actually posted and left open. Or I hand them a repository I've prepared, carrying two traps drawn from my own logs.

The first trap is a wrong diagnosis, and it's mine. On 29 July I reported a bug like this: "I re-crawled the website with the new blog and the AI responses didn't seem to know it." Embedded in that sentence is a confident cause — the crawl failed. Reasonable, and wrong. The blog was in the knowledge base, ranked first for every query; the agent simply never called search. Asked directly, it said "I don't have access to our blog articles" rather than "I didn't look." Accept my diagnosis and you spend the session inspecting a crawler that works fine. The reported symptom is data, not a diagnosis — including when it comes from the person who built the system.

The second is a green lie. Somewhere in the exercise sits code that is wrong and a test that agrees with it. The same system writes both, so a misunderstanding doesn't produce a failing test — it produces a wrong implementation and a test that confirms it, both green. Does the candidate trust the checkmark, or go run the thing and watch it behave?

How hard that is to catch is a dial, and I'd set it low. Leave a visible symptom — something that misbehaves the moment you use it — and anyone who actually runs the thing finds it. Take the symptom away and only someone who distrusts a passing test on principle will. The trap exists to separate the people who check from the people who don't, not to defeat everybody.

It closes on questions, tool still open. I'm not testing whether they know the project — nobody does. I'm testing how they come to know one, which is the job. You will spend your career in code you did not write. Where does a request actually get decided here? What is this design protecting, and what would break if it stopped? Which part would you be afraid to change, and why that part?

Two hours is enough to tell two people apart. The one who spent them reading files gives me a summary. The one who spent them asking questions has found the load-bearing wall.

I grade the transcript, not the diff

Screen two produces two artifacts: a diff and a session log. The diff is the least interesting thing in the room — whatever they produced, the model produced, and it will look fine.

The transcript is the code sample.

I say that with some confidence because I have twenty-three thousand prompts from one project to read against, and every row below is a habit I can measure in my own log.

One failed fix is normal. Two means the model is guessing, and a third guess costs the same as the first two and works no better. The candidate who notices and changes what kind of work is happening — go find who hit this first, it's in a GitHub issue somewhere — is showing the single most valuable reflex I know of in this way of working. It is invisible in a diff and unmistakable in a log.

None of these are criteria I invented. Each is a habit I got wrong first and then noticed in my own log — so I'm not asking anyone to arrive with them, only whether they'd end up finding them. And six rows is not the list; it's what one person could see, on one product, working one way.

Some of what matters leaves no trace at all. The decision not to build something. The conversation where somebody talks the team out of a bad idea. The restraint to stop at good enough. None of it reaches a prompt log, and a rubric built from logs will quietly undervalue every bit of it.

So don't take my six. Go read your own log and generalize your own — the same skill the table is trying to detect.

One trip is not a route

I drove it once.

Nine months, one product, one person, and everything above is that single trip. It proves the car can make the distance. It does not hand anyone a route — no fuel stops, no schedule, no list of what breaks on the way. That is the difference between a feat and a method, and only one of the two is worth writing down. What I want is for this to stop being art and become an engineering problem: specified, repeatable, and wrong in ways you can point at.

The history says that takes a while. When electric motors arrived, factories did not get faster. They had been built around a single steam engine turning a central shaft, with belts running off it to every machine, and dropping an electric motor into that building bought almost nothing. The gain came only when factories were rebuilt around distributed motors — new layouts, new buildings, new ways of organizing the work. Something like four decades passed between the dynamo being available and the productivity showing up. Cars, likewise, arrived decades ahead of the paving and the signage and the highway system that made them worth having.

Which is also why the studies finding these tools make developers slower don't trouble me much. They measure experienced people inside codebases they have known for years, where the tool cannot give you what you already have. That is the opposite of my case. It is what produced my numbers, and it is what limits them.

But I have to be careful here, because the gains will come once we build the rest of it is exactly what gets said about technologies that never deliver. So, specifically. The complements for this way of working have all been named since mid-2025: context engineering, specs as the unit of work, evaluation harnesses standing in for test suites. I've built versions of most of them — the gates, the judge, the specs, the guard that fails the build. None of them has been tested on people. No study has put a team on any of these and measured what shipped. The catalogue is a specification, not a result. Mine included.

What would change my mind is a second trip, and not mine. Someone else's product, the practices written down beforehand, the same records kept. If that comes back at ordinary speed, then what I measured was me, or the year, or luck — and not a method. I'd rather find that out than not ask, which is the disposition the whole interview above is trying to hire for.

The freight and the runners

The runners didn't disappear when the car arrived. They stopped carrying the freight, and running got better for it.

Hand-written code is on the same path, and the interview I ran for twenty-one years is now a tryout for a sport rather than a job. It selects beautifully for someone who can cover ground on foot. I need someone who can drive.

The essays on this site each reduce to one sentence. The checkout: the LLM narrates, the core decides. The judge: the model writes, the judge measures. The certification: the factory builds, the evidence admits. My own desk: the model codes, the gates decide.

This one is about who I'd put in the chair: the machine runs, the driver decides.

I'd still want a runner's eyes. I'd just stop timing the sprint.

Sources for the participation figures: Road Race Management, global road running finishers up 17% in 2024. The chess figure is counted, not quoted: FIDE's combined players list, downloaded from ratings.fide.com on 1 August 2026, holds 563,024 players with a standard rating and 779,054 with a rating of any kind. Project figures come from the git log, prompt log, and test runs of the XInfer agent platform, and are documented in The Model Codes, the Gates Decide.

The randomized trial is METR, "Measuring the impact of early-2025 AI on experienced open-source developer productivity"; its February 2026 follow-up, with agentic tools and a larger sample, measured a speedup instead, with confidence intervals crossing zero and heavy task self-selection. The sign of this effect is not settled, and I am citing the study that measured against me as well as the one that didn't. The factory-electrification account is Paul David, "The Dynamo and the Computer" (1990). Counting rules for my own figures: the line count excludes generated clients, lockfiles and vendored code; the velocity ratio uses GitHub's language-byte count on both repositories, so it is unaffected by where that line is drawn.