Interview Experience | Backend | 🔥🔥 | Datadog
2026 (Jul–Sep) Software Engineer @ Datadog — Technical Screen | 🙂 Positive | Medium | Pending
The screen was about 50 minutes. We went through my background quickly and started coding soon after.
One question, no LeetCode: write a simple Pub-Sub using Python threading.
I thought a lock would be enough. The interviewer kept adding conditions on top of whatever I had just written.
Technical Screen — Python Pub-Sub
My first version was as plain as it gets. A dict for topic -> subscribers, and publish walks the subscribers of that topic and sends the message over.
Since it is multithreaded, I put one lock around the whole thing. Every read and write of the shared state went through that lock.
Publish while another thread subscribes
The first follow-up: what if one thread is publishing while another thread subscribes?
I said the shared state is all under the lock. Subscribe changes the topic -> subscribers mapping, publish reads that same mapping, so publish does not see a half-updated state.
Two publishes at the same time
Then: what if two publishes happen at the same time?
Basically the same answer. Both are touching the same shared state, and the lock serialises them.
Those two went fine. Both answers came down to the same shared state and the same lock.
The subscriber callback holding the lock
Then he asked what happens if one subscriber is really slow.
My first version had a real problem there, because I was calling the subscriber callback while still holding the lock:
def publish(self, topic, message):
with self.lock:
for sub in self.subscribers.get(topic, []):
sub.callback(message)
If one callback blocks, every other publish and subscribe waits behind it.
I only changed this after he pushed on the slow subscriber. The fix was to take the subscriber list out first, release the lock, and then dispatch:
def publish(self, topic, message):
with self.lock:
subs = list(self.subscribers.get(topic, []))
for sub in subs:
sub.callback(message)
Now the lock only protects the shared state, not the callback.
Slow consumer
He kept going: how would you handle a slow consumer?
I said I would give each subscriber its own queue. Publish only puts the message into the queue, and each subscriber has its own worker thread pulling from it. A slow subscriber then only blocks itself instead of everyone.
He asked: what if the queue is full?
I said bounded queue / backpressure first.
He said: assume you cannot just drop the message.
I got messy here. I mentioned blocking and retrying, but I never turned it into one coherent design, and I did not go back and write the code for it.
Unsubscribe with messages still in the queue
The last one was unsubscribe. If a subscriber unsubscribes while its queue still has messages that were never processed, what happens to them?
I do not remember this part well. I mostly talked it through and never wrote it down.
That was the whole screen. One question, no LeetCode. The question itself is not hard, but the interviewer keeps following up on whatever you just wrote. I wrote fast at the start, and only later did I notice that this kind of concurrent code looks like "just add a lock" until someone keeps asking. Lock scope and the slow consumer part are the two places I think I answered so-so.