If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/careercup/ctci shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Stale and unlicensed — last commit 3y ago

• 15 active contributors
• Distributed ownership (top contributor 25% of recent commits)
• ⚠ Stale — last commit 3y ago
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live careercup/ctci repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/careercup/ctci.

What it runs against: a local clone of careercup/ctci — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in careercup/ctci | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | Last commit ≤ 1077 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of careercup/ctci. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/careercup/ctci.git
#   cd ctci
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of careercup/ctci and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "careercup/ctci(\\.git)?\\b" \\
  && ok "origin remote is careercup/ctci" \\
  || miss "origin remote is not careercup/ctci (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1077 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1047d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/careercup/ctci"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A multi-language solutions repository for Cracking the Coding Interview, 5th Edition, containing algorithmically-complete implementations across 13 programming languages (Java 394KB, Dart 334KB, C# 242KB, Python 131KB, Go 98KB, C++ 82KB, and others). It serves as a comprehensive reference for interview problem solutions organized by chapter, with working implementations of classic data structures (linked lists in Go/Chapter 2/list/) and algorithms (quicksort variants in C/Algorithms/). Monorepo organized by language directory (C/, Go/, Java/, etc.), then by chapter (Chapter 1/, Chapter 2/), then by question (Question1_1/, Question2_3/). Within each question folder, core implementation lives in Question.go or ChapQ1.1.c, with test files (Question_test.go) in Go directories and shared data structures like Go/Chapter 2/list/list.go providing reusable abstractions.

Job candidates preparing for technical interviews at FAANG companies who want to learn interview problem patterns across multiple languages, and junior engineers onboarding to a codebase who need to understand how solutions are structured differently in Java vs. Go vs. C#. Also useful for computer science educators teaching algorithm implementation across language paradigms.

This is a mature study/reference repository with broad language coverage and consistent chapter-question structure, but it is not under active development—it appears to be a static solution set for CTCI 5th Edition with no visible CI/CD setup, no test automation framework, and no recent activity indicated. Use it as a learning reference, not as production code or a template for new projects.

Standard open source risks apply.

The repository appears dormant. No ongoing work is evident—it is a completed solutions archive for CTCI 5th Edition. Recent contributor notes mention 'Adding equivalent solutions in Objective-C' and 'Adding my own solutions,' suggesting past pull requests added language variants, but no active sprints or feature branches are indicated.

Clone the repository and navigate to your target language: git clone https://github.com/careercup/ctci.git && cd ctci && ls. For Go examples (most complete): cd Go/Chapter\ 1/Question1_1 && go test -v to run tests. For C examples: cd C/Chapter_1/Question1_1 && gcc -o ChapQ1.1 ChapQ1.1.c && ./ChapQ1.1. No build system or package manager config is required—each language solution is standalone.

Daily commands: Go: cd Go/Chapter\ 1/Question1_1 && go run Question.go or go test -v. C: cd C/Chapter_1/Question1_1 && gcc ChapQ1.1.c -o solution && ./solution. No unified build system—each language is self-contained and compiler/runtime specific. No Makefile or package.json visible; run code directly with language tools.

• [Go/Chapter 1/Question1_1/Question.go](https://github.com/careercup/ctci/blob/master/Go/Chapter 1/Question1_1/Question.go): Reference implementation showing idiomatic Go solution structure and function signature pattern replicated across Go/ solutions
• [Go/Chapter 1/Question1_1/Question_test.go](https://github.com/careercup/ctci/blob/master/Go/Chapter 1/Question1_1/Question_test.go): Demonstrates the testing.T convention used across Go examples; only language with consistent test coverage visible
• [Go/Chapter 2/list/list.go](https://github.com/careercup/ctci/blob/master/Go/Chapter 2/list/list.go): Shared data structure (linked list) implementation used by multiple Chapter 2 questions; shows code reuse pattern
• C/Algorithms/quicksort.c: Core algorithm implementation in C showing low-level approach; paired with quicksort_modified.c to illustrate variant solutions
• C/Chapter_1/Question1_1/ChapQ1.1.c: Entry point for C solutions; demonstrates Chapter + Question naming convention replicated across language folders

To add a solution: (1) Create new directory Go/Chapter\ X/QuestionX_Y/, (2) Implement Question.go with a clear function signature, (3) Add Question_test.go with test cases using Go's testing package as the pattern, (4) For C: create C/Chapter_X/QuestionX_Y/ChapQX.Y.c. For data structures used across questions: contribute to Go/Chapter\ 2/list/list.go or create analogues. Reference existing files like Go/Chapter\ 1/Question1_1/Question.go for function naming style.

No hidden environment variables or service dependencies—this is pure algorithm code. However: (1) Go solutions assume Go 1.x installed; (2) C solutions use only standard POSIX; (3) No unified test runner exists, so you must invoke tests per-language (go test in Go/, manual gcc compilation in C/); (4) Fifth Edition CTCI may be outdated for modern interview prep—6th Edition exists with revised problems; (5) Language implementations may diverge in quality or correctness since no code review process is evident.

• String Manipulation & Hashing — CTCI Chapter 1 heavily focuses on string uniqueness and permutation checking, which require understanding character encoding, hash tables, and collision handling
• Linked List Operations — CTCI Chapter 2 is dedicated to linked lists; the Go/Chapter\ 2/list/list.go implementation shows insertion, deletion, and traversal patterns fundamental to interview problems
• In-Place Sorting (Quicksort Variants) — C/Algorithms/ contains quicksort and quicksort_modified showing partition-based sorting; understanding O(n log n) average case and O(n²) worst case is critical for algorithm interviews
• Time & Space Complexity Analysis — Every CTCI solution requires Big-O analysis of runtime and memory; this repo's multiple implementations of same problems allow comparison of trade-offs (e.g., Question_test.go vs. QuestionB.go alternate approaches)
• Recursion & Backtracking — CTCI problems frequently use recursive solutions; understanding stack frames, base cases, and pruning is essential for chapters covering arrays, strings, and trees
• Data Structure Reuse & Abstraction — Go/Chapter\ 2/list/list.go demonstrates how a single linked list implementation serves multiple questions; learning to identify and extract reusable components improves code interview performance

• yangshun/tech-interview-handbook — Broader interview preparation guide covering system design and behavioral questions alongside algorithm problems; complements CTCI focus
• trekhleb/javascript-algorithms — Multi-language algorithm implementations with detailed explanations and visualizations; similar reference goal but more modern and actively maintained
• donnemartin/system-design-primer — Covers system design interview prep which CTCI 5th Edition lightly addresses; used by same candidate audience
• jwasham/coding-interview-university — Structured learning path for interview prep including data structures and algorithms; CTCI solutions fit as reference implementations in this curriculum

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for Go/Chapter 2 linked list implementations

Go/Chapter 2/list/list_test.go exists but Chapter 2 Questions (Question2_1 through Question2_7) are linked list problems with no corresponding test files. These questions lack test coverage despite having implementations. Adding tests would validate correctness and serve as usage examples for learners.

• [ ] Create Go/Chapter 2/Question2_1/Question_test.go with test cases for the linked list operation
• [ ] Create Go/Chapter 2/Question2_2/Question_test.go with test cases (Remove Duplicates)
• [ ] Create Go/Chapter 2/Question2_3/Question_test.go with test cases (Find Kth to Last)
• [ ] Create Go/Chapter 2/Question2_4/Question_test.go through Question2_7/Question_test.go following the same pattern
• [ ] Ensure tests use the list.go helper from Go/Chapter 2/list/

Add missing unit tests for Go/Chapter 3 stack-based questions

Go/Chapter 3/Question3_1 through Question3_7 implement stack problems but lack test files (only Go/Chapter 3/list/ and Go/Chapter 3/stack/ have basic test coverage). These question implementations need tests to validate their correctness, especially for complex problems like 3_5 (Sort Stack) and 3_6 (Animal Shelter).

• [ ] Create Go/Chapter 3/Question3_1/Question_test.go for Three in One stack problem
• [ ] Create Go/Chapter 3/Question3_2/Question_test.go for Stack Min problem
• [ ] Create Go/Chapter 3/Question3_3/Question_test.go for Stack of Plates
• [ ] Create Go/Chapter 3/Question3_4/Question_test.go through Question3_7/Question_test.go
• [ ] Ensure stack_test.go in Go/Chapter 3/stack/ covers all stack operations used by questions

Create C language test files for Chapter 1 string/array questions

C/Chapter_1/Question1_1 through Question1_4 contain implementations but no test files (.c files lack corresponding _test.c files). Unlike Go code with established testing patterns, adding simple C test runners would help validate correctness and provide examples for learners using the C solutions.

• [ ] Create C/Chapter_1/Question1_1/ChapQ1.1_test.c with test cases for is_unique_string()
• [ ] Create C/Chapter_1/Question1_2/ChapQ1.2_test.c with test cases for permutation checking
• [ ] Create C/Chapter_1/Question1_3/ChapQ1.3_test.c with test cases for URLify
• [ ] Create C/Chapter_1/Question1_4/ChapQ1.4_test.c with test cases for palindrome permutation
• [ ] Add a simple Makefile or build instructions in C/ directory to compile and run tests

• Add Question_test.go test files to all C/ solutions (currently only Go/ has tests). Start with C/Chapter_1/Question1_1/ChapQ1.1.c by creating a simple C unit test harness using assert.h or unity.h.
• Implement missing questions in Go. The file list shows Go/Chapter 1 has Questions 1-8 and Go/Chapter 2 has Questions 1-7, but CTCI Chapter 1 has ~9 questions and Chapter 2 has ~7. Verify completeness against the book and add stubs for missing questions.
• Create a README in each language directory (Go/README.md, C/README.md, Java/README.md) explaining how to run solutions, expected dependencies, and which CTCI chapters are covered. Currently only a root README exists.

This repository is a educational codebase for 'Cracking the Coding Interview' containing algorithm and data structure implementations in C, Go, and Swift. No critical security vulnerabilities were identified. The codebase is not a production application and contains no dependencies, infrastructure configuration, or sensitive operations that would typically introduce security risks. Minor observations include lack of input validation in algorithm implementations (expected for educational code) and absence of security documentation.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.