Atlassian Software Engineer Case Interview: Designing a Cross‑Product Automation Service

This case mirrors Atlassian’s collaborative, customer‑first interview style and evaluates how you turn ambiguous product needs into pragmatic, scalable solutions. You’ll partner with the interviewer to design a lightweight, multi‑tenant automation service that reacts to events in Jira and can trigger actions across Atlassian products (e.g., create a Confluence page summary, update a Bitbucket PR, or post to Trello) while respecting permissions and data residency. What the case covers: 1) Problem discovery and customer focus (Atlassian values): Clarify the user problem (e.g., triaging issues, cross‑project status updates), target personas (admin vs. project team), and success metrics (latency SLOs, rule execution reliability, reduction in manual work). Expect discussion on how you’d iterate safely, communicate trade‑offs openly, and avoid harming the customer. 2) API and rule model: Propose a minimal rule representation (trigger, conditions, actions) inspired by real workflows teams build in Jira. Define external and internal APIs: create/list rules, enable/disable, test rule, and an execute endpoint for actions. Consider JQL‑like filters for targeting issues, idempotency keys, pagination, and rate limits. Show how tenant and user permissions propagate through requests. 3) Architecture for Atlassian Cloud scale: Sketch core components: event ingestion (from product event streams), rule matcher, action dispatcher, permissions/entitlements check, and audit logging. Discuss multi‑tenancy boundaries, partitioning by tenant, and how you’d isolate noisy neighbors. Address eventual consistency, retries with backoff, poison‑message handling, and exactly‑once vs. at‑least‑once semantics (and why). Assume high volume (tens of millions of daily events) and propose horizontal scaling and back‑pressure strategies. 4) Security, privacy, and compliance: Show how you prevent privilege escalation across products, encrypt sensitive data at rest/in transit, and honor data residency and retention controls. Include audit trails for admin visibility and incident response. Consider marketplace app extensibility and how third‑party actions are sandboxed. 5) Observability and operations: Define SLIs/SLOs (e.g., p95 rule evaluation latency, success rate), tracing across services, structured logs, metrics, and alerting. Describe dark launches, feature flags, and phased rollout plans; how you’d test with canaries on a subset of customers and roll back safely. 6) Edge cases and failure modes: Bursty tenants, malformed rules, downstream timeouts (e.g., Confluence action failing), cyclic rule triggers, and duplicate events. Discuss mitigation (dedupe via idempotency keys, circuit breakers, dead‑letter queues) and customer‑visible degradation plans. 7) Collaboration and communication: Throughout, the interviewer looks for how you co‑create the solution, invite feedback, and explain trade‑offs clearly—matching Atlassian’s emphasis on openness, teamwork, and pragmatism. You’re encouraged to narrate assumptions, draw diagrams, and propose small, iterative milestones that deliver value quickly. Interviewer prompt (shared early): “Design a multi‑tenant automation/rules service for Jira Cloud that can trigger actions across Atlassian products. It must be safe, observable, and easy to iterate on. Start by clarifying customers, constraints, and success metrics; then propose APIs, data model, and architecture. We’ll deep‑dive into scale, reliability, and rollout.” What strong answers include: crisp problem framing; API designs with permissions and idempotency; a clear, evolvable architecture; concrete scaling/operability strategies; and explicit links to customer outcomes and Atlassian values.