testing

Random input finds shallow bugs. Coverage feedback, sanitizers and a harness that reaches the parser are what make fuzzing find the deep ones. The interview checks all three, plus what happens after the crash.

Model a bounded reservation workflow, run an offline invariant fixture, and reason about retries, contention, immutable intent and uncertain external outcomes.

The commonest serious bug in AI tools is the oldest: fetching an object by ID without checking who is asking. The scored answer finds it, fixes it at the data access, and tests across users and tenants.

Anyone can write a query that matches an attack. The interview is about everything else: the data source you trust, the benign activity that looks the same, how you proved it fires, and what the analyst does when it does.

Detections are production code that pages people. Treating them that way means version control, tests that prove they fire, review, staged rollout and metrics that decide which ones live.

Three definitions and one practical consequence. The consequence is the point: security tests split into deterministic checks and measured rates.

Trace actual text, image and audio inputs, then distinguish extraction errors, unauthorized influence and completed effects. Build a useful test plan without inventing success rates.

Build an authorized evaluation with synthetic identities, a fidelity matrix and controlled effects after real permission checks. Report what the harness proves and what remains untested.

Review customer, operator and service authority separately. Enforce order access and email release policy, govern contact changes, and test valid work alongside unauthorized reads and disclosures.

Define the compromise scope and secret boundary, map direct and indirect capability paths, and assemble evidence with explicit assumptions. Denial tests and model refusals are useful observations, not universal proofs.