Coinbase Interview Questions (2026): Real, With Answers

It's a timed, proctored coding test delivered through CodeSignal rather than a live interviewer. Candidates report a small set of problems that increase in difficulty as you go, similar in shape to CodeSignal's General Coding Assessment format used by other companies, not Coinbase-specific trivia. The practical advice that shows up across reports: completeness on the first problem counts for more than a half-finished attempt at an optimal solution on the last one.

Treat it like a triage exercise. Get one problem fully passing test cases, then spend remaining time making real progress on the second rather than polishing the first for marginal gains. A recruiter reading the CodeSignal report afterward is looking at pass rate per problem, not effort per problem.

Candidates describe roughly 50 questions in 15 minutes, which works out to under 20 seconds per question. The content splits across pattern completion and spatial reasoning (finish a sequence, rotate a shape), short verbal reasoning passages, and basic arithmetic and ratio problems under pressure.

The tight clock is the point. Coinbase isn't measuring whether you can eventually solve a ratio problem, it's measuring processing speed under time pressure, which correlates with how the company weighs general cognitive ability in hiring. Practice timed logic puzzles the same week as the test. Rustiness costs more here than in almost any other round because there's no partial credit for showing your work.

Candidate reports put the full assessment, coding plus aptitude plus workstyles, at roughly 60 to 90 minutes total, sent as a single CodeSignal link with a deadline of several days to start it but a continuous timer once you begin. Most candidates describe it as not pausable once started, so block out a full quiet hour and a half rather than trying to squeeze it between meetings.

A second, smaller point that trips people up: notifications and second monitors are frequently flagged by CodeSignal's proctoring. Close everything unrelated before you start the timer.

This is a floyd's cycle detection problem in disguise. Treat the array as a linked list where index i points to index arr[i]. Because there are n+1 values in the range 1 to n packed into n slots, a duplicate exists and, viewed as a pointer graph, that duplicate creates a cycle. Run the classic slow/fast pointer approach to find the cycle's entry point.

def find_duplicate(nums):
  slow = fast = nums[0]
  while True:
    slow = nums[slow]
    fast = nums[nums[fast]]
    if slow == fast:
      break
  slow2 = nums[0]
  while slow != slow2:
    slow = nums[slow]
    slow2 = nums[slow2]
  return slow

The interesting part of the answer isn't reciting the cycle-detection trick, it's explaining why a duplicate value guarantees a cycle exists in the first place. Interviewers push on that framing before letting you write code.

This is a hash map with explicit handling of the operations spelled out rather than a trick question. The subtlety interviewers actually probe is what "update" means when the key doesn't exist yet, does it insert, does it throw, and how you handle collisions if you're asked to implement the hash table yourself rather than wrapping a language built-in.

class KVStore:
  def __init__(self):
    self.data = {}

  def get(self, key):
    return self.data.get(key)

  def set(self, key, value):
    self.data[key] = value

  def delete(self, key):
    self.data.pop(key, None)

  def update(self, key, value):
    if key not in self.data:
      raise KeyError(f"{key} not found")
    self.data[key] = value

Interviewers extend this one live, most commonly into TTL expiry (each key carries an expiration timestamp, checked lazily on read) or into thread safety with a lock around mutating operations. Ask which extension they want before assuming.

A hash map one-pass solution is the expected answer, not the brute-force nested loop. Walk the array once, and for each number check whether target minus that number is already in the map before inserting the current number.

def two_sum(nums, target):
  seen = {}
  for i, n in enumerate(nums):
    complement = target - n
    if complement in seen:
      return [seen[complement], i]
    seen[n] = i
  return []

This is squarely a warm-up at Coinbase, most candidates report it opening a round rather than closing one. What interviewers actually watch is whether you jump straight to the hash map approach or narrate the brute force first, since either is fine, it's the narration and edge case handling (duplicate values, no valid pair) that gets scored.

Iteratively, walk the list with three pointers, previous, current, and next, flipping current's next pointer to point backward at previous on each step. Recursively, reverse everything after the head first, then fix the head's own next pointer to point back at itself.

def reverse_iterative(head):
  prev = None
  while head:
    nxt = head.next
    head.next = prev
    prev = head
    head = nxt
  return prev

