Lesson 1 of 5

Security in Interviews

"You do not rise to the level of your goals. You fall to the level of your systems." — James Clear, Atomic Habits

There is a persistent belief that security only matters if you are interviewing for a security role. It is wrong in a way that costs ordinary candidates offers, because it confuses where security is named with where it is assessed.

Consider a five-stage loop: recruiter screen, coding round, system design, code review or debugging, and behavioural. Exactly one of those five — the system design round — is likely to name security as an explicit topic. That is 20%. But security signal is available to the interviewer in four of the five — 80% — because in every round after the recruiter screen you are making decisions about input, trust, identity and failure, and those decisions are visible whether or not anyone asks about them.

This asymmetry is the whole chapter. Candidates prepare for the 20% and are evaluated on the 80%. And the evaluation is not "did they recite OWASP". It is a much simpler judgement the interviewer makes almost unconsciously: does this person think about what happens when the input is hostile, or do they only think about the happy path? You demonstrate that in a forty-five minute coding round with about five minutes of talking — roughly 11.1% of the round — and it changes the write-up more than a faster algorithm does.

The mistake in the other direction is just as costly. A candidate who has read a security book and now interrupts a string-reversal exercise to discuss threat models is not showing judgement; they are showing they cannot tell which problems are which. Security awareness that fires indiscriminately reads as noise, and noise is a negative signal. The skill being assessed is proportionality.

The big question

You are forty minutes into a forty-five minute coding round. Your solution works and the tests pass. You have noticed that the function trusts its input completely. Do you say something, and what exactly do you say?

Where the signal actually lives

Tests — Run & Watch Them Pass

Run to execute the tests…

Everyday analogy

A driving test has one section explicitly called the emergency stop. Candidates rehearse it obsessively. But the examiner is assessing observation continuously — mirrors before signalling, awareness at junctions, whether you look at the road you are turning into — across the entire drive, and the notes they write are mostly about that. Fail the emergency stop and you have failed one manoeuvre; drive the whole route without checking a mirror and you have failed the test even if every manoeuvre was clean. The parallel is exact. There is one round that names security, and there is a continuous assessment of whether you notice things, which runs the whole way through and which most candidates do not know is happening.

Five minutes that change the write-up

Tests — Run & Watch Them Pass

Run to execute the tests…

Engineer's notebook

I have sat on both sides of this and the thing that surprised me most as an interviewer is how rarely the security note is about security. When a candidate says "this trusts the caller's ID — in production I would check ownership", what I write down is not "knows about IDOR". It is that they are modelling the production system while solving the toy problem, which is the single most reliable predictor I have found of how someone behaves on a real codebase. The candidates who never say anything like it are not necessarily ignorant; they have decided the exercise is a game with its own rules, and that decision is the thing I am worried about. The inverse is real too. I once had a candidate spend eleven minutes of a forty-five minute round on the threat model of a function that sorted integers in memory, and I could not recommend them, because on a real team that instinct fires in code review constantly and someone has to absorb the cost. What I want, and what I now say out loud when I brief people, is one sentence at the right moment. Not a lecture, not silence.

Talking about it in the behavioural round

Tests — Run & Watch Them Pass

Run to execute the tests…

From the archives

The technical interview as we know it — the whiteboard, the algorithmic exercise, the structured loop — comes largely from Microsoft in the 1980s and Google in the early 2000s, and it was designed to answer one question: can this person program. That was the binding constraint at the time. The industry has since discovered, repeatedly and expensively, that it was not the only one, and the loop has been accreting rounds ever since — system design when services got distributed, behavioural rounds when teams got large enough that a brilliant engineer could be net negative, code review rounds when it became clear that reading code is most of the job. Security has never received a round of its own outside security roles. What happened instead is that it dissolved into the existing rounds as a quality of the answers rather than a topic, which is why it is simultaneously true that most loops never ask a security question and that most loops assess it. If you are waiting for the round where it comes up, you have already been graded.

Common Mistakes

Preparing only for the round that names it. Security is explicit in 1 of 5 stages and observable in 4 of 5.
Assuming it only applies to security roles. Any role touching input, identity or data access is assessed on it.
Saving the security comment for the end. Asked during clarification it frames the solution; asked at minute forty it is an afterthought.
Raising it on every problem. Threat-modelling a string reversal reads as noise, not judgement.
Lecturing instead of noting. One sentence naming the assumption, the fix and the bug class is the whole move.
Implementing the hardening uninvited. Offer it and let the interviewer choose; the clock is theirs to spend.
Writing only happy-path tests. One hostile case costs nothing and signals more than the other four.
Having no incident story ready. The behavioural round is where the strongest security answers go unsaid.
Telling a story with no structural change. "We were more careful afterwards" is not a fix; a CI check is.
Framing security as a veto. "We can't ship" gets you routed around; exposure, mitigation and accepted risk does not.

Interview Corner

Interview Corner — the same idea at three levels. Answer yours; recognise the one above it.

Warm-up

You are writing a function that fetches an order by ID for the logged-in user. What do you ask before you start?

Model answer — Three things, and I would ask them in the first couple of minutes rather than at the end. First, where does the ID come from — if it arrives from the client then it is attacker-controlled and I cannot treat it as trustworthy just because our own UI produced it. Second, does this function check that the order belongs to the caller, or is it assumed upstream? That is the one that matters most, because if it is assumed upstream and the assumption is wrong, changing the ID in the URL returns someone else's order, which is an IDOR and it is the single most common real-world flaw in code shaped like this. Third, what should happen on malformed input — do we throw, return null, or return a 404, and is there a difference between "does not exist" and "exists but is not yours", because answering those differently leaks whether an order exists. None of that takes long to ask and it changes what I write. Then I would implement the happy path, and when I write test cases I would include one where the ID belongs to a different user, since I am writing tests anyway and that case is the one that documents the assumption.

