Technical interviews
A technical interview is not a quiz. It is a check that you can reason out loud under mild pressure.
A technical interview for a finance, risk or analytical role is not a quiz, though it is frequently prepared for as one. It is a check that you can reason out loud about the subject matter under mild pressure, that you know what you do not know, and that your working can be followed by someone else.
That reframing changes the preparation entirely. Memorising two hundred questions produces answers that sound memorised and collapse at the first follow-up. Understanding twenty concepts well enough to explain each of them twice — once to a colleague and once to an intelligent outsider — covers far more ground, because the interviewer is probing whether the understanding is real rather than whether the definition is word-perfect.
The same logic runs through the written formats. A timed modelling or case test is marked mostly on structure and judgement, and only lightly on how much you finished, which means the winning strategy is almost the opposite of the instinctive one.
Key terms
- Estimation question
- A question with no retrievable answer, asked to see how you decompose a problem: how large a market is, how much a portfolio might lose. Marked on the visibility of the assumptions and the arithmetic, not on the number.
- Assumptions block
- A single labelled area of a model holding every input that could change. Separating it from the calculations is the one habit that carries most of the structure marks on a timed test, and it is what makes a model checkable by anyone but its author.
- Sanity check
- Asking whether an answer has a plausible order of magnitude before presenting it. Flagging an implausible result yourself scores as judgement; presenting it unremarked scores as a failure to notice, which is the more serious finding.
- Case test
- A written or spoken exercise asking for a recommendation supported by analysis, usually under time pressure. Scored on structure, the quality of the assumptions and whether the recommendation actually answers the question posed.
Frequently asked questions
What do technical interviews in finance actually test?
Whether you can reason about the subject rather than recite it. The questions cluster into definitions, mechanics, judgement calls and estimations, and in every one of them the interviewer is following your thinking. Candidates who narrate their reasoning score well even when they reach an imperfect answer; candidates who answer silently and correctly evidence surprisingly little.
How do I prepare if I am not from a finance background?
Learn twenty concepts properly rather than a hundred superficially, and choose them from what the target function does daily. A career changer who can explain the time value of money, what a discount rate does, and why a secured loan behaves differently from an unsecured one is better placed than a finance graduate who has memorised terminology without the underlying mechanics.
Is it acceptable to ask for clarification?
Yes, and it is usually scored positively. Asking whether a question wants the definition or the application, or confirming what the output of a case should be, is what a competent colleague would do before starting work. What is penalised is asking so many clarifying questions that you never commit to an approach.
How much mental arithmetic should I expect?
Enough that being visibly uncomfortable with it costs you. Percentages, ratios, rough compounding and order-of-magnitude checks come up constantly, usually without a calculator. It is a practisable skill and a week of short daily drills removes most of the anxiety, which is what actually degrades performance in the room.