Interview Practice MCP Server

A local MCP server that gives Claude persistent memory of your DSA / HLD / LLD / Behavioral interview practice — backed by plain files on your disk that you can open and review anytime.

It knows a built-in catalog of ~230 problems (149 DSA, 30 HLD, 25 LLD, 29 Behavioral), tracks what you've attempted and when, and can recommend what to practice next: new problems, or ones due for revision, biased toward your flagged weak areas.

What it stores

Session/tracking data, under ~/interview-prep/ by default:

• revision.md — human-readable chronological log, one section per session. This is the file you review.
• index.json — compact machine index: sessions, aggregated weak areas, competency scores (Behavioral), and a per-problem tracker (times practiced, last verdict, last attempt date, absolute path to the linked solution/doc). Keeps Claude's context small.
• custom_catalog.json — problems you've added yourself (e.g. from a mock interview), merged with the built-in catalog.json shipped next to server.py.

Per-problem solutions/docs live in four independent, separately configurable directories — each defaults to a folder under ~/interview-prep/docs/ but is normally pointed at wherever your real practice work lives:

• DSA_SOLUTIONS_DIR (e.g. ~/code/DSA_mock) — organized as <Topic_Folder>/<problem>.py, one real Python file per problem grouped by topic, matching a typical personal LeetCode-practice layout. DSA is code, not markdown — see save_dsa_solution below.
• HLD_SOLUTIONS_DIR (e.g. ~/code/HLD) — one markdown file per HLD problem (e.g. design-rate-limiter.md).
• LLD_SOLUTIONS_DIR (e.g. ~/code/LLD) — holds two separate things: the reference corpus of your own designs, one self-contained .py per problem grouped into category folders (1_state_machine/vending_machine.py), plus flat design-parking-lot.md write-ups from save_practice_doc; and Mock Solutions/, the mock-interview loop where you attempt a problem and Claude grades it. See LLD mock interviews below.
• BEHAVIORAL_SOLUTIONS_DIR (e.g. ~/code/Behavioral) — holds a single candidate_context.md: your reusable background + STAR story bank, with a "Current Focus" section you refresh per company/role. See save_candidate_context below.

Tools exposed to Claude

Tool	When Claude uses it
get_progress_summary	Start of every session — session table, weak areas, competency scores, catalog coverage per type
get_catalog	Browse the full problem pool for DSA/HLD/LLD/Behavioral, filterable by topic/difficulty/status, to find a problem's exact id
suggest_next_problems	"What should I practice next?" — ranks due-for-revision and weak-area-matching problems above fresh new ones
add_custom_problem	Add a problem not in the built-in catalog (company-specific, from a mock interview, a real behavioral question you were asked, etc.)
log_session	End of every session, all types — appends to revision.md, updates weak areas and the per-problem tracker; optionally records per-competency scores (1-5) and improvement suggestions
save_practice_doc	HLD/LLD only — after a design discussion, writes its own markdown file for quick revision
get_practice_doc	Fetch one saved HLD/LLD doc in full, e.g. to revise a specific past solution
list_practice_docs	List all saved HLD/LLD docs (title, topic, last updated) as a revision menu
save_candidate_context	Behavioral only — persist your reusable candidate profile + STAR story bank as one markdown file, overwriting the previous version
get_candidate_context	Fetch the saved candidate context in full, e.g. at the start of a behavioral mock session
scan_dsa_directory	Read DSA_SOLUTIONS_DIR — folder/filename/problem-statement-snippet/last-modified for every .py file, flagging which are already tracked
import_solved_dsa_problem(s)	Backfill the tracker from an existing file on disk (matched to a catalog id) without touching the file — uses its mtime as "last practiced"
save_dsa_solution	After solving a NEW DSA problem — writes a .py file into the right topic folder in DSA_SOLUTIONS_DIR; refuses to overwrite an existing file unless told to
scan_lld_directory	Read LLD_SOLUTIONS_DIR — folder/filename/kind/snippet/last-modified for every file in the reference corpus, flagging which are already tracked. Only kind=solution rows are per-problem designs; Mock Solutions/ is excluded
read_lld_solution	Open ONE LLD file in full — a past design, a corpus doc, or a mock attempt you're about to grade
import_solved_lld_problem(s)	Backfill the tracker from an LLD design already on disk, without touching the file. Refuses anything that isn't kind=solution
save_lld_solution	Write a NEW design into the reference corpus, in the right category folder; refuses to overwrite unless told to
start_mock_attempt	Pose an LLD problem — creates Mock Solutions/<id>/ with problem.md and an attempt.py stub for you to fill in. Never overwrites an existing attempt; re-posing opens the next round
list_mock_attempts	Every mock problem and round: which files exist, what's still awaiting grading, scores and verdicts
save_mock_evaluation	Grade an attempt against the fixed 7-dimension rubric — writes evaluation.md, logs the session, and regenerates feedback.md
save_ideal_solution	Write the interviewer's reference design as ideal.py, beside your attempt. Can only ever write ideal*.py, so it cannot touch your own file
save_simple_solution	Write a pared-back version of that design as simple.py — what a strong candidate could realistically finish in the time box. Can only ever write simple*.py
get_lld_feedback	Rubric averages, weakest dimensions, and attempt history — call this beforesuggest_next_problems("LLD") to aim the next question
get_session_detail	Revisit the full log entry for one past session
resolve_weak_area	Remove a weak area once you've demonstrably improved at it

