Google Software Engineer Interview Prep Guide

Your heaviest focus is expression parsing, caching/eviction, graph/grid algorithms, DP, and Google-scale distributed storage because your selected focus areas and shaky/new concept ratings line up there. You're solid on API basics, auth/rate limiting, WebSocket lifecycle, delivery semantics, and several BFS grid variants, so those stay as review rather than from-scratch study. For Google, this plan highlights distributed storage/messaging consistency, idempotent delivery, large-input/log processing, and reliability/observability follow-ups that often extend coding and design rounds. With one month and no solved-question signal yet, aim for repeated timed practice across the emphasized concepts while using normal-weight topics as maintenance.

Technical Screen — 75 min

Coding & Algorithms

• Expression Parsing and Evaluation for Google Coding (Focus) — covered in depth under Online Assessment below.

• Core Array, String, Hash Map, Sliding Window, and Binary Search Patterns (Focus) — covered in depth under Online Assessment below.

• Trie and Prefix Indexing (Focus) — covered in depth under Onsite below.

• BFS/DFS Graph and Tree Traversal and Shortest Paths (Focus) — covered in depth under Onsite below.

• Dynamic Programming and State-Space Optimization (Focus) — covered in depth under Online Assessment below.

System Design

• Caching and Eviction for Google-Scale Services (Focus) — covered in depth under Onsite below.

• Secure Distributed Storage, Messaging, and Consistency (Focus) — covered in depth under Onsite below.

Software Engineering Fundamentals

• Concurrency, Scheduling, and State Machines (Focus) — covered in depth under Onsite below.

• Reliability, Observability, and Incident Diagnostics (Focus) — covered in depth under Onsite below.

Behavioral & Leadership

• Behavioral Leadership, Ownership, and Stakeholder Management (Focus) — covered in depth under Onsite below.

Onsite — 75 min

Coding & Algorithms

• Expression Parsing and Evaluation for Google Coding (Focus) — covered in depth under Online Assessment below.

• Core Array, String, Hash Map, Sliding Window, and Binary Search Patterns (Focus) — covered in depth under Online Assessment below.

Focus area — Trie/prefix tree is marked shaky and matches your string/prefix focus, so review node invariants and exact-word versus prefix behavior.

What's being tested

Tests construction and use of a Trie (prefix tree) for efficient prefix indexing, exact-word lookup, and longest-prefix matching. Interviewers probe correctness (terminal vs. prefix), per-node metadata for fast top-K or frequency-aware queries, and time/space complexity tradeoffs.

Patterns & templates

• insert / search — traverse nodes per character, create child nodes as needed; O(L) time, O(1) extra space beyond nodes, where L is word length.

• Terminal flag vs. prefix — store is_end boolean and optionally an exact-word payload to distinguish words from mere prefixes.

• Per-node metadata — keep count, freq, or topK list at nodes to answer aggregate queries in O(L + K) time. Update these during insert/delete.

• Children representation — use hash map for variable alphabet or fixed array for small alphabets; memory ~O(total_chars) nodes × child-pointer-size.

• Lazy deletion — clear is_end and decrement metadata; prune nodes only when safe to avoid expensive recursive deletes.

• Longest-match replacement — greedy scan: advance as long as matching child exists and track last is_end; overall O(N + M) for text size N and average match M per start.

• Collect/top-K traversal — DFS from prefix node, early-stop with maintained heap for K best; complexity O(nodes_in_subtrie + K log K).

Common pitfalls

Pitfall: Treating every node with children as a word—forgetting to check is_end leads to false positives for exact search.

Pitfall: Failing to update per-node topK on deletes/updates, causing stale suggestions.

Pitfall: Assuming constant alphabet; using fixed arrays for large Unicode input wastes memory.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — You selected graph algorithms and grid traversal; Dijkstra, topo sort, Union-Find, and SCCs are shaky.

What's being tested

Candidates must demonstrate correct use of BFS and DFS for traversal, reachability, and component counting, plus shortest-path techniques (unweighted BFS, Dijkstra) under constraints. Interviewers probe algorithmic tradeoffs (time/space), correctness with blocked/forbidden nodes, and iterative vs recursive implementations to avoid stack overflow.

Patterns & templates

• BFS for shortest paths in unweighted graphs — use deque queue, mark visited on enqueue, time O(V+E), space O(V).

• DFS (recursive or explicit stack) for connectivity and nested structures; prefer iterative stack to avoid recursion depth issues.

