HackTheRounds Interview Experiences

Coinbase Software Engineer Interview Experience (2026) - Chain Integrity OA & Matching Engine, Offer

Coinbase SWE loop: CodeSignal chain integrity and double spend detection OA, wallet repo extension, matching engine design, mission grounded values round, offer

By Anonymous · 2026-04-17

Background

My path into Coinbase's SWE loop started at a distributed-systems conference last fall, where I ended up on a coffee line behind a Coinbase engineer who offered to pass my resume to a platform team. Three weeks later I had a recruiter screen. I had about five years of backend experience at a mid-sized logistics company and zero professional crypto experience, but I had written some hobby code around transaction validation for fun, which turned out to matter. Coinbase's loop leans heavily into the integrity and state-consistency side of software engineering, not into anything resembling blockchain consensus algorithms.

Timeline

Total: about 7 weeks.

OA (90 min, CodeSignal)

Two coding problems, both themed around ledger correctness. The platform was CodeSignal with the "company take-home" variant rather than the standard general assessment. Python, Java, Go, and a few other languages were supported; I used Python.

Problem 1: Validate Blockchain Transaction Integrity

Problem: You are given an ordered list of transaction records. Each record carries a hash , a prev hash , and the usual payload fields (from, to, amount, timestamp). Write a function that validates the chain: for every record after the first, the record's prev hash must equal the hash of the immediately preceding record, and each record's hash must match a fresh sha256 over its own payload plus prev hash .

This looks like cryptography but it is really just a linked-list consistency check with hashing. Walk the list once. For each record after index 0, recompute its hash from the payload plus its declared prev hash , verify the recomputed value matches the declared hash , and verify that its declared prev hash equals the previous record's hash . Fail fast on the first mismatch.

Time complexity is O(n), space is O(1). I used hashlib.sha256 and serialized payload fields in a fixed canonical order before hashing, because field order affects the hash and "just use str(record) " is a trap that fails on Python versions where dict ordering changed.

Problem 2: Detect Double Spending in a Ledger

Problem: You are given a stream of transactions (account, amount, timestamp) . Positive amounts are credits, negative amounts are debits. Detect whether any account's running balance goes negative at any point, and if so return the (account, timestamp) of the first such event, otherwise return None.

Single pass. Maintain a dict from account to running balance. For each transaction in timestamp order, update the balance, and check if it went below zero. Return the first violation.

The subtlety is how you break ties when two transactions share a timestamp. I keyed on (timestamp, sequence number) where sequence number was the transaction's position in the input, which makes replay order deterministic. Coinbase's interviewers specifically ask about this when they give similar problems in the onsite. If you do not flag it, they will ask.

I finished both problems in about 55 minutes. Left 35 minutes to add tests and add inline comments explaining my tie-break assumption on problem 2.

Recruiter Screen After OA (30 min)

Short conversation after OA results were in. The recruiter asked why Coinbase specifically and how I was thinking about the compensation mix between cash, equity, and their "CIP" inflationary equity refresher program. He was transparent that Coinbase's equity model is unusual and that some candidates turn down offers because they do not understand the vest. Worth researching before the onsite.

Onsite Format

Five rounds back to back over one day.

  1. Coding 1: ledger-flavored algorithm (60 min)
  2. Coding 2: extend a small repo (60 min)
  3. System design (60 min)
  4. Hiring manager deep dive (45 min)
  5. Values and behavioral (45 min)

Onsite Round 1: Coding — Order Matching Cardinality

Problem: You have two sorted arrays of open orders: buys sorted by price descending, sells sorted by price ascending. When a buy's price is = a sell's price, they can match for min(buy qty, sell qty) units. Orders partially fill and the remainder stays on the book. Return the total matched volume after processing all matching opportunities in a single pass.

Two pointers. Pointer b on the buy array, pointer s on the sell array. While b and s are in range and buys[b].price = sells[s].price , match min(buys[b].qty, sells[s].qty) . Whichever order is exhausted, advance that pointer. If both exhaust simultaneously, advance both. Total matched volume accumulates.

The follow-up was: if the two pointers exhaust at the same time, which one advances first, and does it matter? In a single matching pass, no; but if you care about deterministic replay across distributed workers, you want the answer to always be the same regardless of machine or thread order. I went with "buys first" as a convention and noted it explicitly.

Practice it: [[problem/610?company=31|Transaction Filter with Pagination]]

Onsite Round 2: Extend a Wallet Repo

The interviewer shared a small Go repo that already implemented POST /accounts , GET /accounts/:id , and a SQLite-backed storage layer. My task was to add POST /transfers with proper idempotency, rollback, and a clean error model.

The contract I built to:

  • Transfer requires a `X-Idempotency-Key` header
  • If the same key is submitted twice, the second call returns the cached first result rather than retrying the transfer
  • Source and destination balance updates happen inside a single DB transaction
  • Insufficient funds returns HTTP 422 with a structured error body, not a naked 500
  • Every request emits a correlation ID and writes a structured log

