The M13 Pitch — Six Versions¶

On 2027-08-06, you should be able to say who you are and what you can do in six formats, each grounded in specific shipped artifacts. This file gives you the six versions, the rehearsal schedule, and the discipline of what NOT to claim.

The core sentence — the one you rehearse until it stops feeling like a pitch and starts sounding like the truth — is:

“I bridge Python ML and production C++. I’ve shipped an ONNX inference server, a nanobind-wrapped ANN library, and a profiled thread pool — and I can debug all three from perf output to Grafana dashboards.”

Every version below is a rearrangement of that sentence for a different audience and time budget. Write the pitch first; design the roadmap backward from it. That is exactly what we did.

Version 1 — The 30-Second Elevator (Casual Networking)¶

Use case: a meetup introduction, a Twitter/Bluesky bio conversation, a friend-of-friend at a party asking “what do you do.”

Delivery target: ~75 words. Conversational. No numbers unless asked.

“I’m an ML engineer at Zoho. Over the last year I spent evenings and weekends rebuilding my C++ so I could bridge the Python ML world and the native inference world. I’ve shipped a few things: an ONNX-based inference server, a Python library with a C++ core for ANN search, and a lock-free concurrency toolkit. What I want to do next is exactly that — sit on the boundary where Python ML meets C++ production.”

Rehearsal notes: Say this in a mirror until you can do it without saying “um.” Should sound like a mildly-interested colleague explaining their weekend project, not a sales pitch.

Version 2 — The 2-Minute Recruiter Call¶

Use case: a screening call. A recruiter reads your resume, wants context. You have ~120 seconds to make them route you to the right hiring manager.

Delivery target: ~250 words. Three concrete artifacts. One number per artifact.

“I’ve been an applied ML engineer for the last two years at Zoho, but my background is actually C/C++/Java from college — I was strong in the language early. Over the last 13 months I’ve done a deliberate return to C++, targeting the intersection of production ML and native performance.

Three artifacts to point at. First, mynn-cpp — a from-scratch neural network in C++ with Eigen, wrapped with pybind11, hitting 95%+ MNIST accuracy and matching PyTorch within 1% on the same seed. It’s pip install-able. That project taught me the pybind11 boundary and the numerical stability of hand-rolled softmax + cross-entropy.

Second, mini-inference-cpp — a production-shape ONNX inference server. C++ core, gRPC and REST APIs, dynamic batching in the style of Triton, Prometheus metrics, OpenTelemetry traces, deployed to a $5-a-month VM with a public URL. Load-tested with k6 at concurrency 1 through 128. That’s my end-to-end production stack.

Third, pyfast_ann — an ANN index library with a C++ HNSW core and nanobind Python bindings, benchmarked against faiss on a million-vector workload.

What I’m looking for is inference-engineering work — the boundary where a Python ML team throws models over the wall and someone has to make them fast, observable, and reliable. That someone is what I’ve spent the last year becoming.”

Rehearsal notes: Time yourself. Aim for 120–150 seconds. If you go over 180, you’re editorializing. Cut the adjectives, keep the artifacts.

Version 3 — The 5-Minute Technical Intro (Hiring-Manager First Call)¶

Use case: the first call with a hiring manager after the recruiter routed you through. They want to know: do you know what you’re talking about, and are you the level they’re looking for.

Delivery target: ~700 words spoken (5 min). Same three artifacts, but with technical depth — the how and the what surprised me.

Structure to hit:

30 seconds: The arc — college C++, two years of applied ML with AI-assisted work at Zoho, deliberate 13-month return.
90 seconds: mynn-cpp — architecture (Eigen expression templates, custom autograd graph vs. checkpointing choice, pybind11 GIL handling), one hard bug (numerical stability of the softmax gradient, or Eigen aliasing issue), one surprise (compile times, or ABI issues, or Test PyPI wheel packaging).
90 seconds: mini-inference-cpp — the dynamic batching decision (fixed window vs adaptive), the observability stack choices (spdlog vs glog, Prometheus C++ client vs custom, OTel BatchSpanProcessor vs Simple), the tail-latency findings from k6.
60 seconds: pyfast_ann — nanobind vs pybind11 tradeoff (Stable ABI, binary size, compile time), the faiss benchmark honesty (where you lose — you probably lose at 10M+ vectors on recall-vs-latency).
30 seconds: the honest closing — “the arc is: applied ML engineer who now understands the native side. The gap I’m closing is CUDA depth — I know enough to talk to it, not enough to write it. If that gap is a blocker, I want to know now; if it’s growth-space, I’m hungry for it.”

