Technical Interview Questions

Use these technical interview questions to practice explaining your reasoning, not just recalling definitions or writing code.

Updated October 2026 · 14 min read

Technical interviews are not only a test of whether you know a term or can reach a correct answer. Interviewers also listen for how you break down an unfamiliar problem, make assumptions visible, compare options, and check your own work. That is especially important when the question is answered aloud, as it often is in a phone screen, system design conversation, or discussion of a production issue.

This page focuses on questions a software engineer can answer verbally. It includes foundations such as hash maps and Big O, architecture conversations such as rate limiting and chat, and engineering judgment questions about debugging, testing, and trade-offs. For timed practice, use the AI mock interview for software engineers. You can speak or type an answer, then review feedback on structure, evidence, length, and filler words.

What technical interviews test

A technical interview has several layers. Correctness matters, but it is only one layer. A candidate who names the right data structure without explaining why may leave the interviewer unsure whether the choice was deliberate. A candidate who talks through the constraints, compares two workable approaches, and catches a limitation gives the interviewer more evidence of sound judgment.

Correctness

Start with a solution that actually addresses the problem. For a concept question, define the term accurately and connect it to a use case. For a design question, make sure the components you name have a clear role. For a debugging question, separate observed facts from assumptions. Correctness also means noticing boundary conditions, such as a cache returning stale data or a rate limiter behaving differently during a burst.

Communication

Strong technical communication is organized. The interviewer should be able to follow your answer without reconstructing it for you. Say what you are going to cover, use a small example, and pause when a decision depends on missing information. If you change direction, explain why. This is not about sounding formal. It is about making your reasoning inspectable.

Trade-offs

Most engineering choices have a cost. An index can speed up a read but add write work. A cache can lower latency but introduce invalidation and staleness problems. A relational database can support clear relationships and transactions, while a different storage model may fit a particular access pattern or scale requirement. Interviewers want to hear that you recognize these costs and choose based on the problem, not a favorite technology.

How to think out loud

You do not need a polished speech for every question. You need a repeatable routine that keeps you from jumping to an answer before you understand the problem. The same routine works for algorithmic questions, system design, and practical debugging prompts.

Clarify the goal and constraints
Restate the problem in your own words. Ask about input size, latency, availability, ordering, privacy, or expected scale when those details would change the answer. State any assumption you make.
Use a small example
Walk through a compact example before proposing an approach. It reveals ambiguity and gives you a concrete way to explain data flow, edge cases, or output.
Start with the simple approach
Name a straightforward baseline, even if it is not the final answer. Explain why it works and where it becomes too slow, too expensive, or too difficult to operate.
Optimize for the stated constraint
Improve the baseline only after you can name the bottleneck. Compare the new choice with the old one in terms of time, space, complexity, reliability, or cost.
Test the answer aloud
Run through edge cases and failures. Mention empty input, duplicates, retries, partial outages, unusually large data, or concurrent requests when they are relevant.

For a coding-oriented prompt, this routine means you can explain the intended algorithm before touching an editor. For a system design prompt, it means you identify requirements before drawing services. For a behavioral engineering prompt, it helps you give the situation before the lesson learned. The STAR method guide is useful for those story questions.

Technical interview question categories

Question banks are easier to use when you group them by the skill they test. Do not memorize a script for every item. Instead, prepare a simple explanation and one example for each recurring category.

Core concepts and data structures

These questions test whether you can build on shared vocabulary. You may be asked to explain a hash map, a process versus a thread, an index, or a REST API. Give a definition, describe the mechanism at a useful level, then offer a practical example and limitation. If the question involves complexity, say what operation you are measuring before giving Big O.

Data and distributed systems

Questions about SQL versus NoSQL, caching, idempotency, and CAP test whether you can reason about data under real constraints. The best answer does not start with a product name. Start with consistency, query patterns, expected traffic, failure tolerance, and the cost of stale or missing data. Then name a design that fits those needs.

System design

A URL shortener, rate limiter, news feed, or chat service are vehicles for a design conversation. Ask what scale and guarantees matter. Outline the user flow, data model, and main components. Only then discuss the bottleneck that will matter first. A good answer might say that message ordering is only guaranteed within a conversation, rather than promising a global ordering model that is unnecessary and expensive.

Debugging and production judgment

Production prompts are less about finding a single cause from thin air. They test how you make an incident safer while you investigate. Start by defining the symptom and blast radius, then check recent changes and high-signal telemetry. Form a hypothesis, gather evidence, and choose the least risky mitigation. Finish with what you would change to detect or prevent the issue earlier.

Code quality and testing

Engineers need to explain why a change is maintainable, not just functional. Be ready to discuss code review, test layers, observability, API compatibility, and technical debt. The useful answer depends on the context. A small pure function may need focused unit tests, while a payment flow may need integration coverage around its boundaries. Explain the confidence you need and the failure you are trying to catch.

Engineering behavioral stories

Many technical loops include stories about the hardest bug you solved, a disagreement over an architecture decision, or a deadline that created technical debt. These are behavioral questions with technical evidence. Prepare the setup, your specific actions, the result, and the lesson. Avoid describing only what the team did. The interviewer needs to understand your judgment and contribution.

