I sat the Coinbase senior backend loop in early 2024 and the round I want to write up is round 3 of 5: 60 minutes, system design, with a senior staff engineer. The recruiter's prep email had used the phrase "crypto-native context" exactly once and I had read it as a soft suggestion. It was not a soft suggestion. The 25-minute mark of that round was the moment I realized the question was not the question I had been answering.

I was rejected on this loop. The hire bar was strong-hire across the panel and I came in at hire on three rounds and lean-hire on this design round, which the recruiter told me later was the round that pulled the packet down. I want to write down what I missed, because the failure was specific and reproducible.

Why I am writing this as a postmortem instead of a prep guide

The Coinbase loop is widely-publicized as "crypto-flavored backend interviewing." That framing is technically accurate and tactically useless. The thing the framing hides is that for a backend role on the exchange-engine side, you are being graded against a specific set of failure modes that do not exist in a non-crypto exchange: deposit-confirmation windows, reorg risk on the source chain, the legal-and-operational boundary between the hot wallet and the cold wallet, and the per-asset settlement asymmetry. None of those four are obvious from the prompt. All four were the actual rubric.

The prompt and my first 25 minutes

Paraphrased: "Design the order matching and settlement system for a crypto exchange. Assume a single trading pair to start. Walk us through writes, reads, and the steady-state failure modes you would design for."

My first 25 minutes were the cleanest version of a generic exchange design I had ever drawn. Order book in memory per pair, sharded by pair. Append-only event log to a durable store. Reads served from a CDC-fed read replica for non-trading queries. Matching engine deterministic, single-threaded per pair, with a sequence number on every event so the log is the system of record. I knew this material cold and I delivered it cleanly.

First-pass diagram (25 min in)
  REST gateway   ->   order router   ->   per-pair matching engine
                                                  |
                                                  v
                                          append-only event log
                                                  |
                            ----------------------+----------------------
                            |                                            |
                            v                                            v
                  CDC stream to read DB                      settlement service

The interviewer had been quiet during this stretch, taking notes. At minute 25 they said, paraphrased: "This is a clean traditional exchange. Tell me what changes when the asset is on a public chain."

That was the question.

The four crypto-native concerns I was supposed to surface unprompted

I got two of the four. I missed the other two. I am going to lay out all four, because the gap between what I produced under pressure and what the rubric was looking for is the actual lesson.

1. Deposit confirmation windows. When a user deposits BTC, the deposit is not credited until N block confirmations have landed (typically 3-6 for BTC, more for assets with faster blocks and higher reorg risk). The matching engine cannot let the user trade those funds until the deposit is confirmed, and "confirmed" is a per-asset policy, not a global one. I caught this one. I drew a deposit-state machine: pending -> confirming -> credited -> tradeable, with the asset-specific N as a config table.

2. Reorg risk and rollbacks. The chain can reorg. A deposit that looked confirmed at block height H can be invalidated if a deeper reorg occurs. This is the failure mode I missed entirely in the first pass. The interviewer surfaced it: "What happens to a user's already-credited balance if the source chain reorgs past your confirmation depth?" My answer was honest and weak: "I would catch it on the chain monitor and reverse the credit." The follow-up was the trap: "What if they have already traded those funds?" I did not have a clean answer. The expected answer is that the confirmation depth has to be set such that reorgs past it are economically infeasible for the asset, and the policy has to be conservative for low-hashrate chains, and you need an exception runbook for the tail event. I knew the words; I did not have the runbook.

3. The hot-cold wallet boundary. I caught this one too. Drew it explicitly: only a small float lives in the hot wallet, sweeps to cold happen on a schedule with multi-sig, withdrawals above a threshold require a manual approval queue. The interviewer pushed on what happens to user UX during a sweep window and I had a reasonable answer (the hot wallet is sized to cover P95 daily withdrawals, sweeps are scheduled around troughs, manual approval queue is staffed 24/7 with a SLA the user sees).

4. Per-asset settlement asymmetry. This was the one I missed worst. In a traditional exchange, settlement is symmetric and instant: the matching engine credits both sides of the trade in the same write. In a crypto exchange where you may be quoting a pair like BTC/USDT, the BTC side and the USDT side have different finality, different reorg profiles, different deposit-confirmation policies, and (if the user later withdraws) different on-chain settlement times and fee profiles. The internal book can be symmetric, but the moment you cross the on-chain boundary, the asymmetry shows up. The interviewer asked, paraphrased: "What is the longest a user might be exposed to one-sided settlement risk in your system?" I gave a hand-wavy answer about the withdrawal queue and the interviewer let it go, which was not a kindness. It was them registering that I had not internalized the asymmetry as a primitive.

The artifact I should have drawn

What I should have produced, around minute 35, was a per-asset policy table that made the asymmetry visible. Something like:

Per-asset policy (sketch the candidate should have produced)
  asset    confirms    reorg-tail    hot-float    sweep-cadence   wd-fee-policy
  BTC          3          1e-9          1.5%        every 6h         user pays
  ETH         12          1e-7          2.0%        every 4h         user pays
  USDT-ERC    20          1e-7          3.0%        every 4h         user pays
  USDC-ERC    20          1e-7          3.0%        every 4h         user pays

The values are illustrative; the point is that the table itself is the diagram. A senior backend engineer at this company is expected to know that the matching engine is the easy part and the per-asset policy is the load-bearing part. I drew the matching engine in detail and waved at the policy. The grade reflected the choice of detail.

A small piece of code that would have helped my answer

In retrospect, the cleanest way I could have anchored the reorg discussion was a sketch of the credit-reversal path, rather than just saying "reverse the credit." Something concrete:

def on_deposit_confirmed(asset: str, txid: str, user_id: str, amount: int) -> None:
    # Idempotent. The chain monitor may re-emit on restart.
    if already_credited(asset, txid):
        return
    credit_user_balance(user_id, asset, amount, source_txid=txid)
    record_credit_provenance(txid, user_id, amount, confirmed_at_height=current_height(asset))

def on_reorg_invalidates(asset: str, txid: str) -> None:
    # Tail event. We have to handle the case where the user has already
    # traded or withdrawn the credited funds. Two-phase response:
    # 1. Lock further activity on the affected balance immediately.
    # 2. Open an incident. Manual reconciliation, not silent reversal.
    lock_balance_provenance(txid, reason="source-chain-reorg")
    page_oncall(asset=asset, txid=txid, severity="high")

The code is not the point. The point is that drawing the reversal path forces you to acknowledge the trades-and-withdrawals-already-happened case out loud, which is the case the interviewer was waiting for.

The two changes I made before the next exchange-shaped loop

I did two things differently for the next exchange-shaped loop I sat (a smaller competitor, three months later). I read three public engineering posts on deposit-confirmation policy and reorg-handling, taking notes specifically on the runbook for the tail case. And I practiced the "what does the asset table look like" sketch as a separate artifact, the way I would practice a load calculation. The second loop I cleared with a hire on the design round.

The framing the interviewer was actually using on that Coinbase round, which I did not see at the time, was: do you treat the on-chain boundary as a primitive of the design, or do you treat it as an implementation detail you wave at after you finish the matching engine? I waved at it. The good candidates draw it first.