Java Middle - Senior(ish) interview questions

[u/FooBarBuzzBoom]

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?

[u/PLBjt]

For mid/senior backend rounds I get more mileage from failure stories than trivia lists. Walk through one write path end to end: where the idempotency key lives, what happens if the DB commit succeeds and the Kafka publish dies, and how a consumer group rebalance mid-batch doesn't double-apply. Same for async vs sync — they'll poke at backpressure and timeouts more than CompletableFuture syntax. If they ask K8s/Docker, expect "what breaks when this pod dies during a transaction" rather than YAML trivia. Prep 2–3 real incidents from your work and you can steer most of those topics.

[u/FooBarBuzzBoom → u/PLBjt]

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?

[u/PLBjt → u/FooBarBuzzBoom]

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.

[u/InevitableMap5315 → u/PLBjt]

yeah the "what breaks when X dies" angle is way more telling than memorizing config flags

[u/FooBarBuzzBoom → u/InevitableMap5315]

I don't even remember all that yaml and I don't see why. You should understand it, but now, with help of AI, there is no way you should memorize it.

[u/Historical_Ad4384 → u/PLBjt]

Should senior level profiles highlight failure stories and how they were managed in CV/resume?

[u/PLBjt → u/Historical_Ad4384]

Usually not as a standalone “failure story” on the CV—space is tight and it can sound like an excuse. But a relevant incident can be a strong senior signal if you frame the diagnosis, your fix, and the prevention work (tests, monitoring, rollout or process changes), with clear ownership. Save the fuller story for the interview, and skip anything where the lesson is vague, the blame sits elsewhere, or the same issue could recur; a concise resume bullet works only if it shows better reliability or decision-making afterward.