The Modelling Test Checks Whether You Can Build Under Pressure
Candidates are given financial statements and a time limit. What is being assessed is structure and judgement far more than formula knowledge.
What the Test Is
A candidate is given source material, typically a set of financial statements or a company filing, and asked to build a model within a fixed time, commonly between one and four hours.
The task varies by role. A banking test may require a three statement model. A private equity test usually requires a leveraged buyout model with returns analysis. An investing role may ask for an operating model and a valuation with a recommendation.
What Is Actually Being Assessed
| Assessed | Weight |
|---|---|
| Structure and clarity | High |
| Reasonableness of assumptions | High |
| Completion within the time | High |
| Ability to explain the output | High |
| Formula sophistication | Low |
Nobody is impressed by a complicated formula. They are looking for a model another person could pick up, follow, and trust, which is what the job actually requires.
The reason structure dominates is that models are working documents used by teams. A model that produces a correct answer and cannot be audited by anyone else is a liability, because the answer cannot be defended when questioned.
The Common Failures
Running out of time. The most frequent failure. Candidates build the early sections in excessive detail and never reach the output, which is the part that matters.
Hardcoding inside formulas. Numbers typed into calculations rather than held in a clearly labelled assumptions section. It makes the model impossible to review and impossible to flex.
No clear assumptions area. Drivers scattered across the model rather than gathered where they can be seen and changed.
Circular references left unresolved. Interest on average debt creates circularity, and handling it without breaking the model requires knowing in advance how you intend to deal with it.
Failing to sanity check. Margins that drift to implausible levels, a balance sheet that does not balance, growth rates that compound to absurd figures.
How to Approach It
Read everything before building anything. Understand what output is required and work backwards to what the model needs.
Budget the time explicitly and reserve the final portion for checks and for the summary output. Arriving at a complete, simple model beats an elaborate incomplete one every time.
Separate inputs, calculations, and outputs clearly, and use consistent formatting so that hardcoded inputs are visually distinct from formulas.
Build the simple version first and add refinement only if time remains. A working model with three revenue drivers is more useful than a half finished one with fifteen.
And check the obvious things at the end: does the balance sheet balance, does cash flow tie to the cash line, are the margins plausible, does the answer make sense.
The Discussion Afterwards
Many tests are followed by a conversation about the model, and this is frequently where the decision is made.
Expect to justify assumptions, to explain what would change the answer, and to state what you would do differently with more time.
Candidates who acknowledge simplifications deliberately made, and explain why, perform better than those who defend every choice as optimal. Knowing the limitations of your own model is the judgement the test is trying to observe.
Preparation That Works
Build models repeatedly from raw filings rather than from templates, under a timer. Speed comes from having done the mechanical parts often enough that they require no thought, which frees attention for the judgement.
Learn keyboard navigation properly. The time saved is meaningful over several hours and it signals familiarity.
And practise explaining a completed model aloud, because that skill is separate from building it and is assessed just as heavily.
The Bottom Line
The modelling test assesses structure, judgement, and completion under time pressure rather than technical sophistication. Most failures come from poor time allocation, hardcoded inputs, and never reaching the output. Build simple and clean, reserve time for checks, and be ready to explain what you assumed and what would change the answer.