Penetration Tester Interview Prep: Questions and a Mock Test

Interviewers open here more often than candidates expect, and a weak answer is disqualifying regardless of technical depth.

Authorisation is the whole basis of the work. Testing without documented, specific, current permission from someone with authority to grant it is not penetration testing. The scope document is the artefact that defines what is in bounds, and the discipline being assessed is whether you stop at its edge. A candidate who describes following a chain of trust out of scope because it was interesting has described an incident.

Rules of engagement cover the questions the scope document does not: test windows, whether denial of service is permitted, whether social engineering is in scope, what happens if you find evidence of an existing compromise, and who to contact when something breaks. The last two are the ones people forget. Discovering that someone else is already in the environment converts your engagement into an incident response, and the correct move is to stop and escalate rather than to investigate.

Evidence handling matters too. You are collecting proof of exploitability, not extracting data, and the amount of data you touch should be the minimum that demonstrates the finding. Screenshotting one record establishes access; downloading the table does not establish anything additional and creates a real problem for both parties.

Expect a question about a finding outside scope. The answer is to report it, not to test it.

MITRE ATT&CK is the common language for describing what an adversary does, and interviewers use it to check that you think in terms of a campaign rather than a list of exploits.

The enterprise matrix currently lists fifteen tactics, each phrased from the adversary's point of view. Reconnaissance is "the adversary is trying to gather information they can use to plan future operations", and Resource Development is "trying to establish resources they can use to support operations". Then Initial Access, "trying to get into your network", Execution, "trying to run malicious code", Persistence, "trying to maintain their foothold", and Privilege Escalation, "trying to gain higher-level permissions".

One detail worth being current about: the tactic at TA0005 is now named Stealth, described as "the adversary is trying to hide and conceal their actions, appearing as normal behavior", and there is a separate tactic, Defense Impairment, for when "the adversary is trying to break security mechanisms, pipelines, and tooling so defenders can't see or trust what's happening". A great deal of published material still names TA0005 Defense Evasion, so quoting the current framing accurately is a small, visible signal.

The remainder: Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact.

The reason this matters in an interview is that it turns a finding into a narrative. Saying you found an exposed service is a finding; saying it provides initial access, that stored credentials on the host enable credential access, and that those credentials permit lateral movement to a system holding the data the client actually cares about, is an assessment.

The OWASP Web Security Testing Guide is the methodology reference most often named, described as "a comprehensive guide to testing the security of web applications and web services". Its stable release is version 4.2, published in December 2020, with version 5.0 in active development, and its tests are identified by category codes such as WSTG-INFO for information gathering.

What interviewers want is not the code list but the structure: information gathering first, then configuration and deployment, identity and authentication, authorisation, session management, input validation, error handling, cryptography, business logic, and client side.

The two categories that produce the most interesting interview conversation are authorisation and business logic, because neither is found by a scanner. Authorisation flaws are the top-ranked category in the OWASP Top 10 2025, where broken access control remains A01, and the characteristic form is an object reference that the server does not check against the authenticated user. Testing it is systematic rather than clever: enumerate every endpoint that takes an identifier and try it as a different user, as a lower-privileged user, and unauthenticated.

Business logic flaws are where the application does exactly what it was built to do and the outcome is still wrong: a negative quantity that credits an account, a multi-step flow where a step can be skipped, a coupon that can be applied repeatedly. Finding them requires understanding what the application is for, which is why the strongest testers ask about the business before touching the application.

The 2025 list is worth knowing in order, since supply chain failures now rank third and injection has moved to fifth.

Infrastructure testing questions are less about scanning and more about what you do with what you find.

Discovery is where an interviewer checks that you understand the difference between what a tool reports and what is true. A port scan reports what responded, which is not the same as what is running, and version banners are frequently wrong or deliberately misleading. Confirming a service and its version before claiming a vulnerability is basic diligence, and reporting a finding purely from a scanner's output without validation is the most common failure in junior work.

Identity is where modern engagements concentrate, because most environments are now compromised through credentials rather than through memory corruption. Password reuse across systems, service accounts with excessive rights and passwords that never expire, credentials stored in scripts and configuration, and tokens with long lifetimes and broad scope are the recurring themes. The question interviewers like is what you would do first with one valid low-privileged credential, and the strong answer is enumeration of what that identity can reach rather than immediate escalation attempts.

Segmentation determines how far a foothold travels. A flat network turns one compromised workstation into access to everything, which is why lateral movement is the tactic that most often decides an engagement's severity rating.

The framing that separates a senior candidate: severity is a function of business impact, not of technical elegance. A dull misconfiguration that exposes customer data outranks an intricate chain that reaches a test server with nothing on it.

Almost every loop includes a question about writing, because the report is the only thing the client actually receives.

The structure expected is an executive summary written for someone who will not read the rest, expressed in terms of business risk rather than technique, followed by findings each with a clear description, evidence, reproduction steps, an impact statement and a specific remediation. Reproduction steps are the part that determines whether anything gets fixed: a developer who cannot reproduce a finding will deprioritise it, however severe it is.

Severity should be justified rather than asserted. A rating derived from exploitability and business impact, and stated with the reasoning visible, survives the meeting where a stakeholder disagrees with it. A rating copied from a scanner does not.

The judgement question that comes up repeatedly is what to do when a client disputes a finding or pressures you to lower a severity. The professional answer is to separate the facts from the rating: if the technical claim is wrong, correct it immediately and gladly; if the disagreement is about severity, document both positions rather than quietly changing the number. Accepting compensating controls as a reason to lower a rating is legitimate when the controls actually exist and you have verified them.

One more thing interviewers listen for: what you would tell the client to fix first. A report with forty findings and no prioritisation transfers the hard problem back to the people who hired you to solve it.