Rung 4 (M5) — NeetCode-150 in C++, CI-Compiled

You have solved LeetCode in Python. That does not transfer to a C++ study. Rung 4 fixes that. It is the least-glamorous artifact on the ladder but arguably the most study-relevant — it converts your existing DSA intuition into C++ muscle and produces a public repo that says “I do LeetCode in C++ specifically.”

One repo. 150 solutions. GitHub Actions compiling all 150 on every push. That’s the artifact. It is boring, and it works.

What It Is

A public GitHub repo named neetcode-150-cpp containing:

  • 150 .cpp files organized by pattern under src/<pattern>/<problem>.cpp.

  • One file per problem. Each contains a Solution class matching the LeetCode signature, plus a main() guarded by #ifdef LOCAL_TEST that exercises the solution against a few hardcoded cases.

  • A CMakeLists.txt that builds every file as its own executable (via file(GLOB_RECURSE)).

  • A GitHub Actions workflow that on every push compiles all 150 files with -Wall -Wextra -Werror on both GCC and Clang, and runs the LOCAL_TEST main for each. If any solution fails to compile or its self-test fails, CI is red.

  • A top-level README with a progress table: pattern, count solved / total, difficulty distribution.

  • A per-pattern README under each subdirectory: brief notes on the pattern (Sliding Window, Two Pointers, DP, etc.) and links to the problems solved.

Each .cpp file starts with a mandatory header comment:

// Problem:      Two Sum
// Link:         https://leetcode.com/problems/two-sum/
// Difficulty:   Easy
// Pattern:      Array / Hash Map
// Time:         O(n)
// Space:        O(n)
// Notes:        Prefer std::unordered_map; watch for duplicate values.

This header is not optional. It is the reason the repo is useful to skim.

Why It Matters (Employer Signal)

One line: “DSA muscle in C++ specifically, not just Python — and I keep it green in CI.”

This matters for two reasons. First, most applied-ML engineers who claim C++ on their resume have never solved a full DSA problem in C++; study partners know this and probe for it. Rung 4 is your evidence that you have. Second, the CI-compiles-all-150 element is what turns a folder of solutions into an engineering artifact — it says you care about the code enough to keep it building on every push.

Acceptance Checklist

  • Public GitHub repo named neetcode-150-cpp.

  • 150 solutions, organized by pattern (Arrays, Hashing, Two Pointers, Sliding Window, Stack, Binary Search, Linked List, Trees, Tries, Heap, Backtracking, Graphs, Advanced Graphs, 1-D DP, 2-D DP, Greedy, Intervals, Math, Bit).

  • Every file has the header comment above, fully filled in.

  • Every file compiles under -std=c++20 -Wall -Wextra -Werror on GCC 13 and Clang 17.

  • Every file’s LOCAL_TEST main passes.

  • Top-level README shows a progress table and a pattern coverage table.

  • .github/workflows/ci.yml compiles all 150 on push, both compilers, plus one job that runs the tests.

  • CI badge in README, green.

  • Consistent code style, enforced by .clang-format.

  • License: MIT (with a note that problem statements are the property of LeetCode).

  • Repo shared on r/leetcode with a milestone post at 50, 100, and 150 solved.

Where to Publish and Share

  • GitHub: public, MIT, topics: cpp, leetcode, neetcode-150, dsa, interview-preparation.

  • Reddit: r/leetcode at each milestone (50 / 100 / 150). Not r/cpp — they do not want to see LeetCode there.

  • LinkedIn: one milestone post at 150 with the repo link. This is genuinely a talking point for recruiters.

  • In your resume: link this repo under “Projects” as “NeetCode-150 in C++ — all 150 solutions, CI-compiled on every push.”

Common Ways This Rung Fails

  • You solve them but never commit consistently. M5 is 4 weeks. 150 problems is ~5-6 problems per day at 10-15 hrs/week. That is real. Do not try to finish in the last week.

  • CI is not set up until the end. Then you find out 30 of your solutions don’t compile on Clang and you spend the last week fixing them. Set up CI on day one with 3 solutions in it. Extend from there.

  • You copy solutions from NeetCode’s videos verbatim. Fine for learning; deadly for portfolio. If a hiring manager runs your solution style through a plagiarism check against neetcode.io’s samples, you lose credibility. Solve first, then write your own version.

  • You skip the header comment. Then the repo is unbrowsable. The header comment is the reason a stranger will spend more than 5 seconds in your repo.

  • You mix Python solutions in. Don’t. This repo is a C++ signal. If you want a Python one, put it in a separate repo.

What Most People Get Wrong

They treat this as a personal notebook and forget it is a portfolio piece. That means: no README, no pattern organization, no CI, inconsistent style. The result is a neetcode-solutions repo that looks exactly like the other 10,000 on GitHub. The organization and CI are what make yours different. The solutions themselves are commodity content — what a hiring manager evaluates is your engineering around them.

The second mistake: publishing at 50 solved with the plan to keep going, and then never getting to 150. Ship at 150 or don’t ship. A repo called “neetcode-150-cpp” with 87 solutions is worse than not publishing at all — it broadcasts abandonment.

Extension Challenges (Only If M5 Has Slack)

  • Add a difficulty-weighted progress bar in the README that renders from a JSON file the CI updates.

  • Add coverage of Blind-75 as a subset badge in the README.

  • Add a per-pattern “pattern write-up” — 500 words explaining when to reach for that pattern. This alone can become blog content.

  • Add gtest-style test cases for the trickier problems (subarray sum, merge intervals) that go beyond LOCAL_TEST.