Pentester interview questions: a practical grid

An interview with a pentester easily turns into a swap of tool names, and you leave without knowing whether the person can actually run a penetration test. Vocabulary takes a few weeks to learn; method, judgement and the quality of the deliverable take far longer. Below is a set of questions organised by theme, with what a good answer contains and the signals that should worry you.

Before the interview: decide what you are assessing

A useful grid starts from the role, not from a generic list. Settle three things before you meet the first candidate:

• The setting: an in-house team that always tests the same estate, or a consultancy running engagements for varied clients?
• The main scope: web applications and APIs, internal network and Active Directory, cloud, mobile?
• The expected level: a junior whose work is reviewed by a lead, or a senior who can run an engagement from scoping to debrief?

If these points are still open, start with our guide to hiring a pentester, then the pentester job description. A grid built on a vague need compares candidates on criteria that do not matter.

Also decide who will ask the technical questions. A peer who practises pentesting will dig deeper where a generalist recruiter would stop. If nobody in-house can do it, the section for non-technical recruiters below gives you something to hold on to.

Methodology and rules of engagement

"I hand you the test of a web application exposed to the Internet. Walk me through your first hours."

A good answer starts before any technical action: checking the written scope, test windows, emergency contacts and the accounts provided. Then come reconnaissance, mapping the features and systematic note-taking.

Red flag: the candidate fires up a scanner in the first minute and never mentions the rules of engagement.

"What do you do if you find an interesting server outside the authorised scope?"

You want an answer without hesitation: do not touch it, report it to the client and wait for written approval before going further.

Red flag: "I'd just take a quick look anyway."

"During a test, you come across real personal data. What do you do?"

The candidate should talk about minimisation (extract no more than needed to prove impact), secure storage of evidence, deletion at the end of the engagement and a prompt alert to the client when the situation calls for it.

Technical questions by scope

Tailor this part to the role's scope. Three in-depth questions on the core of the job beat ten skimmed ones.

Web applications and APIs

"How do you test access control in an application with three user roles?"

Good answer: create or obtain one account per role, map what each can do, replay one role's requests with another role's session, test predictable object identifiers, and check enforcement on the server rather than only in the interface. The best candidates mention the APIs behind the mobile app, or forgotten older versions.

"Explain SQL injection to me as if I were a developer, then as if I were the CFO."

This two-part question measures real understanding and the ability to adapt. The developer version should cover queries built by concatenation and parameterised queries; the executive version should cover exposed data and consequences.

Internal network and Active Directory

"You are plugged into the internal network with no account at all. Where do you start?"

Expected: listening to and poisoning name resolution protocols, looking for services exposed without authentication, open shares, default credentials, authentication relaying. A good candidate says which of these actions can disrupt the network and must be announced first.

"You have a standard domain user account. How do you look for a path to domain admin?"

You want an approach: enumerating relationships and rights, looking for service accounts exposed to Kerberoasting, misconfigured delegation, passwords in scripts or shares, excessive rights on directory objects.

Red flag: a string of tool names with no ability to explain what each one exploits.

Cloud

"What are your first checks on a cloud account you are given?"

Good answer: identities and permissions (overly broad roles, old access keys), publicly exposed resources, secrets in variables or metadata, whether logging is enabled. The candidate should clearly separate a configuration review from a penetration test, and remember that cloud providers set rules on authorised testing of their platforms.

Exploitation and chaining

"Tell me about the vulnerability you are proudest of."

This is often the most revealing question. Listen for precision: how the lead appeared, what failed, how the proof was built, what impact was shown. Probe the details; a lived story holds up under follow-up questions, a borrowed one falls apart.

"Three low-severity vulnerabilities: how can they add up to a critical risk?"

You want the idea of chaining, with a concrete example. For instance, an information leak revealing a username, a weak password policy, then access to a poorly protected admin function.

"When do you stop exploiting?"

A mature pentester stops once the impact is proven, especially in production. They mention destructive actions to avoid, coordinating with the client before any risky step, and stopping at once if something unexpected happens.

Reporting and debriefing

The report is what the client keeps. This part of the interview is too often skipped.

"What does a good penetration test report contain?"

Expected: an executive summary, the scope and limits of the test, each vulnerability with its description, evidence, a justified risk level and a concrete recommendation, and finally a prioritised remediation plan.

"A developer disputes your finding in a meeting. How do you react?"

You are looking for someone factual: replay the proof, listen to the argument (they are sometimes right about context), adjust the risk rating if needed, never accusatory.

If the candidate has an anonymised report, or one written on a training environment, ask for it. Writing quality is judged on evidence, not on claims.

Summary grid

Use the same grid for every candidate, filled in right after the interview.

Tips for non-technical recruiters

You do not need to know how to abuse Kerberos delegation to run a useful part of the interview.

1. Ask for real examples: "Last time, what exactly did you do?"
2. Follow up with "why": a practitioner justifies their choices, a candidate who recites runs out quickly.
3. Ask for a simple explanation: if they cannot explain it to you, they will struggle in front of an executive committee.
4. Notice where the rules come in: a good pentester raises authorisation and scope unprompted.
5. Do not judge on certifications alone: they prove learning, not practice. Our article on cybersecurity certifications explains what they are really worth.

What the interview does not measure

An interview measures reasoning, communication and judgement. It is a poor measure of the ability to find a real vulnerability alone, against the clock, in an unfamiliar environment. A short hands-on lab, on a deliberately vulnerable environment close to your scope, fills that gap. The discussion that follows ("why this lead, what did you drop?") is often richer than the interview itself.

Our guide to assessing cybersecurity skills explains how to design a fair exercise. On the candidate side, our article on passing a cybersecurity technical interview shows what a strong profile prepares.

In short

A good interview grid for a pentester covers rules and ethics, method, the technical side of your scope, controlled exploitation, reporting and debriefing. It favours lived examples and follow-up questions over lists of tools. Scored the same way for everyone and paired with a hands-on lab, it lets you decide on facts.

Hiring a pentester? At Cyber Recrut, a recruiter and a security practitioner run every search together, and our shortlisted candidates prove their skills on hands-on labs built around your scope. See how we work or share your hiring need.