How Coinbase interviews for engineering roles

Posted on by

Coinbase is on a mission to increase economic freedom in the world. In order to achieve this mission, we need to build a high performing team. Our top priority is attracting and retaining great talent. and we take extraordinary measures to have exceptional people in every seat. This post is designed to give candidates a sneak preview of what we look for in our technical interview process.

In this post we’ll focus on what we look out for in an engineering candidate. Some of this advice will apply to other positions too, but it’s most useful if you want to join us as an engineer.

When joining the interview process you’ll progress through a series of stages. In each stage we’ll assess you in different ways to ensure the role you’re interviewing for is a good mutual fit. While the exercises and questions you face will vary, we always look out for the Coinbase cultural tenets:

  • Clear communication
  • Efficient execution
  • Act like an owner
  • Top talent
  • Championship team
  • Customer focus
  • Repeatable innovation
  • Positive energy
  • Continuous learning

Learn more about these tenets here. You may not get an opportunity to display all of these qualities at every interview stage, but this will give you a good idea of what we are looking for. When we assess your performance we will do so almost exclusively through the lens of these tenets.

The interview stages are (typically but not always):

  • an initial chat with someone from HR about the role
  • one 60 minute pair programming problem
  • one or two 60 minute engineering manager interviews
  • one or two 60 or 90 minute pair programming interviews
  • one or two 60 minute system design interviews

You will need to perform well at all stages to get an offer, so it’s important to prepare for each interview stage. That said, most people that are unsuccessful in their Coinbase interview loop fail on the pair programming stages. Let’s start there.

Pair Programming

In the pair programming interview(s) you will work through a problem with one of our engineers. To start, your interviewer will provide you with a short brief of the problem. Now it’s up to you to code a solution to the problem.

It’s not enough to solve the problem to pass this stage. We are not looking for a minimal Leetcode-style optimal solution. We are looking for evidence that you are able to produce production-grade code. As a result, we assess both the end result and how you got to the result, giving credit for both components. If you get stuck on a bug, how do you overcome it? Do you know your tooling well? Do you use the debugger with a breakpoint, or do you change random lines of code until it works? Is there a method to how you approach a coding problem?

We will look beyond the completeness and correctness of your solution. We will assess the quality and maintainability of your code, too. Is your code idiomatic for your chosen language? Is it easy to read through and understand? What about variable naming? Do you leverage the tooling that is available to you in your IDE and terminal? How can we be confident that your code is correct? Did you test it?

How well do you understand the problem? Do you ask relevant clarifying questions? How well do you take the interviewer’s feedback?

Don’t be discouraged if you do not reach the very end of the problem. We design our interview problems to fill more than the allotted time. The interviewer will stop the interview after either 90 minutes have passed, or when they are confident in their assessment. Ending an interview early is not always a bad sign.

Most candidates who fail the interview do so because their code or process isn’t good enough. We do not typically fail you for an incomplete solution.

Let’s look at a practical example. Suppose the problem is:

Given a list that contains all integers from 1 to n — 1. The list is not sorted. One integer occurs twice in this list. Write a function that determines which.

Here’s the first example solution (there are errors!):

def duplicates(integers):
"""duplicates takes a list of integers and returns the first duplicate value or None if all values are unique"""
 if not isinstance(integers, list):
  raise ArgumentError(“expected list as input”)
sorted_integers = integers.sort()
previous_value = nil
for x in sorted_integers:
 if x == previous_value:
  return x
 previous_value = x
 return None
def test_duplicates():
 assert duplicates([]) == None, "empty array is considered unique"
 assert duplicates([1, 2]) == None , "array of unique values returns None"
 assert duplicates([1, 2, 2]) == 2, "duplicate returns the duplicate integer"
 assert duplicates([1, 2, 2, 1]) == 2, "multiple duplicates returns the first duplicate"

And the second solution (there are errors here, too!):

def dupilcateIntegers(l ):
 n = len(l)
 return sum(l) - ((len(l)+1) * len(l))/2

The first solution doesn’t actually solve the problem. But the author seems to have thought about error handling and input validation. The candidate has thought about the problem and its edge cases. Furthermore the solution attempts to also solve for a larger and more general class of the same problem. They’ve added a short docstring and the code is generally well-formatted and idiomatic python. We would be inclined to consider the first solution a pass. There’s a bug in the implementation and the algorithm is not optimal yet the code is maintainable and generally well structured (with tests too!). This solution is good.

