I have a backend developer interview coming up in a few days and would like to focus my preparation on questions that demonstrate solid mid-to-senior-level knowledge. Topics I expect might include synchronous versus asynchronous calls, idempotency, Kafka topics and partitions, consumer groups, transactions and distributed transactions, Docker, and Kubernetes.
My main weak area is cloud infrastructure. I have experimented with the Azure console but have not done anything particularly advanced, and I have never written Terraform or configured infrastructure from scratch. I have used TeamCity for CI/CD, although mostly by selecting an environment and branch and triggering a deployment.
Should I spend time studying cloud, infrastructure, and deployment topics before the interview? What tricky or practical questions would you ask for this type of role?
4 Answers
You probably do not need to become an infrastructure expert in a few days, especially if the role does not name a specific cloud provider. Still, it is worth learning the basic concepts: containers and images, deployments and health checks, service discovery, load balancing, logs and metrics, secrets, rolling updates, and what a simple CI/CD pipeline actually does.
A small hands-on project would help more than reading cloud product lists. Containerize a small Java service, deploy it somewhere, configure a database and a health check, and set up a basic pipeline. Also understand Terraform at a high level: it describes infrastructure declaratively, tracks state, and applies changes rather than replacing the need to understand the underlying resources.
I would also review a few fundamentals that often reveal how someone thinks: the Liskov Substitution Principle and how you apply it in real code, dependency inversion, JWT advantages and limitations, and configuration management.
For JWTs, know that a stolen token generally remains usable until it expires unless you add revocation or session-management mechanisms. Environment variables are commonly useful for deployment-specific or relatively static configuration, while a configuration service or database can hold dynamic application settings that need to change without redeploying. Be prepared to discuss secrets management rather than treating ordinary environment variables as a complete security solution.
For sequential calls between distributed systems, I would first clarify whether the operations truly need to be ordered. Independent calls can often run concurrently, but if the second depends on the first, the design needs explicit sequencing, timeouts, retries, compensation, and an idempotency strategy. Simply moving the work to another thread does not solve distributed failure handling.
For a mid-to-senior backend interview, practical failure scenarios are usually more valuable than memorizing lists of technologies. Be ready to trace a write from the API through the database and messaging system: where idempotency is enforced, what happens if the database commit succeeds but publishing the event fails, and how a consumer behaves when a group rebalance happens halfway through processing.
For synchronous versus asynchronous code, expect questions about timeouts, retries, backpressure, ordering, and failure handling rather than just syntax such as CompletableFuture. With Docker and Kubernetes, interviewers may ask what happens if a container or pod dies during a transaction and how the system recovers. Prepare two or three real incidents or design examples from your experience and explain the trade-offs you made.
That makes sense. For a database commit followed by a failed Kafka publish, I was thinking about the dual-write problem and the outbox pattern. For a pod failure, I would discuss deployment configuration, consumer recovery, retries, and whether processing is idempotent rather than assuming the platform fixes everything automatically.
Not having worked on distributed systems is not automatically a bad sign if your experience has been in a substantial monolith. Be honest about what you have and have not done, then show that you understand the principles: boundaries, consistency, retries, observability, failure modes, and when a monolith is simpler and safer.
If you have time, build a small test application with two services and a message broker. Make one service fail, duplicate a message, or restart during processing, then explain how you would make the behavior safe. That gives you concrete examples to discuss without pretending to have years of production Kubernetes experience.
I have only used a build server where most of the deployment details were hidden behind a few selections, so I will focus on understanding the pipeline stages and infrastructure concepts instead of trying to learn every cloud service.