How to pass the Coinbase software engineer interview

Coinbase largely ditched traditional LeetCode puzzles a while ago. Instead, they focus on practical, progressive machine coding. If you are interviewing for a software engineering role there, you will go up against the Tech Execution and Domain rounds. These sessions really test your ability to write clean, object-oriented code, manage state, and integrate systems under pressure. You will not be reversing a linked list on a whiteboard. Instead, expect to build real-world components like custom meta-iterators, in-memory transactional databases, and cursor-paginated transaction filters. The stakes are high in cryptocurrency; a single bug can result in massive financial loss. Because of this, Coinbase interviewers evaluate you on how safely you handle edge cases and how rigorously you test your own logic.

The Progressive Coding Philosophy

Before breaking down specific rounds, you need to understand how Coinbase structures its technical interviews. They rely heavily on progressive machine coding. This means you are given a single, seemingly simple problem that expands in complexity over 45 to 60 minutes. The interviewer acts as a product manager handing you new requirements as you finish each phase. You will write executable code in CoderPad. The platform compiles and runs your code, so pseudo-code will not save you here.

A typical progressive interview has three to four parts. Part 1 is a basic warm-up to ensure you can write syntax and structure a class. Part 2 adds a functional constraint that forces you to manage internal state. Part 3 introduces a requirement that might break your previous assumptions, testing how modular and extensible your initial design was. Part 4 usually involves a tricky edge case or a performance optimization. If you hardcode solutions or write monolithic functions in Part 1, you will run out of time refactoring in Part 3.

The Tech Execution Round: Mastering State and OOP

This round evaluates your mastery of language fundamentals and object-oriented design. The interviewer wants to see how you encapsulate logic, name your variables, and manage internal state without creating a tangled mess of boolean flags. The classic prompt for this round is building a custom iterator from scratch.

You might kick things off by implementing a basic iterator over a flat array. You define a class with hasNext and next methods. Just when you get comfortable, the interviewer adds a twist. They ask you to build a Peekable Iterator. A peek method lets you look at the next element without advancing the iterator pointer. The trap here is overcomplicating the state. Many candidates try to manipulate the underlying array index or use multiple boolean flags like has_peeked. The cleaner approach is to use a single cached variable. When peek is called, you fetch the next item from the base iterator and store it in the cache. Subsequent calls to peek just return the cache. When next is called, you check if the cache has a value; if it does, you return the cache and clear it. Otherwise, you fetch directly from the base iterator.

The next progression is often an Interleaving Iterator. You are given a list of iterators and must yield their elements sequentially. If you receive Iterator A (1, 2) and Iterator B (3, 4), your output should be 1, 3, 2, 4. The optimal way to solve this is by using a queue of iterators. You pop the first iterator from the queue, extract its next value, and if it still has elements left, you push it back to the end of the queue. This avoids complex arrays of pointers and naturally handles iterators of different lengths.

• Step 1: Define a clear interface for your base iterator to ensure polymorphism.
• Step 2: For the Peekable Iterator, use a dedicated cache variable and a boolean flag to track if the cache is populated (since null might be a valid value in some languages).
• Step 3: For the Interleaving Iterator, initialize a standard FIFO queue. Enqueue all non-empty iterators.
• Step 4: On next(), dequeue the front iterator, get its value, and requeue it if hasNext() is true.

Alternative Tech Execution Prompt: The Transactional KV Store

Another highly common Tech Execution question is the in-memory key-value store with transaction support. You are asked to build a class that supports GET, SET, and DELETE operations. That is the easy part—just wrap a standard hash map or dictionary. Then comes Part 2: implement BEGIN, COMMIT, and ROLLBACK.

BEGIN starts a new transaction, meaning any SET or DELETE operations are temporary until COMMIT is called. If ROLLBACK is called, all changes since the last BEGIN are discarded. The catch is that transactions can be nested. You might call BEGIN, then another BEGIN, then ROLLBACK the inner transaction while keeping the outer one active.

The secret to passing this question is using a stack of dictionaries. Your global state is the dictionary at index 0. When BEGIN is called, you append a new, empty dictionary to the stack. When SET is called, you write the key and value to the dictionary at the top of the stack (stack[-1]). When GET is called, you iterate backwards through the stack from top to bottom, returning the first value you find for the requested key. If you encounter a special deletion marker (a tombstone), you return null. When COMMIT is called, you pop the top dictionary and merge its keys into the new top dictionary. When ROLLBACK is called, you simply pop the top dictionary and discard it. This stack-based approach handles infinite nesting effortlessly and keeps your code perfectly modular.

The Domain Round: Business Logic and Systems Integration

