Become Data Analyst

Proof required

Submit a public Kaggle notebook, a GitHub repository with a Jupyter notebook, or a Google Colab link showing: the data loading and cleaning steps (with code), at least 2 visualisations addressing the question, and the 300-word written summary. The dataset must be identified by name and source.

What gets checked

• Code is reproducible — someone else running it top-to-bottom gets the same results; random seeds set where relevant
• Cleaning decisions are documented with code comments — not just the code, but why each decision was made (e.g. 'rows with > 30% nulls dropped, 847 rows removed')
• Written summary explicitly names what the data cannot conclude — not just what was found; the limits section is the indicator of analytical maturity

Common mistakes

• Choosing a tutorial dataset (Titanic, Iris, Diamonds) — these are already cleaned and analysed; the value of M1 is in encountering a genuinely messy real dataset
• A 'summary' that only describes the visualisations without answering the original question or identifying the limits of the data
• Code that runs but is not reproducible (un-seeded randomness, local file paths, undocumented dependencies)

Resources

What a verifier looks for

• Run the notebook top-to-bottom independently and confirm it produces the same results — reproducibility is a prerequisite for review
• Ask the submitter to describe one cleaning decision that surprised them and why they made it — genuine data cleaning always encounters unexpected issues
• Check the limits section of the written summary — if it reads like a disclaimer rather than a genuine analysis of what the data cannot tell us, it was written as an afterthought
• Ask what they would do next with this dataset if they had 2 more weeks — this tests whether the analysis produced genuine curiosity or was just executed to completion

You'll sign in first, then come straight back here.

Proof required

Submit the decision question (one sentence), the data sources used, the technical workbook (notebook or SQL queries), and the non-technical report (PDF, slides, or Notion document — no code visible, clear recommendations, at least 3 annotated visualisations with titles that state the finding not just the chart type).

What gets checked

• Chart titles state the finding ('Customers acquired via paid ads churn 40% faster') not the chart type ('Churn rate by acquisition channel') — a finding-title chart can stand alone; a label-title chart cannot
• The report has a recommendations section — not just findings; the question was a decision question so the analysis must end in a recommended decision
• The technical workbook is separate from the report — the non-technical audience sees no code; technical reviewers can audit the methodology

Common mistakes

• A 'decision question' that is actually a description question ('what does our data look like?') — a decision question is only valid if the answer would change what someone does
• A report that presents the visualisations without interpreting them — a non-technical reader should be able to read only the titles and recommendations and know what to do
• Technical workbook that is not reproducible or is the same document as the report

Resources

What a verifier looks for

• Read only the chart titles and the recommendations section — if you understand what decision the analysis recommends without reading the body, the report has achieved its goal
• Ask the submitter what the decision-maker did as a result of the report — this is not always possible, but the answer reveals whether the analysis was truly decision-driving
• Check that every visualisation has a finding-title (states the insight) not a label-title (states the chart type or axes)
• Ask the submitter to explain one finding that surprised them — genuine analysis always reveals something unexpected

You'll sign in first, then come straight back here.

Proof required

Submit your M2 report, the reviewer's written assessment (methodology challenges, alternative interpretation, novel question and your response), and their sign-off confirming their role and a live session.

What gets checked

• Reviewer identifies at least one alternative interpretation of a finding that the submitter had not considered
• Live novel question response demonstrates reasoning about data approach (what data would I need, how would I structure the analysis) not just domain knowledge
• Reviewer sign-off confirms 4+ years of professional data analysis experience in industry (not academic research only)

Common mistakes

• Choosing a reviewer who is a domain expert in the same field as the analysis but not a data professional — the challenge must be to the analytical methodology, not just the domain knowledge
• Novel question response that describes the answer rather than the analytical approach ('I think X is true') — the question tests data reasoning, not domain knowledge
• Presenting only the report without being able to explain the underlying methodology when challenged

Resources

What a verifier looks for

• Prepare 2–3 methodology challenges before the session based on reading the M2 report — the most valuable ones are about what the data cannot prove, not just what it shows
• Introduce the novel question within the first 20 minutes — not at the end; the submitter's real-time reasoning is the most revealing part of the session
• Ask the submitter what they would do differently in the M2 analysis knowing what they now know — this tests whether the review produced genuine learning
• Reviewer minimum qualification: 4+ years of professional data analysis in industry; research-only backgrounds are less appropriate because business data analysis involves messier data and stakeholder communication

You'll sign in first, then come straight back here.