Question library
Explained questions for the decisions developers make.
How do DNS, load balancers, IAM and secrets fit together?
DNS resolves names to records, load balancers select healthy destinations, IAM controls identities and permissions, and secret managers store sensitive credentials. These components connect an application to users and dependencies without putting all configuration into code. A failure at any layer can look like “the API is down” from the outside.
The container exits immediately. What should I check?
A container stays running while its main process remains alive. An immediate exit usually means the command finished, failed startup or was killed, rather than that Docker randomly stopped a healthy application. Logs, exit status and runtime configuration tell you which case occurred.
The app cannot reach the database container. What should I check?
Each container has its own network context, so localhost points back to that container rather than a sibling service. Reaching a database requires the correct address, network path, credentials and an accepting database process. Compose startup order can start a process without guaranteeing it has finished initialization.
Tests pass locally but fail in CI. Why?
A local/CI mismatch means the test depends on something that differs between environments. Common differences include runtime versions, installed files, operating-system behavior, time, service availability or test order. Reproducing the CI command in a clean setup exposes these hidden assumptions.
How would I roll back a bad deployment?
Rollback restores a previously working application version after a harmful release. It works only if that version is compatible with the current database, message formats and configuration. A complete rollback plan includes health verification and a way to preserve or reconcile work already performed by the new version.
A cloud API is unreachable. Where do I start?
An unreachable cloud API may fail before the request reaches application code. DNS, TLS, routing, firewall rules, load-balancer health and listening ports are separate layers to verify. Checking them in order avoids opening broad access or restarting healthy services without evidence.
What was the project?
The interviewer first needs a clear picture of what the product does and who uses it. Introduce the business domain before listing frameworks so the technical discussion has context. A short project summary should be understandable to someone outside your team.
What problem did it solve?
A problem statement explains the user's difficulty or business need that motivated the feature. It should distinguish the problem from your implementation choice: “using NestJS” is not a user problem. Explain the previous limitation only if you know it from the actual project.
What was your role?
Your role describes the decisions and implementation work you personally owned. Interviewers use it to choose follow-up questions and separate individual depth from team-wide scope. Being precise makes a modest contribution easier to defend than an inflated claim about the whole system.
Which technologies did you use?
A technology answer should explain how each tool helped implement the project. Listing names alone does not show whether you used the tool or understood its purpose. Choose the relevant tools and connect them to HTTP handling, persistence, authentication, integration or deployment.
Why did you choose the technology?
A technology decision is a trade-off between requirements, team knowledge, existing systems and operating costs. Sometimes you selected the tool; sometimes you inherited it and made good use of it. Both are valid experiences when clearly distinguished.
How was the API structured?
API structure describes how a request moves from the client through validation and access checks to business logic and persistence. It also includes resource names, error contracts and how responsibilities are separated. A real endpoint example makes the structure easier to understand than a folder list.
How was data modeled?
Data modeling identifies the records, relationships and constraints needed to represent the business correctly. A model should support the important reads and prevent invalid writes. Explain it through a real workflow so each table, document or relationship has a reason to exist.
How did authentication work?
Authentication flow explains how the system establishes and maintains the caller's identity. It includes the login method, credential validation and how subsequent API requests are recognized. Authorization follows from that identity but must be described separately.
How were errors handled?
Error handling defines what happens when inputs, business rules or dependencies fail. A reliable API returns an appropriate response while preserving enough internal context for diagnosis. The answer should describe actual behavior rather than promise that errors were simply “handled centrally.”
How were integrations handled?
An integration connects your system to an external provider with its own data format, identity rules and availability. A good answer covers both data mapping and operational behavior such as timeouts and rate limits. The integration boundary is where many partial failures and mismatched assumptions appear.
What was the hardest technical problem?
A difficult-problem answer should show how you reasoned under a real constraint, not simply that a project had many features. Pick one problem where your investigation or decision changed the outcome. Keep the story focused enough that you can defend each technical detail.
What performance issue did you face?
A performance story starts with a measured symptom and the workload that exposed it. It should explain how you separated potential causes and what work the final change reduced. A faster-looking code snippet is not a complete result without checking the same behavior and load.
Difficulty is an editorial estimate. Completion means you chose to mark a question as understood.