def reverse_recursive(head):
  if not head or not head.next:
    return head
  new_head = reverse_recursive(head.next)
  head.next.next = head
  head.next = None
  return new_head

Simple as it looks, this shows up as an early filter question in phone screens. The follow-up interviewers actually care about is reversing a sublist between positions m and n, which forces you to track the node just before the sublist starts.

A sliding window with a hash map tracking the last seen index of each character does this in one pass. Expand the window's right edge each step, and whenever you hit a character already inside the current window, jump the left edge forward past its previous occurrence rather than shrinking one character at a time.

def longest_unique_substring(s):
  last_seen = {}
  left = 0
  best = 0
  for right, ch in enumerate(s):
    if ch in last_seen and last_seen[ch] >= left:
      left = last_seen[ch] + 1
    last_seen[ch] = right
    best = max(best, right - left + 1)
  return best

Common enough as a phone screen opener that it's worth having cold. The one mistake that costs points: forgetting the `>= left` check, which causes the window to shrink incorrectly when a repeated character's last occurrence is actually outside the current window already.

Every participant keeps a copy of the same ledger, and instead of trusting one party to say what's true, the network agrees on the next batch of transactions through a mechanism that makes cheating expensive or impossible to sustain. In proof-of-work, that mechanism is computational cost, miners compete to solve a puzzle, and whoever solves it first proposes the next block, with the rest of the network verifying it cheaply even though producing it was expensive.

The part worth adding for a technical interviewer: the "central authority" isn't eliminated, it's replaced by an economic incentive structure, honest participation has to be more profitable than attacking the network, and the security of the whole system rests on that assumption holding at scale.

ERC-20 defines a fungible token standard, every unit is interchangeable with every other unit, the same way one dollar bill is interchangeable with another. ERC-721 defines a non-fungible token standard, every token has a unique ID and can carry distinct metadata, so token 1 and token 2 are not interchangeable even though they share a contract.

Architecturally, that difference cascades into how you'd design storage and transfer logic around them. Fungible balances are a simple mapping of address to amount. Non-fungible ownership is a mapping of token ID to owner address, plus a separate metadata layer, and transfer logic has to reference specific token IDs rather than just amounts, which is why marketplaces and wallets built for ERC-20 need real additional work, not just a config change, to support ERC-721 correctly.

