The Thirteen-Month Pitch

Who You Are at M13 — Six Versions

The pitch is not a summary of what you studied. It is a statement of what you can do, grounded in things that exist and can be verified. Every version below is anchored in specific shipped artifacts. If the artifacts don’t exist, the pitch is fiction. Build the artifacts first.

Start rehearsing these in Month 11. By Month 12, you should be able to deliver all three short versions cold, with no notes, in any context. The longer versions are for specific situations — you’ll know which one to use when.


The Locked Sentence (The North Star)

“I’m an applied ML engineer who rebuilt the discipline from first principles over 13 months — from linear algebra and probability through transformers, diffusion, and LLM alignment — and can now design, implement, debug, and take to production any ML system, read and critique the research behind it, and explain it to anyone; one of a few hundred practitioners globally who are genuinely both builders and scholars.”

This sentence is true only if all 8 portfolio rungs exist. If they don’t, use a shorter, accurate version instead. Never say something you can’t verify.


Version 1: 30-Second Elevator

Context: Random encounter, conference, mutual introduction, LinkedIn cold message.

“I’m a machine learning engineer based in India. Over the past year I’ve built a public portfolio going from pure math fundamentals all the way to fine-tuning and deploying LLMs with full monitoring — it’s all on GitHub and HuggingFace. I work on production ML at Zoho, and I’m particularly interested in [one specific problem area you care about]. What are you working on?”

What it does: States your level without overclaiming. Points to verifiable evidence. Redirects to them. Lasts 25 seconds.

Rehearsal target: Smooth delivery by Month 11. Tested on at least 2 real people before Month 12.


Version 2: 2-Minute Recruiter Call

Context: Initial recruiter screen, networking call, brief intro at a meetup.

“I’m an applied ML engineer with about 2 years of total experience. The first year was mostly shipping code at Zoho, which gave me a strong production foundation. The past 13 months I ran a structured deep-dive: starting from linear algebra and probability, through classical ML, deep learning, and modern architectures, all the way to fine-tuning LLMs and building production monitoring systems.

The output is 8 public artifacts: a math-from-scratch notebook, a classical ML benchmarking repo, a backpropagation engine, a nanoGPT from scratch, a QLoRA fine-tuned model with RAG and RAGAS evaluation currently deployed on HuggingFace Spaces, a production ML system running with Evidently monitoring and GitHub Actions CI/CD, a paper reproduction, and three published technical posts.

The two I’d point you to first are [Rung 5 URL] and [Rung 6 URL] — they show the LLM engineering and production system work together. What kind of problems is your team working on?”

What it does: Establishes trajectory, names specific artifacts with URLs, shows production orientation, redirects to their problems. Under 2 minutes.

Critical rule: Do not say “I know” or “I understand.” Say “I built” and “I shipped.” The word “understand” is unverifiable. The URL is.


Version 3: 5-Minute Technical Intro

Context: First round technical interview, technical panel intro, presentation to an ML team.

“Background in brief: about 2 years total, started as an applied ML engineer at Zoho — production environment, real constraints, real users. About 13 months ago I ran a structured reconstruction of the fundamentals: I started with Gilbert Strang’s linear algebra and Blitzstein’s probability, worked through classical ML with a focus on evaluation rigor, built neural networks from scratch including a full backpropagation engine I verified against PyTorch autograd, implemented nanoGPT and DDPM from scratch, then spent the last 6 months on modern LLM engineering and production MLOps.

Three artifacts I’d highlight:

First, the LLM engineering gate — I fine-tuned [model] using QLoRA on [specific task], built a RAG system over [specific corpus], evaluated it with RAGAS (faithfulness 0.XX, answer relevancy 0.XX), and deployed it to HuggingFace Spaces where it’s running now. All the eval code is reproducible.

Second, the production system — it’s a live ML pipeline with DVC for data versioning, MLflow for experiment tracking, GitHub Actions CI/CD with green runs you can see in the repo history, and Evidently monitoring running against real inference data. There’s a runbook.

Third, a paper reproduction of [paper name] from [ICLR/NeurIPS/ICML year] — I got within X% of their reported result on [metric] and documented exactly where and why my implementation diverged.

I’m interested in [specific problem/role] because [one concrete reason tied to what you’ve shipped]. I’m most comfortable in PyTorch, HuggingFace ecosystem, and the standard MLOps stack — MLflow, DVC, FastAPI, Docker. What would you want to dig into first?”

What it does: Establishes depth, names specific technical choices, shows production and research both, invites the interviewer to take the wheel.

Rehearsal target: Practiced as a real presentation to at least one person with ML background before Month 13 interviews begin.


Version 4: Portfolio Landing Page

Context: GitHub profile, personal site, HuggingFace profile, anywhere someone lands from a link.

## [Your Name] — Applied ML Engineer

I build and ship ML systems, from linear algebra to production monitoring.

