Interview Tips

What interviews test

An interviewer has one hour to sample work that normally unfolds over weeks, so the room turns knowledge, reasoning under observation, and collaboration into a compressed signal.

That signal is the technical interview. Its limits explain why firms use multiple readers and rubrics, and why a single shaky answer can be treated as data rather than a full measure of ability.

Three separate screens

An hour is asked to separate three things that correlate less than candidates assume: whether you know the material, whether you can reason while observed and timed, and whether the people in the room want to work with you. Most formats compress these into a single yes, so a shaky performance under pressure gets recorded as a hole in knowledge. Quantitative funds, frontier labs, and large product organizations weight the three differently, and inferring that weighting is most of what preparation buys.

One hour is a small sample, and firms know it. The defenses are structural: several independent interviewers who do not confer until the end, a rubric that scores dimensions rather than a gestalt, and a bar set to tolerate false negatives because a bad hire costs more than a missed one. A candidate who understands the sampling will not argue with a single hard question, and will instead try to leave each interviewer one clear, defensible data point.

Reading the process behind the question

The stated question is rarely the graded one. An algorithm prompt is a vehicle for watching how you decompose a problem, recover from a wrong turn, and check your own work, and the working solution at the end is worth less than the path to it. A candidate who solves it in silence and presents a finished answer has withheld exactly the evidence the interviewer was sent to collect.

Reading a process for what it rewards is a research task you do before the first round. A firm that runs five algorithm rounds and no design round is telling you it hires for raw problem solving over architectural judgment, and a firm that sends a take-home is telling you it trusts sustained work more than whiteboard recall. The shape of the funnel is public information, and treating it as noise wastes the clearest signal you get about what the job values. Coding rounds by role sets what employers publish about their own coding rounds against the families that cover what each role adds, and marks the additions no family covers.

McKinsey personal experience interview

A candidate often arrives with a polished team story, then discovers that the interviewer keeps cutting it down to the exact choice, conflict, and action the candidate owned.

That format is McKinsey’s personal experience interview. It rewards one defensible story in depth, because a broad success narrative without individual causality leaves the interviewer with nothing reliable to grade.

Dimensions McKinsey has described

McKinsey has described the qualities it looks for in this interview along the lines of personal impact, entrepreneurial drive, and inclusive leadership, though the firm has revised the labels over time and coaching sites report further renaming. Treat the exact wording as approximate and the underlying targets as stable: evidence that you changed an outcome, that you acted without being told to, and that you moved a group you did not command. The stories that serve this interview are the same experiences that anchor your resume, told with far more detail about your own decisions.

Why the interviewer keeps narrowing

The interviewer keeps asking what you personally did because the failure mode of this interview is a candidate who narrates a team’s accomplishment in the first person plural. Every follow-up narrows the aperture: what did you propose, who disagreed, what did you do when they pushed back, and how did the decision actually get made. A story with no conflict starves this line of questioning, since a project where everyone agreed and everything worked gives the interviewer nothing to probe and you nothing to have personally caused.

Preparing a few stories deeply

Preparing three stories you can defend to the studs beats preparing twelve you can only narrate. Each strong story should survive twenty minutes of the interviewer pulling on the thread of your specific contribution, which means you need the constraints, the alternatives you rejected, and the reason you chose as you did. A candidate with a deep bench of two or three flexible stories can map almost any prompt onto one of them, while a candidate with twelve thin ones runs out of detail on the second follow-up.

Case interviews

A business problem worked aloud with the interviewer, graded on how you structure the problem and whether you reach a recommendation you can defend with numbers.

Structure before analysis

Structure comes before analysis, and stating the structure out loud is part of the grade. Before touching a number, you lay out the parts of the problem and how they relate, so the interviewer can see the decomposition and correct it early rather than watch you compute inside a frame that was wrong from the start. A market-sizing case is an estimation problem wearing a business costume, and it rewards a visible scaffold of assumptions far more than a lucky final figure.

Arithmetic out loud

Mental arithmetic is tested directly because a consultant who cannot multiply in front of a client loses the room, and there is no calculator in the meeting. The interviewer wants to watch you hold one significant figure and round on purpose, checking each result against a number you already trust, so a fast wrong answer delivered with confidence costs more than a slower one you audit aloud. Practicing arithmetic to fluency is unglamorous, and it earns the cheapest points on the board.

Driving to a recommendation

The aim of the exercise is a recommendation, and a candidate who exhausts a framework without committing to an answer has failed the actual task. Good case performance drives toward a defensible position and treats the structure as a means of getting there, spending time on the branches that move the decision and abandoning the ones that do not. A memorized framework becomes a liability the moment it is applied whole to a problem it does not fit, because reciting all four boxes of a standard template signals that you are pattern-matching rather than thinking about this company.

