Honesty + structured thinking beats bluffing.
On the job
1. Say what you *do* know 2. State assumptions 3. Search docs / logs / code 4. Ask a targeted question to the right owner 5. Time-box investigation and update stakeholders
In the interview
1. Clarify the question 2. Think aloud with a framework 3. Admit gaps explicitly: "I haven't used Flink in production; here's how I'd approach it from streaming fundamentals…" 4. Ask a clarifying question if stuck
Example outline
> If I don't know a Spark config, I won't invent one. I'll reason about shuffle vs compute, propose how I'd measure, and say what I'd look up. Then I'll connect it to something I *have* done, like fixing a skewed join in a project.
Fresher tip
Interviewers expect gaps. Coachability is the signal.
Interview tip: Never fabricate experience with a tool.