I have a backend developer interview coming up in a few days and want to focus on the topics that best demonstrate solid mid-to-senior-level knowledge. I'm considering sync versus async calls, idempotency, messaging topics and partitions, consumer groups, transactions and distributed transactions, plus Docker and Kubernetes. I'm less confident with cloud infrastructure: I've used the Azure console a little, but I haven't written Terraform or configured infrastructure from scratch. My CI/CD experience is mainly with TeamCity, where I selected an environment and branch before deploying. Should I spend time reviewing cloud, infrastructure, and deployment topics, or focus more on backend design and real-world failure scenarios?
4 Answers
For JWTs, know both the benefits and limitations. They work well with OAuth-style identity providers and allow stateless verification, but a stolen token remains usable until it expires unless you add revocation or session-management mechanisms. Environment variables are generally useful for deployment-specific configuration, while a secrets service should hold sensitive credentials. A database-backed configuration store is better suited to application settings that change dynamically and influence business behavior.
If you haven’t worked with distributed systems professionally, that isn’t automatically a problem. Be honest about the gap, then show that you understand the fundamentals. A small practice project could help: containerize a simple service, run it locally with a database and message broker, deploy it to a basic cloud environment, and add a simple CI/CD pipeline. You don’t need to become an infrastructure specialist in a few days, but reviewing deployments, logs, health checks, networking, secrets, scaling, and rollback strategies would make your experience easier to discuss.
A few useful design questions would be: what does the Liskov Substitution Principle mean in SOLID, and how do you keep implementations substitutable? How would you coordinate sequential operations across two distributed systems? Also be prepared to discuss JWTs, their expiration and revocation trade-offs, environment variables versus a configuration or secrets service, and when configuration belongs in a database. For independent calls, parallel execution can reduce latency, but only when ordering and shared-state requirements allow it. If the calls must happen in sequence, explain how you would handle timeouts, partial failure, retries, and recovery instead of simply moving the work to another thread.
I’d describe Liskov in terms of implementations honoring the behavior promised by their interfaces, not just sharing a type. For configuration, I’d use environment variables or a secrets manager for deployment-specific values and a database-backed configuration store for dynamic application settings that may change without redeploying.
For a mid-to-senior interview, failure scenarios are usually more valuable than memorizing configuration flags. Be ready to walk through a write operation from start to finish: where an idempotency key is stored, what happens if the database commits but publishing the event fails, and how a consumer handles a rebalance during batch processing without applying the same message twice. For synchronous and asynchronous communication, expect questions about timeouts, retries, backpressure, ordering, and failure handling rather than just framework syntax. For Docker and Kubernetes, think about what happens when a container or pod dies during processing and how deployments, health checks, retries, and consumer behavior provide resilience. Preparing two or three real incidents or design examples from your work will let you demonstrate practical judgment across several topics.
That makes sense. For a database commit followed by a failed Kafka publish, I’d explain the dual-write problem and recommend an outbox pattern rather than pretending the two operations are automatically atomic. I also need to be more precise about where idempotency is enforced and how consumer retries avoid duplicate effects.
Exactly—the reasoning around what breaks when a dependency or pod disappears is much more revealing than recalling isolated settings.
The exact cloud provider may not matter as much as understanding the concepts. Learn how compute, storage, networking, identity, secrets, monitoring, and deployment automation map to one another, then relate those ideas to the provider you have seen.