Data Analyst

The tool list is table stakes and belongs near the bottom

Almost every shortlisted analyst knows SQL and at least one visualisation tool. Listing them is necessary — screens do look for the words — but leading with them spends your most valuable space on the least distinguishing thing about you.

There is one exception worth making room for: depth in a tool that is genuinely uncommon in your target market, or a specific dialect the posting names. Warehouse-specific SQL, dbt model ownership, or production Python that other people depend on are different claims from familiarity, and are worth stating as such.

An analysis is only finished when somebody did something

The strongest line on an analyst résumé names a decision. “Built a churn model” is work. “Found that churn concentrated in accounts onboarded without a success call, which moved onboarding to a mandatory call for accounts above £10k” is a decision, and it is the version that survives an interview.

This is also the honest boundary. Analysts frequently do not own the decision, and inflating that into ownership is the claim most likely to collapse under a follow-up question. “The recommendation was adopted” is true, verifiable, and enough. If it was not adopted, the analysis can still be your best material — say what you found and what it changed about how the question was asked.

Numbers that mean something without your context

Analysts are more comfortable with numbers than most candidates and, oddly, often use them worse. “Improved query performance by 40%” is unreadable to someone who does not know the starting point — forty percent off an eight-hour job matters, forty percent off four seconds does not.

Give the reader the base: “cut the nightly build from 6 hours to 3.5, which moved the reporting deadline from 10am to before the morning stand-up.” The second half is what makes it land, because it converts a technical number into something a non-technical reader can care about.

Percentages without denominators have the same problem. A 30% lift on a test with 200 users is a story about noise; on 200,000 it is a result. If the denominator is confidential, an order of magnitude is still far better than nothing.

Where these résumés usually get cut

The most common failure is a page of dashboards. Dashboard counts are a measure of activity, not of value, and “built 40+ dashboards” can quietly suggest that nobody in the organisation could answer their own questions. One dashboard with the decision it supports is stronger than forty listed.

The second is analysis with no question attached. Describing methods — segmentation, cohort analysis, A/B testing — without the question they answered reads as coursework. The question is what shows judgement about where to spend effort.

The third is a résumé indistinguishable from a data engineer's or a data scientist's. These roles are screened by different people looking for different evidence, and one page that tries to satisfy all three usually satisfies none. Pick the role in the posting in front of you and lead with the matching evidence.