Handling 'I Don't Know' and Curveball Questions

The idea, in one line

Never bluff. Instead, run three steps: be honest, bridge to what you do know, then show how you'd figure it out.

The three-step recovery

1. Be honest — "I haven't used gRPC directly."
2. Bridge — "but it's a way for services to call each other, and I've tested REST contracts, so I'd expect similar schema-checking concerns."
3. Show the path — "here's how I'd get up to speed: read the proto definitions, write a contract test, and check it against a staging stub."

This turns a blank into a little demo of how you reason and how you learn — and those are harder to teach than any single tool.

See it work

1. BE HONEST (no bluffing)
   "I haven't worked with ___ directly."

2. BRIDGE to something you know
   "But it's similar to ___, and I have done ___,
    so I'd expect ___ to be the key concern."

3. SHOW THE PATH
   "To get productive I'd ___ (read docs / write a
    small spike / pair with someone), and check it by ___."

Advanced — curveball estimates

Some questions have no single right answer: "how many test cases for a login page?" Don't blurt a number. Think out loud — group things into categories, then give a rough range. The reasoning is the real answer.

• Break it into buckets: valid inputs, invalid inputs, boundaries, security, and the user experience.
• Count roughly within each bucket.
• Then give a range, and say what would push it higher or lower.

Grounded in Indeed and Codecademy guidance on answering questions you don't know