Rehearsal notes: This is the version you rehearse most. Record yourself once. Listen back. Cut the umms. The self-honest closing (naming the CUDA gap) is what separates candidates who get offers from candidates who get “we’ll be in touch.”

Version 4 — The Portfolio Landing Page (`raghul-23609.github.io` or personal domain)¶

Use case: the recruiter Googles you. They land on your site. You have 20 seconds before they close the tab.

Delivery target: 60–80 words above the fold. Three artifact cards. One clear next action.

Landing Page Copy (paste into your site’s homepage):¶

# Raghul — C++ for applied ML

Applied ML engineer at Zoho. I sit on the boundary between Python ML
and production C++ inference. Below are the artifacts. Each has a repo,
a benchmark table, a blog post, and, where applicable, a live URL.

[ mynn-cpp ]       [ mini-inference-cpp ]      [ pyfast_ann ]
Eigen MLP in       Production ONNX             HNSW ANN index in
C++, pybind11 to   inference server, gRPC +    C++, nanobind
Python. 95%+       REST, dynamic batching,     bindings. Benchmarked
MNIST acc,         Prometheus + OTel,          against faiss on 1M
matches PyTorch    Docker, load-tested.        vectors.
within 1%.         Live URL.

[ Read the blog → ]  [ CV → ]  [ hello@raghul.dev → ]

Rehearsal notes: “Sit on the boundary between Python ML and production C++ inference” is the sentence to nail. Every other word can be moved. That sentence, in that exact order, is the whole positioning.

Version 5 — The LinkedIn Headline + About Section¶

Use case: the recruiter searches LinkedIn with the query "C++" "ONNX" "inference" India and lands on your profile.

Headline (220 char limit):¶

“C++ / ML engineer · I bridge Python ML and production inference · Author of mini-inference-cpp (ONNX + gRPC + dynamic batching) and mynn-cpp (Eigen + pybind11) · Applied ML @ Zoho”

About Section (target 500–800 words):¶

Applied ML engineer at Zoho. My background is C/C++/Java from school and college years — I’ve been in ML for the last two years and, from 2026-07 to 2027-08, ran a deliberate 13-month return to C++ focused on the intersection with production ML systems.

Three shipped artifacts define what I do:

mini-inference-cpp — a production-shape ML inference server. C++ core, ONNX Runtime backend, gRPC + REST APIs, Triton-style dynamic batching, Prometheus metrics, OpenTelemetry traces, Dockerized, deployed to a public URL with k6/ghz load tests documented at concurrency 1 / 8 / 32 / 128. This is the end-to-end stack that turns a .onnx file into a serving service that survives production.

mynn-cpp — a from-scratch neural network in C++ built on Eigen, with pybind11 Python bindings. Hits 95%+ MNIST test accuracy and matches PyTorch within 1% on the same random seed. Wheel published to Test PyPI. This is the boundary between C++ and Python ML, made real.

pyfast_ann — an HNSW-style approximate-nearest-neighbor index in C++ with nanobind Python bindings. Benchmarked against faiss on 1M vectors; the README publishes the workloads where I win and where I lose.

The umbrella skill: I can take a Python ML model, understand where it’s slow or expensive, port the hot path to C++ or wire it into a native inference runtime, observe it end-to-end (logs, metrics, traces), and debug it from perf output down to a Grafana dashboard.

I’m interested in inference-engineering roles, ML infrastructure roles, or applied C++/ML hybrid positions. Based in India, open to hybrid or remote. Reach me at hello@raghul.dev.

Rehearsal notes: update this on M12 W48, not M13. You want it live when the M13 blog posts hit HN, not the week after.

Version 6 — The “Why Hire Me” Answer¶

