What to Do When You Don’t Know the Answer

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?

girl questioningIf 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.

Comments

  1. BY Ed says:

    I interviewed a kid from MIT at JPL once. I asked “what’s the complexity of a binary search tree?” He was a math guy (BS mathematics), so this was an important question as I was watching to see of he’d handle some of the classic software concepts.

    He said he didn’t know… Then he said, well, if elements go to one side or the other on insert, the tree is log(n) deep. At the leafs, you have to count them all, so its n(log(n)!

    He got a thumbs-up from me.

    • BY Mountains says:

      There’s NO such thing as “complexity of binary search tree”. There’s complexity of CERTAIN OPERATIONS on BST, such as “search”, “insert”, “delete”, “list in order of levels”, “breadth first traversal”, “inorder traversal”, “rebalancing”, etc; there is also space complexity of the data structure (O(n))–though space complexity applies to process/algorithm, really. So, your question was invalid to begin with.

  2. BY Patrick Keys says:

    The missing magic words in this post are “out loud”. As in “Think it through… out loud.” If you think out loud, the interviewer gets to at least understand how you think. And that tends to be as important as being able to reach the right answer.

  3. BY Chris says:

    When I interviewed myself to head my company, I asked myself many hard questions to which I didn’t know the answer. However, I was impressed by my ability to do research and use trial and error methods to eventually find the answers and ultimately I got the position.

  4. BY roadrider says:

    And when real-time problem solving in front of one or more inquisitioners (as opposed to researching a problem and working through potential solutions without an impossibly short time limit) becomes an essential part of the job of software development your post will be relevant.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>