Building a Public Research Portfolio

A resume line that says "backtested a mean-reversion strategy on equities" is a claim. A GitHub repo with the data pipeline, the backtest code, the equity curve, and a paragraph honestly admitting where the strategy breaks down is evidence. Hiring managers at quant desks read hundreds of resumes that all say roughly the same things. A portfolio is the one part of an application they can actually inspect, and it is often the deciding factor between two candidates with similar grades and similar interview scores.

This is not the same as a CV — see Writing a Quant CV for that. A portfolio is the underlying work the CV summarises.

What a reviewer is actually checking

Nobody on the other end is grading whether your strategy makes money. Almost none of them do, out of sample, and everyone reading knows that. What they are checking is whether you understand why it might not, and whether your process would catch that before you found out the hard way. Three questions dominate, in order:

1. Did you avoid the obvious traps? Look-ahead bias, survivorship bias, and treating an in-sample Sharpe as if it were a forecast — see Backtest Overfitting. A single sentence acknowledging a limitation is worth more than a polished chart with none.
2. Can you write? Not literary writing — clear writing. Can a stranger follow your logic from question to method to result in five minutes without opening the code?
3. Is the code something a colleague could pick up? Not production-grade, just readable: sensible file names, a README, no 4,000-line notebook with dead cells.

None of these require an original discovery. Replicating a published result carefully, and being honest about where your replication diverges, demonstrates all three qualities better than a "novel" strategy with unchecked bugs. See Replicating a Published Strategy.

Anatomy of one project

A single strong piece has five parts, in this order:

Section	What it contains	Length
Question	One or two sentences: what you were trying to find out	2 sentences
Data and method	Source, sample period, universe, and how you built the test	Half a page
Result	The headline number, with a chart, plus the number that would appear if you had done it wrong	Half a page
Limitations	What would break this in live trading — costs, capacity, regime dependence	Half a page
Code	A linked repo, runnable end to end	—

The "result done wrong" row is worth dwelling on. If your final Sharpe is 1.4 after transaction costs, show the reader that it was 2.6 before costs, or 3.1 with look-ahead in the universe construction. Showing the gap between the naive and the careful version proves you know where the naive version comes from — which is the entire skill being assessed.

Worked example: one project, two drafts

A candidate wants to show a pairs-trading strategy on US regional banks. The first draft: a notebook titled pairs.ipynb, a plot of cumulative returns climbing steadily to +38% over two years, no mention of costs or the entry rule's parameters. A reviewer skims it in twenty seconds and moves on — there is nothing to evaluate, only a claim.

The second draft, after a week of revision: a README stating the question ("do co-integrated regional-bank pairs mean-revert faster than the sector average, net of costs?"), the universe (46 regional banks, 2015–2023, delisted names included to avoid survivorship bias), the method (rolling co-integration test, entry at 2 standard deviations of the spread), and three results side by side — gross of costs (+38%), net of a conservative cost model (+9%), and net of costs with the co-integration re-tested out-of-sample each quarter rather than fixed once (+4%, Sharpe 0.6). A closing paragraph states plainly that the strategy's capacity is small, since regional-bank pairs are thin, and that the edge shrank each time a more realistic assumption was added — which is itself the honest finding.

The second draft takes longer to write and reports a far less exciting number. It is also the one that gets a callback, because it demonstrates the exact skill the desk needs: knowing how much of your own edge is real.

How many, and how public

Three finished pieces beat ten unfinished ones. A single incomplete notebook per idea signals scattered effort; three complete write-ups, each with a stated limitation, signal judgment. Post the code publicly (a personal site or a code-hosting repo is enough — no polish required) and be prepared to talk through any line of it in an interview, since a reviewer who likes a piece will often open it live and ask you to walk through a design choice.