technical-interview-roadmap

What this skill does

# Technical Interview Roadmap

Generate a company-specific technical interview study plan from a JD URL or pasted job description. Extracts DSA-relevant signals directly from the JD, researches the company's engineering domain, consults the leetcode-teacher learner profile, and outputs a curated LeetCode problem list with phased study timeline. Output goes to `hojicha/<company>-<role>-resume/technical-roadmap.md`.

## Critical Rules

1. **Require JD input.** The user must provide a JD URL or paste JD text. The skill extracts its own DSA-focused signals directly from the JD — it does not depend on resume-builder output. If no JD is provided, prompt the user to provide a URL or paste the JD text.
2. **No paywalled sources.** Only use public engineering blogs, GitHub, official company pages, YouTube tech talks. Hard ban on Glassdoor, Blind, LeetCode Discuss company tags, or any paywalled content.
3. **Cite all research.** Every company engineering claim needs a source URL in the appendix. No unsourced assertions about tech stack or interview process.
4. **Align with leetcode-teacher taxonomy.** All pattern names, classifications, and difficulty labels must match `references/frameworks/problem-patterns.md` from the leetcode-teacher skill. Use the exact pattern names: Two Pointers, Sliding Window, Binary Search, Dynamic Programming, DFS/BFS, Backtracking, Greedy, Hash Table, Heap / Priority Queue, Union-Find.
5. **Read-only on learner profile.** Never modify `~/.local/share/claude/leetcode-teacher-profile.md`. Read it for calibration only.
6. **15-25 problems total.** The problem list must be actionable, not overwhelming. Quality over quantity.
7. **Every problem needs a "Why."** Connect each problem to the company domain, role requirements, or a learner weakness. No generic filler entries.
8. **Companies test what they build.** Interview questions are not chosen at random. Companies select problems that test the foundational concepts their engineers use daily. A payments company asks graph problems because fraud detection traverses transaction graphs. A trading firm asks DP because optimal execution is a dynamic programming problem. A search company asks trie/string problems because their core product is text retrieval. Always reason backward from "what does this company's engineering team actually build?" to "what concepts must their engineers be fluent in?" to "which problems test those concepts?" Every problem in the roadmap must trace back to the company's business, tech stack, or core engineering challenges — not just to generic pattern frequency.
9. **No system design content.** This roadmap covers DSA/coding problems only. Explicitly disclaim system design in the output.
10. **Difficulty is NEVER capped by role level.** Default to full Easy-Medium-Hard coverage for ALL roles. Companies pull from shared OA pools (HackerRank, Codility, CodeSignal) that are often not calibrated to role level — even "early career" roles at crypto/fintech/tech companies routinely test Hard-level concepts (confirmed: Crypto.com early career OA, 2026-02-28, included Hard-level 2D DP + Union-Find problems). If OA ground truth exists (user reports actual OA problems), that overrides all heuristics. Company competitiveness shifts the distribution (more Hard problems for competitive firms) but the floor for ALL companies must include at least 2-3 Hard problems. Role level is useful context for prioritization, not a difficulty ceiling — see Difficulty Calibration in Quick Reference.
11. **URL fetch tool priority.** When fetching a JD URL, use Exa `crawling_exa` as primary. Fall back to `WebFetch` if Exa is unavailable. If neither works, ask the user to paste the JD text directly.

---

## Workflow

### Step 1: Parse Inputs

The user provides a JD URL or pastes JD text. This is the only JD input — the skill does not read `notes.md` or any resume-builder output for JD analysis.

**If JD URL or pasted text is provided:** Proceed to Step 1b.

**If neither is provided:** Prompt the user to either:
1. Provide a JD URL
2. Paste the JD text directly

Also read these optional files if they exist:
```
Optional:
- ~/.local/share/claude/leetcode-teacher-profile.md (learner profile for calibration)
- hojicha/candidate-context.md (discovery interview context — technical background, project details)
```

### Step 1b: DSA-Focused JD Extraction

Runs every time — this is the core input processing step.

#### 1b.1: Fetch JD Content

- **If URL:** Use Exa `crawling_exa` (primary) or `WebFetch` (fallback) to retrieve the page content. Extract the job description text from the fetched content — strip navigation, footers, and unrelated page elements.
- **If pasted text:** Use directly.
- **If fetch fails:** Ask the user to paste the JD text instead.

#### 1b.2: Extract DSA-Relevant Signals

Parse the JD content for:

1. **Hard skills** — programming languages, frameworks, tools, platforms (e.g., Python, PyTorch, AWS, Kubernetes). These map to algorithm patterns in Step 2.
2. **Domain keywords** — industry and problem domain terms (e.g., recommendation systems, real-time ML, distributed computing). These map to problem types in Step 2.
3. **Role level** — infer junior/mid/senior from JD language using the same heuristics as Step 2 item 4 (years of experience, "lead", "architect", "entry-level", "associate").
4. **Company name and role title** — extract for output directory naming and company research (Step 3). If ambiguous, ask the user.

#### 1b.3: Pass Signals Forward

The extracted signals (hard skills, domain keywords, role level, company name, role title, raw JD text) are used directly by Step 2 and Step 8. No intermediate file is written.

### Step 2: Extract Technical Signals from JD

Use the Hard Skills and Domain Keywords extracted in Step 1b.2. If `hojicha/candidate-context.md` exists, also scan it for additional technical signals (languages, frameworks, project domains) that may inform pattern prioritization.

Focus on what JD keywords *imply for coding interviews*:

1. **Hard skills → DSA topics.** Map technical requirements to algorithm patterns using `references/jd-signal-mapping.md`. Example: "distributed systems" → Graph algorithms, BFS/DFS; "real-time processing" → Sliding Window, Heap.
2. **Domain keywords → problem types.** Extract domain-specific signals. Example: "recommendation engine" → Hash Table, Dynamic Programming; "trading systems" → Greedy, Binary Search.
3. **Role level detection.** Use the role level from Step 1b.2 for difficulty calibration.

### Step 3: Company Engineering Research

Use Exa MCP tools (`web_search_exa`, `crawling_exa`) as primary research tools. Fall back to `WebSearch`/`WebFetch` if Exa is unavailable.

**Query strategy (max 5 queries):**

1. `"<company> engineering blog"` — tech stack, problem domains, engineering culture
2. `"<company>" site:github.com` — languages, open-source projects, infrastructure choices
3. `"<company> tech stack"` — confirm and expand the technology picture
4. `"<company> <role> technical interview"` — public interview process information
5. Crawl top 2-3 engineering blog URLs from query 1 for deeper context

**Extract core engineering challenges (Critical Rule 8).** From the research, identify the 3-5 core engineering problems the company's team solves daily. Examples:
- Stripe → real-time payment routing, fraud graph traversal, idempotent transaction processing
- Spotify → recommendation ranking at scale, audio stream chunking, collaborative filtering
- Cloudflare → packet-level routing optimization, DDoS pattern detection, edge cache invalidation

These engineering challenges drive Step 5 topic prioritization and Step 6b problem selection. If research is thin, infer challenges from the company archetype and JD signals.

**Hard ban:** No Glassdoor, Blind, LeetCode Discuss company tags, or any paywalled source. If a search result comes from a banned source, skip it.

**Thin research fallback:** If fewer than 3 substanti