Intervu is in beta — feedback welcome at support@intervu.io

Slack DevOps / SRE Interview Questions

30 real practice questions for the mid-level DevOps / SRE role at Slack (Communications / Productivity), spanning behavioral, technical, system design, leadership, and problem solving. Build and maintain infrastructure, CI/CD pipelines, and ensure system reliability. The first 3 questions below include what Slack interviewers actually listen for, plus likely follow-ups.

Questions
30
Categories
Behavioral (6), Technical (6), System Design (6), Leadership (6), Problem Solving (6)
Difficulty mix
10 easy · 10 medium · 10 hard
Avg. answer time
~4 min

Behavioral Questions (6)

  1. 1.Tell me about a time a quieter or less senior teammate had an insight about infrastructure or reliability that your team almost missed. How did you surface it, and what happened?

    easy~3 min

    What interviewers look for

    • Candidate proactively created space for the quieter voice — didn't just wait for it to emerge organically (e.g., directly asked in a retro, 1:1, design review, or async thread).
    • The outcome was meaningfully better because of the surfaced perspective — not just a feel-good moment but a real technical or operational improvement.
    • Candidate reflects on why the voice was quiet in the first place and what structural change they made so it wouldn't happen again.

    Likely follow-ups

    • What made you notice this person had something worth hearing? Was it a pattern or a one-time read?
    • If that person hadn't spoken up at all, what would have shipped or not shipped differently?

    Company context

    Slack's Inclusive Collaboration principle asks engineers to actively pull in quieter voices, not just tolerate them. In SRE and DevOps work, the person closest to the alert or the on-call rotation often holds the most important signal — but they may be a junior engineer or a contractor. Slack's culture explicitly values hearing those voices before the incident, not after. This question tests whether the candidate practices solidarity and inclusive teamwork at the operational level.

  2. 2.Walk me through a code or config review where you caught something important but had to figure out how to say it without derailing the author. What did you write, and how did they respond?

    easy~3 min

    What interviewers look for

    • Candidate separated the technical concern from any personal framing — the feedback was about the change, not the author's judgment or skill.
    • Candidate can recall specific language they used or a concrete approach (e.g., asking a question rather than asserting, offering a suggestion alongside the concern).
    • The author responded constructively and the change was improved — evidence that the delivery was as effective as the content.

    Likely follow-ups

    • What's the hardest feedback you've had to give in a review — where the problem was serious but so was the risk of damaging the relationship?
    • How do you handle it when someone pushes back on your review comment and you still think you're right?

    Company context

    Slack's engineering culture is famously built around the Code Review with Care principle — Slack even uses PR review as a core technical interview artifact, explicitly evaluating both technical accuracy and the quality and tone of the feedback. For SRE and DevOps roles, config and infrastructure-as-code reviews are high-stakes: a misconfigured Kubernetes manifest or a Terraform change can cause an outage. The expectation is that review comments are constructive and respectful, modeled on the same considerate tone Slack's product encourages in workplace communication.

  3. 3.Describe a time when something a customer or user reported — a bug, a latency complaint, an outage report — changed what your team worked on next. What was the signal, and how did you translate it into an engineering priority?

    medium~4 min

    What interviewers look for

    • Candidate went beyond the symptom the customer reported and diagnosed the underlying reliability or infrastructure problem — not just 'we fixed the bug they filed.'
    • Candidate actively worked to get the customer signal in front of engineers, not just PM or support — they believed understanding the user context was their job too.
    • Candidate can articulate what they would have prioritized instead, and why the customer signal was a legitimate override of that plan.
    • Candidate built something durable — an SLO, alert, or observability improvement — so the same class of problem would surface faster in the future.

    Likely follow-ups

    • How did you make sure the rest of the team understood why this jumped the queue? Was there any friction?
    • What observability or alerting gap did this expose, and did you close it?

    Company context

    Slack's Customer Empathy principle asks engineers to actually use the product and weigh customer impact when making technical trade-offs — not to treat customer signals as noise filtered by PM. For SRE and DevOps engineers at Slack, this is especially acute: a reliability issue in Slack Channels, Slack Connect, or Huddles can affect thousands of enterprise workspaces simultaneously. The expectation is that SREs treat customer pain reports as primary signals worth triaging alongside telemetry, not secondary to it.

  4. 4.Tell me about a real disagreement you had with a developer or engineering team about an infrastructure change — something where you were the SRE pushing back on something they wanted to ship. How did it get resolved?

    medium~4 min
  5. 5.Tell me about a postmortem or incident review where someone on the team — maybe a junior engineer or someone from another function — pointed out a root cause or a contributing factor that the room had missed. How did that happen, and what did you do with it?

    hard~5 min
  6. 6.Walk me through a time you reviewed an infrastructure PR or config change and gave feedback that genuinely changed the design — not just a nit, but something architectural. What was the change, what did you see, and how did you frame it?

    hard~5 min

