In-Memory Key-Value Store (multi-part CodeSignal assessment): Part 1 — implement get, set, delete, update. Part 2 — add scan_keys and scan_keys_with_prefix. Part 3 — add set_with_ttl and update_with_ttl so keys expire. Part 4 — add undo and redo operations.

The key insight is that each part extends the previous one; design the data structure cleanly upfront (a dict plus a sorted structure for prefix scanning, a heap or timestamp map for TTL, and a command-history stack for undo/redo). Parts 1-2 are O(k) where k is matching keys; TTL expiry on reads is O(log n) with a heap; undo/redo is a two-stack pattern. The most common follow-up is: how would you make TTL expiry lazy vs. eager, and what are the trade-offs? OOP discipline and SOLID principles — the interviewer wants clean class design, proper encapsulation, and code that is easy to extend. Speed and correct test-case passage on each level matter because failure blocks the next part.

Interleaving / ZigZag Iterator (multi-part onsite coding round): Part 1 — given two arrays, return elements in interleaved order (e.g., [1,2,3] and [4,5,6] gives [1,4,2,5,3,6]). Part 2 — generalize to n lists (similar to LeetCode 281 Zigzag Iterator but for n lists). Part 3 — design a range-based iterator that takes start, end, and step values.

Use a queue of iterators; on each call to next(), pop the front iterator, yield its current element, advance it, and re-enqueue it if not exhausted. This is O(1) per next() call and O(k) space for k iterators. The follow-up is typically: make the iterator lazy so it handles infinite streams, or add a cycle iterator that restarts once exhausted. Iterator design pattern knowledge, adherence to OOP and SOLID principles, and ability to generalize incrementally. Coinbase specifically evaluates whether the candidate writes extensible code rather than hard-coded solutions.

Currency Exchange Rate — Best Path: Given a list of currency pairs with exchange rates (e.g., [(BTC, USD, 45000), (ETH, USD, 3000)]), find the best exchange rate to convert from currency A to currency B, potentially chaining multiple conversions.

Model as a weighted directed graph where nodes are currencies and edge weights are exchange rates. To maximize the product of rates along a path, convert to log-space: maximize sum of log(rate), which transforms the multiplicative problem into an additive shortest-path problem solvable with BFS/Bellman-Ford (or Dijkstra with negated log weights). Time complexity is O(V + E). Follow-up: detect arbitrage cycles (negative cycles in the log graph). Graph modeling ability and the insight to apply logarithms to convert a product-maximization problem into a standard shortest-path. Also tests awareness of floating-point precision pitfalls relevant to financial systems.

Design a Stock Broker App / Real-Time Asset Price Dashboard: Design a system that shows live prices of assets (crypto tokens) to users, receives price updates from multiple exchanges every few seconds, and displays a rolling average updated every 10 seconds.

Ingest layer: price-update WebSocket feeds per exchange ingested by stateless workers and published to a message queue (Kafka). Aggregation service: consumes updates, maintains a per-token rolling window (circular buffer or sliding-window average over the last 10 seconds), publishes aggregated prices. Delivery: Server-Sent Events or WebSocket push to browser clients, with a Redis cache as the read layer so new connections get the latest price instantly without replaying the stream. Key trade-off: fan-out to millions of clients requires pub/sub with client-side subscriptions per token, not a broadcast. Follow-up: handle exchange outages gracefully — stale-price detection and fallback display. Understanding of real-time data pipelines (producer/consumer separation), the difference between push and pull delivery for high-fan-out reads, and awareness of data freshness vs. consistency trade-offs in a financial context.

Design a Cryptocurrency Exchange: Design a system that allows users to place limit and market orders to trade crypto pairs (e.g., BTC/USD), matching buyers and sellers in real time at scale.

Core components: Order Book Service (in-memory per trading pair, buy orders in a max-heap, sell orders in a min-heap); Matching Engine (deterministic, single-threaded per pair to avoid race conditions, publishes fill events); Order Ingestion API (validates, deduplicates via idempotency key, enqueues); Trade Settlement Service (updates ledger balances atomically); Market Data Service (streams best bid/ask and trade history via WebSocket). Sharding strategy: shard by trading pair so each shard owns one book. Throughput target: millions of orders/day with latency under 50ms. Follow-up: how do you ensure no double-spend during settlement? Clear separation of the matching engine from ingestion and settlement, correct reasoning about why the matching engine must be single-threaded (or use a serialization queue per pair), and financial-system correctness concerns (idempotency, atomicity of balance updates).

