Hot Agent Startup·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Jun 2026Remote

Summary

Got a system design coding question at what seemed like a mid-level SWE screen for an agent startup. One meaty implementation problem with a bunch of follow-ups baked in, not a series of separate questions. Left feeling like I'd covered maybe 70% of what they actually wanted.

Questions Asked (1)

Design and implement a server-side publish-subscribe system in Python using the standard threading library. Multiple publishers and subscribers should be able to operate concurrently, subscribers can join or leave topics, and all active subscribers must receive messages published to their topic. Your solution should be free of race conditions and deadlocks.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

This one spiraled fast.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then outline a high-level design using a central broker with per-topic subscriber lists protected by locks. Implement the core classes (Broker, Topic, Subscriber) with careful lock management to avoid deadlocks and race conditions, and discuss trade-offs like lock granularity and delivery guarantees.

Pro tip: Mention that you would use a single lock per topic to reduce contention and avoid deadlocks, and that you would copy the subscriber list under lock before delivering messages to prevent holding the lock during I/O.

1. Clarify requirements and constraints

Ask about expected scale, message delivery guarantees (at-least-once, at-most-once), and whether subscribers can be slow or unresponsive. This shows you think about real-world implications.

2. Design the high-level architecture

Propose a central broker that manages topics and subscribers. Each topic maintains a list of subscribers and a lock. Publishers send messages to the broker, which dispatches to subscribers.

3. Define the API and data structures

Outline classes: Broker (with methods subscribe, unsubscribe, publish), Topic (with subscriber list and lock), and Subscriber (with a thread-safe queue and a worker thread). Use threading.Lock or RLock for synchronization.

4. Implement concurrency control

Use a lock per topic to protect the subscriber list. When publishing, acquire the lock, copy the subscriber list, release the lock, then deliver messages to avoid holding the lock during I/O. Use condition variables or queues for subscriber message delivery.

5. Discuss trade-offs and edge cases

Talk about lock granularity (global vs per-topic), handling slow subscribers (bounded queues, dropping messages), and potential deadlocks (lock ordering). Mention testing with stress tests.

Key Points to Mention

Use per-topic locks to minimize contention and avoid deadlocks.
Copy the subscriber list under lock before delivering messages to prevent holding the lock during I/O.
Use thread-safe queues (e.g., queue.Queue) for each subscriber to decouple message production and consumption.
Consider delivery guarantees: at-most-once vs at-least-once, and how to handle slow subscribers.
Avoid nested locks or establish a lock ordering to prevent deadlocks.
Test with concurrent publishers and subscribers, including dynamic join/leave, to validate correctness.

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