Technical Interview Questions That Show How Developers Work

A candidate can pass every whiteboard round and still struggle to trace a timeout through three services. That gap is not surprising. Many technical interview questions reward recall of algorithms and syntax, while the job asks for judgment under constraints that are rarely clean.

A more useful technical interview is built around the decisions the engineer will actually make: which trade-off to accept, how to design something that will change, how to find a fault in production, how to leave code someone else can maintain, and how to tell people about risk early enough for them to act. An interview cannot predict or prove how someone will perform; how they perform on the job is the real evidence. Questions that resemble the work give you much better evidence than trivia does.

The 25 technical interview questions below are grouped by the skill each one examines. Each includes notes on what a useful answer covers, so a hiring manager who does not write code every day can follow the conversation. The notes are a basis for discussion, not the only acceptable answer. A candidate who reaches a different answer and explains it well may be giving you the better one.

How Should You Structure a Technical Interview?

Start with the three or four hardest problems the role will face in its first year, then choose questions that resemble them. For most roles, four to six questions in a 60-minute session, with time for follow-ups, give you more evidence than a long list asked quickly. Adjust that to the job: a role with heavy design responsibility may need a full session on system thinking alone.

If more than one person interviews the candidate, give each a different category so the questions do not overlap, and write down what a strong answer looks like before the first candidate arrives.

Fundamentals: Can the Candidate Explain Core Trade-Offs?

Useful fundamentals show up as reasoned trade-offs. A candidate who names a choice, names the alternative, and states the constraint that decided it is showing you how they are likely to make decisions in your codebase.

1. How Would You Choose a Data Structure for This Feature?

Give a concrete feature, such as a leaderboard that updates on every game result and displays the top 100 players. A good answer starts with access patterns: how often reads happen compared with writes, how large the data grows, and whether the ordering must be exact. A sorted set and a heap are both reasonable proposals, and the candidate should explain the cost of each operation in plain terms.

If the candidate names a structure immediately without asking about load or usage, ask what would change their choice. That follow-up shows whether they considered ordering and range queries.

2. When Would You Optimize for Time Instead of Memory?

Ask for a real example from their work. Good answers tie the choice to a measured bottleneck: a cache that trades memory for faster responses on a busy endpoint, precomputed results where latency targets are strict and data changes rarely, or streaming data in chunks where memory is capped, as it often is in serverless functions.

Listen for whether they measured before and after. Optimization on instinct tends to add complexity someone else has to maintain.

3. How Do You Handle Errors at a Service Boundary?

Ask how the candidate would handle a failed call to a payment provider or an internal API. A good answer separates error types. Transient failures get retries with backoff and a limit. Permanent failures, such as invalid input, return a clear error to the caller without a retry. The candidate should also mention timeouts, idempotency for retried writes, and logs with enough context to trace the request.

A strong candidate will also point out that a timeout does not tell you whether the payment went through, so the retry has to be safe either way. A generic catch block that logs and moves on deserves a follow-up question, since that habit hides failures until customers report them.

4. What Makes an API Contract Reliable?

Reliable contracts let teams ship without breaking each other. Ask how the candidate designs and changes an API other teams depend on. Look for explicit schemas with required and optional fields, versioning or additive-only changes so existing clients keep working, consistent error formats and status codes, and contract tests that fail the build when a change breaks a consumer.

Senior candidates often add deprecation windows and describe how they tell consumers about a breaking change before it ships.

5. How Would You Protect Sensitive Data in This Workflow?

Describe a workflow that handles personal or financial data, such as a signup flow that stores tax identification numbers. A good answer covers encryption in transit and at rest, least-privilege access, and keeping secrets out of code and logs. The candidate should also ask which data is needed at all, since data you never collect cannot leak. In regulated environments, audit trails and retention limits belong in the answer.

The question matters because small habits have large consequences here. Logging raw request bodies, for example, can put sensitive data into systems far more people can read.

System Thinking: Can the Candidate Make Sound Design Decisions?

Design questions show whether a candidate reasons about growth, failure and measurement before committing to an architecture. If the role carries significant design responsibility, give these questions a full session of their own.

6. How Would You Design This Service for Growth?

Pick a service close to your product, such as a notification system expected to grow from 10,000 to 1 million users. A good answer begins with requirements: expected traffic, latency targets, and whether every notification must be delivered. The candidate starts simple and names the point where the design would need to change, such as moving to a queue once synchronous sends no longer keep up. They should explain which parts scale horizontally and which become bottlenecks.

