The AI-Era Technical Hiring Playbook

Start here#

A bad technical hire costs you months of salary and months of product, and AI made the old interview easier to pass without the skill.

The old process was a CV, a few interviews, and a coding test. Each step now has a weakness. A CV can be written by AI to match your job post word for word. Interview answers can be fed in during a video call. A take-home test can be finished by an AI coding agent while the candidate watches.

Bloomberg reported on all three sides of this in 2026. In July, job hunters were using AI to cheat in interviews and then failing at work, leaving managers scrambling. Later that month, companies were increasingly worried about applicants using stolen or fabricated identities. And in May, Anthropic's own hiring guidance said candidates should not outsource their thinking to AI.

That last point is the one to hire for. You want an engineer who uses AI well. Your developers should use it; it's part of how a modern team works. What you can't hire is someone who can't think without it. They can't explain the code, find the defect, or tell you whether a change is safe to put in front of customers. The engineer answers for what they deliver, whatever helped them write it.

So this process doesn't ban AI. It looks for evidence that is hard for AI to produce on the candidate's behalf:

• A real person whose identity matches the CV.
• A live conversation about something they built, where every follow-up question goes one level deeper.
• A realistic task done with AI allowed, followed by a debrief where they explain their decisions, diagnose a defect, and say whether the result is ready for customers.

Two words come up below. A work sample is a small, realistic task the candidate completes, like what they would do in the job. A defect is a bug: something in the product that behaves differently from what it should.

1. Decide who evaluates#

Decide who judges the technical skill before you post the role, because you can't, and the candidate will notice if nobody can.

The Empowerment Playbook helps you define who owns each decision.

You judge a lot well: how the candidate communicates, whether they take ownership, whether they ask about your customers, and whether you want to work with them every day. You can't judge whether their code is sound or their technical decisions hold up. Someone has to, and it has to be someone on your side.

A good technical evaluator is a senior engineer or technical leader with no stake in the outcome: an advisor, a part-time Fractional CTO, or a senior engineer from your network who has hired before. Pay them for their time.

Be careful with two choices that look convenient. Your agency's lead can help, but if the agency would lose work when you hire in-house, they have a stake in the result. And a friend of the candidate can't be the evaluator, however qualified.

Write the role before anything else. List three to five outcomes the hire should deliver in their first 6 months, in plain words, such as "Customers can pay by invoice" or "Releases go out every week without breaking the sign-up flow." Every step below checks evidence against those outcomes.

Done looks like: a named evaluator who agreed to the time, and a role written as outcomes.

2. Read the CVs yourself#

A screening tool rewards the CV that matches your keywords, and AI makes every CV match your keywords.

Read every CV yourself. For an early-stage role you will likely get dozens rather than thousands, and a few minutes each is usually enough. Don't let a tool or a job board's ranking decide who you never see. Automated screening favors the CV written to beat automated screening.

Don't try to guess whether AI wrote a CV. Many honest candidates use it to polish their writing. Look for specifics a tool can't invent:

• Named products or projects, with links you can open: a live product, a public code repository, an app store page.
• What they did themselves, as opposed to the team. "I built the billing export" says more than "Contributed to payments."
• Numbers that fit together: dates that add up, team sizes that make sense for the company.
• A path that makes sense: each job explains the next.

Move a candidate forward when you can see at least two things they built and can check that they exist. For each CV that goes through, write one line saying why. You'll use those lines in the next steps.

Done looks like: you read every CV, and each one that went through has one written line of evidence.

3. Check identity#

Confirm the person on the call is the person on the CV, and check it again before you make an offer.

Stolen and invented identities are a real hiring risk now, especially for remote roles. Build the check into the process from the start, and treat every candidate the same way.

At the first call:

• Hold it on video with the camera on, and say so in the invitation. Ask the candidate to keep the camera on for every later interview too.
• Confirm the name matches the CV, the email address, and the professional profile they linked.
• Make sure the person on later calls is the same person as on the first.

Before the offer:

• Call references on numbers or addresses you found yourself, such as through the company's website, as well as the ones the candidate gave you. Ask each reference what the candidate built, and whether they were good.
• Check a government ID through a reputable background check provider, with the candidate's written consent. Follow the laws where you hire, and ask a lawyer there which checks you may run.
• Make sure the name on the contract, the payment account, and the ID match.

Stop the process and talk to the candidate if the person on the call changes, the camera stays off with no reason, the references can't be reached through any independent route, or the names don't match. Ask plainly. An honest candidate has an answer.

Done looks like: every finalist was seen on camera, references were reached independently, and the ID check matches the contract.

4. Talk through their prior work#

Someone who built a thing can talk about it for an hour. Someone who didn't runs out of answers in a few minutes.

