This piece is primarily focused on applying for a position within our Engineering department, but most of it is the same for roles across the company.

Discord’s vision is a world where everyone belongs. Part of creating that world is building a team of people passionate about what we’re doing, with the skills & knowledge to help us get there. Our CEO, Jason, wrote more about our approach to building teams in his blog, The Four Values of Working at Discord.

We know that interviewing can be a daunting prospect at the best of times. However, we also understand that information disparity is one of the ways that the majority’s privilege is reinforced. In this blog post, we hope to be completely transparent on how the hiring gears turn within Discord to give everyone that applies an equal chance at joining the team.

Process Overview

At a high level, the Discord interview process typically moves quickly — as quick as you need it to! — and goes through these steps:

Resume Review. You submit an application to one of our open roles, which is reviewed by our recruiting team, who selects people to talk to. Alternately, we may have reached out to you directly, in which case you’ve already passed the resume review. Fancy you!
Recruiter Screen. One of our recruiters will reach out and set up a time to talk to get to you know a bit and ask some of our more standard questions, such as are you eligible to work in the US, what are your compensation needs, and so on.
Hiring Manager Screen. This is your first chat with the manager who is hiring for the particular role. We’ll go through a set of questions about your background and what you’re looking for at Discord. The goal is to make sure that this will be a good role fit, and if not, we’ll try to find one within Discord that is.
Skills Test. This is a one-hour session with one of our engineers and is a coding interview. We’ll dive more into this later.
Full-day Interview. This is the big one: A full panel that you should plan to dedicate about 5–6 hours to, including a lunch break.

The panel typically includes the following sessions:

Values. This is our chance to learn more about what motivates you and how you handle feedback, conflict, personal growth.
Attitude. In this session, we put you with a couple of Discord staff outside of the team you’re applying to. They’ll get to know you better, learn more about whatever you’re passionate about, and see how you work with people from different roles.
Coding. There are typically 1 to 2 coding sessions spaced between interviews.
Architecture. We’ll hold 1 to 2 architecture sessions for mid to senior roles to see you work through requirements gathering and designing a solution at a high level.
Specialty. For certain roles or more senior roles, we will add a specialty interview session. More on this later.

Following the full-day interview, the team will gather together to share the results of their interview sessions with each other. As a group, we will then decide on whether or not to proceed.

From the full-day interview to the final decision, we move quickly and let you know the result within a few business days.

Before We Begin…

We believe that an effective interview process is designed to evaluate whether you can do the actual job, and not based on trivia or trickery. This theme will come up in each of our sessions that we talk about in detail below.

We strongly value attributes such as empathy and working together effectively. Many of our interviews include assessing this through various means — the way you engage with other roles, the way you collaborate in technical sessions, and so on. We don’t expect you to be 100% extroverted (many of us aren’t!), but the ability to work together is critical to our team.

Finally, many of us aren’t gamers. This is probably the top misconception about working at Discord. It is not expected or required that you be a gamer (of any kind) to work here.

Instead, the things we look for are people who care about the mission and can work together effectively to achieve it.

Now, let’s talk about how we figure that out.

Values: Why Discord?

This is a discussion interview usually administered by one of our more senior managers or other company leaders. The goal of this interview is to figure out what motivates you and how you approach conflict, feedback, and other skills that are useful to building a small and mighty team.

Discord is a mission-driven organization. Yes, we’re working to build a successful business around that mission, but ultimately we’re here because we believe in the vision of Discord and working together to give people the power to create belonging in their lives. It is important to us that anybody we hire is here because they believe in that mission — and so the Values interview will dig into that.

We also want to understand what drives you. Why’d you become an engineer? How do you approach personal growth and learning? What other companies are you interviewing at and why? (We promise we won’t be sad if you’re interviewing at other places at the same time.)

Another tip for this interview: since this is typically given by one of our more senior managers or leaders, this is a great session to ask your big-picture questions. Ask about the vision, our monetization strategy, our culture, etc. This interview is a great opportunity for you to interview us and make sure Discord aligns with your own values!

Attitude: Who you are as a person

If you extrapolate our vision out to workplace culture, it’s probably no surprise to learn that we care a lot about the kind of place we’re creating at Discord. In this session, we’ll team you up with a couple of Discord employees from other parts of the business. If you are applying for an engineering role, your Attitude session will likely include someone from Customer Experience, Marketing, Business Development, Trust and Safety, Design, or one of the many other roles we have at the company.

We want all of our employees to feel that they belong. During the session, the team will ask mostly conversational questions, such as what does everybody do, how did they get to Discord, and why apply at Discord? Outside of Discord, we’ll also ask things like what’s their current job like, how did they work with past teams, and so on.

Interacting with other parts of the company is an expectation of all of our roles. Our engineers interface with staff from other teams constantly, and it’s important that anybody we hire be able to do the same effectively.

Gamers, artists, makers, horticulturists, soft-serve ice cream enthusiasts, musicians, singers — we have a diverse set of interests across the company and are excited to learn about yours!

Technical Interviews: Time to Really Deep Dive

All of our technical interview questions are designed to be based upon real work we’ve done, and problems that have come up in the past.

We don’t ask you to build self-balancing red-black trees in our interviews or describe RAID levels off the top of your head. Trivia has no place in our interviews when we’re still trying to answer the important question of: can this person do the actual job?

After we’ve created an example question, we test it internally with several engineers at different levels of experience, with a variety of backgrounds, and put together an evaluation rubric that objectively defines what we’re looking for.

We try to be specific about what we expect people to do. Some examples of the many things that are on some of our grading rubrics include:

Implemented feature X successfully to specifications.
Understood and demonstrated concurrent programming concepts.
Chosen software architecture that would support adding unit tests without major refactor.
If the candidate has no experience with a technology, they were able to use and understand API documentation effectively.

An interesting part of trying to simulate the actual job, though: use of Google, Stack Overflow, and API docs is expected. We think it’s a bad sign if you don’t use all of the resources at your disposal!

Oftentimes, this can include bouncing your ideas off the interviewer. Consider them as a team member you can collaborate with and gain valuable feedback for the task at hand. While they won’t write the code for you, don’t hesitate to share how you’re thinking through the project and ask for their input or thoughts.

Coding Sessions: Putting Your Head Down to Work

You can expect to do a coding challenge for your skills test for most roles, then one or two coding sessions in the full-day interview. For more senior candidates, we reduce the coding and replace them with architecture sessions.

The specific goals of our coding interviews are to provide practical problems and then see you actually solve them.

The format of the interview is similarly practical. We’ll ask you to use your laptop and be prepared to use whatever your favorite IDE, tools, and programming language are. We want to see you at your best, writing in whatever way you’re used to. If the interview is being done remotely, you’ll need to do a screen share so our interviewer can follow along.

While solving the problem, use all of your standard resources. Google, API documentation, your environment, the interviewer, and anything you traditionally use yourself! This is part of how engineers really work at HQ, and we think the interview should be no different.

Our coding problems have an evaluation rubric that includes:

Does the code compile & run properly, and does it fulfill the question’s requirements?
Do you understand the code you just wrote, including potential runtime analysis? You should know if something is constant time, linear time, or worse.
Given the interview’s time constraints, are you aware of any tradeoffs you made in writing it?
How effectively did you use your environment and resources? Are you comfortable in your editor and in the language you chose?
If it was a problem with stages, how did you approach refactoring your solution to consider the new requirements?
Is the code well abstracted such that it could be tested, whether you wrote tests during the session?

Again, please do talk to your interviewer. You’re more than welcome to ask for feedback as you go, such as when you’re considering a few possible implementation paths.

Architecture: How’d you build it?

Similar to the coding interview, Architecture sessions are designed to see what it’d be like to work with you to design a solution to a problem we’ve actually solved or could anticipate solving down the road.

The interviewer will give you a problem statement, such as “design a URL shortener” and then let you take the reins. We only give architecture questions to people with industry experience, such as senior-level candidates, so we expect you to have done some design in previous roles.

To succeed here, you’ll need to ask a lot of questions. You should work to fully understand the scope required of the solution, what success looks like, and what the valid tradeoffs are in the design. Hint: every design will have tradeoffs!

