You are asked about something you have never used — a serving stack, a library, a scaling pattern — and a plausible answer arrives in your mouth before you have decided to give it. The interviewer asks one specific follow-up: which part would you cache, what expiry, what breaks first. Your second answer is vaguer than your first, and your third is "I suppose it could be". The interview changes temperature. Questions you could have answered well are never asked, and the feedback afterwards says something like "answers were not reliable" or "could not tell what he had actually done".
Theory and system-design rounds, usually in the last third when the interviewer starts probing beyond the resume. Most common on deployment, scaling, cloud and tooling questions, because those have familiar-sounding vocabulary that is easy to assemble from blog posts and videos. It also bites on questions about libraries a student has read about but never imported. The bluff is rarely deliberate — it is a reflex, produced by the belief that "I do not know" is a zero. Linked module: 6.4 (ML theory viva bank).
A bluff is not a knowledge failure. It is a judgement failure, and judgement is what the round is scoring.
Interviewers probe for depth on every topic, not only the ones they suspect. So the probe that exposes the bluff was going to be asked anyway. When it lands, the interviewer learns two things at once: you do not know this, and you were willing to sound as if you did. The first fact is cheap — freshers are not expected to have served models at scale. The second is expensive, because it puts every earlier answer back on the table. If this one was assembled, which others were?
That is why the round often gets shorter rather than harder after a bluff. The interviewer has stopped gathering evidence and started confirming a decision.
The mechanics are always the same. A bluff is built from vocabulary rather than from experience, so it holds at the level of nouns and fails at the level of specifics. "Cache the predictions in Redis" is a sentence anyone can produce. "Cache the features, not the predictions, with a five-minute expiry, because a stale prediction on a store that churned yesterday is worse than a slow one" is a sentence only somebody who has thought about it can produce. One follow-up separates them, and interviewers know exactly which follow-up to use.
There is a related trap on the other side: silence. "I do not know", said alone and then followed by nothing, is honest and scores almost nothing. The professional answer has two halves, and most students only ever practise the first.
Use the two-half protocol, and use it in the first sentence rather than after a pause.
Half one — say it, cleanly. "I have not served a model at that scale, so let me tell you what I do know and where my line is." No stalling, no fog, no "well, it depends". Saying it early costs you nothing and buys you the interviewer's attention for half two.
Half two — say how you would find out. This is the half that earns the marks, and it has three named parts:
Then reason from the ground you do hold. Before you stop, walk from what you have done to what you have not. "I have served this model with FastAPI on one machine and measured it, so I know the model answers in single-digit milliseconds. At 2,000 stores I would expect the load and the feature lookup to dominate, not the model." That sentence is worth more than a correct guess, because it shows the interviewer how you think when the answer is missing.
If you have already bluffed, retract it immediately. "Let me correct something I said a minute ago — I have not actually used that, I was reasoning from what I have read." Retracting inside the same round recovers most of the lost trust. Retracting after a follow-up has already exposed you recovers very little, so do it the moment you notice.
Keep an explicit list of what you have run, what you have read about, and what you have never touched, and rehearse saying which is which out loud. Practise the two-half protocol as a drill, not as a fallback: in every pair viva, one question should be one you genuinely cannot answer, so the words come out smoothly under pressure. Never let vocabulary you cannot unpack into specifics enter your resume or your answers — if you cannot name the expiry, do not name the cache. When an answer starts assembling itself from things you have read, notice the feeling and stop; that feeling is the reflex, and naming it is enough to interrupt it. Remember the arithmetic: not knowing one thing costs you one question, and bluffing once costs you every question you already answered.
Q: "How would you scale this to two thousand stores with a 200-millisecond budget?" Strong answer: state the scope of your experience in the first sentence, give the measured facts you do own, reason out where the bottleneck would move, and close with a named tool, a named document and a named person you would go to. Weak answer: a fluent list of technologies. Interviewers describe the strong version as "honest about scope, reasoned to the edge of it" — and that phrasing is a recommendation, not a criticism.