Knowing how to answer technical interview questions starts with one habit: talk the interviewer through your thought process and explain why you choose one option over another.
Picture a candidate handed a linked-list problem with a marker in hand and no solution in mind. The strongest move is to start narrating, because the interviewer is reading the approach as much as the result. The sections below pair each common question type with an answer shape and the signal behind it. Wider planning advice sits in career advice for tech professionals.
Question types at a glance
Technical interviews are most common in tech, engineering and computer science fields, and the questions change with the role. A software engineer and a product manager, for example, are usually not asked the same ones, as Morehouse College’s career development office explains. Hays notes that candidates may meet one, or a combination, of three standard assessment methods, including scenario and competency questions.
| Question type | What the interviewer is reading | Answer shape | Planning use |
|---|---|---|---|
| Data structures and algorithms | How you approach and solve a common technical problem | Name the structure, state the approach, justify it against an alternative | Practise saying the trade-off aloud, not only coding it |
| Whiteboard or paper coding | Visible thought process rather than flawless output | Narrate while writing and correct in the open | Rehearse away from an editor |
| Scenario and design | Whether your choices fit the context | Explain why you pick X over Y here | Prepare reasons, not memorised architectures |
| Behavioral or competency | Clear description of past work | Situation, Task, Action, Result | Prepare a few real stories |
| Product-focused | Homework on the product | Say what you like or dislike and why | Use the product before the interview |
The question types come from Morehouse College career development and Hays interview guidance.
Data structures and algorithms questions
These questions suit candidates who can name a data structure, say why it fits and describe how it behaves. A technical interview measures how you approach and solve common, and often difficult, technical problems, according to Morehouse College. The answer is therefore a method, not a recited result.
Interviewers working from an interviewer’s own account of textbook answers describe a much more constrained universe of solutions for most coding interview questions. A classic example is detecting a cycle in a linked list. Expect a familiar problem shape, and spend your effort on explaining the choice of structure and the reasoning behind it.
Model answer structure
- Restate the problem. Say it back in your own words so the interviewer can correct a misreading early.
- Name the structure and the approach. Link the data structure to what the problem needs, then describe the algorithm in plain language before writing anything.
- Justify against an alternative. Explain why you choose X over Y and how it makes sense in this context, which is the reasoning Morehouse says to show.
The signal being read is reasoning. A memorised answer delivers less than one that goes beyond the textbook, because the conversation becomes more interesting once a candidate moves past it, as the same interviewer observes.
Whiteboard and paper coding problems
A whiteboard interview usually involves a coding problem to solve on a whiteboard or a piece of paper, according to Hays. This format suits candidates who can think aloud, and it is harder for those who go silent while they write.
The evaluation signal is visible thinking. Hays states that it does not matter if you are not entirely correct, because the focus is the thought process. In practice, a tidy partial solution with clear narration is a stronger answer than a silent attempt that happens to finish.
- Write a little, say a little. Pair each line or box with a sentence of explanation so the interviewer follows the reasoning.
- Keep the layout readable. Leave room on the board or page for changes, since an approach may be revised mid-answer.
- Practise without autocomplete. Prepare by rehearsing on paper. Detailed drills are in the guide on how to prepare for a coding interview.
Scenario and system design questions
Scenario questions suit candidates who can reason about trade-offs rather than recall one correct design. Hays lists scenario questions among the standard assessment methods, and Morehouse advises explaining why you choose X over Y and how it makes sense in this context.
For system design interview preparation, that advice shapes the answer structure. Sketch the main pieces as boxes and arrows, then spend most of the time on why each choice fits the situation described. A design stated without reasons gives the interviewer little to assess.
- Anchor choices in the stated context. Tie each decision to what the interviewer described, not to a favourite tool.
- Compare at least two options aloud. The comparison is the evidence of judgement.
- Keep the sketch simple. A diagram that can be redrawn quickly invites discussion.
Behavioral and competency questions
A behavioral question asks about past work, and it suits candidates who have real examples ready. Hays recommends the STAR technique, which stands for Situation, Task, Action and Result, for competency-style questions in technical interviews.
The evaluation signal here is communication. Hays frames the test as whether you can make yourself understood when describing complex technical problems to others, including listeners who are not technical. Choose a story where the technical detail can be explained plainly, and keep the Action step focused on what you did.
The limit is that STAR is a structure for stories, not for coding or design problems. Using it on an algorithm question would hide the reasoning the interviewer wants to see.
Product and role-specific questions
Product questions suit candidates who have done their homework. Morehouse describes a prompt that asks you to explain what you like or dislike about a product and why you feel that way. A reason makes the opinion useful, so name a specific feature or behaviour rather than a general impression.
Because the questions differ by role, Morehouse separates what a software engineer is asked from what other roles face. The wider preparation routine is covered in how to prepare for a tech interview.
When the solution is not obvious
Not knowing the solution straight away is a normal state, and the right response is to keep reasoning aloud. The interview is measuring how you approach a problem, so an honest sequence of ideas is more useful to the interviewer than silence.
- Say what the problem is asking and what you do know.
- Propose the simplest approach you can think of, even if it looks inefficient.
- Explain what is wrong with it and what you would change.
- Choose a direction and give the reason for the choice.
This sequence is judgement built on Morehouse’s advice to talk the interviewer through your thought process. How much to say aloud follows from that advice: enough that the interviewer can follow each decision and the reason behind it, without narrating every keystroke.
Recovering from a mistake mid-answer
A mistake in the middle of an answer is recoverable when it is handled in the open. Hays says it does not matter if you are not entirely correct, because the interviewer is watching the thought process.
Stop, say what you noticed and fix it. Correcting a flaw while explaining the reason shows the same reasoning skill the interview is designed to measure. Concealing the error or restarting silently removes the evidence the interviewer needs. If a fix would take too long, state the limitation and describe what you would do with more time.
Decision checklist before each answer
- Identify the question type: structure, coding, scenario, behavioral or product.
- Choose the matching answer shape from the table above.
- Decide which choice you will justify aloud and the alternative you will compare it with.
- Begin talking before you begin writing.
- Correct errors openly and keep going.
Frequently asked questions
How can I tell which topics to expect?
Study the job description again before the interview. Hays says you can often identify the topic areas from it.
Are technical interviews only for software roles?
No. They are most common in tech, engineering and computer science fields, but the questions differ by role, according to Morehouse College career development.
Is a memorised answer enough?
It is a starting point rather than the goal. An interviewer writing on allenc.com describes the discussion as more interesting when a candidate goes beyond the textbook answer.
Which book is cited for coding interview practice?
The same allenc.com article cites Cracking the Coding Interview as a preparation resource.
