Slack MTS/SMTS Backend Engineer Interview Experience at Salesforce

Context The interview process was for a Salesforce MTS/SMTS Backend Engineer position, which ultimately turned out to be a role within Slack. The process bypassed standard Talent Acquisition scree

Context The interview process was for a Salesforce MTS/SMTS Backend Engineer position, which ultimately turned out to be a role within Slack. The process bypassed standard Talent Acquisition screening, moving directly to a Hiring Manager assessment.

**

Round 1 Hiring Manager (Director of Engineering)** This round combined behavioral questions with technical scenarios. *

Behavioral: Addressed handling missed deadlines and coworker conflicts. Answers were structured using the STAR (Situation, Task, Action, Result) format. *

Technical Scenario 1: Debugging a legacy project showing 50% higher network latency. * Solution: The approach involved a systematic investigation across multiple domains, including network configuration, backend logic, infrastructure health, and database performance. *

Technical Scenario 2: Implementing @autocomplete in Slack. * Solution: The design mirrored Google Search Autocomplete, utilizing a Rank-based Trie, extensive Client and Server-side caching, and query optimization.

**

Round 2 Problem Solving (Nano Slack Codebase)** A 1.5-hour coding session focused on a simplified Slack implementation ("Nano Slack"). *

Format: * 20 minutes: Codebase review and Q&A. * 60 minutes: Implementation of missing functionalities. * 10 minutes: Scaling discussion. *

Task: There were four specific functional requirements. Existing and new test cases were required to pass. *

Performance: Two requirements were fully implemented, and a clear algorithmic approach was provided for the third.

**

Round 3 System Architecture (Staff Engineer)** *

Problem Statement: Design a system allowing Slack to support third-party integrations (e.g., Jira, OneDrive, BookMyShow). The prompt was intentionally vague and open-ended. *

Solution Approach: The design focused on a Jira integration utilizing a Pub/Sub notification system. User subscriptions to specific Jira items would trigger Slack notifications upon updates. *

Key Components: * Pub/Sub model for event handling. * Database selection and caching strategies. * Message queues (justifying specific technology choices). * Note: The interviewer requested skipping Entity definitions and API contracts to focus on high-level flow. *

Deep Dive: The session concluded with a discussion on failure recovery mechanisms and alternative architectural choices.

Outcome and Key Takeaway The process ended following the Architecture round due to feedback on the design. Candidates targeting Slack backend roles should place heavy emphasis on preparing for vague, open-ended integration system design problems.