Portfolio Ladder — 8 Rungs to Applied C++/ML Signal

You already know how to build ML systems. What hiring managers cannot yet see is that you can build them in modern C++, publicly, and to a shipping standard. This folder is the answer to that gap. Not a wishlist — a ladder. Eight rungs, each mapped to a specific month of the 13-month roadmap, each producing one concrete artifact that lives at a public URL you can paste into a résumé, a cold outreach DM, or a “here’s what I do” section of your LinkedIn.

The ladder is not a menu. It is a sequence. Rung 1 exists because it is the fastest possible signal that you have re-tooled after two years away from C++. Rung 8 exists because it is the only kind of artifact that separates you from every “I took a Coursera C++ course” candidate on the pile. The rungs in between are the load-bearing steps. Skip one and the ladder wobbles.

Two of the rungs — Rung 6 (M9) and Rung 7 (M11) — are marked HARD GATE. If you do not ship them by the end of their month, the roadmap does not silently continue. It pauses, you open ../99_pre_mortem/, and you do a two-week reset. This is not punishment. It is the mechanism that keeps you from spending 13 months on preparation and shipping nothing.


The 8 Rungs at a Glance

#

Month

Artifact

Source Phase

Hard Gate?

Employer Signal (one line)

1

M1

Toolchain Trio: wc, jsonpp, logtail

Phase 0

“Can set up a modern C++ project end-to-end.”

2

M3

Templated LRU Cache w/ benchmarks

Phase 1 · P1.1

“Understands templates, STL, and measures things.”

3

M4

Recursive-descent JSON parser

Phase 1 · P1.2

“Can implement a parser, not just use one.”

4

M5

NeetCode-150 in C++ w/ CI

Phase 2 · P2.1

“DSA muscle in C++ specifically — not just Python.”

5

M7

Thread pool + SPSC ring buffer, TSan-clean

Phase 3 · P3.1/3.2

“Writes and validates lock-free code — rare outside HFT/systems.”

6

M9

Eigen MLP + pybind11 → MNIST >95%, test PyPI

Phase 5 · P5.1/5.2

YES

“Applied ML engineer who owns the C++ layer.”

7

M11

gRPC + REST inference service, deployed

Phase 6 · P6.1

YES

“Ships production inference infrastructure.”

8

M13

Capstone Alpha (MiniServe) + Beta (PyFast lib)

Phase 7

“Shipping-grade applied C++/ML engineer.”


The Specificity Gradient

The ladder is deliberately shaped like a widening funnel of specificity. Each rung ratchets the signal up one notch. Compress the whole story into a single sentence and it reads: CLI tool → templated data structure → real parser → DSA at scale → lock-free concurrency → C++/ML integration → production inference service → shipped products.

  • Rungs 1–4 (M1–M5): fundamentals proven in public. These show you have recovered the language. Nobody hires on these alone, but a candidate without them is not credible.

  • Rung 5 (M7): the first rare artifact. Lock-free code that survives ThreadSanitizer is a filter — most applicants cannot produce this. It moves you from “another C++ candidate” to “worth a screen.”

  • Rungs 6–7 (M9, M11): the hiring signal. This is where the roadmap earns its keep. An Eigen MLP wrapped with pybind11 or nanobind, and a gRPC inference service deployed to a $5/month VM, are the artifacts that map directly to job descriptions at ByteDance, F5, GM Cruise, Anthropic, Perplexity, and any of the dozens of inference-engineering roles listed on Indeed and Built In SF as of mid-2026. Nanobind is now the current-generation binding library — JAX, MLX, and PennyLane have migrated to it. You will target both pybind11 and nanobind so you can speak to either.

  • Rung 8 (M13): the capstones. These are the two artifacts you will demo in studies and paste into cover letters. Everything before is scaffolding for these.


Why the Hard Gates Are Non-Negotiable

Rung 6 and Rung 7 are the only artifacts on this ladder that a hiring manager for an applied C++/ML role in 2026 will actually value on their own merit. Rungs 1–5 are hygiene. Rung 8 is amplification. Rungs 6 and 7 are the product.

If M9 ends and you do not have a pip install-able Eigen MLP that hits 95% MNIST test accuracy, matches PyTorch to within 1% on the same seed, and has a blog post shared on r/cpp and r/MachineLearning — then something in your process is broken. It could be the schedule (10-15 hrs/week may be too tight for this month). It could be the scope (the MLP might need to be smaller). It could be motivation. Whatever it is, it will also break M11, and M11 is the more important artifact. So you stop, read ../99_pre_mortem/, and diagnose before proceeding.