A large distributed design on day one is worth questioning. Ask what problem each component solves today; some candidates add infrastructure because it looks senior rather than because the requirements call for it.

7. Where Is This Architecture Most Likely to Fail?

Show a simple diagram of an existing architecture and ask where it breaks first. Good answers identify single points of failure, such as one database with no replica or one region with no failover, rank the risks by likelihood and impact, and propose what to monitor so each failure is detected early.

If a candidate says the design looks fine, ask them to imagine traffic doubling or a dependency going down. Most real systems have a weak point, and finding it is the skill.

8. How Would You Keep Data Consistent Across Services?

Ask how the candidate would keep an order service and an inventory service in agreement. A good answer names the trade-off between strict consistency and availability, then proposes a mechanism: an outbox to keep a local state change and its event consistent, event-driven updates with idempotent consumers, or a saga with compensating actions. The candidate should explain what the user sees during a temporary inconsistency.

Then ask what happens if the same event arrives twice. The answer shows whether the candidate has dealt with duplicate delivery in practice.

9. What Would You Measure Before Changing the Architecture?

Ask what data the candidate would collect before splitting a monolith or switching databases. Look for latency percentiles on key endpoints, error rates and their sources, saturation of CPU, memory and connection pools, and delivery measures such as deployment frequency and change fail rate. Source: DORA software delivery performance metrics

Time engineers spend blocked on shared code is worth asking about too.

Good candidates also define success in advance. In one enterprise security platform, heavy reporting queries ran against the same databases that served live operations, and that contention shaped the change that followed. If a candidate cannot say what would show a change worked, they are describing a preference rather than a plan.

10. How Would You Roll Out a High-Risk Change?

High-risk changes include database migrations, payment logic, and authentication updates. A good plan uses feature flags so you can turn the change off without a deploy, a canary or percentage rollout to a small group first, defined metrics and thresholds that trigger a rollback, backward-compatible data migrations in separate steps, and a named owner watching the rollout.

Ask for an example. Modernizing a 20-year-old point-of-sale system without downtime is the kind of work where each step matters, because the business keeps running on the system while it changes.

Debugging: Can the Candidate Find and Resolve Production Problems?

Good debuggers form a hypothesis, test it against data, and narrow the problem step by step. Scenario questions show that process far better than a toy bug on a whiteboard.

11. A Service Slows Down After a Deployment. What Do You Check First?

A good answer starts with the change. The candidate confirms the slowdown with latency metrics rather than a single report, checks whether it lines up with the deploy, reviews the diff for new queries, loops, or external calls, examines query plans and indexes, and looks at resource usage and connection pool exhaustion. If the impact is severe, they consider rolling back while they investigate.

Adding servers first is worth a follow-up. It may relieve the symptom, but it hides the cause and raises the cost.

12. How Would You Investigate an Intermittent Failure?

Ask how the candidate would approach a bug that appears once in every few hundred requests. Good answers look for a pattern: correlation with time of day, specific users, specific hosts, or request size. Race conditions, retries, timeouts, and resource limits are common causes, and targeted logging or tracing helps capture the failing case.

Listen for validation. A fix not confirmed against the original failure tends to come back as a reopened ticket.

13. What Would You Do If Logs Contradicted a User Report?

A user says checkout failed, but the logs show a successful transaction. A good candidate treats both as evidence. They check whether the logs cover the full request path, whether the failure happened in the client, and whether timestamps and time zones line up. They consider cases where the payment succeeded, but the confirmation screen failed.

Failures that never reach the server are easy to miss. We worked with a clinical research platform that lost data when an assessment crashed or a connection dropped before syncing, which server logs alone would not have shown. A candidate who dismisses the user because the logs look clean is missing that possibility.

14. How Would You Isolate a Fault Across Multiple Services?

Ask how the candidate would find the source of errors in a request that touches five services. A good answer uses distributed tracing, with trace context passed from service to service, to follow the request path, then checks error rates and latency per service to find where the problem begins, since downstream services often show symptoms of an upstream fault. Source: OpenTelemetry context propagation documentation

Recent deploys and configuration changes per service belong in the investigation. Senior candidates often describe how they communicate during the incident, so other teams stop changing systems while the investigation runs.

15. When Is a Rollback Better Than a Hotfix?

This is a decision question, and the answer shows how the candidate weighs risk.