Google technical interviews

A shared editor makes every pause, wrong turn, and complexity tradeoff visible, not just the final code. Google technical interviews use that setting to test algorithmic problem solving under observation.

Correctness still counts, but a solution that arrives without the data structure choice, cost analysis, and small tests gives the interviewer much less evidence than the same code reasoned through aloud.

Data structures and complexity

The stated core is data structures and the complexity analysis that goes with them. You are expected to reach for the right structure without enumerating the wrong ones, to state the time and space cost of your approach in asymptotic terms, and to know when an average case hides a bad worst case behind it. Complexity is graded explicitly, so a correct solution whose cost you cannot characterize is only half an answer. LeetCode Patterns sorts every LeetCode topic into twenty solution families, each with the signals that identify it, a tested template, and the cost it reaches.

Working aloud and testing

Talking through an approach before writing code is the mechanism by which a wrong plan gets caught early, before you have sunk ten minutes into typing it. Say the idea, wait for a nod or an objection, and only then write.

Once the code is on the screen, run it yourself on a small input and a boundary case before anyone asks. A candidate who catches an off-by-one unprompted shows the habit the job actually needs, and one who waits to be told the code is broken has handed the interviewer a reason to worry.

Design at senior levels

At senior levels a system design round joins the algorithm rounds, and it grades a different faculty: whether you can take a vague requirement and impose enough structure to make progress without inventing constraints nobody stated. The algorithm rounds ask whether you can find a correct, efficient answer to a closed problem, while the design round asks whether you can make reasonable decisions when the problem is open and underspecified.

Frontier lab interviews

A lab hiring for research engineering often wants to know how a candidate handles an unfamiliar codebase, a past project, or a paper whose assumptions need stress-testing. Frontier lab interviews lean toward that evidence.

The format can be costly to both sides, but it samples practical judgment and ownership closer to the work than a timed puzzle usually can.

Work samples over whiteboards

Frontier labs are widely reported to lean on take-home and work-sample tasks where a candidate builds or debugs something close to real work, alongside or in place of timed algorithm rounds. Anthropic’s published candidate guidance names both take-home assessments and live interviews, but what labs publish rarely goes past naming the formats, so the finer picture comes mostly from candidates rather than from the firms. The reasoning is that a lab hiring for research engineering wants evidence you can make a messy codebase do something new, which a two-hour puzzle predicts poorly. A take-home costs the candidate more hours and the firm more grading, and both sides accept the trade because the signal sits closer to the job.

Discussing your own research

Expect a long discussion of your own past work, in which the interviewer keeps asking why you did it that way and what you would do differently now. Depth is the test: a project you actually drove will survive an hour of a specialist pulling on your design choices, and a project you rode along on will not.

A separate exercise sometimes asks you to read a paper and critique it on the spot. Reading a paper critically grades whether you can find the load-bearing assumption in an unfamiliar method and say what would break if it failed, which is the daily work of research and hard to fake.

Safety and judgment questions

Questions about safety and judgment are asked seriously at these labs, and treating them as a compliance ritual to be flattered through is a fast way to fail. A lab deploying models with real consequences needs people who can reason about failure and misuse without either dismissing the risk or performing alarm, so the useful answer names a concrete failure and its mechanism, then says what mitigation you would actually try. A candidate who can trace how a system does harm scores far above one who recites principles.

Quantitative research interviews

Interviews at quantitative funds such as Two Sigma and D. E. Shaw, weighted toward probability and statistics and the taste to tell a real signal from an artifact.

Probability from first principles

Probability and expectation problems are worked from first principles, with the interviewer watching your setup more than your final number. A clean solution names the sample space, defines the random variables before manipulating them, and reaches for a general tool like conditioning or an indicator sum rather than grinding a special case. The problems are chosen so that the direct computation is ugly and a well-chosen decomposition is short, which rewards knowing a few structural moves cold.

Overfitting and sample reuse

Statistics questions probe whether you understand how a backtest lies to you. Expect to reason about overfitting, about how much data it takes to distinguish a real effect from noise, and about what happens to a p-value when you test a hundred signals and report the best. The sample-size and multiple-testing questions have clean quantitative answers, and a candidate who waves at them qualitatively is telling the interviewer they have never been burned by a false discovery.

Owning a research project

You will be asked to walk through a research project you own, and the follow-ups reward honesty about what failed. A candidate who presents only a clean success invites the suspicion that they never understood the failure modes, while one who can explain a dead end and what it taught scores as someone who has actually done research. A clean answer to the wrong question scores poorly here, because a fund is paying for the judgment to pick the question that matters, and elegance spent on an irrelevant problem is a negative signal about taste.

