Code generation is becoming easier to buy than good engineering judgment. That changes what a hiring process should reveal. It does not erase the need for an engineer who understands databases, distributed systems, security, tests, architecture or the product. It raises the cost of employing someone who can produce a convincing diff but cannot explain why it is the right change or when to stop it.

My preferred interview gives the candidate a short, plausible agent-produced artifact and a few open questions. Let them use an agent where that reflects the role. I want to hear what they question after the agent reports success: which evidence they would seek, how they handle a missing business decision, how they protect attention across parallel work, and what they would communicate to the next owner. The interview should reveal reasoning without requiring unpaid implementation work.

This is my proposed hiring design, not a measured claim that a particular rubric predicts success in every company. The examples below are constructed interviewer prompts, not candidate homework. Adapt the questions to the role's actual duties, assess them consistently, and check the rubric against subsequent job outcomes where appropriate. A longer practical exercise, if genuinely necessary, should be narrow, time-bounded and paid. That last point is my fairness recommendation, not an OPM rule.

The first diff has become a poor finish line

A few years ago, an interview that rewarded fast implementation at least measured some portion of the day-to-day work. Today a candidate can ask a capable agent to draft a feature, modify a repository and produce a tidy summary. The scarce question shifts from “can you type this?” to “can you decide what should exist, constrain the implementation, detect a false green light and defend a release?”

This does not mean coding skill disappears. An engineer must still read what the agent wrote, understand the architecture it touched, anticipate failure behavior and tell a causal story about production. The stronger the agent gets at producing surface-plausible output, the more damage a weak causal model can hide behind it. The hiring signal is the quality of decisions and evidence around the code, with technical fundamentals tested explicitly.

The available research describes change but does not settle the size or direction of productivity for every team. DORA's 2025 report characterizes AI as an amplifier of an organization's existing strengths and weaknesses. An early-2025 METR randomized trial found 16 experienced open-source maintainers took 19% longer on their own repo tasks with then-current AI tools. In February 2026, METR said later data suggested possible speedups but selection effects and time measurement made the new estimate unreliable. The early result is not a permanent verdict; the later update is not a clean universal speedup number. Measure your own end-to-end accepted work.

A 2026 longitudinal questionnaire study of professional developers reported a shift from writing toward directing, evaluating and correcting AI output, with some worsening flow and cognitive-load reports. It is self-reported observational work, not an experiment proving that any one hiring process works. It is still a useful prompt to ask whether our interviews resemble the actual supervisory work we now assign.

A plausible patch as a short interview prompt

Imagine a fictional billing service changing the schema of an event. The interviewer brings a one-page packet: a small producer diff drafted by an agent, its green test summary, a simple event diagram and a brief. Two downstream consumers exist, but their code is outside the packet. The old-event compatibility window is unspecified. The candidate is asked to reason aloud over the artifact, not to build or maintain this service.

A weak prompt would hide a trivial bug and call any failure to spot it “agentic engineering.” That tests a narrow coding pattern. The stronger question tests whether the candidate can see the cross-system contract and the unresolved decision. Ask, “What would you need to know before releasing this?” A strong answer might include:

• “These tests cover the producer. Which consumer owner can confirm the older contract?”
• “What is the product requirement for old events already queued or replayed after rollout?”
• “Can we preserve both versions temporarily, and what exact event sample proves a lagging consumer can read the new shape?”
• “What observable signal would pause or roll back the migration, and who has authority to decide?”

There is no magic answer to the compatibility period; the business and system owners must define it. The candidate is being assessed on whether they surface that decision, describe an evidence path and communicate the uncertainty. An interviewer can then reveal one late fact—say, a consumer cannot upgrade for two weeks—and ask how the release recommendation changes. A patch can be elegant and still transfer a release risk to a team that never agreed to it.

The engineer's fundamentals are visible in a short conversation if the interviewer knows what to listen for. A strong answer distinguishes schema evolution, retries, out-of-order delivery, event replay, duplicate handling, source of truth, monitoring, rollback and partial deployment. It can trace the producer in the supplied excerpt and locate assumptions about consumers that the excerpt cannot prove. A candidate who only recites “test more” without naming an old event, a consumer version and an expected business result has not shown the necessary model. The agent can draft an implementation later; the engineer is responsible for the model of reality that tells us whether it is acceptable.

