What to Say in a Technical Interview When You Don’t Know the Answer

What to Say in a Technical Interview When You Don’t Know the Answer

Brand Vantage Academy | Talent Development & Workforce Solutions

Twenty minutes into a technical round, the questions have been comfortable. Then the interviewer asks something about how a database behaves when two transactions touch the same row at the same moment, and the candidate has never encountered it.

Three seconds pass. The candidate says, “Sorry sir, I haven’t studied that.”

The interview continues, politely, but the panel has recorded something — and it is not that the candidate lacked knowledge of concurrency control.

Here is the mechanism most students never see. A competent technical interviewer is not attempting to find the edge of your syllabus. They are deliberately pushing until you reach the edge of what you know, because everything before that point tells them very little. Every candidate can answer the easy questions. The information the panel needs is in what happens afterwards.

Reaching a question you cannot answer is not a failure of preparation. It is the interview arriving at its actual subject.

The Panel Is Measuring Reasoning, Not Recall

If an interviewer wanted to test recall, an online test would do it faster, cheaper and more consistently. The live round exists because there are things a written assessment cannot observe.

What a panel is trying to establish is whether you can approach an unfamiliar problem in a structured way, whether you know the boundary of your own knowledge, whether you say something confident and false when uncertain, and whether you are someone a senior engineer would be willing to hand an ambiguous task to.

A fresher will encounter unfamiliar problems constantly in the first year of employment. The interview is a fifteen-minute sample of how that will go.

Every candidate can answer the questions they prepared for. The interview only becomes informative at the point where preparation runs out.

This reframes the two default responses. Freezing communicates that you stop when the map ends. Bluffing communicates something far more expensive — that your confident statements cannot be trusted, which in a production environment is a real cost.

The Failure Mode Is Bluffing, and Panels Detect It Immediately

Students bluff because they believe admitting ignorance ends the interview. In practice, bluffing ends it faster.

Bluffing is easy to detect, because an interviewer who asked the question already knows the shape of a correct answer. Vagueness, borrowed terminology used slightly wrongly, and confident generalities in place of a mechanism are all visible from the first sentence. What follows is usually a follow-up question specifically designed to test the claim, and the candidate is now defending a position they never held.

The related error is over-claiming on the resume. Anything listed under skills is legitimate interview material, and a panel that finds a listed technology cannot be discussed for two minutes will reasonably discount everything else on the page.

There is a version of honesty that costs nothing and a version that costs everything. “I don’t know” as a full stop is the expensive one. “I don’t know that specific mechanism — let me reason about what it would have to do” is the other.

The Think-Aloud Protocol

The single most useful behaviour in a technical round is externalising your reasoning. If you think silently, the panel sees only the output, and if the output is wrong they have no way to award credit for the process.

A workable sequence when a question exceeds your knowledge runs in five steps.

Restate the question in your own words. This confirms you understood it and, frequently, the interviewer corrects a misunderstanding you did not know you had.

Scope it. Ask what the question is actually asking about. “Do you mean at the application layer or the database layer?” is not a stalling tactic; it is what a working engineer does before starting.

State your assumptions explicitly. “I’ll assume the reads and writes are on the same table and there’s no caching in between.” Assumptions convert an unanswerable question into an answerable one, and naming them shows the panel you know where the uncertainty is.

Reason from adjacent knowledge. You almost certainly know something nearby. If you have never studied database locking but you understand why two threads writing to the same variable produce a race condition, say so and build from there. Analogical reasoning from a principle you do hold is a strong signal.

Name what you would do to close the gap. “I’d want to read the documentation on isolation levels before I said anything definite about how it behaves under load.” This is exactly what the interviewer would do.

The Exact Language That Works

Students often understand this advice in principle and still cannot produce a sentence under pressure. Rehearsed phrasing solves that.

• “I haven’t worked with that directly. Can I reason through what I think it would have to do, and you can tell me where I’m off?”
• “I know the related concept rather than that one. Would it help if I explained how I understand the adjacent case?”
• “Let me make sure I have the question right before I answer.”
• “I want to state an assumption, because my answer changes depending on it.”
• “I’m not confident about that. I don’t want to guess and give you something wrong.”
• “That’s the part I’d need to look up. What I do know is the layer underneath it.”

Each of these does the same two things: it keeps the conversation open, and it separates what you know from what you are inferring. That separation is the professional habit the panel is looking for.

Note the last one. Volunteering the boundary of your confidence — rather than being caught at it — is read as calibration, and calibration is a senior trait appearing early.

The Recovery Nobody Uses

If you realise mid-answer that you have said something wrong, correct it in the room. “I said that backwards a minute ago — the index speeds up reads, not writes, and it actually slows writes down.”

Candidates almost never do this, believing the panel did not notice. The panel noticed. A self-correction converts an error into a demonstration of self-monitoring, which is the more valuable of the two.

The same applies after the interview. If you leave and immediately work out the answer, a short follow-up email that says so is entirely appropriate at fresher level and is remembered.

Preparing to Be Wrong Productively

This is a rehearsable skill, and the rehearsal is unusual: practise being asked things you cannot answer.

Work with a peer who selects questions deliberately outside your syllabus. The objective is not to answer them. It is to speak continuously and coherently for ninety seconds about a problem you have never seen, ending with a stated assumption and a named gap. Do it until the silence stops being uncomfortable.

Alongside that, build genuine depth in a narrow area rather than shallow familiarity across many. A candidate who can go four layers deep on one project they built is far more convincing than one who has surface exposure to eight technologies, because depth is what allows adjacent reasoning to work at all.

And prune the resume to what you can defend. Every line you remove is a question you will not have to survive.

The interviewer is not deciding whether you already know how to do the job. They are deciding whether you will be honest with them on the day you do not.

Key Takeaways

• Assume the panel will push past your knowledge deliberately; reaching that point is the interview working as designed, not a preparation failure.
• Never bluff — a confident wrong answer costs more than an admitted gap, because it makes your other answers unreliable.
• Restate, scope, state assumptions, reason from adjacent knowledge, then name what you would look up.
• Keep two or three rehearsed sentences ready so you can respond to an unknown question without freezing.
• Correct your own errors mid-answer; self-correction is read as calibration rather than as a mistake.

Placement Connection

The technical round is where a shortlisted candidate is either converted or lost, and it is the stage least improved by memorising question banks. Because panels probe to the edge of a candidate’s knowledge by design, the behavior at that edge — structured reasoning, stated assumptions, honest boundaries — is often what separates two candidates with identical academic records and identical projects.

Brand Vantage Academy

Practical, hands-on training at Brand Vantage Academy prepares candidates for live technical evaluation, including structured reasoning practice and placement assistance. See how the programs are built at brandvantageacademy.com.

Suggested Internal Links

Anchor Text	Destination	Relevance
what sits on the interviewer’s scorecard	Blog 50 — What Is Actually Written on the Interviewer’s Scorecard	The rubric behind the behaviors described here
clearing the automated coding round	Blog 32 — What Online Coding Assessments Actually Test — And Why Good Coders Still Fail Them	The technical filter that precedes this interview
defending a project in detail	Blog 27 — Capstone Projects: Turning a College Assignment into Interview Evidence	Building the depth that adjacent reasoning depends on
why strong technical candidates get rejected	Blog 12 — Communication Skills: Why Technically Strong Candidates Get Rejected	The wider communication failure this article addresses one case of
Placement Readiness Programs	Academy page — Placement Readiness Programs	Structured interview preparation and evaluation practice

---