Phase 2 Projects — Public Signal, Employer-Facing

“An unpublished repo is a private hobby. A published, CI-green repo with a rigorous README is a professional artifact. The latter gets you studies.”

Phase 2 produces two public artifacts. Both go on your resume. Both link from your LinkedIn banner. Both are polished to the level where a hiring manager scanning for 90 seconds forms a positive impression.

P2.1 — NeetCode-150 public repo (target: W20)

Goal

All 150 NeetCode solutions in C++, in one repo, with GitHub Actions CI compiling every file on every push, and a README that a stranger can navigate.

Structure

neetcode-150-cpp/
├── README.md                     # nav + weekly mock log
├── .github/workflows/ci.yml       # compile all 150 files
├── CMakeLists.txt                 # or a plain Makefile
├── 01_arrays_hashing/
│   ├── 001_contains_duplicate.cpp
│   ├── 002_two_sum.cpp
│   └── ...
├── 02_two_pointers/
│   └── ...
└── 18_bit_manipulation/
    └── ...

Per-file header format

Every .cpp file starts with this exact block. It is your commitment to rigor and it is what recruiters skim.

// LeetCode 001. Two Sum  |  https://leetcode.com/problems/two-sum/
// Difficulty: Easy
// Pattern:   Arrays & Hashing (unordered_map for O(1) lookup)
// Time:      O(n)     Space: O(n)
// Solved:    2026-07-15   Retry: none   Time-to-first-correct: 6 min
// Notes:     one-pass; check-before-insert order matters.

#include <bits/stdc++.h>
// ... solution ...

CI (GitHub Actions)

.github/workflows/ci.yml:

name: Compile all solutions
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install
        run: sudo apt-get install -y g++-13
      - name: Compile every .cpp
        run: |
          FAILED=0
          for f in $(find . -name '*.cpp'); do
            echo "--- $f"
            g++-13 -std=c++20 -Wall -Wextra -Wpedantic -c "$f" -o /dev/null || FAILED=1
          done
          exit $FAILED

Acceptance criteria

  • 150 .cpp files, one per problem, in category-numbered directories.

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

  • CI green on main.

  • README with: category index, current progress badge (“142 / 150”), weekly mock log, list of problems that took a retry.

  • Repo pinned on your GitHub profile.

  • Repo link on your LinkedIn banner + resume.

Traps

  • Do not check in LeetCode’s copyrighted problem statement text. Just link to the URL. Solutions are yours; statements are theirs.

  • Do not batch commit. One commit per solved problem (or per session, at worst). The commit graph is itself signal.

  • Do not write int solve() for every problem. Follow LeetCode’s class Solution { public: ... }; shape so your local file matches your submission byte-for-byte.

Employer signal

Recruiter reads: “He solved 150 problems, categorized, CI-compiled, self-logged.” Signal: this candidate is systematic, ships, and cares about the meta-work, not just the object-work. That is rarer than raw talent and it converts.

P2.2 — DSA Cheatsheet (public gist or blog post) (target: W20)

Goal

A single polished document — the templates from file 04 with prose, plus your own commentary and 3 “gotchas I learned the hard way” per pattern — published somewhere durable. Either a public GitHub Gist, or a personal blog post on your existing site, or Dev.to / Hashnode.

Structure

  1. Foreword (100 words). Who you are, why you wrote this, honest disclaimer (“this is what I use, not the platonic ideal”).

  2. Fifteen templates from file 04. Formatted with syntax highlighting. Each with a 3-sentence “when to use” and 2–3 concrete LeetCode links.

  3. Common bugs section. The eight from file 01 (long long, unordered_map DoS, auto&, size_t underflow, etc.).

  4. What I would tell my past self. ~200 words. Personal, specific, not generic advice.

Publishing decision tree

  • Personal blog (best): shows domain ownership, SEO benefits accrue to you, permanent record. Use it if you already have a blog or want one.

  • GitHub Gist: zero-friction, git-versioned, links well from your resume.

  • Dev.to / Hashnode: cross-post from either of the above. Free reach, existing audience of engineers.

Acceptance criteria (choose one path)

Path A — reddit-validated:

  • Published on r/leetcode or r/cscareerquestions.

  • ≥ 20 upvotes within 7 days.

  • At least 3 substantive comments (not just “nice, thanks”).

Path B — blog-driven:

  • Published on your personal blog.

  • ≥ 3 distinct referrer sources in analytics within 30 days (HN, Twitter, Reddit, LinkedIn, DevPost, direct — pick any three).

  • At least one incoming link from a non-social site (someone linking to you in their own post).

If neither path lands within 30 days of publishing, the artifact still counts but your distribution strategy needs a rethink — fold that into your Phase 8 portfolio review.

Traps

  • Do not pad. 15 templates, 8 gotchas, 200 words of personal reflection. That is the whole thing. Cheatsheets that try to be textbooks fail.

  • Do not present other people’s work as yours. If a template is Erik Rigtorp’s or NeetCode’s, cite them by name and link.

  • Do not use ChatGPT to write the prose. A hiring manager can smell it. Write in your voice.

Employer signal

“He shipped a public artifact that other people read.” This puts you above the ~95% of candidates who never publish anything. The exact upvote number matters less than the fact of a live URL you can drop into a cover letter.

Nav: ← study simulation · Phase 3 README →