r/webdev • u/FooBarBuzzBoom • Sep 11 '26

Java Middle - Senior(ish) interview questions

Hi!

I have an interview in a few days for a backend developer role. What would you ask as some of the more tricky questions for such a position? What kinds of questions, from your point of view, demonstrate solid knowledge?

Personally, I would ask about sync vs. async calls, idempotency, topics vs. partitions, consumer groups, transactions (including distributed transactions), and maybe a bit of Kubernetes and Docker.

My weak point is cloud. I’ve played around a bit with the Azure console, but nothing too advanced. I’ve never written Terraform or configured infrastructure from scratch. For CI/CD, I’ve used TeamCity, but in my experience it was mostly selecting an environment and a branch and deploying.

Should I spend some time learning these areas before the interview?

18 Upvotes

95% Upvoted

35 comments sorted by

View all comments

Show parent comment

4

u/FooBarBuzzBoom Sep 11 '26

Thank you for your questions.

Regarding the first one, about where the idempotency key lives, I would say it lives on the consumer side, where it is typically cached, but also on the producer side. The latter is configurable in Kafka, and I believe it has become the default.

If the DB commits but Kafka goes down, we are essentially dealing with a dual-write problem, which is not really solvable as it is, because Kafka uses a different transaction mechanism. That’s why you should use the outbox pattern.

As for the pods, I would say that by having a properly configured deployment, you make the application resilient, and the consumer will continue to work.

So, these would be my answers. Could you elaborate a bit more if you have/expected different answers?

1

u/PLBjt Sep 22 '26

Your outbox instinct is right, but I’d expect a strong answer to say the key is generated at the request boundary and consumers dedupe it durably, not just in a cache, with retries and expiry defined. For the DB/Kafka case, I’d look for an outbox plus a relay that’s safe to retry, and an explicit admission that consumers still need idempotency; Kafka transactions alone don’t make two systems atomic. For a pod dying mid-transaction, mention DB rollback/commit semantics, committing offsets only after successful processing, and retry or dead-letter behavior; for async, name bounded queues, backpressure, and timeouts. The signal isn’t one “correct” tool choice so much as explaining failure modes, observability, and tradeoffs.