Slack Software Engineer interview typically runs 5 rounds: recruiter screen, hiring manager call, technical challenge, system design, behavioral. It usually takes a few weeks and is notably product-specific and hands-on.
$150K
Avg. Base Comp
$236K
Avg. Total Comp
5-6
Typical Rounds
3-5 weeks
Process Length
Our candidates report that Slack is looking for engineers who can operate comfortably in the messy middle between product and infrastructure. The strongest signal isn’t whether you can recite a textbook pattern; it’s whether you can reason through a realistic, Slack-shaped problem and explain the tradeoffs clearly. One candidate described a mapping-system design prompt, while another was asked to build command-triggered integrations and think through a search-suggestions API. That tells us Slack cares a lot about whether you can translate ambiguous user needs into systems that feel native to the product.
A recurring theme is that Slack seems to value practical judgment over polished answers. Multiple candidates mentioned code exercises that were tied to an actual app or buggy codebase, including debugging delayed responses and extending a Slack-like chat application with features such as private channels. In those moments, what makes or breaks the interview is not speed alone, but how well you can inspect unfamiliar code, identify failure modes, and make sensible choices under constraints. We’ve also seen motivation come up early and often, so the company is clearly screening for people who can articulate why they want to build in this environment, not just why they want a software engineering role.
The pattern across experiences is a fairly high bar for systems thinking, especially when the prompt is open-ended. Slack appears to reward candidates who can stay grounded in user impact while discussing architecture, reliability, and integration behavior in the same breath. If there’s one non-obvious takeaway, it’s that the interviewers seem to care less about a perfect solution than about whether your reasoning feels like someone who has actually shipped and supported product-facing software.
Synthetized from 2 candidates reports by our editorial team.
Had an interview recently?
Share your experience. Unlock the full guide.
Real interview reports from people who went through the Slack process.
The process was fairly structured and started with a recruiter screening, which felt pretty standard and mostly covered my background and interest in Slack. After that I had a chat with a staff engineer, and then a technical challenge where I had to build a mini-app. That was probably the most hands-on part of the process and felt more practical than a pure algorithm exercise. The final stage was a virtual onsite with four separate interviews with the team, and two of those were system design rounds. One of the design prompts I got was how I would design a mapping system, so it was less about memorizing a template and more about thinking through product and architecture tradeoffs in real time.
The behavioral side was also present throughout, not just at the end. In the earlier conversations I was asked why I wanted to work at Slack, so it was clear they cared about motivation and fit as much as technical depth. Overall, the process felt fairly demanding because it combined a build exercise, multiple team interviews, and repeated system design discussions. I didn’t get an offer, but the interviews were professional and the expectations were clear. If you’re preparing, I’d focus on being able to talk through a product-oriented mini-app build and on practicing system design in a way that explains your reasoning, especially for open-ended prompts like mapping or similar infrastructure problems.
Prep tip from this candidate
Be ready for a hands-on mini-app build, not just coding questions, and practice explaining your approach in system design rounds where the prompt is open-ended, like designing a mapping system.
Share your own interview experience to unlock all reports, or subscribe for full access.
Sourced from candidate reports and verified by our team.
Topics based on recent interview experiences.
Featured question at Slack
Select the 2nd highest salary in the engineering department
| Question | |
|---|---|
| Top Three Salaries | |
| Empty Neighborhoods | |
| Merge Sorted Lists | |
| Subscription Overlap | |
| Prime to N | |
| Rolling Bank Transactions | |
| Random SQL Sample | |
| Comments Histogram | |
| Raining in Seattle | |
| Customer Orders | |
| Upsell Transactions | |
| String Shift | |
| Closest SAT Scores | |
| Find the Missing Number | |
| Weighted Keys | |
| P-value to a Layman | |
| Scrambled Tickets | |
| Largest Salary by Department | |
| Hurdles In Data Projects | |
| Delivery Estimate Model | |
| Monthly Customer Report | |
| First Touch Attribution | |
| Download Facts | |
| Size of Joins | |
| Google Maps Improvement | |
| Over 100 Dollars | |
| Find Bigrams | |
| Minimum Change | |
| Last Transaction |
Synthesized from candidate reports. Individual experiences may vary.
An initial conversation with a recruiter to cover your background, interest in Slack, and basic role fit. In one experience, the recruiter reached out directly and this step was described as fairly standard.
A conversation with the hiring manager that followed the recruiter screen in at least one process. This round was used to discuss motivation, experience, and likely team fit before moving into technical evaluation.
A technical conversation with a staff engineer early in the process. This stage appeared to assess technical depth and readiness for the more hands-on challenge that followed.
A practical assignment that was either a mini-app build or a code review/debugging exercise. Candidates described it as product-oriented and open-ended, such as working through a buggy codebase, debugging a service delay, or adding a feature to a Slack-like app.
A final virtual onsite with multiple separate interviews, typically including system design, coding, and behavioral rounds. One experience had four interviews total, with two system design discussions focused on real-world tradeoffs like designing a mapping system or a command-triggered API integration.