Locus | Staff Backend Engineer | June 2026 | Rejected
Summary
I interviewed for a Staff Backend Engineer position at Locus in June 2026, completed LLD and HLD rounds, and was rejected after the HLD round.
Full Experience
Interview Experience – Backend (LLD + HLD + Hiring Manager) | Rejected in HLD
I recently interviewed for a backend engineering role. The process consisted of three rounds:
- Round 1 (1.5 hrs): Low-Level Design (LLD) – Knockout
- Round 2 (1.5 hrs): High-Level Design (HLD) – Knockout
- Round 3: Hiring Manager Discussion
Unfortunately, I was rejected after the HLD round.
Round 1 – Low-Level Design (Machine Coding)
Problem Statement
Design and implement an in-memory Meeting Room Booking System.
Functional Requirements
Create Meeting Rooms
Each room should contain:
roomIdcapacity
Book a Room
Implement:
bookRoom(startTime, endTime, requiredCapacity) -> bookingId
A booking should succeed only if:
- A room exists with
capacity >= requiredCapacity. - The selected room has no overlapping booking during the requested time interval.
Prevent Overlapping Bookings
Two bookings overlap if:
startA < endB && startB < endA
Time intervals are half-open ([start, end)), so bookings like [10,20) and [20,30) are considered valid.
Storage
- Keep everything in-memory.
- Use appropriate data structures such as
Map,List, orTreeMap.
What the Interviewer Evaluated
- Object-oriented design
- Clean class responsibilities
- Appropriate data structure selection
- Efficient conflict detection
- Clean APIs and modular code
- Time and space complexity
- Design trade‑offs and possible scalability improvements
Round 2 – High-Level Design
Problem Statement
Design a multi-tenant configurable workflow engine for an enterprise B2B SaaS platform.
Customers should be able to define workflows using either:
- A visual workflow builder
- JSON/YAML specifications
Functional Requirements
The workflow engine should support:
- Sequential execution of workflow steps
- Conditional branching
- API/action execution
- Human approval tasks
- Timers and wait states
- Retry mechanisms
- Notifications
- Validation before publishing workflows
- Declarative workflows (no customer code execution)
- Workflow versioning so running executions are unaffected by new versions
- Execution monitoring
- Audit logging
- Workflow status tracking
Non-Functional Requirements
The system should scale to:
- Hundreds of tenants
- Thousands of workflow definitions
- Millions of workflow executions
It should also ensure:
- Tenant isolation
- Durability
- Fault tolerance
- Low‑latency execution
- Operational visibility and monitoring
Overall, both rounds were quite interesting. The LLD round focused heavily on writing clean, extensible code with proper data structures, while the HLD round emphasized distributed systems design, workflow orchestration, scalability, and multi‑tenancy.
Hopefully this helps others preparing for similar backend system design interviews. Good luck!
Interview Questions (2)
In-Memory Meeting Room Booking System Design
Design and implement an in‑memory Meeting Room Booking System.
Functional Requirements
- Create Meeting Rooms: each room has
roomIdandcapacity. - Book a Room:
bookRoom(startTime, endTime, requiredCapacity) -> bookingIdshould succeed only if a room with sufficient capacity exists and the room has no overlapping bookings. - Overlap definition:
startA < endB && startB < endAwith half‑open intervals[start, end). - Storage: keep all data in memory using appropriate structures like
Map,List, orTreeMap.
Evaluation Criteria
- Object‑oriented design and clean class responsibilities.
- Choice of data structures for efficient conflict detection.
- API design, time/space complexity, and scalability trade‑offs.
Multi‑Tenant Configurable Workflow Engine Design
Design a multi‑tenant configurable workflow engine for an enterprise B2B SaaS platform.
Functional Requirements
- Users can define workflows via a visual builder or JSON/YAML.
- Support sequential steps, conditional branching, API/action execution, human approvals, timers, retries, notifications, validation, declarative execution, versioning, monitoring, audit logging, and status tracking.
Non‑Functional Requirements
- Scale to hundreds of tenants, thousands of workflow definitions, and millions of executions.
- Ensure tenant isolation, durability, fault tolerance, low latency, and operational visibility.
Focus Areas
- Architecture for multi‑tenancy and isolation.
- Design of workflow definition storage, execution engine, and versioning.
- Strategies for scalability, fault tolerance, and monitoring.