Building interviewing.io's architectural foundation required balancing several competing priorities: real-time collaboration, state consistency, and search visibility. The platform's core challenge emerges from its dual nature as both an interactive coding environment and a content-heavy educational resource.
Asynchronous State Machine for Interview Sessions
The interview room operates as a finite state machine with defined transitions: Idle -> Connecting -> Active -> Degraded -> Terminated. Each state carries specific WebSocket message contracts. A critical early bug involved race conditions during reconnection—if a candidate refreshed while the interviewer was typing feedback, the feedback state would desync.
The engineering team resolved this by implementing Operational Transformation (OT) for the shared editor and CRDTs for the video/audio metadata. This distinction matters: OT handles the high-frequency, latency-sensitive code edits, while CRDTs manage the lower-frequency, eventually-consistent session metadata. The InterviewSession aggregate root encapsulates this complexity, exposing only applyEvent(SessionEvent) to the application layer.
Real-Time Signaling with Fallback Resilience
WebRTC signaling traverses a custom Elixir/Phoenix channel. However, the architectural insight lies in the fallback mechanism. When STUN/TURN negotiation fails (common in corporate firewalls), the system degrades gracefully to a relayed audio stream rather than failing the session. This Degraded state triggers a UI banner but preserves the core interview loop. Monitoring revealed that 12% of sessions entered this state, disproportionately affecting users in APAC regions—a geographic bias that informed subsequent TURN server provisioning.
Content Architecture for SEO and Discoverability
Interviewing.io's content strategy hinges on "signal over noise." Each company-specific interview guide (e.g., "Google PM Interview") follows a strict schema:
- H2: Company + Role + "Interview Process"
- H2: "What to Expect" (behavioral pattern)
- H2: "Sample Questions" with
<details>/<summary>expandable sections to prevent content dilution. - H2: "Preparation Resources"
Internal linking prioritizes contextual relevance over generic navigation. A guide on Amazon's Leadership Principles links to specific behavioral question breakdowns, not a generic "behavioral interview" page. This topology maximizes PageRank flow to high-intent, high-conversion pages. The content CMS enforces this schema at the API layer—attempting to publish without the required H2 structure returns a 422 Unprocessable Entity.
Candidate-Employer Matching as a Two-Sided Market
The booking system presents a classic marketplace optimization. Candidates demand transparency (salary ranges, interviewer seniority), while employers control access to protect time. The architectural compromise: anonymized profile cards showing "Ex-Google L6, 8 years experience, specializes in System Design" without PII. The matching algorithm weights candidate preferences (company tier, practice vs. real interview) against employer filters (years of experience, current company tier). A hidden complexity: employers often request "no current employees at competitors," which the graph database handles via negative edge traversal.
Analytics and Privacy Boundaries
Session recordings are segmented by data sensitivity. Code editor keystrokes are ephemeral (real-time only, never stored). Video/audio streams are stored encrypted for 30 days for dispute resolution, then purged. The analytics pipeline derives "coding velocity" metrics—keystrokes per minute, paste events, idle time— but aggregates these immediately to prevent individual reconstruction. This design satisfied GDPR Article 17 (right to erasure) by ensuring no raw keystroke logs existed to delete.
Infrastructure as Interview Simulation
The staging environment runs nightly chaos engineering: random WebSocket kills, 500ms latency injection, and TURN server blackholing. This originated from a production incident where a Kubernetes pod restart caused 23 seconds of audio desync—unrecoverable for interview flow. The fix involved session affinity via consistent hashing on interview_id, ensuring both signaling and media gateways routed to the same AZ.
Critical Design Decisions and Trade-offs
Decision: CRDTs over Strict Consensus for Session Metadata
- Rationale: Interview state (who joined, current phase) does not require linearizability. Eventual consistency across 300ms is imperceptible to users.
- Trade-off: Edge cases exist where both parties simultaneously mark the session "complete," triggering duplicate archival jobs. Mitigated via idempotent S3 writes with
interview_idas the key.
Decision: OT for Code Editor, CRDT for Chat
- Rationale: Code requires strict ordering (OT with central server as tiebreaker). Chat tolerates reordering (CRDTs allow local-first, merge later).
- Trade-off: Engineering overhead of two synchronization paradigms. Justified by the editor's role as the product's core differentiator.
Decision: Schema-Enforced Content Structure
- Rationale: SEO is not a feature but a distribution channel. Enforcing H2/H3 hierarchy at the API level prevents "content debt" where unstructured pages decay in search rankings.
- Trade-off: Content editors require technical onboarding. Countered by a WYSIWYG editor that auto-suggests schema compliance.
System Decomposition
| Component | Technology | Responsibility | SLO |
|---|---|---|---|
| Interview Session | Elixir/Phoenix | WebSocket lifecycle, state transitions | 99.99% availability |
| Code Editor | React + Monaco + OT Server | Real-time collaboration | <50ms latency for 95th percentile local echo |
| Media Gateway | Janus (WebRTC) | Video/audio routing, TURN fallback | <200ms relay latency |
| Content CMS | Next.js + PostgreSQL | Schema enforcement, rendering | Static generation, <100ms TTFB |
| Matching Engine | Python + Neo4j | Two-sided preference optimization | <500ms for candidate recommendations |
| Analytics Pipeline | Flink + S3 | Privacy-safe aggregation | 5-minute freshness |
常见错误与修正
| 反模式 | 症状 | 修正 |
|---|---|---|
| 将面试状态存储在客户端 | 刷新后状态丢失, 重复 booking | SessionState as server-side single source of truth |
| 通用内容页面无 schema | 搜索排名停滞, 高跳出率 | 强制 H2/H3 hierarchy, 内部链接图优化 |
| 录制原始视频流 | GDPR 审计失败, 存储成本激增 | 分段加密, 30 天 TTL, 仅聚合分析 |
| 单一 WebSocket 处理所有实时数据 | 代码编辑延迟影响 signaling | 分离数据平面 (code OT) 与控制平面 (signaling) |
一句话总结
Interviewing.io's architecture succeeds by treating the interview session as a state machine with graded degradation, the code editor as a latency-critical OT system, and content as a schema-rigid SEO asset—each optimized for its distinct failure mode and success metric.
Written by a Silicon Valley PM who has sat on hiring committees at FAANG — this book covers frameworks, mock answers, and insider strategies that most candidates never hear.
Get the PM Interview Playbook on Amazon →
FAQ
How many interview rounds should I expect?
Most tech companies run 4-6 PM interview rounds: phone screen, product design, behavioral, analytical, and leadership. Plan 4-6 weeks of preparation; experienced PMs can compress to 2-3 weeks.
Can I apply without PM experience?
Yes. Engineers, consultants, and operations leads frequently transition to PM roles. The key is demonstrating product thinking, cross-functional collaboration, and user empathy through your existing work.
What's the most effective preparation strategy?
Focus on three pillars: product design frameworks, analytical reasoning, and behavioral STAR responses. Mock interviews are the most underrated preparation method.