Hiring and Growing Engineers When Code Is Cheap

---

In Lesson 1 we established that judgment, not code production, is now the scarce resource. That has an immediate, uncomfortable consequence: most hiring loops are still selecting for the wrong thing. And a slower-burning one: the system that grew juniors into seniors is breaking, and few teams are doing anything about it.

Hiring: interview for judgment, not syntax

The traditional technical loop optimized for writing correct code quickly under pressure. AI made that signal nearly worthless — it produces false positives (candidates who look fast, or quietly used AI) and false negatives (strong reasoners who don't grind algorithms). You have to move the target.

The single most useful format I've adopted: give the candidate AI-generated code that looks correct but is subtly wrong, and ask them to assess it. Plant a race condition, a missing edge case, an injectable query, a wrong abstraction. Then watch:

• Appropriate suspicion — do they treat plausible code as guilty until proven correct, or trust it because it compiles?
• Depth of reasoning — can they articulate why it's wrong, not just that a variable name is bad?
• Correction quality — do they fix the cause or patch the symptom?

This tests exactly what the job now requires. The weak signal is a candidate who accepts the code; the strong signal is one who's suspicious in the right places.

Beyond code review, probe judgment directly: give an ambiguous problem and watch how they decide what to build and what not to; have them reason about a system they didn't write; ask for a real story where the obvious answer turned out wrong. You're hiring the judgment that decides whether code should ship — interview for that.

Crutch vs tool: let them use AI, then watch how

Don't ban AI from interviews; it's silly to pretend it doesn't exist at work. Let candidates use it and assess how:

• Crutch user — accepts output uncritically, can't explain it, helpless when the AI is wrong (which they can't detect). Looks productive, ships subtle bugs.
• Tool user — prompts well, verifies output, catches the AI's mistakes, and can explain and defend every line as if they'd reasoned it themselves.

Make the rule "use whatever you want, and be ready to defend every line." A candidate who can't defend their AI's code has told you they'd ship code they don't understand — the exact failure mode AI introduces at scale, and the most important thing to screen out.

Growing: the apprenticeship is breaking — fix it on purpose

Here's the strategic trap. The short-term math looks like "a senior with AI outproduces a junior and the time spent reviewing the junior — so why hire juniors?" Follow that logic across the industry and you get: no juniors entering the pipeline → current seniors age out → no mid-levels grew into senior roles → an acute shortage of exactly the judgment AI can't replace.

Seniors are not summoned; they're grown, over years, from juniors who made mistakes on real systems, got them caught in review, and slowly internalized judgment. If AI removes the rung where juniors used to write simple code, you haven't removed the need for that learning — you've removed the mechanism for it.

So the answer isn't "stop hiring juniors." It's change what juniors do and how they learn:

• Have them review and critique AI output, not just produce it. Reviewing is how judgment forms, and it's now available in unlimited supply.
• Make them explain and defend the generated code they ship. If they can't explain why it's correct, they've learned nothing — they've forwarded a guess.
• Give them ownership of failure modes and operations early. The 3am pager teaches what no AI hands you.

Used as a crutch, AI lets a junior skip the learning entirely. Used as a tutor — with these guardrails — a junior can build judgment faster than previous generations did, because they have a tireless explainer on tap. The difference is entirely in how you structure their work, which is your job, not the tool's default.

Reflect before moving on

Two questions for your team. First: does your interview loop test something an AI now does for free? If a round is mostly "write this function from scratch," replace it with "here's plausible code — what's wrong and how would you fix it." Second: are your juniors building judgment or forwarding guesses? If they ship code they can't explain, your pipeline is quietly breaking.

→ Go deeper in the companion essay: Hiring for Judgment in the AI Era: An Interview Playbook. Next, we turn hiring into a durable structure: the career ladder.