We passed on a strong engineer last year because he finished too fast. He sent the take-home back in well under half the time we'd budgeted — clean tests, a sensible migration path, and a short README that explained which trade-offs he had made and why. One panelist wrote a single line on the scorecard: likely AI-assisted, cannot assess true ability. We thanked him and moved on.
A few weeks later he turned up on a client's platform team, where he rewrote their payment retry logic and cut a support queue that had been a running sore for two quarters. The engineer we did hire instead — hand-typed everything, no tooling, textbook answers — took the better part of a quarter to become genuinely useful on the same kind of work. That comparison sat badly with me for a long time. We hadn't measured his engineering at all. We'd measured his typing, and quietly filed it under character.
The day the take-home stopped telling us anything
Every hiring process rests on a hidden assumption. Ours was simple: the code a candidate hands back is evidence of the thinking that produced it. For twenty years that held. Writing code was slow, so slow code-writing revealed you — your habits, your blind spots, your patience.
That link snapped. Once an agent can produce a working implementation of a well-specified problem in minutes, the artifact stops being evidence of anything except access to the tool. And almost everyone has access now. According to InformationWeek's July 2026 report on the CIO problem that follows an AI coding rollout, 93% of developers use these tools, yet team-level productivity gains stall at roughly 10%. Sit with that gap for a second. Near-total adoption, modest output gain. The tools are everywhere and the returns are not.
That gap is a hiring signal, not a tooling failure. If 93% have the tool and only a handful convert it into real throughput, then the thing worth interviewing for is whatever separates those two groups. It isn't access. It's judgement.
Fundamentals or outcomes — which one should we actually hire for?
Hire for fundamentals, and test them through outcomes. The two are not opposing camps. Fundamentals are what let an engineer tell a good agent output from a plausible one, and outcomes are the only honest evidence that those fundamentals are real. An engineer who can recite the CAP theorem but ships a race condition has failed the test. So has one who ships fast and cannot say why the query got slow.
I've heard both camps argue this at conference dinners and in my own conference rooms, and both are half right in a way that makes the debate go in circles.
The fundamentals camp says: if you can't write a binary search on a whiteboard, you can't review what the machine wrote. The outcomes camp says: nobody writes binary search at work, the customer doesn't care how the code arrived, and a purist who takes a quarter to ship lost to a pragmatist who shipped in a week.
Here's what I've learned from being wrong on both sides. Fundamentals aren't valuable as recall. They're valuable as a detector. A person who understands indexes doesn't need to write one — they need to notice, in three seconds of reading a diff, that the agent added a query with no index behind it. That's not trivia. That's the thing standing between your team and a production incident at 2am.
| Fundamentals stopped being a writing skill. They became a reading skill. |
And the outcomes camp is right about something the purists keep dodging: an engineer who refuses the tools is now slower than the market, and slow is a real cost paid by real customers. The Guardian's July 2026 interactive on how software engineers are adapting to AI found people doing both things at once — going back to basics and chasing new skills. That's not a contradiction. That's the correct response.
The Direction, Judgement, Recovery test
Agentic engineering is the practice of getting software built by directing autonomous coding agents and taking full accountability for what they produce. That definition gives you three things to score, and I've come to think they're the only three that matter in an interview loop now.
Direction. Can the candidate turn a vague business problem into a specification precise enough that an agent produces something useful? This is the skill most people underrate. Watch what they do before the first prompt — do they ask about traffic, data volume, failure modes, the existing codebase's conventions? A weak candidate prompts immediately. A strong one asks two questions first.
Judgement. Given agent output, can they find what's wrong with it? Not style nits. The subtle things: the missing idempotency key, the retry that will hammer a struggling downstream, the migration that locks a table with forty million rows. This is where fundamentals show up, and there's no faking it.
Recovery. When the agent confidently goes down a bad path — and it will — how long before they notice, and what do they do? Do they keep re-prompting, or do they stop, read the code, and take the wheel? I've watched capable people burn most of a session re-prompting rather than spend ten minutes reading the file. Recovery is the single strongest predictor I've found of how someone will behave during an incident.
Notice there's a fourth row. Accountability isn't a skill, it's a stance, and it's the one I now weigh most heavily for senior hires. The engineer who says "the model generated it" has told you exactly how the postmortem will go.
Why is the gap widest at mid and senior levels?
The gap is widest at mid and senior levels because those engineers were hired, promoted and rewarded on a definition of seniority that agents have partly absorbed — deep command of one stack, fast recall, personal throughput. Juniors have no habits to unlearn and executives were never measured on output. The people in the middle built an identity on the exact skill that got cheaper.
I see three distinct behaviours in that band, and they don't correlate with talent at all.
The first group treats the agent as a faster autocomplete. They're productive, mildly. Their ceiling is their own typing speed, which is the ceiling they already had.
The second group hands over whole features and reviews lightly. Fast — until something ships that nobody in the room understands. These are the engineers who make a CTO nervous, and rightly.
The third group treats the agent like a very fast, very literal junior engineer who has never read the codebase's conventions. They spec tightly, review hard, and take the wheel early. That framing turns out to be closer to the truth than most people expect: a study from Peking University researchers, reported in August 2026, tested four frontier models on 106 issues across 49 repositories and found the agents rarely went and read the projects' own contribution guidelines before writing code. They don't ask. Somebody has to make them.
Here's the interesting part — seniority now cuts the other way in some markets. KQED reported in July 2026 that experienced engineers are finding an opening precisely because employers want people who can confidently direct the work, not just do it. Twenty years of pattern recognition became more valuable, not less. But only for the engineers who let go of the pride in typing it themselves.
| Don't ban the tools in your interview. A no-AI rule tests a workflow nobody uses after day one, and it filters hardest against the candidates who've adapted best. If you need to see unaided reasoning, ask them to explain a decision out loud instead. |
Should we change expectations, or change adoption?
Change adoption first, then change expectations — in that order, and never the reverse. An organisation that raises the bar before it has given engineers a real agentic workflow is just punishing people for a gap it created. Adoption is a management responsibility. Expectation is what you're allowed to set once you've met it.
I'll say plainly what I think a lot of leaders are getting wrong, and I'm willing to be wrong about it. Grading engineers on AI usage is a mistake. Business Insider reported in August 2026 that companies are now building AI skills into performance reviews. I understand the impulse. But measuring tool usage produces tool usage, and Goodhart's law hasn't been repealed. You'll get engineers running an agent on tasks that never needed one, so the dashboard looks right.
Measure the work instead. The New Stack made the same argument in August 2026 about the agents themselves in evaluating coding agents through executable contracts and scorecards — grade the output against a contract, not the process against a vibe. The logic transfers cleanly to people. Cycle time, defect escape rate, review depth, incident recovery. Those numbers move whether the code was typed or generated, and they're honest.
There's a structural risk underneath all of this that nobody has solved. Forbes reported in August 2026 that junior coding jobs keep vanishing while AI coding tools reach $60 billion valuations. If we stop hiring juniors, where do the seniors of 2032 come from? You cannot review code you were never taught to write. Peter Drucker's line applies: the greatest danger in times of turbulence is not the turbulence, it's acting with yesterday's logic.
So we kept hiring juniors in Ahmedabad, and we changed what their first year looks like. Less feature work, more reading. More reviewing agent output under supervision. Their apprenticeship is now in judgement rather than in typing, which is what the job will actually be.
Your next 90 days: a hiring plan you can start on Monday
Enough theory. Here's the sequence I'd run if I were rebuilding a loop from scratch.
- Week one — audit your own funnel. Pull the last twenty candidates you rejected. How many were rejected for something an agent now does? Every one of those is a signal your rubric has expired.
- Week two — pick the repository. Not a toy. A real service, ten to fifteen thousand lines, with the messiness intact. Strip the secrets, keep the history.
- Week three — write a deliberately ambiguous brief. Bury one contradiction in it. The candidates who surface it are the ones you want.
- Week four — seed three defects into an agent-written pull request. One cosmetic, one performance, one that loses data. Score which ones get caught, and in what order.
- Weeks five to eight — run it in parallel with your old loop. Don't cut over. Compare, on the same candidates, and see where the two disagree.
- Weeks nine to twelve — calibrate the panel. Have three interviewers score the same recorded session independently. If they disagree wildly, the rubric is the problem, not the interviewers.
And one thing to stop doing today: remove any line from your job descriptions that says "must be able to code without AI assistance." Ben Greene made a related point in his July 2026 InfoQ talk on the mindsets that matter when code isn't enough — code comprehension, attacking the hard problem first, staying close to customer impact. Those are the traits worth screening for. None of them are about who typed the characters.
Your challenge for the next twenty-four hours: open the last technical interview scorecard you filled in, and mark every criterion that a coding agent has made irrelevant. If more than a third of the sheet goes, you already know what your Monday morning is for.
Frequently asked questions
Should candidates be allowed to use AI coding agents in a technical interview?
Yes. Banning agents tests a workflow that ends on day one of the job, and it penalises the candidates who have adapted best. Let them use their own setup, then score the session rather than the finished code — the questions they asked, the defects they caught, and the moment they stopped trusting the output.
How do you test computer science fundamentals without whiteboard algorithms?
Hand the candidate a 300-line pull request written by an agent, with three defects seeded into it: one cosmetic, one performance, one that loses data. An engineer who understands indexes, locking and idempotency will find the serious ones fast. Recall is optional; recognition is not.
Why do mid-level and senior engineers struggle most with AI coding tools?
They were promoted on personal throughput and deep single-stack command — the exact abilities agents partly absorbed. Juniors have no habits to unlearn, and leaders were never scored on output. Engineers in the middle have to trade an identity built on writing code for one built on directing and reviewing it.