**What I've built (2026):**
- 🧮 Math foundations: SVD + gradient descent from scratch [GitHub]
- 📊 Classical ML: 3-model benchmark with calibration, full pipeline [GitHub]
- 🔥 Deep learning: backpropagation engine, CNN (CIFAR-10), CharLM [GitHub]
- 🤖 Transformers: nanoGPT, ViT, DDPM on MNIST [GitHub + HuggingFace]
- 🦙 LLM engineering: QLoRA fine-tune + RAG + RAGAS eval + live demo [HuggingFace Spaces]
- ⚙️ Production: live ML system, DVC + MLflow + CI/CD + Evidently monitoring [GitHub]
- 📄 Research: paper reproduction of [title] ±X% from reported results [GitHub]
- ✍️ Writing: 3 posts on [topics] [Substack/Medium]

Currently: Applied ML Engineer at Zoho, India.
Interested in: [one sentence about what problems you want to work on next].

[GitHub] [HuggingFace] [LinkedIn] [Blog]

Rules:

  • Every item has a working link. No “coming soon.”

  • Numbers are real (RAGAS scores, CIFAR-10 accuracy, paper delta). Not approximate.

  • The description of each artifact is one clause, not a paragraph.


Version 5: LinkedIn Headline and Bio

Headline: Applied ML Engineer · Built end-to-end LLM + production ML systems · Zoho · Writing about ML

About section (first 3 lines — shown before “see more”):

I’m an ML engineer who spent 13 months rebuilding the discipline from first principles — math through production. I ship verifiable systems: fine-tuned LLMs with RAG and evaluation, production ML pipelines with monitoring. Portfolio at [URL].

Full bio:

Currently at Zoho building production ML systems. Independently completed a structured 13-month deep-dive into ML and AI: linear algebra, classical ML, deep learning from scratch, modern architectures (transformers, diffusion, GNNs), LLM fine-tuning and alignment, and production MLOps.

Public work includes: a QLoRA fine-tuned model with RAGAS evaluation and live demo, a production ML system with DVC/MLflow/Evidently running on real data, a paper reproduction of [paper] from [venue], and technical writing on [topics].

I’m interested in roles working on [one specific area]. If that’s your team, let’s talk.

Rules:

  • The headline has 3 distinct claims separated by ·

  • The first 3 lines of About contain the most critical information (most people don’t click “see more”)

  • No “passionate about,” “enthusiastic,” or “love to” anywhere


Version 6: “Why Hire / Admit / Assess Me”

Context: Written applications, scholarship/fellowship applications, final-round interview question.

“Three things that are unusual in combination.

First, I rebuilt the fundamentals. Not surface-level: I implemented backpropagation from scratch and verified it against PyTorch autograd. I derived the DPO loss from the RLHF constrained optimization. I reproduced a result from [paper] within measurement error and documented exactly where I diverged and why. Most engineers at my level haven’t done this. The work is on GitHub.

Second, I ship. I have a live LLM inference endpoint, a production monitoring system with real drift data, and a CI/CD pipeline with a verifiable run history. These are not demos. They run. The URLs work.

Third, I can explain it. I’ve written [N] technical posts. I’ve given [one] talk. When I learn something, I convert it into something someone else can use. That’s not ego — it’s the Feynman test applied as a discipline.

The combination — foundational depth, production execution, and communication — is the specific profile this role requires. I’m not applying because I qualify. I’m applying because this is exactly the problem I’ve been building toward.”

Rules:

  • Three distinct claims, each verifiable

  • No hedging phrases: “I believe,” “I think,” “I’m hoping to”

  • The last sentence names the specific role or problem, not a generic aspiration


Rehearsal Schedule

Month

Action

M11

Write first draft of Versions 1 and 2 with actual artifact URLs

M11

Deliver Version 1 to one real person (not family)

M12

Version 3 rehearsed as a full 5-minute block to a technical peer

M12

LinkedIn updated with Version 5

M12

Portfolio landing page live (Version 4)

M13

All 6 versions polished and tested

M13

Version 1 delivered cold, 3 times, to different people


What NOT to Claim

The discipline section of the pitch is as important as the pitch itself. If any of these are not true, do not say them:

  • Do not say “production-scale” unless your system has served real users (not just yourself)

  • Do not say “state-of-the-art” unless you have benchmarked against a published baseline

  • Do not say “deep understanding” — it is unverifiable; say what you built instead

  • Do not list frameworks you have only used in tutorials: “experienced in X” means X is in your GitHub with working code

  • Do not claim the fine-tune was on a “large model” if you used a 1B parameter model; say the model name and size

  • Do not say “I deployed to production at Zoho” without permission and accuracy — this can be verified and if it’s not exactly right, it ends the conversation

The constraint is not modesty. The constraint is that every claim you make will be probed. Claims that survive probing build credibility. Claims that don’t survive probing end candidacies.


Return to: README.md · This is the last file in 00_command/. You’re ready to begin.