AI-Native Hiring Guide: An Interviewer's Rubric for Engineers Who Drive Agents

What the Handbook Replaces, and What It Assumes You Already Do

The README opens with a blunt framing: in 2026 programmers are mecha pilots, and the hiring target is no longer people who write code but people who can drive an AI agent. The stated problem is that conventional technical interviews test whether a candidate can produce correct code, and that test stops discriminating once an AI produces better code than most applicants.

So the guide measures five things instead: the quality of an issue written for an agent, the judgement to spot risk in AI output, the ability to work with an agent efficiently, product instinct and systems thinking (whether something should be built at all), and decision-making under pressure. Note the assumption baked into that list. Every one of these skills is defined relative to a working agent pipeline. A team that has not standardised on an agent tool has nothing for the candidate to drive, and the exercise collapses.

The intended audience is explicit in the About section: it is an internal interview tool for Ehafo Medical, open sourced for peers to reference. That origin explains the shape of the artifact. It is a scoring instrument for interviewers who already agree on what good looks like, not a teaching document for teams still deciding.

Two Roles, Five Modules, Fifty Points

The guide splits the target role into Builder, who drives output, and Reviewer, who guards quality, plus a hybrid path for candidates who fit both. The interview runs 60 minutes: five minutes to break the ice and decide which archetype the candidate is, fifteen minutes on a shared segment covering issue writing and solution review, ten minutes on the live AI-driving exercise, fifteen minutes on the role-specific module, ten minutes for the candidate's questions, and five minutes to score on the spot.

Scoring is five modules at 10 points each, 50 total. PASS requires 35 or more (70 percent) with no veto triggered. HOLD is 30 to 34, which puts the candidate in reserve. FAIL is below 30, or any single veto condition firing. Each of the 14 structured questions ships in a junior and a senior variant and carries a three-band rubric at 5, 3 and 1.

The arithmetic is worth pausing on. A candidate can score 34, land in HOLD, and be one point away from PASS while a different candidate at 35 passes outright. The guide does not describe a tie-break or a review step for that boundary, so whoever runs the loop has to decide how much weight a single point carries. That is a design gap, not a bug, but it is the kind of gap that shows up in a real hiring meeting.

The Live AI-Driving Segment Is the Load-Bearing Wall

The 20-30 minute block labelled AI driving is the part that distinguishes this from a question bank. The README calls it the basic skill of the mecha pilot and describes it as watching, in the room, how a candidate operates an AI agent. Nothing in the supplied material specifies which agent, which task, or which environment the candidate works in, and that is the largest unstated variable in the whole handbook.

If your team uses one agent tool and the candidate has only used another, the segment measures tool familiarity as much as it measures driving skill. The guide does not address this. An interviewer running it has to either supply a neutral task that any agent can attempt or accept that the score partly reflects which product the candidate happens to know.

The Reviewer track has a related asymmetry. Reviewing AI output is a skill you can test with a prepared code diff, and the README mentions prepared materials including solution summaries and code diffs so that non-technical interviewers can run the session. That is a real convenience: a recruiter or a manager without a coding background can administer the review questions with the supplied artifacts. But it also means the Reviewer module can be scored without the interviewer being able to independently judge the diff, which pushes a lot of weight onto how well those prepared materials were written.

Running It: One HTML File and Two Commands

The deployment story is genuinely minimal. The README describes the artifact as a single-file HTML page with zero dependencies that opens directly in a browser, and there is a hosted copy at vorojar.github.io/ai-native-hiring-guide/. The local instructions give two options:

open index.html

or, for any HTTP server:

npx serve .

The scoring record is filled in inside the browser and supports printing or PDF export, which is what makes the 55-60 minute scoring slot practical: the interviewer scores while the session is fresh rather than reconstructing notes afterwards.

What the material does not provide is any configuration. There are no config keys, no environment variables, no JSON schema for the question set, and no documented way to substitute your own questions or adjust the 10-point module weighting. If you want to change the rubric, you are editing HTML. For a team that wants to fork the questions and keep them in sync with an internal repo, that is a maintenance decision the README does not speak to.

Six Veto Conditions and the Cost of a False Positive

The guide includes six hard elimination criteria, described as a guard against subjective drift. The logic is sound: a numeric scale invites generosity, and a veto list caps how generous an interviewer can be. A candidate who triggers any one of the six fails regardless of the other 49 points.

One-vote-veto systems have a known failure mode, and this handbook does not document a mitigation. A single interviewer who misreads a candidate on a veto item ends the process, and there is no described appeals step or second-scorer requirement. The README also does not list what the six conditions actually are, so a team evaluating the project cannot check whether the vetoes match their own bar without opening the HTML.

That is the first thing to inspect. Veto conditions are where a hiring rubric encodes its culture, and this one hides them behind a browser tab. If the six items turn out to include something your team does not consider disqualifying, the whole scale becomes unusable without editing the file.

Where This Fits Against a Conventional Interview Loop

The obvious alternative is the standard loop: a coding exercise, a system design conversation, and a behavioural round. The difference is not difficulty, it is what gets observed. A coding exercise samples the candidate's own output. This handbook samples the candidate's output through an agent, which is a different signal: issue phrasing, review eye, and how they recover when the agent goes sideways.

A second alternative is the take-home plus review. That measures the artifact, and it scales better because it does not consume an interviewer's hour. This handbook deliberately does not do that. The live segment exists precisely because the README frames agent operation as something you watch rather than something you read afterwards, and a take-home cannot show how a candidate reacts when a run fails mid-task.

The trade-off is cost. Sixty minutes of interviewer time per candidate, with a segment that only works if the interviewer understands agent workflows well enough to judge them. A take-home is cheaper and more comparable across candidates; this is richer and more dependent on the person running it.

Licence, Maintenance and What to Verify Before You Commit

The README ends with an MIT License line. The repository metadata supplied here returns no licence identifier, and there are no releases. Those two facts point the same way: the licence claim lives in the README text, so confirm the LICENSE file in the repository before you redistribute or modify the handbook inside a company. This is not legal advice, just the gap between what the README asserts and what the metadata shows.

Maintenance is a real question for a document like this. The last push is dated 2026-03-12, there are no releases, and the project is not archived. A hiring rubric ages in two directions at once: the agent tooling it assumes changes, and the roles it defines shift as teams reorganise around those tools. With no release process, there is no version number to pin, so if you fork the HTML you own the divergence yourself.

The practical sequence before adopting it: open index.html, read the 14 questions and the six veto conditions, and check whether the Builder and Reviewer split matches how your team actually divides work. If the veto list survives that reading and you can run the live segment honestly, the 50-point scale is a usable instrument. If either check fails, you are better off writing your own questions and borrowing only the 60-minute time budget.

Editorial conclusion

Adopt this if your team already ships through AI agents and you need a shared vocabulary for Builder and Reviewer roles plus a printable score sheet for the same 60-minute loop. Do not adopt it if you are still hiring for conventional coding ability or if you cannot run the 20-30 minute live AI-driving segment, because the rubric assumes that observation happened. Before using it, open index.html and read the 14 questions and the six veto conditions against your own stack: the repository states the licence as MIT in the README, but the GitHub metadata returns no licence identifier, so confirm the LICENSE file yourself and check whether the 10-point-per-module weighting across five modules matches what your team actually values.

Official sources

1. Issues
2. Project website
3. README
4. vorojar/ai-native-hiring-guide on GitHub