Full list of technical interview questions

Work through these questions in different modes. First, answer without notes. Next, record yourself and listen for unclear transitions or undefined terms. Finally, practice under a timer. You do not need the same answer every time, but the structure should become familiar.

Explain how a hash map works, including collisions and why lookups are usually fast.
Tests whether you can explain data structures clearly, including average complexity and collision handling.
Practice
How would you explain Big O notation to a nontechnical product manager?
Tests clear communication about algorithmic growth without relying on jargon or formulas alone.
Practice
When would you choose an array over a linked list, and when would you choose a linked list?
Tests trade-off reasoning around access, insertion, memory layout, and practical usage.
Practice
Explain the difference between a stack and a queue, then give a practical use case for each.
Tests whether you can connect basic structures to concrete engineering problems.
Practice
Why are balanced trees useful for database indexes?
Tests your ability to connect data structures, ordered access, and storage-system behavior.
Practice
What is the difference between a process and a thread?
Tests operating-system fundamentals, isolation, memory sharing, and failure boundaries.
Practice
What is a race condition, and how would you prevent one?
Tests whether you can identify shared-state risks and choose an appropriate synchronization strategy.
Practice
Compare REST and GraphQL. What trade-offs would guide your choice?
Tests API design judgment, not whether you treat one approach as universally better.
Practice
How would you decide between a relational database and a NoSQL database for a new service?
Tests data-modeling judgment, consistency needs, query patterns, and operational trade-offs.
Practice
Where would you add caching in a web application, and what could go wrong?
Tests performance reasoning alongside invalidation, staleness, capacity, and failure-mode awareness.
Practice
Explain the cache-aside pattern and when you would use it.
Tests whether you can describe a common caching pattern and its consistency limitations.
Practice
What is a database index, and why can adding too many indexes hurt performance?
Tests read-versus-write trade-offs and an understanding of how indexes support queries.
Practice
Explain the CAP theorem in practical terms for a distributed system.
Tests whether you can discuss network partitions and consistency choices without oversimplifying CAP.
Practice
What does idempotency mean for an API, and why does it matter?
Tests reliable API design, retry safety, and your ability to use a concrete example.
Practice
Walk me through how you would find duplicates in a 10GB file that does not fit in memory.
Tests decomposition, constraints, external-memory thinking, and communicating an approach before implementation.
Practice
Design a URL shortener. Start by clarifying requirements, then describe the high-level architecture.
Tests structured system design, data modeling, scale assumptions, and sensible trade-offs.
Practice
Design a rate limiter for a public API. Which algorithm would you use and why?
Tests distributed-systems thinking, fairness, storage choices, and handling bursts versus sustained traffic.
Practice
Talk through a high-level design for a personalized news feed.
Tests feed fan-out trade-offs, ranking boundaries, data flow, and how you frame scale.
Practice
How would you design a chat service that supports message ordering and offline users?
Tests real-time architecture, delivery semantics, persistence, and explicit assumptions about ordering.
Practice
Design a service for uploading large files reliably over unreliable networks.
Tests resilience, resumable uploads, validation, storage boundaries, and user-facing failure handling.
Practice
A service's latency suddenly doubles after a deployment. How would you investigate?
Tests incident triage, hypothesis-driven debugging, safe rollback judgment, and communication under pressure.
Practice
How would you diagnose a memory leak in a production service?
Tests observability, reproduction, profiling, safe mitigation, and distinguishing leaks from traffic changes.
Practice
How would you debug an intermittent failure that you cannot reproduce locally?
Tests use of logs, traces, correlation, environmental differences, and controlled experiments.
Practice
A database query becomes slow as the table grows. What would you check first?
Tests query plans, indexes, data distribution, load context, and avoiding premature fixes.
Practice
How would you change a widely used API without breaking existing clients?
Tests versioning, rollout planning, compatibility, observability, and communication with downstream users.
Practice
What do you look for in a code review besides whether the code works?
Tests maintainability judgment, correctness boundaries, readability, tests, security, and operational impact.
Practice
How do unit, integration, and end-to-end tests differ, and how would you balance them?
Tests pragmatic testing judgment, confidence boundaries, feedback speed, and maintenance cost.
Practice
What signals would you add to a new production service before launch?
Tests operational readiness through metrics, logs, traces, alerts, and meaningful service objectives.
Practice
Tell me about a time you made a technical debt trade-off under a deadline.
Tests ownership, risk communication, and whether you created a credible follow-up plan.
Practice
Tell me about the hardest bug you have investigated and how you found the cause.
Tests persistence, debugging discipline, technical depth, and a clear account of your contribution.
Practice
Tell me about a disagreement over a technical approach and how you resolved it.
Tests evidence-based collaboration, respectful conflict, and willingness to change your mind.
Practice
Tell me about a production incident you helped handle. What did you do first?
Tests calm prioritization, ownership, communication, and lessons that improved future reliability.
Practice
Tell me about a time you improved code quality or developer productivity.
Tests initiative, measurable impact, adoption, and your ability to explain a technical improvement plainly.
Practice
Tell me about a time you influenced an engineering decision without being the decision maker.
Tests technical communication, stakeholder awareness, and influencing through evidence rather than authority.
Practice
How would you get productive in an unfamiliar codebase with an urgent bug to fix?
Tests prioritization, codebase navigation, risk management, and asking focused questions.
Practice

