Data Analyst

Prove it: Guided build

Produce two things. (1) A spreadsheet workbook from the guided dashboard project, rebuilt on your own copy of the data, with a separate 'Notes' tab listing every cleaning step you applied and how many rows each affected. (2) A text file of at least 25 SQL queries you wrote and ran against a sample database (SQLBolt, pgexercises or the course database), each preceded by a one-line comment stating the business question it answers. It is good when: the workbook's pivot totals reconcile to the raw data total; no formula contains a hard-coded number that should be a cell reference; every query runs without error; at least eight queries use a JOIN and at least eight use GROUP BY; and the comments describe questions, not syntax ('which customers ordered more than twice', not 'GROUP BY with HAVING'). Following the tutorial closely is fine here; copying its files without running them is not.

Prove it: Guided build

Produce a public GitHub repository named 'analyst-core-skills' containing: (1) a sql/ folder with at least 20 solved problems from the 8 Week SQL Challenge or DataLemur, each file headed by the question in plain English, at least eight using window functions and at least six using CTEs; (2) a notebook that loads a public dataset with pandas, performs one grouped analysis and one join, and runs one hypothesis test with the result written as a sentence a manager would understand; and (3) a screenshot and link of a one-page dashboard you built in Power BI, Tableau Public or Looker Studio following a course. It is good when: every SQL file runs; window-function solutions use PARTITION BY correctly rather than self-joins; the notebook runs top to bottom on a fresh kernel; the hypothesis-test sentence states the effect size and the uncertainty, not just 'p < 0.05'; and the dashboard has no more than six visuals, each with a title that states what it shows. Following guided material is expected here; the evidence is that you ran and adapted it, not that you invented it.

Prove it: Independent project

A public GitHub repository and a published dashboard that answer the six questions in the Olist spec below. Submit: the repo link (SQL files, a README, and a data-cleaning log) and the dashboard link. It is good when: every query runs against the loaded data and is commented with the question it answers; the cleaning log lists each issue found, the rows affected and the decision taken; row counts are checked after every join, and the README says so; the dashboard fits on one screen and each visual answers one of the spec questions with a title that states the finding; the README opens with three bullet-point findings a manager could act on, followed by method and a 'What I could not conclude' section. A submission with no stated limitations, or any number in the README that cannot be traced to a query, is not finished.

Prove it: Guided build

Produce a public GitHub repository containing a small dbt project built on the jaffle-shop sample data (or the Olist data from your first analysis) running on DuckDB. It must have: staging models for each source; at least one fact and one dimension model with the grain stated in the model description; generic tests (unique, not_null, relationships, accepted_values) on every primary and foreign key; one cohort-retention model; a sources.yml with descriptions; and a README with a one-paragraph requirements summary written as if for a stakeholder. It is good when: `dbt build` passes from a fresh clone following only the README; every model has a description; the commit history shows at least ten commits on feature branches merged via pull request; one pull request contains a review comment you wrote to yourself explaining a design choice; and the cohort model's numbers reconcile with a hand-written SQL check you include in the repo.

Prove it: Portfolio piece

One self-scoped, end-to-end analysis published as a GitHub repository plus a dashboard or report, with a one-page memo addressed to a named (real or realistic) decision-maker. It must include: a problem statement saying who would use the result and what decision it informs; data you sourced yourself (public data, an API or your own collection, not a pre-cleaned Kaggle competition set); SQL or dbt for transformation; at least one statistical check of whether a key difference is real; and a recommendation. It is good when: a non-analyst can state the recommendation after reading only the memo; every number in the memo traces to code in the repo; the README documents at least three judgement calls and the alternatives you rejected; there is a limitations section; and you can explain, in a recorded five-minute walkthrough or out loud to a reviewer, why you built it this way and what you would do with another month.

Prove it: Production ownership

Own the analysis for at least one real experiment (or, where your company cannot randomise, one quasi-experimental causal analysis) from design to decision, and produce: a pre-registration document written before launch (hypothesis, primary metric, guardrail metrics, randomisation unit, minimum detectable effect, sample size and run length, decision rule); the readout (effect size with a confidence interval, sample-ratio-mismatch check, guardrail results, segment caveats); and a one-paragraph note on the decision taken. Add a metric tree for your team's primary outcome metric. It is good when: the pre-registration is dated before the start of the test; the readout reports uncertainty, not just significance; the SRM check is shown; you resisted or explicitly flagged any peeking or post-hoc segment fishing; the decision maker confirms in writing that the readout informed the decision; and the metric tree's leaf metrics are things a team can directly influence. If you are not yet in a role that runs experiments, do the same on the public Kaggle A/B testing dataset, but treat that as practice and not as this phase's evidence.

Prove it: Production ownership

Own one production data asset (a dashboard, a dbt model set, or a recurring report) used by at least one other team for at least three months, and produce an ownership pack: a README naming the owner, consumers, refresh schedule, metric definitions and known caveats; automated tests and freshness checks on its inputs with a log of failures caught; a lineage diagram from sources to the asset (dbt docs or exposures are fine); an access and privacy review stating what personal data it touches and who can see it; and at least one incident write-up in blameless postmortem format. It is good when: a consumer can find the definition of every metric on the asset without asking you; tests have caught at least one real problem before a stakeholder did; the incident write-up names the root cause, the time to detect and the preventive action, without blaming a person; personal data is minimised and access is justified; and a colleague could take over the asset from the ownership pack alone.

Prove it: Production ownership

Write and deliver three decision-facing documents at work over at least two months: at least one analysis memo (one to two pages) and at least one longer decision document or narrative (three to six pages) with options and a recommendation, plus one executive presentation of either. Keep each document, the feedback you received and the decision taken. It is good when: each document states the recommendation or answer in its first three sentences; a reader can understand the key point from the headings alone; every claim with a number shows its uncertainty or caveats; options are presented fairly, including the one you do not recommend; the decision maker can name what they decided and confirms the document informed it; and your second and third documents show measurable improvement in reader feedback (for example, fewer clarifying questions or a shorter meeting). If you share them outside your company, redact anything confidential.

Prove it: Org impact

Over at least six months, produce a leadership portfolio: (1) a written account of one decision you changed without having authority over it, with the before and after and the evidence of your role; (2) an analysis review checklist you introduced for your team and a log of at least ten reviews you gave using it; (3) a mentoring record for at least one less experienced analyst, with their goals, what you worked on and their own written assessment of the outcome; and (4) a one-page career decision note on whether you are pursuing the staff or management path and why. It is good when: the changed decision is confirmed by the decision maker; review comments focus on correctness and clarity rather than style, and the checklist caught at least one real error; the mentee can name a skill they gained and a piece of work it improved; and the career note is grounded in what you enjoy doing day to day, not in title or pay alone.

Prove it: Org impact

Lead one organisation-level change and document it: either (a) defining or redesigning a company's or division's metric framework (north star, metric tree, owners, definitions and review cadence) and getting it adopted in planning, or (b) designing and implementing a change to how the analytics function is organised or operates (team structure, intake and prioritisation, self-serve strategy). Produce the proposal document, the adoption evidence and a value assessment six months later. It is good when: the proposal was approved by the leader who owns the outcome; the metric framework or operating model is visibly in use (planning documents, recurring reviews, OKRs reference it); each metric or team has a named owner; the value assessment cites specific decisions the change affected and estimates their impact honestly, including uncertainty; and you can describe what you would do differently and what did not work.