zhongwei/gh-dotclaude-marketplace-plugins-interview-assist
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-29 18:24:07 +08:00
commit 330645cc39
19 changed files with 4991 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

263
commands/behavioral.md Normal file
View File

@@ -0,0 +1,263 @@
---
model: claude-sonnet-4-0
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <question-topic> [--level=staff|principal] [--category=leadership|influence|conflict|ambiguity|failure|vision]
description: Prepare for behavioral and competency interview questions using STAR method
---
# Behavioral Interview Coach
Master the behavioral/competency interview with STAR method stories calibrated for Staff+ engineers. Focus on demonstrating technical judgment, leadership, and impact.
## Interview Structure (30-45 minutes)
### Opening (1 minute)
- Warm greeting
- "Tell me about yourself" (30-sec version, then pivot to questions)
### Behavioral Questions (25-30 minutes)
- Ask 3-5 targeted questions
- Listen for specificity and agency
- Follow up to understand your thinking
### Your Questions (5 minutes)
- Show genuine interest
- Ask about growth, culture, technical challenges
### Closing
- Thank you and next steps
## STAR Method Framework
**Situation** (15-20 seconds)
- Context: Where were you working?
- Challenge: What was the situation?
- Constraints: What made it hard?
**Task** (10 seconds)
- What needed to happen?
- What was your responsibility?
**Action** (60-90 seconds)
- What specifically did YOU do?
- Focus on your decisions and reasoning
- Include 2-3 specific steps or decisions
**Result** (20-30 seconds)
- What was the outcome?
- Use metrics/numbers when possible
- What did you learn?
**Total per story**: 2-3 minutes
## Staff vs Principal Calibration
### Staff Engineer Stories
**Show**:
- Technical depth in your domain
- Mentoring and multiplying through others
- Taking on bigger scope than expected
- Making architectural decisions
- Influencing people with expertise, not authority
**Narrative Focus**:
- "I became the expert in [domain]"
- "I helped the team level up by..."
- "I recognized [pattern], which became how we..."
- "I took on [stretch project] and learned..."
### Principal Engineer Stories
**Show**:
- Organizational impact and vision
- Shifting how the company thinks about problems
- Building capability that multiplies across the org
- Influence at executive levels
- Creating lasting change, not just fixing things
**Narrative Focus**:
- "I identified [organizational gap] and built [solution]"
- "I shifted how we think about [problem]"
- "I created [framework/pattern] that the org now uses"
- "This impacted [multiple teams/business metrics]"
## Question Categories & Preparation
### Leadership & Influence (Most Important for Staff+)
**"Tell me about a time you influenced a technical decision without direct authority"**
Staff approach:
```
Situation: Team was about to choose database that I thought would scale poorly
Task: Convince them to reconsider without having authority over decision
Action:
- Analyzed growth projections vs database scaling curves
- Created comparison showing where each option breaks
- Proposed low-risk: try with our data patterns first
- Presented as "here's the cost-benefit" not "you're wrong"
Result: Team switched. Prevented major rewrite later. Became go-to for architecture questions.
```
Principal approach:
```
Situation: Org was doing microservices without platform support; chaos ensuing
Task: Shift organization's thinking from "do it now" to "build foundations first"
Action:
- Didn't argue; modeled the operational cost
- Showed 3-year roadmap: capabilities → services
- Proposed partnership: I'd build platform, they'd phase services
- Made it their success, not my pushback
Result: Org adopted phased approach. Better outcome. I led platform team.
```
### Handling Ambiguity & Complexity
**"Tell me about a time you had incomplete information and had to decide"**
Challenge: Show you gather data before deciding, or decide quickly when you must
Include: How you frame the decision, how you commit despite uncertainty
### Mentorship & Growth
**"Tell me about someone you mentored and helped grow"**
For Staff: Show concrete growth (junior → mid) or helped someone transition areas
For Principal: Show broad impact (multiple people, org capability building)
### Conflict & Disagreement
**"Tell me about a conflict you resolved"**
Key insight: The best answer shows how you converted conflict into collaboration
Include: Listening to understand, finding shared goals, proposing together
### Failure & Learning
**"Tell me about something you'd do differently"**
Don't say: "I didn't really fail"
Do say: "I made assumption X that turned out wrong. Here's what I learned."
### Technical Vision
**"Describe your biggest technical contribution"**
For Staff: Deep expertise that became team/org standard
For Principal: Platform/capability that others build on
## Interview Red Flags
❌ **Vague answers**: "We did X" instead of "I did X"
❌ **No specific details**: "Everything went well" vs "This metric improved 40%"
❌ **Rambling stories**: "Let me back up... actually, before that..."
❌ **Defensive tone**: "I wasn't wrong, the other person was"
❌ **No learning**: "It worked great" with no reflection
❌ **Unrelated stories**: Story doesn't address the question
✓ **Specific examples**: "In Q3 2022, I..."
✓ **Your agency**: "I recognized... so I..."
✓ **Concrete outcomes**: "Reduced latency by 60%, improved reliability to 99.99%"
✓ **Clear learning**: "This taught me that..."
✓ **Focused narrative**: Answer in 2-3 minutes
## Building Your Story Bank
Create stories covering:
- [ ] Technical depth / expertise
- [ ] Influence without authority
- [ ] Mentoring / growth
- [ ] Conflict / disagreement
- [ ] Failure / learning
- [ ] Ambiguity / decision-making
- [ ] Innovation / new idea
- [ ] Scale / big project
Have 1-2 stories per category, flexible enough to adapt to questions.
## Adapting Stories to Questions
Same story, different angle:
**Your story**: "I designed a caching layer that improved latency 60%"
**If asked about technical depth**:
Focus: "The hard part was cache coherency patterns. We chose [approach] because..."
**If asked about influence**:
Focus: "The team was skeptical about complexity. Here's how I convinced them..."
**If asked about learning**:
Focus: "We made assumption X that failed at scale. So I redesigned around..."
## Interviewer's Perspective
**They're evaluating**:
1. Can you think clearly under pressure?
2. Do you have good judgment?
3. Are you easy to work with?
4. Do you take responsibility?
5. Are you growing?
6. Will you make our org better?
Your stories should show all of these.
## Talking Points for Interviews
When you're stuck:
- "Let me think for a moment..."
- "That's a great question—it reminds me of..."
- "I want to give you an honest answer rather than rush one"
When explaining your reasoning:
- "I recognized that [insight]"
- "So I proposed [approach]"
- "The result was [outcome], and the learning was [insight]"
When asked follow-up questions:
- "That's a great point. Actually, it's why I..."
- "I hadn't thought about it that way. It changed my perspective on..."
- "Yes, and what I learned from that was..."
## Execution Day Tips
**Before interview**:
- Review your story bank (don't memorize, internalize)
- Get good sleep
- Arrive 5 min early
**During interview**:
- Listen fully to question before answering
- Take 2 seconds to collect thoughts
- Tell story conversationally (not rehearsed sounding)
- Check for understanding: "Does that make sense?"
- Be specific: names, dates, metrics
**If you get stuck**:
- "Let me think about the best example..."
- "Want me to tell you about another time...?"
- Ask: "What part would you like to know more about?"
## After Interview
**How you did well**:
- They asked follow-up questions (means they were engaged)
- They smiled/nodded (means they believed you)
- They spent time on your story (means it resonated)
- They asked your questions back (means they're interested)
**Signs to improve**:
- They seemed disengaged
- They interrupted to move to next question
- You rambled (they redirected)
- You couldn't answer follow-ups
## The Ultimate Goal
Interviews aren't about being perfect. They're about showing:
- You think clearly
- You can communicate
- You take responsibility
- You're growing
- You'll make their team better
Your stories are the proof.

181
commands/coding.md Normal file
View File

@@ -0,0 +1,181 @@
---
model: claude-sonnet-4-0
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <problem-name> [--level=staff|principal] [--pattern=hash-map|sliding-window|etc] [--difficulty=easy|medium|hard]
description: Practice coding problems with brute-force to optimized solution evolution
---
# Coding Interview Coach
Guide through a coding problem with evolution from brute-force to optimized solution. Includes talking points, complexity analysis, and pattern recognition for Staff+ interviews.
## Problem Categories
### Classic Patterns
- **Hash Map**: Two Sum, Three Sum, Anagrams, Frequencies
- **Sliding Window**: Substrings, Subarrays with constraints, Max window
- **Two Pointers**: Palindromes, Containers, Merge operations
- **Heap/Priority Queue**: Top-K, K-way merge, Running median
- **Graph**: Connectivity, Paths, Cycles, Components
- **DP/Recursion**: Overlapping subproblems, Optimal substructure
- **Prefix/Suffix**: Range queries, Pre-computed information
- **Binary Search**: Sorted array operations, Search space reduction
### Difficulty Levels
- **Easy**: Straightforward application of one pattern
- **Medium**: Pattern recognition required, some optimization
- **Hard**: Multiple patterns, system-level thinking, novel combination
## Execution Framework
### Phase 1: Problem Clarification (2-3 minutes)
Ask clarifying questions:
- What are the constraints? (Array size, value ranges)
- Can there be duplicates?
- What's the return format?
- Are there special cases?
- Time/space requirements?
### Phase 2: Brute-Force Solution (5-10 minutes)
Start simple:
1. Outline the straightforward approach
2. Walk through on a concrete example
3. Write clean, understandable code
4. Analyze time/space complexity honestly
5. Verify it works on edge cases
**Critical Talking Points**:
- "This approach tries every possibility"
- "It's O(?) because [explanation]"
- "Why I'm starting here: it's correct, which matters most"
### Phase 3: Analysis & Insight (2-3 minutes)
Identify where brute-force struggles:
- What operation is repeated?
- What would speed up [operation]?
- What data structure has a useful side effect?
Example: "The brute-force searches for complements repeatedly. If we could look them up in O(1), the problem dissolves."
### Phase 4: Optimized Solution (5-10 minutes)
Introduce the optimization:
1. State the primitive and its side effect
2. Explain how we compose it with our approach
3. Code the optimization
4. Walk through on example
5. Analyze new complexity
**Critical Talking Points**:
- "This primitive has [side effect] that dissolves the problem"
- "Instead of [old operation], we now [new operation]"
- "Complexity improves to O(?) because [reasoning]"
### Phase 5: Trade-Off Discussion (2-3 minutes)
Articulate the trade-off:
- What space do we use?
- When is this trade-off worth it?
- Alternative approaches for different constraints?
- How would this scale to [larger problem]?
### Phase 6: Pattern Recognition (1-2 minutes)
Connect to broader pattern family:
- "This pattern solves problems like: [family]"
- "The key insight applies to: [variations]"
- "You'd use this when: [scenario]"
## Interview-Ready Presentation
When presenting a solution, follow this structure:
```
1. Problem Restatement (30 sec)
"So we're finding X in Y with constraint Z"
2. Brute-Force Overview (1 min)
"My first approach: [simple strategy]"
"Time/Space: O(?)/O(?)"
"Why start here: it's correct"
3. The Optimization (2 min)
"[Problem observation]"
"[Primitive solution]"
"[Why this works]"
"New complexity: O(?)/O(?)"
4. Code Walk-Through (2-3 min)
"Looking at the code..."
"[Explain key parts]"
5. Verification (1 min)
"On this example: [walk through]"
"Edge cases: [how it handles]"
6. Talking Points (1 min)
"The key insight is..."
"This applies to..."
```
Total: 8-12 minutes for medium problem = Interview realistic
## Complexity Cheat Sheet
### Time Complexity (Common)
- O(1): Hash lookup, Array access
- O(log n): Binary search, Tree height
- O(n): Single pass through array
- O(n log n): Sorting, Search + sort
- O(n²): Nested loops
- O(2ⁿ): Brute-force with choices
- O(n!): Permutations
### Space Complexity (Common)
- O(1): Constant extra space
- O(log n): Recursion depth
- O(n): Hash map, extra array
- O(n²): Nested data structures
## When Stuck
**If unclear on problem**: Ask 3 clarifying questions
**If unsure on approach**: Walk through brute-force first (always valid)
**If code not working**: Trace through your example step-by-step
**If code correct but slow**: Look for the repeated operation
**If time running out**: Explain what you'd do next
## Example: Two Sum
```
Problem: Find two indices where array[i] + array[j] == target
Brute-Force:
- Try every pair with nested loop
- O(n²) time, O(1) space
- Talks point: "We check every combination"
Insight:
- For each number, we need to find its complement
- Hash map gives us O(1) lookup
Optimized:
- Single pass: check if complement exists, then add number
- O(n) time, O(n) space
- Talking point: "Hash lookup dissolves the 'find complement' problem"
Trade-off:
- Space: using O(n) extra space
- Worth it: O(n²) → O(n) is massive improvement
- When to choose differently: if space is extremely constrained
```
## Success Criteria
You're interview-ready when you can:
- ✓ Explain your thinking out loud clearly
- ✓ Identify the brute-force without optimization obsession
- ✓ Spot the optimization opportunity
- ✓ Articulate why the optimization works
- ✓ Code it cleanly
- ✓ Discuss trade-offs intelligently
- ✓ Apply patterns to novel problems
This command helps you practice the entire flow until it becomes natural.

266
commands/leadership.md Normal file
View File

@@ -0,0 +1,266 @@
---
model: claude-opus-4-1
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <scenario-type> [--level=staff|principal] [--context=situation|analysis|response]
description: Master Staff+ and Principal leadership scenarios for senior interviews
---
# Leadership Scenarios Coach
Master the unique interview challenges at Staff+ and Principal levels. These aren't IC technical contributions—they're about strategic influence, organizational thinking, and transformational impact.
## Scenario Types
### Type 1: Influence Without Direct Authority
**The Situation**: You see something critical that needs to happen, but you have no authority to mandate it.
**Staff+ Example**:
```
Scenario: Team is about to choose a database that won't scale to anticipated size
Challenge: You don't manage them; they trust different people
Approach:
1. Get the data (growth forecasts, scaling curves)
2. Make it clear, not preachy ("Here's what happens at 10x")
3. Propose low-risk path ("Let's test on our data patterns first")
4. Make them the decision-maker (not you imposing)
Response: "I'd present the analysis, propose a test, and let them decide"
Impact: Decision changes before hitting the scaling wall
```
**Principal Example**:
```
Scenario: Org pursuing microservices without ops/platform readiness
Challenge: Leadership committed to this direction
Approach:
1. Understand their motivations (why do they want this?)
2. Acknowledge the benefits (don't dismiss)
3. Show the operational cost (with numbers)
4. Propose staged approach (first: build platforms that enable services)
5. Offer to lead platform development
Response: "Rather than say no, I'd say here's when we're ready, and here's what we need first"
Impact: Organization de-risks while moving forward; I lead platform capability
```
### Type 2: Difficult People / Conflict Resolution
**The Situation**: You disagree with a peer on something important, and they have political influence.
**Staff+ Approach**:
```
Situation: Backend engineer wants tech choice that frontend can't support
Challenge: Both have valid reasons; political factors at play
Approach:
1. Separate person from problem ("We both want shipping to work")
2. Understand their actual concern (not dismiss their reasoning)
3. Find what each is optimizing for
4. Reframe to shared problem ("How do we get both benefits?")
5. Propose solution that respects both concerns
Result: Path forward feels like collaboration, not compromise
```
**Principal Approach**:
```
Situation: Two teams in conflict over architectural boundaries
Challenge: Both partly right; conflict is costing organization coherence
Approach:
1. Get curious, not defensive ("Why do you feel strongly about this?")
2. Identify the real issue (usually different goals, not stupidity)
3. Reframe at organizational level (not team level)
4. Propose structural solution (clear ownership, decision rights)
5. Make resolution about org clarity, not person vindication
Result: Problem solved at system level; both teams better off
```
### Type 3: Scaling Yourself / Multiplication
**The Situation**: Too much work for one person; need to multiply impact through others.
**Staff+ Example**:
```
Situation: You're the only one who understands critical systems
Challenge: You're bottleneck; that's not sustainable
Approach:
1. Extract the knowledge (what's your mental model?)
2. Document patterns (frameworks others can follow)
3. Mentor someone specific (not just documentation)
4. Step back and let them lead
5. Move to next leverage point
Impact: Expertise became team capability; you're available for new work
```
**Principal Example**:
```
Situation: Org wide capability gap (e.g., performance, security, reliability)
Challenge: This isn't one team's problem; it's org architectural
Approach:
1. Identify the gap at org level
2. Build the platform/capability that enables others
3. Teach how to use it (change how decisions are made)
4. Create governance that propagates the pattern
5. Measure org-level improvement
Impact: Organization's capability increased; you changed how they think
```
### Type 4: Navigating Broken Processes
**The Situation**: You see a process that's creating problems; fixing it requires changing how people work.
**Staff+ Example**:
```
Situation: Deployment process is slow, people are frustrated
Challenge: Process is organizational, not just technical
Approach:
1. Document the cost (time, frustration, broken deployments)
2. Propose a better process (easy to try, easy to revert)
3. Make it better for participants ("Your job becomes easier")
4. Help others adopt it
5. Celebrate early wins
Impact: Process improved, team happier, velocity increased
```
**Principal Example**:
```
Situation: Entire org's decision-making process creates bottlenecks
Challenge: This is cultural; affects strategy
Approach:
1. Make the cost visible (opportunity cost, culture impact)
2. Design new process (with stakeholders, not imposed)
3. Make the case (how does this enable our goals?)
4. Lead the transition carefully
5. Measure business impact
Impact: Org moves faster; decision quality actually improves
```
### Type 5: Technical Vision & Strategy
**The Situation**: You see 3-5 years forward; current path is suboptimal.
**Staff+ Example**:
```
Situation: Tech debt accumulating, will become problem in 2 years
Challenge: Business wants features, not refactoring
Approach:
1. Align with business goals ("Tech debt blocks the features you want")
2. Propose incremental path (can do both)
3. Build credibility through delivering
4. Gradually shift thinking
Result: Team now thinks about debt as business problem
```
**Principal Example**:
```
Situation: Org architecture will limit growth in 2-3 years
Challenge: Business doing fine now; no urgency
Approach:
1. Create leading indicators (what would suggest this matters?)
2. Build the team to start architectural work
3. Show early wins (component that's more efficient)
4. Position architecture as competitive advantage
Result: Org starts architectural transition early; executes better
```
## Interview Framework
### What They're Evaluating
**Staff+**:
- Do you see problems others miss?
- Can you move things without authority?
- Can you multiply your impact?
- Will you make the organization better?
**Principal**:
- Do you think strategically (3-5 year horizon)?
- Can you shift organizational thinking?
- Do you create lasting change vs short-term fixes?
- Are you comfortable with ambiguity and complexity?
### Answer Structure
1. **Problem Recognition** (15 sec)
- What did you notice?
- Why did others miss it?
2. **Approach** (60-90 sec)
- How did you think about it?
- Specific steps you took
- How you involved others
3. **Results & Impact** (30 sec)
- What changed?
- How do you measure it?
4. **Reflection** (20 sec)
- What did you learn?
- How does this apply to this role?
### Key Phrases
**When explaining your approach**:
- "Rather than [surface approach], I thought [deeper approach]"
- "I recognized [pattern/gap] that others hadn't seen yet"
- "I made it safe for people to [desired behavior]"
- "This shifted from [old way] to [new way]"
**When discussing impact**:
- "The organization went from [state] to [state]"
- "It changed how [team/org] thinks about [topic]"
- "Created lasting [capability/pattern] that still applies"
- "Multiple teams now use [framework/approach]"
**When asked difficult follow-up**:
- "That's a great point. Here's why I made that trade-off..."
- "I think about it differently now because of [learning]"
- "If I did it again, I would [improvement]"
## Red Flags (What NOT to do)
❌ "I just told them to..." → Shows authority thinking
✓ "I helped them see..." → Shows influence thinking
❌ "The team wasn't smart enough to..." → Blames others
✓ "The team wasn't equipped to see..." → Shows empathy
❌ "I fixed it myself" → Not multiplying
✓ "I built capability" → Multiplying impact
❌ "Nobody listened" → Victim narrative
✓ "I changed my approach" → Leadership narrative
❌ "This was obvious" → Dismissive
✓ "This became obvious once we..." → Collaborative
## Preparing Your Scenarios
Build 4-5 stories covering:
- [ ] Influencing without authority
- [ ] Handling conflict/disagreement
- [ ] Multiplying through others
- [ ] Navigating broken org dynamics
- [ ] Strategic/visionary thinking
Practice telling them in 2-3 minutes with focus on your thinking.
## The Core Question Behind All These
Interviewer is really asking:
**"Will you make this organization better at the leadership level?"**
Not: Are you smart enough? (Assumed)
Not: Can you code? (Assumed)
But: Can you see what needs to happen and make it happen?
Your stories should prove you can.
## Success Indicators
You did well if:
- ✓ They asked follow-up questions (means they're engaged)
- ✓ They challenged your thinking (means you passed baseline)
- ✓ They leaned forward (means they're interested)
- ✓ They took notes (means it stood out)
- ✓ They discussed their org challenges (means they're thinking about your fit)
These are leadership interviews. Show you think and act like a leader.

380
commands/mock.md Normal file
View File

@@ -0,0 +1,380 @@
---
model: claude-opus-4-1
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <interview-type> [--level=staff|principal] [--company-type=faang|startup|enterprise] [--difficulty=medium|hard|very-hard] [--mode=lightweight|standard|comprehensive]
description: Run realistic mock interviews with adaptive questioning and detailed performance feedback
---
# Mock Interview Simulator
Run realistic interview simulations with adaptive questioning, real-time feedback, and comprehensive performance scoring. Test your readiness before the real thing.
## Interview Types Available
### 1. Coding Interview (45 minutes)
- Problem introduction and clarification
- Solution development with live feedback
- Complexity analysis and optimization
- Edge cases and variations
- Real-time feedback and scoring
### 2. System Design Interview (60 minutes)
- Requirements clarification
- High-level architecture design
- Component deep-dives
- Scale and trade-off analysis
- Real-time feedback and scoring
### 3. Behavioral Interview (30-45 minutes)
- STAR-method question responses
- Follow-up probing questions
- Alignment to role assessment
- Communication clarity feedback
- Real-time feedback and scoring
### 4. Full Interview Loop (2-3 hours)
- Coding interview + feedback
- System design interview + feedback
- Behavioral interview + feedback
- Final questions + comprehensive debrief
### 5. Quick Lightning Round (15 minutes)
- Single problem or question
- Rapid feedback
- Quick confidence check
## How the Mock Works
### Setup Phase
1. Tell me the interview type and difficulty level
2. I'll confirm the format and time
3. We'll agree on ground rules (thinking time, interruptions, etc.)
### During Interview
- I'll ask questions like a real interviewer
- I'll interrupt if unclear (real interviewers do)
- I'll push back on decisions (testing your confidence)
- I'll ask follow-ups based on your responses (adaptive)
- I'll note timing and pacing
### Feedback Phase
- Immediate feedback on performance
- Scoring on key dimensions
- What went well (be specific)
- What to improve (be actionable)
- Likelihood of moving forward at this company/level
## Coding Interview Flow
### Phase 1: Problem Introduction (2 min)
- I present the problem
- Listen for your clarifying questions
- Watch if you ask the right questions upfront
### Phase 2: Approach (3 min)
- You outline your high-level approach
- I might challenge: "What if [variation]?"
- I'm checking your thinking process
### Phase 3: Implementation (20 min)
- You code while thinking out loud
- I'll interrupt if unclear
- I'll ask for complexity analysis as you go
- I'm checking: clarity, correctness, pace
### Phase 4: Optimization (10 min)
- I ask: "Can you optimize?"
- You identify bottleneck and improve
- We discuss trade-offs
- I'm checking: depth, flexibility, knowledge of patterns
### Phase 5: Variations & Edge Cases (8 min)
- I present similar problems
- You apply your pattern
- I test your understanding
- I'm checking: pattern recognition, transfer
### Feedback Scoring
**Problem Understanding** (1-5 stars)
- Did you clarify requirements?
- Did you identify edge cases?
- Did you understand constraints?
**Solution Approach** (1-5 stars)
- Is your strategy sound?
- Is it optimal or close?
- Did you consider trade-offs?
**Code Quality** (1-5 stars)
- Does it compile and run?
- Is it clean and readable?
- Does it handle edge cases?
**Communication** (1-5 stars)
- Could I follow your thinking?
- Did you explain your approach?
- Did you think out loud?
**Overall Score**:
- **4.5-5**: Strong hire (likely to move forward)
- **4.0-4.5**: Solid, competitive
- **3.5-4.0**: Needs some improvements
- **3.0-3.5**: Below bar for this company
- **<3.0**: Not ready yet
## System Design Interview Flow
### Phase 1: Requirements (5 min)
- I present the system design problem
- You ask clarifying questions
- I'm checking: Do you ask the right questions?
- I'm watching: Do you clarify before designing?
### Phase 2: High-Level Design (10 min)
- You outline components and flow
- I probe: "How do these interact?"
- I might challenge: "What about [concern]?"
- I'm checking: Architectural thinking
### Phase 3: Component Deep-Dive (20 min)
- You pick a critical component
- I ask: "How would you...?"
- I press on: "What about [edge case]?"
- I'm checking: Technical depth, decision-making
### Phase 4: Scale & Trade-Offs (15 min)
- I ask: "How does this scale to 10x?"
- I challenge: "Why that choice over [alternative]?"
- I probe consistency/availability trade-offs
- I'm checking: Senior-level thinking
### Phase 5: Extensions (8 min)
- I ask: "How would you add [new requirement]?"
- Or: "What's your biggest concern?"
- You address follow-up or raise concerns
- I'm checking: Holistic thinking
### Design Interview Scoring
**Requirements Understanding** (1-5 stars)
- Did you ask good questions?
- Do you understand the problem?
- Did you identify constraints?
**Architecture Quality** (1-5 stars)
- Is the design sound?
- Does it handle the requirements?
- Is it elegant or over-engineered?
**Technical Depth** (1-5 stars)
- Can you explain components?
- Do you know the details?
- Can you justify decisions?
**Trade-Off Analysis** (1-5 stars)
- Do you discuss trade-offs?
- Are they well-reasoned?
- Do you understand implications?
**Communication** (1-5 stars)
- Clear explanation?
- Good diagrams?
- Easy to follow?
**Overall Score**: Same as coding (4.5+ is strong hire)
## Behavioral Interview Flow
### Phase 1: Opening (1 min)
- Warm introduction
- "Tell me about yourself" (30-sec version)
### Phase 2: Behavioral Questions (20-25 min)
- I ask 3-4 targeted questions
- I listen for STAR structure
- I ask follow-ups to probe deeper
- I'm checking: Specificity, agency, learning
### Phase 3: Your Questions (5 min)
- You ask questions about the role/company
- I'm checking: Genuine interest? Thoughtful?
### Phase 4: Closing (1 min)
- "Do you have any final thoughts?"
- Thank you and next steps
### Behavioral Interview Scoring
**Story Structure** (1-5 stars)
- Is it STAR format?
- Does it flow?
- Is it concise?
**Specificity** (1-5 stars)
- Specific details (names, dates)?
- Concrete examples?
- Or vague generalities?
**Agency** (1-5 stars)
- Do YOU show impact?
- Or is it "we did"?
- Clear your role?
**Relevance** (1-5 stars)
- Does it match the question?
- Does it match the role?
- Or off-topic?
**Communication** (1-5 stars)
- Natural delivery?
- Confident?
- Good pacing?
**Overall Score**: Same scale, 4.5+ is strong
## Full Interview Loop
Run all three in sequence with debrief between each:
1. **Coding interview** (45 min) → feedback (5 min)
2. **System design** (60 min) → feedback (5 min)
3. **Behavioral** (30 min) → feedback (5 min)
4. **Final questions** (5 min)
5. **Comprehensive debrief** (10 min)
**Total time**: 2.5-3 hours (like a real interview day)
**Debrief includes**:
- Overall scoring across all three
- What was your strongest area?
- What needs work?
- How would each company/level view this?
- What's your action plan?
## Quick Lightning Round
For rapid practice / confidence checks:
- Single coding problem (15 min)
- Single behavioral question (10 min)
- Single system design component (15 min)
**Use when**: You want to practice one area or quick check-in
## Adaptive Questioning
### In Coding Interviews
- **If you're struggling**: Easier problems, more hints
- **If you're excelling**: Harder optimizations, variations
- **If you're slow**: "Let's assume you solve this, what's next?"
- **If you're unsure**: "What would you need to proceed?"
### In System Design
- **If lacking clarity**: More prompts on requirements
- **If missing depth**: "Tell me more about [component]"
- **If great design**: "How would you handle failures?"
- **If running long**: "What's most important to dive on?"
### In Behavioral
- **If too vague**: "Tell me more specifically..."
- **If wandering**: "That's interesting, back to [question]..."
- **If great answer**: "Any other examples?"
- **If missing agency**: "What specifically did YOU do?"
## Real-World Adjustments
### I'll Simulate Real Interview Conditions
**Mild interruptions**:
- "Wait, why did you...?"
- "I want to understand..."
**Real-time reactions**:
- Nod when understanding
- Frown when confused
- Take notes (creates pressure)
**Time pressure**:
- "We're running low on time..."
- "Let's wrap up this part..."
**Genuine pushback**:
- "Are you sure about that?"
- "What if...?"
- "How do you know?"
## After Each Mock Interview
### Immediate Feedback (3-5 min)
- What you did well (specific)
- What to improve (actionable)
- Your score with context
- Likely interview outcome
### Comprehensive Debrief (for full loop)
- Overall scoring summary
- Strengths and weaknesses
- How you compare to bar
- Specific action items
- Timeline to next mock
## Setting Up Your Mock
### Best Practices
- [ ] Quiet space (no interruptions)
- [ ] Good internet connection
- [ ] Have paper/whiteboard ready
- [ ] Camera on (eye contact practice)
- [ ] Professional setting (or at least clean background)
- [ ] Think like it's real (pressure helps practice)
### During Mock
- Take your time thinking (silence is OK)
- Ask clarifying questions
- Think out loud
- Show your work
- Handle interruptions professionally
### After Mock
- Don't get defensive on feedback
- Take specific actions on suggestions
- Schedule another mock to practice improvements
- Track improvement over multiple mocks
## Success Indicators
You're interview-ready when:
- ✓ Consistent 4.0+ scores across all three
- ✓ Can handle harder difficulty levels
- ✓ Communicate clearly under pressure
- ✓ Ask good clarifying questions
- ✓ Recover well from mistakes
- ✓ Show genuine interest and learning
- ✓ Can do this in multiple rounds without exhaustion
## Types of Companies/Difficulty
### Company Types
- FAANG (Google, Meta, Amazon, Apple, Netflix)
- High-Growth Startup (Series C/D/E)
- Enterprise (Microsoft, Adobe, IBM)
- Early-Stage Startup (Seed/Series A/B)
### Difficulty Levels
- **Medium**: Early-career to mid-level
- **Hard**: Mid-level to Staff engineer
- **Very Hard**: Staff/Principal level
### Level Settings
- **Staff Engineer**: Hard difficulty, senior questions
- **Principal**: Very Hard, strategic/vision questions
---
**Ready for a realistic interview?** Tell me:
- What type of interview? (coding / system-design / behavioral / full loop / lightning)
- What level? (staff / principal / other)
- What difficulty? (medium / hard / very-hard)
- How much time? (15 min / 45 min / 60 min / 2+ hours)
Let's go!

256
commands/side-effects.md Normal file
View File

@@ -0,0 +1,256 @@
---
model: claude-sonnet-4-0
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <problem-or-system> [--depth=basic|detailed|deep] [--focus=coding|system-design|both]
description: Master side-effect decomposition for interview problem-solving
---
# Side-Effects Engineering Interview Coach
Learn to dissolve problems by recognizing primitive side effects and composing them for emergent properties. Based on the philosophy: instead of solving problems, design substrates where problems can't exist.
## Core Framework
### The Dissolution Approach vs Traditional Solving
**Traditional**: Problem → Design Solution → Implement → New Problems → Patch → Accumulate Complexity
**Side-Effects**: Problem → Identify Emergent Properties → Catalog Side Effects → Compose Primitives → Problem Dissolves
## Methodology
### Step 1: Reframe the Problem
Instead of: "How do I solve X?"
Ask: "What substrate makes X impossible to express?"
**Examples**:
- **Two Sum**: "What if finding complements were instant?" → Hash table
- **URL Shortener**: "What if collisions were impossible (not handled)?" → Monotonic counter per shard
- **Event Ordering**: "What if message ordering was guaranteed by design?" → Partitioned queue
- **Cache Invalidation**: "What if staleness wasn't a problem?" → TTL + eventual consistency
### Step 2: Identify Side Effects
Every primitive has consequences that make operations trivial:
**Hash Table**:
- Side effect: O(1) lookup
- Side effect: Duplicate detection automatic
- Side effect: Historical tracking free
- Dissolves: Search problems, frequency counting
**Sorted Array + Two Pointers**:
- Side effect: Monotonicity
- Side effect: Bi-directional logic
- Dissolves: Palindrome, container, range problems
**Heap**:
- Side effect: Instant min/max
- Side effect: Lazy evaluation
- Dissolves: Top-K, k-way merge, priority-based operations
**Queue with Partitioning**:
- Side effect: FIFO guarantee per partition
- Side effect: Ordering by key
- Dissolves: Ordering problems, distributed ordering
### Step 3: Compose for Emergence
Select primitives whose side effects combine to produce the property you want.
**Example: URL Shortener**
**Property 1: Collisions impossible**
- Primitive: Counter per shard
- Side effect: Monotonic IDs = inherently unique
- Result: Collision question is meaningless
**Property 2: Scaling without coordination**
- Primitive: Consistent hashing
- Side effect: Automatic shard routing
- Result: Horizontal scaling is free
**Property 3: Analytics automatic**
- Primitive: Write-Ahead Log
- Side effect: Creates event stream
- Result: Analytics consume stream (not added separately)
### Step 4: Verify Dissolution
The problem can't exist in the new substrate.
**Check**: Can you ask the old question?
- "How do we handle collisions?" → Meaningless (can't happen)
- "How do we scale?" → Already solved by design
- "How do we collect analytics?" → It emerges automatically
## Primitive Catalog
### Data Structure Primitives
**Hash Map/Dictionary**
- Side effects: O(1) lookup, duplicate detection, historical tracking
- Dissolves: Search families, frequency, grouping
- Interview: "Instant lookup makes the problem trivial"
**Sorted Array + Two Pointers**
- Side effects: Monotonicity, bi-directional logic
- Dissolves: Palindrome, container, range problems
- Interview: "Sorting exploits monotonicity; pointers eliminate search"
**Heap/Priority Queue**
- Side effects: Instant min/max, lazy evaluation
- Dissolves: Top-K, merge, scheduling
- Interview: "We always know what matters next"
**Prefix/Suffix Arrays**
- Side effects: Pre-computed info, O(1) queries
- Dissolves: Range queries
- Interview: "Pre-computation trades space for constant time"
### Algorithmic Primitives
**Divide and Conquer**
- Side effects: Problem decomposition, recursive structure
- Dissolves: Tree problems, merge problems
- Interview: "The problem is already decomposed"
**Binary Search**
- Side effects: Logarithmic search space reduction
- Dissolves: Search in sorted data
- Interview: "Monotonicity gives us O(log n) locations"
**Dynamic Programming**
- Side effects: Caching subproblems, optimal substructure
- Dissolves: Exponential → polynomial complexity
- Interview: "Memoization eliminates redundant computation"
### System Design Primitives
**Counter per Shard**
- Side effects: Monotonic uniqueness, no coordination
- Dissolves: Collision handling, distributed ID generation
- Interview: "Monotonic IDs are inherently unique"
**Consistent Hashing**
- Side effects: Automatic routing, minimal rebalancing
- Dissolves: Manual sharding logic
- Interview: "Hashing gives us automatic distribution"
**Partition by Key**
- Side effects: FIFO guarantee, ordering preservation
- Dissolves: Distributed ordering problems
- Interview: "Partitioning enforces ordering by design"
**Write-Ahead Log**
- Side effects: Creates event stream, enables replication
- Dissolves: Separate analytics pipeline
- Interview: "The log is the single source of truth"
**Caching Layer**
- Side effects: Instant access for cached data
- Dissolves: Database bottleneck for hot data
- Interview: "Cache misses become the only database queries"
## Interview Application
### For Coding Problems
**Flow**:
1. Identify the brute-force bottleneck
2. Ask: "What operation is repeated?"
3. Ask: "Which primitive's side effect makes this operation free?"
4. Compose and explain
**Example: Two Sum**
- Bottleneck: Finding each number's complement
- Side effect needed: O(1) lookup
- Primitive: Hash map
- Composition: Single pass, check then add
- Result: "Hash lookup dissolves the search problem"
### For System Design Problems
**Flow**:
1. Identify desired emergent properties
2. Ask: "What would make this requirement trivial?"
3. Catalog primitives with those side effects
4. Compose the architecture
5. Verify the problem dissolves
**Example: Design Notification System**
- Property 1: Scalable message ingestion
- Primitive: Message queue (side effect: buffering + ordering)
- Property 2: Reliable delivery
- Primitive: Persistent queue + acknowledgment (side effect: guaranteed delivery)
- Property 3: Low latency notifications
- Primitive: Publish-subscribe (side effect: fan-out from one message)
- Result: Architecture emerges from side effect composition
## Talking Points for Interviews
### When explaining your approach:
- *"Rather than handle [problem], I'd design for [property] impossible to express it"*
- *"This primitive has a side effect: [consequence]. That dissolves the [problem]"*
- *"Composing [primitive A] with [primitive B] gives us [emergent property]"*
- *"The substrate makes this question meaningless"*
### When defending a decision:
- *"We don't need special logic for [case] because the design prevents it"*
- *"This scales because [side effect] makes [concern] automatic"*
- *"The property isn't added—it emerges from the composition"*
### When addressing trade-offs:
- *"We're using [space] to gain [side effect], which dissolves [problem]"*
- *"The trade-off is worth it because we convert exponential to linear"*
- *"Without this primitive, we'd need custom logic for [multiple cases]"*
## Practice Problems
### Beginner Level
1. **Two Sum**: What side effect dissolves the complement problem?
2. **Anagrams**: What side effect detects frequency matching?
3. **Palindrome**: What side effect exploits string structure?
### Intermediate Level
1. **LRU Cache**: What compositions give us LRU behavior for free?
2. **K-Way Merge**: What side effect gives instant next element?
3. **Sliding Window**: What side effect maintains window constraints?
### Advanced Level
1. **Design a URL Shortener**: What substrate prevents collisions?
2. **Design a Distributed Lock**: What primitives give us atomic operations?
3. **Design Event Sourcing**: What side effects does WAL enable?
## Key Distinction: Solve vs Dissolve
**Solving**:
- Problem: "How do we prevent X?"
- Solution: "Add logic to detect and handle X"
- Cost: Complexity accumulates with each edge case
**Dissolving**:
- Problem: "How do we make X impossible?"
- Solution: "Choose primitives where X can't exist"
- Benefit: Problem space shrinks; complexity decreases
**Interview Example**:
❌ **Solving Approach**:
"We prevent cache consistency problems by: invalidating on write, using TTLs, checking staleness..."
✓ **Dissolving Approach**:
"We don't prevent consistency problems—we choose eventual consistency. The substrate is: cache with TTL. Within the TTL, it's correct. After TTL, it refreshes. Consistency problems dissolve."
## Success Indicators
You understand side-effects engineering when you:
- ✓ See problems and ask "what substrate dissolves this?"
- ✓ Know primitives deeply (not just API, but side effects)
- ✓ Recognize composition opportunities
- ✓ Explain solutions via emergent properties
- ✓ Identify impossible-to-express problems in your substrate
- ✓ Can apply this thinking to novel problems
This approach separates engineers who memorize solutions from engineers who dissolve problem spaces.

342
commands/strategy.md Normal file
View File

@@ -0,0 +1,342 @@
---
model: claude-sonnet-4-0
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <company-name-or-type> <role-title> [--research-depth=surface|comprehensive] [--focus=company|role|alignment|preparation-plan]
description: Develop interview strategy for specific companies and roles
---
# Interview Strategy & Preparation Coach
Develop a tailored strategy for your specific company and role. Understand what they're looking for, predict likely questions, and create a preparation plan.
## Company Type Analysis
### FAANG Scale (Google, Meta, Amazon, Apple, Netflix)
**Interview Characteristics**:
- **Coding**: Hard algorithmic problems (LeetCode hard)
- **System Design**: Scale of millions/billions of users
- **Bar**: Very high; they're selective
- **Process**: Multiple rounds (4-6 hours total)
**Preparation Focus**:
- Master algorithms (this is their baseline)
- Practice hard problems daily
- Design for massive scale (1B+ users)
- Have stories about scale challenges
**Typical Questions**:
- "Design a feed system like Facebook"
- "Design a rate limiter"
- "Design a distributed cache"
- "Design a URL shortener at global scale"
**Company-Specific Notes**:
- Google: Loves system design depth + algorithms
- Meta: Cares about scale and rapid iteration
- Amazon: Values customer obsession + operational excellence
- Apple: Quality and user experience matter
- Netflix: Cares about resilience and performance
### High-Growth Startup (Series C/D/E)
**Interview Characteristics**:
- **Coding**: Practical problems (can you ship?)
- **System Design**: Scaling from thousands to millions
- **Bar**: Moderate-high, but more practical
- **Process**: 2-3 rounds (2-3 hours)
**Preparation Focus**:
- Show you can ship quickly
- Demonstrate adaptability
- Have stories about scaling under pressure
- Understand their specific problems
**Typical Questions**:
- "We're at 100K users, getting slow. Fix it."
- "Design a system for our specific use case"
- "How would you approach our biggest technical problem?"
- "Tell me about scaling something rapidly"
**Pre-Interview Research**:
- Use their product
- Read their engineering blog
- Understand their tech stack
- Know their current challenges (from news/Crunchbase)
### Well-Established Tech Company (Microsoft, Adobe, IBM, Oracle)
**Interview Characteristics**:
- **Coding**: Practical over theoretical
- **System Design**: Real-world with constraints
- **Bar**: Solid, but less extreme than FAANG
- **Process**: 2-3 rounds (2-3 hours)
**Preparation Focus**:
- Show you understand enterprise constraints
- Have stories about complex org navigation
- Know their products
- Understand their competitive position
**Typical Questions**:
- "Design a system for our customers"
- "How would you approach this legacy codebase?"
- "Tell me about working in large organizations"
- "How do you balance innovation and stability?"
### Early-Stage Startup (Seed/Series A/B)
**Interview Characteristics**:
- **Coding**: May be optional or lighter
- **System Design**: Medium scale, specific to their needs
- **Bar**: Moderate, emphasis on fit
- **Process**: Casual (1-2 rounds, 1-2 hours)
**Preparation Focus**:
- Show genuine interest (not career move)
- Have opinions on their technical direction
- Demonstrate adaptability and learning
- Understand their vision
**Typical Questions**:
- "Tell me about yourself"
- "What would you work on first?"
- "How do you think about our technical challenges?"
- "Why do you want to join us?"
## Role-Specific Strategy
### IC Track (Individual Contributor)
**What They Want**:
- Technical contribution
- Mentorship/multiplying impact
- Technical leadership (without management)
**Preparation**:
- Coding: Solid (probably LeetCode medium+)
- System Design: Yes (you design systems)
- Behavioral: Focus on technical impact + mentorship
**Sample Questions**:
- "Design a system for this use case"
- "Tell me about your technical expertise"
- "How do you mentor others?"
- "Describe a system you scaled"
### Tech Lead Track
**What They Want**:
- Technical excellence + people skills
- Can make architecture decisions
- Can help engineers succeed
**Preparation**:
- Coding: Strong (you need to code still)
- System Design: Yes (you decide architecture)
- Behavioral: Focus on both technical + people stories
**Sample Questions**:
- "Tell me about a team you've led"
- "How do you develop people?"
- "Design this system"
- "How do you handle technical disagreement?"
### Manager Track
**What They Want**:
- Can grow people
- Can navigate org
- Can deliver results through others
**Preparation**:
- Coding: May be lighter (but not absent)
- System Design: Lighter (you don't design systems)
- Behavioral: Focus on people growth, retention, culture
**Sample Questions**:
- "Tell me about developing a person"
- "How do you handle underperforming engineer?"
- "Describe your team dynamics"
- "How do you balance business and team needs?"
## Pre-Interview Preparation Plan
### Week 1: Company Deep-Dive
- [ ] Use their product (spend 2+ hours)
- [ ] Read recent press (last 6 months)
- [ ] Study engineering blog (last 2 years)
- [ ] Check their job postings (understand hiring)
- [ ] Research leadership team
- [ ] Identify 5 technical challenges they likely face
- [ ] Understand their business model and competitors
**Deliverable**: One-page company summary with challenges you could solve
### Week 2: Role Alignment
- [ ] Study job description deeply
- [ ] List top 10 requirements
- [ ] Map your background to each
- [ ] Identify gaps (be prepared to address)
- [ ] Write "why I want this role" (1-2 minutes)
- [ ] Prepare 3-5 relevant stories
- [ ] Generate 5-7 thoughtful questions to ask
**Deliverable**: Interview talking points aligned to role
### Week 3: Interview Practice
- [ ] Practice coding (5-10 problems at their difficulty)
- [ ] Design 2-3 systems they likely build
- [ ] Mock interview (with friend)
- [ ] Get feedback on communication
- [ ] Time yourself (coding 30 min, system design 40 min)
- [ ] Practice behavioral stories (2-3 min each)
- [ ] Record yourself (watch for tics, clarity)
**Deliverable**: Confidence that you can execute under pressure
### Week 4: Mental Prep
- [ ] Review your story bank (don't memorize, internalize)
- [ ] Review company research (brief last look)
- [ ] Prepare your work setup (quiet place, good internet)
- [ ] Get good sleep night before
- [ ] Eat healthy
- [ ] Arrive early (5 min buffer for tech checks)
**Deliverable**: Calm, prepared mindset
## Question Prediction by Company Type
### FAANG Typical Questions
- "Design a feed system"
- "Design a cache"
- "Design a rate limiter"
- "Design a distributed storage system"
- "How would you monitor this?"
- "Tell me about your biggest technical contribution"
- "How do you handle disagreement?"
### Startup Typical Questions
- "Design an analytics system"
- "We're at X scale, it's slow. How do you solve it?"
- "Design a system for our specific need"
- "Tell me about rapid scaling"
- "How would you improve our tech?"
- "What would you work on first?"
### Enterprise Typical Questions
- "Design a system for our customers"
- "How would you approach this legacy system?"
- "Tell me about working in large orgs"
- "How do you balance innovation and stability?"
- "Describe a complex project"
- "How do you influence across teams?"
## Positioning Your Background
### The Alignment Formula
For each major requirement in the job:
**Step 1**: Identify the requirement
"They need someone who can [X]"
**Step 2**: Show you have it
"At [company], I [did similar work]"
**Step 3**: Make it specific
"Here's an example: [concrete project]"
**Step 4**: Quantify the impact
"The result was [metric/outcome]"
### Example Alignments
**Requirement**: "Experience scaling systems"
**Your background**: "I scaled our database from 100K to 10M QPS"
**In interview**: "That required [challenges], which is why I approach scaling by [methodology]"
**Requirement**: "Technical leadership"
**Your background**: "I led architecture decisions across 3 teams"
**In interview**: "I did this by [approach], which shows [capability]"
**Requirement**: "Infrastructure expertise"
**Your background**: "I designed our microservices infrastructure from scratch"
**In interview**: "The lessons I learned were [insights]"
## Your "Why" Story (2 minutes)
Prepare to answer: "Why are you interested in this role?"
**Structure**:
```
1. What excites you about what they're building
2. Specific technical problem you want to solve
3. How your background prepares you
4. What's next for you
```
**Example**:
```
"I'm interested because:
1. You're solving distributed systems at scale—that's exciting
2. Specifically, I want to dive deep into distributed consensus—I've done similar work
3. My background in systems design means I can contribute immediately
4. I'm looking to go deeper on distributed systems, which this role offers
"
```
## Red Flags & How to Address
### If you're worried...
**Concern**: "I don't have exact experience in [X]"
**Strategy**: "I have deep experience in [related skill], which transfers to [X]"
**Concern**: "I haven't worked at a company their size"
**Strategy**: "I've scaled [system/team] from [small] to [large], showing I can grow"
**Concern**: "I'm coming from a different tech stack"
**Strategy**: "I learn new tech quickly. Here's my approach to learning: [methodology]"
**Concern**: "I'm transitioning roles (IC→Lead, etc.)"
**Strategy**: "I've been preparing by [evidence], and I'm excited about [new domain]"
## Interview Day
### Night Before
- Get good sleep (matters more than extra studying)
- Light review of company facts
- Prepare your work space
### Morning Of
- Healthy breakfast
- Review your "why" story and key talking points
- Get to call 5 minutes early
### During
- Take your time (silence while thinking is OK)
- Ask clarifying questions
- Think out loud
- Show genuine curiosity
- Be yourself
### After
- Thank you email within 24 hours
- Reference something specific from conversation
- Reiterate genuine interest
- Keep it brief (don't oversell)
## Success Metrics
You're well-prepared when:
- ✓ Can discuss their company/problems intelligently
- ✓ Have relevant stories for their role requirements
- ✓ Can solve coding problems at their difficulty
- ✓ Can design systems for their scale
- ✓ Can articulate why this role matters to you
- ✓ Have thoughtful questions to ask them
- ✓ Feel confident about your background/experience
You nailed the strategy when they seem interested in YOU specifically, not just looking for "anyone who can code."

301
commands/system-design.md Normal file
View File

@@ -0,0 +1,301 @@
---
model: claude-opus-4-1
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <system-name> [--depth=standard|deep] [--focus=architecture|scalability|trade-offs] [--generate-diagram=true|false]
description: Design complete systems with WHY, WHAT, HOW, CONSIDERATIONS, and DEEP-DIVE framework
---
# System Design Interview Coach
Complete framework for designing systems from problem to implementation. Includes WHY/WHAT/HOW structure, trade-off analysis, mermaid diagrams, and deep-dive optimizations.
## Interview Flow (60 minutes)
### Phase 1: Requirements & Context (5 minutes)
**Your goal**: Understand the problem deeply before designing
Ask clarifying questions:
- Scale: users, requests per second, data volume?
- Availability: SLA requirements (99.9%, 99.99%)?
- Latency: response time targets?
- Consistency: strong or eventual?
- Features: read-heavy, write-heavy, or balanced?
- Growth: expected growth rate?
**Interviewer's watching**:
- Do you ask the right questions?
- Do you understand the constraints?
- Can you estimate numbers?
### Phase 2: High-Level Architecture (10 minutes)
**Your goal**: Outline the system at 30,000 feet
Cover:
- Major components (load balancer, services, databases, caches)
- Communication patterns (sync/async, protocols)
- Data flow from user request to response
- Rough scalability approach
Draw simple diagram showing component interactions.
**Interviewer's watching**:
- Do you think in systems?
- Can you structure complexity?
- Do you know when to keep it simple?
### Phase 3: Detailed Component Design (20 minutes)
**Your goal**: Explain key components with confidence
Pick 2-3 components to discuss:
- How does this component work?
- Why this technology choice?
- What are the constraints it handles?
- How does it scale?
**Interviewer's watching**:
- Do you have technical depth?
- Can you justify decisions?
- Do you know trade-offs?
### Phase 4: Scalability & Trade-Offs (15 minutes)
**Your goal**: Show senior-level thinking
Discuss:
- Bottlenecks: What breaks first at 10x growth?
- Consistency: Strong vs eventual? Why?
- Reliability: Failure modes and recovery?
- Cost: What drives operational expense?
- Complexity: Is this operationally feasible?
**Interviewer's watching**:
- Do you think like a Staff engineer?
- Can you make principled trade-offs?
- Do you understand operational reality?
### Phase 5: Extensions & Deep-Dives (8 minutes)
**Your goal**: Demonstrate mastery
Address follow-up questions:
- "How would you handle [new requirement]?"
- "What's the hardest part of operating this?"
- "What would you optimize for [metric]?"
- "How would you debug this in production?"
**Interviewer's watching**:
- Are you thinking ahead?
- Can you handle surprises?
- Do you know what you don't know?
## System Design Framework
### WHY: Problem & Context
**What to cover**:
- Problem statement (1-2 sentences)
- Primary use cases (top 3-5)
- User base and growth expectations
- Non-functional requirements (scale, latency, availability)
- Business context (why does this matter?)
**For interviewer's benefit**:
- Shows you understand the problem before solving it
- Demonstrates customer empathy
- Proves you can estimate and scope
### WHAT: Components & Data Model
**What to cover**:
- Core entities (Users, Posts, Comments, etc.)
- Entity relationships
- Storage requirements (how much data?)
- Major services (Authentication, Feed, Search, etc.)
- API contracts (what endpoints do we need?)
**For interviewer's benefit**:
- Shows you think about data structure
- Demonstrates you can decompose systems
- Proves you understand component boundaries
### HOW: Architecture & Patterns
**What to cover**:
- Request flow (from user → response)
- Service architecture (monolith vs microservices decision)
- Communication patterns (synchronous, asynchronous, pub-sub)
- Storage topology (where does data live?)
- Caching strategy (where, what, how long?)
- Replication and failover
**For interviewer's benefit**:
- Shows you know architectural patterns
- Demonstrates systems thinking
- Proves you can make principled decisions
### CONSIDERATIONS: Trade-Offs & Reality
**What to analyze**:
**Consistency**
- Strong: Always get latest data (high latency, low availability)
- Eventual: Might get stale data (low latency, high availability)
- Your choice: "For [reason], we accept [consistency model]"
**Scalability**
- Vertical: Big machines (simpler, limited)
- Horizontal: More machines (complex, unlimited)
- Your choice: "We scale [direction] because [reason]"
**Reliability**
- Single point of failure? (bad)
- Replication strategy? (multiple copies)
- Disaster recovery? (backup and restore procedure)
- Your choice: "We replicate [this way] to handle [failure]"
**Cost**
- Storage: What's the cost per GB?
- Compute: What's the cost of this many servers?
- Bandwidth: What's the egress cost?
- Your choice: "This costs [X] but solves [Y]"
**Operational Complexity**
- How many different technologies?
- How hard is debugging?
- What's the on-call pain?
- Your choice: "We keep it simple: [reason]"
### DEEP-DIVE: Component Optimization
**For each major component**, be prepared to discuss:
1. **Bottleneck Analysis**
- What's the scaling limit?
- Where would we hit the wall first?
- How do we know?
2. **Optimization Opportunities**
- What could we do to handle more load?
- What are the trade-offs?
- When is this optimization worth doing?
3. **Failure Modes**
- What if [component] fails?
- How do we detect it?
- How do we recover?
4. **Operational Concerns**
- How do we monitor this?
- What metrics matter?
- How do we debug issues?
5. **Alternative Approaches**
- What's another way to design this?
- When would you choose it?
- What problems does it have?
## Mermaid Diagram Strategy
Create diagrams that show:
1. **Architecture Diagram**: Components and communication
2. **Data Flow**: Request path through the system
3. **Database Schema**: Key entities and relationships
**Tips**:
- Keep diagrams simple initially
- Add detail when asked
- Label important decisions
- Annotate bottlenecks
## Example: Design Facebook Feed
### WHY
- **Problem**: Show users their friends' posts in a personalized, real-time feed
- **Use Cases**:
1. User opens app → see recent posts from friends
2. Friend posts → appears in followers' feeds quickly
3. Massive scale: billions of posts, minutes of latency acceptable
- **Requirements**:
- Read-heavy (100:1 read to write ratio)
- Latency: Feed load < 200ms
- Availability: 99.99%
- Consistency: Eventual OK (a few minutes lag acceptable)
### WHAT
- **Entities**: User, Post, Friendship, Like, Comment
- **Relationships**: User → Post (1:many), User → Friend (many:many)
- **Storage**: Posts: 100s of billions, User data: billions
- **Services**: Auth, Post Creation, Feed Service, Search
- **APIs**:
- POST /posts (create)
- GET /feed (get user's feed)
- POST /posts/{id}/like (like post)
### HOW
- Load balancers distribute requests
- Stateless web servers handle auth and routing
- Post service writes posts to database
- Feed service reads from cache first, database second
- Cache layer (Redis) stores hot posts
- Fanout on write: When user posts, push to all followers' feeds
- Asynchronous: Queue for fanout, workers process
### CONSIDERATIONS
- **Consistency**: Eventual consistency (a few second lag OK)
- **Scalability**: Horizontal—more servers as needed
- **Reliability**: Multi-region replication for availability
- **Cost**: Balance storage vs computation
- **Complexity**: Fanout-on-write is complex but enables fast reads
### DEEP-DIVE
1. **Fanout Bottleneck**: Celebrity posts with 100M followers?
- Solution: Hybrid fanout—fanout for normal users, cache for celebrities
2. **Feed Personalization**: How do we rank posts?
- Solution: ML model, but start with recency + engagement
3. **Real-time Updates**: How do we push new posts?
- Solution: Long-polling, WebSockets, or event stream
## Talking Points During Interview
**When introducing your design**:
- "Let me outline the system at a high level..."
- "The key insight here is [insight]"
- "This design makes [requirement] easy"
**When defending a choice**:
- "We chose [option] because [constraint] → [option] is better"
- "The trade-off is [cost] for [benefit]"
- "This would change if [different constraint]"
**When asked about scaling**:
- "Currently [component] is the bottleneck"
- "We'd scale [direction] because [reason]"
- "This approach works until [limit], then we'd [next evolution]"
**When asked about failure**:
- "If [component] fails, [other component] takes over"
- "We'd detect it via [monitoring], then [recovery action]"
- "This is why we replicate [data/component]"
## Red Flags to Avoid
❌ Diving into implementation details too early
❌ Not asking clarifying questions
❌ Designing for scale you don't need
❌ Making technology choices without justification
❌ Ignoring operational reality
❌ Treating consistency/availability as separate concerns
❌ Not discussing trade-offs
✓ Start broad, add detail on request
✓ Ask clarifying questions upfront
✓ Design for the specified scale
✓ Justify technology choices
✓ Consider how humans operate it
✓ Explicitly discuss trade-offs
✓ Show you understand what you don't know
## Success Criteria
You're ready when you can:
- ✓ Clarify ambiguous requirements with good questions
- ✓ Outline architecture clearly on a whiteboard
- ✓ Explain each component's role
- ✓ Justify your technology choices
- ✓ Discuss trade-offs explicitly
- ✓ Handle "what if" questions with confidence
- ✓ Show understanding of operational reality
- ✓ Demonstrate Staff+ systems thinking

335
commands/whiteboard.md Normal file
View File

@@ -0,0 +1,335 @@
---
model: claude-sonnet-4-0
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <concept-or-problem> [--format=system-design|algorithm|architecture] [--scenario=explain|walkthrough|deep-dive]
description: Master whiteboarding and technical communication for interviews
---
# Technical Communication & Whiteboarding Coach
Learn to think out loud, explain complex concepts clearly, and communicate your technical thinking in real time during interviews.
## Core Communication Principle
Your thinking is more important than your solution. Interviewers want to see:
- How you approach unfamiliar problems
- How you incorporate feedback
- How you explain your reasoning
- How you handle uncertainty
## Interview Whiteboarding Flow
### Setup (First 1 minute)
**What to do**:
1. Take a breath (shows confidence)
2. Repeat the problem back (shows understanding)
3. Ask clarifying questions (shows thoughtfulness)
4. Outline your approach (shows structure)
**Example**:
```
"So you want me to design [system] with [constraints].
Let me make sure I understand:
- [Constraint 1]?
- [Constraint 2]?
- Success metrics are [metric 1] and [metric 2]?
Here's how I'll approach this:
1. Outline components
2. Walk through user flow
3. Discuss trade-offs
4. Explore deep-dive questions
Does that work for you?"
```
This buys you time while staying engaged.
### Thinking Out Loud (The Critical Skill)
**What NOT to do**:
```
[Sit silently for 5 minutes]
[Write code/diagram in silence]
[Explain everything at the end]
```
**What TO do**:
```
"Let me think about this structure...
The challenge is [problem].
One approach would be [option A], but that would [drawback].
Another approach would be [option B], which [benefit] but [cost].
Given [constraint], I think [option A] is better because [reasoning].
Does that make sense, or would you want me to explore [option B]?"
```
**Why this works**:
- Shows your thinking process
- Gives interviewer chance to guide you
- Prevents you from going down wrong path alone
- Demonstrates communication skill
### Whiteboard Technique: System Design
**Layout**:
```
┌─────────────────────────────────────────┐
│ [Title: System Name] │
└─────────────────────────────────────────┘
[Client Layer] [API Gateway]
↓ ↓
[Load Balancer] ─────→ [Service 1]
[Service 2]
↓
┌──────────────┐
│[Database] │
│[Cache] │
│[Queue] │
└──────────────┘
[Key Decisions/Annotations on the side]
```
**Tips**:
- Use boxes for components (services, databases)
- Use arrows for communication with labels (HTTP, gRPC, async)
- Use cylinders for databases
- Label everything (what, why)
- Leave space to add detail
- Draw rough; clarity matters more than art
### Whiteboard Technique: Algorithm
**Layout**:
```
Problem: [Statement]
Approach: [High-level strategy]
Example:
Input: [example]
Process:
Step 1: [what, why]
Step 2: [what, why]
Output: [result]
Complexity: Time O(?) Space O(?)
```
**Tips**:
- Write problem clearly at top
- Work through example step-by-step
- Show your thinking
- Label complexity clearly
- Mark improvements with arrows
### Narrating Your Thinking
**Pattern to use**:
```
"I'm thinking about [aspect].
The key insight is [insight].
So my approach is [approach].
Let me walk through this on the example:
[Step 1]: [explain]
[Step 2]: [explain]
[Step 3]: [explain]
Does this make sense? Any questions before I code this?"
```
**For System Design**:
```
"One challenge is [bottleneck].
To handle this, I'd use [technology] because [side effect].
That dissolves [problem] and enables [benefit].
Here's what it looks like:
[Draw component]
[Explain interaction]
"
```
## Handling Questions During Whiteboarding
### When asked "What about X?"
**Don't**: Dismiss it or add it to your diagram
**Do**: "That's a great point. Currently I have [approach]. For X, we could [option]. Which would you rather see me explore?"
### When you don't know something
**Don't**: Pretend to know or go silent
**Do**: "I'm not sure off the top of my head. Let me think... I'd probably [approach] and then validate with [method]"
### When they push back on your design
**Don't**: Get defensive
**Do**: "I see your concern. That's why we [mitigation]. The trade-off is [what we gain] vs [what we lose]."
### When they ask you to go deeper
**Do prepare** by understanding which components need depth:
- They ask you to explain → you explain in detail
- They ask "how would you..." → you think through the new constraint
- They ask "what if..." → you adjust your design live
## Active Listening Signals
Show you're listening:
- ✓ Pause before responding (shows you heard them)
- ✓ Reference their point: "When you mentioned X, that suggests..."
- ✓ Adjust based on feedback: "So you're saying reliability matters more, which means..."
- ✓ Look at them when they're talking (yes, even at whiteboard)
- ✓ Nod or indicate understanding
This matters as much as your technical answer.
## Pacing Your Explanation
### The 2-Minute Rule
- **For any concept**: Explain in 2 minutes at high level
- **If they want detail**: They'll ask, then go 5 minutes deep
- **If running out of time**: "In the interest of time, let me jump to [important part]"
### Time Management Template
**60-minute system design**:
- 0-5 min: Clarify requirements
- 5-15 min: High-level design
- 15-40 min: Component detail
- 40-55 min: Trade-offs and deep-dive
- 55-60 min: Your questions
**45-minute coding**:
- 0-2 min: Clarify problem
- 2-5 min: Approach outline
- 5-25 min: Code + explanation
- 25-40 min: Complexity + optimization
- 40-45 min: Edge cases + questions
## Specific Scenarios
### Explaining Cache Invalidation
Straightforward approach:
```
"We use a cache layer for frequently accessed data.
The challenge is: how do we handle stale data?
I'd approach it with TTLs (time-to-live):
- Data cached for [duration]
- After TTL expires, cache invalidates
- Next request fetches fresh data
Trade-off: We accept some staleness (max [duration]) to gain speed
"
```
### Explaining Consistency Models
```
"We have two options:
Strong Consistency:
- Always latest data
- But slower (coordinates across systems)
- Use when correctness is critical (payments, orders)
Eventual Consistency:
- Might be slightly stale (by [duration])
- But fast (no coordination)
- Use when freshness tolerance is high (feeds, recommendations)
Given [constraint], I'd choose [model]"
```
### Explaining Failure Handling
```
"If [component] fails, here's what happens:
Detection: [monitoring mechanism]
Failover: [backup takes over]
Recovery: [how we restore]
This ensures [SLA]"
```
## Anti-Patterns to Avoid
❌ **Silent coding**: Code while thinking
→ ✓ Narrate while you code: "I'm adding this check because..."
❌ **Waiting for perfection**: Perfect diagram before explaining
→ ✓ Rough diagram + narration: explain as you draw
❌ **Technical jargon without explanation**: "We'll use eventual consistency"
→ ✓ Explain for humans: "We accept [small lag] to gain [speed]"
❌ **Dismissing interruptions**: "Let me finish my explanation"
→ ✓ Embrace interruptions: "Good point, that means we need [adjustment]"
❌ **Long monologues**: Talk for 10 minutes straight
→ ✓ Conversation: "Does this make sense? Any questions?"
❌ **Vague descriptions**: "It's like AWS S3"
→ ✓ Concrete description: "A distributed file system where [how it works]"
## Confidence Techniques
### Show Confidence Without Arrogance
- Speak clearly (not fast)
- Use decisive language: "I'd choose X" not "maybe we could possibly try"
- Explain your reasoning (not just the answer)
- Invite questions: shows you're secure in your thinking
### When Uncertain
- "Let me think through that..." (shows you're careful)
- "That's a good question—I hadn't considered..." (shows openness)
- "I'd want to validate that with [method]..." (shows rigor)
### Physical Presence
- Stand tall (not defensive slouch)
- Use the whiteboard space (don't cower in corner)
- Make eye contact (show you're engaged)
- Gesture naturally (show you're comfortable)
## Practice Techniques
### Solo Practice
1. **Record yourself**: Watch how you explain without audience
2. **Whiteboard solo**: Explain to empty room
3. **Narrate videos**: Watch architecture videos, pause and explain aloud
### With Partner
1. **Think-aloud protocol**: Explain while they listen
2. **Interruption practice**: Have them interrupt with questions
3. **Feedback focus**: "Could you follow my thinking?"
### In-person Mock
1. Find someone to play interviewer
2. Use actual whiteboard
3. Time yourself
4. Get specific feedback
## The Goal
Whiteboarding well means:
- ✓ Clear thinking that's easy to follow
- ✓ Inviting collaboration, not defending a solution
- ✓ Showing your reasoning, not just your answer
- ✓ Comfortable thinking out loud under pressure
- ✓ Responsive to feedback
You're not trying to be perfect. You're trying to think well with an audience.