• Dijkstra with heapq for weighted shortest paths; complexity O((V+E) log V); store distances and parents for path reconstruction.

• Multi-criteria shortest path: encode tuple cost (danger_count, steps) and use lexicographic comparison in priority queue or use 0-1 BFS for binary costs.

• Remove/ignore blocked nodes by pre-marking in set or deleting adjacency entries before traversal.

• Connected clusters (geometric): build adjacency by threshold distance squared to avoid sqrt, deduplicate coordinates with a set, then BFS/DFS for components.

• Deleting in a binary search tree: handle leaf, single-child, two-children cases — replace with inorder successor (min in right subtree) and adjust pointers.

Common pitfalls

Pitfall: Marking visited only on pop instead of on enqueue causes duplicate enqueues and exponential blowup on dense graphs.

Pitfall: Using sqrt for many distance checks costs CPU and risks floating error — compare squared distances instead.

Pitfall: Recursing on deeply nested lists/trees without converting to an iterative stack risks stack overflow on large inputs.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

• Dynamic Programming and State-Space Optimization (Focus) — covered in depth under Online Assessment below.

System Design

Focus area — You selected caching/eviction; LRU, LFU, TTL, stampede mitigation, and adaptive eviction are all shaky.

What's being tested

Interviewers probe your ability to design and reason about high-throughput, low-latency caching systems: selecting eviction policies, ensuring correctness under concurrent updates, sizing and sharding caches, and preventing cache-related reliability incidents at scale. Google cares because caches are critical to reduce backend load, control tail latency (p99), and lower cost; the interviewer wants to see tradeoff-driven engineering, measurable SLAs, and safe operational practices.

Core knowledge

• Cache hit rate and miss rate: define hit rate = hits / (hits + misses). Small improvements in hit rate can produce large backend load reductions; quantify expected backend QPS reduction given hit-rate delta.

• Cache architectures: know cache-aside, write-through, and write-back semantics and failure modes; cache-aside is common for reads-heavy workloads, write-through simplifies durability at the cost of write latency.

• Eviction policies: understand LRU, LFU, CLOCK, ARC, and TinyLFU; LRU is simple, LFU excels with skewed access, TinyLFU combines admission with eviction to avoid polluters.

• Working set vs capacity: identify working-set size W relative to capacity C; if W >> C expect thrashing and low hit rates. Instrument to measure approximate W and tail-frequency distributions (e.g., Zipf).

• Distributed caching & sharding: use consistent hashing for node membership churn; shard by key to avoid cross-node coordination. Account for rebalancing cost proportional to moved key bytes.

• Replication & consistency: for read-replicas, choose between eventual consistency with TTL or synchronous invalidation; for strong consistency, prefer single-writer or versioned invalidation tokens (generation numbers).

• Cache invalidation patterns: know time-based TTL, explicit invalidate-on-write, and hybrid approaches. Invalidation races lead to stale reads; using monotonically increasing version or compare-and-set reduces races.

• Cache stampede & mitigation: mitigate thundering herd with request coalescing, singleflight, probabilistic early recompute, or client-side locking; use jittered TTL to avoid synchronized expirations.

• Admission filtering & Bloom filters: reduce backend misses with Bloom filters to block requests for known-missing keys, but account for false positives and memory tradeoffs: false-positive rate ≈ (1 − e^(−k n / m))^k.

• Eviction engineering at scale: track eviction rate, cold-start cost, and tail-latency impact; tune eviction in presence of hot keys via explicit pinning or hot-key bypass to single-tenant caches.

• Instrumentation & SLOs: collect hit_rate, miss_lat, evictions/sec, and cache_fill_time; SLOs commonly target p99 read latency and a minimum hit-rate for backend protection.

Worked example — "Design a distributed cache for session data with eviction and strong consistency"

First 30s: ask workload questions — read/write ratio, session size, TTL expectations, consistency needs (strict read-after-write?), failure SLAs, and traffic patterns (burstiness, hot keys). Skeleton answer pillars: (1) data model: store session token → small JSON, keep version number for concurrency; (2) architecture: cache-aside with write-through for critical updates or cache-aside + synchronous invalidation if low write volume; (3) distribution: consistent-hash shards, optional replication for availability; (4) eviction: TTL per-session plus LRU within shard, pin authenticated sessions briefly to avoid premature eviction; (5) reliability: singleflight for refreshes, use compare-and-swap on writes to avoid stale overwrite. Tradeoff to flag: choosing write-through increases write latency and backend load consistency but simplifies correctness; cache-aside yields lower write latency but requires careful invalidation to avoid stale reads. Close by proposing measurable benchmarks (simulate 95th/99th percentile latency under production QPS), and if more time, implement load tests, heap/GC tuning on cache nodes, and an automated rebalancer that moves only cold keys.

