Technical Interview Questions and 12 Worked Answers

By Mustafa Tarabya, founder of CVBooster · Published 2026-09-12 · Updated 2026-09-12

12 min read

Technical interview questions come in two kinds, and candidates prepare for the wrong one. Half the loop asks what you know; half asks how you behaved when a system broke, scored like any other behavioral question. The interviewer is marking your reasoning out loud rather than the final answer, so a correct answer given silently loses to a wrong one talked through. Twelve full answers follow, checked in September 2026, seven as STAR stories and five as knowledge answers, plus the answer that loses and five questions to ask back. Written by Mustafa Tarabya, who hired for his own company, read every application himself and now writes CVBooster's guides.

Here is the first one complete, with the thinking left in.

Walk me through how you would debug a service that is slow only in production.

Situation: In 2025 our checkout API responded in about 90 milliseconds on staging and between 2 and 6 seconds in production, on the same build. Task: I owned the service and had to find the cause before the next release, without a load test environment. Action: I started with what differed rather than the code, because the build was identical: data volume, concurrency, network hops, configuration. I timed the same request at three layers, load balancer, application and database, and the application layer accounted for only 40 milliseconds. That pointed at the database. The slow query log showed one query against a table with 14 million rows in production and 2,000 on staging, missing an index. Result: Adding the index took the endpoint to about 120 milliseconds. I then added a staging data set at 10 percent of production volume, which caught two more missing indexes before release.

Tailor my CV to this job

What a technical interviewer is scoring

Technical loops are scored against published competencies more often than candidates realize. The Information Technology Competency Model, maintained by the Employment and Training Administration at the US Department of Labor, defines the technical tier plainly. Its software competency covers "the process of designing, writing, testing, debugging/troubleshooting, and maintaining the source code of computer programs", and its support competency covers "assistance and technical support to help users implement and solve problems". Debugging and support sit inside the definition, not beside it.

The model is explicit that nobody is expected to hold all of it: "it is not intended that IT workers possess all of the competencies listed". That is your permission to say you do not know something, then say how you would find out.

The task wording in O*NET profile 15-1252.00, the Department of Labor's occupational database, tells you what your examples should be about: "analyze user needs and software requirements to determine feasibility of design within time and cost constraints" and "modify existing software to correct errors, adapt it to new hardware, or upgrade interfaces and improve performance". Constraints and maintenance, not greenfield building.

On the behavioral half, employers publish what they want. Amazon's Leadership Principles include Dive Deep, which asks people to "stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ", and Insist on the Highest Standards, which asks that "defects do not get sent down the line". Both are interview questions in disguise.

Tip: Say your assumptions out loud before you start, then say which one you are testing first. That sentence is most of the score.

Four answers about how you work

Tell me about the most technically difficult problem you have solved.

Situation: A nightly batch job that reconciled 400,000 payment records started failing intermittently in March 2025, roughly one run in four, with no error in the log. Task: I had two weeks before an audit that needed six months of clean reconciliations. Action: I made it reproducible before trying to fix it, which took most of the first week. I added timing and row counts at every stage, and the failures matched runs that overlapped a replication lag spike: the job was reading a replica mid-catch-up and silently getting fewer rows. I moved that read to the primary and added a row count assertion that failed loudly. Result: Thirty consecutive clean runs before the audit. The assertion caught a genuine data problem two months later that would otherwise have been invisible.

Describe a time you disagreed with another engineer about a technical decision.

Situation: A colleague wanted to move our scheduled jobs onto a message queue in 2024. I thought a cron table plus a lock was enough for six jobs. Task: We had to agree before the sprint started, and he was more senior. Action: I wrote down what we each thought the queue bought us, then tested the claim that mattered: whether jobs were actually overlapping. Two of the six were, both on one server. I proposed the lock as a two-day fix, with the queue as the plan past twelve jobs or once we needed retries, and put that trigger in writing so it was a decision rather than a veto. Result: The lock shipped in two days and held for eighteen months. When the count reached fourteen jobs we moved to the queue, and he led it. Neither of us had to be wrong.

