Google Security Foundations & Threat Modeling interview questions

The first ten minutes of any design review decide its quality. This answer shows the sketch, the one question that finds most bugs, and why controls come last.

Candidates who say 'everything is new' and candidates who say 'nothing is new' both lose this one. The answer that scores names exactly three differences and keeps the rest of the toolkit.

Reciting the six letters earns little. What scores is a diagram drawn aloud, one boundary walked in depth, and a list of threats with owners.

The order lookup is the whole interview. Candidates who spend ten minutes on jailbreaks and two on authorization have it backwards.

Definitions take ten seconds. The interviewer wants a worked failure: which layer broke, which one held, and why they did not break together.

Three words people use interchangeably, and a prioritisation question that exposes whether you have ever had a backlog of thirty findings.

Neither 'block it' nor 'ship it' scores. The interviewer is watching whether you can find the one risk that matters in a day and offer a path to launch.

Five minutes, no jargon, one decision. Candidates who explain how attention works have already lost the room.

Most candidates start by deleting the commit. The key was copied the minute it went public; the clock starts with revocation.

A reset flow is a second login page with weaker checks. Interviewers use it because every step has a classic bug, and the strong answer finds them in order.

Two classic tools that structure attacker thinking. The scored answer uses each for what it is good at and names the blind spots before an interviewer does.

STRIDE assumes components follow their code. A model follows its inputs. The scored answer keeps the six categories and adds what probabilistic, persuadable components need.

Detection quality is decided before the first alert, by what you logged and how you set the threshold. The scored answer derives both from the questions an investigator will ask.

Privacy principles become engineering decisions about fields, retention and contracts. The scored answer walks one feature and makes each principle concrete.

Reviews fail when they arrive late, cover everything equally and produce vague findings. The scored answer scopes early, focuses on the riskiest decisions and writes findings as specific, owned changes.

Every senior security engineer has one. The scored answer shows you reduced the risk, made the residual visible, got the right owner to accept it, and kept watching.

Interviewers want a security engineer who can say no without becoming the department of no. The scored answer shows evidence, an alternative that met the goal, and a working relationship afterwards.

Severity disputes are usually disagreements about facts or assumptions. The scored answer finds which, settles it with evidence and the agreed scale, and has an escalation path that does not damage trust.

AI features need the usual secure development steps plus a few that most lifecycles lack. The scored answer places each activity at the stage where it is cheapest and names the gate.

How you treat the first reporter decides whether there is a second. The scored answer acknowledges quickly, validates safely, fixes by severity, communicates honestly and handles AI-specific scope questions.

Leaked keys remain one of the commonest breach causes, and agents create new places to leak them. The scored answer prefers no secret at all, then short-lived ones, and keeps them out of every model context.

Good metrics change decisions. The scored answer picks a few in coverage, risk, outcomes and speed, defines each precisely, and explains what action each one triggers.

Security engineers rarely have authority over the teams whose code matters most. The scored answer makes the secure path the easy one, earns trust through help, and gives teams ownership.

A judgement question with an ethical edge. The scored answer makes the risk clear in business terms, offers options, accepts a properly informed decision, and knows the rare cases where it is not enough.

A penetration test is a controlled, authorised simulation of an attacker with a scope, rules and a report. The legal and planning parts are what separate it from an attack.

Internal assessments rarely need exotic exploits. They follow the credentials, and the controls that matter are the ones that stop credentials from spreading.

Attackers are not wizards; they repeat a small number of moves because those moves keep working. The answer names the moves and the choke points where one control breaks many intrusions.

When finding a bug costs a few dollars of compute, the defender's advantage has to come from somewhere else. A staff-level answer says exactly where.

A leadership question. The scored answer finds out what exists, fixes the highest-impact exposures, and builds the few shared controls that make every later project cheaper.

The tools are free; running them is not. A strong answer picks a small set by risk, assigns owners, and treats every security tool as software that can be compromised or relicensed.