3 ms·

This type of information about the candidate can be gotten in a much more evenhanded way by rephrasing the question: What's the trickiest bug you've ever had to

This type of information about the candidate can be gotten in a much more evenhanded way by rephrasing the question: What's the trickiest bug you've ever had to fix, and why? Follow up as appropriate with specific questions about the actual bug they solved.

dcow 9y ago
I generally agree you shouldn't ask pass/fail "trick" questions, but in most domains there are some questions that can tell you a lot more about someone than it might seem to an outside observer. For example, in an android domain interview, I've asked people to make a view blink onscreen. It's totally fine if they roll an implementation on the spot (and it's an easy question anyone can handle), but someone seasoned with the framework or who's read a lot of framework sources might know there's an undocumented feature of LayoutInflator that builds blink layouts if it encounters a <blink> tag while parsing layout xml. At least to me, that extra info is valuable. I'm sure there are analogs in for example C++ about quirks of the language that change with and without RTTI or exceptions etc that would tell you a lot about how much real experience someone has working with a given tool.
Stratoscope 9y ago
I'm not very fond of questions in the form "What's the (trickiest|best|worst) (bug|problem|code|thing) you've ever (fixed|written|seen)?" Other examples are the classic "What's your greatest strength?" and "What's your greatest weakness?" These are all recipes for brain freeze. If you ask me a question like that I'll probably think of something, but then I'll ask myself, "But was that really the best/worst/trickiest? Maybe there was another bug that was even trickier, or another strength/weakness of mine that's greater/worse than the one that just came to mind." You can avoid that somewhat by leaving out the request to name the most extreme case: "Can you tell me about an interesting bug you fixed?" Then I could just pick one and start talking about it. Perhaps even better, ask about an embarrassing bug. Those may be the easiest to remember. Maybe it would be that election results map that started turning states red when CNN was turning them blue? And how the bug snuck in even with three people reviewing the code change? And we could talk about what went wrong and how code reviews don't guarantee correct code. All kinds of possibilities for interesting discussion there.

dcow 9y ago

I generally agree you shouldn't ask pass/fail "trick" questions, but in most domains there are some questions that can tell you a lot more about someone than it might seem to an outside observer. For example, in an android domain interview, I've asked people to make a view blink onscreen. It's totally fine if they roll an implementation on the spot (and it's an easy question anyone can handle), but someone seasoned with the framework or who's read a lot of framework sources might know there's an undocumented feature of LayoutInflator that builds blink layouts if it encounters a <blink> tag while parsing layout xml. At least to me, that extra info is valuable. I'm sure there are analogs in for example C++ about quirks of the language that change with and without RTTI or exceptions etc that would tell you a lot about how much real experience someone has working with a given tool.

Stratoscope 9y ago

I'm not very fond of questions in the form "What's the (trickiest|best|worst) (bug|problem|code|thing) you've ever (fixed|written|seen)?" Other examples are the classic "What's your greatest strength?" and "What's your greatest weakness?" These are all recipes for brain freeze. If you ask me a question like that I'll probably think of something, but then I'll ask myself, "But was that really the best/worst/trickiest? Maybe there was another bug that was even trickier, or another strength/weakness of mine that's greater/worse than the one that just came to mind." You can avoid that somewhat by leaving out the request to name the most extreme case: "Can you tell me about an interesting bug you fixed?" Then I could just pick one and start talking about it. Perhaps even better, ask about an embarrassing bug. Those may be the easiest to remember. Maybe it would be that election results map that started turning states red when CNN was turning them blue? And how the bug snuck in even with three people reviewing the code change? And we could talk about what went wrong and how code reviews don't guarantee correct code. All kinds of possibilities for interesting discussion there.