Intermediate

How do you raise a security concern in an interview without derailing the problem you were given?

Model answer — Proportionally, and early rather than late. My rough model of a forty-five minute coding round is five minutes clarifying, twenty-five implementing, ten testing, and about five minutes total spent on hardening — said aloud, spread through, roughly a ninth of the round. The clarification phase is where it is cheapest: asking whether the input can be attacker-controlled costs nothing there and frames everything after it, whereas the same question at minute forty sounds like something I remembered rather than something I was doing. When I notice something mid-solution I name it in one sentence and keep moving — something like "this assumes the ID belongs to the caller; in production I would check ownership here, otherwise it is an IDOR" — which names the assumption, the fix and the bug class in about eight seconds. Then I explicitly hand the decision back: do you want me to implement that, or note it and continue? The clock is the interviewer's to spend, not mine. The other half of the answer is knowing when not to. If the task is to reverse a string or sort an array in memory, there is no security dimension and raising one is not a strength — it signals I cannot tell which problems are which, and on a real team that instinct fires in every code review and someone else absorbs the cost. What is being measured is judgement about proportion, not vocabulary.

Advanced

You are the interviewer. How would you assess whether a candidate thinks about security, without asking a security question?

Model answer — I would design for it rather than hope for it, because the signal is available in most of the loop but only if the exercise admits it. So first, I would pick a problem with a real trust boundary in it — something that takes user-supplied input and reaches data belonging to someone, rather than a pure algorithmic exercise where the correct amount of security discussion is zero. Then I would watch three specific moments. During clarification, does the candidate ask where the input comes from and whether it can be hostile? During implementation, do they name the assumptions they are making about the caller, or do they silently trust everything the signature hands them? And when they write tests, is any case adversarial, or is every one a variation on valid input? None of those require me to say the word security, and all three are observable in a normal coding round. In a code review round I would seed a defect whose only symptom is a missing ownership check — no crash, no obvious smell, correct-looking code — because the ability to notice a missing check is a genuinely different skill from spotting a bug that misbehaves. I would also be careful about what I score. I am not rewarding vocabulary; a candidate who says "IDOR" and a candidate who says "this would let someone read another user's order" have given me the same signal. And I would score the failure mode in both directions — a candidate who threat-models a sorting function is showing me a real problem too, because indiscriminate concern has a cost on a team and I would rather see it in the interview than in the first month.

Company lens — how the same topic gets asked

micro1Concept: naming an assumption in code you just wrote.

GoogleDepth: proportionality — knowing which problems have a security dimension.

MetaDesign: building security into the clarification phase of a round.

AmazonReality: a behavioural story with a structural fix, not a personal one.

Hands-on

Take the last coding exercise you did — from a practice site, an old interview, anything — and reread it for a trust boundary. Where does data enter, and what does the function assume about it? Write the single sentence you would have said aloud, in under twenty words, naming the assumption and the fix. Then do the harder half: find a practice problem that genuinely has no security dimension, and confirm you can say so. Finally, write out one incident story you could tell in a behavioural round, and check that it ends in a structural change rather than a resolution to be more careful.

Tests — Run & Watch Them Pass

Run to execute the tests…

Summary

Security is named in 1 of 5 stages (20%) and observable in 4 of 5 (80%). Candidates prepare for the smaller number.
The judgement being made is simple — do you consider hostile input, or only the happy path?
It applies outside security roles. Any role touching input, identity or data access is assessed on it.
Ask during clarification. "Can this input be attacker-controlled?" costs nothing at minute three and everything at minute forty.
Budget roughly 5 minutes of 45 — about 11.1% — spread through the round as sentences, not a lecture.
One sentence: assumption, fix, bug class. Then hand the clock back: implement it, or note it and move on?
Write one hostile test case. You are writing tests anyway; that one carries the signal.
Proportionality is the skill. Roughly half of typical exercises have no security dimension, and raising it there is a negative.
The behavioural round is unclaimed territory — a real incident story, ending in a structural change, is the strongest answer available.
Never frame security as a veto. Exposure, cheapest mitigation, and what you would accept if you shipped anyway.

The next chapter narrows to the round where this is most concentrated and most winnable: being handed unfamiliar code and asked what is wrong with it, with a clock running and no ability to execute anything.

Editorial reflection

Writing this chapter forced me to admit something slightly uncomfortable about interviews generally, which is that the most valuable signals are almost always the unrequested ones. Nobody is impressed by a correct answer to the question they asked; that is the floor. What moves a write-up is the thing the candidate noticed that was not on the sheet — and security is the richest available source of those, because it is the one dimension of software quality that is simultaneously universal and unasked. That also explains why the advice here is so unglamorous. There is no framework to memorise and no vocabulary to acquire. There is a habit of asking where the input comes from, a willingness to name an assumption out loud, and — the part most people miss — the restraint to say nothing when there is nothing to say. I keep returning to the fact that the same instinct, applied without proportion, is a liability rather than a strength. Very few things in engineering are like that. Most virtues are monotonic; more testing is better than less, more clarity is better than less. Security attention is not, and learning where its ceiling sits is most of what separates someone who has read about this from someone who has done it.

Enrol to track progress

Q&A · 0

Enrol to ask questions and join the discussion.

No questions yet — be the first to ask.