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/lifei6671/interview-go 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.

GO — Healthy across all four use cases

• Last commit 5mo ago
• 17 active contributors
• Distributed ownership (top contributor 49% of recent commits)
• Apache-2.0 licensed
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ No CI workflows 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 lifei6671/interview-go repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/lifei6671/interview-go.

What it runs against: a local clone of lifei6671/interview-go — 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 lifei6671/interview-go | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 186 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of lifei6671/interview-go. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/lifei6671/interview-go.git
#   cd interview-go
#
# 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 lifei6671/interview-go and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

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

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "question/q001.md" \\
  && ok "question/q001.md" \\
  || miss "missing critical file: question/q001.md"
test -f "base/go-scheduler.md" \\
  && ok "base/go-scheduler.md" \\
  || miss "missing critical file: base/go-scheduler.md"
test -f "algorithm/reverse_list.go" \\
  && ok "algorithm/reverse_list.go" \\
  || miss "missing critical file: algorithm/reverse_list.go"
test -f "docs/index.html" \\
  && ok "docs/index.html" \\
  || miss "missing critical file: docs/index.html"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 186 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~156d)"
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/lifei6671/interview-go"
  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 curated collection of Go interview questions, algorithms, and theoretical explanations hosted as a Jekyll-based website (interview.disign.me). It provides practical Go code solutions (31.5K lines) alongside detailed markdown explanations for concurrent programming, data structures, sorting algorithms, and common mistakes—serving as both a study guide and quick reference for Go job interviews. Multi-topic monorepo organized as a Jekyll site: /question/ holds interview Q&A (q001.md–q025.md), /algorithm/ contains Go implementations with /algorithm/docs/ explanations and /algorithm/list/ for linked-list problems, /base/ covers GMP scheduler and goroutine theory, /redis/, /mysql/, /architecture/, /llm/ hold domain-specific topics. Each question typically pairs a .md explanation with runnable .go code examples.

Go developers preparing for technical interviews, particularly those targeting roles at companies like ByteDance. Contributors are Go engineers who've encountered tricky concurrency patterns (goroutines, channels, sync.Map), algorithm challenges, or architectural design questions in real interviews.

Actively maintained educational resource with stable, growing content. The repository shows regular additions (algorithm/list/ examples, base/ theory sections), clear organization into question/base/redis/mysql/architecture folders, and a live website deployment. No apparent CI/test automation evident, but the nature (curated Q&A) means maturity is measured by content completeness rather than test coverage—verdict: actively developed and production-deployed.

Low technical risk as a static content repository—no runtime dependencies or complex CI/CD. Single-maintainer risk (lifei6671) is moderate for a resource-only project. Primary risk is content staleness (Go 1.x features may not reflect current best practices) and lack of peer review process for solutions. No evidence of issue tracking or pull request review workflow visible.

Based on file structure, active areas include expanding algorithm solutions (array intersection, 3sum variants, string matching with Sunday algorithm), deep-diving into Go scheduler theory (base/go-gpm.md, base/go-scheduler.md, base/go-scheduler-base.md), and adding Redis/MySQL/architecture interview content. Recent focus appears to be linking to external study.disign.me articles on GC and memory leaks.

git clone https://github.com/lifei6671/interview-go.git
cd interview-go
# This is a Jekyll static site; install Ruby and dependencies:
bundle install
# Preview locally on http://localhost:4000:
bundle exec jekyll serve

Daily commands: This is a documentation site, not an executable application. To preview changes: bundle exec jekyll serve generates _site/ locally. To run individual Go examples: go run algorithm/3sum-closest.go or execute test cases in /algorithm/testdata/. No standard 'start' command—consume as a website or extract .go files for execution.

• README.md — Entry point listing all 25+ interview questions and theoretical topics; defines the repo's scope and navigation structure.
• question/q001.md — First canonical question (alternating digits/letters) establishing the Q&A format used throughout the interview collection.
• base/go-scheduler.md — Core theoretical foundation explaining Go's GPM scheduler—essential context for understanding concurrency questions in q009-q015.
• algorithm/reverse_list.go — Representative algorithm implementation demonstrating coding style and patterns used across the collection.
• docs/index.html — Generated documentation site entry point; required for understanding how this repo is deployed and consumed by readers.
• base/redis.md — Theoretical foundation for Redis topics referenced in multiple interview questions and data structure problems.
• algorithm/list/README.md — Organizational guide for linked-list algorithm problems; demonstrates how algorithm sections are subdivided and documented.

