Last updated: September 16, 2026
By Robert Ardell, Co-Founder and Strategic Advisor, KORE1
The penetration tester interview questions that predict the hire put a live target in front of the candidate, ask who authorized their last test, and make them explain one finding in writing. Certifications and clean trivia answers tell you almost nothing. A candidate can recite the five phases of a test, define union-based SQL injection, and name every tool in Kali, then spend a paid engagement running a scanner and pasting its output into a report nobody can act on.
Search this exact phrase and you get a hundred lists written for the person being interviewed. Memorize the CIA triad. Define cross-site scripting. Name the ports. Reciting all of it is precisely what a mediocre tester does right before they launch a scan and read you the results.
This page is written for the other side of the table. The hiring manager, the security lead, the founder who knows they have an exposure and does not yet know how to tell a real operator from a report generator.
A word on where I sit, because it colors everything below. KORE1 runs offensive security searches through our penetration tester staffing desk, inside the firm’s IT staffing services group, and I have spent two decades in the recruiter’s chair watching this hire go right and wrong. Our invoice only lands when a client hires a person we sent. The advice here is free. Take the questions, run the exercise, hire the tester yourself if you can. Screening for the wrong skill drains a budget whoever ends up running the search.
Last quarter a fintech in Austin ran a candidate through four rounds for a senior web app tester. OSCP on the resume, CEH under it, a clean whiteboard session on the OWASP Top 10, a culture interview everyone liked. They almost signed. Then he got on our live box, ran Burp’s active scanner, took what it flagged, and wrote it up. The scanner missed the thing that mattered. An authorization flaw, where changing one ID in a request pulled a different customer’s records. A curious junior finds that in twenty minutes. He never went looking. One hour of watching him work caught what four interviews had missed.
Sort the Slate by Attack Surface First
“Penetration tester” is a job title stretched across work that barely overlaps. A web app specialist and a red team operator share a vocabulary and almost nothing else day to day. Run one generic loop against all of them and you reward the candidate who studied the widest, not the one who can do your actual work.
So start here. Write down the surface this person will spend most of their time attacking. Then pick the row and ask the question next to it. The wrong answers sort themselves out fast.
| What They Mostly Attack | The Question That Sorts the Slate | What a Real Answer Tends to Mention |
|---|---|---|
| Web and API applications | Show me the last bug you found that no scanner would have caught. | An access-control or logic flaw, a chained request, why the automated tool walked past it |
| Internal network and Active Directory | Walk me from a single low-privilege foothold to domain admin. | Kerberoasting, a misconfigured ACL, BloodHound paths, why they picked one route over a louder one |
| Cloud (AWS, Azure, GCP) | You have read access to one over-permissioned role. Where do you go? | IAM privilege escalation, a public storage bucket, metadata service abuse, an assumed-role chain |
| Red team and adversary simulation | Tell me about an engagement where your first plan failed and you adapted. | Detection they tripped, an EDR they had to evade, the part of the op that did not work |
| Mobile and hardware | What did you have to pull apart physically or decompile to get in? | A stripped binary, a hardcoded key, a debug interface, certificate pinning they had to defeat |
If two rows fit the opening, that is usually two roles, or one role plus a scoped engagement to cover the rest. Say the surface out loud on the intake call. It shortens the search more than any clever question does. Still deciding between a staff hire and a one-off test? Our how to hire a penetration tester guide lays that decision out in full.
The Core Five, Whatever the Surface
These do not care about the surface. A web specialist, an AD operator, and a red teamer should all have real answers, and a weak answer looks about the same in every one of them.
Your on-site contact is out sick and the written scope is thin. You are standing in front of the target. Now what?
This is the most revealing question on the page, and almost no candidate-prep list includes it. The right first move is not a technique. It is a refusal to touch anything until authorization is clear.
You want to hear about rules of engagement, a signed statement of work, a named escalation contact, and a hard stop when any of those are missing. A candidate who shrugs and starts testing is a liability wearing a hoodie. There is a real case every offensive professional knows. In 2019, two Coalfire testers were hired through Iowa’s State Court Administration to assess courthouse security, and they were arrested and held for nearly twenty hours after the county read the scope differently than the people who signed it. The charges were dropped. The county settled for $600,000 in early 2026, more than six years later. Authorization is not paperwork. It is the difference between a test and a crime, and a tester who treats it casually will one day treat your production database casually too.
The scanner comes back clean and the client thinks they are done. Are they?
No. That is the whole answer, and how they explain the “no” is the signal.
Strong testers describe the ratio without prompting. A scanner finds the front door. A person finds the window nobody documented, the trust between two services that each look fine alone, the workflow that lets step three fire without step two. Real testing is mostly hands and judgment. The tool is the opening move, not the game. If someone frames their whole process as launch the scanner, read the output, ship the report, thank them and keep looking. That is a report generator, not a tester.
Walk me through a finding you chained from low severity into a full compromise.
Anyone can file a list of medium-severity issues a tool spat out. The seniority shows up in chaining. An open redirect plus a token in a URL plus a lax cookie policy is three yawns on a scanner report and one account takeover in the hands of someone good.
Listen for a coherent attack path, not a pile of CVEs. Ask why they picked that route. Ask what they skipped. The tester who can tell you which findings they chose not to chase, because the real risk lived elsewhere, is the one you want scoping your next engagement.
Show me a sanitized report, then explain that same finding to a CFO.
The report is the product. It is the one artifact most of your organization will ever see. A brilliant exploit written up so badly that no developer can follow the steps just sits on a page, and the hole stays open for the next real attacker.
Every credible tester has a sanitized sample with client details stripped. Read it for the writing, not the vulnerabilities. Can a developer reproduce the finding from the steps given? Does it translate risk into money and consequence, or does it paste a CVSS score and a stock remediation blurb and move on? Then make them do it live. Hand them one finding and ask them to explain it to a non-technical executive in a minute. The ones who can are worth more than the ones who only pop shells, every single time.
When did you decide not to exploit something?
Judgment. This question finds it or it does not.
A production environment is not a lab. There is a moment in real engagements where a tester proves a vulnerability exists without detonating it, because dumping the whole table or crashing the service would hurt the client more than the finding is worth. Testers who have actually worked in production talk about blast radius, about calling the client before escalating a critical at 11 p.m., about documenting the path instead of walking all the way down it. Testers who have only played in CTF labs tend to look puzzled by the question. That look tells you a lot.
OSCP, OSCP+, and the Alphabet After Them
A certification proves someone passed an exam on a given day. That is all it proves. Weight the hands-on ones, and stay skeptical of the multiple-choice kind.
The OSCP is still the practical baseline the market reads for, because clearing it means compromising machines under a 24-hour clock and then writing the whole thing up. Now the part almost nobody updating a req has caught. OffSec split the credential in late 2024. The classic OSCP does not expire. The newer OSCP+ does, three years out, and holders keep it current through continuing education or a requalifying exam. So a posting that insists on a “current OSCP” is chasing something that was never a thing. An experienced tester spots that in about four seconds and reads the rest of your req more warily from there. If what you want is proof of recent practice, name the OSCP+. If recency does not matter to you, just write OSCP.
Past the baseline, a rough map that holds up across our searches. OSWE and GWAPT mean genuine web depth. OSEP points at evasion and post-exploitation. CRTO and CRTP turn up on capable red teamers. CREST matters if you hire into or sell into the UK, and it shows on more US resumes every year. Then the CEH, and every offensive hire you talk to will have a view on it. The exam is largely multiple choice, so it clears an HR keyword filter and stalls with the people who run the technical round. A CEH sitting next to real engagements the candidate can describe in detail is fine. A CEH sitting alone tells you nothing you were trying to learn. Do not screen a good tester out for lacking it, and do not wave anyone through on it. Our penetration tester job description template carries the full posting language, including that OSCP line most reqs get wrong.
Make Them Touch a Live Box
A short hands-on exercise beats an hour of question-and-answer. It is also the single most reliable filter we run, and the one no amount of candidate-prep content helps anyone fake.
Stand up a deliberately vulnerable target, or agree together on a machine from a platform like Hack The Box or TryHackMe, and then watch how the person actually works. Web candidates get sixty minutes to find three bugs and write up two with reproduction steps. Network candidates get an internal Active Directory walkthrough and have to enumerate, find the misconfiguration, and explain Kerberoasting as though your CTO were in the room. Cloud candidates trace a real attack path, say a public bucket to an assumed role to data they should never reach. We frame the whole thing against NIST Special Publication 800-115, the federal technical testing guide, so the conversation uses the same four-phase vocabulary your own security team does: planning, discovery, attack, reporting.
What you are grading is not whether they finish. It is what they do when the easy way in is shut. Reach for something manual when the tool comes up empty, or freeze? We turned down a candidate with an immaculate resume last quarter on the AD exercise alone. The paper said senior. The work said junior. That gap is the whole point, and no keyword scan of a resume will ever surface it.
Testing With AI, and Getting Fooled by It
Ask what role AI plays in how they test, and where it steers them wrong. The answer separates people who have folded the new tooling into real work from people performing familiarity with it.
This is not academic anymore. In June 2025, an autonomous system called XBOW reached the top of HackerOne’s US leaderboard, out-submitting thousands of human researchers, though its own team reviewed the findings before submission and a large share sat unresolved or duplicated. Read that carefully. The machine is astonishing at breadth and volume. It is also confidently wrong a lot of the time. It still needs a person to judge what is real, what is noise, and what would actually hurt the business. A strong candidate will tell you they use large language models to speed up recon, draft a tricky payload, or explain an unfamiliar protocol, and that they verify every single thing the model claims, because it will invent a plausible CVE or a confident wrong exploit without blinking. If a candidate either dismisses AI entirely or treats its output as gospel, both answers should worry you.
The flip side matters too, and it belongs in the loop if your applications use LLMs. Prompt injection sits at the top of the OWASP Top 10 for LLM Applications for the second edition running. A tester who will be near your AI features should be able to explain how a hidden instruction in a document the model reads becomes an attack. If they cannot, that is a scoping gap you want to know about before the offer, not after.
Cloud and APIs Rewrite the Question Set
The generic network loop gets pointed at maybe half the openings that reach us tagged “cloud pen tester.” Adjacent skill set. Not the same one.
In the cloud, the incident almost always starts at identity, not at a port. Ports barely matter here. Ask a cloud candidate how they would escalate from an over-permissioned role, and listen for whether they know the provider’s rules of engagement cold. On AWS, for instance, customers can test a defined list of their own services without asking first, but command-and-control, denial-of-service simulation, and red team exercises require a submitted Simulated Events form and advance approval. A tester who does not know that will either get your account flagged or refuse to do work that was actually allowed. Both cost you.
For APIs, the question is authorization, over and over. The single most common serious API bug is broken object level authorization, where an endpoint hands back another user’s object because it never checked ownership, and it sits at number one on the OWASP API Security Top 10. Ask a candidate how they hunt for it. The good ones describe swapping IDs methodically and watching what comes back. The 2025 refresh of the main OWASP Top 10 is worth a candidate knowing too, since it folded server-side request forgery into broken access control and added software supply chain failures as its own category. If your team hires cloud-first, our cloud security engineer interview questions go deeper on the defensive half of that seat.
How Long the Loop Runs, and the Band Behind It
Keep the loop short. The strong offensive testers are juggling two or three offers at once and off the market within a month, so a five-round gauntlet hands the best of them to whoever moved faster and paid ten grand less. Our IT desk averages about seventeen days from open req to signed offer, and that speed is most of the game. Match rounds to the level. Put the live exercise early, before you burn everyone’s calendar on a candidate the box would have sorted in an hour.
| Level | Rounds That Make Sense | Typical Base (2026) |
|---|---|---|
| Junior / Associate | Screen, one live box, a manager chat | $80,000 to $105,000 |
| Mid-level | Screen, live exercise, report review, team fit | $110,000 to $140,000 |
| Senior | Screen, deeper exercise, scoping conversation, leadership | $140,000 to $180,000 |
| Lead / Principal / Red team | Exercise, program design, executive briefing | $175,000 to $220,000+ |
Those are base numbers. Senior operators with real exploitation behind them clear $200,000 in total pay, and specialists on elite product-security teams or cleared work sit higher again. The Bureau of Labor Statistics keeps no line item for penetration testers, so it files them under information security analysts, which reported a 2024 median of $124,910, a top tenth above $186,420, and 29% projected growth through 2034. Treat that bucket as a floor the whole field rests on rather than a pentest figure, because offense pays a premium over it the moment someone can prove they exploit and chain rather than scan. Our penetration tester salary guide splits the bands out by level, city, and specialty, and you can test one against your own market with the salary benchmark assistant before you take a number into a budget conversation.
What First-Time Buyers Ask Us
Our panel has never done offensive work. Can we even run this loop?
Borrow a tester for the technical round. A trusted contractor, an engineer you know at another company, an advisor, even one paid hour from a senior operator. Your own people can read communication, reasoning, and whether the room will actually respect this hire. What they cannot catch is a soft answer on chaining or authorization, and that soft answer is the one that tells you how the first six months go.
Is a live hacking exercise fair, or should it be a take-home?
Live, and keep it to an hour. A take-home measures who had a free weekend, and the strongest testers, the ones already juggling offers, tend to decline them. Watching someone work a target in real time shows you how they think when a tool comes up empty, which is the entire job. Give them a machine you both agree on and let them drive.
The candidate has an OSCP. Can we skip the technical round?
No. The OSCP proves they compromised lab machines under a clock at some point, which is worth real weight, but it says nothing about how they handle your production environment, your report readers, or a scope that goes sideways. Treat every certification as a reason to interview, never as a reason to skip the interview.
How do we test for AI-assisted testing without it turning into a gimmick?
Ask how they already use it and what it gets wrong for them. You are not looking for a demo. You want to hear that they lean on AI for recon or payload drafting and then verify everything it produces, because the models fabricate confident, plausible, wrong answers. Someone who has genuinely integrated the tooling can name a specific time it misled them.
Should we let candidates use AI tools during the live exercise?
Allow it and watch how they use it. Banning it tests a world that no longer exists, since your hire will use these tools on day one. The signal is whether they drive the model or the model drives them. A strong candidate uses it to move faster on the boring parts and still makes their own call on what is real.
Project engagement, contract-to-hire, or a full-time offensive hire?
A scoped engagement fits a one-time test with a clean deliverable. Contract-to-hire suits a need you are still sizing, where sixty to ninety days of real work tells you what no loop can. A permanent role that owns your whole testing program should be a direct hire. We place all three ways. Our twelve-month retention runs past ninety percent, and that comes from sizing the arrangement to the work rather than forcing the work into an arrangement.
Put a Real Target in Front of Them
This year’s exploits are a two-week study. The part you cannot compress like that is judgment. Finding the flaw the scanner skipped. Stopping before you break production. Writing the finding up so a developer actually closes it. Build the loop around those three, and let a live box sort what a resume never could.
If you are opening an offensive security search and the finalists have started to run together on paper, that sameness is the problem we solve for a living. Pull in a KORE1 recruiter before you widen the net any further, and we will say plainly whether the search needs us or just needs a sharper loop. Either answer costs nothing. When you are ready, reach out to our team. Not sure of the shape yet? Our cybersecurity staffing practice and the security engineer interview questions guide cover the defensive, build-the-thing side of the house. And the same role can start as a contract engagement or land as a direct hire, once you know which one it is.
