Security Engineer Interview Prep: Questions and a Mock Test

This is the fastest currency check an interviewer has, and a lot of preparation material is out of date. The OWASP Top 10 was revised, and the 2025 edition is now the current release. Its order is: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions.

Compare that with the 2021 edition: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures, A09 Security Logging and Monitoring Failures, A10 Server Side Request Forgery.

The movements tell a story worth being able to narrate. Broken access control stayed at number one. Injection fell from third to fifth, which reflects parameterised queries and ORMs becoming the default rather than injection ceasing to matter. Misconfiguration rose to second. The vulnerable-components category broadened into software supply chain failures at third, which is the single most visible change in the industry's threat model over the past few years. And server-side request forgery no longer stands as its own category, while mishandling of exceptional conditions appears as a new one.

Quoting the 2021 order confidently is not a disaster. Quoting it while insisting it is current is.

Injection remains a staple question even at fifth place, because the quality of the answer varies so widely.

The weak answer is escaping. The strong answer is separating code from data so the parser never treats attacker input as syntax. For SQL that means parameterised queries or prepared statements, where the query structure is fixed before any value is bound. Escaping is a fallback for the cases where parameterisation is genuinely impossible, such as a dynamic table name, and those cases need an allowlist rather than a filter.

The follow-up is usually cross-site scripting, and the correct framing is contextual output encoding rather than input sanitisation. The same string is safe in one context and dangerous in another, so encoding belongs at the point of output and has to match the context: HTML body, HTML attribute, JavaScript, URL, CSS. A single sanitising function applied on the way in cannot know where the value will eventually land. Content Security Policy is the defence in depth layer, not the fix.

Be ready for the variants: second-order injection where the payload is stored and executed later, and injection into things that are not SQL at all, such as LDAP filters, OS commands, template engines, and NoSQL query documents.

Password storage is where interviewers separate people who have read about cryptography from people who have used it.

General-purpose hash functions such as SHA-256 are the wrong tool, because they are designed to be fast and hardware can compute them in enormous quantities. Password hashing needs a function that is deliberately slow and memory-hard, so the current answers are Argon2id, scrypt, or bcrypt, with parameters tuned to the hardware. A salt, unique per password and stored alongside the hash, defeats precomputed rainbow tables and stops identical passwords producing identical hashes. A pepper is a secret held outside the database, which helps only if the database leaks and the secret does not.

On transport, TLS 1.3 is the current baseline and the useful things to know are the shape rather than the byte layout: a reduced handshake, forward secrecy by requiring ephemeral key exchange, and the removal of the older cipher suites and negotiation options that produced a decade of downgrade attacks.

One distinction interviewers probe often: encryption provides confidentiality, hashing is one-way and provides integrity when combined with a key as a MAC, and a signature provides integrity plus authenticity plus non-repudiation. Candidates who use "encrypt" for all three tend to be probed until it shows.

Software supply chain failures sitting at A03 in the 2025 list is a good prompt for what to prepare. The threat model runs from dependencies you chose, through dependencies you did not know you had, to the build system itself.

Worth being able to discuss concretely: transitive dependencies and why a lockfile matters, typosquatting and dependency confusion where a public package shadows a private name, compromised maintainer accounts, and post-install scripts that execute at install time rather than at run time. On the build side, the risk is that a compromised build produces a signed artefact that every downstream check trusts, which is why reproducible builds, provenance attestations and a software bill of materials have become mainstream asks rather than niche ones.

NIST's Secure Software Development Framework, published as SP 800-218 version 1.1 in February 2022, is the reference to name when an interviewer asks how you would structure secure development across an organisation rather than fix one bug.

The judgement question underneath this is usually about patching. A scanner reporting hundreds of vulnerable dependencies is normal, and treating them all as equally urgent is a way of achieving nothing. Being able to reason about exploitability, whether the vulnerable code path is reachable, and what compensating controls exist is what a security engineer is actually for.

The 2025 list renames the logging category to Security Logging and Alerting Failures, and the word alerting is the point. Logs that nobody looks at are an archaeology tool, not a control.

Expect questions about what you would log for a given feature, and the good answers cover authentication events including failures, authorisation denials, changes to permissions and to security configuration, and access to sensitive data. Equally important is what not to log: credentials, tokens, full card numbers, and personal data that the logging pipeline then spreads across systems with weaker controls than the original store.

Detection questions usually want a threat-informed answer. Being able to describe an attack in stages, initial access, execution, persistence, privilege escalation, lateral movement, exfiltration, and to say what evidence each stage leaves, is more valuable than naming tools. MITRE ATT&CK is the shared vocabulary for exactly that decomposition.

The incident round is behavioural. Interviewers listen for containment before eradication, for preserving evidence before rebuilding a host, for knowing who has authority to disconnect a production system, and for a communications path that includes legal and regulatory obligations. A candidate whose first instinct is to reimage the machine has destroyed the only copy of how the attacker got in.