Design a Distributed Notification System: Design a system that reliably delivers email, SMS, and push notifications at high throughput for a trading platform (e.g., price alerts, trade confirmations, withdrawal approvals).

Producer services publish notification events to a durable message queue (Kafka or SQS) keyed by user ID and channel. Per-channel workers consume events, apply rate limiting and deduplication (idempotency key in Redis), and call third-party providers (SendGrid, Twilio, FCM). A retry/dead-letter queue handles provider failures with exponential backoff. Preferences service controls per-user opt-in per channel. Scale: fan-out is per-user, not broadcast, so horizontal scaling of workers handles throughput. Follow-up: how do you ensure exactly-once delivery semantics, and what happens if a user changes their notification preference mid-flight? Message queue architecture knowledge, idempotency handling for third-party integrations, and awareness of at-least-once vs. exactly-once delivery. Coinbase evaluates whether the candidate thinks about reliability and user experience under failure conditions.

Tell me about a time you had to make a technical decision with incomplete information. What was your process, and what was the outcome?

Structure with STAR. Emphasize how you gathered the most important data points quickly, defined the reversibility of the decision, set a time-box for gathering evidence, and moved forward with explicit assumptions documented. Close with what you learned — did the outcome validate your process even if the decision was later changed? Coinbase values bias toward action and clear reasoning under uncertainty. Decision-making clarity, comfort with ambiguity, and ownership. The interviewer checks whether the candidate can articulate the reasoning process, not just the outcome.

Describe a situation where you failed or your project did not go as planned. How did you respond, and what did you learn?

Choose a real failure with meaningful stakes — not a disguised success story. Describe what you got wrong (technical overconfidence, missed requirement, poor estimation), what you did immediately to limit damage, and what systemic change you made afterward. Coinbase specifically evaluates growth mindset; the learning and behavior change after failure carry more weight than the failure itself. Intellectual honesty, ownership without deflecting blame to teammates or circumstances, and concrete evidence of behavioral change. Interviewers flag candidates who can only describe others' failures or reframe failures as successes.

Tell me about a time you disagreed with a teammate or manager on a technical approach. How did you handle it, and what happened?

Use STAR. Frame the disagreement as principled and data-driven — you raised the concern with specific technical evidence, proposed an alternative, were open to counter-arguments, and ultimately either changed your mind with new data or accepted the decision once heard. Avoid making the other party look incompetent. Close with the outcome and what you would do differently. Collaboration and communication style, ability to advocate for technical positions without damaging relationships, and respect for final decisions. Coinbase's culture doc emphasizes candor balanced with respect.

Coinbase Interview Questions

Coinbase runs a 4-5 round loop: an online aptitude test (40 logical-reasoning questions in 20 minutes), a CodeSignal coding assessment (4 progressively harder parts in 90 minutes), two technical onsite rounds (one Domain/Code-Design and one Technical Execution), a High-Level System Design round for IC4 and above, and a 30-60 minute Hiring Manager behavioral round. The CodeSignal problems are multi-part and incremental — each part adds functionality on top of the last, and passing all test cases in part N unlocks part N+1. Coinbase has historically leveled candidates down during the EM round; the system-design bar is high for senior ICs (IC4/IC5).

20 real questions across 3 rounds

Reported via LeetCode Discuss: Coinbase SDE3 Remote India Sep 2024 (5843528), Coinbase IC4 India Offer (6392076), Coinbase IC5 Offer (5117593), Coinbase IC5 India (1983246), Coinbase Virtual On-site (1647092), Coinbase IC4 India (5287663); Glassdoor Coinbase SWE reviews; Blind post IC5 Coinbase implement iterators (LgR2Zt5Z); interviewing.io Coinbase interview process page

Run a Coinbase mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews