← Atlassian Interview Insights

Atlassian·Machine Learning Engineer·Onsite - System Design / Architecture·Senior

Senior
Jun 2026

Summary

Atlassian ML Engineer interview with a system design coding round centered on interval management. The problem was more involved than I expected for an MLE role, felt more like a backend SWE question with a thin ML wrapper.

Questions Asked (2)

Q1

Design and implement a tennis court reservation system that supports booking a time interval on a court, cancelling an exact booking, and querying whether a court is occupied at a given time. Walk through the data structure you'd use to maintain non-overlapping intervals per court and the time complexity of each operation.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs
Author's notes

I went with a sorted map per court keyed by start time, which let me do a predecessor lookup to check for overlap in O(log n).

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and assumptions (e.g., granularity, time zones, concurrency). Then propose a per-court data structure that maintains non-overlapping intervals, such as a balanced BST or sorted list, and analyze the time complexity of booking, cancelling, and querying. Finally, discuss trade-offs and potential optimizations for scale.

Pro tip: Mention that using a balanced BST (e.g., TreeMap in Java) allows O(log n) operations and that you'd handle concurrency with per-court locks or optimistic concurrency to avoid race conditions.

1. Clarify Requirements

Ask about expected load, time granularity, whether bookings can span multiple courts, and if concurrent access is a concern. This shows you think about real-world constraints.

2. Choose Data Structure

Propose a per-court balanced BST (or sorted list) storing intervals keyed by start time. Explain that this keeps intervals ordered and allows efficient overlap checks.

3. Define Operations

Detail how to implement booking (check for overlap with predecessor/successor, then insert), cancellation (find and remove exact interval), and query (find interval containing the time).

4. Analyze Complexity

State that all operations are O(log n) for balanced BST, or O(n) for sorted list if using linear search. Mention that query can be O(log n) with binary search.

5. Discuss Trade-offs and Extensions

Compare BST vs. interval tree vs. hash map with bucketing. Address concurrency, persistence, and scaling to multiple courts (e.g., sharding by court ID).

Key Points to Mention

  • Use a balanced BST (e.g., TreeMap) per court to store intervals sorted by start time.
  • Overlap check: for a new interval [start, end), find the floor and ceiling entries; ensure no overlap.
  • Cancellation requires exact match of start and end times; remove the interval from the BST.
  • Query for a given time: find the interval with the largest start <= time and check if time < end.
  • Time complexity: O(log n) for booking, cancellation, and query with balanced BST; O(n) with sorted list.
  • Concurrency: use per-court locks or optimistic concurrency control to handle simultaneous bookings.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Extend the reservation system to support rescheduling a booking and finding the next available slot of a given length on a specific court.

Algorithms & Data StructuresTechnical Trade-offs
Author's notes

This is where I started running out of steam.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data model and constraints (e.g., court schedules, booking durations, time granularity) and then design an efficient algorithm for finding the next available slot, likely using interval trees or sorted lists. For rescheduling, outline the steps to validate the new slot, update the booking, and handle conflicts, emphasizing trade-offs between time and space complexity.

Pro tip: Discuss how you would handle edge cases like back-to-back bookings, buffer times, and concurrent rescheduling requests, showing you think about real-world robustness. Also, mention how you might extend the solution to support multiple courts or varying slot lengths, demonstrating scalability.

1. Clarify requirements and constraints

Ask about the granularity of time slots, maximum booking duration, whether courts have operating hours, and if there are buffer times between bookings. Confirm if rescheduling must preserve the original duration and if the new slot must be on the same court.

2. Design data structures for efficient queries

Propose using a balanced interval tree or a sorted list of bookings per court to quickly find gaps. Consider a segment tree or bitset for discrete time slots if the granularity is fixed (e.g., 15-minute increments).

3. Implement next available slot search

Outline an algorithm that iterates through existing bookings to find the earliest contiguous free interval of the required length. If using an interval tree, perform a range query to find gaps; if using a sorted list, scan and merge intervals.

4. Implement rescheduling logic

Describe the steps: validate the new slot is available and meets constraints, remove the old booking, insert the new booking, and update any indexes. Handle atomicity to avoid race conditions in concurrent environments.

5. Analyze trade-offs and optimize

Compare time complexities: interval tree O(log n + k) for queries vs. sorted list O(n) for scanning. Discuss space overhead and whether to precompute availability. Mention potential caching or lazy evaluation for performance.

Key Points to Mention

  • Time complexity of finding the next available slot: O(log n) with interval trees vs. O(n) with linear scan.
  • Handling of edge cases: bookings that exactly fill a gap, zero-length gaps, and buffer times between bookings.
  • Concurrency control: using locks or optimistic concurrency to prevent double-booking during rescheduling.
  • Data model considerations: storing bookings as intervals [start, end) and using half-open intervals to avoid overlap ambiguity.
  • Scalability: partitioning by court or using a distributed cache for high-throughput systems.
  • Trade-offs between precomputing availability (faster queries, more updates) and on-the-fly computation (slower queries, simpler updates).

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.