What a finance technical interview is really checking

The four question types that recur across finance and risk interviews, what a good answer sounds like, and how to recover when you do not know.

The short answer: Technical interviews in finance and risk roles draw from four question types, and knowing which one you are in tells you what a good answer sounds like. Definitional questions want a crisp definition plus why it matters. Mechanical questions want a walk through a calculation with the assumptions named. Judgement questions want a reasoned position, not a correct answer. Estimation questions want visible arithmetic and stated assumptions rather than a right number. The single most valuable habit across all four is thinking out loud, because the interviewer is assessing your reasoning and cannot assess silence — and the recovery when you do not know is to say so and then reason toward the boundary of what you do know.

Key points

Four question types — definitional, mechanical, judgement, estimation — and each has a different shape of good answer.
Think out loud throughout: an interviewer scores reasoning, and a correct answer arrived at silently evidences almost nothing.
Name your assumptions before you calculate. An answer with stated assumptions can be corrected; one without them can only be wrong.
"I do not know, but here is how I would work it out" scores far better than a confident guess that turns out to be wrong.

Four question types, four shapes of answer

What each question type is testing, and what a good answer contains
Type	Example shape	A good answer contains
Definitional	"What is duration?"	A one-sentence definition, then why it matters to someone doing this job
Mechanical	"Walk me through how you would size this facility"	The steps in order, the assumptions named, the sanity check at the end
Judgement	"Would you lend to this borrower?"	A position, the two or three factors that drove it, and what would change it
Estimation	"How much does this portfolio lose in a downturn?"	Visible arithmetic, stated assumptions, a plausible order of magnitude

Misreading the type is the most common way a well-prepared candidate answers badly. A judgement question answered with a definition sounds evasive; a definitional question answered with a fifteen-minute discussion sounds unfocused. If you are unsure which you are in, ask — "do you want the definition or how I would apply it here?" is a good question, not a weak one.

Thinking out loud, and why silence costs you

The mark sheet in a technical interview usually has more lines about approach than about the answer. That is not generosity; it is because the job involves reasoning through unfamiliar problems, and an interviewer who cannot see your reasoning has no evidence about the thing they are hiring for.

So narrate. State what you are being asked, what you will assume, what you will calculate, and what would make you doubt the result. It feels laborious and it is the single highest-scoring habit available. It also gives the interviewer somewhere to intervene: most will correct a wrong assumption early rather than watch you build on it, and that only happens if the assumption was spoken.

The same estimation question, narrated and not

Question: Roughly what share of a retail loan book might be in arrears in a bad year?
Silent answer: "Maybe five percent."
Narrated answer: "I will assume unsecured retail, so higher than a mortgage book. In a normal year I would expect low single digits; a bad year might be two to three times that, so mid-to-high single digits. I am assuming no policy change and no large concentration. If it were secured I would halve it."

Both give a similar number. Only one of them shows the model behind the number, and only one can be corrected mid-answer — which is the difference between a candidate who is easy to work with and one who is not.

Preparing twenty concepts rather than two hundred questions

Technical preparation collapses to a short list if you organise it by concept. Take the twenty ideas your target function actually uses daily and be able to explain each one twice: once to a colleague, once to an intelligent person who does not work in finance. The second version is the harder and more useful one.

For a credit role: probability of default, loss given default, exposure at default, security and its limits, covenants, cash-flow versus asset-based lending.
For a markets role: yield and price, duration, the shape of a curve, what a hedge does and what it costs, liquidity versus solvency.
For a risk role: the three lines of defence, inherent versus residual risk, appetite and limits, what a control actually is — see risk career paths.
Across all of them: the time value of money, and why the same cash flow is worth different amounts at different dates — the mechanics are in real versus nominal returns.

Frequently asked questions

What happens if I genuinely do not know the answer?

Say so, immediately and without apology, then show the boundary of what you do know and how you would find the rest. "I have not worked with that instrument directly. What I know is that it behaves like X in this respect, so I would expect Y — is that the direction?" That is a strong answer. A guess delivered confidently is the weak one, because it tells the interviewer they cannot rely on you to flag uncertainty.

How much detail is expected at graduate level?

Considerably less than candidates fear on content, and rather more than they expect on reasoning. A graduate is not expected to know how a specific model is calibrated. They are expected to explain what a discount rate does, why a number moves when an input moves, and to notice when an answer is implausible. Precision about the basics beats vague familiarity with the advanced.

Should I memorise technical question lists?

Use them to find your gaps, not to prepare answers. A memorised definition sounds memorised, and the follow-up — "why does that matter for this business?" — is not on the list. Better to take twenty core concepts and be able to explain each one to a smart person outside finance, because that is the same skill the interview is testing.