INTERVIEW TRACK
Application Security
01How do you prioritize vulnerabilities?
Combine exploitability, business impact, exposure, affected data, existing controls, and evidence. CVSS is an input, not the final decision. Explain the likely attack path and remediation urgency.
Interview tip: Add one example from your own testing, code review, or incident work.
02What is the difference between authentication and authorization?
Authentication establishes who the caller is. Authorization decides what that identity may do to a specific action or object. Test authorization on every server-side request, not only in the user interface.
Interview tip: Add one example from your own testing, code review, or incident work.
03How would you review a new API before launch?
Map assets and trust boundaries, review the schema, identify authentication and authorization decisions, test abuse cases and rate limits, inspect secrets and logging, then validate controls with negative tests.
Interview tip: Add one example from your own testing, code review, or incident work.
04When should a team use SAST, DAST, and SCA?
SAST finds source-level patterns early, DAST tests a running application from the outside, and SCA tracks vulnerable dependencies and licenses. They complement manual threat modeling and testing rather than replacing them.
Interview tip: Add one example from your own testing, code review, or incident work.
05How do you reduce security friction for developers?
Provide reproducible evidence, an actionable fix, a secure code example, clear ownership, and fast feedback in the existing workflow. Measure recurring root causes and improve paved-road components.
Interview tip: Add one example from your own testing, code review, or incident work.
06What makes an effective threat model?
It has a bounded scope, accurate data flows, assets and trust boundaries, realistic attacker goals, prioritized abuse cases, named controls, owners, and follow-up validation.
Interview tip: Add one example from your own testing, code review, or incident work.
INTERVIEW TRACK
Penetration Testing
01What do you do before testing starts?
Confirm written authorization, scope, excluded systems, test windows, data-handling rules, emergency contacts, rate limits, evidence requirements, and stop conditions.
Interview tip: Add one example from your own testing, code review, or incident work.
02How do you test for IDOR or BOLA?
Create at least two users with different ownership and roles. Replay object requests while changing identifiers and methods. Test read, write, delete, export, and nested resources. The server must enforce ownership each time.
Interview tip: Add one example from your own testing, code review, or incident work.
03How do you validate SSRF safely?
Use a controlled callback domain first, then permitted loopback or private targets. Record DNS and HTTP evidence, keep request volume low, and avoid cloud metadata unless scope explicitly permits it.
Interview tip: Add one example from your own testing, code review, or incident work.
04How do you handle a critical finding during an engagement?
Stop risky exploitation, preserve minimal evidence, verify the result, notify the agreed emergency contact, explain immediate containment, and continue only after direction from the client.
Interview tip: Add one example from your own testing, code review, or incident work.
05How do you avoid false positives?
Reproduce manually, use a negative control, identify the exact security boundary that failed, capture request-response evidence, and distinguish theoretical exposure from demonstrated impact.
Interview tip: Add one example from your own testing, code review, or incident work.
06What belongs in a pentest retest?
Verify the original path no longer works, test obvious bypasses and adjacent endpoints, confirm the root cause was fixed, check for regressions, and record the build or environment tested.
Interview tip: Add one example from your own testing, code review, or incident work.
INTERVIEW TRACK
Bug Bounty
01What makes a strong vulnerability report?
A clear title, affected asset, prerequisites, exact steps, request-response evidence, demonstrated impact, remediation advice, and a severity rationale aligned with the program policy.
Interview tip: Add one example from your own testing, code review, or incident work.
02How do you approach an unfamiliar target?
Read the policy, build an asset inventory, understand core workflows and roles, map parameters and APIs, identify high-value state transitions, and test hypotheses rather than running noisy tools blindly.
Interview tip: Add one example from your own testing, code review, or incident work.
03How do you demonstrate business-logic impact?
Show the broken invariant in the smallest safe proof: bypassing a limit, changing ownership, receiving an unauthorized benefit, or reaching an impossible state. Do not create avoidable financial or user harm.
Interview tip: Add one example from your own testing, code review, or incident work.
04How do you avoid duplicate reports?
Focus on new features and edge-case workflows, build target-specific notes, connect small observations into an attack path, and validate quickly before spending time on a polished report.
Interview tip: Add one example from your own testing, code review, or incident work.
05When should you stop testing a finding?
Stop when impact is proven, further action could affect real users or data, the program forbids the technique, or the next step crosses a trust boundary not in scope.
Interview tip: Add one example from your own testing, code review, or incident work.
06How do you communicate with a triager who disagrees?
Stay factual. Restate the violated security guarantee, provide a minimal reproducible test and negative control, map impact to program policy, and ask one precise question about the disputed assumption.
Interview tip: Add one example from your own testing, code review, or incident work.