Project deep dives
Explain ownership, trade-offs, failure handling, and real project outcomes.
Browse the complete question directory
Project discussion
- What was the project?
- What problem did it solve?
- What was your role?
- Which technologies did you use?
- Why did you choose the technology?
- How was the API structured?
- How was data modeled?
- How did authentication work?
- How were errors handled?
- How were integrations handled?
- What was the hardest technical problem?
- What performance issue did you face?
- What database optimization did you perform?
- What failure scenarios existed?
- How did you handle retries?
- How did you prevent duplicate processing?
- How did you secure the application?
- What would happen at 10x traffic?
- What is the bottleneck?
- What would you cache?
- Where could a race condition happen?
- What happens if a third-party integration is unavailable?
- What happens if a database transaction fails halfway?
- How would you monitor this system?
- What would you redesign today?
Technical deep dives
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.
What database optimization did you perform?
Database optimization changes data access so the same required result costs less work or waits less. Typical changes involve a query, index, join pattern or transaction scope. The useful story explains why the original plan was expensive and what trade-off the new design introduced.
What failure scenarios existed?
Failure scenarios are the ways a normal workflow can be interrupted or produce an uncertain result. They include invalid data, unavailable dependencies, duplicate events and crashes between steps. A project answer should explain the scenarios the actual system handled and honestly identify known gaps.
How did you handle retries?
A retry policy decides which failures may be attempted again, how long to wait and when to stop. It is valuable for temporary faults but dangerous for non-idempotent side effects. Explain the actual policy and duplicate protection used, or clearly say that a policy was missing.
How did you prevent duplicate processing?
Duplicate prevention identifies repeated attempts at the same logical operation and avoids applying its effect twice. It must work under concurrent requests and crashes, so an ordinary pre-check is often insufficient. A stable key plus an atomic database rule is one approach, with separate handling for external effects.
How did you secure the application?
Application security is a collection of controls at identity, data-access, input and operational boundaries. A project explanation should focus on specific implemented checks rather than broad labels such as “secure APIs.” Use one concrete request to demonstrate how an unauthorized action was rejected.
What would happen at 10x traffic?
A 10x traffic question tests whether you understand how work and resource usage grow. Different parts of the system may scale differently, so ten times the requests does not automatically require ten times the app servers. Start with current bottlenecks, data growth and external quotas, then estimate which limit appears first.
Difficulty is an editorial estimate. Completion means you chose to mark a question as understood.