A second angle — "Design a CDN-like cache for serving user avatars with TTL and global invalidation"

Same core concepts apply but constraints differ: traffic is extremely read-heavy, objects are larger, and eventual consistency is acceptable for most updates. Use long TTLs with Cache-Control headers, CDN edge caching, and origin invalidation API for user-initiated updates. Eviction becomes LRU within edge node capacity; apply range or object-size aware eviction to avoid evicting many small hot objects for a single large object. Use conditional GETs (ETag/If-Modified-Since) to reduce origin load. Mitigations: background cache-warming on expected changes, and a purge API that propagates invalidation asynchronously with versioning to prevent stale windows.

Common pitfalls

Pitfall: Treating eviction policy as the only knob.
Designers often focus on LRU/LFU but ignore admission filtering, working-set measurement, and hot-key handling; this leads to suboptimal hit rates and tail latency.

Pitfall: Not asking about read/write patterns and error budgets.
Failing to clarify whether strong consistency is needed causes wrong choices between write-through and cache-aside, exposing race conditions or unnecessary latency.

Pitfall: Over-optimizing per-node LRU without addressing rebalancing cost.
Ignoring consistent-hash churn or large-object movements during node scaling produces high network IO and transient misses; plan for incremental rebalancing and tooling.

Connections

Interviewers may pivot to load balancing and partitioning, database transaction isolation vs cache consistency, or rate limiting / backpressure to protect a backend when cache miss spikes occur. Be ready to tie caching decisions to capacity planning and SLO tradeoffs.

Further reading

• [Designing Data-Intensive Applications — Martin Kleppmann] — strong chapters on caching patterns, replication, and consistency tradeoffs.

• Redis Labs: Caching Design Patterns — practical operational patterns and pitfalls for large-scale caches.

Practice questions

Focus area — You selected sharding, API design, transactions, and messaging; LSM trees, quorums, CAS, and Bloom filters need first-principles review.

What's being tested

Candidates must show practical mastery of designing scalable, durable, and consistent distributed storage and messaging systems: partitioning, replication/consensus, durability vs latency tradeoffs, client-facing APIs, and multi-tenant operational concerns. Interviewers probe whether you can frame correctness constraints (ordering, delivery semantics, isolation), pick appropriate algorithms (consensus, MVCC, CAS), and justify tradeoffs for availability, performance, and cost in realistic failure modes. They also expect concrete engineering choices — data models, garbage collection, metadata placement, and how to observe and recover systems.

Core knowledge

• Partitioning (sharding): split data by key to scale throughput; choose consistent hashing or range partitioning depending on hot-key risk; each partition should be independently replicated and rebalanced.

• Replication & consensus: use leader-follower (e.g., Kafka) for high-throughput append logs or quorum consensus (RAFT, Paxos) for strong consistency; quorum = $\lfloor n/2\rfloor+1$ for n replicas.

• Durability & storage tiers: persist writes to WAL/append-only segments on local SSD, then tier cold objects to object stores (S3); segment sizes commonly 100MB–1GB for efficient compaction and recovery.

• Delivery semantics: clearly separate at-least-once, at-most-once, exactly-once; exactly-once typically requires idempotency + transactional writes (two-phase commit or idempotent producer with sequence numbers).

• Ordering & offsets: order guarantees usually per-partition; store consumer offsets in a durable, low-latency store (etcd/Zookeeper/internal offsets topic); allow manual/automatic offset management for replay.

• Deduplication & content-addressable storage: map content to hash-based IDs (e.g., SHA-256) for dedup; use reference counts or reachability GC; avoid counting race conditions with atomic CAS or distributed transactions.

• Large-payload handling: keep metadata in the log/queue and store large blobs in object store; pass pointers in messages to avoid broker memory spikes.

• Retention & compaction: support time/size-based retention and log compaction for latest-key semantics; compaction is CPU and IO heavy — plan background compaction windows and backpressure.

• Transactions & isolation: distributed transactions use coordinated commit (2PC) or transactional log with multi-writer epochs; prefer application-level idempotency or single-partition transactions to avoid cross-partition 2PC complexity.

• Authentication, authorization, encryption: require mutual TLS (mTLS) at the transport, RBAC for tenant isolation, and encryption-at-rest for sensitive blobs; keep token lifetimes short and log access-control decisions for audit.

• Monitoring & SLOs: instrument p99/p95 latency, throughput, tail-recovery time, replication lag, and GC pauses; SLOs drive choices: e.g., synchronous replication increases p99 but improves durability.

• Failure & recovery playbooks: design for fast leader failover, replica catch-up, and safe truncation; ensure metadata (topic list, partition assignment) is itself replicated and versioned.

Worked example — Design distributed message queue service

First 30s framing: ask about expected throughput, latency SLOs, message size distribution, ordering guarantees (global vs per-topic-partition), retention semantics, multi-tenancy, and exactly-once needs. Declare assumptions: per-partition ordering is OK, message sizes small (<1MB), throughput 100k msgs/sec per topic.

Skeleton pillars to present:

1. API model: Publish(topic, key, payload) and Subscribe(topic, partition) with consumer-group semantics and offset commit API.
2. Partitioning & routing: consistent hashing on key → partition to provide per-key ordering and balance.
3. Durability & persistence: append-only segmented logs on local disks, immediate fsync for durability when required, async replication.
4. Replication & failover: leader-follower per partition with RAFT-style majority for critical topics and configurable replication factor for others.
5. Consumer offset & delivery semantics: offsets stored durably; support at-least-once by default, exactly-once via idempotent producers + transactional commit for consumer offsets.

One concrete tradeoff: synchronous replication guarantees durability but increases end-to-end latency; offer topic-level policy to choose sync vs async replication. For large payloads, use pointers to external object store to prevent broker memory/IO explosion.

How to close: summarize SLOs and deployment assumptions, mention operational concerns (compaction windows, monitoring), and say "if I had more time I'd design the metadata service, simulate leader failover scenarios, and sketch client retry/backoff and quota enforcement."

A second angle — Design distributed transactions protocol

The same fundamentals (consensus, durable logs, coordination) apply but constraints shift: cross-shard atomicity demands a coordination protocol. For small-scale, prefer single-partition transactions to avoid distributed commit. For cross-partition, present coordinator-based 2PC built on a replicated log plus leader election; reduce blocking using optimistic concurrency control or cohort-prepared leasing and use timeouts and idempotent commit records to recover. Call out costly failure modes: coordinator crash leaves prepared state requiring careful GC. Tradeoffs: 2PC gives atomicity but sacrifices availability; consider sagas for looser consistency with compensating actions.

Common pitfalls

Pitfall: Designing for global total ordering by default. Total ordering across all keys kills scalability; prefer per-partition ordering and explain why the app actually needs global order.

Pitfall: Ignoring metadata scalability. Storing topic/partition metadata in a single node becomes a bottleneck; design metadata as a small replicated service and quantify limits (metadata ops/sec, number of partitions).

Pitfall: Over-promising exactly-once without implementation detail. Saying "we support exactly-once" without explaining idempotent producers, sequence numbers, and atomic offset commits will lose credibility; show the mechanism (transactional writes + offset commit).

Connections

Interviewers may pivot to adjacent topics like stream processing (stateful processing and time semantics), object storage design (cold-storage lifecycle and GC), or multi-region replication (geo-consistency models and conflict resolution). Be ready to discuss monitoring/playbooks and cost tradeoffs (e.g., hot-spot mitigation vs replication cost).

Further reading

• [Designing Data-Intensive Applications, Martin Kleppmann] — deep treatment of logs, replication, consensus, and transactions.

• The Kafka Papers & Confluent Blog — practical patterns for log-based messaging, partitioning, and storage tradeoffs.

Practice questions

Software Engineering Fundamentals

Focus area — Your fundamentals rating is 2/5 and you selected distributed job scheduling, performance, debugging, and resilience.

What's being tested

These problems test building and reasoning about an async primitive (like CompletableFuture) and scheduling: safe callback registration, correct completion state machine, and efficient timer/task multiplexing onto a thread-pool. Interviewers probe race-free state transitions, cancellation, ordering guarantees, and scalable timer/scheduler data structures.

Patterns & templates

• State machine with explicit states (e.g., PENDING → COMPLETING → COMPLETED/FAILED/CANCELLED) and a single CAS transition per completion to avoid races.

• Callback list appended atomically with compareAndSet and drained by the thread that wins completion, avoiding locking on hot path.

• Use volatile for result/state visibility and minimal locking; prefer lock-free for low-latency futures, fallback to short critical sections when necessary.

• Implement timers with a min-heap priority queue for correctness, or a timer wheel for large-scale (~10^6 timers) amortized O(1) ticks.

• Use ForkJoinPool / work-stealing for parallel array processing; prefer divide-and-conquer recursively to maximize locality and CPU utilization.

• Cancellation: mark state then attempt to remove scheduled tasks; for heap-based timers, use lazy deletion flags to avoid O(n) removals.

• Batch wakeups: coalesce scheduled callbacks and run them on a worker thread (execute()), avoid running user callbacks under internal locks to prevent deadlocks.

Common pitfalls

Pitfall: Failing to make state transitions atomic leads to double-completion or lost callbacks when two threads try to complete concurrently.

Pitfall: Running user callbacks while holding internal locks causes deadlocks or long GC pauses; always invoke callbacks outside locks.

Pitfall: Assuming notify() without rechecking condition — handle spurious wakeups and always loop on the predicate when using wait()/notify().

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — You selected observability/logging/metrics and rated fundamentals 2/5, so emphasize diagnosis, SLOs, and incident thinking.

What's being tested

Interviewers expect you to demonstrate practical reliability engineering judgment: define measurable service health, design observability that surfaces real faults, and run diagnostics that map telemetry to root causes. They want concrete tradeoffs (cost vs. coverage, signal-to-noise), familiarity with distributed consistency and replication failure modes, and an incident-driven troubleshooting approach. For a Software Engineer role, focus on designing and instrumenting the service, choosing SLI/SLO targets, reasoning about alert thresholds, and proposing safe remediation paths—not organizational or SRE team staffing.

Core knowledge

• SLI / SLO / SLA — an SLI is a measurable signal (e.g., p99 latency); an SLO is a target for that SLI over a window; an SLA is a contractual penalty tied to SLO violations and error budget consumption.

• Error budget math — error_budget = 1 − SLO (e.g., 99.9% availability → error_budget = 0.001); use rolling windows and partition by customer tier when enforcing.

• Latency percentiles — prefer p50/p95/p99 for user-impact; calculate percentiles on aggregated distributions (HDR histograms) to avoid misinterpretation from averages.

• Metrics vs logs vs traces — metrics are numeric time-series for alerting, logs for event detail and forensic search, traces for request causality; instrument with correlation IDs for cross-signal joins.

• Instrumentation primitives — use client-side and server-side timers, structured JSON logs, and distributed context propagation (trace-id, span-id); expose metrics via Prometheus-compatible endpoints or push gateways.

• Alerting strategy — prefer alerting on symptoms with automated noise-reduction (rate-limited, aggregation windows, dynamic baselines); avoid alerting on single-instance internal counters unless they imply customer impact.

• Health checks & readiness — implement separate liveness and readiness probes; readiness gates for in-flight migrations and leader elections prevent traffic to partially initialized nodes.

• Replication & consistency — know leader-based replication (e.g., Raft, etcd) and leaderless quorum models (e.g., Dynamo-style with vector clocks), and root causes like split-brain, stale reads, and write reordering.

• Diagnostics signals — correlate replication_lag, commit-index, election-count, GC pauses, CPU steal, syscall errors, and network RTT; sudden divergence patterns often point to networking or leader mis-election.

• Automated remediation patterns — safe steps: circuit breakers, traffic-shaping, progressive rollbacks (canaries), and self-healing (auto-restart) with kill-switches and manual override paths documented in runbooks.

• Cost/coverage tradeoff — high-cardinality traces and logs are expensive; use sampling, adaptive tracing, and retain raw logs for a short time while long-term aggregates and derived metrics persist.

• Post-incident hygiene — capture timeline, hypotheses tried, root cause, corrective action, and follow-ups; quantify operational impact in SLI terms and update SLOs or instrumentation gaps accordingly.

Worked example — Explain SLI/SLO/SLA and design monitoring

Frame: start by clarifying user-visible actions and tenants — "Which API calls define customer experience? Are there tiers with different availability promises?" Declare assumptions about request routing, data consistency, and acceptable windows.

Pillars: (1) choose 3–5 core SLIs (successful request rate, p99 latency, error-rate by endpoint), (2) set SLOs per user-impact and business tolerance (e.g., 99.9% p99 latency over 30 days), (3) design alerting and dashboards that map SLI breaches to runbooks and escalation, (4) define automated short-term remediation (circuit breaker) and rollback policy.