Trading interviews

Interviews at Jane Street and similar firms, built around games where you price under uncertainty while an adversary takes the other side of every quote.

Making a market

The signature exercise, as candidates rather than the firms describe it, is a market-making game: the interviewer names an unknown quantity, and you must quote a two-sided price, a bid at which you will buy and an ask at which you will sell, tight enough to be competitive and wide enough to survive being picked off. The interviewer then trades against your quote, hitting your bid when your price is too high and lifting your offer when it is too low, so a quote you are unwilling to trade on both sides is not a real quote. The width of your market encodes your uncertainty, and a candidate who quotes a penny-wide market on a quantity they barely understand is announcing that they do not know what a spread is for.

Updating and expected value

As new information arrives, you are expected to move your quote, and the cost of not updating is that the interviewer keeps trading against a stale price until you notice. Failing to revise on a strong signal is the sharpest negative in the game, since it shows either that you did not register the information or that you cannot turn it into a number. Many of the expected value questions hide a correlation: the naive computation treats two events as independent and prices a bet that looks positive, while the events move together and the real expectation is negative, so the discipline being tested is checking whether your terms are actually independent before you multiply.

Probability puzzles

A probability puzzle usually looks like a one-off trick until the candidate recognizes the small family it belongs to. Probability puzzles test the reusable method, not folklore about the setup.

Conditioning, symmetry, linearity of expectation, and random-walk recurrences turn many ugly computations into short arguments, and missing the structure leaves candidates doing arithmetic the problem was designed to avoid.

Conditioning and base rates

Conditional probability defeats intuition most reliably on base rates, where a rare condition and an imperfect test combine in a way that feels wrong. Take a condition that affects one person in a thousand, a test that catches it 99 percent of the time, and a false-positive rate of 5 percent, and ask what a single positive result means.

$$P(D \mid +) = \frac{P(+ \mid D)\,P(D)}{P(+ \mid D)\,P(D) + P(+ \mid \lnot D)\,P(\lnot D)}$$

Plugging in gives $P(D \mid +) = (0.99 \times 0.001) / (0.99 \times 0.001 + 0.05 \times 0.999)$, which is $0.00099 / 0.05094$, or about 1.9 percent. The positive test raises your probability from 0.1 percent to roughly 2 percent, and the answer stays small because the false positives drawn from the vast healthy majority swamp the true positives drawn from the tiny sick minority. Candidates who answer near 95 percent have anchored on the accuracy of the test and ignored the prevalence.

Symmetry instead of arithmetic

Many problems dissolve under a symmetry argument that never computes anything. Asked for the probability that one specific card precedes another specific card in a well-shuffled deck, you can note that the two orderings are equally likely by symmetry, so the answer is exactly one half, with no reference to the 50 cards in between. The same move answers questions about a uniformly random queue position or which of several symmetric players draws a winning ticket first, and spotting the symmetry converts a page of casework into a sentence.

Linearity of expectation

Linearity of expectation is the most reused tool in the whole genre, because it holds whether or not the pieces are independent.

$$E\!\left[\sum_{i=1}^{n} X_i\right] = \sum_{i=1}^{n} E[X_i]$$

For the number of fixed points of a uniformly random permutation, let $X_i$ indicate whether item $i$ maps to itself; then $E[X_i] = 1/n$ and the sum is exactly 1 for every $n$, with no inclusion-exclusion. The coupon collector total, the expected number of records in a random sequence, and the count of descents all fall to the same move: write the quantity as a sum of indicators and add the easy expectations, ignoring the dependence you would need for a variance.

Random walks and hitting times

Random walks and their hitting times form the last cluster, and they reward a recurrence rather than a simulation. For a symmetric walk on the integers starting at $k$ with absorbing barriers at 0 and $N$, write $T$ for the number of steps until absorption, and its expectation is

$$E[T] = k\,(N - k)$$

so a walk starting in the middle of a wide interval runs for a time that grows with the square of the width. You derive it by conditioning on the first step and solving the resulting difference equation, the same method that gives the ruin probability $(N-k)/N$, and recognizing that a problem is a disguised random walk is most of the work of solving it.

System design interviews

A system design prompt starts underspecified on purpose, so drawing boxes before naming load, guarantees, and failure tolerance creates an architecture for a problem nobody asked. The round is a system design interview.

It grades whether the candidate can find the binding constraint and defend a tradeoff, because the wrong constraint makes every later component choice look more precise than it is.

