Handling Unknown Questions
Fast recall
Quick revision
Core answer
Whether you say 'I don't know, but here's how I'd find out' and reason from what you do know (honesty + process).
Freezing, or guessing confidently and wrong — both worse than an honest 'I'd look it up'.
Say 'I'm not certain, but here's how I'd find out'; reason from what you know. Interviewers test honesty + process, not memorization.
Interview-ready guide
Interview answer
I have not used that specific Rails cache store, so I do not want to invent its eviction behaviour. I understand the surrounding role: a cache keeps a reusable result behind a key, and correctness depends on expiry and invalidation when the source data changes.
Could I clarify whether the question is about how Rails chooses the store, or what happens when several processes update the same cached value? Those are different boundaries, and I can reason more accurately once the failure being discussed is clear.
For example, if the concern is stale product data, I would trace where the key is written, which updates should invalidate it, and what a miss does. I would not assume an in-memory store behaves like Redis across multiple application processes.
My current hypothesis would be that the application can tolerate a miss but must define how much staleness is acceptable. I would confirm the store's atomic operations and expiration semantics in the Rails adapter documentation, then reproduce the update and read with two processes or a focused integration test.
So I cannot give the store-specific guarantee yet, but I can identify the relevant contract, the unsafe assumption, and the evidence needed to answer it. If the exact recall is required, I would rather state that gap than present a guess as production behaviour.
Handling Unknown Questions
Direct Answer
When you do not know an interview answer, state the limit honestly, clarify the term or scenario, connect it to knowledge you do have, and separate facts from assumptions. If useful, reason through a small example and explain exactly how you would verify the uncertain part with documentation, a focused experiment, logs, or a test. Do not bluff or fill space with unrelated facts. A partial but traceable answer is more useful than confident misinformation.
Deep Dive & Architecture
Not knowing can mean several things: an unfamiliar name, a forgotten API detail, no production experience with a tool, or a concept that is entirely new. Naming the boundary prevents a narrow recall gap from sounding like total confusion and prevents broad familiarity from being presented as specific experience.
Clarification discovers the contract under discussion. A question about a queue may concern delivery guarantee, ordering, retry, throughput, or application use. Answering the wrong dimension at length creates more risk than asking one precise question.
Reasoning is valuable only when assumptions stay visible. A nearby concept can supply a starting model, but product-specific behaviour must not be inferred as fact. Drawing one input, transition, and expected output often reveals exactly where documentation or an experiment is needed.
Verification should be executable. “I would research it” is vague; reading the official adapter contract, writing a two-process reproduction, checking an execution plan, or capturing a failing request identifies evidence and a stopping condition. This method is also how engineers handle unknowns after the interview.
Common Mistakes & Pitfalls
Freezing, or guessing confidently and wrong — both worse than an honest 'I'd look it up'.
Check your understanding
Answer these without looking back at the article.
- How do you distinguish a forgotten detail from an unknown concept?
- What makes a verification step concrete rather than vague?
- When should you stop reasoning and state that you need documentation?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.