You're hiring a software engineer, a backend developer, or a DevOps specialist. The CV looks strong, the conversation went well – but there's a nagging question: can this person actually do what they claim? And how are you supposed to judge that if you don't have a development background yourself?
This is not an uncommon problem. Many companies fill technical roles through HR teams or managers who are excellent at reading people – but who can't read the technical code behind the surface.
What You Can Assess Without Technical Knowledge
There are signals that give reliable hints even to non-technical evaluators.
Concrete answers, not buzzwords. When a candidate answers "What technical challenges have you solved recently?" with something like "I've worked a lot with cloud technologies," that tells you very little. Can they describe the specific problem, the decisions made, and what the outcome was? Depth shows up in specifics, not in jargon.
Ownership and reflection. Does the candidate talk about their own mistakes and what they learned from them? If someone claims they've never faced serious difficulties, they either haven't built much – or they aren't being open. Experienced developers know technology is complex, and they reflect on it.
Explaining technical concepts clearly. Can the person explain a technical concept in a way that makes sense to you? This is not a trick question. It's a genuine sign of professional maturity. Developers who can't communicate ideas clearly often struggle in cross-functional teams and with stakeholders too.
Curiosity and continuous learning. The IT field changes fast. Good developers stay curious. Ask: "What have you learned in the last twelve months without being asked to by your employer?" The answers reveal a lot about intrinsic motivation.
Where the Limits Are – and What That Means
To be honest: with these observations, you can learn quite a bit – but you cannot assess whether the code is clean, whether architecture decisions are sound, or whether a candidate truly has the skills your specific technical environment needs. That's not a gap in your abilities. It's simply a different competence.
This is where the risk of a bad hire is born. A likeable candidate who speaks convincingly about technology isn't necessarily the right person. And a quieter candidate with deep expertise may appear less brilliant in conversation.
What This Means for Your Process
If you want your assessment to stand on solid ground, you need a technical voice in the process at some point – someone with experience in the domain you're hiring for. That could be an internal senior developer, a technical co-founder, or an external expert who evaluates the candidate on your behalf.
The combination of your judgment as a people reader and a qualified technical review is what makes a hiring decision genuinely reliable.
Key Takeaways
- Concrete answers over buzzwords are a good signal
- Reflection and openness about difficulties indicate maturity
- Explaining technical concepts clearly is a real competency marker
- Technical depth assessment requires technical know-how – that's normal and plannable