Technical Questions (6)

  1. 7.Slack's real-time messaging server needs to guarantee message delivery ordering within a channel. How would you use Kafka to ensure that, and what tradeoffs would you think about?

    easy~3 min
  2. 8.We run a fleet of Kubernetes pods that serve Slack's API layer. How would you design liveness and readiness probes for a service that also depends on Redis and a sharded MySQL backend?

    easy~3 min
  3. 9.Slack Connect lets companies share channels across org boundaries. If you were designing the deployment pipeline for a service that handles cross-org permission checks, what safeguards would you build in given that a bug could expose messages across company boundaries?

    medium~4 min
  4. 10.Slack's edge proxy is Envoy-derived and sits in front of all API traffic. You notice that P99 latency at the edge has spiked but service-level P99s look normal. Walk me through how you'd isolate where the latency is actually coming from.

    medium~4 min
  5. 11.Slack's MySQL is horizontally sharded by workspace ID. You need to build a reliable, low-operational-overhead migration path to move a high-traffic workspace from one shard to another without downtime. How would you approach it?

    hard~5 min
  6. 12.Slack Huddles uses WebRTC for audio and video. If you were designing the SLO framework for Huddles from scratch, what metrics would you choose and how would you handle the fact that media quality is inherently subjective and hard to measure server-side?

    hard~5 min

System Design Questions (6)

  1. 13.Slack Workflow Builder lets non-technical users trigger automations across dozens of integrations. How would you design the observability stack for that service so that when a workflow silently fails, someone actually finds out?

    easy~3 min
  2. 14.Slack's desktop client is an Electron app, and a meaningful share of enterprise users are on locked-down machines with restrictive network proxies. How would you design a lightweight connectivity diagnostic service that helps SREs understand whether a reported outage is actually client-side network degradation versus a real backend incident?

    easy~3 min
  3. 15.We want to build a canary deployment system for Slack's API services where a canary sees real production traffic but a bug in the canary can never corrupt shared database state for non-canary users. How do you design that guarantee?

    medium~4 min
  4. 16.Agentforce in Slack uses AI agents that can read channel history and take actions on behalf of users. Design a rate-limiting and quota system for those agents that protects Slack's infrastructure without degrading the experience for legitimate high-volume enterprise users.

    medium~4 min
  5. 17.Slack's status page shows a single global health indicator, but our infrastructure is actually regional and our enterprise customers operate in specific AWS regions. Design a system that automatically computes and publishes per-region service health without any human writing the status update.

    hard~5 min
  6. 18.Slack Huddles lets users do spontaneous audio calls inside channels. Design the infrastructure for a graceful degradation strategy so that if the media relay tier is fully down, users can still fall back to something useful — not just get an error screen.

    hard~5 min

Leadership Questions (6)

  1. 19.Tell me about a time you had to learn a new tool or technology quickly because your team needed it — not because you chose it. How did you get up to speed, and what did you deliver?

    easy~3 min
  2. 20.Describe a time you noticed a teammate was struggling with a task — not because they asked for help, but because you picked up on it yourself. What did you do?

    easy~3 min
  3. 21.Tell me about a time you had to push back on a PM or product team about a launch timeline because the reliability or operational risk was too high. How did you make the case, and what happened?

    medium~4 min
  4. 22.Think about the last on-call rotation or incident response you were part of. How did you make sure the experience wasn't miserable for the rest of your team — not just for yourself?

    medium~4 min
  5. 23.Tell me about a time you inherited or adopted a service that was in worse shape than anyone had told you — undocumented, flaky, or without clear ownership. How did you decide what to stabilize first, and how did you communicate the state of things to stakeholders who were relying on it?

    hard~5 min
  6. 24.You're the SRE on a feature launch for a high-visibility Slack product — say, a major Workflow Builder update — and two days before launch you discover that the deployment process requires a manual step that will require someone to be awake at 2am. The dev team says 'we've always done it this way.' What do you do?

    hard~5 min

Problem Solving Questions (6)

  1. 25.Estimate how many Slack messages are sent globally in a single hour on a typical Tuesday morning. Walk me through your reasoning.

    easy~3 min
  2. 26.Slack Connect channels are shared between two or more companies. If one of those companies gets offboarded from Slack — their subscription lapses — how would you estimate the blast radius on the connected orgs still using those shared channels?

    easy~3 min
  3. 27.Slack's search indexes messages across billions of records. If search result latency suddenly jumps from P99 200ms to P99 800ms and you've ruled out Elasticsearch cluster health, what's your diagnostic tree from there?

    medium~4 min
  4. 28.Estimate the total storage cost Slack incurs annually just for storing emoji reaction metadata — not the emoji images themselves, just the reaction event records. Walk me through your assumptions.

    medium~4 min
  5. 29.Slack's notification pipeline has to fan out a message sent to a large public channel — say, a company-wide channel with 50,000 members — to mobile push, desktop, and email within a few seconds. Design the reliability model for that fan-out path. What are the failure modes you'd want SLOs on?

    hard~5 min
  6. 30.Over 18 months, Slack's P99 API response time has drifted from 180ms to 340ms with no single incident to blame. How would you build the case that this is a real problem worth a dedicated engineering investment, and what would the remediation plan look like?

    hard~5 min

More Slack interview questions