This maps directly to "act like an owner." The strongest answers pick a moment with real ambiguity, not a case where the right move was obvious to everyone and you just happened to be the one who executed it. Describe the state before you acted (what was unclear, what could have gone wrong if you'd waited for someone to assign it), the specific action you took, and how you verified it was actually the right call rather than just lucky.

A detail that separates a senior answer from a junior one: acknowledging what you'd have done differently if it hadn't worked out, since real ownership includes owning the downside, not just the win.

This is the "continuous learning" tenet, straightforward in structure but easy to answer shallowly. The weak version of this story is "I read the docs and figured it out." The strong version names the specific gap in your knowledge, the approach you took to close it under time pressure, and one thing that surprised you or that you got wrong along the way before getting it right.

Given Coinbase's domain, a story that involves ramping up on something crypto-adjacent, even if you came from a non-crypto background, tends to land well here, since it directly demonstrates you can pick up the domain knowledge the role will require.

Coinbase screens explicitly for mission alignment around "economic freedom," and a generic answer about liking crypto or wanting a challenging engineering problem tends to read as interchangeable with an answer for any other tech company. A stronger answer connects something specific, a product decision Coinbase made, a public position the company took, a technical writeup from their engineering blog, to why it resonates with you personally, showing you've actually engaged with the company rather than just applying broadly.

It doesn't need to be dramatic. A candidate who cites a specific detail from Coinbase's public engineering or policy writing comes across as more prepared than one reciting "I've always been interested in crypto."

The honest, straightforward version of this answer is almost always the strongest one. Interviewers have heard every version of a deflection and tend to trust candidates more when the reason is specific and forward-looking, wanting more ownership, wanting to work closer to the problem domain, wanting a team at a different stage, rather than purely a complaint about the previous employer.

If there's something genuinely negative about the last role, it's fine to name it briefly and factually, then pivot quickly to what you're looking for instead, rather than spending the majority of the answer on what went wrong previously.

It's a series of agree/disagree statements about work preferences, whether you prefer strict process or flexible improvisation, whether you'd rather ship something imperfect fast or wait for it to be right, and similar tradeoffs. It's scored against Coinbase's nine tenets (clear communication, efficient execution, act like an owner, top talent, championship team, customer focus, repeatable innovation, positive energy, continuous learning) rather than against a universal correct profile.

There isn't a single right answer, but there is a wrong strategy: answering every question with the most extreme "strongly agree" to seem maximally driven. Coinbase's assessment is designed to catch inconsistent or performative answering patterns, since the same underlying trait gets probed from multiple angles across the survey. Answer honestly and consistently rather than trying to reverse-engineer the ideal profile.

Enough that it's worth taking seriously rather than treating as a formality. Candidate reports describe recruiters citing a specific score threshold, and at least one Blind post mentioned an IC4 candidate scoring 525 out of 750 on an in-memory database problem set and still advancing, which suggests the bar isn't a hard cutoff so much as a strong signal combined with resume and role fit.

The safest read: a very low score on the coding section is close to a hard no, since it's the cheapest, most objective data point recruiters have before spending an engineer's time on a phone screen. A mediocre aptitude score paired with a strong coding section and relevant resume can still move forward.

The shape is consistent (coding plus aptitude plus workstyles) but the coding content shifts with role. Backend and infrastructure candidates report data structure and system-flavored problems, in-memory key-value stores with get, set, delete, and update, generic search APIs with filter operators. Frontend and full-stack candidates report more standard algorithmic problems layered with a JavaScript or React-adjacent framing.

If you know the team you're interviewing for ahead of time, ask the recruiter what stack the OA is likely to test in. Recruiters generally answer this directly since it isn't considered a leak of confidential content, just a courtesy that saves everyone a wasted attempt.

The key insight is that this reduces to finding the longest palindromic suffix that starts a palindrome from position 0, or equivalently, the longest prefix of the string that is itself a palindrome when combined with its own reverse. A clean approach: build the string s + '#' + reverse(s), compute the KMP failure function over it, and the last value in that failure array tells you how many characters at the start of s are already part of a palindrome, so you insert the rest, reversed, at the front.

def min_insertions_front(s):
  combined = s + "#" + s[::-1]
  fail = [0] * len(combined)
  for i in range(1, len(combined)):
    j = fail[i - 1]
    while j > 0 and combined[i] != combined[j]:
      j = fail[j - 1]
    if combined[i] == combined[j]:
      j += 1
    fail[i] = j
  overlap = fail[-1]
  return s[overlap:][::-1]

Brute force (try every prefix, check if the rest can be mirrored) is a fine place to start out loud. Getting to the KMP-based linear solution is what separates a pass from a strong pass here.

The plain version is a straightforward generator. The cycling requirement is what makes this an interview question rather than a one-liner: once next() would go past end, it has to wrap back to start rather than raising StopIteration, and you need to decide (and state out loud) whether it cycles forever or stops after a fixed number of laps.

class CyclicRangeIterator:
  def __init__(self, start, end, step=1):
    self.start, self.end, self.step = start, end, step
    self.current = start

  def __next__(self):
    value = self.current
    self.current += self.step
    if self.current > self.end:
      self.current = self.start
    return value

Follow-ups usually ask you to make it thread-safe or to support a hasNext() that behaves sensibly for an infinite cycling iterator, worth flagging that hasNext() on a cycling iterator is always true and asking whether that's the intended behavior.

Keep a queue of the remaining iterators. Each call to next() pops the front iterator, takes its next value, and if that iterator still has elements left, pushes it to the back of the queue. This naturally interleaves the lists in round-robin order and gracefully degrades to fewer active lists as they get exhausted.

from collections import deque

class ZigzagIterator:
  def __init__(self, lists):
    self.queue = deque((iter(lst), len(lst)) for lst in lists if lst)

  def __next__(self):
    it, remaining = self.queue.popleft()
    value = next(it)
    if remaining - 1 > 0:
      self.queue.append((it, remaining - 1))
    return value

  def has_next(self):
    return len(self.queue) > 0

Reports mention a variant where next() and hasNext() get called in an unusual order by the test harness, so make hasNext() side-effect free rather than accidentally advancing an iterator.

The straightforward part is dispatching on operator string to the right comparison. The part that turns this into a real interview question is the follow-up: how does this scale to a million records, and how do you paginate results consistently if new records are being inserted while a client pages through?

def search(records, field, op, value):
  ops = {
    "=": lambda a, b: a == b,
    ">": lambda a, b: a > b,
    "<": lambda a, b: a < b,
  }
  return [r for r in records if ops[op](r.get(field), value)]

The strong answer moves past filtering an in-memory list and into cursor-based pagination, a cursor that encodes the last seen id or timestamp rather than an offset, so pages stay stable even as the underlying dataset changes between requests. Naming why offset pagination breaks under concurrent writes is the actual signal interviewers report looking for.

A sliding window backed by a deque handles this cleanly. Push each new event onto the back, and before returning the average, pop events off the front whose timestamp falls outside the window, maintaining a running sum so you never recompute the average over the whole window each time.

from collections import deque

class RollingAverage:
  def __init__(self, window_seconds):
    self.window = window_seconds
    self.events = deque()
    self.total = 0.0

  def add(self, timestamp, price):
    self.events.append((timestamp, price))
    self.total += price
    while self.events and timestamp - self.events[0][0] > self.window:
      _, old_price = self.events.popleft()
      self.total -= old_price

  def average(self):
    return self.total / len(self.events) if self.events else 0.0

This is close to the "crypto dashboard" style question reported from onsite loops, where prices arrive every couple seconds from multiple exchanges and need to be averaged on a slower cadence. Naming the memory tradeoff of storing raw events versus a bucketed histogram is a good place to show range.

Use three pointers, low, mid, and high. Walk mid through the array: if you see a 0, swap it to the low pointer and advance both low and mid; if you see a 2, swap it to the high pointer and pull high back without advancing mid, since the swapped-in value at mid still needs to be examined; if you see a 1, just advance mid. The array ends up partitioned in a single pass with O(1) extra space.

def dutch_flag_sort(nums):
  low, mid, high = 0, 0, len(nums) - 1
  while mid <= high:
    if nums[mid] == 0:
      nums[low], nums[mid] = nums[mid], nums[low]
      low += 1
      mid += 1
    elif nums[mid] == 2:
      nums[mid], nums[high] = nums[high], nums[mid]
      high -= 1
    else:
      mid += 1

Candidates who reach for a full sort or a two-pass counting approach usually get asked directly why they didn't do it in one pass with constant space. Naming the invariant of the three regions (everything below low is 0, between low and mid is 1, above high is 2) before coding it up avoids most of the off-by-one bugs people hit live.

Track three states per node during a DFS: unvisited, in the current recursion stack, and fully processed. A cycle exists if the DFS ever reaches a node that's still in the current recursion stack, not just previously visited, because "visited but no longer on the stack" means that branch already finished cleanly.

def has_cycle(graph):
  WHITE, GRAY, BLACK = 0, 1, 2
  color = {node: WHITE for node in graph}

  def dfs(node):
    color[node] = GRAY
    for neighbor in graph[node]:
      if color[neighbor] == GRAY:
        return True
      if color[neighbor] == WHITE and dfs(neighbor):
        return True
    color[node] = BLACK
    return False

  return any(color[n] == WHITE and dfs(n) for n in graph)

This comes up dressed as a dependency graph question, detecting circular dependencies between services or packages, more often than as a pure graph theory prompt. Framing your answer around the real scenario rather than abstract nodes tends to land better.

A min-heap holding the current head of each list is the standard approach: pop the smallest, append it to the result, push that node's next pointer back onto the heap if one exists, and repeat until the heap is empty. This runs in O(n log k) where n is total elements and k is the number of lists, better than merging lists pairwise one at a time.

import heapq

def merge_k_lists(lists):
  heap = []
  for i, node in enumerate(lists):
    if node:
      heapq.heappush(heap, (node.val, i, node))

  dummy = tail = ListNode()
  while heap:
    val, i, node = heapq.heappop(heap)
    tail.next = node
    tail = tail.next
    if node.next:
      heapq.heappush(heap, (node.val, i, node.next))
  return dummy.next

Interviewers sometimes ask you to compare this to divide-and-conquer pairwise merging first, which also lands at O(n log k) but with different constant factors and memory behavior. Being able to name both and explain when you'd pick one over the other is a stronger answer than defaulting straight to the heap.

The honest answer starts with what you give up, not what you add. Eventual consistency, a completely reasonable default for a social feed or a product catalog, is usually not acceptable for balance-affecting operations, since a user briefly seeing a stale balance isn't just a UX rough edge, it can lead to a double-spend if the frontend lets them act on that stale view.

Concretely, that means favoring strongly consistent reads on balance-critical paths even at some latency cost, treating every write as needing an idempotency key by default rather than as an edge case, and building in reconciliation jobs that compare your ledger against upstream sources of truth (a bank, another exchange, a blockchain) on a schedule, because financial systems get audited and "we believe it's correct" isn't sufficient, you need to be able to prove it after the fact.

Proof-of-work ties the right to propose the next block to spent computational effort, which is externally verifiable but expensive and slow to finalize, Bitcoin's roughly 10-minute block time exists because faster blocks would make chain reorganizations, and therefore double-spend attacks, cheaper. Proof-of-stake ties that right to capital already locked in the system, validators post a stake and lose part of it if they act dishonestly, which lets the network reach finality faster since dishonesty is punished economically rather than made computationally impractical.

The tradeoff worth naming explicitly: proof-of-stake systems have to solve the "nothing at stake" problem, since voting on multiple competing chains costs a validator nothing extra the way mining on two chains costs real electricity in proof-of-work, which is why slashing conditions exist specifically to punish that behavior.

A hot wallet keeps private keys accessible to systems connected to the internet, needed for fast withdrawals and day-to-day liquidity, but that connectivity is exactly what makes it a target. A cold wallet keeps keys entirely offline, air-gapped hardware or a similar setup, trading withdrawal speed for dramatically reduced attack surface.

The allocation decision is a liquidity-versus-risk tradeoff, not a fixed number. An exchange sizes its hot wallet to cover expected withdrawal volume over a defined window, say a day or a week, plus a buffer, and keeps the rest cold, moving funds between them on a schedule or by threshold rather than reactively, since a reactive cold-to-hot transfer under withdrawal pressure is itself an operational risk if it's not already a rehearsed process.

Base is an Ethereum Layer 2 built using the Optimism stack, meaning it inherits Ethereum's security guarantees while processing transactions off the main chain for lower fees and faster confirmation, then periodically settling back to Ethereum Layer 1. For a company like Coinbase, owning infrastructure at this layer rather than only building applications on top of someone else's chain gives more control over fees, latency, and the developer experience for anything built on top of it.

The business angle interviewers listen for: Base is also a distribution play, it lowers the barrier for developers building consumer crypto apps by giving them cheap transactions plus an on-ramp into Coinbase's existing user base, which is a different strategic bet than simply running exchange infrastructure.

This targets "efficient execution." Interviewers are listening for the reasoning behind the tradeoff, not just the fact that you shipped fast. What specifically did you cut, why was that the right thing to cut rather than something else, and what was the plan, if any, for closing the gap afterward.

Avoid a version of this story where "imperfect" secretly meant "buggy" or "untested." The tenet is about scope discipline, deciding what doesn't need to be perfect for this release, not about cutting corners on correctness or quality bar.

This is the "clear communication" prompt, and it's usually more revealing when candidates talk about receiving feedback poorly at first, then adjusting, than when they present themselves as having handled everything perfectly. Pick a real instance, describe the feedback specifically rather than vaguely, and be honest about your initial reaction if it wasn't immediately gracious.

What Coinbase interviewers report weighting heavily here: whether the story ends with a concrete behavior change, not just an acknowledgment. "I heard the feedback and thought about it" is weaker than "I heard the feedback and changed X in how I did Y afterward, here's what happened next time."

This maps to "championship team." The instinct is to reach for a pure success story, but interviewers report that answers acknowledging a mistake that shaped an outcome, followed by what changed as a result, often land better than a flawless win, because they demonstrate accountability rather than just competence.

Structure it around your specific contribution and its downstream effect on the team's result, not a general description of a project you were part of. Vague team-success stories where your individual role is unclear tend to read as padding rather than substance.

This tests both "clear communication" and "act like an owner" together, whether you can advocate for a position you believe in without either caving immediately or digging in past the point where it's productive. Pick a disagreement with real substance, not a trivial style preference, and be specific about what you actually said to make your case.

The ending matters more than the middle. If you were wrong, say so plainly and explain what changed your mind. If you were right but didn't prevail, describe how you supported the decision anyway once it was made, since teams that relitigate settled decisions are exactly what "championship team" is meant to screen against.

Another angle on "clear communication," but distinct from the feedback question because it's about translating complexity rather than delivering an uncomfortable message. The strongest answers describe the specific simplification you made, what you cut and why it was safe to cut, rather than just claiming the audience "understood it better afterward."

A good closing detail: mention how you verified they actually understood, a follow-up question they asked, a decision they were then able to make correctly, rather than just asserting comprehension happened.

This question is really asking whether you've thought concretely about ramping up rather than assuming competence transfers automatically. A strong answer names specific, sequenced milestones, understanding the existing codebase and shipping a small fix in the first few weeks, taking ownership of a defined piece of scope by month two, contributing to a design decision independently by month three, rather than a vague statement like "hitting the ground running."

Tailoring the answer to what you actually know about the team's current priorities, from the job description or from earlier conversations in the loop, signals you were listening in prior rounds rather than reciting a stock answer.

Hiring managers ask a version of this to check whether you applied broadly without much thought about fit, or whether you actually looked at what this specific team owns. The strongest answers reference something concrete about the team's actual scope, a product feature, a known technical challenge, a public engineering blog post from that team specifically, rather than restating the general Coinbase mission you likely already covered earlier in the loop.

If you genuinely don't have strong context on the team yet, it's fine to say so and pivot the question back, asking what makes this team's problems distinct from others at the company, which turns a potential weakness into a legitimate, engaged follow-up question.

Model currencies as nodes and each exchange rate as a directed, weighted edge, where the weight from A to B is the rate and the implied weight from B to A is its reciprocal. Finding the best rate from A to B is then a longest-path problem over multiplicative edge weights, which you convert into a shortest-path problem by taking the negative log of each rate, turning multiplication into addition, and running Bellman-Ford or a DFS with memoization if the graph is guaranteed acyclic.

import math
from collections import defaultdict

def best_rate(pairs, rates, src, dst):
  graph = defaultdict(list)
  for (a, b), r in zip(pairs, rates):
    graph[a].append((b, -math.log(r)))
    graph[b].append((a, -math.log(1 / r)))

  best = {src: 0}
  for _ in range(len(graph) - 1):
    for u in list(best):
      for v, w in graph[u]:
        if v not in best or best[u] + w < best[v]:
          best[v] = best[u] + w
  return math.exp(-best[dst]) if dst in best else None

The log transform is the piece candidates most often miss on the first pass. Naming it out loud early, before writing any code, is usually the difference between a smooth 45 minutes and a scramble in the last ten.

This is an external-memory counting problem, not a pure algorithm one. The standard pattern is a two-phase approach: hash-partition the log into smaller files by account ID so each partition fits in memory, count frequencies within each partition, then merge the per-partition top-K candidates using a min-heap of size K to get the global top K.

What actually gets scored here is whether you notice the memory constraint before writing any code. Plenty of candidates jump straight to a Counter and a heapq.nlargest call, which is the right answer for an in-memory version of the question and the wrong answer for the version actually asked. Naming the disk-versus-memory tradeoff up front is the single biggest difference between candidates who pass this one and candidates who don't.

Shard by trading pair or by account ID depending on which access pattern dominates. If most queries are "give me everything for this account" (balances, order history), shard by account ID and accept that cross-account queries, admin reporting, fraud analysis, become more expensive and usually get served from a separate read-optimized replica or warehouse instead of the primary sharded cluster.

If the matching engine itself needs sharding, shard by trading pair, since orders for BTC-USD never need to interact with orders for ETH-USD at the matching layer, which makes trading-pair sharding a natural, low-coordination-overhead boundary. The mistake interviewers watch for is proposing a shard key that requires cross-shard transactions for the hottest, most latency-sensitive operation in the system.

Reentrancy happens when a contract calls an external contract or address before updating its own internal state, and that external call turns around and calls back into the original function before the first call finishes, seeing stale state and potentially draining funds through repeated withdrawals against a balance that was never actually decremented. The infamous DAO hack in 2016 is the canonical example.

// vulnerable: external call before state update
function withdraw(uint amount) public {
  require(balances[msg.sender] >= amount);
  (bool sent, ) = msg.sender.call{value: amount}("");
  require(sent);
  balances[msg.sender] -= amount; // too late
}

// fixed: checks-effects-interactions pattern
function withdraw(uint amount) public {
  require(balances[msg.sender] >= amount);
  balances[msg.sender] -= amount; // update state first
  (bool sent, ) = msg.sender.call{value: amount}("");
  require(sent);
}

The general principle to name, not just the fix for this one bug: checks-effects-interactions, validate conditions, update your own state, then make external calls, in that order, every time. A reentrancy guard modifier is a reasonable belt-and-suspenders addition but isn't a substitute for getting the ordering right in the first place.

Layer 1 blockchains like Ethereum have limited transaction throughput because every node has to process and store every transaction. Rollups move execution off-chain, batch many transactions together, and post a compressed proof or summary back to Layer 1, so the base chain only has to verify a small amount of data per batch instead of every individual transaction.

Optimistic rollups assume transactions are valid by default and rely on a challenge window, typically about a week, during which anyone can submit fraud proof if a batch is wrong, which means withdrawals back to Layer 1 are slow because you have to wait out that window. Zero-knowledge rollups generate a cryptographic proof of validity at the time the batch is submitted, so there's no challenge period needed and withdrawals can finalize much faster, at the cost of the proof generation itself being computationally heavier and historically harder to make fully general-purpose for arbitrary smart contract logic.

Smart contracts can't natively read data from outside their own blockchain, they have no way to know the current price of an asset on their own. An oracle is a service that feeds external, real-world data, most commonly price data, onto the chain in a form contracts can read and act on, lending protocols checking collateral value being the most common example.

Manipulation happens when an attacker can temporarily distort the price an oracle reports, often by exploiting low liquidity on a single decentralized exchange the oracle sources its price from in a flash loan attack, borrow a huge sum, move the price on a thin market, trigger a contract that trusts that price into an unfavorable action like liquidating collateral incorrectly, then repay the loan in the same transaction. The defense is sourcing prices from multiple independent venues and using time-weighted averages rather than a single spot price from a single source, which makes momentary manipulation far more expensive to pull off.

This is where the hiring manager checks whether you'll need constant direction or can operate independently on underspecified work, which matters more at a company hiring for ownership than for pure execution against a fully-specified ticket. The strongest answers describe a repeatable process, not a one-off story: how you identify the smallest testable assumption to validate first, how you decide when to ask a clarifying question versus make a reasonable default assumption and move forward, and how you communicate that assumption to stakeholders so it can be corrected early if wrong.

Naming a specific instance where an assumption you made turned out to be wrong, and how quickly you caught and corrected it, is more convincing than claiming you always get it right on the first try.

This isn't a formality, hiring managers report weighing the quality of candidate questions as a real signal. Weak questions are ones answerable from the public job description. Strong questions probe something specific to that manager's actual experience running the team, current technical debt they're actively wrestling with, how the team's priorities shifted over the last two quarters, what the biggest disagreement on the team has been recently and how it got resolved.

Asking at least one question that could genuinely change whether you'd accept an offer, not just questions designed to look good, is what actually reads as engaged rather than performative.

Two clocks are running here and the design has to decouple them. Ingest events from each exchange as they arrive (every 1 to 2 seconds per source) into a rolling buffer keyed by asset symbol, then run a separate, slower job on a 10-second tick that reads the current buffer contents, computes the average across sources, and publishes it to whatever the frontend subscribes to.

The buffer itself is the interesting part: a sliding window per symbol, either time-bucketed (discard anything older than 10 seconds) or a fixed-size ring buffer if update frequency per exchange is predictable. Fan-out to clients is typically WebSocket or server-sent events rather than polling, since a dashboard showing "live" prices that's actually polling every 10 seconds defeats a lot of the point.

Idempotency keys are the whole answer here. Every event you emit or receive carries a unique key, and before processing an event, you check whether that key has already been recorded as processed in a durable store, an idempotency table with a unique constraint on the key column works well because the database itself rejects a duplicate insert rather than relying on application logic to catch the race.

idempotency_keys
 key (unique), status, result_snapshot, created_at

The subtlety interviewers push on: the check-and-record has to be atomic, not two separate database calls, or two near-simultaneous deliveries of the same webhook can both pass the check before either records itself as processed. A unique constraint plus an INSERT that fails loudly on conflict handles that correctly without needing an application-level lock.

Token bucket is the standard fit here because it naturally supports bursts up to a cap while still enforcing a steady average rate, which matches how API clients actually behave, mostly quiet with occasional spikes. Each customer key gets a bucket sized and refilled according to their tier, a free-tier bucket refills slowly with a small capacity, an enterprise-tier bucket refills faster with more burst headroom.

rate_limit:{customer_id} -> { tokens: int, last_refill: timestamp }

At Coinbase's scale, the bucket state has to live somewhere shared and fast, Redis with a Lua script that does the check-and-decrement atomically is the common answer, since doing it as separate GET and SET calls from application code reintroduces the same race condition problem the idempotency question above has.

The scale concern is the number of active thresholds, not the number of price updates, so the design should avoid checking every user's threshold on every price tick. Group thresholds by asset symbol into a sorted structure (a sorted list or a small interval tree per symbol), so a single price update only needs to check the thresholds near that new price rather than scanning every threshold ever set.

thresholds_by_symbol: { "BTC": sorted_list[(price, user_id, direction)] }

When a price crosses a threshold, push the notification onto a queue rather than sending it synchronously inline with the price update pipeline, since notification delivery (push, email, SMS) has a completely different latency and failure profile than price ingestion, and you don't want a slow email provider to back up your price feed.

A trie is the expected data structure, where each node stores the top few completions for the prefix ending at that node rather than recomputing suggestions on every keystroke. Populate each trie node with a small ranked list, by frequency or recency, computed once during insertion or a periodic rebuild, so a lookup is just a trie walk followed by returning a precomputed list.

class TrieNode:
  def __init__(self):
    self.children = {}
    self.top_suggestions = []

def insert(root, word, freq):
  node = root
  for ch in word:
    node = node.children.setdefault(ch, TrieNode())
    node.top_suggestions.append((word, freq))
    node.top_suggestions.sort(key=lambda x: -x[1])
    node.top_suggestions = node.top_suggestions[:5]

def suggest(root, prefix):
  node = root
  for ch in prefix:
    if ch not in node.children:
      return []
    node = node.children[ch]
  return [w for w, _ in node.top_suggestions]

The real interview happens in the follow-ups, not the trie itself: how do you keep suggestions fresh without re-sorting on every insert, and how would this scale if the trie no longer fits in memory on one machine. Sharding by prefix and pushing ranking updates to an async job are the answers that show you've thought past the toy version.

Start by pinning down matching semantics before touching data structures: price-time priority is the standard and safest default to propose, where orders at the best price are matched in the order they arrived. The order book itself is typically a price-indexed structure, a balanced tree or skip list per side (bids and asks), with a FIFO queue of orders at each price level.

For throughput at 100K orders/sec, the honest answer is a single-threaded, in-memory matching engine per trading pair rather than a lock-free multithreaded design. One thread avoids the correctness bugs that come with concurrent order matching, and 100K ops/sec is well within what a single core handles for in-memory operations. Persistence comes from an append-only write-ahead log, and failover comes from replicating that log via consensus, Raft is the common answer, to a standby that can take over without replaying from a cold snapshot.

The detail that separates a strong answer from a merely competent one: explicitly stating you'd pause matching rather than risk an inconsistent ledger during a partition or failover, instead of optimizing for microsecond latency the interviewer never asked for.

The core decision is append-only, not mutable-balance. Every balance change is recorded as an immutable event (a debit, a credit, a fee), and a user's current balance is derived by summing their event history rather than stored and updated in place as a single row. This makes every state change auditable and replayable, which matters enormously more here than in a typical CRUD system, since a silently wrong balance is a very different kind of incident than a stale cache entry.

ledger_entries
 id, account_id, amount, entry_type, reference_id, created_at

balance(account_id) = SUM(amount) WHERE account_id = ?

Practically, you materialize a running balance in a cache or a snapshot table for read performance, but that cache is always reconstructible from the ledger, never the source of truth itself. Idempotency keys on every write (so a retried webhook or a duplicated trade event can't double-credit an account) is the follow-up almost every interviewer asks about if you don't bring it up first.