The candidate who lists ten threats loses to the one who names the two that matter and explains why the other eight can wait. That habit, ranking risk instead of enumerating it, is what a security engineer loop is built to find. These interviews are rarely trivia contests about port numbers or cipher suites. Someone hands you a system, watches how you reason about the ways it breaks, and decides whether they would trust you to make a call at 2am with half the facts in front of you.
The shape of the loop depends on the flavor of the role, and candidates lose time by prepping for the wrong one. Product security and application security engineers get heavy threat-modeling and code-review rounds. Cloud and infrastructure security engineers get identity, network, and detection rounds. Detection and response people get log analysis and incident scenarios. A generalist at a mid-size company might see all of it in a single day. Read the job description and the recruiter’s round breakdown before you decide where your prep hours go.
The rounds you’ll actually sit
A senior security engineer onsite at a company like Datadog, Cloudflare, or a well-funded startup usually runs four or five rounds: a threat-modeling or design-review round, a cloud IAM or infrastructure round, a coding or code-review round, an incident or detection round, and a behavioral one that is really about judgment and how you handle being wrong. Big tech loops (Google, Meta, Amazon security orgs) add a specialized round for the sub-team, plus the usual coding bar. The coding round for security roles skews practical: parse a log file, write a script to find anomalous entries, spot the injection in a diff. You are not usually grinding hard dynamic-programming problems.
The two rounds people underprepare for are threat modeling and IAM, so that is where the rest of this goes.
The threat-modeling round is a conversation, not a checklist
A classic prompt: “Users can upload a profile picture. Threat model it.” Weak candidates start naming attacks at random. Strong ones draw the trust boundaries first. Where does untrusted input enter, where does it get stored, who reads it back, and what runs with higher privilege along the way. Once the boundaries are on the whiteboard, the threats fall out of them instead of coming from memory.
STRIDE is the framework most interviewers expect you to reach for, and it works well as a prompt to make sure you covered each class of problem. The value is not reciting the acronym, it’s using it to find the threats you would otherwise skip, then ranking what you find by real impact and likelihood.
| STRIDE category | Question it forces | Example on the file-upload feature | Control that usually answers it |
|---|---|---|---|
| Spoofing | Is the actor who they claim to be? | A guessable object key lets one user overwrite another’s upload | Authenticated requests, per-user signed URLs, unguessable keys |
| Tampering | Can data change in transit or at rest? | The content-type header says PNG but the bytes are an SVG with script | Validate magic bytes, re-encode server-side, ignore the client’s stated type |
| Repudiation | Can someone deny an action they took? | No record of who uploaded the file that later served malware | Append-only audit log with actor, source IP, and timestamp |
| Information disclosure | What reaches the wrong party? | A public storage bucket exposes every user’s uploads by URL | Private bucket, object-level access control, short-lived signed reads |
| Denial of service | Can an attacker exhaust resources? | A 2KB archive that expands to 4GB on decode (a decompression bomb) | Size caps before and after decode, per-user rate limits, async processing |
| Elevation of privilege | Can a low-privilege actor gain more? | An SVG runs script in your main origin and steals session cookies | Serve user content from a separate sandboxed domain, strip active content |
The move that gets you the offer is what you do after the table. Say which two of those you would fix this sprint and why. On a file upload, stored cross-site scripting through an SVG and a public bucket are the ones that turn into a real breach; the decompression bomb is a nuisance you can rate-limit later. An interviewer wants to hear that you can tell a headline from a footnote. If you rank everything as critical, you have told them you will drown their engineering team in tickets nobody can prioritize.
Expect the interviewer to push on your assumptions. “You said re-encode the image server-side, what if the image library itself has the vuln?” Good answer: run the decode in a sandboxed worker with no network and a tight memory limit, and keep the library patched, because ImageMagick and libwebp have both shipped remote-code-execution bugs. That kind of specific, recent example does more for you than any amount of framework vocabulary.
Cloud IAM is where the real incidents live
Most breaches in 2026 are not exotic. They are an over-permissioned role, a leaked long-lived credential, a misconfigured bucket, or a CI/CD pipeline nobody locked down. Interviewers know this, so the identity round is often the one that decides the loop for cloud roles. You should be able to read an AWS IAM policy out loud and say what is wrong with it.
A common setup: they show you a policy with "Action": "*" on "Resource": "*" attached to an application role and ask you to scope it down without breaking the app. The answer is a process, not a guess. Pull the access history from CloudTrail or IAM Access Analyzer, see which actions the role actually used over the last 90 days, write a policy that grants those on the specific resource ARNs, and roll it out in a staging account first. Least privilege is discovered from real usage, not designed from intuition.
Questions that come up again and again in these rounds:
- “What’s the risk with
iam:PassRole, and how does the confused-deputy problem show up in the cloud?” - “Why prefer short-lived role credentials over long-lived access keys, and how do you kill the last of the static keys in a legacy account?”
- “A Lambda needs to read one S3 bucket. Write the policy.” (They are checking whether you scope the resource ARN or reflexively type a wildcard.)
- “Where does a cross-account role assumption chain go wrong, and how would you detect abuse of it?”
The confused-deputy answer is worth rehearsing because it separates people who have run cloud security from people who have read about it. A service you grant access to can be tricked into using its permissions on an attacker’s behalf; the fix is a condition on the trust policy, usually an sts:ExternalId or a aws:SourceArn check, so the role can only be assumed in the context you intended. If you can draw that on the board, you have signaled real operational experience.
Say what zero trust means, not what the vendor slide says
Zero trust gets asked badly and answered worse. The interviewer is not looking for the marketing definition. They want to know what actually changes in a system when you stop trusting the network. The short version: being on the corporate VPN or inside the data center no longer grants any access by itself. Every request is authenticated and authorized on its own, using the identity of the caller and the posture of the device, and you design as if the attacker is already inside.
Ground it in something real. Google’s BeyondCorp is the canonical example, where employees access internal apps over the public internet with no VPN, and access decisions come from user identity plus device state rather than IP address. In practice that means service-to-service calls carry short-lived, verifiable credentials (mTLS or signed tokens), device health feeds into the access decision, and you segment so a foothold in one service does not hand over the rest. If a candidate recites “never trust, always verify” and stops, the follow-up sinks them: “okay, how would you actually enforce that between two microservices?” Have the concrete answer ready.
The incident question tests how you think under uncertainty
You will get a scenario: “We see 400 failed logins against one account, then a success from an IP in a country the user has never logged in from. What do you do?” The trap is jumping straight to a conclusion. The signal they want is a calm sequence: contain first (revoke the session and active tokens, force a re-auth), scope the blast radius (what could that account reach, what did it touch in the last hour), preserve evidence, then figure out root cause. Containment and eradication are different steps, and mixing them up is a classic tell that someone has only read the playbook.
If they ask about an incident you handled, they are scoring candor and reflection as much as the technical detail. Name what you missed and what you changed afterward. “We over-alerted for a month before we tuned the detection” reads as real; a flawless story reads as fiction.
What gets people rejected
The rejections cluster in a few places. Reciting frameworks without judgment, so every threat is critical and nothing gets prioritized. Reaching for security theater, like proposing a web application firewall to patch an authorization bug in the code. Not being able to write a least-privilege policy when asked, which suggests you have never actually operated the thing you audit. Treating security as a wall against the product team instead of a set of tradeoffs you make with them; the engineer who says “we should block that launch” loses to the one who says “here’s the one fix that makes that launch safe enough to ship Thursday.”
The people who get offers are the ones who, handed a messy system and incomplete information, can tell you what to fix first and defend the ordering. That is most of the actual job. The interview is a compressed rehearsal of a decision you will make for real, with less time and higher stakes, a few weeks after you start.
Practice the behavioral round:
