cswork / libraryOpen practice workspace

Interview guides · Reverb

Reverb Software Engineer Interview Guide

Reverb Software Engineer interview guide: reported rounds, questions and how candidates describe the process.

The 60-second brief

As a Software Engineer at Reverb, you play a crucial role in developing and maintaining the technology that powers one of the largest online marketplaces for musical instruments. Your work directly impacts the user experience by ensuring that the platform runs smoothly, efficiently, and securely. This role is vital not only for the functionality of the website but also for enhancing the overall user journey, from browsing products to completing transactions. Working within a collaborative environment, you'll engage with cross-functional teams to tackle complex challenges. You will be involved in building scalable systems that support the growing demands of both buyers and sellers in the music community.

This guide is scoped to a Software Engineer candidate at Reverb.

Focus areas

  • System Design
  • Coding Challenges (Algorithmic Problem Solving)
  • Algorithms

The Reverb interview process

Reverb candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Phone Screen

Initial call to assess candidate's background and fit for the role.

What to demonstrate

  • Initial call to assess candidate's background and fit for the role
  • Depth in System Design

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.

Technical Assessments

Candidates complete technical assessments to demonstrate their skills.

What to demonstrate

  • Candidates complete technical assessments to demonstrate their skills
  • Depth in System Design

How to prepare

  • Answer aloud and timed: Describe how you would manage state in a React application.
  • Answer aloud and timed: What are the principles of Test Driven Development (TDD)?

Final Interviews

Interviews with key team members to evaluate collaboration and cultural fit.

What to demonstrate

  • Interviews with key team members to evaluate collaboration and cultural fit
  • Depth in System Design

How to prepare

  • Answer aloud and timed: Design a system for a music recommendation engine.
  • Answer aloud and timed: How would you approach building a high-availability web service?

Where candidates lose points

Prepare for Behavioral Questions

Be ready to share specific examples from your past experiences that illustrate your skills and fit for the team.

Practice Coding Challenges

Familiarize yourself with coding interview platforms and practice common algorithms and data structure problems.

Communicate Clearly

During technical discussions, articulate your thought process and reasoning behind your decisions.

Research the Company

Understand Reverb's products, mission, and values to demonstrate your genuine interest in the role and the company.

Questions & practice

Solve a problem involving data structures (e.g., trees, graphs).

Medium · Coding / Algorithms

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Write a function to find the shortest path in a graph.

Medium · Coding / Algorithms

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Implement a caching mechanism in a web application.

Medium · Coding / Algorithms

Approach

  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.

Follow-up

  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

How would you optimize a database query?

Medium · Technical / Domain Questions

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Discuss the trade-offs between SQL and NoSQL databases.

Medium · System Design / Architecture

Approach

  1. Name the grain you start from and join outward from it.
  2. Check whether any join is one-to-many before aggregating, or the sums inflate.
  3. Say which index the query would use, and what makes it unusable.
  4. Handle the rows that do not match: that is usually the actual question.

Follow-up

  • How does the query change if that join becomes one-to-many?
  • What happens to this when the table is ten times larger?

Explain the difference between REST and GraphQL.

Medium · Technical / Domain Questions

Approach

  1. Say who the caller is and what they do when the call fails halfway.
  2. Define the identity of a request so a retry cannot double-apply it.
  3. Separate accepted, pending, failed and confirmed; they are different facts.
  4. Design the error taxonomy before the success shape; callers branch on it.

Follow-up

  • What happens if the caller retries after a timeout?
  • How does a client discover it is on an old version of this contract?

Describe how you would manage state in a React application.

Medium · Technical / Domain Questions

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

What are the principles of Test Driven Development (TDD)?

Medium · Technical / Domain Questions

Approach

  1. Clarify what is being asked and what a complete answer contains.
  2. State your assumptions explicitly before working the problem.
  3. Say what you would check first and why it is the highest-information step.
  4. Work from the requirement backwards to the design.

Follow-up

  • What assumption would you test first?
  • How would you know your answer was wrong?

Design a system for a music recommendation engine.

Medium · System Design / Architecture

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

How would you approach building a high-availability web service?

Medium · System Design / Architecture

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

Given a set of requirements, how would you design a feature from scratch?

Medium · Problem-Solving / Case Studies

Approach

  1. Fix the scope first: who calls this, how often, and what they do when it fails.
  2. Name the read and write paths separately; they rarely have the same bottleneck.
  3. Choose a partition key and say what query it makes expensive.
  4. State the consistency you need, and where you are willing to be stale.

Follow-up

  • What breaks first when traffic grows ten times?
  • How does this behave when that dependency is down for an hour?

How would you approach debugging a performance issue in production?

Medium · Problem-Solving / Case Studies

Approach

  1. Establish what changed and when, before forming any theory.
  2. Pick a bisection that eliminates candidates whichever way it turns out.
  3. Check the instrumentation before believing the symptom.
  4. Separate the trigger from the cause; the deploy is rarely the bug.

Follow-up

  • What would you look at first, and what would it rule out?
  • How would you tell a cause from a coincidence here?

Suggested practice checklist

Built from the rounds and topics Reverb candidates report.

Day 1 — Map the Reverb loop

  • Write out the reported sequence: Phone Screen, Technical Assessments, Final Interviews.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.

Day 2 — Work System Design

  • Spend the session on System Design, which Reverb candidates report being tested on.
  • Write one worked example in System Design and time yourself on it.

Deliverable: One timed worked example in System Design.

Day 3 — Work Coding Challenges (Algorithmic Problem Solving)

  • Spend the session on Coding Challenges (Algorithmic Problem Solving), which Reverb candidates report being tested on.
  • Write one worked example in Coding Challenges (Algorithmic Problem Solving) and time yourself on it.

Deliverable: One timed worked example in Coding Challenges (Algorithmic Problem Solving).

Day 4 — Work Algorithms

  • Spend the session on Algorithms, which Reverb candidates report being tested on.
  • Write one worked example in Algorithms and time yourself on it.

Deliverable: One timed worked example in Algorithms.

Day 5 — Answer out loud: Technical / Domain Questions

  • Answer aloud, timed: How would you optimize a database query?
  • Answer aloud, timed: Explain the difference between REST and GraphQL.

Deliverable: Spoken answers to 2 reported Technical / Domain Questions question(s), under time.

Day 6 — Answer out loud: System Design / Architecture

  • Answer aloud, timed: Design a system for a music recommendation engine.
  • Answer aloud, timed: How would you approach building a high-availability web service?

Deliverable: Spoken answers to 2 reported System Design / Architecture question(s), under time.

Day 7 — Answer out loud: Behavioral / Leadership

  • Answer aloud, timed: Describe a time you had a conflict with a teammate and how you resolved it.
  • Answer aloud, timed: How do you prioritize your tasks in a fast-paced environment?

Deliverable: Spoken answers to 2 reported Behavioral / Leadership question(s), under time.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Describe a time you had a conflict with a teammate and how you resolved it.

Medium · Behavioral / Leadership

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

How do you prioritize your tasks in a fast-paced environment?

Medium · Behavioral / Leadership

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

What motivates you to perform well in your role?

Medium · Behavioral / Leadership

Approach

  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.

Follow-up

  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?