Tradeoff: explicitly discuss balancing alert sensitivity vs. noisy paging — choose a multi-tier alert scheme (actionable page for customer-impacting SLO breach; internal tickets for degradations).

Close: state how you'd validate—run chaos tests, synthetic traffic, and measure alert precision; "If I had more time, I'd add per-customer SLI aggregation and adaptive alerts using short-term anomaly detection."

A second angle — Diagnose distributed database inconsistency

This framing shifts emphasis to low-level replication telemetry: first ask which consistency model the system promises (strict serializability vs. eventual). Organize diagnostics around (1) leader health and election logs, (2) replication offsets / watermark comparisons across replicas, (3) client-side write-path tracing and idempotency keys, and (4) network partitions and clock skew metrics.

A strong answer argues for safe mitigation: stop accepting writes to suspect partition, promote stable replica, or perform controlled reconciliation using deterministic merge or compensation operations. Highlight tradeoffs between consistency repair cost and customer-visible rollback: sometimes serving stale reads is preferable to data loss; other times write-rollback with reconciliation is better.

Common pitfalls

Pitfall: Confusing symptom and root cause.

Many candidates jump to "scale more" when p99 spikes, whereas root causes are often latency amplification from a downstream dependency or GC pauses; always correlate traces, GC, and network metrics before capacity actions.

Pitfall: Designing alerts on internal counters.

Alerting on a single queue-length or thread-count without mapping to user-facing SLI causes pager fatigue; instead alert on user-visible degradation and attach internal counters to the dashboard for diagnostics.

Pitfall: Overengineering remediation.

Proposing fully autonomous rollback with no human-in-loop is tempting, but neglects blast-radius controls; prefer staged automation (canary, circuit-breaker, manual escalation) and explicit abort criteria.

Connections

Interviewers may pivot to capacity planning (load forecasting, autoscaling policies), security & multi-tenancy (isolation of telemetry and remediation), or deeper distributed-systems theory (consensus algorithms, clocks, and anti-entropy). Be prepared to connect monitoring decisions to deploy processes and CI/CD safeguards.

Further reading

• Site Reliability Engineering (Google SRE book) — practical guidance on SLI/SLO, incident response, and postmortems.

• Designing Data-Intensive Applications by Martin Kleppmann — solid coverage of replication, consistency models, and repair strategies.

Practice questions

Behavioral & Leadership

Focus area — You selected conflict, impact communication, prioritization, failure, and ownership; prepare Google-style evidence-backed stories.

What's being tested

Interviewers are probing your ability to take ownership of a technical area while managing ambiguity, tradeoffs, and multiple stakeholders. They want to see clear problem framing, evidence-based tradeoff analysis, pragmatic delivery plans (including risk mitigation), and effective communication under pressure. For a Software Engineer this means demonstrating technical judgment that leads to shipping reliable code, resolving incidents, and aligning cross-functional partners without delegating the engineering responsibilities you own.

Core knowledge

• Ownership vs. accountability: Ownership means owning technical decisions, rollout, monitoring, and remediation; accountability is accepting follow-through until metrics show recovery or launch success.

• Clarifying goals fast: Ask for the success metric (e.g., p95 latency, error rate, adoption %, revenue impact), the deadline, and non-negotiable constraints (privacy, compliance, infra limits).

• Stakeholder map: Identify approvers, implementers, and consumers; capture names, acceptance criteria, and communication cadence in a one-page decision log or RFC.

• Risk assessment formula: Use Risk = Probability × Impact; quantify impact (user count, revenue/hour, SLA penalty) and use it to prioritize fixes vs. features.

• Incremental delivery patterns: Use feature flags, canary rollout, and progressive exposure to limit blast radius; require rollback plan and quick toggle in Git-driven CI/CD.

• Observability and SLOs: Define dashboards and alerts tied to SLO/SLA and p99/p95 metrics; ensure alerts map to on-call via PagerDuty and have runbooks.

• Incident & postmortem hygiene: Run blameless postmortems, list corrective actions with owners and deadlines, and track them in JIRA. Include root cause, contributing factors, and time-to-detect/repair.

• Tradeoff language: Frame decisions as three-part: benefit, cost (engineering/time/opportunity), and mitigation. Quantify when possible (e.g., "adds 2 engineer-weeks, reduces error rate by 60%").