The reset protocol for both hard gates is identical:

  1. Stop all forward roadmap progress for 14 days.

  2. Write a failure post-mortem in ../99_pre_mortem/ covering: what was scoped, what shipped, what didn’t, what the blocking constraint was (time / knowledge / motivation / scope), and one change you will make.

  3. Rescope the missing artifact to a smaller version that ships in 14 days. For M9, that might be “Eigen MLP without pybind11, MNIST 90%.” For M11, “gRPC service on localhost, no cloud deploy.”

  4. Ship the rescoped version. Then resume the roadmap one month behind.

This is not failure. This is the roadmap doing its job.


Publication Cadence — The Rule

The single biggest mistake developers make with portfolio projects is polishing before publishing. Do not do this. The rule is:

Publish the minimum viable version the day it works. Polish for the two weeks after — not before.

Concretely:

  • The moment your Rung N artifact passes its acceptance checklist, push to a public GitHub repo the same day. README can be rough. Tests can be sparse. Publish anyway.

  • Over the following two weeks, polish: expand README, add benchmark charts, add CI badges, write the blog post, share on the target community.

  • Do not start Rung N+1 until Rung N is published. Not “done.” Published.

This rule exists because unpublished work is invisible. A 60%-polished public repo beats a 100%-polished local one, every time.


Where Each Rung Gets Shared

Every rung has a specific target community, not “the internet.” Generic sharing is noise. The rungs and their targets:

Rung

Primary sharing venue

Why this venue

1

r/cpp_questions, tagged “returning after 2 years”

Low-stakes feedback community; welcomes returnees

2

r/cpp with [Show r/cpp] tag

Templated code is on-topic; benchmark charts get engagement

3

r/cpp with [Show r/cpp] tag; optional: Hacker News if fuzzing stretch is done

Parsers are a classic r/cpp topic

4

r/leetcode, r/cscareerquestions

DSA repos land better where DSA is the topic

5

r/cpp with [Show r/cpp]; consider /r/cpp_questions cross-post for review

Lock-free is r/cpp catnip

6

Personal blog + r/cpp + r/MachineLearning + Hacker News (Show HN)

Cross-audience: language + applied ML

7

Personal blog + r/cpp + r/devops + Hacker News (Show HN)

Infra crowd + language crowd

8

LinkedIn long-form post + Hacker News (Show HN) + personal blog

Recruiter-facing + technical peers

Publish to your own blog first (even a plain Markdown-on-GitHub-Pages blog is fine). External communities link back to your blog. Your blog is the durable asset — Reddit and HN are amplifiers.


What This Ladder Deliberately Does Not Include

  • No game engines, no ray tracers, no Chip-8 emulator. These are excellent projects, but they do not map to applied C++/ML enterprise roles. Save them for a hobby.

  • No CUDA kernels. You are targeting applied enterprise C++, not GPU kernel engineering. If a role wants CUDA, they will train you on it. The delta from C++/ML integration to CUDA is much smaller than the delta from “no C++ signal” to “C++/ML signal.”

  • No “clone Redis” or “clone SQLite” projects. These are impressive but very time-expensive and have poor differentiation — thousands of engineers have done them. Your inference service (Rung 7) plays the same signal role and maps directly to job descriptions.


What Most People Get Wrong

They build one big project. They start it in month 2, hope to finish in month 12, and end up with a half-done thing at month 13. This ladder inverts that: many small, complete, published artifacts, each on its own repo, each with its own share moment. Employers browsing your GitHub see a cadence of shipping, not one dusty in-progress folder.

The other thing they get wrong: they measure their portfolio by lines of code. Lines of code are irrelevant. Distinct public repos with distinct one-line signals are what get you screened. Eight small, sharp repos beat one 40,000-line monolith.


How to Use This Folder

Each file 01_...md through 08_...md is a single rung spec. Read the rung spec at the start of its month, not the end. Print the acceptance checklist if you have to. When you hit “publish” day, come back to the rung spec and check every box. If a box is unchecked, the rung is not done, even if the code compiles.

Cross-reference with the source phase folder listed at the top of each rung spec. The phase folder contains the engineering plan. This folder contains the publication plan. They are complementary — you need both.