The first technical conversation with an IT candidate is one of the most critical moments in the entire hiring process – and one of the most difficult to navigate when you don't have a technical background. How do you tell the difference between a candidate who has real substance and one who is simply fluent in technical vocabulary?
The answer doesn't lie in asking more complicated technical questions. It lies in conversation patterns that make depth visible.
Ask Why, Not Just What
Most candidates can answer what they've worked with. What's more revealing is why they made certain decisions.
Instead of: "Do you have experience with cloud infrastructure?" Better: "Describe a decision you made in one of your recent projects where you chose between two technical approaches. What were your reasons – and what would you do differently in hindsight?"
This kind of question isn't a trap – it's honest. Someone who made a grounded decision can explain it. Someone who didn't make or understand the decision will struggle.
The Simplicity Test
Ask the candidate to explain a technical concept from their work in a way that you, as a non-technical person, can follow. This is not a gotcha – it's a genuine competency test.
Good developers can simplify without becoming inaccurate. Someone who can't do this either lacks deep understanding or can't communicate for different audiences – both matter in day-to-day work.
Ask About Failure
"What was the hardest technical problem you've ever faced, and how did you handle it?" is one of the most revealing questions in any interview. Authentic answers show self-awareness and problem-solving ability. Evasiveness – or projecting an image of someone who has never had real difficulties – is a signal worth noting.
The same logic applies to: "Tell me about a project that didn't go as planned. What was your part in that?"
Questions About Collaboration and Handover
Technical competence isn't only about writing code. In most companies, developers work alongside QA, design, product, and sometimes directly with clients. Questions like "How do you ensure that others can understand and build on your code?" or "How do your deployments typically work?" give insight into professionalism and team mindset – regardless of your own technical knowledge.
What You Still Can't Replace
These questions help you spot obvious gaps and assess candidates as people. What they can't do: provide a qualified view of technical depth. Whether someone writes solid code, makes sound architecture decisions, or sets the right technical priorities – that cannot be fully determined from a conversation alone.
For that level of assessment, you need someone with experience in the relevant domain – someone who can probe the candidate on substance, whether through a review of prior work or a practical assignment.
Key Takeaways
- Why-questions reveal more depth than what-questions
- The simplicity test: good developers can explain things without jargon
- Failure questions reveal self-awareness and experience
- Collaboration questions reveal professionalism
- Technical depth needs a technical conversation partner