Setup (macOS)

1. Keep this folder wherever you cloned it, e.g. /Users/YOUR_USERNAME/code/file_mcp/. server.py and catalog.json must stay next to each other — the catalog is loaded relative to the script.

2. Install the MCP SDK (any Python ≥3.10):

   pip3 install mcp

   (If you use uv: uv pip install mcp, and adjust the command below to your venv's python.)

3. Open Claude Desktop → Settings → Developer → Edit Config. This opens ~/Library/Application Support/Claude/claude_desktop_config.json. Add:

   {
   "mcpServers": {
   "interview-memory": {
   "command": "python3",
   "args": ["/Users/YOUR_USERNAME/code/file_mcp/server.py"],
   "env": {
   "INTERVIEW_PREP_DIR": "/Users/YOUR_USERNAME/interview-prep",
   "DSA_SOLUTIONS_DIR": "/Users/YOUR_USERNAME/code/DSA_mock",
   "HLD_SOLUTIONS_DIR": "/Users/YOUR_USERNAME/code/HLD",
   "LLD_SOLUTIONS_DIR": "/Users/YOUR_USERNAME/code/LLD",
   "BEHAVIORAL_SOLUTIONS_DIR": "/Users/YOUR_USERNAME/code/Behavioral"
   }
   }
   }
   }

   Use absolute paths. If python3 on your PATH isn't the one with mcp installed, use the full path (check with which python3). Omit any of the four *_SOLUTIONS_DIR vars you don't need — each independently falls back to a folder under INTERVIEW_PREP_DIR.

4. Fully quit Claude Desktop (Cmd+Q) and reopen it. You should see the server's tools under the connectors/tools indicator in the chat input.

Note:~/code/HLD only ever receives what this server writes, so there's nothing to import there. ~/code/LLD is different — it already holds a real corpus of hand-written .py designs in category folders, so start with the first-time LLD import below. Older LLD work outside LLD_SOLUTIONS_DIR (e.g. ~/code/Practice LLD/chess/main.py) is not reachable by these tools; move it under ~/code/LLD if you want it tracked.

First-time DSA import

If DSA_SOLUTIONS_DIR already has solutions in it (like an existing Arrays_and_Hashing/, Graphs/, etc. layout), the tracker starts out blank until you import — the files existing on disk isn't the same as the MCP knowing about them. Ask Claude:

Scan my DSA directory and import everything you can confidently match to the catalog.

Claude will call scan_dsa_directory(), read each file's problem-statement snippet, match filenames like island.py → number-of-islands or top_k.py → top-k-frequent-elements using its own judgment (filenames rarely match catalog ids exactly), and call import_solved_dsa_problems in bulk. Anything it can't confidently match (scratch files, company-specific problems) it should flag for you to decide — add those via add_custom_problem first if you want them tracked. This step only reads files and writes to index.json; it never modifies anything under DSA_SOLUTIONS_DIR.

First-time LLD import

LLD_SOLUTIONS_DIR (~/code/LLD) already holds ~31 hand-written designs in numbered category folders, none of which the tracker knows about. Ask Claude:

Scan my LLD directory and import everything you can confidently match to the catalog.

scan_lld_directory() returns every file with a Kind column — solution (a per-problem design), category-doc (a folder README), aggregate-doc (INDEX.md, QUICK_REFERENCE.md and friends, which span many problems), practice-doc (a markdown write-up this server wrote via save_practice_doc), or other. Only solution rows are importable; import_solved_lld_problem(s) refuses the rest, so an index file can never get linked to a single problem. Claude matches filenames to catalog ids by judgment (8_lru_cache.py → design-lru-cache-oop), and roughly half the corpus isn't in the 25-entry built-in LLD catalog at all (order_lifecycle.py, whatsapp_messaging.py, audit_trail.py, …) — those need add_custom_problem first. Nothing under ~/code/LLD is modified; only index.json is written.

LLD mock interviews

The loop that turns practice into targeted practice. You write the design yourself; Claude grades it as the interviewer and remembers where you're weak.

~/code/LLD/Mock Solutions/
feedback.md # running scorecard, regenerated after each grading
design-parking-lot/
problem.md # the prompt, as Claude posed it
attempt.py # YOUR work — no tool in this server ever writes over it
evaluation.md # Claude's scored critique
ideal.py # Claude's reference design
simple.py # the same design pared back to interview scope

Re-attempting a problem later opens the next round (attempt_2.py, evaluation_2.md, ideal_2.py, simple_2.py), so you keep the earlier one to diff against.

The flow. Say:

Let's do an LLD mock interview.

1. Claude calls get_lld_feedback() and suggest_next_problems("LLD") to pick a problem aimed at your weakest dimensions, then start_mock_attempt(...) — which writes the prompt and an empty attempt.py.
2. You write your design in attempt.py, on your own. Say when you're done.
3. Claude calls read_lld_solution("Mock Solutions/design-parking-lot/attempt.py"), then save_mock_evaluation(...) with rubric scores and a written critique, then save_ideal_solution(...) and optionally save_simple_solution(...).
4. Read evaluation.md and diff attempt.py against ideal.py — and against simple.py for the version that actually fits the clock.

The rubric is a fixed seven-dimension vocabulary, scored 1-5. It's fixed on purpose: free-form labels would never aggregate, and the aggregate is exactly what makes later sessions pick different problems.

Dimension	What it measures
requirements-and-scope	Clarifying questions, scoping, stated assumptions
class-decomposition	Entity/responsibility split, cohesion
design-patterns	Pattern choice, and whether it was justified
solid-and-extensibility	SOLID, open/closed, how the design absorbs change
concurrency-and-edge-cases	Thread safety, races, boundary conditions
code-quality	Naming, structure, idiomatic Python
tradeoff-communication	Articulating and defending alternatives

Scores accumulate in index.json under lld:-prefixed keys (kept apart from Behavioral competency scores, which share that store), and surface in three places: feedback.md for you to read, get_lld_feedback() and get_progress_summary() for Claude, and a weakest-dimensions note appended to suggest_next_problems("LLD"). That last one matters — the generic weak-area ranking matches against catalog topics, and every LLD topic starts with "OOP Design", so without the rubric the feedback would never actually change what gets asked.

Safety.attempt.py is yours: start_mock_attempt refuses to overwrite one, save_ideal_solution can only ever write a file named ideal*.py, and save_simple_solution only simple*.py. Scans and imports exclude Mock Solutions/ entirely, so Claude's own output can never be backfilled into the tracker as your finished work.

Wiring it into your practice routine

Say this at the start of a chat (or bake it into a Claude Desktop project/skill):

At the start of every practice session, call get_progress_summary, then suggest_next_problems for the type we're practicing (DSA/HLD/LLD) and let me pick from the top few. For LLD also call get_lld_feedback first and aim the pick at my weakest rubric dimensions. After we solve/discuss it, call log_session (with problem_id set). Then for HLD/LLD call save_practice_doc with the full write-up (HLD: requirements, capacity estimate, architecture, API/data model, trade-offs; LLD: class design, patterns used, key decisions). For DSA, if the problem isn't already on disk, call save_dsa_solution with the final code and a short explanation.

If I say I want to attempt an LLD problem myself rather than discuss it, run the mock loop instead: start_mock_attempt, wait for me to write attempt.py, then read_lld_solution, save_mock_evaluation (score honestly — inflated scores break the feedback loop), save_ideal_solution, and save_simple_solution for the cut-down version.

Example flow (HLD):

1. "What should I practice today?" → Claude calls get_progress_summary, then suggest_next_problems("HLD"), and proposes 2-3 options (mixing anything due for revision with new ones matching your weak areas).
2. You work through the problem together.
3. Claude calls log_session(..., problem_id="design-rate-limiter") to record the verdict/gaps, then save_practice_doc("HLD", "Design a Rate Limiter", <full writeup>, problem_id="design-rate-limiter"), creating HLD_SOLUTIONS_DIR/design-rate-limiter.md.
4. Next time you ask to revise, list_practice_docs() shows everything documented so far, and get_practice_doc pulls up any specific one in full.

Example flow (DSA):

1. suggest_next_problems("DSA") → you pick "Course Schedule".
2. You solve it together.
3. log_session(..., problem_id="course-schedule"), then save_dsa_solution("course-schedule", "Course Schedule", "Graphs", <code>, explanation="topological sort via Kahn's algorithm") → creates DSA_SOLUTIONS_DIR/Graphs/course_schedule.py.

Example flow (Behavioral):

1. Before your first mock session, tell Claude about your background and stories; it calls save_candidate_context(...) to write BEHAVIORAL_SOLUTIONS_DIR/candidate_context.md (a "Core Profile & Story Bank" section, plus a "Current Focus" section for whichever company/role you're currently prepping for).
2. "Let's do a behavioral mock for CompanyX." → Claude calls get_candidate_context() to see your stories, then suggest_next_problems("Behavioral") and proposes a few questions (built-in catalog of 29 common questions across competencies like Leadership, Conflict & Disagreement, Ownership — see catalog.json), or you can just ask about a real question you were asked and it'll use add_custom_problem("Behavioral", ...) to track it.
3. You answer with a STAR story together.
4. Claude calls log_session(..., interview_type="Behavioral", problem_id=..., competency_scores={"leadership": 4, "communication": 3}, improvements="Add a concrete metric to the result step.") — this appends the verdict, scores, and improvement suggestions to revision.md, and updates the per-competency score averages shown in get_progress_summary.
5. Prepping for a different company next week? Call save_candidate_context(...) again with an updated "Current Focus" section — the Core Profile & Story Bank stays intact since you write the whole file each time.

Tuning revision timing

By default a problem is considered "due for revision" 21 days after its last attempt (or immediately, regardless of days, if it matches a currently flagged weak area). Change it via the INTERVIEW_PREP_STALE_DAYS env var in the Claude Desktop config's env block.

Adding more problems

catalog.json (next to server.py) is the shared, built-in catalog — feel free to hand-edit it, or just ask Claude to call add_custom_problem, which writes to custom_catalog.json inside your INTERVIEW_PREP_DIR instead (keeps your personal additions separate from the shipped list).

Testing / autostart

A stdio-transport MCP server (what this is) isn't a background daemon you start once and leave running — Claude Desktop spawns it fresh as a subprocess every time it needs it, using whatever command/args/env is in mcpServers.interview-memory in claude_desktop_config.json. So there's no separate "autostart" toggle: being registered in that config is autostart — Desktop manages the process lifecycle automatically from then on. That's already wired up (see Setup above); you just need to fully quit (Cmd+Q, not just close the window) and reopen Claude Desktop for it to pick up the config.

Four ways to check it's actually working, in increasing order of realism:

1. Does it even boot?python3 server.py from this folder — should start and hang silently (that's correct; it's waiting for a client on stdin). Ctrl+C to stop.
2. Does it speak MCP correctly?python3 test_server.py — spawns the server as a real MCP client would, does the protocol handshake, lists all 26 tools, and calls get_progress_summary for real. Read-only, safe to run anytime. A clean "All checks passed" means the server itself is solid, independent of Claude Desktop.
3. Do the LLD tools actually behave?python3 test_lld_tools.py — builds a synthetic design repo in a temp directory and exercises every LLD tool against it: path guards, kind classification, rubric validation, the full mock loop, and above all that attempt.py comes out byte-identical to what was written. Hermetic — it never touches ~/code/LLD or your real index.json.
4. Is Claude Desktop actually using it?
   • Open a chat and look at the tools/connectors icon near the input box — interview-memory should be listed with its tool count.
   • ps aux | grep server.py — while Desktop is open, you should see a live python3 .../server.py process (Desktop spawns it once you open a chat that uses it, or at startup depending on version).
   • Logs: ~/Library/Logs/Claude/mcp-server-interview-memory.log.
   • Interactive debugging (optional): mcp dev server.py launches the MCP Inspector, a local web UI where you can call any tool by hand and see raw responses — useful for poking at edge cases outside a real chat.

Security

This server only ever runs over stdio (mcp.run(transport="stdio")), the same as the original. Stdio means Claude Desktop spawns it as a local subprocess and talks to it over stdin/stdout pipes — it opens no network port, so there is nothing for another machine, process, or website to connect to. Don't change the transport to sse/http unless you also add authentication and bind to localhost; as shipped, "outside access" isn't a meaningful attack surface because there's no listener at all.

Within the local filesystem, a few guardrails are worth knowing about since Claude drives these tools somewhat autonomously:

• Path sanitization. Every value used to build a filename (problem_id, problem titles) is passed through a slugifier that strips everything except a-z 0-9 - before it ever touches a path. A value like ../../etc/passwd becomes etc-passwd, not a traversal — verified with an adversarial test during development.
• Directory containment.save_practice_doc can only write inside HLD_SOLUTIONS_DIR or LLD_SOLUTIONS_DIR (whichever matches the call); save_dsa_solution can only write inside DSA_SOLUTIONS_DIR; save_candidate_context/get_candidate_context are confined to BEHAVIORAL_SOLUTIONS_DIR; import_solved_dsa_problem(s) can only link to files that already live inside DSA_SOLUTIONS_DIR (it refuses anything outside it, e.g. ~/.ssh/, /etc/); get_practice_doc re-checks that whatever index.json points at is still inside the allowed directory for that problem type before reading it.
• No code execution. The server only reads and writes text files. It never execs, evals, or runs the DSA solutions it stores — code/content_markdown arguments are treated purely as bytes to persist.
• Overwrite protection.save_dsa_solution refuses to replace an existing file unless overwrite=True is passed explicitly, since DSA_SOLUTIONS_DIR is assumed to hold real, hand-written work. (save_practice_doc for HLD/LLD, and save_candidate_context for Behavioral, do overwrite by design — they hold Claude's latest write-up/profile, and those directories are managed entirely by this server.)
• Env-var-scoped roots.INTERVIEW_PREP_DIR, DSA_SOLUTIONS_DIR, HLD_SOLUTIONS_DIR, LLD_SOLUTIONS_DIR, and BEHAVIORAL_SOLUTIONS_DIR are only ever set by you, in your own Claude Desktop config — they aren't something a chat message can override.

Troubleshooting

• Server not appearing: check JSON syntax in the Claude Desktop config (one bad comma disables everything), confirm paths are absolute, then look at logs in ~/Library/Logs/Claude/mcp-server-interview-memory.log.
• Test the server manually: python3 server.py should start and wait silently (Ctrl+C to exit).
• ModuleNotFoundError: No module named 'mcp': run pip3 install mcp with the same python3 referenced in the config.
• save_dsa_solution refusing to write: it never overwrites an existing file without overwrite=True — this is deliberate, since DSA_SOLUTIONS_DIR is treated as containing real, hand-written solutions.