From coursework to portfolio: presenting quant work

A final-year student presents a trading strategy to a panel: an equity curve climbing steadily above its benchmark, a Sharpe ratio of 1.8, and a conclusion slide that reads “the model successfully predicts market direction.” The first question from the panel is simple: “what happens in your worst period?” The student does not know. There is no slide for it, because the equity curve on screen was chosen precisely because it never dips. The presentation, built to look finished, has no answer to the one question a reviewer was always going to ask.

This happens constantly in student and early-career quant work, and it is not a knowledge gap about the underlying statistics. It is a presentation habit: building toward a result that looks complete, rather than a result that survives being questioned. The fix is not more polish. It is understanding what a reviewer is actually checking for, and building the presentation around that instead of around the headline number.

What a reviewer is actually looking for

A reviewer — a professor, a hiring manager, a portfolio manager sitting on the other side of an interview — is rarely trying to catch a student in a mistake. They are trying to answer a narrower question: can this person be trusted with a research claim? That question gets answered less by the size of the Sharpe ratio and more by how the candidate responds when the Sharpe ratio is challenged.

Four things a reviewer is checking, roughly in order of how quickly they get to them:

Does the candidate know what their own number means, and what it doesn’t? A Sharpe ratio of 1.8 is meaningless without knowing the sample period, the frequency of annualisation, and whether it is in-sample or out-of-sample. A candidate who can state all three without hesitation has already answered most of the reviewer’s real question.
Did the validation avoid the standard mistakes? A random train/test split on time-series data, a scaler fit on the full sample before splitting, a target built from information not actually available at prediction time — these are the first things an experienced reviewer checks for, because they are the most common way a promising-looking result turns out to be an artifact.
Is the worst case shown, not just the average case? A single equity curve or a single accuracy number hides more than it reveals. A reviewer wants to see the distribution of outcomes across the actual test periods used, not a hand-picked window.
Does the candidate know what they have not tested? A student who volunteers “this was only tested on large-cap US equities over one ten-year window, so I would not claim it generalises to other regimes” has demonstrated more research maturity in one sentence than five polished slides can.

None of these four requires a bigger dataset, a fancier model, or a more elaborate deck. They require the presentation to be built around what the analysis actually showed, including its weak points, rather than around the parts that photograph well.

Show the worst fold, not just the average

If a project used any form of cross-validation or walk-forward testing, the single most useful table a student can present is the fold-by-fold breakdown, not the averaged summary statistic. Consider two projects with the same headline number:

Project	Fold 1	Fold 2	Fold 3	Fold 4	Fold 5	Mean accuracy	Worst fold
A	0.58	0.60	0.57	0.61	0.59	0.59	0.57
B	0.75	0.68	0.62	0.55	0.35	0.59	0.35

Both average to 0.59. Project A is a modestly consistent result. Project B is a model that works well in some periods and collapses in others — a materially different, and materially riskier, finding that the mean alone conceals completely. A student who presents only the mean for Project B is not lying, but they are omitting the fact a reviewer most needs. A student who leads with the fold table, including the worst case, has pre-empted the question before it gets asked and shown they understand why it matters. The article /quantlab/validation/roc-auc-and-worst-fold covers the statistical reasoning behind treating the worst fold as the headline figure rather than a footnote — a habit worth adopting before the first interview, not after a panel asks for it.

A one-slide honesty check

Before finalising any presentation of quant work — a thesis defence, a portfolio piece for a job application, a project readout — run through this list:

State the sample. Universe, date range, provider, and frequency, in one sentence a listener could write down.
State the split. Chronological or random, how many folds, whether purging or embargoing was applied. If this was skipped, say so plainly rather than leaving it implicit.
State the worst case, not just the average, for whatever metric is the headline.
State the cost assumption used in any backtest — commission, slippage — and whether the result survives realistic frictions or only a frictionless simulation.
State one thing not tested. Every project has a boundary. Naming it before a reviewer finds it is what makes the rest of the claim credible.
State how to check it. What would someone need — the dataset, the code, the parameters — to reproduce this number themselves?

This list is short enough to fit on one slide, and doing so is usually more persuasive than an additional slide of extra charts. A reviewer who sees all six points addressed, briefly, trusts the presenter’s judgment more than one who sees a longer deck that avoids the same six points entirely.

Building a portfolio piece, not a coursework artifact

Coursework is graded against a rubric the student never sees in full. A portfolio piece — something shown to a prospective employer or included in an application — is judged against a much simpler standard: would this survive being questioned by someone who does this professionally? That standard rewards exactly the habits above and punishes their absence more severely than a course grade typically would, because a professional reviewer has less patience for a polished result that cannot answer a basic follow-up question.

A practical difference this makes: a coursework project is often written to hit every item on an assignment brief, in the order the brief lists them. A portfolio piece should be restructured around the checkable-report skeleton described in /quantlab/practice/writing-a-checkable-report — universe and data, risk and return, validation with the worst fold shown, backtest, and an honest limitations section — because that is the structure a reviewer already expects, and matching it signals fluency in how real research gets communicated.

What to leave out

A common overcorrection is to try to demonstrate breadth by including every technique attempted, including the ones that did not work. This usually backfires: a presentation that lists eleven models tried before landing on the twelfth reads, to an experienced reviewer, as an unreported multiple-testing problem rather than as diligence. If eleven configurations were tried, that trial count belongs in the methodology section as a stated fact affecting how the final result should be discounted — not as a list of failed attempts presented for their own sake. Fewer slides, each one answering a question a reviewer would actually ask, beats a comprehensive record of the entire search process.

The presentation is the research, once it leaves the room

A result that only its author can defend is not finished research — it is a draft that happens to have a conclusion slide. The gap between coursework and a genuinely presentable piece of quant work closes not through better visuals, but through anticipating the four things a reviewer checks and answering them before they are asked: what the number means, whether the validation avoided the standard mistakes, what the worst case looked like, and what was never tested at all.

Key takeaways

A reviewer is judging whether a candidate understands what their own number means and does not mean, more than the size of the number itself.
Present the worst fold next to the mean for any cross-validated or walk-forward result; two results with the same average can have very different worst-case behaviour.
Run a six-point honesty check before presenting — sample, split, worst case, cost assumptions, one untested limit, and how someone could check the result themselves.
Restructure a portfolio piece around the checkable-report skeleton rather than a coursework rubric; it matches what a professional reviewer already expects to find.
Naming one thing not tested is more persuasive than listing every technique attempted; an untracked list of failed attempts reads as an unreported multiple-testing problem, not as diligence.