How to write a good CV
Szymon Kopyciński, Gabriel Bridger, Bilal Naheem · 29 September 2026
How to write a good CV, in general, with simple to follow principles.
Intro
CV advice tends to sound like a recipe, when really it should be a set of guidelines.
"Use action verbs, add numbers, keep it to one page, mention leadership, list your skills", etc. etc.
All of these can be sensible advice, but they are also very easy to follow badly. Adding a percentage to every bullet does not automatically make a CV good, and neither does describing yourself as "results-driven". Results-driven tells me nothing, what results??
The three Directors at NEFS Quant come from fairly different backgrounds. Between us, our CVs lean towards software and infrastructure engineering, quantitative research, trading, and finance. None of us wrote our CVs together, yet when putting them side-by-side, there are quite a few points of overlap which we all arrived at independently.
This post covers those common ideas.
It is primarily aimed at students applying for internships and graduate roles in quantitative finance, trading, research, software engineering and adjacent areas. There is no single perfect CV, but there are some very good ways of making yours easier to read and, more importantly, giving the reader something worth reading.
This post is based on the 2026/2027 year Director CVs, Szymon, Gabe and Bilal. Some of the passages in this article are inspired by their actual CV content.
Start with a very boring template
Your CV does not need gradients, skill bars, profile photos, icons everywhere, or a two-column layout carefully assembled in Canva. Bluntly speaking, they won't help you out. For most of the roles our members are likely to apply for, the content matters far more than making the document look unusual.
All three NEFS Quant Directors use some variation of Jake's Resume, a simple single-column LaTeX template.
Template: Jake's Resume on Overleaf
The original template is by Jake Gutierrez, is based on the sb2nov/resume template, and is published under the MIT License.
There is a reason the format is popular: it is compact, predictable and leaves most of the page for the thing that actually matters, what you have done.
You do not have to use Jake's Resume, and you definitely do not have to use LaTeX. The more general lesson is to keep the presentation simple.
Make sure a machine can read it too
Before your CV reaches a person, there is a decent chance it will pass through an Applicant Tracking System (ATS).
There is a lot of slightly ridiculous advice online about "beating the ATS", as though somewhere inside Goldman Sachs there is a single evil regex deciding your future. That isn't (necessarily) the case.
Different employers use different systems in different ways. The useful takeaway is much simpler: do not make your CV unnecessarily difficult for software to parse.
This is another reason we like boring CV templates.
Use a simple, preferably single-column layout. Use obvious section headings like Education, Experience, Projects and Skills. Avoid putting important information inside graphics, text boxes, charts or elaborate tables. Your name being rendered in beautiful vector art is considerably less useful if the parser decides you don't have one.
Make sure the PDF actually contains selectable text rather than effectively being an image, and if an application explicitly asks for a particular file format, use it.
Keywords matter too, but this does not mean dumping every word from the job description into the bottom of your CV in white text.
If a role repeatedly asks for Python, C++, Linux, options, statistics or market microstructure, and you genuinely have experience with those things, your CV should probably use those terms somewhere. There is little benefit in describing something using unnecessarily vague language when the employer has already told you what they call it.
This is also a good reason to make small changes to your CV between applications. You do not need to rewrite the entire thing every time, but if two accurate ways of describing your experience exist, use the terminology that makes the relevance obvious.
Write for the human who will eventually read your CV, just make sure the machine can somewhat read it too.
Evidence beats adjectives
A CV is, fundamentally, a collection of claims about you.
The easiest way to make those claims convincing is to provide evidence.
Compare:
Built scalable market-data infrastructure.
with:
Architected a multi-venue market-data platform processing 5B+ order-book deltas per day, sustaining 50k+ messages/s.
The first tells the reader that you think the system was scalable. The second gives them enough information to come to that conclusion themselves.
The same applies outside software engineering. Instead of:
Built a statistical arbitrage strategy.
you might have:
Screened 3,000 equity-pair combinations using Engle-Granger cointegration and ADF residual tests, identifying five statistically mean-reverting pairs with sub-30-day half-lives.
And instead of:
Improved the speed of a data pipeline.
you could say:
Architected a blockchain-based extraction pipeline, reducing backfill time by 99.8% versus the public API.
Notice what is missing from all three: hard-working, analytical, innovative, results-driven.
Saying you are "analytical" is cheap, it's better to prove it.
Numbers are context, and shouldn't be decoration
You will often hear that every CV bullet should contain a number. That's not quite the point.
Numbers are useful when they communicate something meaningful about scale, performance, impact, selectivity or difficulty.
Processing, say, 5 billion orderbook messages per day tells us something about scale. Reducing a process from four minutes to 17 seconds tells us something about impact. Finishing 128th out of 19,000 teams tells us something about performance. Being selected from 400 applicants tells us something about selectivity.
On the other hand:
Worked in a team of four people.
is not automatically an impressive bullet because it contains the number four.
Do not go hunting for arbitrary percentages to satisfy some imaginary CV formula. Ask what information would help a reader understand why the work was difficult or useful, and quantify that where you reasonably can.
Also make sure you can defend every number you include. If you claim that something reduced latency by 70%, there is a fair chance an interviewer will ask how you measured it.
That should be a question you are happy to answer.
Explain what you actually did
Results matter, but so does the mechanism that produced them.
Consider:
Reduced data-loss windows from 40 minutes to 30 seconds.
That is already fairly good. But:
Engineered a canary worker handoff, reducing per-replacement data-loss windows from 40 minutes to 30 seconds p99.
is much more informative.
We now know both what changed and how it changed.
This becomes particularly important for technical and quantitative applications, where the interesting part of a project is often your reasoning. Mentioning things like:
- PCA
- cointegration
- order-book modelling
- asynchronous workers
- optimisation
- execution logic
or whatever else was genuinely important to the work gives an interviewer something to grill you about. Which is good. Unless you didn't prepare for your interview...
A useful mental model for a bullet is:
What you did → how you did it → why it mattered.
You will not always fit all three cleanly into one sentence, and forcing the formula can make your writing worse. But strong bullets will usually answer at least two of those questions.
Projects count
A common problem for students is the circular one:
I need experience to get an internship, but I need an internship to get experience.
Fortunately, an employer does not need to have paid you before you are allowed to demonstrate that you can do something.
Across our three CVs you will find independent quantitative research, trading competitions, an exchange implementation, systematic strategies, portfolio analysis, infrastructure projects and society work alongside conventional employment.
A serious project can be some of the strongest material on a student CV. The important word there is serious.
"Implemented a textbook pairs-trading strategy on a handful of equities and reported its in-sample Sharpe" is probably not giving a quant researcher much to ask you about.
Taking the idea further might.
What happens after transaction costs? Why did you choose those parameters? Does performance survive out-of-sample? What happens in different volatility regimes? What assumptions have you made about execution? How sensitive are your results to those assumptions?
The project does not have to make money. It does not even have to work.
Finding out that an idea fails, working out why, and being able to explain the process can demonstrate far more ability than producing a suspiciously perfect equity curve.
The same applies to engineering. A project becomes much more interesting when you have encountered actual design decisions, constraints, failures and trade-offs.
Oftentimes, you'll learn more when something fails than when it succeeds. That's decent advice in itself.
A title is not an achievement
Being President, Director, Treasurer, Analyst or Team Lead can be useful context.
It is not, by itself, evidence that you were good at anything.
Compare:
Director of a quantitative finance society.
with something closer to:
Designed and delivered a quantitative finance programme across three specialist tracks, managing five senior analysts delivering weekly sessions in Python, probability and market making.
The title tells us where you sat in an organisation. The bullet tells us what happened because you were there.
The same principle applies to internships. "Software Engineering Intern at X" already appears immediately above your bullets. There is very little value in using the next line to tell the reader that you "worked as a software engineering intern".
You need to be able to prove you aren't larping the title.
Your skills section is not evidence
Putting Python at the bottom of a CV does not tell somebody how good you are at Python.
Putting C++ (Advanced) does not solve this problem either.
The strongest evidence for a skill should generally appear elsewhere on the page.
Self-assessed skill levels are particularly awkward because there is no common scale. One person's "advanced" is another person's "intermediate", and the interviewer has no idea which definition you are using.
If you list Python, ideally the reader has already seen you use Python to build a backtester, analyse financial data, implement an execution strategy or develop production infrastructure.
If you list SQL, it helps if there is evidence that you have actually worked with a database.
The Skills section then becomes an index of technologies you have already demonstrated, plus a concise place for relevant tools that did not naturally appear elsewhere.
This also means that collecting technologies for the sake of making the Skills section longer is not particularly useful.
Knowing fifteen programming languages badly is rarely more impressive than being demonstrably good at two.
Put the strongest material first
Our own CVs do not even agree on section ordering.
Two of us currently lead with Education. One leads immediately with Professional Experience.
That is fine.
A first-year student whose strongest signals are their grades, university and projects may reasonably put Education first. Someone with highly relevant professional experience may decide that making an employer read through their A-levels before reaching it makes little sense.
Your CV is not a chronological autobiography. It is a document designed to communicate the most relevant information about you quickly, so order it accordingly.
The same applies within sections. Your most impressive project does not have to be the project you happened to start most recently if another ordering communicates your background better. Just make sure that ordering is consistent.
You probably do not need a personal statement
Highly motivated Finance student with a passion for financial markets seeking a challenging opportunity to apply analytical and problem-solving skills...
The recruiter already knows you are a student. They know you are applying for the opportunity. They will probably assume you are at least somewhat interested in it. Those three or four lines are expensive.
Could the same space contain another project? Another two meaningful bullets from an internship? More detail about some research you actually did?
There are situations where a profile is useful, particularly if you are changing careers or need to explain an unusual background. But do not include one simply because you think CVs are supposed to have one.
In simple terms, you shouldn't need a personal statement at the top of your CV, because it should be implied by the content on your CV.
Keep it to one page
For the sorts of student applications we are discussing here, we strongly prefer a one-page CV. That's useful because it means you won't dump 15 bullet sections full of filler words, just to make your CV sound more impressive.
Your GCSE Geography grade probably does not need half a line. A certificate from a two-hour virtual job simulation probably does not deserve more space than a substantial project you spent three months building. The summer job you had four years ago may become less relevant once you have stronger experience.
This is not an invitation to reduce the font to 7pt and remove every millimetre of whitespace. You should always cut weaker content before making stronger content unreadable.
Believe me (Szymon speaking here), I once reduced spacing between my CV sections by 1pt, to fit it all on one page, when I could've just cut a weak line (I had plenty of those as a fresher).
Leave something human at the bottom
There is nothing wrong with having interests.
In fact, all three of our CVs have them.
Poker appears remarkably often. Elsewhere there is climbing, skiing, rugby, powerlifting, golf, cooking and mountain biking.
An Interests section is obviously not going to compensate for an otherwise weak application, but one line costs very little space and gives the person reading your CV something about YOU rather than another technology or module.
Be specific where you can.
"Sport, finance and travelling" does not tell somebody much. "Powerlifting (280kg deadlift)" probably does.
Szymon here again, during an interview at a market making firm I was asked about my interest in poker. Turns out all of the people on the interview panel played poker. That being said, make sure you are actually interested in your "interests", otherwise that convo can get very awkward. That's why I haven't put golf on my CV just yet...
Do not optimise the truth out of your CV
There is a point at which CV optimisation starts making a candidate sound like they personally transformed the global economy during a six-week spring internship. We all know you didn't.
You should present your work well, you should use strong verbs when they accurately describe what happened, you should quantify genuine results, and you definitely should make ownership clear.
But the person interviewing you may spend half an hour asking about a single bullet. That is a feature.
A good CV should contain things you want to be questioned about because you understand them well and genuinely did the work.
- If you say you architected something, be prepared to draw the architecture.
- If you report a Sharpe ratio, know how you calculated it.
- If you claim a performance improvement, know what the baseline was.
- If you mention a model, understand its assumptions.
The goal is not to make every sentence sound maximally impressive. The goal is to make the genuinely impressive parts of your experience easy to see.
A few smaller things that matter
There are a few other things which probably do not deserve entire sections of their own, but are still worth getting right.
Confidentiality
Especially in quant, trading and engineering roles, you may have done genuinely interesting work which you are simply not allowed to describe in full. You must respect that.
Do not break an NDA for the sake of making a bullet sound better. Do not publish proprietary strategy logic, client information, internal PnL, sensitive infrastructure details, private datasets or anything else you were trusted not to disclose.
Instead of describing the exact strategy, describe the class of problem you worked on. Instead of naming confidential counterparties or clients, describe their type. Instead of publishing internal numbers, use an appropriate scale, range or relative improvement if that is permitted.
For example:
Built execution infrastructure for a proprietary systematic strategy, reducing median order-submission latency by 35%.
can still be a strong bullet without explaining the alpha signal, venue logic or every component of the production stack.
Interviewers in these industries understand confidentiality. In fact, showing that you understand where the boundary is is probably better than enthusiastically dumping your previous employer's intellectual property into a PDF - because they don't want it to happen to them.
If you are unsure whether something is confidential, err on the side of caution. Use common sense though: in the example closer to the top of the page on data throughput, that isn't necessarily private information, as it could just be a simple sum of the messages a public data feed emits.
Maths, Further Maths and Olympiads
For students early in university, school-level academic achievements can still be useful.
Strong grades in Mathematics and Further Mathematics, STEP/MAT/TMUA results, maths or programming olympiads, national competitions and similar achievements can all be useful signals, particularly when you do not yet have much university-level experience to replace them with.
The same applies to unusually strong GCSE or A-level results more generally. But their value falls as the rest of your CV becomes stronger.
If you are a first-year with no internships, a strong Further Maths grade or olympiad result may absolutely deserve space. If you are graduating with relevant internships, research and substantial projects, nobody needs half a page devoted to what you did at 17.
Competition results
Trading competitions, hackathons, programming contests and case competitions can be good CV material, but give the result enough context to mean something.
Finished 37th.
tells us almost nothing.
Finished 37th out of 2,400 teams globally.
tells us considerably more.
Percentiles are often useful too:
128th out of 19,000 teams globally (top 0.7%).
If it was a team competition, make that clear. If there were multiple rounds, make clear whether the number refers to the overall competition or one particular stage.
And you do not need to include every competition you have ever entered. The fact that you participated is usually much less interesting than either a strong result or the substantial work you did during it.
Bullet mechanics
The small details matter because inconsistency makes an otherwise good CV look rushed.
You generally do not need to write in the first person. The reader already knows whose CV it is.
So not:
I built a Python backtester which...
but:
Built a Python backtester which...
Use past tense for completed work:
Built, designed, implemented, analysed, reduced.
For genuinely ongoing work, present tense can make sense:
Develop, maintain, lead, research.
The exact convention matters less than being consistent.
Try to start bullets with the thing you actually did. Built, designed, analysed, implemented, optimised, tested and led are usually more informative openings than:
Responsible for...
or:
Helped with...
That does not mean reaching for a thesaurus and turning every bullet into corporate fan fiction. If you helped with something, say so. If you built it, say you built it.
Finally, keep formatting consistent: dates, punctuation, capitalisation, locations, dashes, section spacing and bullet indentation. None of these will get you an internship on their own.
Before you send it
For a final pass, we would check roughly the following:
- Is it one page, readable at normal zoom, and visually consistent?
- Can someone understand the important parts of your background in 20–30 seconds?
- Do your bullets describe what YOU actually did, rather than the general purpose of the company or team?
- Where possible, have you shown scale, impact or performance with meaningful numbers?
- Does the reader understand how you achieved your most important results?
- Are the strongest things you have done receiving the most space?
- Could you comfortably spend ten minutes answering questions about every bullet on the page?
- Have you removed material that exists only because you think a CV is "supposed" to contain it?
- Finally: has somebody else proofread it?
There isn't a single perfect CV. No such thing exists. But there are a few simple things you can do to make a good CV.
NEFS Quant · About · Blog · News & Events · People · Privacy policy