Scale before boxes

Before drawing a single box, you establish the scale and the requirements, because a design is only correct relative to a load and a set of guarantees. Ask what the read and write rates are, how big the data is, what latency the product promises, and what it is allowed to lose in a failure, and only then start sketching. A candidate who draws an architecture before pinning these numbers is designing for an imaginary system and will defend choices that the real requirements would have ruled out.

Finding the binding constraint

The heart of the round is naming the bottleneck and designing against it, since every interesting system has one resource that runs out first and the rest of the design follows from protecting it. Say which constraint binds, whether it is write throughput, tail latency, or memory bandwidth, then structure the design around that rather than distributing equal attention across every component. State plainly what your design gives up, because every real choice sacrifices something and a candidate who claims a design with no downside has either missed the tradeoff or is hiding it.

Serving a model versus serving a page

Where the system is a model, the design departs from ordinary web serving in ways worth stating. A stateless web request is short and cheaply replicated, whereas serving a large model is dominated by the accelerator: a single request can occupy a GPU for the length of a generation, latency is set by sequential token production rather than a database round trip, and the memory holding attention state is often the constraint that binds. Batching many requests together lifts throughput at the cost of individual latency, and autoscaling is coarse and slow because accelerators are expensive and take real time to bring online, so the tradeoffs look almost nothing like those of a stateless service.

Questions to ask

The last minutes of an interview can feel like etiquette, but the interviewer is still watching what the candidate chooses to investigate. Questions to ask are a second sample of judgment.

A concrete question about failure, constraints, or the work itself can reveal both the team’s reality and the candidate’s taste, while generic logistics spends the remaining signal cheaply.

Questions that reveal the work

Asking what would make the team call a project a failure is worth more than any question about culture, because the answer tells you how the team defines success and how honestly it talks about risk. A vague, upbeat reply is itself information about a group that has not thought hard about failure. Asking what constraint the team is fighting right now works the same way, surfacing whether the real obstacle is technical, organizational, or a shortage of the people who understand the system.

Compensation goes to the recruiter

Compensation questions belong with a recruiter, not with the engineers or researchers interviewing you, whose read on your judgment is part of the decision and who cannot change the number anyway. Spending your two or three good questions on pay, level, or start date signals that you have stopped evaluating the work, and it wastes the one moment where your curiosity is on display. Keep the logistics for the person whose job is logistics.

What their answers tell you

The answers you get are a read on whether to accept, and they are more candid here than anything a recruiter will tell you. A team that answers the failure question concretely and disagrees with itself in front of you is showing you a healthy culture, while one that closes ranks and recites the mission is showing you something too. Treat the closing questions as your own diligence, since the interview runs in both directions and the same hour is your best chance to price the job.

Where candidates lose

A strong candidate can lose the room without exposing a knowledge gap: silence hides the reasoning, a prepared story misses the actual prompt, and a group accomplishment collapses under follow-up.

Where candidates lose is often the communication layer around the work. Once the interviewer cannot attribute the claim or see the reasoning, the underlying ability becomes harder to credit.

Silence and the prepared answer

Long silence while thinking is the most common self-inflicted wound, because the interviewer cannot see your reasoning and a quiet pause reads as being stuck. The fix is to externalize the search: say what you are considering, what you have ruled out, and where you are heading, so a pause becomes visible progress rather than a stall. An interviewer who can follow your thinking can also throw you a rope, and one staring at a silent candidate has nothing to grade.

Answering the question you prepared instead of the one you were asked is the next most common, and it is fatal in a behavioral round where the interviewer chose the prompt for a reason. Under stress a candidate hears a familiar keyword and launches a rehearsed story that answers a neighboring question, which tells the interviewer you are pattern-matching to your script. Listen to the actual question, and if you want to reframe it, say so out loud and get agreement before you redirect.

Credit and overclaiming

Claiming credit for a team’s result and then failing the follow-up ends interviews at every firm that probes for specifics. Saying “we” until nobody can tell what you did invites the question of what you personally contributed, and a candidate who cannot answer has converted a group success into a personal doubt. Use “we” for the parts the team did and “I” for the parts you did, and keep the boundary sharp enough to survive three follow-ups.

Overclaiming familiarity with a method you cannot derive is the technical version of the same mistake, and it is easy for an interviewer to expose. Say you know a technique and a competent interviewer will ask you to derive a piece of it or state where it breaks, so a confident claim you cannot back turns curiosity into distrust of everything else you said. Claim what you can reconstruct under questioning, name the edge of your knowledge honestly, and let the boundary be a real one, because an interviewer trusts a candidate who admits the limit far more than one caught bluffing.