08 — Phase 6 Projects (Month 13 Capstone)¶
These are not exercises. They are portfolio artifacts. Each one is designed to produce something that exists in public, can be linked in a job application, and provides evidence that is impossible to fake. By the end of Month 13, a hiring manager or research team should be able to spend 30 minutes with your public portfolio and form an accurate picture of what you can do. That is the acceptance criterion for all three projects.
The projects compound. The paper reproduction feeds the blog post. The blog post feeds the talk. Execute them in order.
Project 1: Reproduce a 2024-2025 Paper From Scratch¶
The Claim¶
Reproducing a research paper from scratch — from the math to working code to benchmarks — is the single highest-signal thing you can do to demonstrate research-grade engineering. It is not about being smarter than the authors. It is about proving that you can read primary sources, translate them to code without a tutorial, and produce a quantified result.
Specification¶
Choose one paper from this list (in rough difficulty order):
Flash Attention 2 (arXiv:2307.08691) — Implement the tiling algorithm. The paper has known gaps in implementation detail. Finding and bridging those gaps is the point.
GRPO (arXiv:2402.03300) — Implement the Group Relative Policy Optimization training loop for a small LM on a verifiable task (e.g., arithmetic).
DPO (arXiv:2305.18290) — Implement the DPO loss and training pipeline for a small model (GPT-2 or Llama-3.2-1B). Compare to SFT baseline.
GQA (arXiv:2305.13245) — Implement grouped-query attention and benchmark memory/speed vs standard MHA at different group sizes.
Mamba (simplified) (arXiv:2312.00752) — Implement the selective SSM scan algorithm. Benchmark against a transformer on a synthetic sequence task.
Required deliverables:
/paper-reproduction-[paper-name]/
├── README.md # The write-up (see spec below)
├── paper_notes.md # Your 3-pass reading notes with the 5 questions answered
├── implementation/
│ ├── model.py # Core implementation, documented with equation references
│ ├── train.py # Training script
│ ├── eval.py # Evaluation against paper's reported benchmarks
│ └── requirements.txt # Exact dependency versions
├── results/
│ ├── benchmark_results.json # Your numbers vs paper's claimed numbers
│ └── figures/ # Loss curves, benchmarks
└── FINDINGS.md # What differed from the paper, and why
README.md specification (this is the public artifact that matters):
## Reproduction: [Paper Title] ([arXiv:XXXXXXX])
### Why This Paper
[1 paragraph: why this paper is important in 2024-2025]
### What I Reproduced
[Specific claims from the paper I targeted, with the paper's reported numbers]
### My Results
| Metric | Paper Reported | My Implementation |
|--------|---------------|------------------|
| ... | ... | ... |
### Where the Paper Was Unclear
[This is the most valuable section. What did you have to figure out that the paper didn't specify?]
### What I Would Do Differently
[Honest assessment of your implementation vs optimal]
### How to Run
[Exact commands. Should work in a fresh environment.]
Acceptance criteria:
Repository is public on GitHub with a clear README
At least one quantitative metric is within 15% of the paper’s reported result OR you have documented why you cannot close the gap
FINDINGS.mdcontains at least 3 specific observations about what the paper left ambiguous or underspecifiedCode runs end-to-end from
requirements.txtinstall to evaluation in under 1 hour on a single GPU (or CPU with reduced config)You can explain every line of the core implementation without referencing the paper
Time estimate: 40-60 hours across 4 weeks. This is the most time-intensive project. Do not rush it. The quality of your FINDINGS.md is more valuable than perfect metric reproduction.
Where to share after completion:
Post to r/MachineLearning with a title like: “Reproduction of [Paper]: What the paper doesn’t tell you”
Share on Twitter/X with a brief thread (3-5 tweets: what you found, what was hard, what the community should know)
Link from your GitHub profile
Project 2: Write 3 Technical Blog Posts¶
The Claim¶
Writing is not a soft skill. It is a forcing function for clarity. If you cannot write 1,000 words about a technical concept with original evidence, you do not understand it. Three published posts over Month 13, each targeting a different major phase from your 13-month journey, produce a permanent public record of your thinking.
Specification¶
Write exactly 3 posts. One per major phase theme:
Post 1: Foundations-era insight (Phase 1-3 topic) A concept from the first 4 months that you now understand differently than you did when you first learned it. Example angles:
“What gradient descent tutorials get wrong about learning rate schedules”
“The regularization technique I dismissed that actually matters at scale”
“I tested 4 implementations of batch normalization — here’s what the paper doesn’t say”
Post 2: Applied ML insight (Phase 4-5 topic) Something from the applied/deep learning phases where you have a quantified result. Example angles:
“I compared 3 fine-tuning approaches on [task] — here are the actual numbers”
“Why my first recommendation model failed, and what the training loop was hiding”
“The evaluation metric that looked great offline and failed completely online”
Post 3: Frontier opinion (Phase 6 topic) A structured technical argument about a contested question. With evidence. Example angles:
“Why I believe MoE will be the default architecture for production LLMs by 2026 — and what would change my mind”
“The reproduction I did that made me skeptical of [paper/technique]”
“What 13 months of intensive ML study taught me that the curriculum gets wrong”
Per-post specification:
Element |
Requirement |
|---|---|
Length |
1,000-2,500 words |
Original content |
At least one thing the reader cannot get from existing tutorials: your numbers, your experiment, your structured argument |
Evidence |
At minimum 1 chart, code block, or table with your own data |
Structure |
Hook → Context → Finding → Evidence → Implications → What remains unknown |
Platform |
Substack (preferred for long-form) OR Medium OR HuggingFace Spaces |
Acceptance criteria:
All 3 posts are published (not drafts) before Month 13 ends
Each post has been shared to at least 2 channels (e.g., Twitter/X thread + r/MachineLearning)
At least 1 post achieves >500 genuine reads within 2 weeks of publishing
At least 1 post receives >3 substantive comments from readers who clearly read the post (not just “great post!”)
No post is a paper summary with no original contribution
What counts as original contribution:
Your own experimental results with your own numbers
A structured argument with falsifiable claims and stated conditions for update
A reproduction finding (what the paper didn’t tell you)
A failure post-mortem with causal analysis
What does NOT count:
“Here is what [paper] is about” without your own analysis
“I tried [technique] and it worked” without comparison or failure modes
Tutorial content that exists in 400 other posts
Time estimate: 6-10 hours per post (research + writing + editing + distribution). Budget 25 hours total.
Project 3: Deliver a 30-Minute Technical Talk¶
The Claim¶
Teaching is the final test of understanding. If you can construct a coherent, evidence-backed 30-minute technical talk — one where an intelligent non-expert walks away with a genuinely new mental model — you have compressed your learning into the most transferable possible form. Public delivery adds the constraint of real-time questioning, which exposes gaps that polished writing hides.
Specification¶
Topic selection criteria:
Must be a topic from your Phase 6 sub-domain of focus
Must have original content: your reproduction result, your experiments, your structured opinion
Must be accessible to “senior software engineer with no ML background” as the floor
Must be substantive enough to challenge “ML engineer with 2 years experience” — it cannot be a tutorial
Candidate topics:
“What the DeepSeek papers actually mean for the future of LLM training” — with your own cost analysis and benchmark reading
“How Flash Attention 2 works, why it matters, and what I found when I implemented it” — your reproduction as the anchor
“The 5 things I learned about fine-tuning LLMs that no tutorial taught me” — empirical, from your own experiments
“Why the research-to-production gap exists and how to close it” — your 13 months as the data
Venue options (in order of preference):
Venue |
How to Get In |
Audience Size |
|---|---|---|
Local PyData or ML meetup |
Email organizer with title + abstract 3-4 weeks in advance |
30-150 |
Zoho internal tech talk / learning session |
Propose to your team or engineering org |
10-50 |
Online: Twitter Spaces or Discord community |
Message community admins with a proposal |
20-200 |
PaperSpace / HuggingFace community events |
Apply through their community channels |
Variable |
Record and publish (fallback) |
Self-hosted on YouTube/Loom |
Async |
Required deliverables:
/technical-talk-[topic-slug]/
├── slides/
│ └── [title].pdf # Final slide deck (exported)
├── talk_notes.md # Speaker notes with timing cues
├── recording/
│ └── [link or file] # Recording of the delivered talk
└── README.md # Topic, audience, venue, date, Q&A summary
Talk structure:
0:00 - 2:00 Hook: The specific question or surprising result that motivated the talk
2:00 - 7:00 Context: Why this matters now. What the audience needs to know first.
7:00 - 20:00 Core content: Your reproduction / experiments / structured argument
— This is where original content lives. No handwavy slides.
20:00 - 27:00 Implications: What changes if this is true? What would you do differently?
27:00 - 30:00 Open questions: Intellectual honesty. What you don't know. What would change your view.
+Q&A (5-10 min if live)
Acceptance criteria:
Talk is delivered to a live audience OR recorded and published (minimum: recorded)
Duration: 28-35 minutes
Slides are available publicly
At least 1 audience question asked (live) OR at least 5 genuine comments on the recording
You can answer every question from the Q&A without looking at slides
The talk includes at least 1 slide with your own data (not screenshots from papers)
Time estimate: 15-20 hours (topic research, slide construction, rehearsal, delivery). Budget minimum 2 full rehearsals before the live version. One rehearsal is not enough — that is not a hypothesis, it is empirical.
Capstone Summary¶
By completing all three projects, you will have produced:
Artifact |
Location |
What It Proves |
|---|---|---|
Paper reproduction + FINDINGS.md |
GitHub (public) |
You can read primary sources and implement from math |
3 technical blog posts |
Substack/Medium |
You can synthesize and communicate original technical insight |
30-minute talk + recording |
YouTube/community |
You can teach, handle live questions, and hold a room |
All combined |
Your public profile |
A portfolio that speaks louder than any resume claim |
What most people do instead: They complete the learning and never publish anything. This is the most common failure mode of self-directed learning programs. The work disappears. No artifact = no signal to the outside world that the work happened. Do not let that be your outcome.
These three projects are not optional polish on the roadmap. They are the exit exam. The certificate of completion is the public record you create.
Return to README.md · Previous: 07_the_applied_phd_identity.md
🏁 End of Phase 6. End of the 13-Month Roadmap.
The journey from “1-year applied ML engineer” to “applied PhD equivalent” is complete on paper. The real completion happens when you post the first artifact, get the first genuine question you can’t immediately answer, and realize that the frontier is not a destination — it is a practice. You now have the system to keep going.