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):

  1. 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.

  2. GRPO (arXiv:2402.03300) — Implement the Group Relative Policy Optimization training loop for a small LM on a verifiable task (e.g., arithmetic).

  3. 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.

  4. GQA (arXiv:2305.13245) — Implement grouped-query attention and benchmark memory/speed vs standard MHA at different group sizes.

  5. 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.md contains at least 3 specific observations about what the paper left ambiguous or underspecified

  • Code runs end-to-end from requirements.txt install 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:

  1. “What the DeepSeek papers actually mean for the future of LLM training” — with your own cost analysis and benchmark reading

  2. “How Flash Attention 2 works, why it matters, and what I found when I implemented it” — your reproduction as the anchor

  3. “The 5 things I learned about fine-tuning LLMs that no tutorial taught me” — empirical, from your own experiments

  4. “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.