Use case: you’re asked directly, in an study, “why should we hire you.” This is the highest-stakes 90 seconds of the study.

Delivery target: ~180 words. Two claims + two artifacts + one honest limit.

“Three reasons.

First, I’m rare in this specific slice. Most Python ML engineers cannot ship native C++; most native C++ engineers cannot debug a PyTorch training loop. The overlap is small and this is where you need me: at the boundary. My mynn-cpp and mini-inference-cpp projects prove I live in both worlds.

Second, I can ship end-to-end. mini-inference-cpp isn’t a coding exercise; it’s a service running at a public URL with load tests, dashboards, and a Docker image under 200MB. I don’t need a platform team to make my work operational — I bring my own observability.

Third, I’m honest about what I don’t know. My CUDA depth is intermediate — I can profile a kernel, I haven’t written a fast one. If you need someone deep on GPU internals from Day 1, I’m not that person. If you have room for someone who can grow into that while owning everything from the HTTP request to the ONNX session, I am exactly that person.”

Rehearsal notes: the honest third reason (the CUDA limit) is not a weakness — it is proof you know your own scope. Do not fake breadth you do not have. study partners can smell it.

What NOT To Claim¶

A discipline section. If any of the following comes out of your mouth at M13, you are stretching:

❌ “Expert in C++.” You will be strong applied. “Expert” is 10+ years and language-committee involvement.
❌ “I know CUDA.” You will know enough CUDA to have opinions about it. Say “comfortable at intermediate level; can profile, not yet writing production kernels” instead.
❌ “I built a Triton competitor.” You built a Triton-inspired inference service at a portfolio scale. That is not a Triton competitor; it is a demonstration you understand the same architectural ideas.
❌ “I contributed to PyTorch / LLVM / gRPC.” Only claim this if you actually merged a PR. A drive-by issue comment does not count.
❌ “I understand distributed systems deeply.” Phase 6 gives you the basics. Real distributed systems depth is a multi-year track. Say “working knowledge of the C++ engineer’s distributed toolkit — gRPC, sharding, backpressure” instead.
❌ “I’m a machine learning researcher.” You are an applied ML engineer with strong native infrastructure skills. Different job. Own the difference.

Rehearsal Schedule (Starting M11)¶

Week	Activity
W41 (M11)	Draft all 6 versions using this template. Time each one out loud.
W42	Record Version 3 (5-min technical) on your phone. Listen back. Cut adjectives.
W43–44	Rehearse Versions 1 and 6 during hard-gate #2 crunch. Even 5 min a day.
W45	Rung 7 shipped — update Versions 2, 3, 4, 5 with fresh live URL + benchmark numbers.
W46	First mock study call with a peer or on Exponent. Use Version 3 in the intro.
W47–48	Refine based on peer feedback. Do NOT do this alone — pitch quality is an outside-view problem.
W49	Update LinkedIn About section (Version 5). Do not job-search yet; positioning first.
W50	Second mock study. Introduce Version 6 in a “why hire you” prompt.
W51	Capstones shipped. Update all 6 versions with capstone artifacts.
W52	Ready. Start warm outreach on 2027-08-07. Not before.

What Most People Get Wrong About Pitching¶

They wait until they need the pitch to start writing it. Then it’s frantic, generic, and it sounds like a resume read aloud. The reason this file exists in M1 (readable from Day 1) is so that when the M13 moment arrives, you are refining the pitch, not composing it. Composing under pressure produces vanilla; refining across 13 months produces voice.

The second failure: they pitch capability instead of evidence. “I know C++, ML, and systems” is a resume claim; anyone can say it. “I shipped a public ONNX inference server at [URL] load-tested at 128 concurrent connections” is evidence; you’re the person who can say it. The pitch is nothing but evidence in a well-chosen sentence order.

The third failure: they over-claim. The market notices. The engineers on the other side of the table have read tens of thousands of resumes; they can smell embellishment. Honesty about your CUDA limit sells better than false expertise, because it signals you also know the limits of your other claims. Under-promise, then hand them the repo.

Return to: README.md — you have reached the end of the master command layer. Suggested next read: 01_month_by_month.md — open M1, start Monday morning.