What do you do when you're asked a technical question you don't know the answer to?
Fast recall
Quick revision
Core answer
Your honesty, intellectual humility, and ability to reason through unfamiliar problems under pressure
Freshers often panic and either freeze completely or attempt to bluff their way through with generic buzzwords
Verbalize your thought process out loud as you reason through the problem, showing structured thinking even when you don't know the answer
Interview-ready guide
Interview answer
When I don't know the answer to a technical question, I'm honest about it right away.
I'll say something like, I haven't worked with that directly, but let me think through it based on what I do know. Then I connect it to related concepts.
For example, if asked about Redis and I've only used HashMap for caching, I'd explain that caching generally involves key-value lookups with fast access times, and reason that Redis probably extends those principles to distributed systems. I verbalize my thinking process out loud so the interviewer can follow my reasoning. Even if I don't reach the perfect answer, it shows I can work through unfamiliar problems logically.
The key mistake I've seen other freshers make is bluffing with buzzwords. They'll claim to know something, then stumble when asked follow-up questions. Interviewers detect this immediately, and it kills trust.
It's way better to admit you're learning and demonstrate curiosity. I might finish by saying, This is new to me, but I'm genuinely interested — what resources would you recommend to learn more? That shows I'm coachable and eager to fill gaps in my knowledge, which is what junior developers do every day.
What do you do when you're asked a technical question you don't know the answer to
Direct Answer
Be honest that you're not sure, then demonstrate reasoning: connect to related concepts you do know, think through the logic, and arrive at a reasonable answer. Don't bluff — experienced interviewers detect it immediately and it damages trust.
Code Example
// Interviewer asks: "How would you implement rate limiting in a REST API?"
// You haven't done this before, but you reason through it:
// "I haven't implemented rate limiting, but let me think through it...
// We need to track request counts per user over a time window.
// That sounds like a cache with expiration."
@RestController
public class OrderController {
private final Map<String, Integer> requestCounts = new ConcurrentHashMap<>();
@GetMapping("/orders")
public ResponseEntity<List<Order>> getOrders(@RequestHeader("User-Id") String userId) {
var count = requestCounts.getOrDefault(userId, 0);
if (count >= 100) { // 100 requests per window
return ResponseEntity.status(429).build(); // Too Many Requests
}
requestCounts.put(userId, count + 1);
// In production, we'd need a scheduled task to reset counts
return ResponseEntity.ok(fetchOrders());
}
}
// "This is a basic approach. Real systems would use Redis or a specialized library."
Common Mistakes & Pitfalls
- Bluffing with buzzwords: Freshers say "Yeah, I know microservices" then can't explain when asked to elaborate. Interviewers immediately spot this through follow-up questions. Just say you haven't used it in production but understand the core concept.
- Going completely silent: Some candidates freeze when they don't know something, creating awkward silence. Interviewers can't assess your thinking if you don't verbalize it. Always talk through your reasoning.
- Over-apologizing: Saying "Sorry, I don't know" five times wastes time and signals insecurity. State it once, then move into problem-solving mode.
- Guessing randomly: Throwing out unrelated concepts hoping something sticks ("Is it like... blockchain?") shows poor judgment. If you truly have no anchor point, say so and ask a clarifying question instead.
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.