A CV for a data analyst or data scientist role differs from a general software engineer CV mainly in what earns the emphasis, not in its basic shape. Reverse-chronological experience, a short summary and outcome-focused bullets still apply, but a data-focused CV leads with the question an analysis answered and the decision it changed, and names the size and source of the data honestly, rather than leaning on the pipeline or model that produced the answer. A finished dashboard, a trained model or a clean pipeline is not itself the outcome worth naming on a CV; the decision a team made differently because of it is.
Why the emphasis shifts for data-heavy work
A general software engineer's CV commonly earns credit for what shipped: a feature, a service, a system that now runs in production and that a user can point to. Data-heavy work often has a different kind of payoff. A report a leadership team used to choose between two plans, a segmentation that changed how a marketing budget was split, a check that flagged a real problem in a dataset before it reached a downstream system, none of that shows up the same way a shipped feature does. A CV for this kind of role has to state the decision explicitly rather than assuming a reader connects a chart or a model to whatever happened next. That framing matters most for analyst and data scientist roles specifically, where the day-to-day output is often an answer to a question someone actually asked, not a feature a user interacts with directly.
Naming the question a project answered, not just the tool used
A bullet that opens with the tool, "Built a churn prediction model in Python using scikit-learn", tells a reader what technology was involved before it tells them anything about why the work mattered. A bullet that opens with the question the work answered gives a reader the payoff first: which of several onboarding steps most predicted a customer cancelling within two months, whether a proposed pricing change would plausibly reduce signups in a given region, which of two competing product changes a team should prioritise. The tool still belongs in the bullet, just later, once the reader already knows why the analysis existed in the first place. This ordering matters more for data-heavy work than it does for a lot of general engineering work, because the question an analysis was built to answer is often the single most legible thing about it to a reader outside the team.
Describing data honestly: size, sources and scope
Naming the size and shape of the data a project actually worked with gives a reader a sense of scale without needing an invented precision figure. An honest description names things you can actually recall or check: roughly how many records or rows were involved, how many separate sources were joined to build the dataset, how far back the data went, and whether the work ran once as a single analysis or on a recurring schedule. Stating a scope honestly, for example "joined data from three internal systems covering roughly two years of activity", holds up under a follow-up question in a way an invented, unverifiable statistic about the analysis's impact does not. Where an analysis genuinely changed a tracked metric and that number is something you can still point to, it belongs on the CV stated directly; where it is not, scope and the decision it informed carry the bullet just as well on their own.
Grouping tools by where they sit in the pipeline
A data role's tools list often spans a query language, a modelling library, a visualisation tool and a scheduling or orchestration system all at once, and grouping that list by where each tool sits in the pipeline, ingestion, transformation, analysis and modelling, then reporting or visualisation, gives a reader a faster read on the shape of a candidate's experience than one long unsorted line does. A reader scanning for someone comfortable owning an end-to-end pipeline can see that shape immediately from four short pipeline-stage groups, and a reader looking specifically for modelling experience can go straight to that one group instead of reading past a scheduler and a visualisation tool to find it.
Illustrative example: a bullet built around a decision it informed
Illustrative before and after. Before, tool-led: "Used SQL and Python to analyse customer usage data and build a churn model." After, question- and decision-led: "Analysed roughly eighteen months of usage data across two product lines to identify which onboarding step most predicted cancellation within sixty days; the finding led the product team to redesign that single step rather than the wider onboarding flow." Nothing in the rewritten version invents a percentage or a result the person could not actually describe; it states the question, the rough scope of the data, and the decision the finding changed, all things the person genuinely witnessed.
Where quantifying impact still applies
The same caution against inventing a number applies here as it does anywhere else on a CV: a real, currently checkable figure from a dashboard or a report is worth stating directly, and a remembered impression rounded into a clean percentage is not. Quantifying engineering impact on a CV without inventing numbers covers that distinction in more depth, and the same scope-and-decision approach applies just as well to a data-heavy bullet as it does to a general engineering one.
Build yours
CVBuilderKit's Developer template is built around project- and outcome-led entries, which suits a data analyst or data scientist's project list as well as it suits application code. Start from it, or from a blank document, in the builder, and lead each bullet with the question a project answered before naming the tool that answered it.