I talked before about why it’s good to tell your interviewer when you already know the solution to a problem. But what happens when you don’t know the answer? What do you do then? If it’s an algorithm question, not knowing the solution is the normal case. You’re not supposed to know the answer! Your interviewer is asking you these questions to test how good you are at problem solving. It wouldn’t be a very good test of problem-solving skills if you didn’t actually have to solve the problem, now would it? What happens if it’s a factual question, though, such as “Can you execute two finally blocks in the same method?” Questions like these are largely tests of knowledge. Of course, they are still tests of knowledge designed as “samples” to see how comfortable you are with that language or technology as a whole. In an ideal world, you know the answer to all the factual (aka “trivia”) questions and can just spit them out. In the real world, though, you’ll probably come across a few that you don’t know. But don’t surrender yet! All is not lost. In many cases, you might be able to “derive” the answer.

• Don’t know if you can execute two finally blocks in one method? Think it through. What would it mean if you could do that? What sorts of problems might it solve? What sorts of problems might it create? What would you, as the language designer, do?
• Don’t know if method X or method Y in some API is faster or better to use? Think it through. What does each method have to do? In what cases might one run into issues?
• Don’t know what defining a static variable within a method would do? Think it through. What does static as a class member variable do? What might it do inside a method? What are the implications of that? Why would you, as a language designer, allow this?

Attempting to derive an answer might actually lead you to the right answer. But even if it doesn’t, you’ll hopefully demonstrate knowledge and understanding of the technology in question, and ultimately that’s what this whole process is all about.