Where does your resume lose out?
Pick your role and see.
We have spent years hiring for AI, data and analytics roles. Reading real resumes, we saw where strong candidates lose out, and it is different for every role. None of it is about ability, and every gap is fixable.
What do you do?
Pick the closest match. Each role loses out in a different way, so the gaps, and the fixes, are different too.
Where Data Engineer resumes lose out
Data engineers rarely lack the work. Their numbers read as estimates, the decisions they owned go unstated, and the incident story every interviewer asks for is missing.
Estimated numbers
Over 8 in 10
of the improvements resumes claim, like “30% faster”, are round figures ending in 0 or 5. If they were measured, you would expect only about 1 in 5.
“Reduced processing time by 40%.” “Improved performance by 30%.” About 1 in 4 resumes claim a cost saving, yet only about 1 in 7 put a currency figure anywhere. A round number reads as an estimate, and a reader who doubts one figure starts to doubt the rest.
Optimised ETL pipelines, reducing runtime by 40%.
Cut the nightly orders load from 6 hours to 2 hours 10 minutes by replacing full reloads with incremental merges, on roughly 1.2 TB a day.
An illustrative example.
Where the real number lives
- Orchestrator run history: Airflow, Dagster or ADF task durations from before and after the change.
- Warehouse query history: runtime, bytes scanned and credits used for the queries you touched.
- The cloud bill: the same service a month before and a month after.
- Failure history: incidents, retries and manual fixes per month, before and after.
- If you cannot get the exact figure, give the scale instead: rows a day, TB, events a second. A true scale is more convincing than a rounded improvement.
Ownership
Under 1 in 10
of resumes use the word “owned”. About 4 in 10 say “led”, and more than 1 in 3 say “designed and implemented”.
Most bullets say what the engineer built. Very few say what they were accountable for: the decision they made, the trade-off they accepted, or what happened once it was in production. Ownership is not a verb. It is a decision and its consequences.
Designed and implemented a data lake on S3 using Glue and Athena.
Chose partitioned Parquet on S3 with Athena over a Redshift cluster to keep query cost flat as volume grew, then ran it on call for nine months, including two backfills after upstream schema changes.
An illustrative example.
Ask yourself
- What did I decide that someone else could have decided differently, and why did I choose this way?
- What did I turn down, and what did that cost?
- Who depended on this, and what did they do when it broke?
- What happened after launch: who ran it, who was paged, what did I change?
The incident story
1 in 5
resumes mention an incident, a root cause or an outage at all. Yet nearly 9 in 10 mention monitoring, alerting, SLAs or data quality.
“Tell me about a production incident” is one of the most common data engineering interview questions, and most candidates have a real answer. It just never made it onto the resume, and by interview day the details have faded.
Responsible for monitoring and support of production pipelines.
Traced duplicate orders in the daily revenue table to an upstream retry change, backfilled 11 days, then added an idempotent key and a row-count check so it cannot recur silently.
An illustrative example.
Capture it while it is fresh
- Write down what broke, who noticed first and how long it lasted.
- Keep the numbers: rows affected, hours of bad data, who was downstream.
- Record the fix and the prevention separately. Prevention is the part interviewers remember.
Identical tool lists
Most
list all four of Python, SQL, AWS and PySpark. Nearly all list AWS, and about 9 in 10 list PySpark.
When most resumes list the same stack, the list stops telling anyone anything. What separates candidates is the reason behind a choice, the constraint they worked within and the cost they accepted.
Skills: Python, SQL, AWS, PySpark, Spark, Airflow, Redshift, Snowflake, Kafka.
Kept Kafka for the event stream but moved the batch load to Snowflake Snowpipe, removing a Spark cluster we were paying for around the clock.
An illustrative example.
Make a tool list worth reading
- Group tools by what you did with them, not alphabetically.
- Drop the ones anyone in your role would be assumed to know.
- For each headline tool, know the alternative you considered and why you passed on it.
- Name the constraint: a latency target, a budget, a small team, compliance.
Also worth fixing
Under 1 in 10
link a GitHub profile
Almost none link a blog, and none link Kaggle. A lot of data engineering lives in private repositories, so the best evidence is often invisible outside the team that saw it. Writing up what you built, without the confidential detail, gives a reader something to check.
1 in 4
already mention GenAI work
Usually as a line in the middle of a paragraph on a core data engineering background. If you have built with LLMs or retrieval, say so where it is easy to find, and say what it did.
Where Data Scientist resumes lose out
Data science resumes say which model was trained. They rarely say which decision it changed, who acted on it, or how anyone knew it worked. GenAI is now so common that mentioning it no longer sets anyone apart.
The decision, not the model
Almost none
use the word “owned”, and only about 1 in 5 say “led”.
A model nobody acts on is a prototype. Most resumes say what was trained and stop. The parts that show ownership are missing: the decision the model informed, who acted on it, and what happened next.
Built a churn prediction model using XGBoost.
Built the churn model and owned its rollout: the retention team called the top-scoring 10% for three months, and churn in that group fell against a holdout that was left alone.
An illustrative example.
Ask yourself
- What decision did this model change, and who made it?
- What did people do differently because of it?
- How did you know it worked: a holdout, an A/B test, a before and after?
- What happened after launch: drift, retraining, who maintained it?
GenAI is now the norm
2 in 3
mention GenAI, LLM or RAG work, and about 6 in 10 name RAG specifically.
When most resumes mention the same thing, mentioning it stops helping. What separates candidates is what they built with it, how they evaluated it and what went wrong along the way.
Worked on LLM and RAG based applications using LangChain.
Built retrieval over support tickets and wrote the evaluation set that showed it answered 4 in 10 questions wrongly. Changing how documents were split moved that to 1 in 10.
An illustrative example.
Say what sits behind the buzzword
- What problem was retrieval or prompting solving, and for whom?
- How did you evaluate it: a test set, human review, which metrics?
- What failed, and what did you change?
- What did it cost, and how fast was it?
Results without a baseline
Most
of the improvements resumes claim are round figures ending in 0 or 5. If they were measured, you would expect only about 1 in 5.
“Improved accuracy by 25%” means little without a baseline. Compared with what, on which data, and did it change a decision? A number without those answers is easy to doubt and impossible to check.
Improved model accuracy by 25%.
Raised recall on the fraud class from 0.62 to 0.81 on a held-out month of data, against the previous rules-based baseline.
An illustrative example.
Make a result checkable
- State the baseline it beat.
- Say which metric you used, and why that one.
- Name the data: how much, which period, and whether it was held out.
- Say what the improvement was worth: money, time or decisions.
Also worth fixing
1 in 4
link a GitHub profile
The rest describe their work with nothing to check. A public notebook or write-up, with private data removed, lets a reader see how you think.
Nearly 9 in 10
list scikit-learn, and almost as many list Python
The toolkit list cannot tell one candidate from another. Say what you did with a tool, and why you chose it over the obvious alternative.
Where AI & ML Engineer resumes lose out
AI and computer vision engineers have close to the opposite problem to data engineers. Many already have public proof, but the resume does not turn it into something a recruiter can act on.
A paper does not say what you built
About half
of resumes cite a paper, a publication or a conference, and a few mention a patent. The proof exists.
Publication language and resume language are different languages. A paper title tells a recruiter that you did research. It does not say what you built, what it ran on, or who used it. What is missing is not evidence but translation.
Co-authored a paper on defect detection using deep learning.
Turned our defect detection research into a line-side inspection model that flags scratches within 40 ms per frame, running on edge GPUs at two plants.
An illustrative example.
Translate each paper into four lines
- The problem, in the customer's words rather than the paper's.
- What you built or decided, and your part in it.
- Where it ran: the hardware, the latency budget, the data volume.
- What changed because of it: a metric, a decision, a user.
The fundamentals never appear
Almost none
of resumes use any of the vocabulary a technical screen relies on: anchor boxes, IoU thresholds, NMS, backpropagation, positional embeddings or cosine similarity.
This is not a resume-writing failure. A resume says what you built. A technical screen tests whether you understand why it worked: which hyperparameters you tuned and what they did, how you stopped overfitting, how a vision transformer differs from a CNN. Better bullets cannot close that gap, because a resume was never the right place for it.
Trained object detection models using YOLO and PyTorch.
Retuned anchor sizes and the IoU threshold after the defaults missed small scratches, then raised the NMS threshold so neighbouring defects stopped being merged into one.
An illustrative example.
Explain it, do not just list it
- Which hyperparameter did you change, and what happened to the result?
- How did you know the model was overfitting, and what fixed it?
- What would break if the training data changed?
- Why this architecture and not the obvious alternative?
- Say it in your own words, as if to a colleague. That is the version an interviewer is listening for.
Tracking and deployment are thin
3 in 4
describe real-time work, but almost none name an experiment tracker such as MLflow, and only about 4 in 10 name ONNX or TensorRT.
Real-time is a claim about latency, hardware and cost, and the resume rarely says which. How a model reached production, and how you knew it kept working, is what separates a research prototype from a shipped system.
Deployed real-time models to production.
Exported to ONNX and quantised to INT8 to fit a 30 ms budget on an edge GPU, and tracked every training run in MLflow so a regression could be traced back to a data change.
An illustrative example.
Tell the deployment story
- The latency or throughput budget you had to meet, and the hardware.
- What you did to get there: export format, quantisation, batching, profiling.
- How you knew it kept working: monitoring, drift checks, a retraining trigger.
- How runs were tracked, so a result could be reproduced.
Your title is not your specialisation
2 in 3
have a job title that no other ML or AI resume in our set shares.
Machine learning engineer, AI engineer and computer vision engineer are used almost interchangeably, sometimes within a single resume. A recruiter searching one label misses people who use another.
Machine Learning Engineer | AI Engineer | Computer Vision
Computer vision engineer: object detection and defect inspection on edge GPUs.
An illustrative example.
Make it findable
- State your specialisation in the first line, in the words a recruiter would search.
- Name the domain you work in, such as manufacturing inspection or medical imaging.
- Name one thing you shipped in that domain.
Also worth fixing
About 4 in 10
say they led something
Almost none mention code review. Senior roles usually involve leading design and reviewing other people's work, so if you do, say so and give one example.
1 in 5
of ML and AI resumes use the word “owned”
That is the highest of any role we looked at, and it is still a minority. If you own outcomes, make it the first thing a recruiter reads, not the fifth.
Catch it while you still remember it
Every gap above has the same cause: the detail was real, but nobody wrote it down at the time. graph asks for it while the work is fresh.
When you ship something, add a quick note. graph asks the follow-up questions a hiring panel would: throughput, latency, edge cases, the decision you made and why. Your answers become a resume tailored to a job description, an interview prep sheet built from your own stories, and a profile you can share when you choose to.
See the four steps or read why we built it.
Make your work impossible to overlook.
Start with your resume. graph shows you what it understood and what is missing.