Coinbase·Software Engineer·Technical Phone Screen·Senior

SeniorPrefer not to say

Jul 2026

Summary

Coinbase software engineer interview with a multi-level coding problem centered on building an NFT minting and management system from scratch. The problem escalated across three levels, from basic ownership tracking to transfers to royalty calculations, and you had to define your own test cases and parse input yourself.

Questions Asked (3)

Implement a basic NFT minting system where you can mint an NFT with a creator and metadata, look up the current owner, and list all NFTs owned by a given user.

Data ModelingAlgorithms & Data Structures

Author's notes

First level felt manageable.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and defining the data model: an NFT with a unique token ID, creator, metadata, and current owner. Then design the core operations (mint, ownerOf, tokensOfOwner) using appropriate data structures like a mapping for ownership and a reverse index for efficient lookups. Discuss trade-offs, edge cases, and potential extensions like transfer and events.

Pro tip: Demonstrate awareness of real-world NFT standards (e.g., ERC-721) and mention how your design aligns with or simplifies them. Also, proactively discuss gas optimization or storage efficiency, which is crucial for blockchain systems.

1. Clarify Requirements and Assumptions

Ask questions to confirm scope: Is this on-chain or off-chain? Should we support transfers? What metadata format? Clarify uniqueness of token IDs and whether creator can mint multiple NFTs.

2. Define Data Model

Specify the NFT struct (tokenId, creator, metadata, owner) and choose data structures: a mapping from tokenId to NFT for ownership lookup, and a mapping from owner to a list/set of tokenIds for listing owned NFTs.

3. Design Core Operations

Outline mint (create NFT, assign owner, update indexes), ownerOf (return owner from mapping), and tokensOfOwner (return list from reverse index). Consider access control and validation.

4. Analyze Complexity and Trade-offs

Discuss time/space complexity of each operation. For tokensOfOwner, using a dynamic array may cause duplicates or require removal on transfer; consider using a set or linked list for efficient add/remove.

5. Address Edge Cases and Extensions

Mention handling of non-existent token IDs, duplicate mints, and potential transfers. Suggest how to extend to support transfers, events, and metadata standards like ERC-721.

Key Points to Mention

Use of mappings for O(1) ownership lookup and reverse index for listing owned NFTs.
Trade-offs between array and set for tokensOfOwner: arrays are simple but removal is O(n); sets offer O(1) add/remove but may have overhead.
Importance of unique token IDs and how to generate them (e.g., counter).
Consideration of gas costs and storage optimization in a blockchain context.
Alignment with ERC-721 standard: ownerOf, balanceOf, tokenOfOwnerByIndex, and events like Transfer.
Handling of metadata: on-chain vs off-chain (e.g., IPFS hash) and its implications.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Add transfer functionality so ownership can move between users, with validation that only the current owner can initiate a transfer, and maintain a full transfer history per NFT.

Data ModelingSystem DesignTechnical Trade-offs

Author's notes

Transfer history tripped me up a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints, then propose a data model that captures ownership and transfer history. Walk through the transfer flow with validation, and discuss trade-offs around storage, consistency, and scalability.

Pro tip: Emphasize idempotency and atomicity in transfers to prevent double-spending or inconsistent state, and consider how you would handle concurrent transfer requests.

1. Clarify Requirements

Ask about expected scale, consistency needs, and whether transfers should be immediate or require confirmation. Confirm if history must be immutable and queryable.

2. Design Data Model

Propose an NFT entity with an owner field and a separate transfer history table/collection. Consider using an append-only log for history to ensure auditability.

3. Implement Transfer Logic

Outline the transfer function: validate caller is current owner, update ownership, and append a transfer record. Use transactions or atomic operations to ensure consistency.

4. Address Concurrency and Security

Discuss locking, optimistic concurrency, or idempotency keys to handle simultaneous transfer attempts. Ensure only authorized users can initiate transfers.

5. Discuss Trade-offs and Scalability

Compare on-chain vs off-chain storage, SQL vs NoSQL, and synchronous vs asynchronous history updates. Mention indexing strategies for efficient history queries.

Key Points to Mention

Ownership validation: check that the sender is the current owner before allowing transfer.
Atomicity: use database transactions or blockchain smart contracts to ensure ownership update and history append happen together.
Transfer history: store as an append-only log with timestamps, sender, receiver, and transaction ID for auditability.
Idempotency: prevent duplicate transfers by using unique request IDs or nonces.
Concurrency control: handle race conditions with locks, versioning, or serializable isolation.
Scalability: consider partitioning history by NFT ID or using a time-series database for efficient queries.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Extend the transfer system to support a sale price, where the original creator automatically receives a royalty percentage from every secondary sale, the seller gets the remainder, and balances are tracked per user with proper error handling.

System DesignData ModelingTechnical Trade-offs

Author's notes

This is where things got interesting and also where I started fumbling a bit.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then design a data model that tracks ownership, sale prices, and royalties. Walk through the transfer flow with atomic balance updates and error handling, and discuss trade-offs like precision, concurrency, and scalability.

Pro tip: Emphasize idempotency and atomicity in balance updates to prevent double-spending or lost royalties, and mention using a database transaction with proper isolation levels.

1. Clarify Requirements

Ask about royalty percentage rules (fixed or per-item), currency, precision, and whether royalties apply to all future sales. Confirm error handling expectations and concurrency requirements.

2. Design Data Model

Define entities: User (with balance), Item (with creator, current owner, sale price, royalty percentage), and Transaction (with buyer, seller, amount, royalty amount, timestamp). Consider using a ledger for auditability.

3. Define Transfer Logic

Outline the steps: validate sale, calculate royalty and seller proceeds, update balances atomically, record transaction, and handle errors like insufficient funds or invalid ownership.

4. Address Concurrency and Errors

Discuss using database transactions with locking or optimistic concurrency to prevent race conditions. Specify error handling: rollback on failure, return meaningful errors, and ensure idempotency.

5. Discuss Trade-offs and Scalability

Talk about precision (use decimal or integer cents), performance implications of ledger vs. direct balance updates, and how to scale with sharding or caching.

Key Points to Mention

Use a ledger-based system for auditability and to track all balance changes.
Ensure atomicity of balance updates using database transactions.
Calculate royalties with proper rounding and precision (e.g., using integers for cents).
Handle concurrency with locking or optimistic concurrency control.
Implement idempotency to prevent duplicate transfers.
Provide clear error messages and rollback mechanisms for failed transactions.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.