Tell me about a time you broke production.

Situation: In June 2024 I ran a data migration that rewrote 60,000 customer records and truncated any address line over 40 characters, which I had not tested against real data. Task: About 900 addresses were wrong and the next delivery file went out at 18:00. Action: I said so immediately rather than fixing it quietly, because the delivery file was the deadline. I restored the affected column from the pre-migration snapshot into a temporary table, matched on the primary key, and repaired the 900 rows in about 40 minutes. I wrote the post-mortem myself, naming the missing step: a length check against production data rather than the schema. Result: The delivery file went out correct and on time. Every migration since runs a field-length report against a production copy first, and that check has blocked two similar changes.

Tell me about a time you had to learn an unfamiliar system quickly.

Situation: I inherited a 9,000-line reporting service written in a language I had not used, two weeks before its only maintainer left. Task: I had to be able to fix it in production, not to rewrite it. Action: I did not read it top to bottom. I traced one real report end to end, from request to query to rendered output, and drew that path on paper. Then I broke it on purpose in a copy, three times, to see what the failures looked like in the logs. I used the maintainer's last week for the five questions my notes could not answer. Result: I fixed the first production bug alone in the second week. The traced diagram and the five answers became the handover document, which the next engineer used instead of shadowing anyone.

Five knowledge answers, given properly

What is the difference between SQL and NoSQL, and when would you pick each?

Answer: A relational database enforces a schema and gives you joins and transactions across tables. A document or key-value store trades those for a flexible shape and easier horizontal partitioning. I pick relational by default, because most business data has relationships and I would rather the database reject bad shapes than find them later. I pick a document store when the access pattern is one key returning a nested object, when the shape genuinely varies per record, or when write volume needs partitioning a single primary cannot take. Where it goes wrong: Saying one "scales better" without naming the access pattern. The follow-up is always "scales in which dimension", and reads, writes and storage have different answers.

When is it appropriate to denormalize a database design?

Answer: When a read path that matters is slow because of joins, and I have measured it. Denormalizing means accepting duplicate data and the job of keeping copies in step, so it buys read speed with write complexity and risk. I would do it for a reporting table rebuilt on a schedule, or a counter kept alongside the rows it counts, and I would keep the normalized tables as the source of truth. I would not do it because a design "looks like it will be slow". Where it goes wrong: Denormalizing before there is a query plan to point at. Interviewers ask this to see whether you measure first.

What is the difference between a process and a thread?

Answer: A process has its own memory space, so two processes cannot see each other's variables without going through the operating system. Threads live inside one process and share that memory, which makes them cheap to start and cheap to pass data between, and also means two threads can corrupt the same structure at once. That is why shared state needs a lock, and why a crash takes down every thread in the process but not the other processes. I reach for separate processes when isolation matters more than speed. Where it goes wrong: Reciting the definition with no consequence attached. The consequence, shared memory means synchronization, is the part being scored.

How would you find a memory leak?

Answer: I confirm it first by watching resident memory over hours under steady load, because a rising graph that plateaus is a cache, not a leak. If it keeps climbing, I take two heap snapshots an hour apart and compare object counts by type rather than by size, because the leaking type usually grows in count while everything else is flat. Then I look at what holds a reference to it, which is normally a collection that is added to and never cleared, an event listener never removed, or a connection never closed. Where it goes wrong: Reaching for a profiler before deciding what a leak would look like in a graph. Say the measurement first.

What happens when you type a URL into a browser?

Answer: The browser resolves the hostname through DNS, opens a TCP connection, and negotiates TLS if the scheme is HTTPS. It sends an HTTP request, a server or a proxy answers, and the browser parses the HTML, then fetches the scripts, stylesheets and images it refers to, rendering as it goes. I give those five steps, then offer depth on one, usually DNS caching or TLS, rather than guessing which layer the interviewer cares about. Where it goes wrong: Starting at the packet level. This question tests structure and awareness of your audience.

