Build and Ship a Data Science Project

Proof required

Share a public Jupyter notebook or GitHub repository containing: (1) a one-paragraph problem statement naming the question, the intended audience or stakeholder, and why the answer matters, (2) a description of the data source with the retrieval or collection method documented, and (3) an EDA section with at least 5 visualisations and a written finding for each — including one finding that surprised you.

What gets checked

• Problem statement names a specific question with a measurable answer — 'I explored sales data' is not a question; 'Which product categories have the highest return rate, and is return rate correlated with discount depth?' is
• EDA visualisations are annotated with findings, not just displayed — a chart with no interpretation shows you can run code, not that you understand the data
• At least one surprising finding is documented with an explanation of why it was unexpected and what it implies for the next step

Common mistakes

• Starting with a dataset and reverse-engineering a question — the question should drive the data collection, not the other way around; projects that start from 'interesting' public datasets often lack a real stakeholder perspective
• EDA that only checks whether the data is clean — distributions, correlations, and anomalies are the analytic content; cleaning is infrastructure
• Using synthetic or toy datasets for a portfolio project — Iris and Titanic are learning tools, not portfolio projects; real-world data with real messiness is the standard

Resources

What a verifier looks for

• Ask the submitter to explain why they chose this question — a genuine project has a real motivation; 'I found an interesting dataset' is a signal that the question was retrofitted
• Review the EDA section: each chart should have a written finding below it — ask the submitter to explain the most surprising finding and what it implied for their modelling approach
• Ask about the data quality issues they encountered — every real-world dataset has them; a project with no data quality discussion used a pre-cleaned dataset and missed the learning

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

Proof required

Share the updated notebook or repo showing: (1) a baseline result (a naive model, a simple regression, or a single aggregation), (2) at least two alternative approaches with evaluation metrics for each, (3) a final chosen approach with a written justification for why it was selected, and (4) an honest limitations section explaining what the pipeline cannot do or where it might fail.

What gets checked

• Evaluation metrics are appropriate to the problem — accuracy is not the right metric for an imbalanced classification problem; AUC, precision/recall, or F1 should be used and explained
• Two alternative approaches are genuinely different — trying Random Forest and a tuned Random Forest is not two alternatives; trying Random Forest and Logistic Regression is
• Limitations section is honest and specific — 'the model is not perfect' is not a limitation; 'the model was trained only on data from 2018–2022 and may not generalise to post-pandemic consumer behaviour' is

Common mistakes

• Optimising for training accuracy without measuring generalisation — always evaluate on held-out data; a model that scores 99% on training data with no test evaluation is a memorisation exercise, not a model
• Choosing the most complex approach without justification — a simpler model that performs nearly as well is usually better; the justification for complexity should be explicit
• Omitting the limitations section — every real data science project has limitations; a project without them is either dishonest or shallow

Resources

What a verifier looks for

• Ask the submitter to explain why they chose their final approach over the alternatives — the justification should cite evaluation metrics, not intuition alone
• Review the evaluation section for data leakage signals: if training and test metrics are nearly identical on a complex model, ask how the train/test split was constructed
• Ask about the limitations: what would make this analysis wrong? A candidate who can identify the most dangerous assumption in their own work demonstrates genuine data science maturity

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

Proof required

Share: (1) the public GitHub repository URL with a README containing the problem statement, data source, how to run the code, and key findings, (2) confirmation that the notebook runs cleanly from top to bottom (state this explicitly and describe how you verified it, e.g. Kernel → Restart and Run All), and (3) the name and role of your technical reviewer, their most challenging question, and your response.

What gets checked

• GitHub repository is public and the README is complete — a repo with a one-line README and no run instructions does not meet the standard
• Notebook runs end to end without errors on a fresh kernel — 'I ran it and it worked' without describing the verification method is insufficient
• Technical reviewer has real data science or ML experience — a classmate from a beginner course does not meet the bar; a working data scientist, analyst, or ML engineer does

Common mistakes

• Publishing without testing reproducibility — notebooks that import local files, hardcode absolute paths, or require unlisted packages will not run on a reviewer's machine
• README that describes the code rather than the project — the README should answer 'what question did you ask, what did you find, and why does it matter?' before explaining how to run the code
• Choosing a technical reviewer who will not ask challenging questions — the reviewer should push back on methodology; a reviewer who only says 'looks good' is not a qualifying reviewer

Resources

What a verifier looks for

• Clone the repository and attempt to run the notebook — confirm the environment requirements are documented and the notebook runs from top to bottom on a fresh kernel
• Ask the submitter what their technical reviewer's most challenging question was and how they answered it — this is the core evidence that a genuine technical review took place
• Ask whether any changes were made to the project after the review — a genuine technical review almost always surfaces at least one improvement; a project with no post-review changes warrants a question

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