How to screen software engineers in 2026, when every candidate uses AI

A screen is a filter, and every filter fails in two directions. It lets through people you should have cut, which costs you interview hours. Or it cuts people you should have kept, which costs you the hire. The first failure is visible. The second never shows up in any report, because the person you cut went and got hired somewhere else.

What a screen is for

A screen exists to cut a pipeline down to the number of people you can afford to interview properly, without losing the people you want. That is the whole job. It is not a ranking of who is the best engineer in the pile. You don't have enough information at that stage to rank anyone. You have enough to answer a narrower question: is there a good enough chance this person can do the work that an hour of an engineer's time is a fair bet?

Say 120 people apply for one backend role. You can run eight to ten real interview loops before the team starts dodging the calendar invites. So the screen has to remove about 110 people. If it removes them at random, you keep the hit rate you started with and you've spent nothing but the candidates' time. If it removes them on a signal that predicts the job, your interviews get better. If it removes them on a signal that doesn't predict the job (a keyword, a university name, a puzzle time), you've spent effort making your interview pool slightly worse, and you'll never find out.

Two things follow. A screen should be cheap for you, because you run it on everyone. And it should be cheap for the candidate, because you're asking a lot of people to do it and most of them will get nothing back.

The four signals worth screening for now

The job changed. Most of the engineers I talk to now write code with an assistant open. So the skills that separate a strong hire from a weak one moved too. I'd screen for four things.

Can they read code

Reading got more valuable, because more of the code in front of an engineer was written by something else. Give a candidate 40 lines they haven't seen and ask what it does, what it assumes, and where it breaks. Someone who has been reading code for years answers in a minute and mentions the edge case you planted. Someone who mostly pastes and hopes describes the syntax.

Can they find a bug

Debugging is a different skill from writing, and it's the one a screen can test most cheaply. Hand over a function with a real defect (an off-by-one, a wrong comparison, a race) plus an input that fails, and ask them to find the bug and say why the input fails. The quality of the "why" matters more than the fix. Anyone can guess a fix and rerun the test. Explaining the mechanism tells you they can do it on your codebase on the day the tests don't exist.

Can they explain a change

Ask for a short written explanation of a diff: what changed, why, and what a reviewer should worry about. This predicts how they'll behave in code review and in an incident channel. It's also the hardest signal to fake with a tool, because the tool doesn't know your reviewer or your history.

Can they work with an AI assistant without being led by it

This is the new one, and most screens skip it. Put the candidate in front of an assistant and a task, and watch what happens when the assistant is wrong. Some candidates notice and push back. Some accept a plausible answer that fails on the one input they didn't check. The second group ships bugs faster than any earlier generation of engineer could, and ships them with confidence. What you're looking for is a habit of verification: does the candidate test the suggestion, ask a sharper question, or override it when it's wrong?

Why keyword filters and timed puzzles miss these

Resume keyword filters measure whether a candidate knows which words you want to see. Anyone with an assistant can produce a resume that matches your posting term for term in under a minute, and I assume many do. The filter still cuts people. It cuts the ones who didn't bother to optimize the document, which correlates with nothing you care about.

Timed algorithm puzzles used to measure something: preparation, and a rough floor on ability. Now an assistant solves most of the standard ones in seconds, so an unproctored puzzle measures whether the candidate used one. A proctored puzzle measures whether they memorized a category of problem that rarely shows up in the job. Neither touches reading, debugging, explaining, or collaboration.

Both methods survive because they're cheap to run and produce a number. The number feels like signal. It isn't the one you needed.

A screening sequence for a small team

This sequence fits a team with no recruiter and one engineer willing to spend a few hours a week on hiring. Time costs are rough and per candidate unless noted.

1. Read the application yourself, five minutes each. Cut only on hard constraints: location, work authorization, a level that is plainly wrong. Don't cut on keywords. This is the most expensive step at volume, so cap the pile at what you can read in a morning and close the posting when you hit the cap.
2. Send a short exercise, 45 minutes of candidate time. One code-reading question, one debugging question, one written explanation of a change, and one task where they work with an assistant and you get the transcript. Grade against a written rubric. Budget ten minutes of your time per submission.
3. Call the people who scored well, 30 minutes. Walk through one of their answers and ask them to defend it. This is where you catch the outsourced exercise. The person who did the work can explain the reasoning. The person who didn't can't.
4. Only then run your interview loop.

For 120 applicants, if 90 pass the hard constraints and 60 finish the exercise, that's about ten hours of reading, ten hours of grading, and fifteen or so half-hour calls before anyone reaches the loop. Call it 28 hours of one engineer's time. That's not free. It's still cheaper than running fifteen full loops on people a keyword filter picked, and the loops you do run are on people who've already shown you they can read and debug.

What it costs the candidate is under an hour before they hear from a human. I'd treat that as the ceiling. Past it, your strongest applicants are the ones with the most other options, and they walk.

What to do about AI use

Assume it. Every candidate who wants the job and has the tool will use the tool. Telling them not to selects for people who follow instructions over people who are open about how they work, and you can't check anyway.

Design for it. If a question can be answered by pasting it into an assistant, it will be, and the question stops measuring the candidate. Move the difficulty into the parts an assistant can't do alone: judging whether the output is right, knowing what to check, explaining the choice to a person.

Grade it. The most informative artifact in a modern screen is the transcript of a candidate working with an assistant. Did they brief it well? Did they catch the wrong suggestion? Did they override it, or did they argue with a correct one? A transcript tells you more about daily working habits than any puzzle. This is the part I built Evaluator around, and it's the part I'd argue for even if you build your own: the AI-collaboration section puts the candidate and an assistant on a task inside the assessment and grades the transcript on whether they brief the assistant well, catch a wrong suggestion, and override it when it's wrong.

The trade-off is that grading a transcript takes longer than checking an answer key, and it needs a rubric that says what good looks like. If you don't write that rubric down, you'll grade up the candidates who sound like you.

The mistakes I see most

• Over-long take-homes. A six-hour project asks unpaid work of everyone and gets finished by the people with the most free time, who are not the same people as the best engineers.
• Screening for trivia. Language quirks, framework version differences, the exact signature of a standard library call. An assistant answers these instantly, and the job never asks.
• No rubric. If two people on your team would score the same answer differently, you don't have a screen. You have a coin flip with paperwork.
• One interviewer's gut. Gut is where the biases live. Write the criteria down before you see a single answer, and make the grader justify each score in a sentence.
• Treating the screen as the interview. The screen decides who gets an hour of your time. Ask it to do more and it gets longer for everyone.

If you want to see what a screen built on these four signals looks like, you can generate one from a pasted job description at tryevaluator.com/try, no signup, and read the per-question feedback and the reasoning behind each score.