Sample verbal answers

These examples are deliberately spoken rather than written like documentation. Notice the order: definition first, mechanism second, then a concrete use and limitation. Use your own wording when you practice.

Sample answer: Explain a hash map

A hash map stores values under keys so it can usually retrieve a value quickly. When I add a key, the map runs that key through a hash function to produce a number, then uses that number to choose a location in an underlying array. To look the value up later, it hashes the same key and checks that location again. On average, insert and lookup are O(1), assuming the keys are spread reasonably evenly.

Two different keys can land in the same location, which is a collision. A common way to handle that is to keep a small list or another structure at that location and compare the original keys. If too many collisions happen, lookup slows down, so implementations resize and rehash as the map fills. I would use a hash map for something like looking up a user profile by user ID. I would not choose it when I need values returned in sorted key order, because the structure is optimized for lookup rather than ordering.

Sample answer: Design a rate limiter

I would first clarify whether the limit is per user, API key, IP address, or endpoint, and whether short bursts are allowed. For a public API, I would likely use a token bucket because it allows a controlled burst while enforcing an average rate. Each client has a bucket with a capacity and a refill rate. A request consumes one token. If the bucket is empty, the service returns a rate-limit response and tells the client when it can retry.

For one server, the counter can live in memory. For multiple API servers, I would use a shared fast store and an atomic operation so two servers cannot both accept the last token. I would include the remaining-limit and reset information in the response. I would also decide what happens if the shared store is unavailable. For a sensitive endpoint, I might fail closed. For a low-risk endpoint, I might allow traffic temporarily and alert, because blocking every request during a limiter outage could be worse.

Big O reference for verbal explanations

Big O is a way to describe how resource use grows with input size. It does not replace discussion of constants, network calls, memory limits, or database behavior. In an interview, use it to compare approaches, then explain what the comparison means in practice.

Complexity	Meaning	Common example
O(1)	Does not grow with the number of inputs.	Average hash map lookup by key.
O(log n)	Grows slowly as input grows.	Binary search in sorted data.
O(n)	Touches each input once.	Scanning a list for a maximum value.
O(n log n)	Common for efficient comparison sorts.	Sorting records before processing them.
O(n²)	Compares many pairs of inputs.	Checking every item against every other item.

Be precise about average versus worst-case behavior when it matters. Hash map lookup is commonly described as O(1) on average, but adversarial collisions can worsen it. A balanced tree index commonly supports logarithmic lookup, but a query can still be slow if it returns a large result set or requires expensive joins. The purpose of the explanation is to show you can identify the dominant work.

Mistakes to avoid in technical interviews

Answering before clarifying the problem. A brief question can prevent an answer optimized for the wrong constraint.
Using terms without explaining the decision. Saying “use a cache” is not enough. Say what is cached, how it expires, and what happens when it is stale.
Skipping the baseline. A simple first approach makes your optimization easier to understand and justify.
Claiming certainty during a production scenario. State what you would verify before changing a live system, especially if the evidence is incomplete.
Ignoring trade-offs. Every design has a boundary. Name the cost of your choice and the condition under which you would revisit it.
Giving a team-only story. For an engineering behavioral question, use “I” to explain your own actions while crediting the team accurately.

Technical practice should sit alongside role-specific and behavioral preparation. Review data analyst interview questions if your role crosses into analytics, and use the behavioral interview questions bank to prepare stories about collaboration, conflict, and ownership. Then return to the software engineer practice track and rehearse an answer until it is clear without sounding memorized.

Frequently asked questions

What questions are asked in a technical interview?

Technical interviews commonly cover core concepts, problem solving, system design, debugging, testing, and the decisions behind your work. The exact mix depends on the role, seniority, and company.

How do I prepare for technical interview questions without a coding editor?

Practice saying your reasoning in a fixed order: clarify the problem, use a small example, state a simple approach, improve it, and test edge cases. You can rehearse that process in the software engineering mock interview.

Should I explain Big O in a technical interview?

Yes, when you compare approaches or discuss scale. State the time and space cost plainly, then explain what input size or operation makes that cost matter.

How long should a technical interview answer be?

A direct concept question often needs one to two minutes. A system design or problem-solving question can take longer because the interviewer expects you to clarify requirements and discuss trade-offs.

What should I do if I do not know a technical interview answer?

Say what you do know, name your assumption, and reason from first principles. Ask a focused clarifying question if it changes the solution. Avoid guessing with unexplained jargon.

Are behavioral questions part of a technical interview?

Usually, yes. Engineers are often asked about production incidents, technical disagreements, code quality, and collaboration. Prepare structured stories with the STAR method.