Hacker News Reader

Comment by brndnmtthws | Hacker News Reader

Please don't ask trick questions in interviews. It's never a good idea.

Why? I'm curious because sometimes I use a "trick" question (trick in quotes because this really isn't a trick question either) to gauge someone's ability to think on their feet. A "trick" question being one I'm fairly certain there's no answer to floating around and which requires some thinking. The goal should never be a pass/fail did they know the trick question, but someone who can think on their feet and work through one is more appealing to me than someone who throws in the towel.

Disagree. If you're a web developer, knowing these subtleties could prevent major and time-consuming bugs. The best engineers I've worked with know a ridiculous amount of these kinds of "tricks"--that's a big part of what makes them the best.

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.

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.

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.

"The best engineers I've worked with know a ridiculous amount of these kinds of "tricks"--that's a big part of what makes them the best."

Nah, no way. I work with some great engineers and they do not do "tricks" in their code. You write clean code that works within known conventions and patterns, so that it has long term maintainability. If you need "tricks" like this, then you're probably neck deep is some trash code looking for hail-marys to save you from yourself by causing side effects that you desire in the short term.

Nobody should intentionally write code like that. But being able to quickly identify code that unintentionally causes strange behavior (and being able to avoid it) is hugely valuable.

Maybe your problem is you hired developers that write code with tricks and gotchas.

Read more carefully. I would never hire a developer who would write code like that. I would hire a developer who can quickly identify such subtle mistakes, and fix/avoid them because of that deep knowledge.

Others seem to misunderstand your point. Essentially you want someone with deep knowledge. To share an example... "Deep C" - by Olve Maudal [0]. It isn't about writing bad code - it's about understanding how the code will compile/run, how to avoid potential issues, and how to avoid similar issues that might occur that stem from that same understanding of how the code will compile/run.

[0] https://www.slideshare.net/olvemaudal/deep-c/9-What_will_hap...

Reply on news.ycombinator.com