Factor	Favors rollback	Favors hotfix
Cause identified	No	Yes, with high confidence
User impact	Severe or spreading	Limited
Fix complexity	Large or untested	Small and tested
Data changes involved	Reversible	Irreversible

Good candidates note that irreversible schema changes complicate rollbacks, which is why they plan migrations in reversible steps. Ask what they did the last time they had to make this call under pressure.

Code Quality: Can the Candidate Leave the System Easier to Maintain?

Maintainable code keeps the next change affordable. These questions show whether a candidate leaves a codebase easier to work in or adds costs every future engineer pays.

16. What Would You Change in This Code Review?

Give the candidate a 40- to 80-line snippet with real problems: a missing null check, a function doing three jobs, an unclear variable name, and a query inside a loop. A good reviewer prioritizes correctness and security, then performance, then readability. Their comments explain why and suggest a fix, and they separate blocking issues from preferences.

This format reflects work the engineer will do every week, which is why it often tells you more than a puzzle. A reviewer who focuses mainly on formatting, or rewrites everything, is showing you something about their priorities.

17. How Do You Decide What to Test?

Ask how the candidate chooses what to cover when time is limited. A good answer ranks code by the cost of failure. Payment logic, authentication, and data transformations get thorough tests. Edge cases, such as empty inputs and boundary values, get explicit coverage. Simple glue code gets less.

A coverage percentage alone is a weak goal. High coverage with weak assertions can make a test suite look more reassuring than it is.

18. When Should You Refactor Instead of Adding a Feature?

Refactoring first makes sense when the existing structure would make the new feature slower to build, harder to test, or more likely to introduce defects. Ask for an example. Clear triggers include logic that would otherwise be copied into a third place, code that cannot be tested without restructuring, and a recent bug traced to confusing structure in the same area.

Good candidates scope refactors tightly and ship them separately from features, which keeps reviews small and rollbacks simpler.

19. How Would You Work Safely in Unfamiliar Code?

Every new hire starts in unfamiliar code. Good candidates read the tests to learn expected behavior, trace one request end to end, and add characterization tests before changing legacy logic. They make small changes, verify each one, and use commit history or the original author for context.

Rewriting modules they do not yet understand is the pattern to probe. It tends to produce regressions and friction with the team.

20. How Do You Handle Technical Debt Under a Deadline?

Debt taken on under deadline pressure should be deliberate, recorded, and scheduled for repayment. A good answer names the debt, records it with the risk described, and tells the stakeholder what the shortcut will cost later. The candidate should be unwilling to cut corners on security and data integrity.

Unrecorded debt compounds. A funding platform built as a rapid prototype is a familiar example: the shortcuts that helped it launch became expensive as its data volume grew.

Communication: Can the Candidate Keep Delivery Aligned?

Communication determines whether problems reach decision-makers in time to act. An engineer who raises a risk early often contributes more than one who writes faster code and reports problems late.

21. How Would You Explain a Technical Risk to a Project Sponsor?

Ask the candidate to explain a real risk, such as an unsupported library in the payment path, as if you were a non-technical sponsor, then play that role. A good answer states the risk in business terms: what could happen, how likely it is, and what it would cost. The candidate offers two or more options with a recommendation and avoids jargon or defines it briefly.

Too much technical detail and too little are both worth noticing. Either can leave a sponsor unprepared to make a decision.

22. What Would You Do When Requirements Conflict?

Sales wants a feature quickly, and security requires a review. Good candidates raise the conflict early and in writing, identify who owns the decision, present the trade-off with the cost on each side, and record the outcome. Picking a side without telling anyone and building it anyway is the pattern to probe.

Recorded decisions also help later engineers understand why the system looks the way it does.

23. How Would You Respond to a Missed Milestone?

Ask for a real example of a milestone the candidate missed or saw coming. A good answer flags the slip as soon as it is likely rather than on the due date, explains the cause without blaming others, offers options such as reduced scope, more help, or a new date, and describes what changed afterward.

Early warning matters because options narrow over time. A slip reported a month ahead leaves choices that a slip reported the day before does not.

24. When Would You Challenge an Architectural Decision?

A candidate should challenge a decision when they have evidence it will cause a concrete problem, and do it through the right channel. Good answers show the candidate gathered data, raised the concern with the decision owner, proposed an alternative, and committed to the final decision once it was made. They can distinguish a preference from a risk.

A useful follow-up is to ask what would change their mind about their own position. Engineers who never challenge let weak decisions spread; engineers who reopen settled decisions slow the team down. The question helps you see which way a candidate leans.

