"Send me another unvetted profile and I'm done working with you"
That email, a Tuesday morning. The engineering lead at a major client was looking for a Microsoft infrastructure architect. I'd sent over an Azure and Office 365 specialist — a functional expert, not a technical one. I didn't catch the difference. The client did.
I spent five years as an account manager at a staffing agency, placing developers and IT contractors. Five years of evaluating technical profiles without being technical myself. That situation — different client, different tech stack, same gut-punch — happened more times than I can count.
If you recruit developers for a staffing firm or a recruitment agency, you know the feeling. A resume lands on your desk, the candidate sounds strong, but you have no way to verify. No engineers on staff. Just contractors already billed out to clients, finishing their day at 6 PM with no interest in screening your candidates for free.
This article is what I wish I'd had when I started. The methods I built up through failed placements, lost clients, and hard lessons on the ground.
The real problem: nobody to validate
In a staffing agency focused on contractor placement, the pattern is always the same.
Zero developers on staff. Zero time to validate.
Your consultants are at client sites, on assignment, billed. Asking them to do a technical interview means asking them to work for free on personal time.
I tried. "Can you talk to a candidate tonight? 30 minutes, tops." The answer, when it came: "I have a life." And honestly, fair enough.
So you end up alone with the resume. You do what every non-technical recruiter does: evaluate based on career trajectory, communication skills, gut feeling. You check that dates line up, that the candidate speaks confidently about their projects. But is what they're telling you technically solid? Or is it polished fluff? No way to know.
Reference checks help a bit. A former manager will tell you if the contractor was reliable and pleasant to work with. Rarely whether they actually knew Spring Boot or if their code passed review on the first try.
Competence signals you can spot without technical skills
After hundreds of screening calls, I identified three indicators that require zero technical knowledge to evaluate.
Clarity of explanation. Ask the candidate to explain their last project as if you weren't technical. A good developer will make you understand what they built, why, and how — without drowning you in jargon. If after five minutes you still don't understand what they did, that's a signal. Either they don't master their subject or they can't communicate — either way, your client will have the same problem.
Career consistency. A Java developer who lists Angular, React, Vue.js, Svelte, and Python in their skills but has only done Java projects for three years? Inconsistent. Someone who actually worked with a technology can tell you about a concrete project where they used it. "I saw it in a training" doesn't carry the same weight as a six-month production deployment.
Ability to talk about failures. A candidate who says everything always went smoothly is either lying or lacks self-awareness. Good developers can describe a problem they encountered, how they identified it, and what they did to fix it. It's in the description of the problem that you hear the real skill level.
Questions that reveal the real level
You don't need to ask technical questions. You need questions that force the candidate to be specific.
About past projects:
"Tell me about a project where you had to make an important technical decision. What was the context, what were your options, and why did you go with that one?"
This single question tells you a lot. A skilled developer will talk about constraints, trade-offs, and business context. A shaky profile will stay vague: "We used React because it's good."
"What's the hardest bug you've solved recently?"
Same logic. You're listening for the resolution process, not the technology involved. Did they investigate methodically? Or did they throw things at the wall hoping something would stick?
About collaboration:
"When a colleague proposes a technical approach you disagree with, how do you handle it?"
"If you join a team and the existing codebase is poorly structured, what do you do?"
These questions reveal professional maturity. A junior says "I'd rewrite everything." A senior talks about trade-offs, technical debt, and business priorities.
Red flags I learned to spot
Five years in staffing sharpens your instincts. Some profiles trigger an immediate alert.
Technology name-dropping. The resume lists 15 frameworks, the candidate talks about "modern stack" and "microservices," but can't explain what they actually built with any of them. I had a candidate rattle off Kubernetes, Docker, Terraform, and AWS in the same sentence. When I asked what they'd deployed on AWS themselves — silence.
Inability to simplify. "It's hard to explain if you're not technical." Red flag. A developer who masters their subject can explain it simply. I've placed architects who explained distributed systems using everyday analogies. And I've passed on "seniors" who couldn't clearly describe their last project.
No questions at all. A good developer is curious about the project, the team, the tech environment. A candidate who asks nothing is either disengaged or so desperate they'll take anything — and leave at the first recruiter call.
Overly perfect answers. Since ChatGPT, this signal has become more common. Answers that are too structured, too thorough, too polished. On phone screens, you sometimes hear the slight delay of someone reading a screen. On video calls, it's the gaze drifting to the bottom left at every question.
Delegating the technical screening
These methods work. I used them for five years. But let's be honest: they take time, they depend on your experience, and they have limits. You catch the clearly weak profiles and the clearly strong ones. Everything in between — which is the majority — you're going on gut instinct.
That's why I built Reqa.
The idea is straightforward. Instead of asking a contractor on assignment to spend 45 minutes after work screening a candidate, you send the candidate a link. They do a 25-minute technical interview with an AI that adapts to their answers — digging deeper when needed, adjusting when they struggle.
You get a report with skill-by-skill scores, strengths, areas of concern, and concrete excerpts from the conversation. Five minutes of reading, and you know whether the profile is worth putting in front of the client's technical team.
This doesn't replace the final human interview. The face-to-face with the hiring manager is still essential. But the difference between "sending a profile and hoping for the best" and "sending a profile backed by a structured technical report" shows up directly in your placement rate.
What I'd do differently
If I'd had these methods and this tool from my first year in staffing, I'd have kept clients I lost due to weak technical credibility. I'd have avoided sending that functional specialist for a technical architect role. I'd have placed faster, and better.
Tech recruiting without being technical isn't a handicap. It's a real skill set. But only if you have the right methods and the right tools.