We recommend spending a few minutes talking through some possible designs and sketching them out on the whiteboard (or in a beautiful sketch in Microsoft Paint if you’re doing this remotely). Depending on the particular question, this may involve talking about code architecture, systems design, data modeling, or any number of similar areas.

Work closely with the interviewer to make sure you’re going in a good direction and the decisions you’re making are aligned with the task’s requirements. Your interviewer is an expert in the problem domain, so you should leverage their knowledge to help you make appropriate tradeoffs.

If you are not asking questions and checking in, it will be hard to succeed at this session. Look before you leap!

We are not evaluating your knowledge of the problem domain. If we ask you to design a system to route calls to the best available backend, but you have no experience with WebRTC, that’s absolutely fine. We’ll be there to help.

Instead, we’ll be evaluating on:

How thoroughly you understood the requirements. Did you ask good questions, seek clarification, and incorporate that into your design?
What tradeoffs you made and why. Were they appropriate to the hypothetical needs of the customer for this problem?
Simplicity. We strongly value choosing both the simplest and best solution that solves the problem, but with an eye towards growth. Will it work at 2x and 10x scale? If not, why?
Clarity in communication. Were you able to effectively describe your chosen architecture and explain it to the interviewer?

Specialty Sessions

There are two main specialty sessions at this point, but we will add more as it makes sense. We still follow the same guidance for any of our interviews, of course, and try to make them objective with a documented success criteria.

The Troubleshooting session is used by the Infrastructure department, designed to see you handle a production incident. We’ll give you a very simple infrastructure diagram with some databases, caches, and web servers, then set up a precipitating event: you get the dreaded page.

The engineer administering the question will then simulate the world for you. You can ask for anything you want, such as dashboards or graphs, or even ask to SSH in to a machine to run some commands and look around.

Of course, since we don’t believe in trivia problems, we don’t expect you to remember command line arguments or anything, but a general idea of what top would tell you could be useful here.

“Getting to root cause” is not an expected outcome of the Troubleshooting session. Most people don’t. If you do, it’s usually because you got lucky and happened to look in the one place that had the critical clue. We’re more interested in seeing your approach to the process and how you understand what’s going on, not whether or not you fix the issue.

Finally, the Project Retrospective session is typically given to management candidates and very senior engineers who might become tech leads one day.

The goal here is to understand your approach to getting better over time. We value our ability to try things and learn from them — failure happens and is expected sometimes, the important part is how you learned from that failure!

We’ll ask you to walk us through a recent project that you shipped where you played the role of leader. We want to hear about the project itself from start to finish, and see your analysis of how it went.

When reflecting on your past project, you should consider how well you understood and describe the success criteria and whether you hit them. What was your understanding of the tradeoffs you made in the project and why they were being made?

Following that project, have you incorporated your learnings and for future projects, and how do you lead your team and keep them aligned, motivated, and engaged?

The Three Most Important Points

At the end of the day, an interview day at Discord is your opportunity to learn about us and make sure that you have what you need to make an informed choice if you get an offer.

The most important part, however, is to know what you want. If you go into your interview process in any company with a clear set of your needs and goals, you’ll be more successful in getting them. Do you want a mission driven organization, or are you more passionate about liquid compensation? Do you want to be a manager at some point? Do you want to lead a team?

Second, ask lots of questions. We’ve said it a lot, but this is truly one of the most valuable ways to figure out if Discord is right for you. You’ll have access to a dozen people from all kinds of roles. Ask what they like, ask what they don’t, and ask follow up questions.

And third, be clear about what you need and what you want. If you’ve evaluated your situation and realized that what you want is mentorship to become a manager, tell us that! If you have specific compensation minimums you need based on your life situation, that’s also helpful to share early so we can tell you immediately if it’s even doable for us. We wouldn’t want you to spend a whole 5 to 6 hour day interviewing if it isn’t something you can accept an offer for.

This is as much your process as it is ours, and we treat the interview as a collaborative effort. We’re happy to do our best to work with you, just let us know what you need, and we’ll see what we can do.

Good luck in your search! If you’re interested in applying for a spot at Discord after reading this, take a look at our open jobs.

We hope to talk to you in the interview room soon! 😄