Cybersecurity interview questions

Security interviewers characteristically take a simple question and keep going deeper. What is TLS becomes how does the handshake work becomes what does the certificate actually prove becomes what happens if a certificate authority is compromised.

This is deliberate. It is not about reaching a specific fact but finding where memorisation ends and understanding begins. Everyone hits that point; the assessment is partly what you do when you reach it.

The right response is to say plainly what you know, what you do not, and how you would find out. Candidates who bluff are identified immediately and it is disqualifying, because a security professional who invents confident answers is a genuine liability.

These come up in nearly every interview regardless of specialisation, because they underpin everything else. Vague answers here are hard to recover from.

Prepare to explain each to a non-specialist as well as technically. Communicating risk to people who are not engineers is a substantial part of the job, and interviewers are listening for whether you can do it.

The most reliable preparation is explaining each one out loud without notes. Concepts that feel solid while reading frequently collapse two levels into an explanation, and finding that out alone is far better than finding it out in the room.

• Authentication versus authorisation, stated crisply
• How TLS establishes trust, and what a certificate does and does not prove
• Symmetric versus asymmetric cryptography, and where each is used
• Hashing versus encryption, and why passwords are hashed with a salt
• Common web vulnerabilities and the mechanism behind each
• How DNS works, since it appears in so many attack paths

You will be given an incident — a workstation showing unusual outbound traffic, credentials found in a public repository — and asked what you would do. The assessment is method rather than a specific correct answer.

Strong answers establish scope before acting, and consider evidence preservation before containment destroys it. Weak answers jump immediately to wiping the machine, which resolves the symptom and destroys the ability to understand what happened.

Say your reasoning aloud rather than delivering conclusions. The interviewer cannot assess a method they did not hear, and a candidate who narrates the trade-off between containing quickly and preserving evidence is demonstrating exactly what the question is for.

• What is the scope — one machine, or a pattern across many?
• What evidence would be lost if I act now?
• Contain first or investigate first, and what justifies the choice?
• Who needs to be informed, and when?
• What would tell me the incident is genuinely over?

Expect something like: the business wants to ship a feature you consider insecure, and the deadline is fixed. This tests whether you can work with an organisation rather than issuing prohibitions.

The answer interviewers want articulates the risk in business terms, offers options with different cost and residual risk, and accepts that the decision belongs to the business once it is properly informed. Security professionals who cannot do this get excluded from decisions, which makes them ineffective regardless of technical skill.

Add that you would record the decision and revisit it. Accepting a risk with a written owner and a review date is a completely different thing from accepting it silently, and naming that distinction shows you have worked somewhere real.

You will be asked how you keep current. This is a real question in security, where the landscape shifts continuously, and a vague answer about reading news suggests you do not.

Answer specifically: named sources you actually follow, a recent vulnerability you looked into and what you concluded, a lab exercise you worked through. Specificity is the whole signal here, and it is easy to prepare honestly.

The strongest version includes a conclusion rather than a summary. Saying that you looked into a recent vulnerability and decided it did not affect your environment, and why, demonstrates the analytical step that matters rather than the reading.

If the role touches AI systems, expect prompt injection to come up. The answer that lands treats it as an architectural problem — the model can be influenced by any text it processes, so the control must be what the system is permitted to do — rather than a filtering problem.

Being able to distinguish direct from indirect injection, and to explain why the indirect kind is harder to defend because the malicious content arrives through a trusted-looking channel, marks you out in a field where most candidates have read one article.

It also helps to connect it back to ordinary security. An over-scoped credential on an agent is broken access control, and generated output rendered without escaping is an injection sink like any other — framing it that way shows the AI layer sits on top of fundamentals rather than replacing them.

Depth beats breadth. Two topics you can discuss to genuine depth serve you better than twenty you can define, because the why-ladder will expose the difference within a minute.

Prepare one incident story in detail — something you investigated, in a lab if not at work — covering what you saw, what you ruled out, and what you concluded. That single story answers a large share of both technical and behavioural questions.

Include what you got wrong in it. An account that mentions a hypothesis you pursued and eliminated is far more credible than one where every step was correct, and it demonstrates the elimination process the job actually consists of.