There is so much advice online about how to polish your resume, and yet so many resumes are still bad. How can this be? I think most people think they’re following the standard resume advice even when they’re actually still getting it wrong. It can be very, very hard to take off the blinders of your own experience. Of course everything you’ve done makes sense to you.
Writing a good resume takes much more time and effort than most people assume, and it’s important to get it right. Your resume provides the building blocks for the story you want to tell, both in your interview and in your cold email. A good resume doesn’t just help you get your foot in the door: it trains you on how to package your story such that you perform better through the entire interview process.
Below, I’ll walk through specific examples from real resumes and show you exactly how the job-seeker improved them. My hope is that looking at these concrete examples will help you spot the flaws in your own resume.
The first step to writing a good resume is to be as specific as possible. You want to be as detailed as you can (while still being concise) and ensure you highlight the tools you’ve used and the skills you’ve employed in the past.
Go through every bullet point on your resume and break it down word by word. Are the words you’re using specific enough? Can you add references to tools and programming languages you’ve used? Are there opportunities to add descriptive adjectives to help give the reader more context? Get as descriptive as you can, and worry about editing for length later.
Here is an example in improved specificity from Olga Krieger, who is currently on the data science job market. Note the level of work we put in to crafting a single bullet point on her resume (this stuff takes time!).
“Captured key data points from a variety of sources into a structured data library.”
This bullet point tells me nothing. I have no idea what this project involved or why it mattered. I had a lot of questions for Olga in my initial feedback. I asked…
- What were the “key data points”? Why were they key?
- How many sources was it? Phrases like “over a dozen” are good here.
- What kind of library did you create? Was it some kind of database (what kind?), or something else?
- What does “capturing” mean? How did you capture them, what tools did you use? Being specific will make anything you did sound more impressive.
You can see that I am very exacting in my questions. You need to be tough on yourself to get the resume right.
Here’s the revised version of the same bullet point that Olga came back with:
“Collected crypto projects’ information (key personnel, tech overviews, fundraising details, github metrics), validated their disclosures, and conducted fundamental analysis (token distribution, monetary policy) to build a comprehensive market intelligence tool: an S&P for crypto.”
This is much better! I actually understand what she’s talking about here and what type of analytical work this project required. Now it sounds like she actually did some work, and gained a ton of complex domain knowledge in the process. A “comprehensive market intelligence tool” sounds very useful! Sign me up.
This bullet could be edited further to remove the parentheticals, but it clears the high bar of communicating with specificity. As you make your resume more specific, you should be as descriptive as you can first—you can always trim it down later.
To get more specific on your resume, try these tips:
- Specify tools and programming languages. Instead of saying “Built an [x] that did [y]”, say “Using [TOOL], built an [x] that did [y].”
- Add clauses that convey the impact of your work. Instead of saying “Did [THING]”, say “Did [THING], thereby achieving such-and-such impact.”
- Use specific words instead of broad, imprecise words. Instead of saying something like like “Captured data”, use more specific words, like “Scraped data” or “Collected data” and specify (for example) where the data came from: “Scraped data from 32 websites”, “Collected data from 18 municipal open data sources.”
- Don’t speak ambiguously about something non-technical you did in order to make it sound more technical. Be honest, straightforward, and specific. Your non-technical work matters, too! I’d always rather see a highly specific description non-technical work than an ambiguous, unilluminating description of anything.
- Use numbers. You probably know you should use numbers to convey the impact your project had (e.g., “increasing revenue by 10%”), but you can also use them to describe the process of your work. For example, give us a sense of the amount of data you had to wrangle or amount work you had to do, e.g., “from dozens of data sources,” “from 4 different APIs,” “to create a database of 10 million rows.”
- Specify the exact process you used. Instead of saying “Did [x]”, say “Did [x] using [PROCESS].” You can achieve this via the technical name of your process (e.g., “Built a recommendation engine using collaborative filtering”), but it’s often more powerful to describe that process in colloquial, jargon-free terms (e.g., “Built recommendation engine that used weighted averages of features to predict the best products for each user”). Explaining your work in colloquial terms demonstrates that you have a deep understanding of the process you used. Still, technical buzzwords can be eye-catching, so aim for a balance of both these approaches.
- Add descriptive adjectives. Every time you see a noun on your resume, ask yourself: “What kind of [NOUN]?” What kind of models? What kind of input? What kind of stakeholders? What kind of result? Your adjectives add color to your resume and help shape the impression you give to the reader.
Many resumes leave out the why of the described project. They don’t communicate the motivation for the project, why it mattered, or what was causing the problem the person set out to solve. Meanwhile, they gloss over the mechanics of the models built or the tools used, so the reader has no context for how hard the problem was or what skills the job-seeker had to leverage in order to solve it.
Here’s an example from Olga’s resume where context was missing.
“Deployed models into production using AWS (SageMaker, EC2, ECS, ECR).”
- Which models?
- How did you do it?
- You can rephrase this to be more active: “Built [whatever kind of pipeline—ETL, deployment, Docker, whatever] pipeline to deploy [such and such] machine learning models into production.”
Here’s Olga’s revised bullet point:
“Built a deployment pipeline to train and host ML models using Python, Docker, and AWS (SageMaker, EC2, ECS, ECR), allowing users to get content-based recommendations in addition to simple filtering”
There are two layers Olga added here that provide additional context. The first is that she “built a deployment pipeline to train and host ML models.” Why did she build the pipeline? To train and host the models. Here Olga uses a formulation that you can use to get to the heart of the why on your own resume: Find every instance where you say you “Did [x],” and add the phrase “in order to…” Whatever comes after “in order to” is the beginning of your answer to why.
Second, Olga explains that this project “[allowed] users to get content-based recommendations.” This phrase explains *why* the project mattered. Now I know that she didn’t build this pipeline in a vacuum: She built it to solve a problem, and I know what problem she solved. A hiring manager now has the proper context to understand this project and assess how it relates to the position they’re hiring for.
Give context: part 2
Most people know less about your past field than you do. This is true whether your last job was managing a restaurant or researching a very obscure area of particle physics. Your resume needs to acclimate your reader to your niche of past experience in a concise, compelling, digestible way. I should not have to Google any terminology in order to understand your resume.
Another aspiring data scientist I know had a bullet on his resume that started like this:
Performed comparative analysis of literature on automatic synthetic scene generation.
Well, that sounds very impressive…but I have no idea what automatic synthetic scene generation is! All I get from this bullet point is, “well, that sounds complicated.” A hiring manager is going to have a hard time understanding just how impressive his work was or how the skills he leveraged there might translate into the job they’re hiring for.
Any time you mention [obscure research term / piece of insider jargon], just tack on a 3-5 word phrase describing what that term means. Like this:
Performed comparative analysis of literature on automatic synthetic scene generation, [3-5 word description of what automatic synthetic scene generation is].
Yes, cramming your entire discipline into 3-5 words is probably going to be harder than it looks. It will probably take 4-5 drafts of this short phrase to get it right. Like I warned you above: perfecting a resume takes a lot of time!
I’ve made this mistake myself. For years, I had a research project on my resume that referred to “CPT transformations.”
“What are CPT transformations?” someone asked me once. I updated the resume to clarify that they were “charge, parity, and time transformations.”
This was silly: I was still using language that only a particle physicist would understand! All anyone took away from that sentence was “huh, sounds complicated.” They were missing everything profound and interesting about the problem because I just wasn’t explaining myself.
Here’s how this project reads on my LinkedIn profile now:
Under guidance of OW Greenberg, proved the noncommutativity of charge, parity, and time reversal transformations (CPT), contrary to the current understanding of fundamental particle physics.
I don’t explain the nuts and bolts of what I did, but I do give the context that our work challenged the established order (“contrary to the current understanding of fundamental particle physics”). This phrase does double-duty by also clarifying the field of research involved here (“particle physics”), which most readers will have at least heard of.
The “under guidance of” phrase plays an interesting role here. Some might think that exposing the fact that I had guidance would sell my work short. But in fact, being upfront about the fact that I worked 1:1 with a (very famous) professor actually helps sell the fact that the research we did was groundbreaking. Without that phrase, a reader would probably assume that I couldn’t have been doing groundbreaking physics research all on my own at age 22, and so they would discount the project. Being 100% clear about the fact that I didn’t do this alone suggests that the work would be too hard for me to do alone—which actually helps me.
Had I tried to oversell the project by masking Dr. Greenberg’s involvement, I would have undersold the work. Overselling often leads to underselling. It’s always better just to be specific, honest, and clear.
Focus on impact
You’ve surely read this tip in resume advice blogs before: Don’t just say what you did, but say why it mattered. What impact did your work have on your team, on the company, on the world? It’s ideal if you can quantify that impact.
Most people look at their past experiences and think the impact cannot be quantified. But the vast majority of work is quantifiable in some way—as a data scientist, you above all people should believe this! You should start by determining if you can quantify, say, a specific dollar amount of revenue generated, an estimated range of boost in the percentage accuracy of predictions (“by 10-15%” is a great phrase), or a savings of a certain number of man-hours.
But if the project doesn’t lend itself to these kinds of straightforward quantifications, focus on finding a way to convey the scope of what you did. Quantify how much data you gathered, or how many people on the team you supported. Give us a sense of how important this work was.
Most importantly, remember that getting the right number is only part of the story. Your impact is your grand conclusion: What was the result of all this hard work you did? Why, ultimately, did it matter?
Here’s an example of crafting impact from Olga’s resume:
“Improved recommendations from the content based engine by reconstructing user taste profiles.”
- How did you reconstruct them?
- What was the impact of the improvement? What percentage, what dollar value, etc?
Here’s how Olga updated the bullet point:
Improved recommendations by reconstructing user taste profiles, taking in an average of multiple weighted items instead of a single item, thereby increasing user engagement in geometric progression.
This is a classic example of showing, not telling. Now Olga doesn’t just tell me that she “improved recommendations”, she shows me that her improvement had the impact of “increasing user engagement in geometric progression.” My only quibble here is I’d like to have seen some actual percentage number on the increase. If that’s not possible, using slightly more specific language in place of “geometric progression” would achieve the same result. But this is miles ahead of where the bullet point started.
Notice that Olga also improves this bullet by giving the context: she improved the recommendations by “taking in an average of multiple weighted items instead of a single item.” This clarifying clause gives us insight into how she solved the problem (and it does so, once again, by being specific!).
Here are some other examples from Olga’s resume where she was able to quantify her impact…
Coordinated with a team of remote analysts to aggregate the first version of a data library of validated token disclosures for which listed token projects are now paying $10K per year.
Streamlined processes (weekly recaps, new data entry, and schedules), saving 15% of office’s time.
Built a model explaining 0.83% of bitcoin price variance using time-series data and Twitter API.
Created a 7GB sqlite database stack from scratch, incorporating open data sets from health regulators.
Lead a team of 4 data scientists organizing weekly calls and tracking goals and lessons learned.
In collaboration with 1 other data scientist, built the first version of a collaborative filtering recommender system using explicit and implicit user feedback.
Notice how sometimes Olga quantifies the result of her project, but other times she just conveys the scope by mentioning (1) data size, (2) the size of the price fluctuation she modeled, or (3) the number of people she worked with. These are all smart ways to build a picture in the reader’s imagination of what the work looked like, how challenging it was, and what impact it had.
Keep in mind, also, that lots of data science projects are liable to fail. Some projects only ever get to 70% accuracy. I love to see a specific number on a resume, even if it’s low. Specificity adds validity to a resume regardless of what is actually being specified: if you did the project and only got to 70% accuracy, then at least I know you know how to measure outcomes!
Impact isn’t just about the result you produced. Impact can also mean giving the reader a sense of the role you played within the larger company.
Another data scientist I worked with, Perry, had a past job at a hedge fund. On his resume, he described his hedge fund experience like this:
Analyzed and determined the quality of investment strategies with out-of-sample testing before implementing them into our portfolio.
This description was missing something. I knew from speaking from Perry that he had been the only analyst on his team. His description didn’t give a sense of how scrappy and independent he had to be in this role. In my feedback, I wrote…
- For your hedge fund experience, I would recommend saying something like “Sole analyst at a hedge fund with $X under management” or something to give the scale of the company. If you aren’t comfortable with a dollar number, you could even do “Sole analyst on a team of x,” to give some feel that you were scrappy and independent in this environment.
Perry added a bullet to this effect:
Sole analyst on a team of seven that was focused on identifying investible market opportunities via algorithmic trading.
This information gives me a much better sense of the impact he must have had on the team and on the broader company: he was the only person doing what he did. As a hiring manager, someone like that—who can work independently, support the rest of the team with a unique skill set, and still drive value—jumps to the top of my list.
Notice that Perry found a way use numbers to give us a sense of his impact: he specifies that is was “a team of seven.”
It’s okay to solve a problem
When my sister was revising her resume, a friend with a background in HR looked it over for her. This friend cautioned my sister against mentioning a time when she solved a problem at her last company, saying that she should avoid descriptions that could “make the company look bad.” This is some of the worst advice I have ever heard.
Every company has problems. The company you’re applying to surely has problems! Spotting problems and fixing them is the entire point of your job. It’s incredibly powerful to highlight instances where you took the initiative to solve a problem or fix a broken process.
Here is the example from my sister’s resume that that HR professional lacked the insight to appreciate:
After noticing that manual lead entry was costing the company 20-35 labor hours weekly, independently researched and implemented an automated process using a PDF parser and Excel.
Note how this bullet point tells a story: she starts with how she noticed a problem, then independently pursued a solution, which she finally implemented. The word “independently” is catnip for hiring managers—believe me, I dream of hiring people who do not have to be told what to do.
My sister follows other good resume-writing practices here: she quantifies her impact (“costing the company 20-35 labor hours weekly”) and she specifies the tools she used to implement her solution (“using a PDF parser and Excel”). She’s not in the tech industry, but this is the kind of person I want to hire: she saw an inefficient, laborious process and she fixed it without anyone even asking her to. That’s hugely impressive and a character trait that any company would appreciate.
Don’t downplay your work
I’ve noticed that many resume-writers don’t get specific on what they’ve done because deep down, they think their past work wasn’t that interesting or impressive. Perhaps a dirty secret of work is that everyone thinks this way about themselves. The people who are most impressive to you probably are not that impressed with their own achievements. Once you’ve actually done something, it often seems trivial.
So here is a counterpoint: if a company paid you to do something, your work must have been meaningful or impactful in some way. No company is dumb enough to pay its workers to do nothing 100% of the time. Even if you did unpaid work through school or through an internship, your school or company still used the time and resources of paid employees to enable you to do that work. So ipso facto, the work you did must have mattered somehow. If we’re talking about a personal project: well, you didn’t give up halfway through; you kept investing your time to finish it—so it must have had some value.
So approach your resume with the acknowledgement that none of your time has been wasted. Everything you have done has been building somewhere. Unburden yourself of the mental framing that your last project “wasn’t that interesting” or some task you performed “wasn’t that hard.” Your character traits come out in the work you do, even if it is trivial work. Your skills are put to use in your personal projects, even if you lack the resources to take them as far as you would like. So discard your urge to downplay your work or trivialize it. Find the little nuggets of gold in your past experience—the times where you were able to shine, the times you broke through some kind of barrier, the times where you really had an impact—and polish those in the detail that they deserve.
Keep in mind that the hiring manager is not reading your resume to judge you, but to understand you. Be clear and specific, and paint them an interesting picture.