5 exercises — choose the best-structured answer to common developer tools engineering interview questions. Focus on language server protocols, debug adapters, parsing, and editor extension architecture.
Structure for developer tools engineering interview answers
Name the protocol layer: LSP, DAP, and Tree-sitter each have distinct client-server boundaries
Cover the lifecycle: initialise → active use → shutdown sequences matter for correctness
Address performance: incremental parsing, lazy computation, and cancellation are first-class concerns
Give concrete examples: name real servers (rust-analyzer, debugpy, pylsp) and real editors (VS Code, Neovim)
0 / 5 completed
1 / 5
The interviewer asks: "Explain the Language Server Protocol architecture — how does the LSP client-server model work, and what are the key lifecycle messages?" Which answer best covers LSP internals?
Option B covers the full LSP picture: JSON-RPC transport details, the initialize/initialized/shutdown lifecycle sequence with capability negotiation, all four document sync notification types with their semantics, five core request types, $/cancelRequest for expensive operations, and server-side incremental AST maintenance (using rust-analyzer + Salsa as a concrete example of how production servers handle performance). Options A, C, D each describe the high-level concept correctly but don't cover capability negotiation, document sync lifecycle, cancellation, or how servers maintain incremental state.
2 / 5
The interviewer asks: "How does the Debug Adapter Protocol work — explain the adapter pattern and the key request/event lifecycle for a debugging session." Which answer best covers DAP internals?
Option B covers all seven layers: adapter pattern with concrete runtime examples, full session lifecycle (initialize → launch → configurationDone), three types of breakpoints (source, function, data watchpoints), four execution control requests + the stopped event with reason and threadId, stack inspection with the lazy variable expansion via variablesReference, custom and evaluate requests, and reverse requests (runInTerminal, startDebugging for multi-process). Options C and D name the initialize/launch sequence but don't cover breakpoint types, variable inspection mechanics, or reverse requests.
3 / 5
The interviewer asks: "What is Tree-sitter, how does it differ from traditional regex-based syntax highlighting, and what are the key concepts in writing a Tree-sitter grammar?" Which answer best covers Tree-sitter internals?
Option B covers the full picture: CST vs token stream distinction, incremental re-parsing with microsecond performance, error-resilient partial trees with error nodes, grammar combinators (seq, choice, repeat, prec, prec.left, prec.right), external C scanners for context-sensitive lexing (Python indentation, Ruby heredocs), LR(1) compilation to C, S-expression query syntax with a concrete example, and testing methodology. Options C and D each identify 1-2 correct aspects but none cover external scanners, LR(1) compilation, query syntax, or testing.
4 / 5
The interviewer asks: "Walk through the key sections of a VS Code extension manifest (package.json) — what are activation events, contribution points, and how do you keep extension startup fast?" Which answer best covers VS Code extension architecture?
Option B covers all six dimensions: exact package.json section names and types, six specific activation events with the * anti-pattern warning, eight specific contribution point types with descriptions, extension host isolation and DOM access restriction, startup performance guidance (lazy imports, dynamic import, 200ms target, profiler), and web extension packaging. Options A, C, D each mention activation events and contribution points but don't cover extension host architecture, startup performance best practices, or web extension support.
5 / 5
The interviewer asks: "What are LSP semantic tokens — how do they differ from TextMate grammar-based highlighting, and how does the server-client protocol work for semantic tokens?" Which answer best covers semantic token architecture?
Option B covers all six dimensions: TextMate grammar limitations (line-based regex, convention-based scope names), semantic token value proposition (actual type information), delta encoding format with all 5 integer fields explained (deltaLine, deltaStartChar, length, tokenType as index, tokenModifiers as bitmask), three protocol request types (full, range, full/delta), VS Code rendering and theme compatibility, and performance (lazy computation, cancellation). Options A, C, D each identify the key benefit but don't explain the encoding format, the three request types, or the theme compatibility mechanism.