The build decision is itself a test

I would also ask a candidate when not to build. Give a salesperson an agent, and a meeting scheduler appears in an afternoon. If that salesperson needed to close leads, the visible demo might be a distraction masquerading as initiative. The owner now inherits conflicting calendars, cancellations, reminder delivery, permissions, time zones, support and vendor integrations. A maintained scheduling product may be a small recurring cost relative to the lifetime cost and diverted attention of a custom one.

This is not a blanket “always buy.” A company may have a real differentiating workflow or regulatory constraint. I want an engineer or technical leader who can draw the boundary: what part is commodity, what must be custom, who will maintain it, what risk the vendor assumes, what integrations are still ours, and what the full cost looks like over a year. The candidate should be able to say “buy,” “build,” “compose,” or “wait,” and support the choice. Claude Code's own documentation establishes the tool's ability to read, edit and run code; it does not show how much time organizations waste re-creating SaaS products. That waste is my argued risk, illustrated here, not a measured prevalence claim.

Make “anti-laziness” observable

“Anti-laziness” sounds like a personality label. In an interview I can observe something more concrete: does the candidate seek a falsifying fact after the first plausible answer? In the event prompt, a green producer suite is the first green light. It is not evidence that a lagging consumer processes replayed events correctly. The candidate who notices that distinction and specifies an independent compatibility probe has shown a useful verification habit. The employer builds and runs the probe on its own time.

I would record behaviors rather than impressions:

None of these behaviors replaces core engineering skill. A candidate who cannot explain the data flow or diagnose a failing replay should not pass simply because the process notes sound polished. Conversely, a brilliant coder who ignores the product decision or leaves no usable handoff is not demonstrating the full role the team needs.

Protect attention while orchestrating agents

The word “multitask” can reward the wrong behavior. Six agents producing diffs in parallel may create six review queues and six plausible but incompatible stories about the system. The useful skill is deciding which tasks are independent, giving each a bounded acceptance contract, preserving its state and collecting evidence at a review gate. Human attention goes to the decision with the highest consequence or uncertainty, rather than to the latest notification.

In another short question, I would describe three potential work streams: the billing migration, a documentation cleanup and a production alert. Ask what runs now, what can be delegated, what information changes the priority, and when the candidate would review each result. The strong response may pause one stream. It may ask for the alert's customer impact before launching any code change. It may keep the migration in an isolated branch or worktree until the contract owner answers. This is reasoning over a scenario, not a request to operate three agent streams in the interview. The score is whether the proposed parallelism respects review capacity.

This is also a business issue. A manager who sees more commits but a growing release and review queue has not created more completed product value. Use the right denominator: accepted changes that satisfy product requirements, escaped defects, incident cost, rework, time spent reviewing, and work consciously avoided. The exact measures will vary by product and risk. “Time to first diff” is a useful submetric, not the total outcome.

Communication is a technical control

As code production becomes less scarce, the handoff around it becomes more important. “Fixed” tells a future engineer almost nothing. I want a decision packet with five fields:

1. Source: What request or observation initiated the change, and what is its authority?
2. Change: What code, configuration or behavior actually changed?
3. Proof: Which independent tests or readbacks ran, on what version and environment?
4. Uncertainty: What was not tested, what assumption remains, and what would invalidate the decision?
5. Owner: Who accepts the release, monitors it and can roll it back?

For the billing prompt, ask the candidate to describe the handoff they would want: event versions actually tested, the replay trace still needed, participating consumer owners, the migration window and stop condition. They should not invent a completed trace. If their proposed packet lets the next person identify the unproved boundary, it reveals whether they understand durable engineering communication. Google Research's 2026 qualitative taxonomy draws on 91 developer-written agent rule sets and 15 experienced-developer interviews; its expectations include adhering to standards, ensuring quality, problem solving and collaborating with the developer. That study describes desired agent behavior, not evidence that my five-field packet improves a company's hiring results. The packet is an engineering proposal to test.

An interview loop built around the real job