• Communication primitives: Use asynchronous docs (Google Docs/RFC) for detailed tradeoffs, short syncs for alignment, and single-owner status updates for escalation; summarize decisions in a TL;DR at top.

• When to escalate: If risk > threshold (e.g., potential customer-facing outage or >X% revenue impact), escalate to product or SRE managers immediately; otherwise handle within the squad with clear checkpoints.

• Code-quality gates: Define minimal acceptable CI checks (unit tests, linters, integration smoke) and when to accept tech debt with a remediation timeline.

• Ambiguity tactics: Propose explicit assumptions, prototype the riskiest unknown for one sprint, and agree on acceptance criteria to prevent rework.

Worked example — "Answer leadership and ambiguity scenarios"

First 30 seconds: ask for the measurable outcome ("which metric moves define success?"), timeline, and constraints (privacy, infra, dependent teams). Declare assumptions you will use if not specified (e.g., "assume existing API throughput handles +30% load"). Structure your answer around three pillars: (1) clarify and scope — write a one-paragraph objective and list open questions; (2) build & mitigate — deliver a minimal increment behind a feature flag with monitoring and rollback; (3) align & communicate — convene stakeholders for an initial decision and send an RFC summarizing choices and risks. Call out a central tradeoff explicitly: speed-to-production vs. long-term maintainability — choose incremental delivery if you must meet a deadline, but require a follow-up tech task to eliminate temporary scaffolding. Close by stating next steps and what you'd do with more time: broaden tests, run load tests, and coordinate a staged rollout with PagerDuty runbook updates.

A second angle — "Answer leadership and quality tradeoff questions"

The same framing applies but the emphasis shifts to explicit quality thresholds: begin by quantifying acceptable risk (e.g., target p99 latency and minimum test coverage). Use the risk formula to justify cutting scope: prefer shipping a narrower feature with strong observability and rollback capability over a full-featured release with brittle tests. Propose a temporary mitigation (rate limit, circuit breaker) and a technical debt ticket with priority and estimated cost. In negotiation, offer concrete alternatives and associated timelines so stakeholders choose based on quantified tradeoffs rather than abstract assurances.

Common pitfalls

Pitfall: Focusing solely on the technical solution and ignoring stakeholder alignment.

If you produce a great technical plan but haven't secured stakeholder buy-in, the project stalls or gets blocked. State who needs to approve what, surface tradeoffs early, and propose a sync cadence so technical work and stakeholder expectations remain aligned.

Pitfall: Claiming unconditional ownership without delegation or follow-through.

Ownership isn't doing everything alone — it's making clear who owns which subtasks and tracking them until resolution. Use JIRA tickets with owners and due dates; escalate only when commitments miss agreed checkpoints.

Pitfall: Over-engineering to avoid ambiguity.

Building a full solution to remove all unknowns wastes time. Instead, prototype the riskiest unknown, iterate, and use feature flags and canaries to reduce blast radius while you refine the design.

Connections

Interviewers can pivot into incident response and SRE practices (runbooks, SLO design), system design tradeoffs (latency vs. throughput), or cross-team influence topics (how you get alignment without authority). Demonstrating fluency in those adjacent areas makes your behavioral answers more actionable.

Further reading

• Site Reliability Engineering (Google SRE book) — practical guidance on incident response, SLOs, and blameless postmortems.

• Accelerate (DORA) — evidence on delivery metrics, tradeoffs between speed and stability, and measurable engineering performance.

Practice questions

Online Assessment — 18 min

Coding & Algorithms

Focus area — You marked shunting-yard and two-stack evaluation new, with parser and unary-operator handling shaky.

What's being tested

Expression parsing and evaluation problems test your ability to tokenize input, apply operator precedence and associativity, and produce a correct evaluation plan (either AST or stack-based). Interviewers probe for robust handling of edge cases (unary operators, whitespace, parentheses) and for an algorithmic solution with clear time/space bounds.

Patterns & templates

• Shunting-yard algorithm — convert infix to Reverse Polish Notation (RPN) in O(n) time, using an operator stack and output queue.

• RPN evaluation — single-pass stack-based evaluator: push numbers, pop operands on operator, O(n) time and O(n) extra space.

• Recursive descent parser — implement grammar functions like parseExpression, parseTerm, parseFactor to respect precedence and parentheses.

• Pratt / precedence-climbing parser — compact alternative to recursive descent for many precedence levels, avoid duplicating code per level.

