The Technical Recruiter Interview: Proving You Can Hold a Conversation With Engineers

Every technical recruiting interview has a moment where the hiring manager stops asking about process and asks something like "so what's the difference between a backend and a platform engineer?"

It isn't a quiz and there's no expectation that you can write code. It's a check on a specific risk: that you'll waste an engineering team's time by sending them people who don't fit, and burn the company's reputation with candidates by sounding like you don't understand the job you're selling.

This page is about that half of the interview only. The pipeline, screening, offer and metrics questions are a separate set, and they're covered in Recruiter Interview Questions — no point repeating them here.

The three areas

Area	What they're checking	What it looks like
Reading a CV	Whether you can tell depth from a keyword list	"Here's a CV. Would you pass it? Why?"
Running an intake	Whether you turn a vague req into a searchable profile	"Role-play: I'm the EM, I need a senior backend engineer"
Handling depth	Whether you bluff	"What does this team's stack actually do?"

Reading a CV for signal

The exercise: they hand you a CV and ask whether you'd move it forward. The trap is that the obvious answer — matching keywords to the job description — is the thing they're checking you don't do.

What to say out loud instead:

"Three things I'd look at before the keyword list. First, whether the scale is real — 'built a microservices architecture' at a company of eight people is a different claim than at one of eight hundred, and neither is bad, but they're different jobs. Second, what they owned versus what their team shipped; CVs use 'we' and 'I' almost interchangeably and the screen is where I'd separate them. Third, the move between roles — someone who's gone from a large company to a small one usually chose something, and what they chose tells me whether this role fits."

Then the bit that lands:

"What I wouldn't do is reject on a missing technology. If they've done the same shape of work in a neighbouring stack, that's an engineering-manager decision, not mine — and I'd rather ask than filter someone out on my own guess. Filtering on keywords is how you end up telling a hiring manager there's nobody out there."

The intake role-play

This is the highest-value part of the round and the one candidates prepare least. They play an engineering manager who wants "a senior backend engineer", and your job is to leave the meeting with something you can actually search for.

Weak intake gathers requirements. Strong intake converts them.

Them: "I need a senior backend engineer. Python, ideally some AWS."

You: "Let's make that concrete. What's the first thing they'd work on — is there something waiting for them, or is it general capacity?"

Them: "We're splitting a monolith. It's going to be a lot of untangling."

You: "Then the thing I'm looking for isn't really Python, it's people who've done a migration on a live system. That's a much smaller group and they don't advertise it in a headline — it'll be in a bullet three roles down. It also changes who says yes: some very good engineers find that work miserable, and I'd rather find that out in my screen than in your second round."

Them: "Fair."

You: "Two more. Is there anyone currently on the team whose profile I should be looking for more of — and is there anyone who wouldn't get hired here today? Those two answers tell me more than the job description will."

That last pair is the move worth memorising. Asking who wouldn't get hired today surfaces the real bar, and managers answer it honestly because it's about the past rather than a hypothetical candidate.

Closing the intake: "So I'll go looking for engineers who've broken up a live system, in any language close to Python, and I'll weight migration experience over years. I'll send you three profiles by Thursday and I want you to reject at least one of them, because if you like all three I've probably pitched too safe and I need to know that early."

Inviting a rejection is a small thing that reads as very experienced.

The depth questions, and how not to bluff

You will be asked something you half-know. The whole test is what happens in that second.

The answer that ends the interview: making something up. Engineers detect it instantly, and it confirms the exact fear that motivated the question.

The answer that works has three parts — what you do know, the boundary, and the question you'd ask:

"Frontend and backend I can describe properly. Platform I'd put as the team that builds what the other engineers deploy onto — CI, environments, the paved road — rather than shipping product features themselves. Where I'd get out of my depth is exactly where the line sits at your company, because it moves: some places platform owns databases and some don't. That's something I'd want twenty minutes on before I write any outreach, because it changes who I'm talking to."

Nobody loses a technical recruiting role for that answer. People lose it for the confident wrong one.

A few terms worth being able to describe in one plain sentence each, because they come up constantly and vagueness about them is expensive:

Term	A sentence that's enough
Frontend / backend	What the user touches, versus what runs on the server
Platform / infrastructure	The team that builds what other engineers deploy onto
API	The contract that lets two systems talk without knowing each other's internals
Monolith / microservices	One deployable unit versus many, with the trade-off being coordination against complexity
Full-stack	Works across both sides, usually with a stronger half — ask which
SRE / DevOps	Keeping it running and making releases safe, rather than adding features

The goal is not to sound like an engineer. It's to be able to have the conversation without either of you having to slow down.

The question they end on

"How would you sell this role to someone who isn't looking?"

It's a technical question disguised as a sales one, because the pitch reveals whether you understood the work. The weak version sells the company — funding, growth, culture. The strong version sells the problem:

"I'd lead with the migration. For the right engineer that's a genuinely interesting two years of work and it's the kind of thing that's hard to get access to — most places won't let you near it. I'd be honest that it's untangling rather than greenfield, because the people who'd hate that will self-select out, and that's a good outcome for both of us."

Selling the problem rather than the perks is also, incidentally, what makes outreach get replies.

Preparing

Two exercises, both short.

Take a job description for an engineering role you've hired for and write the one sentence that actually narrows the market — not the requirements list, the differentiator. If you can't find it, that's what intake is for.

Then pick three terms from your current reqs that you'd describe vaguely under pressure, and write one plain sentence for each. Say them out loud. The fluency you need isn't knowledge, it's not hesitating.

For the analytical side of a recruiting loop — where they hand you a role and ask for a plan with numbers — the worked version is here: Recruiter Interview Case Study.