Atlassian·Software Engineer·Technical Phone Screen·Senior

SeniorPrefer not to say

Apr 2026Remote

Summary

Atlassian backend interview, follow-up round after a sequential HTTP fetcher question. They pushed me to parallelize the whole thing and then kept piling on edge cases until I was juggling like four different concerns at once.

Questions Asked (1)

You've already built a sequential HTTP fetcher. Now rewrite it to send requests in parallel using threads, async/await, or a concurrency pool. It still needs to return the URL, status code, and body for each request.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

The parallelization part wasn't too bad, I went with an async approach and that felt natural.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then choose a concurrency model (threads, async/await, or a pool) with clear justification. Present a clean implementation that preserves the original output contract (URL, status, body) while handling errors and resource limits, and discuss trade-offs and testing.

Pro tip: Mention that you would add a concurrency limit (e.g., semaphore or bounded pool) to avoid overwhelming the target server or exhausting local resources, and that you'd make it configurable. This shows you think about production readiness, not just correctness.

1. Clarify requirements and constraints

Ask about expected scale (number of URLs), latency sensitivity, target server rate limits, and whether ordering of results matters. Confirm that the output contract (URL, status code, body) must remain unchanged.

2. Choose a concurrency model with justification

Select threads, async/await, or a concurrency pool based on the workload (I/O-bound vs CPU-bound), language ecosystem, and team familiarity. Briefly explain why the chosen model fits best.

3. Design the parallel fetcher

Outline the structure: a function that takes a list of URLs and returns a list of results. Use a pool or semaphore to limit concurrency, and ensure each task captures its URL and handles exceptions so one failure doesn't crash the whole batch.

4. Implement and handle edge cases

Write clean code that preserves the output format, manages timeouts, retries (if appropriate), and resource cleanup. Ensure thread-safety or async-safety when collecting results.

5. Discuss trade-offs and testing

Compare the chosen approach to alternatives (e.g., threads vs async) in terms of complexity, performance, and debuggability. Mention how you would test it: unit tests with mocked HTTP calls, integration tests, and load testing.

Key Points to Mention

Concurrency limit (e.g., semaphore, bounded pool) to avoid overwhelming the target server or local resources
Error handling per request so one failure doesn't affect others; return error info in the result
Preservation of the original output contract: URL, status code, and body for each request
Trade-offs between threads, async/await, and concurrency pools (e.g., GIL, context switching, complexity)
Timeouts and retries to handle network issues gracefully
Testing strategy: mocking HTTP calls, verifying concurrency behavior, and measuring performance

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