Production reasoning & mock prep
Practice debugging, review unfamiliar code, and explain real engineering decisions.
Performance & security
Explore topicInvestigate production incidents and protect application boundaries.
API latency jumps from 200ms to 5s. What do I do?
A jump from 200ms to 5s indicates that requests are doing more work, waiting longer, or both. The first task is to establish scope and timing so the incident is not mistaken for one user's network issue. Then use measured stages to separate a recent regression from traffic or dependency saturation.
PostgreSQL CPU becomes very high. What do I check?
High PostgreSQL CPU means the database is spending substantial time processing work rather than simply waiting for requests. Causes include expensive queries, poor plans, repeated query volume or maintenance work. CPU alone does not tell you whether an index, query rewrite or traffic reduction is the right fix.
MongoDB aggregation becomes slow. What do I check?
A slow aggregation often processes a much larger intermediate dataset than its final output suggests. Joins, unwinds, sorts and groups can expand work or exceed useful memory limits. Inspecting the pipeline stage by stage reveals where the expensive growth occurs.
Node memory keeps growing. How do I investigate?
Growing Node memory can be normal temporary allocation, retained JavaScript objects, native buffers or another process-level resource. A leak is suggested when unnecessary retained memory continues to grow across comparable workloads and garbage-collection cycles. Heap size and total process memory are related but not identical measurements.
The event loop is blocked. What do I do?
An event-loop block happens when synchronous JavaScript occupies the thread long enough to delay other callbacks. Requests can appear to hang even when their own logic is simple because they share that scheduling thread. Measuring loop delay and CPU profiles connects the symptom to a specific workload.
The database connection pool is exhausted. What do I do?
A connection pool has a limited number of database connections and queues callers when all are busy. Exhaustion can come from too much parallel work, slow queries, long transactions or connections that are never released. Increasing the limit may overload the database instead of fixing the cause.
Authentication tokens are being abused. What do I do?
Abused credentials create an active access-control incident, not just a validation bug. The response must stop unauthorized use, establish how credentials were obtained and restore the affected authentication boundary. The right revocation action depends on whether a single session, many refresh tokens or signing credentials were compromised.
A third-party API starts timing out. What do I do?
A third-party timeout means your service did not receive an answer within its waiting budget. It does not prove that the remote operation was never performed. Timeouts need bounded waiting, controlled concurrency and a strategy for uncertain results, especially for actions with side effects.
Duplicate workflow jobs are processed. How do I fix this?
Duplicate jobs can occur when a producer resends work or a consumer crashes before acknowledging a completed action. Many reliable delivery systems intentionally allow redelivery to avoid losing work. Correct processing therefore identifies the logical operation and makes repeated attempts safe.
A deployment causes intermittent 500s. What do I check?
Intermittent failures after deployment often mean only some instances, requests or data shapes are incompatible with the change. A rolling deployment can briefly run old and new versions together. Grouping errors by instance and version reveals whether the issue is configuration, code, readiness or schema compatibility.
System design
Explore topicArchitecture decisions, distributed systems, and ten design scenarios.
AI code review
Explore topicEvaluate generated code for correctness, security, and reliability.
How do I check correctness?
Correctness means the implementation satisfies the required behavior for valid, invalid and concurrent inputs. A review begins with the intended rule, because readable or compilable code can still implement the wrong rule. Trace the inputs, state changes and outputs before judging style.
How do I check security?
A security review checks whether code respects boundaries between untrusted input, authenticated identity and protected actions or data. It asks what a caller can control and whether that control lets them exceed their permissions. Framework defaults and type annotations do not establish resource-level access automatically.
How do I check performance?
A performance review checks whether the amount of work stays reasonable as input size and traffic increase. Database calls, large allocations and synchronous CPU work can be more important than small syntax choices. Use measurements for suspected hotspots rather than adding optimizations everywhere.
How do I check reliability?
Reliability means the operation behaves predictably when dependencies fail, time out or return uncertain outcomes. It includes recovery after a crash, bounded resource use and preservation of business state. A happy-path test cannot prove that retries, rollback and cleanup are correct.
How do I check maintainability?
Maintainability means another developer can understand and safely change the code without discovering hidden dependencies. Clear responsibilities, names and contracts reduce the chance that a small change breaks unrelated behavior. Abstraction helps when it removes a real duplication or dependency, not merely when it adds more classes.
Which edge cases and tests matter most?
Edge cases are valid boundary conditions and failure situations that ordinary examples may not exercise. Useful tests prove important rules under those conditions, including concurrent and repeated requests. The highest-value case is often where a missing record, denied access or partial failure changes control flow.
What can break in production, and how would I debug it?
Production failures often come from conditions absent in small examples: parallel requests, large datasets, expired credentials or unavailable providers. A review should consider how the code exposes and recovers from these conditions. Observability is part of the design because a hidden failure is harder to correct safely.
What is wrong with this example NestJS service?
The example performs a read, checks stock in application code, and later writes a modified value. Those steps are not one atomic operation, so another request can change the record between them. It also trusts the quantity without showing validation, making both business-rule and concurrency bugs possible.
How can an atomic update prevent overselling?
A conditional atomic update makes the database check availability and reduce stock as one write operation. This avoids the application-level read/check/write gap. It protects the stock row, but related reservation records and repeated client submissions still need their own transaction and idempotency design.
What review comment would I leave?
A useful review comment explains an observable problem, its consequence and a concrete improvement. It should be specific enough to act on while leaving room for the author to discuss constraints. Focus on behavior and evidence rather than criticizing who wrote the code or whether AI generated it.
How do I spot common React and async bugs?
React and async bugs often come from incorrect assumptions about identity, snapshots and completion order. A render's values can be captured by a callback, and asynchronous results may arrive after the UI has moved on. Review the lifecycle and timeline rather than checking syntax alone.
Project deep dives
Explore topicExplain ownership, trade-offs, failure handling, and real project outcomes.
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.
What is the bottleneck?
A bottleneck is the resource or serialized step that limits throughput or increases waiting time. It can move after an optimization, so it is a property of a workload and system state rather than a permanent label on a component. Traces and saturation measurements help identify it.
What would you cache?
Caching reuses an earlier result to avoid repeated work. Good candidates are expensive repeated reads with an acceptable freshness window and a clear key. Caching is a poor shortcut when every answer must reflect the latest write or when users could share private results accidentally.
Where could a race condition happen?
A race condition happens when overlapping operations can violate a rule because their checks and writes are not coordinated. It can occur across requests even in a single-threaded Node process, and across multiple app instances. Identify the shared state and the exact interleaving that produces a wrong result.
What happens if a third-party integration is unavailable?
An unavailable integration should not cause unlimited waiting or silently lose accepted work. The design needs deadlines and an explicit user-visible outcome, such as failure, pending work or a stale-but-labeled result. Retry and reconciliation policies depend on whether the external operation is safe to repeat.
What happens if a database transaction fails halfway?
A database transaction is intended to prevent partial committed changes within its own boundary. If a participating statement fails and the transaction is rolled back, its uncommitted database changes are not kept. Other systems and earlier independent commits are outside that protection.
How would you monitor this system?
Monitoring tracks whether the system meets its operational goals and helps locate failures. Metrics show trends, logs show events and traces connect steps in a request or workflow. Useful monitoring includes business progress, not just whether processes are alive.
What would you redesign today?
A redesign answer should show what you learned from the existing system and how you would improve one real weakness. The proposal needs a benefit, a migration approach and an honest cost. Replacing a whole stack is rarely a convincing answer without a specific constraint driving it.
How do I explain Azure AD SSO and its tokens?
Single sign-on lets an application rely on an identity provider so users can reuse an established login. OIDC supplies login identity on top of OAuth, while access and refresh tokens support API access and session continuation. The client and API validate different token purposes rather than trusting any token returned by the login service.
What is a tenant, and why does it matter?
A tenant is an organizational identity boundary containing users, applications and policies. Multi-tenant applications must decide which organizations can sign in and which data each organization may access. Identity-provider tenant validation and application database tenant scoping are related but separate controls.
How do I explain workflow state, retries and compensation?
Workflow state records where a run is, which steps completed and what remains to be done. Retries repeat recoverable steps, while compensation performs a business recovery action after partial success. Durable state makes these decisions possible after a process restart instead of relying on in-memory progress.
How do I explain stored procedure optimization?
A stored procedure is database-side code that groups SQL operations and control flow into a callable unit. It can reduce application round trips and centralize data logic, but a procedure can still contain slow queries or hold locks too long. Optimization begins by finding the expensive statements and understanding their plans and transaction behavior.
How do I explain price/time priority and auditability?
Price/time priority chooses better eligible prices first and then the earlier accepted order among equal-price orders in a simple matching model. Auditability means accepted inputs and resulting decisions can be reconstructed and checked. Concurrency control, durable sequence and exact quantities are needed so recovery does not change the outcome.
Interview skills
Explore topicPrepare clear, honest answers and build independent technical judgment.
How should I explain a technical concept?
A good interview explanation gives the listener a usable understanding of a concept, not just a memorized definition. Start with what it is, why it exists and how it works at a basic level. Then connect the idea to an example, a mistake or a trade-off so the interviewer can follow your reasoning.
What should I study first?
Preparation works best when later topics build on earlier ones. JavaScript scope and async behavior support Node and React; database rules support backend correctness and system design. Follow the sequence, but spend extra time where you cannot yet explain a concept without reading the answer.
How do I answer a debugging question?
A debugging answer is an investigation plan that narrows a symptom to a cause using evidence. It should explain what you would measure, what the result would mean and what you would do next. Separate reducing user impact now from proving and preventing the underlying defect.
What if I do not know an answer?
An honest answer can still show strong engineering judgment when part of a topic is unfamiliar. Clearly separate facts you know, assumptions you are making and details you would verify. This lets the interviewer assess your reasoning without being misled by confident guesses.
How do I explain my own work?
A project answer should connect a real business problem with your specific contribution and its outcome. The problem → responsibility → action → result structure keeps the story clear without hiding technical details. Add the reason for an important decision and the trade-off you accepted.
How can I reduce dependence on AI?
Reducing AI dependence means being able to understand, test and change a solution without treating generated output as authority. Use AI as a source of candidate ideas, then establish correctness through your own reasoning and evidence. The goal is independent judgment, not avoiding useful tools entirely.
Mock interview questions
Explore topicRehearse coding and behavioral answers, then follow the technical mock rounds.
Explain your most difficult project.
A difficult-project answer should focus on one concrete challenge and how you handled it. The interviewer is assessing problem solving, ownership and learning more than the project's impressive name. Use real constraints and evidence so the explanation remains defensible under follow-up questions.
Tell me about a production issue.
A production-incident answer explains impact, investigation, mitigation and prevention in a clear order. It should show that you worked from evidence and reduced risk while users were affected. Use a genuine incident and avoid claiming a root cause you never confirmed.
Tell me about a technical disagreement.
A technical-disagreement answer shows how you compared competing priorities and reached a workable decision with others. The goal is to explain reasoning and collaboration, not prove that you won an argument. Use an example where evidence, constraints or a small experiment helped the team choose.
Tell me about a decision you changed later.
Changing a technical decision can show good judgment when new evidence invalidates an earlier assumption. Explain why the original choice was reasonable at the time and what information changed. Then describe how you migrated safely rather than simply declaring the first choice bad.
How do you validate AI-generated code?
Validating AI-generated code means taking responsibility for its behavior rather than accepting plausible-looking output. Start from requirements and trace the important paths, then use tests and documentation to verify assumptions. Generated code deserves the same correctness, security and maintainability standards as manually written code.
How do you maintain code quality?
Code quality is the ability of a codebase to remain correct, understandable and safe to change. It comes from clear design, meaningful tests, review and feedback from production behavior. Tools enforce some consistency, but they do not replace sound business rules or ownership of dependencies.
How do you remove duplicate IDs from an array?
Deduplication removes repeated values according to a defined equality rule. JavaScript Set handles primitive IDs conveniently and keeps the order of first insertion. Objects are compared by reference, so deduplicating records by an id field requires an explicit key-based approach.