• Tokenizer / lexer — produce numeric tokens, operators, parentheses; handle multi-digit numbers, decimals, and identifiers if needed.

• Unary vs binary handling — detect unary minus/plus by previous token type (start, (, or operator), treat as high-precedence unary operator.

• AST construction — build nodes (Op, Num) if transformations or repeated evaluations needed; evaluate via post-order traversal.

• Precision & types — decide integer vs floating semantics up front; use long/BigInteger or decimal libraries for overflow/precision guarantees.

Common pitfalls

Pitfall: Confusing unary and binary minus — treat -3 and a - 3 differently when tokenizing/parsing.

Pitfall: Wrong associativity for exponentiation — ^ is usually right-associative; mishandling produces incorrect results.

Pitfall: Not validating tokens/stack state — failing to detect malformed expressions leads to crashes or silent wrong answers.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — You picked string parsing; sliding-window substrings are shaky and KMP/Rabin-Karp are new, so foundational string/hash patterns deserve extra reps.

What's being tested

These problems test frequency-counting and anagram/signature reasoning for strings, efficient sliding-window checks over substrings, and membership lookups using hash maps. Interviewers probe algorithmic choices (O(n) vs O(n·k)), correct edge-case handling, and clean iteration/parsing for large inputs.

Patterns & templates

• Sliding window on contiguous substrings — O(n) two-pointer expand/contract; maintain counts and window invariants to avoid re-scanning.

• Frequency signature via fixed-size arrays or Counter — store counts as tuples or serialized keys for O(1) comparison on alphabet-limited strings.

• Hash set / map for membership — pre-hash dictionary words or signatures to get average O(1) membership tests during enumeration.

• Bitmask / digit mask for digits 0–9 — represent presence with a 10-bit int, enabling O(1) union/intersection checks across numbers.

• Two-pointer on arrays for monotonic constraints — move left/right and maintain aggregate (sum/count) for O(n) feasibility checks.

• Binary search over answer space — convert "max size" questions to monotone predicate, run O(n) check per mid for total O(n log n).

• Single-pass string parsing for snake_case→camelCase — build result in-place, handle separators and capitalization in O(n) time and O(1) extra space.

Common pitfalls

Pitfall: Comparing full count arrays per window naïvely makes algorithms O(n·k); instead update counts incrementally on pointer moves.

Pitfall: Forgetting to canonicalize signatures (order or normalized tuple) causes false negatives when checking anagram membership.

Pitfall: Not validating separators/edge cases (empty string, consecutive underscores) in parsing tasks leads to incorrect outputs or crashes.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — Grid DP and edit distance are shaky, and DP appears in both screen and online assessment.

What's being tested

These problems test state-space modeling and dynamic programming (DP): defining compact states, transitions, and value propagation under movement and collision constraints. Interviewers probe whether you can exploit invariants (e.g., modulo classes, symmetry) to reduce exponential state blowup and choose the right search/optimization primitive (memoized dfs, bottom-up dp, bfs, or dijkstra).

Patterns & templates

• Bitmask DP for small numbers of tokens — represent occupied cells as bits; typical complexity O(states * transitions) and memory O(2^k * n).

• Canonical ordering: sort token positions (or canonicalize symmetric states) to avoid counting permutations; reduces state-space by k! when tokens indistinguishable.

• Modular invariants: reduce positions using modulo classes (e.g., moves of +3 preserve pos % 3), immediately discarding unreachable targets.

• Use top-down memoization (dfs + cache) for sparse reachable state graphs; bottom-up dp when transition ordering is clear and states dense.

• For weighted single-path problems, use Dijkstra with heapq for min-cost; store predecessor to reconstruct lexicographically tiebroken paths.

• Use BFS for reachability or shortest-step counts on unweighted graphs; complexity O(V+E).

• Tip: prune states with an upper-bound heuristic (e.g., remaining coins max) to speed search when exact optimum needed.

Common pitfalls

Pitfall: Treating identical tokens as distinct causes factorial state explosion; canonicalize positions to collapse equivalent permutations.

Pitfall: Ignoring movement invariants like pos % step == constant leads to wasted work on unreachable states and wrong feasibility answers.

Pitfall: Assuming greedy local coin collection is optimal; without proof, fallback to DP/search and justify complexity tradeoffs.

Practice these

the practice cards below cover the canonical variants — solve all of them and time yourself

Practice questions