Hold a live, 45-minute video call with your evaluator. Ask the candidate to walk you through one project from their CV that they're proud of. Then keep asking one level deeper. The evaluator leads the technical questions; you listen and ask about customers, people, and decisions.

Good questions to go deeper:

• What did the product do, and who used it?
• What part did you build yourself?
• What was the hardest decision you made on it? What else was on the table?
• What broke after it went live? How did you find out, and what did you do?
• What would you change if you built it again?
• Where did you use AI on it, and where didn't you trust it?

Listen for detail that gets richer as you go deeper: names of things, specific failures, trade-offs they regret. Be wary of answers that stay general, that describe what "we" did with no "I," or that come after a pause and sound like a written summary. Don't accuse anyone. Ask the next, more specific question; that's where the difference shows.

Done looks like: the evaluator wrote a short note saying whether the candidate could explain their own work in depth, with two examples.

Optional: a design conversation#

If the role needs architecture judgment, your evaluator can add a system design conversation after this call: 25 minutes for a screen, 50 for a senior role. It runs on a shared whiteboard, with no live coding. The evaluator gives one realistic problem and asks two questions every time: where AI fits in the design, and how the candidate would build it with AI coding agents. Score what you hear on the same scorecard, under the prior-work and AI-judgment lines. Don't add a second rubric.

5. A work sample with AI allowed#

Let the candidate use AI on a realistic task, then find out whether they understand what they delivered.

Design the task#

Your evaluator writes a task close to the job. For most roles, that means a small change to a small, realistic project: add a feature, fix a behavior, or improve something slow. Keep it to about 3 hours of the candidate's time, and pay for it if it takes longer. Don't use real customer data or your real product; use a small practice project your evaluator prepares.

Say in the brief that AI is allowed:

## The task
What to build or change, and who it's for.

## What we give you
A small project, how to run it, and its test data.

## Using AI
Use any AI tools you like. Tell us which ones and what you used them for. You answer for everything you submit, however it was written.
You'll be asked to explain every decision in the debrief.

## What to send back
Your change, a short note on the decisions you made, and anything you'd do
before putting it in front of customers.

## Time
About 3 hours. Stop there, and tell us what you'd do next.

Before the debrief, the evaluator adds one defect to the candidate's submitted change or to the project around it: a small bug that a careful engineer would find, such as a calculation that's wrong in one case or a check that lets the wrong user through.

Run the debrief#

Hold a live, 60-minute video call. The candidate shares their screen. No AI during this call, and say so in advance. The debrief has three parts.

Explain the decisions, about 20 minutes. The candidate walks through what they built and why. The evaluator asks about each choice: why this approach, what else was on the table, what the AI suggested that they changed or refused.

Diagnose the defect, about 25 minutes. The evaluator describes what a user sees: "A customer reports the total is wrong when they apply two discounts." The candidate finds the cause, explains it, and says how they would fix it and how they'd prove the fix works. Thinking out loud matters more than speed.

Justify release readiness, about 15 minutes. Ask: "Would you put this in front of our customers today? What would you check first? What could go wrong after release, and how would we know?" A strong candidate names the risks and the checks. A weak one says it works because the tests pass.

Done looks like: the evaluator scored all three parts of the debrief in writing, with the evidence for each score.

6. Decide and start well#

Make the decision in writing, against the outcomes you wrote at the start, and plan the first 30 days before the hire's first day.

Meet with your evaluator within 2 days of the last debrief. Go through the scorecard together. You decide; the evaluator's written assessment is your evidence on the technical side. If the evaluator has a serious doubt about the technical skill, don't override it because you liked the candidate. Hire no one rather than the wrong one.

Write the decision down: who you hired, why, the evidence for each criterion, and any doubt you chose to accept. You'll come back to it at 30 days.

Then plan the first 30 days:

• One small, real change in production in the first 2 weeks, reviewed by someone else before release.
• One of the 6-month outcomes chosen and scoped by the end of the first month.
• A check-in at 30 days, with the evaluator if possible, against the decision you wrote down.

Done looks like: a written decision, a first 30 days plan the hire has seen, and a date for the 30-day check-in.

Working templates#

Hiring scorecard#

Score each line from 1 to 4. Write one sentence of evidence for every score; a score with no evidence counts as 1.

Good and worrying answers#

Before you post the role#

• The role is written as three to five outcomes for the first six months.
• A technical evaluator agreed, with time set aside for the calls.
• A work sample brief and the practice project are ready.
• The identity checks and the background check provider are chosen.
• The scorecard is agreed between you and the evaluator.

Start with the evaluator#

Find the person who will judge the technical skill before you post the role. Everything else in this process depends on them.

If you're about to hire and nobody on your side can judge the candidates, running that process is part of what I do as a part-time Fractional CTO.