25. How Do You Hand Over Work Another Engineer Must Maintain?

Ask what the candidate leaves behind when they finish a project. Good answers include a README covering setup, deployment, and known issues; decision records explaining key choices; runbooks for common operational tasks; the access the next team needs; and a live walkthrough with the engineer taking over.

Knowledge that lives in one person’s head is a single point of failure. Good handoffs make it less likely the next team will rewrite a working system because nobody can explain it.

How Should Interviewers Score Answers Consistently?

Write the rubric before the interview, and have each interviewer score independently before discussing the candidate. Without a shared standard, the most confident voice in the debrief tends to decide the outcome. A four-point scale can organize the notes:

Score	Label	What it sounds like
1	No evidence	Guesses, cannot explain the reasoning, or skips the question
2	Partial	Correct answer with no trade-offs or constraints named
3	Strong	Names options, chooses one, and explains the deciding constraint
4	Exceptional	Adds failure modes, measurement and business impact without prompting

 

Write the expected strong answer next to each question so every interviewer grades against the same standard. The score is an interview aid, not a validated predictor of performance, so record the specific evidence behind each score.

Which Interview Questions Should You Avoid?

Questions that mainly measure memorization, puzzle tricks, or comfort under observation tell you little about how someone will work, and they can screen out capable engineers.

Question type	Example	Why it adds little
Trivia	“What does this obscure flag do?”	Tests recall any engineer can look up in seconds
Gotchas	Riddles and brain teasers	Rewards having seen the trick before
Whiteboard recall	Implement a red-black tree from memory	Measures memorized algorithms under observation, not daily work
Unscoped design	“Design Twitter” with no constraints	Invites generic, rehearsed answers

 

Replace them with scenarios drawn from your own systems. A simple check for any question in your bank: what part of the real job does it resemble? If the answer is none, cut it.

How Gun.io Assesses Developers

At Gun.io, the purpose of a technical conversation is practical: what responsibility can this engineer reasonably carry in a particular engagement? We evaluate technical capability and professional fit through human interviews, and questions like the ones above help answer that. Work history and implementation ability add to the picture, but no single interview settles it. How someone performs in the actual environment is the real evidence, so selection continues well after an engineer starts.

We pay particular attention to the habits these questions expose: measuring before changing, validating a fix, recording decisions and raising risk early. Those habits matter in the work we take on, from backend and data systems to modernization projects that cannot interrupt the business.

Frequently Asked Questions

What Are Good Technical Interview Questions for Software Developers?

Good technical interview questions ask candidates to reason through realistic scenarios, such as debugging a slow service or rolling out a risky change. They show trade-off judgment and communication, which matter more on the job than recall. Avoid trivia and puzzles.

Can Technical Interview Questions Predict How a Developer Will Perform?

No, not on their own. Technical interview questions give you evidence about how a candidate reasons, and that evidence is stronger when the questions resemble the real work. How someone performs on the job is the real evidence, so treat interview scores as one input alongside work history.

How Many Questions Should You Ask in a Technical Interview?

Four to six in a 60-minute session usually works, with time for follow-ups. Depth on a few scenarios tells you more than shallow coverage of many. Adjust the number to the role and the time you have.

How Do You Evaluate a Technical Answer if You Cannot Review Code?

Evaluate the structure of the reasoning: whether the candidate asks clarifying questions, names alternatives, and explains the deciding constraint. A written rubric with an example of a strong answer helps non-specialists score consistently. For code-heavy roles, include a technical reviewer in at least one conversation.

Should You Use Live Coding or a Take-Home Assessment?

A short, scoped take-home or a paired code review suits most roles, since both resemble real work with less observation pressure. Live coding works well when it is collaborative and based on a realistic problem. Whichever you choose, follow up with a conversation about the candidate’s choices.

What Are the Hardest Technical Interview Questions to Answer Well?

Questions about intermittent failures and data consistency across services are among the hardest, because good answers draw on experience with real production systems. A strong answer is useful evidence of senior-level judgment, especially when it holds up under follow-up questions.

Hire for the Judgment the Work Requires

Choose questions that resemble the work the engineer will do in their first months, write the strong answer before the first interview, and score independently before you compare notes, then let performance on the job confirm what the interview suggested.

If you are hiring for a role like this, talk to us about what you’re building and bring the hardest problems the role will face this year, along with the constraints around them.