In a nutshell
- You don't need to judge code to screen developers well. You need to judge whether someone can talk specifically, consistently and in depth about work they say they did. Recruiters already have that skill.
- That also happens to be what hidden AI help and proxy interviewers struggle with. A tool can polish an answer to "tell me about a project". It struggles with five follow-ups about the details, in an order it didn't expect.
- Use a 25-minute script: an ownership section about their best recent project, an "explain it like I'm a new PM" question, and a drill-down on two CV claims. Every question below has listen-for cues written for non-engineers.
- Score five dimensions from 0 to 2, then pass, hold or reject. "Hold" means an engineer takes a five-minute look, so you never have to make a technical call you're not equipped to make.
- Accents, nerves, NDAs and empty GitHub profiles are not red flags. Vagueness that doesn't improve when you ask for detail is.
What can a non-technical recruiter actually judge?
More than most people assume. You can't tell whether a database design was right. You can absolutely tell whether someone can describe their own design in specific terms, explain why they made a choice, and stay consistent when you come at it from another angle.
So your screen isn't a mini technical interview. It's a specificity test.
| You can judge | Leave to the engineers |
|---|---|
| What they built, as opposed to what "we" built | Whether the architecture was right |
| Concrete details: names, numbers, dates, problems | Whether the code is clean or efficient |
| Whether the story gets richer or thinner under follow-ups | Whether their technology choices were optimal |
| Whether they can explain a technical idea simply | Algorithmic ability |
| Whether their story matches the CV and profiles | Depth in a specific framework |
This matters more than it used to. In CoderPad's 2025 survey, 40% of recruiters said they had caught a candidate cheating, and among those, 15.5% had seen someone impersonate the candidate. CoderPad sells interview software, so read it as vendor data. Gartner's 2025 survey of 3,000 candidates found 6% admitted to interview fraud, posing as someone else or having someone pose as them. Your screen is often the first and cheapest place to notice inconsistency.
What should I do before the call?
Ten minutes, two jobs.
Pick two CV claims to drill into (5 minutes)
Highlight the two most impressive, specific claims. Good targets:
- A big number: "Cut page load time by 60%", "Scaled to 2 million users".
- A leadership claim: "Led the migration to microservices".
- A recent project that matches the role.
Write each down with space for notes. You'll ask about both.
Do a five-minute GitHub or portfolio check
You're not reading code. You're checking whether the picture is consistent.
| Look at | Healthy sign | Worth a neutral question |
|---|---|---|
| Contribution graph | Activity spread over months or years, with gaps | Nothing for years, then a burst in the last few weeks |
| Top repositories | Related to what they say they do, with a README | Only tutorial projects, unrelated to their speciality |
| "Forked" label | A few forks alongside original work | Almost everything is an unchanged copy of someone else's project |
| Dates | Line up with the CV | Contradict the CV |
The big caveat: an empty or private GitHub is normal. Most professional code lives in private company repositories. Empty is neutral, never negative. Only inconsistency is worth asking about:
"I noticed your GitHub is mostly from the last couple of months. Is most of your work in private company repos?"
"Yes, everything at my last job was private" is a perfectly good answer.
What's the 25-minute screen script?
| Minutes | Section | Goal |
|---|---|---|
| 0–3 | Opening | Set expectations, confirm identity and logistics |
| 3–10 | Ownership: their best recent project | Hear what they did, in detail |
| 10–15 | "Explain it like I'm a new PM" | Check they understand it well enough to simplify |
| 15–21 | CV claim drill-down | Check depth and consistency |
| 21–25 | Logistics and their questions | Notice period, location, pay, next steps |
Short on time? Cut the drill-down to one claim. Never cut the ownership section. It's the most informative part.
Opening (3 minutes)
"Thanks for making time. Just to confirm, I'm speaking with [full name]? Great. For the next 25 minutes I'd like to hear about your work in your own words, ask some follow-up questions, then cover logistics and your questions. I'm not technical, so I'll ask you to explain things simply, and I'll ask for a lot of detail. That's how I make sure I describe your experience accurately to the engineering team. This one's a conversation, so no notes or AI tools needed."
The "I'm not technical" line is honest, lowers the stakes, and gives you permission to ask "what does that mean?" as often as you need. The last sentence states your AI rule for this stage. Greenhouse's 2025 survey found 27% of job seekers had never seen an employer AI policy (vendor data), so say it out loud. Better still, send a written policy with the invite. Our free AI interview policy template is a starting point.
Ownership (7 minutes)
"Tell me about a project from the last year or two that you're proud of. What was it, and what was your part?"
Then pick two or three:
"What did you personally build or decide, as opposed to the rest of the team?"
"What was the hardest problem you hit? How did you solve it?"
"What went wrong, or what would you do differently now?"
"How did you know it was working? Was there a number you watched?"
Listen for:
| Strong | Weak |
|---|---|
| "I" for their work, "we" for the team's, kept clearly apart | "We" for everything; can't say what they did |
| A product name, a team size, a number, a specific bug | "Leveraged cutting-edge technologies to drive impact" |
| Something went wrong, and they describe it | Everything went perfectly |
| Details get richer with each follow-up | Answers get vaguer, or repeat in new words |
| They correct you when you summarise wrongly | They agree with every summary |
That last row is a useful technique. Summarise slightly wrong ("So you built the mobile app?" when they said the API) and see whether they correct you. People who did the work correct you straight away.
"Explain it like I'm a new PM" (5 minutes)
"Imagine I'm a product manager who just joined your team. Explain how that system works in plain language, so I could explain it to a customer."
Then:
"What part is most likely to break, and what would a customer notice if it did?"
Strong: they simplify without losing substance, use an analogy tied to their system, check you're following, and describe the weak spot in human terms ("orders would show as paid but never ship").
Weak: jargon repeated louder, or a smooth but generic answer that could describe any system ("a scalable, cloud-native architecture that handles requests efficiently").
Explaining something simply requires understanding it. A generated answer usually arrives in the complex version and struggles to translate on the fly.
CV claim drill-down (6 minutes)
For each claim, ask what, how, why, and what if:
"Your CV says you cut API response time by 60%. What was slow, and what did you do?"
"How did you measure it? What was the number before and after?"
"Why that approach? Was there another option you considered?"
"What would you have done with half the time?"
That last question changes the conditions of their own story. A prepared answer doesn't cover it.
Strong: they remember the numbers, or honestly say "roughly 800 milliseconds, I don't remember exactly". They name what was slow and an alternative they rejected. "Half the time" gets a real answer: "I'd have skipped the rewrite and just added the cache."
Weak: round numbers with no context, numbers that change between answers, or "I'd have worked harder".
Write down the technical terms they use, even if you don't understand them. The engineer reading your notes will.
Close (4 minutes)
"That's really helpful. Practical things: what's your notice period, where are you based, and what are you looking for on compensation? Then I'd love to hear your questions. The next step would be a 45-minute technical conversation with our engineering lead, and I'll let you know by Friday either way."
Check the location and time zone match the application. If they don't, ask neutrally. The FBI has warned that paid facilitators attend virtual interviews on behalf of North Korean IT workers. Most mismatches are innocent, but simple consistency checks are your earliest defence against proxies of any kind. More in fake job candidates and proxy interviews.
How do I score the screen?
Score immediately after the call, before talking to anyone. 0, 1 or 2 per dimension.
| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| Ownership | Couldn't separate their work from the team's | Some personal detail, mostly "we" | Clear account of what they did |
| Specificity | Generic throughout | Some concrete details | Names, numbers, problems, something that went wrong |
| Depth under follow-up | Got vaguer | Held for one or two follow-ups | Got richer every time |
| Plain-language explanation | Couldn't simplify | Simplified, but generic | Clear analogy tied to their system |
| Consistency | Contradicted CV or profiles | Minor mismatch, plain explanation | Fully consistent |
- 8–10, no zeros: pass. Move to the technical stage.
- 5–7, or any single zero: hold. Send your notes to an engineer for a five-minute look.
- 0–4, or two or more zeros: reject politely.
Two overrides. A zero on consistency means escalate to the hiring manager, not reject, because it might be an innocent mistake or an identity issue. And a missing hard requirement (location, work authorisation) overrides any score.
Why bother with a rubric? Because structured interviews, with planned questions and anchored scoring, are among the strongest predictors of job performance. A 2022 re-analysis by Sackett and colleagues put their validity at about .42, against .19 for unstructured ones.
What are the red flags?
Things worth an escalation or a closer look:
- [ ] Can't say what they personally did on any project
- [ ] Details get vaguer, not richer, with each follow-up
- [ ] Numbers change between answers
- [ ] Agrees with your deliberately wrong summary
- [ ] Explanation is fluent but could describe any system
- [ ] CV, LinkedIn and what they said don't match (employers, dates, location)
- [ ] Long pause before every substantive answer, combined with answers that collapse under one follow-up
- [ ] Voice, appearance or knowledge of the earlier conversation differs at the next stage
What isn't a red flag?
| Not a red flag | What to do instead |
|---|---|
| Accent or non-native English | Score whether the content is specific, not how it sounds |
| Nerves, pauses, "um" | Slow down, one question at a time |
| "That's under NDA" | "Can you describe it without the confidential parts?" |
| Empty or private GitHub | Neutral. Don't score it |
| Short career or career change | Ask about projects, coursework or their previous field |
| Asking you to clarify | Treat it as a positive |
What should I do next?
Print the script and run it on your next three screens. Then compare your holds with what the engineers decided, and adjust.
For the technical side of this method, see technical interview follow-up questions. To see where your whole loop is exposed, take the free cheat-risk audit. And if you'd like stack-specific question banks where every question has listen-for cues for non-engineers, plus a 25-term glossary with a follow-up question for each term, that's in Unscripted, the paid kit.