Technical interviews
Timed modelling tests, and where the marks actually are
What an interviewer looks for in a timed modelling or case test, how marks are usually split, and the habits that lose points before you start.
The short answer: A timed modelling or case test is marked on structure, accuracy, judgement and communication — usually in that order of weight, and rarely on how much you finished. Candidates lose marks before they start by opening the spreadsheet and typing: the first five minutes should be spent reading the brief, deciding the layout, and writing down what the output needs to be. A model that is half-built but clearly laid out, with assumptions in one visible block and a stated conclusion, scores better than a complete one where the marker cannot follow the logic. The most valuable single habit is separating inputs from calculations, because it makes every other mark accessible.
Key points
- Marks are weighted toward structure and judgement, not completeness — finishing is not the objective and rarely the differentiator.
- Spend the first five minutes not typing: read the brief, plan the layout, write down what the answer has to look like.
- Inputs in one clearly labelled block, calculations elsewhere, no hard-coded numbers inside formulas. This single habit carries most of the structure marks.
- Reserve the last five minutes for a sanity check and a one-line conclusion; an unstated conclusion is an unscored one.
Where the marks actually are
Typical weighting on a timed modelling or case test| Criterion | Rough weight | What the marker looks for |
|---|
| Structure | High | Can someone else follow and check this? |
| Judgement | High | Sensible assumptions, and the important ones flagged |
| Accuracy | Medium | The arithmetic holds where it was attempted |
| Communication | Medium | A conclusion, stated, that answers the question |
| Completeness | Low | How much got finished |
Illustrative of the shape rather than any one employer's sheet. The consistent finding is that completeness is weighted lowest and candidates optimise for it hardest.
Once you have seen that table, the strategy is obvious and almost nobody follows it: build less, label everything, and always reach a stated conclusion.
The first five minutes
- Read the whole brief before touching anything. The final paragraph frequently changes the required output, and a model built for the wrong output scores near zero regardless of quality.
- Write the answer shape down. One sentence: "the output is a three-year cash flow with a headroom figure against the covenant." Everything you build serves that sentence.
- Sketch the layout. Assumptions block at the top, calculations below, output at the bottom or on the right. Decide once.
- List the assumptions you will need. Growth, margin, timing, rate. Put them in the block as labelled cells now, even before you know the values.
The last five minutes, which most people spend building
Stop early. The final five minutes are worth more spent checking and concluding than spent adding a section nobody asked for.
- Sanity-check one number. Does the output have a plausible order of magnitude? An implausible figure left unremarked is the worst outcome; the same figure with "this looks high — likely because I assumed X" beside it is a judgement mark.
- Check the units and the periods. Annual rate applied to a monthly period is the most common silent error in timed tests.
- Write the conclusion. One or two sentences: what the answer is, what it depends on most, and what you would check next.
- Label anything unfinished. "Not attempted — would model as Y" is honest and scoreable. Leaving it blank is neither.
The habit generalises well beyond the test. Work that a colleague can pick up, check and extend is the actual deliverable in most analytical jobs, and a timed test is a compressed version of exactly that. Preparing for it properly is not interview theatre — it is a rehearsal of the job, which is why employers keep using it.
Practising for it is straightforward and almost nobody does it. Take a published set of figures — an annual report, a public dataset — set a forty-five minute timer, and build something that answers a question you have posed yourself. The value is not in the model; it is in discovering how long the setup actually takes you, which is invariably longer than expected and is the single thing most likely to cost you marks on the day.
Two mechanical habits are worth building in that practice because they pay in every timed exercise. Get the layout down before any calculation, so the structure marks are secured whatever happens to the clock. And write the conclusion sentence at the halfway point rather than the end — a conclusion drafted while you still have thirty minutes can be revised, while one attempted with four minutes remaining frequently does not get written at all. The same discipline underpins a spoken case interview.
Frequently asked questions
What if I run out of time?
Expected, and usually designed in. The tests are frequently set so that finishing is not realistic, precisely to see what you prioritise. Make sure the part you did complete is coherent and labelled, and write one line stating what you would have done next and what you would expect it to show. That line often scores better than the section it replaces.
How much does formatting matter?
More than seems reasonable, because it is a proxy for something the marker genuinely cares about — whether your work can be picked up and checked by someone else. Consistent number formats, labelled rows, units stated, inputs visually distinct from calculations. It takes almost no time and it is directly on the mark sheet in most structured tests.
Are case tests different from modelling tests?
The medium differs; the marking does not, much. A case test asks for a recommendation supported by analysis, a modelling test asks for a model that produces one. Both reward a stated structure up front, visible assumptions, and a conclusion that answers the question that was asked. [Case interviews](/learn/consulting-careers/case-interviews) covers the spoken version of the same skill.
Published 2026-08-01 · Updated 2026-08-01