← Atlassian Interview Insights

Atlassian·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
Apr 2026

Summary

Atlassian software engineer interview with a system design flavor, focused on building a rating system from scratch. The problem itself wasn't too bad but the follow-up on scaling and data structures is where things got interesting.

Questions Asked (2)

Q1

Design a simple movie rating system that supports adding ratings for items and querying the total score, average score, and number of ratings per item.

Algorithms & Data StructuresSystem DesignData Modeling
Author's notes

I went with a hashmap keyed by item ID, storing count and cumulative score so average is just a division away.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a data model using a hash map to store per-item aggregates (sum, count) for O(1) updates and queries. Discuss trade-offs, scalability, and potential extensions like concurrency or persistence.

Pro tip: Mention that storing only aggregates (sum and count) avoids storing individual ratings, saving memory and enabling O(1) operations. Also, proactively discuss how to handle concurrent updates with atomic operations or locks.

1. Clarify Requirements

Ask about expected scale, read/write patterns, concurrency needs, and whether ratings can be updated or deleted. Confirm that queries are per item and that we need total, average, and count.

2. Design Data Model

Propose a hash map where each key is an item ID and the value is an object containing sum of ratings and count of ratings. This allows O(1) updates and queries.

3. Define Operations

Specify addRating(itemId, rating): update sum and count; getTotal(itemId): return sum; getAverage(itemId): return sum/count; getCount(itemId): return count. Handle missing items gracefully.

4. Discuss Trade-offs and Scalability

Compare with storing individual ratings (e.g., for auditing or recomputation). Address concurrency (locks, atomic types), persistence (database), and distributed scaling (sharding by item ID).

5. Consider Extensions

Mention potential additions like rating distribution, time-based queries, or user-specific ratings, and how the design could adapt.

Key Points to Mention

  • Use a hash map for O(1) average-case time complexity for updates and queries.
  • Store sum and count per item to compute average without storing all ratings.
  • Handle edge cases: item not found, division by zero when count is zero, invalid ratings.
  • Concurrency: use thread-safe data structures or locks for concurrent updates.
  • Scalability: shard by item ID for distributed systems; consider caching for hot items.
  • Persistence: discuss writing to a database or using a write-ahead log for durability.

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

Q2

How would your design change if the system needed to handle a very large number of items or high-frequency streaming rating updates?

System DesignTechnical Trade-offsData Modeling
Author's notes

This is where I felt like I was playing catch-up.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the scale and update frequency, then walk through how each component (ingestion, storage, computation, serving) would evolve. Focus on trade-offs between consistency, latency, and cost, and propose a concrete architecture that handles the new requirements.

Pro tip: Emphasize that you would first quantify the problem (e.g., QPS, data volume) and then consider incremental changes before a full redesign, showing pragmatism and cost-awareness.

1. Clarify Requirements and Scale

Ask questions to understand the expected number of items, update rate, read patterns, and consistency needs. This ensures your design targets the right bottlenecks.

2. Identify Bottlenecks in Current Design

Analyze which components (e.g., database writes, aggregation logic, cache) would fail under high load. This pinpoints where changes are needed.

3. Propose Architectural Changes

Suggest specific modifications like sharding, partitioning, stream processing, or pre-aggregation. Explain how each addresses the bottleneck.

4. Discuss Trade-offs and Alternatives

Compare options (e.g., batch vs. stream, consistency vs. availability) and justify your choices based on requirements and constraints.

5. Summarize and Validate

Recap the proposed design, highlight how it meets the new requirements, and mention any monitoring or scaling strategies for future growth.

Key Points to Mention

  • Sharding or partitioning of data to distribute load across multiple nodes.
  • Use of stream processing (e.g., Kafka, Flink) for real-time rating updates.
  • Pre-aggregation or materialized views to speed up read queries.
  • Caching strategies (e.g., Redis) to reduce database load for frequent reads.
  • Trade-offs between consistency and availability (CAP theorem) in distributed systems.
  • Horizontal scaling and auto-scaling to handle variable load.

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