Rung 3 — NeetCode-75 in C

Headline. All 75 NeetCode problems solved in idiomatic C — not translated from Python, not leaning on a garbage collector, not skipping the ones where memory management is the hard part.

Month target. M5 (November 2026). Publish incrementally; the “done” moment is the day problem 75 lands with green tests.

What You Build

Repo name: neetcode-75-in-c. One folder per problem: problems/<num>_<slug>/.

Each problem folder contains:

  • README.md — problem statement (paraphrased in your words, not copy-pasted from LeetCode — that would be a ToS violation), input/output examples, constraint bounds.

  • solution.c — your solution. Header comment MUST include: Time: O(…) — Space: O(…) — Approach: one-sentence summary.

  • tests.c — at minimum 5 test cases: 2 from the problem examples, 1 edge case (empty input), 1 large input (stress), 1 adversarial (worst-case shape).

  • Makefile — one target: test. Runs the binary, compares stdout to expected, exits 0 or non-zero.

  • RETRY.md (only if applicable) — if you failed the problem on first attempt and retried, log what changed: wrong data structure? off-by-one? bad complexity? This file is for you but visible — it is honesty as portfolio.

Root-level:

  • README.md — the aggregate: table of all 75 problems with columns [#, name, difficulty, time-to-solve, retries, complexity, DS used].

  • .github/workflows/ci.yml — runs make test in every problem folder on every push. This CI must stay green after every commit.

  • stats.md — aggregate stats: mean time-to-solve per difficulty tier, retry rate, most-used data structure.

Target size: ~5000-8000 LOC of C total across 75 problems.

Why This Rung, Why Now

By M5, you’ve had 5 months of C. Rung 3 answers a specific fear a hiring manager has: “Will this person reach for Python when the study whiteboard says ‘implement a hashmap’?” If your GitHub shows 75 problems solved in C — with the memory management fully handled, no strdup sloppiness, no leaked allocations — that fear is dead.

You ship in M5 (not M4, not M6) because Rung 3 is the last rung where the individual artifacts are small enough to sprint. Rungs 4-6 are single-project marathons. Rung 3 is 75 sprints. It calibrates your “can I finish a small thing in one sitting” muscle, which will be tested every day of Rungs 4-6.

Acceptance Criteria

  • 75/75 problems in problems/ with solution.c + tests.c

  • Every solution.c has an explicit Time / Space / Approach header comment — no exceptions

  • CI runs all 75 test binaries on push and is green on main

  • Aggregate README.md table lists all 75 with per-problem metadata

  • At least 15 problems have a RETRY.md (if you have zero retries across 75, either you’re a savant or you’re not solving before peeking — both need addressing)

  • 5 hardest problems (by your retry count) have long-form writeups cross-posted to r/C_Programming as individual threads

  • Zero memory leaks reported by Valgrind on a spot-check of 10 random problems

  • Zero ASan errors across full test suite

Where to Publish

  • GitHub: pinned on profile. Topics: c, algorithms, neetcode, interview-preparation.

  • Reddit — r/C_Programming: post only the 5 hardest, one at a time, over 5 weeks. Title format: “How I solved [problem] in C — [one specific technique]”. Never spam-post the repo. Each post is a technique writeup, not an ad.

  • LinkedIn: one post at the end of M5, framed as “75 algorithm problems in C, here’s what surprised me about the language.” Include 3 concrete surprises — e.g., “I re-implemented my own hashmap 40 times before I was fast enough to move on.”

  • Personal blog / dev.to: the 5 hardest writeups can be cross-posted here as long-form.

Signal to Recruiter / Employer

“DSA in C is routine for this person. They don’t reach for a garbage collector when the problem gets sticky. If we hand them a C codebase and ask them to add a feature that requires a new data structure, they will not silently reach for std::unordered_map.”

Rung 3 is also the rung that opens the door to study loops. Many companies use LeetCode-style rounds; being able to say “I’ve done all of NeetCode-75 in C, here’s the repo” is a stronger signal than “I’ve done a lot of LeetCode” — the language constraint is a proof-of-work stamp.

Common Failure Modes

  1. Fake completion via one-liner solutions. You solve the easy problems in 3 lines and count them. Fine — but if all 25 easy problems have identical file structures with no thought about memory, a reviewer notices. Detection: even easy problems should have a Time/Space/Approach header comment; if 25 files have the exact same generic comment, that’s copy-paste labor, not thought.

  2. Leaks in the test harness. Your solution is clean but tests.c leaks setup memory. Valgrind reports leaks and you assume it’s the solution. Detection: run Valgrind against a solution you know is leak-free (a hello-world) to establish baseline behavior.

  3. Skipping the memory-heavy problems. “Copy List with Random Pointer”, “LRU Cache”, “Design Twitter” are the ones people quietly drop. Detection: these must be in the repo. If they’re not, you have not done Rung 3 — you have done Rung 3-minus-hard.

  4. RETRY.md files that all say “I forgot a free.” If every retry log has the same excuse, either you have one blind spot (worth naming and drilling) or you’re not writing honest retry logs.

Estimated Hours

  • 25 easy problems × 30-45 min = ~15h

  • 40 medium problems × 60-90 min = ~50h

  • 10 hard problems × 2-4h = ~30h

  • Aggregate README + stats + polish: ~5h

  • 5 writeup posts (Reddit + blog): ~10h

Total: ~110 hours across M4-M5. ~14h/week for two months. This is the most sustained sprint on the ladder before Rung 5.

Prior-Art / Inspirations to Study First

  • neetcode.io — the canonical list. Read the problem descriptions once; do not read the C solutions of others until you’ve solved yours.

  • begoon/leetcode-in-c and similar GitHub repos — skim only for repo structure (folder-per-problem, README table), never for solutions.

  • skeeto (Chris Wellons) blog — read two or three of his posts on memory arenas. His allocator-first mental model will save you 20 hours of free-tracking pain.

Return to README.md · Previous: 02_rung_2_libprep_containers.md · Next: 04_rung_4_mini_shell.md