While Tech Execution focuses on abstract data structures and state manipulation, the Domain round shifts focus to concrete business problems. Coinbase wants to see how you translate product requirements into API design and business logic. You will be dealing with concepts like transaction feeds, user balances, and risk limits. A classic prompt is building a transaction ledger.

You start by creating a system that processes deposits and withdrawals. You need to maintain an accurate user balance and a history of transactions. The interviewer will watch how you handle edge cases like insufficient funds or negative deposit amounts. Throwing descriptive errors instead of silently failing is heavily rewarded here. Then, they will ask you to build a reporting function that fetches the user's transaction history. This leads directly into the pagination trap.

The Pagination Trap: Offset vs Cursor

Financial systems demand stable, perfectly consistent data reads. If a user is scrolling through their transaction history, they should never see the same transaction twice, nor should they miss one. The interviewer will ask you to paginate the transaction history, returning 50 records at a time. Most candidates instinctively reach for offset-based pagination.

Offset pagination works by skipping a set number of rows. To get page two, you query for LIMIT 50 OFFSET 50. The flaw here is data shifting. If the user receives three new transactions while they are viewing page one, all existing transactions shift down by three positions. When they click to page two (OFFSET 50), they will see three transactions they already saw on page one, because those items were pushed into the offset window. In a financial app, showing duplicate transaction records causes immediate user panic.

To pass this round, you must implement cursor-based pagination. A cursor acts as a fixed pointer to a specific record. Instead of saying 'skip 50 records', you say 'give me 50 records that occurred before transaction ID X'. Because you are in CoderPad without a real database, you have to write this logic in application memory. You will need to sort your in-memory array of transactions by timestamp descending. Your cursor should be a combination of the timestamp and a unique transaction ID (to handle tie-breaking if two transactions happen at the exact same millisecond). Your fetch function takes this cursor, binary searches the sorted array to find the exact index of the cursor, and slices the next 50 elements.

• Create a Transaction class with an amount, type, timestamp, and a UUID.
• Store transactions in a list and maintain a sorted order based on timestamp (descending).
• Design the fetch_history method to accept a cursor object containing last_timestamp and last_id.
• Iterate or binary search through the list to find the first transaction strictly older than the cursor.
• Return the slice of the next N transactions, along with a new cursor generated from the last item in that slice.

Alternative Domain Prompt: The Limit Order Book

If you are interviewing for a team closer to the exchange engine, you might be asked to build a simplified limit order book. An order book matches buyers (bids) with sellers (asks). Buyers want to pay as little as possible, but the highest bid takes priority. Sellers want to charge as much as possible, but the lowest ask takes priority.

The optimal data structure for this is two priority queues. You use a Max-Heap for the bids and a Min-Heap for the asks. When a new buy order arrives, you peek at the top of the Min-Heap (the cheapest available sell order). If the buy price is greater than or equal to the sell price, you have a match. You then execute the trade. The complexity comes from partial fills. If the buyer wants 10 coins but the seller only has 4, you must completely remove the seller's order from the heap, subtract 4 from the buyer's quantity, and keep checking the next best ask until the buyer is completely filled or the price no longer crosses.

In CoderPad, you will need to implement or import heap structures carefully. Python developers can use the heapq module, but remember that heapq only implements min-heaps. To create a max-heap for the bids, you must invert the price by multiplying it by -1 before pushing it onto the heap. Documenting these small language-specific quirks out loud shows deep familiarity with your tooling.

Time Management and Communication Strategy

Progressive coding interviews are marathons disguised as sprints. You have about 45 minutes to write 100 to 200 lines of robust, tested code. Pacing is everything. Do not over-engineer Part 1. If you spend 20 minutes setting up abstract base classes and interfaces for a simple array iterator, you will run out of time before reaching the complex logic in Part 3 that actually determines your hire status.

Talk while you type, but do not narrate your syntax. The interviewer can see that you are writing a for-loop. Instead, explain the 'why' behind your decisions. Say things like, 'I am using a dictionary here instead of an array because we need O(1) lookups for the transaction IDs later, and memory is not our primary constraint.' This proves you are making intentional engineering tradeoffs.

The Testing Mandate

At Coinbase, untested code is considered broken code. Do not wait for the end of the interview to test your logic. Adopt a lightweight Test-Driven Development approach. After you finish Part 1, write three quick assertions. When you move to Part 2, add three more. This incremental testing proves that your new features do not break existing functionality.

Focus heavily on edge cases. If you are building the transaction ledger, what happens if someone deposits zero dollars? What if they try to withdraw more than their balance? What if the pagination cursor points to a transaction that was just deleted? Writing tests for these scenarios shows product empathy and a security-first mindset, which are highly valued traits in the crypto space. By mastering state management, understanding financial data patterns like cursor pagination, and rigorously testing your code, you will be well-positioned to clear the Coinbase engineering loop.