Debugging-First Round
Forward Deployed Engineering
What it tests
Diagnostic thinking — can they find and fix bugs in unfamiliar code?
Format
- 1Give candidate a broken application (your product or a simplified version)
- 23-5 bugs of increasing difficulty: syntax error, logic error, race condition, performance issue (N+1 query), subtle security vulnerability
- 3Candidate debugs live, explaining their thought process
What to look for
- Systematic debugging (vs. random guessing)
- Tool usage (debugger, logging, profiling)
- How they explain their reasoning (critical for customer-facing eng)
- Do they find the root cause or just patch the symptom?
Full description
Format:
- Give candidate a broken application (your product or a simplified version)
- 3-5 bugs of increasing difficulty:
- Bug 1: Syntax error (warm-up)
- Bug 2: Logic error in data transformation
- Bug 3: Race condition in async code
- Bug 4: Performance issue (N+1 query, memory leak)
- Bug 5: Subtle security vulnerability
- Candidate debugs live, explaining their thought process
Time: 60 minutes
What to look for:
- Systematic debugging (vs. random guessing)
- Tool usage (debugger, logging, profiling)
- How they explain their reasoning (critical for customer-facing eng)
- Do they find the root cause or just patch the symptom?
Why debugging > building: FDE/SE work is 70% debugging customer issues, 30% building new features. Testing what they'll actually do on the job.