Application Security Engineer interview questions and how to answer them
AppSec interviews test two things at once: can you find the bug, and can you get a developer to fix it without a fight. Expect a live code review, a threat modeling exercise and a lot of questions about how you've worked with engineering teams. The candidates who do well talk like builders who happen to think like attackers.
What happens in each round
- 1
Recruiter screen
What happens
Whether your background is code-heavy or ops-heavy, which languages you read comfortably, and whether you've owned security tooling or only consumed its output.
- 2
Hiring manager conversation
What happens
How you prioritize across many teams, how you've handled pushback from developers, and whether you'd fit a security champions model or a central review queue.
- 3
Secure code review exercise
What happens
You get a snippet or a small repository, often in Python, Java or JavaScript, and walk through what's wrong. They watch your process as much as your findings.
- 4
Threat modeling or design review
What happens
They describe a feature, such as a file upload service or a new login flow, and ask you to find the risks and propose controls out loud on a whiteboard or shared doc.
- 5
Team and cross-functional panel
What happens
Engineers from product teams judge whether they'd want you reviewing their pull requests. Tone, clarity and willingness to accept tradeoffs carry this round.
Questions you're likely to get
1.Walk me through how you'd review this code for security issues.
Why they ask
This is the core skill of the job. They want to see whether you have a method or just scan for keywords.
How to answer
- Start by finding where untrusted input enters: request parameters, headers, file uploads, message queues
- Trace that input to sinks such as database queries, shell calls, template rendering and redirects
- Check authorization on every action, not just authentication at the front door
- Name each finding with its impact and a concrete fix in the same language
- Say what you'd want to check outside the snippet, like framework defaults or middleware
2.How would you threat model a new feature that lets users upload profile pictures?
Why they ask
Upload features hide several classic bugs, and the question shows whether you think in data flows or in checklists.
How to answer
- Sketch the flow: browser, API, storage bucket, image processing, delivery to other users
- Call out risks at each hop: oversized files, content-type spoofing, malicious image parsers, stored cross-site scripting through SVG, public bucket exposure
- Propose controls with a cost in mind: re-encode images server side, serve from a separate domain, signed URLs, size limits
- Rank what you'd insist on before launch versus what can follow
3.What's the difference between SAST, DAST and software composition analysis, and when do you rely on each?
Why they ask
You'll likely own at least one of these tools. They want to know you understand their blind spots.
How to answer
- Static analysis reads source and catches patterns early, but it's noisy and misses logic flaws
- Dynamic testing hits the running app and finds real exploitable issues, but coverage depends on what it can reach
- Composition analysis flags vulnerable dependencies, and the hard part is judging whether the vulnerable function is even called
- Give an example of tuning one of them, such as writing a custom Semgrep rule or suppressing a noisy CodeQL query
4.A developer pushes back and says your finding isn't exploitable. What do you do?
Why they ask
Friction with engineering teams is where AppSec programs fail. This checks your temperament.
How to answer
- Assume they might be right and ask what control they think stops it
- Reproduce it or write a short proof of concept if you're confident
- If it's truly not exploitable today, say what would make it exploitable later and agree on a severity
- Offer the fix yourself when it's small, and write the decision down
5.Explain broken object level authorization and how you'd find it in an API.
Why they ask
Access control bugs are some of the most damaging API flaws, and scanners rarely catch them.
How to answer
- Define it plainly: a user can read or change another user's record by changing an ID
- Find it by testing with two accounts in Burp Suite and swapping identifiers
- In code, look for handlers that fetch by ID without checking ownership or tenant
- Fix it with a central authorization check or a query scoped to the current user, not scattered if-statements
6.How would you get security checks into our CI/CD pipeline without slowing teams down?
Why they ask
Most AppSec teams are small compared with engineering. They need someone who scales through automation.
How to answer
- Start in report-only mode so you can measure noise before blocking anything
- Only fail builds on high-confidence, high-impact rules, like hardcoded secrets or known-bad patterns
- Put findings inside the pull request, not in a separate dashboard nobody opens
- Track how often developers suppress a rule and fix the rule when it's wrong
7.Tell me about a vulnerability you found that you're proud of.
Why they ask
They want real depth and to hear how you explain root cause.
How to answer
- Set up the context briefly: what the app did and where you were looking
- Explain the root cause, not just the symptom
- Describe the impact honestly without inflating it
- Say how it was fixed and whether you prevented the same class of bug elsewhere
8.How do you handle secrets that end up committed to a repository?
Why they ask
It happens constantly, and the right response is more than deleting the line.
How to answer
- Rotate the secret first, because git history and forks keep it alive
- Check logs for any use of the credential while it was exposed
- Add secrets scanning in pre-commit hooks and in the pipeline
- Move the team to a secrets manager so the pattern doesn't repeat
9.How would you build a security champions program?
Why they ask
Many teams want AppSec to scale through developers, and this tests whether you've thought about incentives.
How to answer
- Pick volunteers with credibility on their own teams, not whoever has free time
- Give them something real: early access to tools, office hours, a say in rule tuning
- Keep asks small, such as reviewing security-tagged pull requests
- Get their managers to count the work in performance reviews
10.What would you do in your first few weeks here?
Why they ask
They're checking whether you'd listen before changing things.
How to answer
- Inventory the main applications and who owns them
- Read recent incident reports and bug bounty submissions to learn where it actually hurts
- Meet engineering leads and ask what security currently slows down for them
- Pick one visible, low-friction win before proposing bigger changes
11.Tell me about a time you accepted a risk instead of blocking a release.
Why they ask
Security people who can never say yes get routed around. They want judgment.
How to answer
- Describe the finding and why the deadline mattered to the business
- Explain the compensating control you put in place, like a feature flag or extra logging
- Show that the risk was written down with an owner and a follow-up date
- Say what happened afterward
Mistakes that sink good candidates
Talking about developers as the problem
Your interviewers include developers.
Naming tools without explaining a decision you made with them
Rating every finding critical
It tells them you can't prioritize.
Freezing on the code exercise instead of talking through your thinking as you read
Need more Application Security Engineer interviews to prep for?
HeroApply applies to Application Security Engineer jobs that match you, every day. 134 jobs are open today.