Running a cyber technical interview without being an expert

Many managers have to hire a security profile without mastering the technical side themselves: IT directors, operations leads, SME founders or HR managers. The risk is well known: the interview turns into a pleasant conversation that leaves you with an impression, not with evidence. This guide gives you a simple interview outline, questions that need no expertise to ask, and a way to decide on facts.

What you can judge, and what you can't

Start by being honest about your scope. Without security expertise, you cannot check that a command is right or that an architecture holds up. You are, however, perfectly able to judge many things that matter just as much.

You can judge on your own	You need technical support
Clarity of reasoning and ability to explain	Whether a specific technical answer is correct
Consistency between the CV and what the person tells you	Real depth on a tool or a domain
Ability to prioritise by business risk	Quality of a technical deliverable (report, rule, script)
How they talk about their mistakes and limits	Level compared with the market for a specialist role
Fit with your context and resources	Whether a tool or architecture choice makes sense

The left column is a good half of the decision. The right column is handled with a hands-on exercise and a practitioner's eye, not with questions improvised during the interview.

Prepare before you meet the candidate

A structured interview is won beforehand. An hour of preparation stops you from comparing candidates on different criteria.

Describe three real situations from the role. For example: "an alert fires on a Friday evening on an admin account", "a client demands answers to a security questionnaire within a week", "management wants to roll out a new SaaS tool quickly".
Pick four or five criteria to assess, no more: reasoning, prioritisation, communication, autonomy, honesty about limits.
Write the questions in advance and ask every candidate the same ones.
Define what a good answer looks like for each question, in a few words.
Split the roles if there are two of you: one asks, the other takes factual notes.

If the situations feel vague when you write them down, the job description usually is too. Our SOC analyst job description template shows how to describe a role through its concrete tasks.

The five-part outline

Allow about an hour. The outline stays the same from one candidate to the next; only the follow-ups change.

1. Opening and framing (5 minutes)

Explain how the interview will run, the team's context and what you expect. Say plainly that you are not an expert and that you expect accessible explanations. That is already a test: a good profile knows how to adjust their message.

2. One project, in depth (15 minutes)

Ask the candidate to pick a project or incident they are proud of, then stay on it. One topic explored in depth beats five skimmed. You are looking for what they did themselves, not what the team did.

3. A scenario based on your context (20 minutes)

Present one of your three situations and let the candidate reason out loud. Do not look for the exact answer: watch the approach. Do they ask questions before acting? Do they separate urgent from important? Do they know who to alert?

4. Limits, mistakes and learning (10 minutes)

Ask about a past mistake, a topic they have not mastered yet and how they keep up to date. In security, being able to say "I don't know, here is how I would check" is a professional quality.

5. Their questions and next steps (10 minutes)

The candidate's questions say a lot about what matters to them: resources, reporting line, on-call duties, room to act. Close by explaining the next steps and a response time you will actually meet.

Follow-up questions do the heavy lifting

Without expertise, your best tool is not the technical question: it is the follow-up. It separates someone who has done the work from someone who has read about it.

"What did you do yourself, specifically?"
"Why that choice rather than another?"
"What made you change your mind along the way?"
"How did you know it was fixed?"
"If you did it again, what would you change?"
"How would you explain it to our CFO?"
"What could have gone wrong?"

An experienced practitioner answers three or four successive follow-ups with increasingly precise detail: a system name, a constraint, a trade-off, a mistake. A rehearsed story runs out of steam quickly and falls back on generalities.

Warning signs and good signs

Write down facts, not impressions. The signals below are observable without technical knowledge.

Warning sign	Good sign
"We" always replaces "I"	The candidate clearly separates their part from the team's work
Answers pile up tool names	Answers start from the problem, then get to the tools
No mistake, no limit acknowledged	A mistake described along with what they learned
Solutions before understanding the context	Questions about your context before proposing anything
Jargon that does not simplify when you ask	A clear explanation, with an analogy if needed
Everything is critical, everything is urgent	A justified ranking of risks

Watch out for a common bias: fluency is not competence. A reserved candidate can be excellent, especially for highly technical roles. One more reason to rely on the scorecard rather than on gut feeling.

Bring in a technical eye at the right time

A structured interview does not replace technical verification; it complements it. Organise that verification so it does not stretch the process.

A short hands-on exercise, realistic and fictional, to watch the candidate at work. Our article on assessing skills beyond the CV explains how to design and score it.
A security practitioner to design the exercise, review the deliverable and run a focused technical conversation. That can be a peer from another company, a trusted provider or a specialist firm.
A cross review: each person scores on the scorecard separately, then you compare before discussing.

For roles where you want precise technical questions, our role-specific guides can give the practitioner a starting point: pentester interview questions or incident response analyst interview questions.

Decide with a simple scorecard

Right after the interview, before discussing it with anyone, score each criterion from 1 to 4 with an observed fact to back it up.

Criterion	What you score	Example of a fact to record
Reasoning	Structured approach, explicit hypotheses	"Asked about the scope before proposing anything"
Prioritisation	Link between action and business risk	"Dealt with the privileged account first"
Communication	Clarity, adapted to the listener	"Explained ransomware without jargon"
Autonomy	Moving forward without complete instructions	"Ran a security assessment alone in their last role"
Honesty	Acknowledging limits	"Said they didn't know our tool and explained how they would learn it"

Decide the expected threshold and the non-negotiable criteria in advance. A high communication score does not make up for missing prioritisation in an operational role.

Mistakes to avoid

Improvising questions from one candidate to the next, which makes any comparison impossible.
Asking technical questions whose answers you don't understand: you won't be able to judge them.
Hiring on gut feeling after a smooth conversation.
Adding interview rounds to make up for a lack of method. A long process loses the best profiles.
Forgetting to inform the candidate: in France, recruitment methods must be relevant to the role and disclosed to the candidate beforehand, as the Labour Code sets out on legifrance.gouv.fr.

In short

You do not need to be an expert to run a good technical interview. You need real situations, prepared questions, follow-ups that dig, and a scorecard filled in straight away. Pure technical verification belongs to a hands-on exercise and a practitioner. Together, the two perspectives give you a sound decision you can explain.

Hiring a security profile without security expertise in-house? At Cyber Recrut, a recruiter and a security practitioner run every search, and our shortlisted candidates prove their skills on hands-on labs before you meet them. See how we work or tell us about your hiring need.