The U.S. Office of Personnel Management starts assessment design with a job analysis: what work does the role actually do and which competencies are required at entry? Its structured interview guidance uses predetermined job-related behavioral or situational questions and common scoring standards; its guide shows question-specific examples for rating answers. OPM says structured interviews commonly cover four to six competencies, balanced against available time. My few-question format can probe several related competencies per prompt; it is my proposal, not an OPM-prescribed question count or a validated private-sector hiring test.

I would prepare the artifacts and answer anchors before meeting a candidate. A concise loop can use three open prompts. First, show the green billing patch and ask: What could make it unsafe to release, what smallest independent result would change your mind, and how does a late consumer constraint change your decision and handoff? Second, use the meeting-scheduler case to ask where to buy, compose or build. Third, describe a production alert beside two agent work streams and ask what gets attention first. These prompts cover technical fundamentals, verification, product judgment, attention and communication without asking anyone to finish a project. Give everyone the same artifacts, questions, late fact and reasonable time. Write strong-answer and weak-answer anchors first, use two trained reviewers on a pilot sample, compare disagreements and revise vague anchors. Include a targeted code-reading follow-up so an articulate candidate cannot substitute process language for engineering ability.

The new fact matters. After the candidate presents a plan, reveal that one consumer cannot upgrade for two weeks, or that queued events can replay after the producer deploys. The signal is not whether the candidate guessed that exact fact. It is whether they update the compatibility plan, explain the remaining uncertainty and change the release recommendation when evidence warrants it. If a role truly requires observing implementation under time pressure, offer a separate, narrowly scoped paid exercise with a supplied environment, explicit stop time and no production deliverable. That compensation and scope policy is my recommendation; no cited study here proves its hiring yield.

Ten employer experiments before changing the hiring process

The following are proposed tests for the hiring team, not ten tasks for applicants. They are not claims of measured hiring performance. Start with anonymized or consented pilot data and the role's own job analysis.

1. Map the role's last ten accepted changes to actual decisions, code work, review and handoffs; compare that map with the present interview.
2. Give experienced internal engineers the proposed questions and ask whether their decisions resemble real role work; remove trivia that does not.
3. Give all pilot participants the same short artifact, questions and time; test whether presentation variance dominates the score.
4. Present a cross-system contract decision, not a trivial syntax bug; check whether the questions distinguish substantive reasoning from lucky guessing.
5. Give reviewers independent prewritten anchors for fundamentals, architecture, verification, prioritization, focus and communication; measure disagreement before hiring use.
6. Insert a late fact about a lagging consumer in the conversation; see whether the reasoning changes rather than rewarding a lucky initial guess.
7. Ask which negative-control replay case should fail; have the team, not the candidate, verify that the expected outcome was written independently of the agent.
8. Ask for a buy/build/compose decision on a commodity internal tool; verify the scoring rewards complete ownership reasoning, not a predetermined “buy” answer.
9. Ask one prioritization question about three hypothetical streams and a production signal; see whether candidates protect review attention without making them operate those streams.
10. Compare pilot scores with subsequent accepted-work and review-quality observations where lawful and practical; revise or discard rubric elements that do not help.

The last step matters most. A tidy interview story can become another self-confirming AI workflow. The rubric itself needs negative controls, reviewer calibration and evidence that it predicts something your team actually values.

My hiring rule

Give candidates a plausible agent-produced first diff and a real decision boundary. Ask a few short, open, common questions. Listen for a causal system model, a test that could falsify the green result, a revised decision when a late fact arrives, and a handoff that names uncertainty and owner. Check fundamentals directly. Then hire the engineer who can make and explain those decisions. Do the preparatory build and calibration work inside the company; do not shift it into an unpaid multi-week audition.

The approved written reads for Days 43–49 appear below. An individual video player or native social link is added only after its exact Public copy is read back. The Week 07 engineering field-notes companion contains a fictional interviewer packet, calibration runner, four local synthetic tests and ten proposed probes. Its public files were read back against the local source manifest. This is a proposed interview design, not a measured hiring result or productivity uplift.

The field kit

The companion folder for this week holds runnable examples, decision records, evidence and limits. The repository release log is updated after each article's live readback.