Has it ever happened to you that you found a candidate who ticked every box on the job description and sailed through screening, only for the magic to disappear the moment they sat down for a technical interview?
One of the hardest moments in my job is learning that a candidate I recommended for the technical interview (the second stage of a recruitment process at Happy Team) doesn't have the right skills, and the whole meeting turns out to be a waste of everyone's time.
I then ask myself the recurring questions: Could I have designed the screening better, so I'd pick up on a candidate's technical potential? And is that even possible when I’m not a technical person myself?
Below you’ll find a list of tips I use as a non-technical recruiter to bring in candidates as technically strong as possible.
And if you're a developer who came across this article, stick around. You'll see that there are real people on the other side, who genuinely want to assess you fairly.
Make sure you know who you're looking for
Have a thorough conversation with the Hiring Manager. Ask them who they're actually looking for.
- Is there anything in particular they look for?
- Does commercial experience matter above all else, or would it still count if candidates had only used a tool or technology in personal projects?
- Are there specific responsibilities that matter the most?
You can put the same questions to the team – ask what they spend most of their time on and look for parallels in what candidates say.
💬 What are the 3 things a candidate absolutely cannot get away with not knowing?
Dig into previous experience
Ask the candidate about their most recent role and encourage them to cover as many technical details as possible.
Push for technical answers. After screening, you can share your notes with someone who works on that type of project or with the Hiring Manager and ask how they'd rate a candidate's seniority.
If the candidate’s answers are full of specifics – tools used, decisions made, problems solved – that can be a sign of high seniority. It's also a learning opportunity for you, because you'll start to understand which concepts are considered more advanced.
💬 Tell me about your most recent project – what technologies did you use, and what decisions were yours to make?
Ask about learning process
If the candidate is self-taught, ask what resources they used to get into the field. Maybe they had a mentor at a previous job who invested time in them? If so, ask about that person: their seniority level and responsibilities.
It's important to understand the path the candidate took to build their skills. Was it a quality path? Do they know the fundamentals? Have they picked up any bad habits along the way? If the picture that emerges is chaotic, and they can't name their main sources of knowledge, there's a high risk of gaps.
💬 How did you get into programming? What was your main source of knowledge at the start, and where do you go to learn now?
Dig into what “growth” actually means
Candidates often say they're looking for new challenges. It's worth asking what kind of challenges. Sometimes the answer will surface a skill set that's directly relevant to the role, or areas they want to go deeper into that could come up in the job.
If a candidate has specific goals – "I want to move into architecture" or "I want more system design work" – you're dealing with someone self-aware, who knows where they want to go and has the motivation to get there.
💬 What do you want to learn over the next six months, and why that specifically?
Focus on recent achievements
Ask what they've learned lately. This gives you a feel for the level of difficulty and the challenges they've actually been dealing with. You may come across someone who pushes themselves outside of work, too – personal projects are a good signal that a candidate enjoys programming and wants to be as good as they can be.
If the highlights they mention are several years old, that might suggest they've stopped growing and are coasting on past wins.
💬 What's surprised you technically? What have you learned or discovered recently?
Don’t be afraid to ask “basic” questions
If something comes up – ask how it works. Check whether the candidate can explain a technical process to a non-technical person. It's also a decent read on their patience and ability to pass on knowledge. People who genuinely understand the principles and can connect definitions into a coherent whole will tend to handle this well.
Clear, logical explanations show that the candidate has a real command of their knowledge. Muddled definitions with no logical thread are often a sign of disorganised understanding – or that they've simply never had to explain it to anyone before.
💬 Could you explain to me what [e.g. REST API / CI/CD / a Docker container] is, as if I'd never heard of it before?
Keep the conversation on technical ground
Don't let the business side dominate the conversation. Remember: even though you're not technical yourself, your job is to gather as much information as possible about the actual challenges and responsibilities the candidate faced at work. Your notes can always serve as a foundation for later technical conversations.
If a candidate is clearly dodging technical answers and drifting into stories about the business, processes, and management, that can point to a lack of hands-on experience.
💬 Tell me about the biggest technical challenge you've faced. How did you approach it, and what would you do differently today?
Ask about the biggest technical challenge
This one tends to reveal a lot. Listen for specifics – not just what the challenge was, but how they thought through it and why they made the calls they did. If their decisions touched on architecture or automation, that's usually a sign you're talking to someone fairly senior.
Let the conversation go where it naturally leads: why that solution and not another one? What would they do differently today? Candidates who can reflect honestly on their own work (not just describe it) tend to be the stronger ones.
💬 Which task in your most recent project demanded the most from you technically?
Pay attention to the scope of responsibility
Check what their actual ownership looked like. Does the candidate mostly talk about working solo or as part of a team? Were the decisions they made driven by external input or support?
If they frequently highlight their own role and responsibility, that might genuinely mean they played a key part in the team.
If the answers feel inconsistent, it was probably more of a team effort – and the scope of their personal responsibility may be smaller than it first appears.
💬 Who made the final technical decisions in your team? How often did you do that?
Step away from the success narrative
Ask the candidate about a mistake or a poor decision they made at work. Pay attention to how they think through a problem and whether they can draw lessons from it. Ideally, they'd walk you through the steps they took to fix things and rescue the project.
The least interesting answers here are the ones where they have no idea how to respond, shift the blame onto teammates, or give vague, generalised answers with no real reflection on how to avoid making the same mistakes in the future.
💬 Tell me about a time you made a bad technical decision. What happened, and what did it teach you?
Wrapping up
Screening is the stage where, among other things, we dig deeper into a CV and decide whether it's worth recommending someone to the technical stage. It won't replace a technical interview, but it can make the whole process more efficient, so that technical interviewers can quickly identify the strongest candidate in the room.
During a well-designed screening, you will spot an engineer with genuine potential. Someone whose experience maps onto your actual needs. Someone who doesn't just communicate well in a conversation, but can speak clearly about their successes, draw lessons from mistakes, and has a real sense of their own motivation and direction.
For a recruiter, what matters is whether the candidate speaks with precision, whether they understand and can explain their own decisions, whether their scope of responsibility matches what you're hiring for, and whether they'd actually fit the existing team. Uncertain, chaotic answers where it's hard to find any technical substance – or any confirmation of the specific knowledge you're looking for – should be a warning sign.
If several areas produce answers that don't satisfy you, that's a signal to hold back on recommending the candidate. At Happy Team, we also have a simple rule: if, after a screening, we can't say "Oh yeah", we don't hire. That way, only truly promising candidates make it to the technical interview.