The load-bearing design decision is that the idempotency-key check happens inside the same DB transaction as the balance mutation, using a unique constraint on the request dedupe table. Outside-the-transaction dedupe creates a race: two concurrent requests with the same key both see "not yet processed" and both proceed to mutate. I explained this to the interviewer before I wrote the code, which saved back-and-forth later.

I also wrote two small tests: one happy-path, one idempotency retry. The interviewer asked me to add a third for insufficient-funds, which I did.

Practice it: [[problem/606?company=31|Design Banking System]]

Onsite Round 3: System Design — Crypto Exchange Order Book

Problem: Design the matching engine for a crypto exchange. Assume a single trading pair (BTC-USD) with 10K orders/sec at peak and a p99 match latency under 10ms.

Four components.

Order ingest. API validates, writes to a per-pair Kafka topic. Validation is lightweight: shape and balance check. Real validation happens in the engine.

Matching engine. Single-writer process per pair. Holds two in-memory priority queues: bids (max-heap by price), asks (min-heap by price), with FIFO tie-break within a price level. New orders match greedily against the opposite side, emit trade events, and persist.

The single-writer constraint is the answer Coinbase wants to hear on this question. Do not suggest parallelism within a pair. Scale by adding pairs (horizontal), not by adding threads within a pair (breaks determinism).

Persistence. Every accepted order and every trade is appended to an event log before the engine acknowledges the request. On crash, the engine replays the log from the last checkpoint to reconstruct the in-memory book.

Market data fanout. Trades and order-book deltas publish to a fanout layer (Redis pub/sub or a separate Kafka topic) and stream to WebSocket-connected clients. Historical data archives to a time-series store.

The interviewer pushed on disaster scenarios. What if the engine crashes mid-trade? Because acknowledgment is after the log write, any in-flight trade that was not logged is not acknowledged, so the client retries with idempotency semantics. What about third-party exchange integration for routed orders? I proposed a separate sync-API adapter with circuit-breaker and backoff, and flagged that the state machine on the adapter (pending - dispatched - confirmed or failed) is its own source of bugs.

Practice it: [[problem/611?company=31|Crypto Trading System (Order States)]]

Onsite Round 4: Hiring Manager

Mostly resume deep dive. She pulled two specific bullets: the one about a partial outage I had triaged at 3am, and the one about migrating a billing system from SQL to a hybrid SQL+key-value store. For each she asked "what decision would you reverse today," and then drilled on the reasoning.

Two questions that surprised me. "When have you shipped something worse than you wanted and what kept you from polishing it further?" and "When did you disagree with a PM and what happened?" The honest answer matters more than the impressive answer here. I talked about a compliance project where we shipped a v1 with known gaps because the deadline was external, and how we closed those gaps over the following quarter with a posture change from the team.

Onsite Round 5: Values

Coinbase's values round is grounded in their public "mission first" framing. The interviewer wanted to hear why crypto specifically, and whether I had an actual mental model of what Coinbase is trying to do beyond the slogan.

I had prepared one story about a family member trying to send money internationally and failing because of rail frictions that crypto could conceivably solve. Not a "I love bitcoin" answer, not a "I am ideologically sound" answer, but a "here is a specific frustration that maps to a specific product capability" answer. That went well.

Other questions: tell me about a time you committed to a decision you disagreed with. How do you handle ambiguity. How would you explain custody and self-custody to a non-technical family member.

Result

Offer came five business days after the onsite. Senior SWE level, comp within the levels.fyi 75th percentile. Equity was granted with the CIP refresher mechanism, which the recruiter walked me through line by line. I accepted after one round of negotiation on the sign-on.

Tips

  1. Canonicalize payload serialization before hashing. Problem 1's most common failure mode is "I used `str()` on a dict and got a non-deterministic hash." Sort fields and serialize explicitly. This also matters in the onsite repo round.
  2. Keep your idempotency dedupe check inside the DB transaction. Every candidate I know who got dinged on the repo round either did the check outside the transaction or forgot to put a unique constraint on the dedupe table. Either one is a correctness bug under concurrency.
  3. For the matching engine, repeat "single-writer per pair" three times until it feels natural. Do not suggest thread-level parallelism inside a pair. That is the Coinbase-specific trap.
  4. Ask the recruiter to walk you through the CIP equity mechanism before you think about comp. The structure is genuinely different from standard RSU grants at other tech companies, and candidates who assume it is the same miss real dollars on negotiation.
  5. For the values round, prep one genuine crypto story. Not ideology, not price action. A specific problem in your life or a loved one's life where a crypto primitive would plausibly help. That is the answer that signals fit.
  6. Sort transactions deterministically with a tie-break. Whenever you process timestamped events, always tie-break on a secondary key (sequence number, tx id). Coinbase interviewers ask about this on every financial-data problem I saw.

Coinbase's loop is one of the fairest I have done. The questions are grounded in real problems their teams solve, so the prep transfers directly to the job if you get it.