A Walkthrough Guide to Finding an Engineering Job at Slack

Interviews, eh? Horrid, stressful ordeals that fly by in a sweaty mess and then linger long in the memory. Or, at least, that’s the traditional model. But why on earth would anyone want that? They should be a chance for you to show your best self and to find out if you want to work somewhere.

“Somewhere”, in this case, being Slack.

We’ve put a great deal of effort into designing our interview process so that it is comprehensive and consistent, and are working hard to remove as many points of bias as possible. To date we’ve found it successfully identifies people who will succeed here — those with a high degree of technical competence who also embody Slack’s values: empathy, courtesy, craftsmanship, solidarity, playfulness, and thriving.

What we look for in interviewees

First and foremost we look for skilled engineers who are passionate about programming and display a high degree of craftsmanship. We value those who can level up their whole team rather than just themselves, and who have a passion for exploration and inquisitiveness about how things work and what our customers need. People who are highly collaborative and understand the value of a diverse team with different backgrounds, thoughts, ideas, and lived experiences do very well at Slack, as well as those who take personal responsibility for their decisions and get stuff done.

What does the interview process look like?

Candidates do their best in interviews when they know up front what to expect, so here’s an outline of our process. We follow the same process for all web engineering candidates, regardless of position or level of experience:

1. Resume screen
At a high level, we’re evaluating if you’re a good fit for the role you applied for — there are many amazing, talented people, but not all will be a great fit for Slack (and Slack won’t be a great fit for everyone). We aren’t concerned with where, or even if, you went to college as much as your experience and the passion for your work.

2. A phone call with one of our technical recruiters
This takes around 30 minutes and covers high-level questions about what you’re looking for and why you’re interested in Slack.

3. A technical exercise
We’d like to get an idea of how you write code in the real world, since we feel this is the best indicator of how you’d write code day to day here at Slack. Granted, the Slack codebase is larger and more complicated than any technical exercise, but we have found the technical exercise to be a good indicator of future performance on the job. There are great engineers at big name companies and at small ones, so this gives everyone a chance to shine independent of where they are now.

This varies by position, but generally you’ll have a week to complete a technical exercise and submit the code and working solution back to us.

Since we don’t do any whiteboard coding during the onsite interview, the technical exercise is one of the best ways we’ve found to evaluate programming competency.

The exercise is graded against a rigorous set of over 30 predetermined criteria. We’re looking for code that is clean, readable, performant, and maintainable. We put significant effort into developing these criteria to ensure that, regardless of who grades the exercise, the score is an accurate reflection of the quality of the work. We do this to limit bias. If there are clear criteria, variations that might impact score but have nothing to do with the candidate (such as if the grader is having a good day) are less likely to influence the outcome.

It is important to note that we go to great lengths to ensure the technical exercise is graded as blindly as possible. For the majority of positions the person grading the exercise has not seen the name or resume of the person submitting it (we are working towards this for all positions). Some positions require candidates to submit a working version of their coding exercise and some candidates choose to host it on their website, so we are exploring ways to mask the URL from graders.

We cannot emphasize enough that the coding exercise is the most important way for us to evaluate your technical skills. If you’re selected to come in for an onsite interview, a portion of that interview will be devoted to discussing this exercise, including the choices and tradeoffs you made.

4. A phone call with the hiring manager
This usually takes 1 hour and is an in-depth conversation about your background, current technical challenges you face and what you’re looking for in your next role. We welcome and encourage any questions, so come prepared with the list of things you’d like to know about Slack.

5. An onsite interview
This usually takes around 4 hours. You’ll talk to 4–5 people from the engineering team, each for 45 minutes, followed by 15 minutes with the hiring manager. Our onsite interview focuses on technical and architectural discussions as well as determining how the values we care about at Slack fit with your own.

As mentioned earlier, we won’t ask you to solve algorithm questions or write code on the whiteboard (although we may use the whiteboard to have you draw out how you envision a system being built). Whiteboard coding often skews towards people who have a lot of experience and practice with whiteboard coding, which is not something that’s part of the day to day job at Slack.

To be clear, we often use a whiteboard to hash out ideas, but not to code up a binary search algorithm (or any coding problem). Interviews are stressful, and when the candidate is asked to do something they don’t normally do and do it in front of someone judging them, it introduces a performance dynamic that can be alienating.

There is no need to bring a computer to the interview, nor are there any specific subjects you should study up on. We want to get a good idea of how you think about building and debugging complex systems at a high level, which is not something you can necessarily study for.

Every person you speak with will leave time for questions — remember, you’re interviewing us as much as we are interviewing you. We want to make sure that Slack is a place you will enjoy working and can thrive in from both your perspective and ours!

What technologies does Slack use?

Many candidates ask about our tech stack and the interesting engineering challenges we face. As a rapidly growing company the challenges are often moving and changing at a high rate, but here is an overview.

Slack is a distant descendant of a conventional LAMP stack app: Linux, Apache, MySQL, and PHP all play important roles in the server-side of Slack.

We’ve extended our database layer to do automatic sharding, failover and caching. We have built a distributed, asynchronous job scheduler and execution engine. We deliver messages and notifications via a custom real-time messaging server and perform intelligent edge-caching in an application-aware way. So far, we have found that each order of magnitude beyond which Slack needs to grow requires creative rethinking of the back-end and front-end, and we know that we have more rounds of this kind of challenge ahead.

Our current challenges include:

• Our real-time message server, responsible for most of the real-time interactions happening in various clients, is implemented in Java, and accessed via a WebSocket API. A lot of what makes Slack feel like Slack is the result of careful work on the message server. Many of the distributed systems challenges we face on the back-end are in coordinating this service with the rest of the (LAMP-ier) back-end. This server is critical to Slack, and we have a boundless appetite for it to scale, perform better, and be more reliable.
• Building and operating a worldwide fleet of cache and proxy servers to make Slack as fast as possible for our users around the world.
• Improving the harvest and yield of our data infrastructure, currently built on Presto, Hive, and Spark.
• Building and delivering smooth, native-feeling clients on a diverse set of platforms.

Major languages in use include:

• Our back-end uses PHP for application logic and Java for our real-time messaging server. Our services and portable native libraries are in Go and C++.
• Our web client uses Smarty and Handlebars for templating, jQuery for DOM manipulation, and is mostly native JavaScript (no frameworks).
• Our Data Engineering team is especially polyglot, using Scala for data pipelines, Java for UDFs in Hive and Presto, Go and Python for our custom workflow engine, and PHP/JavaScript to instrument front-end and back-end code.
• Our iOS app is written in Swift and Objective-C, while our Windows Phone app is written in C# and our Android app in Java. Our desktop apps are written in a mix of Objective-C, C++ and JavaScript, using Electron.

All of our code lives in git and GitHub and we use a variety of tools, some homegrown and some externally built, to manage the commit, test, review, build, deploy cycle in a very automated fashion. We are proud that our developer tools infrastructure allows us to safely and confidently update Slack >50 times a day in production.

How should I apply?

Our careers page lists all of our open engineering roles — if you spot one that looks like a great fit, apply online (but please don’t apply for multiple roles). We look at all resumes and do our best to respond within 1 week.

Many candidates think they need to find someone currently at Slack to “get their foot in the door.” Rest assured this is not the case; in fact most of our hires have come from people who have applied via our careers page. We take all applications seriously. We care deeply about diversity at Slack and when you only hire from your current employees’ networks, you tend to get a homogenous set of candidates.