Three answers about judgment

How do you decide what to test?

Situation: A payments module I maintained in 2024 had 300 tests, took eleven minutes to run, and still let two bugs into production that quarter. Task: I wanted fewer, better tests, and time back in the pipeline. Action: I mapped the two escaped bugs to the code they touched. Neither path had a test, while 40 tests covered getters. I deleted those 40, wrote tests for the two escaped paths and for every boundary where money was rounded or split, and added one end to end test through the gateway sandbox. Result: The suite came down to 210 tests and under four minutes, and nothing escaped in the following two quarters. I now start from what would cost money if it broke, not from a coverage number.

How do you explain a technical problem to a non-technical stakeholder?

Situation: In 2025 I had to tell a finance director why a report she relied on would be two days late after a schema change. Task: She needed to decide whether to delay a board pack, not to understand the schema. Action: I gave her the decision first: the report will be ready Thursday rather than Tuesday, and the numbers will be right. Then one sentence of cause with no jargon, that a field had changed shape and the old query was reading the wrong column. Then two options, wait for Thursday or take Tuesday's version with the affected column blank. Result: She took Tuesday with the column blank and moved that section of the board pack. I now lead every update with the date and the decision, and keep the cause to a sentence.

How do you keep your technical knowledge current?

Situation: I work in a small team, so nobody assigns me learning, and I stopped trusting my own reading list in 2023 when I noticed it was all things I already agreed with. Task: I wanted a method that produced something usable rather than a pile of bookmarks. Action: I now pick one thing a quarter that sits next to a real problem we have, and build the smallest version of it. Last quarter that was a small load generator to understand our own rate limits. I also read the release notes of the three dependencies we run in production, which is fifteen minutes a month. Result: Two of the last four quarterly builds went into production, and the release notes habit caught a deprecation that would have broken our scheduler this year.

Tailor my CV to this job

The answers that lose the job

The debugging question at the top of this page, answered the way most candidates answer it.

"I would check the logs and look at monitoring to see what is going on. Production is always different from staging, so it could be a load issue or a config issue. I would probably talk to the team to see if anyone had seen it before, and then start looking at the code to see what might be causing the slowness, and test some fixes until it improved."

It loses for one reason: no order and no test. Every option is listed and none chosen, so the interviewer learns nothing about how this person narrows a problem. "Could be load or config" with no measurement to tell them apart is the opposite of Dive Deep. "Test some fixes until it improved" says the candidate changes things before understanding them, the one behavior a technical interview exists to screen out.

The fix: name what differs, say which difference you are testing first, and say what measurement would rule it out.

Questions to ask them

What does the on-call rotation look like, and what paged you most last month?
How long does a one-line change take to reach production?
What is the oldest system I would be expected to touch, and who understands it?
How is technical debt decided on and funded here?
What did the last person in this role find hardest?

Related pages: STAR interview questions covers the behavioral half, competency based questions the written version, and computer skills how to list a technical stack on a CV without padding it.

Frequently asked questions

How to answer interview questions?

Answer the question in the first sentence, then support it with one specific example or one ordered method. In technical interviews, state your assumptions out loud and say which one you are testing first. Interviewers score the reasoning they can hear, so silent correctness scores badly.

How to answer job interview questions?

Use one real event per behavioral question, structured as the situation, what you owned, the steps you took and the measured result. For knowledge questions, give the short definition, then the consequence that makes it matter, then offer depth on one part rather than guessing.

What questions to ask in an interview?

Ask about the on-call rotation, how long a one-line change takes to reach production, the oldest system you would touch, how technical debt is funded, and what the last person found hardest. Those five answers tell you more about the job than any description.

What are good questions to ask in an interview?

Good questions are ones only this team can answer, and they should cost the interviewer some honesty. Ask what paged them most last month, or what they would fix with two free weeks. Avoid questions about culture in the abstract and anything already on the careers page.

More in this series: Interview questions and answers

Looking for a worked example for your job title? Browse the resume examples by job title.

Get your free ATS score · All articles