Distributed System Design Evaluation

Template Overview

System design interviews evaluate how senior engineering candidates navigate massive scale, architectural ambiguity, and competing technical trade-offs. When candidates can only regurgitate generic textbook three-tier architectures without understanding failure domains or hardware limits, system design loops fail.

A rigorous System Design Rubric evaluates candidates on end-to-end engineering craft: scoping requirements, calculating back-of-the-envelope capacity envelopes, designing clean API contracts, defining storage topologies, and hardening systems against catastrophic failures.

This template provides an engineering-grade evaluation structure: requirements scoping, architectural block diagramming, data storage schema evaluation, trade-off analysis, and final hiring recommendations.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "System Design Interview: [Candidate Name]"
date: [YYYY-MM-DD]
candidate_name: "Candidate Casey Zhang"
interviewer: "[[Principal Systems Architect]]"
role_applied: "Staff Systems Engineer — Core Infrastructure"
design_problem: "Local-First Full-Text Search Engine across 100,000 Markdown Vault Notes"
recommendation: [Strong Hire | Hire | Leaning Hire | Leaning No Hire | Strong No Hire]
tags: [interview, system-design, architecture, engineering, hiring]
---

# System Design Interview: [Candidate Name] — [YYYY-MM-DD]

## 1. Requirements Scoping & Non-Functional SLAs
- **Functional Requirements:** Real-time incremental indexing of Markdown notes; sub-10ms full-text keyword queries; support for boolean operators and prefix matching.
- **Non-Functional SLAs:**
  - Query Latency: P99 < 15ms across 100,000 documents (~500MB total text).
  - Memory Envelope: Maximum 80MB RSS under active query load.
  - Zero Network Egress: 100% offline local execution; zero external daemon dependencies.
- **Rating:** 🟢 Exceeds Expectations (Immediately pinned down memory footprint and crash recovery SLAs).

## 2. High-Level Architectural Topology
- **Storage Subsystem:** Selected embedded SQLite with FTS5 virtual table in WAL mode over custom inverted index files.
- **Concurrency Model:** Dedicated background Grand Central Dispatch (GCD) serial queue for ingestion; concurrent read connections for UI queries.
- **Memory Management:** Leveraged `mmap` for database pages to allow macOS kernel virtual memory paging under pressure.

## 3. Deep-Dive: Indexing Pipeline & Concurrency Trade-Offs
| Design Choice | Candidate Proposal | Evaluator Critique / Probing | Verdict |
| :--- | :--- | :--- | :--- |
| **Tokenization** | Standard unicode61 with custom unicode diacritics stripping | Probed on CJK (Chinese/Japanese/Korean) n-gram tokenization | Handled gracefully with bigram fallback |
| **Write Contention** | Debounced 250ms batching before committing SQLite transactions | Probed on potential data loss during sudden app crash | Solved with transaction WAL checkpoints on shutdown |
| **Crash Safety** | Automated SQLite integrity check on app startup | Probed on recovery time for 500MB database | Verified <200ms verification time |

## 4. Bottlenecks, Failure Modes & Edge Cases
- Successfully addressed file-system change storms (e.g. `git checkout` mutating 5,000 files simultaneously) by queuing debounced file change events.
- Recognized that opening too many concurrent SQLite reader handles on macOS can exhaust POSIX file descriptor limits.

## 5. Final Hiring Recommendation & Synthesis
> [!IMPORTANT] Recommendation: Strong Hire
> Casey demonstrated world-class systems intuition. Deep knowledge of SQLite internals, POSIX file descriptor limits, and Apple Silicon unified memory caching. An immediate hire for our storage team.

- [ ] Submit scorecard to hiring portal.
- [ ] Attend hiring committee review on [[YYYY-MM-DD]].

Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

---
title: "System Design: Casey Zhang"
date: 2026-10-07
candidate_name: "Casey Zhang"
interviewer: "[[Elena Rostova]]"
recommendation: Strong Hire
tags: [interview, system-design]
---

# System Design: Casey Zhang — October 7, 2026

## 1. Summary
Casey designed an outstanding local search indexer using SQLite FTS5 with custom WAL checkpoints.

## 2. Strengths
Mastery of POSIX file locks, memory mapping, and thread concurrency.

## 3. Recommendation
Strong Hire for Staff Systems Engineer.

When to Use and When to Avoid

When to Use

• Use during senior and staff-level engineering system design interviews.
• Use to evaluate distributed systems or local client architecture competencies against an objective rubric.
• Use to document candidate trade-off analysis, capacity estimations, and failure recovery designs.

When to Avoid

• Avoid using for junior software developer algorithmic coding screens (use [[technical-coding-interview]]).
• Avoid using for non-technical behavioral interviews.

On-Device AI Integration

Capture system design interviews with Oyma on macOS:

Analyze the system design interview audio transcript:
1. Synthesize the candidate's functional requirements scoping and non-functional SLA targets.
2. Outline the high-level system topology, storage models, and concurrency architecture proposed.
3. Detail the technical trade-offs evaluated (caching, database choices, memory overhead, failure modes).
4. Record the final hiring recommendation with specific systems engineering evidence.
Output in rigorous, engineering-grade CommonMark.

Your technical interview rubrics and candidate assessments remain safely encrypted on your private Mac.