Software Engineer Interview Prep Guide

Use a hashmap plus a doubly-linked list for the base LRU. For the TTL extension, add a timestamp field to each node and either lazy-expire (check on access) or active-expire (background sweep). This two-part structure is one of the most common phone-screen prompts at Google and Amazon and tests your ability to extend a working solution under pressure.

Use a min-heap of size k for O(n log k) time, or QuickSelect for O(n) average. State the brute-force (full sort, O(n log n)) first — every senior interviewer judges your problem-decomposition discipline before they grade the optimal answer. Skipping the brute force is one of the top reported reasons strong candidates fail per Tech Interview Handbook.

Sort by start, then walk the list once and merge with the previous interval if start <= previous end. This is the canonical interval pattern that recurs across FAANG / mid-market loops. State the time complexity (O(n log n) dominated by sort) and call out the edge cases interviewers reward you for naming: empty list, single interval, fully nested intervals.

BFS or DFS over connected components, marking visited cells in-place. Discuss space/time trade-offs (DFS recursion uses stack space, BFS uses an explicit queue) and mention that for a streaming or memory-constrained variant you would use Union-Find. This pattern shows up in roughly 1 of every 6 onsite coding rounds per the Educative analysis of FAANG interview data.

Walk the universal 60-minute framework: clarify (5 min), capacity estimation (5 min — 100M/day → ~1.16K writes/sec, ~1B reads/sec at 100x read multiplier), high-level design (10 min), deep dive on Base62 encoding + collision handling + KV store sharding (20 min), bottlenecks at 10x scale (10 min), wrap (5 min). Show the arithmetic on the board — interviewers grade on whether you reason about scale in numbers, not adjectives.

Compare token bucket vs sliding window log vs sliding window counter, then pick one and justify. For distributed coordination, explain Redis with atomic INCR + EXPIRE, the fail-open vs fail-closed trade-off when Redis is unavailable, and proper 429 + Retry-After response semantics. The senior signal here is naming where state lives across N edge nodes — vague answers like "we use Redis" without explaining the partitioning strategy underperform.

Cover WebSocket connection management with sticky load balancing, message ordering guarantees (per-conversation sequence numbers vs Lamport timestamps), KV store for message history, push notifications for offline users, and read-receipt tracking. The differentiator at L5+ is explaining how offline messages get delivered in order across multiple devices — interviewing.io reports this as the most common follow-up that separates strong from weak senior candidates.

This reflects Meta's AI-assisted coding round introduced in late 2025, now spreading to other companies. The signal has shifted from "write code fast" to "verify, debug, and extend AI-generated code under time pressure." Read and understand the existing code first, use the AI for boilerplate but verify every line, and treat AI output like a junior PR — strong review discipline is the calibration signal. Practice with Cursor or Copilot before the loop, not after.

Pick one of two flagship projects with crisp metrics (latency, scale, revenue, model quality, deployment velocity). Practice a 3-minute walkthrough plus 15 minutes of follow-up depth. Be ready to explicitly call out what you'd do differently — per multiple FAANG hiring-manager guides, "I'd do everything the same" reads as a junior-mindset signal. The hiring-manager screen is calibrating whether your scope matches the level you're applying for; vague ownership ("we built…") gets you downleveled.

Frame as a technical disagreement, not a personality clash. Show your framing of the trade-off, how you built the case (doc, data, prototype), the resolution, and the relationship after. Avoid villainizing the other person. The strongest senior signal is naming the specific trade-off you debated (e.g., "we were choosing between async eventual consistency and synchronous strong consistency for the payments path") — interviewers grade you on trade-off vocabulary, not on who "won."

Specifics on how you built the case: a one-page design doc shared with N stakeholders, a prototype that derisked the riskiest assumption, a written argument against an alternative. "I gave feedback" is vague; "I wrote a 4-page doc, presented at the architecture review, addressed two staff-level objections in writing, and 3 of 4 affected teams committed by week 4" is the senior calibration. This archetype is decisive at L5+ where ownership-without-authority is the actual day-to-day work.

Show calm decomposition under pressure. Cover: how you triaged, the explicit decision to mitigate vs root-cause first, blast radius (users affected, revenue impact, duration), the postmortem changes you drove (specific runbook, alert, or architectural change). The senior signal is naming what you changed structurally afterward — the post-incident review template you authored, the SLO you established, the on-call rotation policy you proposed. Hero narratives ("I stayed up all night and fixed it") underperform structural-change narratives.

Demonstrate structured debugging. First check whether it's a measurement issue (instrumentation change, recent deploy). Then segment by geography, device, and user cohort. Check recent deployments and rollbacks. Review dependency health dashboards. Build a hypothesis tree and systematically eliminate branches. Tested at Meta and Google to evaluate how you handle ambiguity and use data to drive decisions — diving into solutions before clarifying is the most common reason strong candidates underperform on this prompt.

Show the bias-to-action with safety nets. Walk the decision tree: (1) confirm the bug reproduces and isn't a misuse; (2) measure the blast radius — does the workaround block 10% or 100% of the path; (3) decide between forking the dependency, monkey-patching with a feature flag, or escalating to the dependency owner; (4) name the explicit trade-off you accept (e.g., "I patched at the call site behind a flag, accepting tech debt that we tracked in JIRA for paydown the following sprint"). Naming the trade-off explicitly is the senior calibration.

Discuss readability and maintainability, adherence to existing patterns, performance implications at scale, security vulnerabilities (injection, auth bypass), test coverage and test quality, error handling and observability. Mention how you give constructive feedback: lead with questions rather than directives, explain the why behind suggestions, acknowledge good patterns. The senior calibration is naming the operational dimensions (observability, on-call ergonomics) that junior reviewers skip.