• README.md + Question Index (Markdown, GitHub README rendering) — Entry point and table of contents; curates 25+ questions into logical categories (syntax, concurrency, algorithms, theory, architecture)
  • Failure mode: If outdated or links break, readers cannot discover content; trust in curation erodes
• Question Files (question/q.md)* (Markdown, embedded Go code blocks) — Core interview preparation material; each file pairs a coding/conceptual problem with explanation, analysis, and Go code
  • Failure mode: Errors or unclear explanations lead to incorrect interview prep; misunderstandings in Go concurrency are particularly risky
• Algorithm Implementations (algorithm/.go, algorithm/list/.md) (Go, Markdown, diagrams (PNG/JPG in images/)) — Concrete Go solutions to classic coding problems (linked lists, sorting, string manipulation, sliding windows); paired with documentation
  • Failure mode: Incorrect implementations or missing edge cases teach wrong patterns; linked list diagrams with wrong pointers confuse visual learners
• Theoretical Base (base/*. — undefined

Add a New Interview Question

1. Create new markdown file following existing format (q026.md, q027.md, etc.) (question/q001.md)
2. Write question with problem statement, analysis, and code example in markdown (question/q009.md)
3. Add reference link to README.md in the appropriate section (Syntax, Concurrency, Algorithm, etc.) (README.md)
4. Update docs/_sidebar.md to include new question in navigation menu (docs/_sidebar.md)

Add a New Algorithm Problem with Implementation

1. Create .go file in algorithm/ or appropriate subdirectory (e.g., algorithm/new-problem.go) with implementation (algorithm/reverse_list.go)
2. Create corresponding .md documentation in algorithm/docs/ with problem description and explanation (algorithm/docs/reverse-string.md)
3. Add link to README or create section in algorithm/0001.md for visibility (algorithm/0001.md)
4. If part of linked list or specialized category, update relevant algorithm/list/README.md or category (algorithm/list/README.md)

Add a New Theoretical Foundation Article

1. Create markdown file in base/ directory (e.g., base/go-memory-management.md) (base/go-scheduler.md)
2. Include detailed explanations with diagrams/images referencing images/ folder (base/redis.md)
3. Add reference link to README.md under 'Golang 理论' section (README.md)
4. Update docs/_sidebar.md to include in documentation site navigation (docs/_sidebar.md)

Add Architecture Design Topic

1. Create numbered markdown file in architecture/ (e.g., architecture/0014.md following 0001-0013 pattern) (architecture/0001.md)
2. Write system design topic with patterns, tradeoffs, and Go implementation considerations (architecture/0010.md)
3. Link from README.md or relevant question files that reference the architecture concept (README.md)

• Markdown + GitHub Pages (docsify/Jekyll) — Low-friction content authoring; free hosting; built-in Git versioning; searchable web UI without backend infrastructure
• Go code examples (.go files) — Interview-realistic; executable and testable; demonstrates idiomatic Go patterns directly relevant to hiring assessments
• Static site generation (Jekyll/_config.yml) — No runtime dependencies; fast load times; suitable for large Q&A collections; automatic GitHub Pages deployment

• Pure Markdown Q&A over interactive IDE/sandbox

  • Why: Simplifies maintenance; no backend; leverages GitHub ecosystem
  • Consequence: Readers must manually run/test code; no real-time execution feedback; reduced hands-on learning but lower barrier to contribution

• Curated question collection over auto-generated from tests

  • Why: Human-vetted explanations; pedagogical narrative; editorial quality control
  • Consequence: Manual effort to add/update; slower to scale; but higher signal-to-noise ratio for interview prep

• Separate algorithm/ and question/ directories over unified structure

  • Why: Allows multi-level organization (list, sort subcategories); easier to grow algorithm library independently
  • Consequence: Slight navigation complexity; but better scalability and focused problem grouping

• Real-time code execution sandbox (no backend LeetCode-style judge)
• Interactive debugging or visualization tools (static content only)
• Authentication, user progress tracking, or personalized learning paths
• Mobile-first application (web-friendly static site, not native app)
• Multi-language interview preparation (Go/Golang-focused only)
• Enterprise training platform features (free, self-service study guide)

No hidden service dependencies—this is a pure static site. However: (1) Jekyll requires Ruby + bundler; bundle install can fail on M1 Macs without proper Ruby setup. (2) Go examples in algorithm/ are standalone but may use older idioms (no generics, pre-1.18 patterns). (3) External links to study.disign.me (q019, q020, GC article) are not mirrored locally—if that domain goes down, those references break. (4) Test data in /algorithm/testdata/ip.data is referenced but not all .go files have corresponding test files or usage examples.

• Goroutine Scheduling (GPM Model) — Understanding Go's Processor-Memory-Goroutine scheduler is essential for solving concurrency interview questions (q009, q015, q017) and avoiding deadlocks or race conditions
• Channel Communication & Close Semantics — Question q018 directly tests behavior when reading/writing closed channels; this is a critical footgun in Go concurrency that requires precise mental model
• Memory Escape Analysis — Interview q019 covers memory escape; Go's escape analyzer determines whether variables live on stack or heap, affecting GC pressure and performance—crucial for optimization questions
• String-to-Byte Conversion & Copy Semantics — Q020 addresses whether string→[]byte conversion triggers allocation; understanding Go's string immutability and slice backing array is essential for performance-aware code
• Sunday String Matching Algorithm — Algorithm/docs/match-sunday-string.md teaches a substring search variant faster than naive O(nm) in average case—demonstrates algorithmic optimization beyond basic string methods
• Sliding Window Maximum (Deque Pattern) — Algorithm/docs/sliding-window-maximum.md uses a monotonic deque to solve O(n) in single pass; this pattern appears in many coding interview problems (LeetCode 239, etc.)
• sync.Map vs Regular map[string]interface{} Under Contention — Q010, Q011, Q022 test understanding of when sync.Map (optimized for read-heavy concurrent access) beats sync.RWMutex+map patterns—critical for high-concurrency system design

• golang/go — Official Go repository—source of truth for runtime behavior, scheduler implementation, and language spec referenced in base/ theory documents
• grpc/grpc-go — Production Go concurrency patterns and channel usage examples that complement the interview questions on goroutines and sync patterns
• etcd-io/etcd — Large-scale Go codebase demonstrating real-world solutions to concurrency, distributed systems, and performance challenges covered in architecture/ section
• awesomeGO/awesome-go — Comprehensive curated list of Go libraries and frameworks—useful companion for understanding ecosystem context when studying interview topics
• halfrost/LeetCode-Go — Similar algorithm-focused interview prep repo with LeetCode solutions in Go; alternative resource for algorithm pattern drilling alongside this repo's explanations

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 unit tests for algorithm Go files (algorithm/*.go)

The algorithm directory contains many standalone .go files (3sum-closest.go, add-binary.go, array-intersection.go, etc.) but no corresponding *_test.go files. This repo is an interview preparation resource, so demonstrating proper Go testing practices with unit tests for each algorithm would be both educational and ensure code correctness. Tests would verify the algorithm implementations match their documented behavior in algorithm/docs/.

• [ ] Create algorithm/3sum-closest_test.go with test cases for 3sum-closest.go
• [ ] Create algorithm/add-binary_test.go with test cases for add-binary.go
• [ ] Create algorithm/array-intersection_test.go with test cases for array-intersection.go
• [ ] Add tests for other algorithms (kmp-string.go, reverse-string.go, sliding-window-maximum.go, etc.)
• [ ] Create algorithm/sort/ subdirectory tests for bubble_sort.go, insertion_sort.go, selection_sort.go
• [ ] Ensure tests reference testdata/ip.data where applicable

Add missing solution documentation for algorithm/list/ problems

The algorithm/list/ directory contains 8 linked list problems with markdown files and images, but many lack Go implementation files. Adding .go solution files (e.g., reverse-list.go exists but corresponding solutions for problems 2-8 are missing) would complete this popular interview topic and match the pattern used in the main algorithm directory.

• [ ] Create algorithm/list/reverse-list.go for problem 1 (反转链表)
• [ ] Create algorithm/list/reverse-interval.go for problem 2 (链表内指定区间反转)
• [ ] Create algorithm/list/merge-sorted-lists.go for problem 3 (合并两个排序的链表)
• [ ] Create algorithm/list/detect-cycle.go for problem 4 (判断链表中是否有环)
• [ ] Create algorithm/list/find-cycle-start.go for problem 5 (链表中环的入口结点)
• [ ] Create algorithm/list/kth-from-end.go for problem 6 (链表中倒数最后k个结点)
• [ ] Create algorithm/list/remove-nth-node.go for problem 7 (already exists as removeNthFromEnd.go, verify consistency)
• [ ] Create algorithm/list/first-common-node.go for problem 8 (两个链表的第一个公共结点)

Create Go test files for question/ directory problems

The README references 25+ interview questions in question/q001.md through question/q025.md, but there are no corresponding .go implementation or test files in the repository. Adding runnable Go solutions with tests for at least the concurrency problems (q009, q010, q011, q013, q015, q018, q022) would provide practical value for interviewees preparing for Go-specific challenges.

• [ ] Create question/q009_goroutine_channel_test.go for goroutine and channel usage problem
• [ ] Create question/q010_concurrent_map.go and corresponding test for blocking concurrent map
• [ ] Create question/q011_concurrent_map_lock_test.go for high-concurrency lock and map issue
• [ ] Create question/q013_waitgroup_timeout_test.go for WaitGroup.Wait() timeout functionality
• [ ] Create question/q015_concurrency_test.go for golang concurrency test problem
• [ ] Create question/q018_closed_channel_test.go demonstrating read/write behavior on closed channel
• [ ] Create question/q022_sync_map_test.go for sync.Map usage patterns

• Add unit tests for algorithm implementations—currently algorithm/*.go files lack *_test.go files. Start with algorithm/3sum-closest.go and algorithm/reverse-string.go to establish test patterns.
• Complete missing algorithm documentation—files like algorithm/ip-start-end-query.go and algorithm/kmp-string.go have .go implementations but no corresponding .md explanation in algorithm/docs/. Pick one and write a detailed explanation matching the style of algorithm/docs/3sum-closest.md.
• Migrate external article links into the repo—question/q019.md and q020.md reference external study.disign.me URLs for 'memory escape' and 'byte array copy'. Create new /base/go-escape-analysis.md and /base/go-string-bytes.md with standalone explanations so no external links are required.

This is a Golang interview question and algorithm learning repository with minimal security concerns. The codebase is primarily educational documentation and algorithm implementations without complex dependencies or configuration. No critical vulnerabilities were identified. The main recommendations are standard open-source best practices: ensuring any actual Go modules have proper dependency tracking (go.mod/go.sum), reviewing test data for sensitive information, and establishing a security policy. The low security score deductions are due to absence of security documentation and best practices rather than active vulnerabilities in the code itself.

• Low · No dependency lock file detected — Root directory - Missing go.mod/go.sum. The repository appears to be primarily documentation and algorithm examples without a go.mod or go.sum file visible. While this is acceptable for educational content, it makes dependency tracking impossible if this code were to be used in production. Fix: If this repository is used as a library or in production, ensure go.mod and go.sum files are present and committed to version control for reproducible builds.
• Low · Test data file included — algorithm/testdata/ip.data. The file 'algorithm/testdata/ip.data' is included in the repository. Test data files should be reviewed to ensure they do not contain sensitive information, credentials, or real production data. Fix: Review the content of test data files to ensure they contain only sanitized, non-sensitive test values. Consider using .gitignore rules for large or sensitive test data.
• Low · No security policy or SECURITY.md — Root directory - Missing SECURITY.md. The repository does not appear to have a SECURITY.md file or security vulnerability reporting policy, which is a best practice for open-source projects. Fix: Create a SECURITY.md file documenting how security vulnerabilities should be reported privately before public disclosure.
• Low · Limited input validation patterns — algorithm/*.go files. As an interview question/algorithm repository, there is minimal evidence of input validation in the code structure. If these algorithm implementations are used as reference code, developers may not implement proper input validation in production code. Fix: Add comments in algorithm implementations highlighting where input validation should occur in production code. Include security notes in 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.