Portfolio and GitHub¶
A GitHub full of tutorial notebooks does not impress interviewers. They have seen hundreds of Titanic survival analyses. One original project with a clear README, clean code, and documented results will do more for your candidacy than twenty Kaggle notebook forks.
This note covers what interviewers actually look at on your profile, how to structure a project repo so it reads as professional work, and how to build something credible this week if you have nothing yet.
Learning Objectives¶
- Identify the five things interviewers check on a GitHub profile in the first 60 seconds
- Structure a project repo so it communicates clearly without the interviewer running any code
- Write a project README that tells the complete story of your work
- Pin the right repos and write a profile README that positions you correctly
What Interviewers Actually Check (In Order)¶
When a technical interviewer opens your GitHub, here is their mental checklist — in order:
- Pinned repositories — Are there 3–6 repos pinned? What are the names? Do they suggest real projects or just forks and tutorial copies?
- README of the top repo — Does it exist? Does it explain the problem and the result clearly? Can they understand what was built without opening a notebook?
- Commit history — Is there a pattern of regular work, or a single giant commit that uploaded everything at once? Single-commit projects suggest the work was done elsewhere and dumped here.
- Code quality in one file — They will open one Python file or notebook. Is it readable? Are there meaningful variable names, comments where needed, and no dead code?
- Activity — Not for quantity, but for recency. A profile with no activity in 18 months looks abandoned.
Warning
Do not pad your commit count with trivial changes just to look active. Interviewers who look closely will see "fix typo", "fix typo 2", "add file", "update" across 30 commits and it signals the opposite of what you intended.
Repo Structure That Reads as Professional¶
Every project repository should follow this layout:
project-name/
├── README.md <- the most important file in the repo
├── requirements.txt <- exact package versions; proves the code is reproducible
├── data/
│ ├── raw/ <- original, unmodified source data (or a download script)
│ └── processed/ <- cleaned outputs
├── notebooks/
│ ├── 01-eda.ipynb <- numbered; one notebook per phase
│ ├── 02-feature-engineering.ipynb
│ └── 03-modelling.ipynb
├── src/
│ ├── __init__.py
│ ├── preprocess.py <- reusable functions extracted from notebooks
│ └── evaluate.py
└── reports/
└── figures/ <- saved plots referenced in the README
Tip
Numbered notebooks (01-, 02-, 03-) tell the reader the order to follow without any explanation. This is a small signal that you think about the reader's experience.
Warning
Do not commit raw data files larger than a few MB. Put large files in .gitignore and add a download script or a link to the source. A repo that requires cloning 500MB before anything works will not be inspected.
Writing a README That Does the Work¶
The README is your project's abstract and your first impression. Write it for someone who has 90 seconds and wants to know: what problem, what approach, what result.
README Template (Annotated)¶
# Project Title
One-sentence description of what this project does and why.
## Problem Statement
What real question or problem does this address?
Why does it matter — for a business, user, or research purpose?
Keep this to 3–5 sentences. Do not write an essay.
## Data
- Source: [Dataset name and link]
- Size: X rows × Y columns, covering [date range or scope]
- Key features: list 4–6 of the most important columns
## Approach
Brief narrative of your method. No need to be exhaustive —
summarise the pipeline:
1. Data cleaning: [key decisions you made]
2. Feature engineering: [what you created and why]
3. Modelling: [algorithms compared, selection rationale]
4. Evaluation: [metric chosen and why it fits the problem]
## Results
| Model | Accuracy | AUC | Precision | Recall |
|---|---|---|---|---|
| Baseline (majority class) | 0.73 | 0.50 | — | — |
| Logistic Regression | 0.78 | 0.81 | 0.71 | 0.69 |
| Random Forest | 0.82 | 0.87 | 0.76 | 0.80 |
Key finding in one sentence: the random forest achieved AUC 0.87 and reduced
false negatives by 34% compared to the logistic regression baseline.
## How to Run
git clone https://github.com/yourusername/project-name
cd project-name
pip install -r requirements.txt
jupyter notebook notebooks/01-eda.ipynb
## Limitations and Next Steps
- What assumptions did you make that might not hold in production?
- What would you do with more time or better data?
- What would the next version of this model include?
Success
A good README means an interviewer can evaluate your thinking without opening a single notebook. The results table, the rationale for metric choice, the honest limitations section — these are what separate a junior portfolio from a professional one.
What to Do If You Have No Projects Yet¶
Build one project this week. That is enough. One well-executed project beats five half-finished ones.
A project that works for the portfolio: - Uses a real, publicly available dataset (not synthetic data) - Answers a specific question or solves a defined problem - Goes from raw data to a trained model or actionable insight - Has a results section with real numbers - Has a README written as described above
Datasets that make for interesting projects:
| Dataset | Source | Good for |
|---|---|---|
| NYC Taxi Trips | NYC Open Data | Regression, time-series, EDA |
| IMDb Movies | Kaggle | Classification, NLP, EDA |
| Customer Churn (Telco) | Kaggle | Binary classification |
| Stack Overflow Survey | Stack Overflow | EDA, survey analysis |
| COVID-19 Johns Hopkins | GitHub | Time-series, visualisation |
| Open Food Facts | OpenFoodFacts.org | Clustering, feature engineering |
Tip
Choose a dataset where the business question is obvious. "Which customers will churn?" is a better project question than "explore this dataset." The project question drives every decision downstream and makes your README much easier to write.
Pinning Your Repos¶
Pin exactly 3–6 repositories. Anything fewer looks sparse. Anything more dilutes focus.
Pin in this order: 1. Your strongest end-to-end ML project 2. Your strongest EDA or analysis project 3. Any project with a live demo (Streamlit app, GitHub Pages, etc.) 4. A SQL analysis project if you have one 5. One more strong project if you have it
Do not pin: - Tutorial follow-alongs - Course assignment repos - Repos that start with "learn-" or "tutorial-" or "practice-" - Repos with fewer than 5 commits and no README
Warning
Default GitHub shows repositories sorted by most recently updated. Without pinning, an interviewer who visits your profile might see your most recent toy project at the top, not your strongest work. Pin deliberately.
GitHub Profile README¶
A profile README (yourusername/yourusername/README.md) appears at the top of your GitHub profile. Keep it short.
## Hi, I am [Name]
Data scientist with a focus on [your focus: e.g., customer analytics, NLP, time-series].
Currently working on: [one sentence on your current project].
**Stack:** Python · SQL · scikit-learn · pandas · [2–3 more relevant tools]
[LinkedIn](your-link) | [Portfolio](your-link if you have one)
Do not include skill bars, animated badges, or walls of technology logos. These are visual noise. Write one clear sentence about what you work on.
Success
The profile README is the first thing someone reads when they visit your profile page directly. A focused, honest two-paragraph profile reads as confidence. A profile packed with every technology you have ever touched reads as insecurity.