What Your Interviewer Already Knows About You

Here is how a code review exercise goes in a well-designed interview.

You're given forty lines of AI-generated code and asked: read this, tell me what you'd change before shipping it. No time pressure. No trick questions.

Most candidates start the same way. They find the variable names they'd choose differently. They note a missing comment. They suggest a formatting change. They are, in this moment, doing exactly what they do every day — reviewing code for style.

Five minutes in, they've generated a list of improvements. None of them would affect the behaviour in production.

The interviewer thanks them and asks: did you find anything that would cause this to fail?

The question lands differently for different candidates. Some go back immediately — they missed something, they know it, now they're looking for it. Some look at the interviewer, unsure what they're supposed to have found. Some say confidently: no, the code looks solid to me.

That moment — the gap between what each candidate sees and what's actually there — is one of the most predictive signals in the entire process.

What a careful interviewer already knows

Before you've answered a question, an interviewer who has thought carefully about the AI era already knows several things from your resume and the first five minutes of conversation.

They know whether you're in the Avoider, Dumper, or Steerer pattern (see Part 1 of this series). The signals are in how you describe your workflow, not in which tools you name.

They know roughly where your skills sit relative to the new weighting for the AI era. The skills that now matter most — specification quality, output evaluation, failure-mode reasoning — are almost never tested in traditional interviews, which means most candidates haven't been developing them deliberately. The atrophy research covered in Part 2 gives interviewers a framework for understanding what's likely to have degraded and what probably hasn't.

And they know what they're going to find out from the exercises: not whether you're smart, but whether you can evaluate output that looks correct but isn't.

What the new interview actually tests

The hiring series covered this from the interviewer's side in detail. From the engineer's side, the picture is simpler: there are three things being tested, and they all connect.

Specification quality. Given a vague requirement, do you slow down and name what's missing before building anything? Do you ask about edge cases, error states, performance assumptions? Or do you start building immediately and discover constraints as you go?

The exercise is usually a two-sentence requirement and a blank page. What happens in the first thirty seconds tells the interviewer most of what they want to know. The strong candidate asks questions or writes down assumptions. The weak candidate asks which framework to use.

Output evaluation. Given code — AI-generated, but you're not always told — can you find the problem that matters? Not the style issue, not the naming inconsistency. The behavioural failure: the case where the function returns the wrong answer silently, the retry logic that never actually retries, the edge case that was never handled and will surface in production.

This is the code review exercise from the opening of this article. The hiring article on this topic goes deep on what interviewers are watching for. The short version: they're watching how far you read before you find the real problem, and whether you can tell the difference between a style issue and a correctness issue.

Failure-mode reasoning. Given a system description — a payment retry queue, an email sending service, a user permissions cache — can you describe how it fails? Not theoretically. Specifically: what's the scenario where it produces a silent wrong answer? What's the failure that only shows up at 3× normal load? What's the dependency assumption baked into the design that will be false in production?

Strong candidates go somewhere interesting quickly. They find the failures that don't raise exceptions. The third article in the hiring series covers why this signal matters more than most traditional interview components.

What it doesn't test

This is as important as what it does test.

Syntax and language trivia. Nobody is testing whether you can write a binary search from memory or name all the methods on a string object. These skills had limited predictive value before AI; they have almost none now.

Framework and library knowledge. Knowing the React lifecycle hooks, the Spring Boot annotations, the SQLAlchemy relationship parameters — this is retrievable knowledge. The interview is testing judgement, not retrieval.

Algorithm performance. Big-O analysis, time/space tradeoffs on abstract data structures — these still matter for System Engineering roles at scale, but they're not the primary signal for most engineering positions. The skill map shows exactly where this sits now relative to the other competencies.

This shift has a practical implication for preparation. Time spent grinding LeetCode is time not spent developing specification quality and output evaluation. If you're preparing for a serious interview at a company that has updated their process, the ROI on LeetCode is low.

How to prepare

The three skills being tested are trainable. None of them require a special environment — you can practice them on your own work, today.

For specification quality: Before your next task, write down what done looks like. Not a ticket summary. A behavioural specification: what inputs are valid, what outputs are expected, what failure looks like, what performance assumption is baked in. Then identify five things that are missing from the requirement. If you do this consistently for a month, the first thirty seconds of an interview exercise will feel natural rather than unfamiliar.

For output evaluation: Take the code review exercise seriously. Find a piece of AI-generated code — your own recent work is fine — and review it with one rule: you're not looking for style issues, you're looking for the thing that will fail in production. Give yourself a specific constraint: find one thing that produces a wrong answer, silently, under a valid input. This is harder than it sounds, and that difficulty is what makes it valuable to practice.

You can also practice against the System Engineer Question Bank and Product Engineer Question Bank — these are designed as interviewer tools, but reading them as an engineer tells you exactly what's being evaluated and at what level of specificity.

For failure-mode reasoning: "How does this fail?" as a daily habit. Pick any system you worked with today — your own feature, a third-party API you called, an internal service you depended on. Name three failure modes. Force yourself to be specific: not "it might have bugs" but "if the upstream service returns a 200 with an empty body, this will process successfully and produce a silent wrong answer." Do this every day for two weeks and you'll find your rate of catching production failures before they happen increases noticeably.

Using the scorecards as a mirror

The scorecards were built as interviewer tools — the System Engineer Scorecard and the Product Engineer Scorecard give interviewers a structured way to evaluate candidates across the full skill set.

Reading them as a candidate is instructive. Each dimension has a description of what a 5/5 looks like and what a 1/5 looks like. Working through them honestly — scoring yourself across each dimension — gives you a clearer picture of where you actually stand than most self-assessments.

The difference between a 3 and a 5 on output evaluation, for example, is not about being smarter. It's about having developed the habit of looking for behavioural correctness rather than style. That habit is buildable. The scorecard tells you what the endpoint looks like.

What this series is about

We've been writing about the AI era from the hiring side for most of this year — what interviewers should stop testing, what they should test instead, how teams should be structured, what leadership looks like.

This series is the other side of that. Same framework, but the question is not "how do I hire for the AI era" — it's "how do I become the engineer who thrives in it."

The next article is about the deepest part of that shift: not the habits you need to build, but the way you have to change how you think before the agent runs.