Hiring for the ADLC, and what to screen for now
Technical interviewing was calibrated to predict who could produce correct code under time pressure. That signal is now cheap to fake and less predictive of the job, and almost nobody has rewritten the loop.
The technical interview has been criticised continuously for fifteen years and has barely changed, which tells you something about how hard it is to replace. Whatever its faults, the standard loop did one thing reliably: it filtered out people who could not program. That filter had real value, because a meaningful fraction of applicants could not, and because the ability to produce correct code was closely related to the job.
Both halves of that have weakened. The signal is now trivially obtainable with assistance, and the underlying ability, while still necessary, is a smaller share of what determines whether someone is good at the work.
This is not an argument that programming ability stopped mattering. It is an argument that we were measuring a proxy, the proxy has broken, and the thing it was a proxy for needs measuring directly.
What the loop was actually measuring
The standard interview measured code production under observation. In doing so it correlated with several things at once, and the correlations were the point rather than the measurement itself.
It correlated with having internalised the fundamentals well enough to use them without reference. It correlated with being able to decompose a problem. It correlated with communicating while thinking. And, less admirably, it correlated with having recently practised interview questions, with comfort under artificial pressure, and with a particular educational background.
The first two are exactly as relevant as they always were. The difference is that the exercise no longer isolates them, because the observable output can be produced without them.
Weakened signals
- Can produce syntactically correct code
- Recalls a standard algorithm
- Implements a known data structure
- Writes tests for a given function
- Speed of production
Signals that got more predictive
- Reads unfamiliar code accurately and fast
- Spots the plausible-but-wrong
- States what a requirement leaves undefined
- Knows what they do not know, out loud
- Judges whether a change should exist
The single most useful reframe I have found: the job used to be mostly writing and the interview measured writing. The job is now substantially reading, judging and specifying, and almost no interview measures any of the three.
Reading is the underrated one
If I could change one thing about a typical loop, it would be to add a serious code-reading exercise, and I would weight it heavily.
The exercise is straightforward to construct. Take two hundred lines of real code from a system the candidate has never seen, containing a defect that is not syntactic. Ask them to explain what it does and to find the problem. Do not tell them a defect exists until they have described the code, because whether they notice unprompted is itself the signal.
This measures things that are hard to measure otherwise and that turn out to matter enormously. Whether they can build a mental model of unfamiliar code quickly. Whether they read for intent or pattern-match on shape. Whether they notice the thing that is locally reasonable and globally wrong, which is precisely the failure mode of generated code. Whether they say “I do not understand this part” rather than confabulating, which is the single most valuable professional habit there is and one that interviews systematically punish.
It is also much harder to prepare for than an algorithm question, because there is no canonical set of reading problems circulating, and because comprehension does not respond to cramming.
Specification as an interview exercise
The second addition I would make is a specification exercise, and I would use it for every level above entry.
Give the candidate a deliberately underspecified feature request, of the kind a real product manager writes on a Tuesday. Ask them to produce acceptance criteria precise enough that someone else could build against them and a machine could check them.
What you learn is remarkable. Weak candidates restate the request in more words. Strong candidates come back with the questions that were not answered, and the good ones notice the requirements nobody stated: what happens with concurrent requests, what the failure behaviour should be, whether this needs to be idempotent, what happens to data already in the system, what the security property is.
That skill is the load-bearing skill of the agentic life cycle. If criteria are how correctness gets enforced, then people who write good criteria are the people who determine whether your system is safe. Hiring for it directly seems obvious once stated and is done almost nowhere.
An additional benefit: this exercise is close to unfakeable with assistance, because a model given an underspecified request will confidently fill the gaps with plausible defaults rather than surfacing them as questions. Surfacing the gap is the human contribution, and the exercise isolates it neatly.
On whether to allow assistance in the interview
The question every hiring manager is now arguing about. My position: allowing it, with conditions, is the only defensible option, but it changes what you must evaluate.
Banning it produces an interview that measures something the job no longer contains, and it produces an arms race with candidates who will use it anyway in remote settings. Allowing it without changing the evaluation produces no signal at all, because everyone completes the task.
Allowing it and evaluating the interaction is the useful version. When assistance is permitted, watch how they use it. Do they check the output or accept it? Do they notice when it is subtly wrong? Can they explain why they asked for what they asked for? Do they know when not to bother? An interviewer watching a candidate accept a plausible wrong answer without reading it has learned more than any algorithm question would have taught them.
This requires interviewers who can themselves evaluate that interaction, which is a training problem most organisations have not started on.
What has not changed at all
A short list, worth stating so the argument does not overreach.
Fundamentals still matter. Someone who does not understand how memory, concurrency, transactions or networks behave will accept generated code that is dangerous for reasons they cannot perceive. If anything the cost of this gap has risen, because the volume of code they are accepting has risen.
Debugging still matters, and it is the skill I would weight most highly after reading. It is a search process under uncertainty and it does not automate. Ask about the hardest bug they ever found and listen for method rather than outcome.
Judgement about what to build has always been the difference between a good engineer and a productive one, and it is untouched.
And the ordinary human things are unchanged: whether they can disagree without being unpleasant, whether they change their mind when shown evidence, whether other people want to work with them.
Where this breaks down
Reading exercises are hard to build and harder to keep. They require real code, a genuine non-obvious defect, and enough context to be fair. They leak, they take work to refresh, and a badly built one measures familiarity with your stack rather than comprehension. This is a real cost and it is why most teams will not do it.
Specification exercises reward a particular verbal style. Someone who thinks precisely but writes slowly can score badly for reasons unrelated to their ability. Any exercise weighted toward articulation will disadvantage non-native speakers and people who need time to compose. I do not have a clean fix; giving the exercise as take-home work helps and introduces different problems.
None of this is validated. I am describing what appears predictive based on observation, not on evidence from a hiring process run long enough to correlate against performance. The existing loop at least had the virtue of being wrong in ways we had measured. Anyone who tells you they know the new loop works is ahead of the data.
The junior problem is not solved by better interviewing. The pipeline issue is that the work juniors learned on has automated. You can interview for potential all you like; if there is no apprenticeship path on the other side, you have hired someone into a role that does not develop them. That is an organisational design problem, and it sits upstream of anything the interview can fix.
The takeaway
The interview measured code production because code production was the job and was hard to fake. It is now neither, and continuing to measure it is measuring the wrong thing well.
Test reading, because reading unfamiliar and possibly wrong code at volume is what the day now consists of. Test specification, because criteria are how correctness gets enforced and someone has to be good at writing them. Allow assistance and evaluate the interaction rather than the artefact. Keep the fundamentals, keep debugging, and be honest that none of this is validated yet.
If you take one thing into next week: add one reading exercise to your loop and see how many of your strong-on-paper candidates cannot explain what a piece of code does. The distribution will surprise you, and it will be the most useful thing you learn about your process this year.
The next piece follows the change into operations and asks what on-call means when the person paged has no memory of the code, because nobody wrote it.