The second solution is correct and optimal, yet this candidate would not pass the interview. The formatting is sloppy and there are spelling mistakes, and unused variables. The code itself is terse and difficult to understand. This candidate would probably be rejected.

Finally, also keep in mind that you have only 90 minutes to complete the problem. Our problems don’t really have any tricks in them, and the naive solution is typically good enough. We won’t ask you to invert a binary tree, but we will ask you to solve a simplified version of a real life problem. We’re looking for production-like code, not hacky solutions.

So how would you best prepare for the pair programming interview with us? Don’t focus too much on grinding Leetcode. It’s better to focus on the fundamentals. Learn your editor, your debugger, and your language. Practice writing well formatted and well structured code with relevant method and variable names, good state management and error handling.

System Design

In our system design interview you will be asked to design the general architecture of a real-world service. For example: How would you design a Twitter feed?

The brief is typically short, and it’s up to you to ask the interviewer for clarifications around the requirements.

Don’t dive too deeply into any one specific aspect of the design (unless asked by the interviewer). It’s better to keep it general and give a specific example of a technology you know well, that would be a good fit for the use case at hand. Example: “For this service an RDBMs database would be a good choice, because we don’t know exactly what the queries will look like in advance. I would choose MariaDB.”

Be sure to address the entire problem, and if you’re unsure if you’ve covered everything ask the interviewer to clarify, or if there’s anything they’d like you to expand upon.

If you are unsure about the specifics of a particular component in your design, it’s best to try to let your interviewer know and to tell them how you would go about finding the answer. Don’t wing it — being wrong with confidence is a negative signal, whereas humility is a positive signal. A good answer might be: “I don’t know if the query pattern and other requirements fit well with an SQL database here, but I have the most experience with MariaDB so it would be my default choice. However, before making a decision I would have to research what its performance might look like in this specific case. I’d also research some NoSQL alternatives like MongoDB and perhaps also a column wide store like Cassandra.”

You’ll be assessed on your ability to explore the requirements, and how well your design might perform in real life. Do you take scalability into account? How about error handling and recovery? Do you design for change? Have you thought about observability? You’ll also be assessed on how well you communicate your design and thoughts to the interviewer.

General Tips

During our interview process, we look for signals that help us understand whether there is a skill match but more importantly a cultural fit. Some of the signals we look for:

  1. Be honest — Honesty always pays. If you’ve seen the question before, best to let your interviewer know so that an alternate question can be discussed. Similarly, exaggerating current scope/responsibilities is considered a red flag.
  2. Speak your mind — Even if the question might seem difficult or you need time to think, vocalize your thoughts so that the interviewer can help you along. It’s not as important to get the right answer as it is to have a reasonable thought process.
  3. Understand before responding — It’s best to listen and understand the question before responding. If you’re unsure, ask to clarify or state your assumptions. We aren’t looking for a quick response but always appreciate a thoughtful response. If the question isn’t clear the first time, feel free to request the interviewer to repeat it.
  4. Good Setup — Being a remote first company, our interviews are virtual on Google Meet. Take the meeting at a place where the internet connection and your audio/video is good. It’s better to reschedule in advance if your setup isn’t tip-top. Finally, test your microphone and camera an hour before joining the call. We keep our cameras on the entire interview and expect you to do the same.
  5. Be Prepared — We advise that you go through the links your recruiter shares with you as part of the interview invite. They contain information about how everyone at Coinbase operates and what they value.
  6. Ask what’s on your mind — Our panelists always leave time for the candidates to ask questions.Take that opportunity to ask questions that would help you decide your Coinbase journey rather than asking generic questions (most of which are answered on our blog). You will interview with engineers and managers so tailor your questions to the unique perspectives offered by each role.
  7. Crypto or Industry knowledge — Unless you are specifically interviewing for a role that requires deep crypto/blockchain knowledge (your recruiter would be able to share this with you), we aren’t looking for this knowledge as a mandatory skill. As long as you are willing to learn, we want to talk to you — even if you are entirely new to crypto. We all were new at one point too!

Thanks for taking the time to learn a little bit more about our interview process. If you are interested in building the future of finance, have a look at our open roles here. Good luck!

How Coinbase interviews for engineering roles was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.