C# Potential Interview Question…Too hard? [closed]

Answer 1

Another vote against using it, but for a different reason.

When put on the spot like this, a lot of really good programmers would come up with the wrong answer, but not because they don't know the concepts or couldn't figure it out. What happens is that they'll see something like this and think, "Aha, trick question!", and then proceed to out-think themselves in the response. This is especially true in an interview setting where they don't have the benefit of the IDE or Google or any other of the other helps a programmer takes for granted in their day to day programming.

Answer 2

Too hard? No, but what is your goal in the question? What are you expecting to get from your interviewee? That they know this particular syntactic quirk? That either means that they've studied the spec/language well (good for them) or that they've run into this problem (hopefully not from what they wrote, but if they did - yikes). Neither case really indicates that you've got a solid programmer/engineer/architect on your hand. I believe that what's important is not the question but the discussion surrounding the question.

When I interview candidates, I usually ask one deceptively simple question which is based on a language semantic quirk - but I don't care if my interviewee knows it because that semantic quirk allows me to open up a lot of avenues that allow me to find out if my candidate is methodical, their communication style, if they're willing to say "I don't know", are they capable of thinking on their feet, do they understand language design and machine architecture, do they understand platform and portability issues - in short, I'm looking for a lot of ingredients that all add up to "do they get it?". This process takes an hour or more.

In the end, I don't actually care about whether they know the answer to my question - the question is a ruse to let me get all the rest of that information indirectly without ever having to ask. If you don't have a valuable ulterior in this question, don't bother even asking it - you're wasting your time and your candidate's time.

Answer 3

This smacks of a trick question to me. If you've been using the language for long enough, you've probably run into the problem and know the answer; but how long is long enough?

It's also a question where your background might work against you. I know in C++ the definition in B would hide the definition in A, but I have no idea if it works the same in C#. In real life, I'd know it was a questionable area and try to look it up. In an interview I might try to guess, having been put on the spot. And I'd probably get it wrong.

Answer 4

Not really fair as an interview question, as it's a bit of a trick question. The good answer I'd want from an interviewee would be more along the lines of "That needs refactoring".

Unless you're looking to hire someone to work on compilers I'm not sure that you need to go that much in depth into the CLR.

For interview questions I look for things that show the coder's level of understanding in their answer. This is more of an oddity/puzzle.

Answer 5

use it as a question only as long as you expect the candidate to tell you his thought processes as he describes what he thinks should be happening. Who cares about the right and wrongness of actual code in question - in the real world, the candidate would find code like this, find it not working and debug it with a combination of debugger and writeline calls, so its a useless question if you want candidates who know (or guess) the right answer.

But those who can explain what they think would happen, that's a different matter. Hire them even if they get it wrong.

Answer 6

That's a ridiculous question to ask - I could answer it in < 60 seconds with Snippet Compiler, and if I ever worked in a code base that depended on the functionality - it'd be quickly refactored out of existence.

The best answer is "that's a stupid design, don't do that and you won't have to parse the language spec to know what it's going to do".

If I was the interviewee, I'd think very highly of your geek trivia cred, and would perhaps invite you to the next game of Geek Trivial Pursuit. But, I'm not so sure I'd want to work with/for you. If that's your goal, by all means ask away.

• Note that in an informal situation, geek trivia like this can be fun and entertaining. But, to an interviewee, an interview is anything but fun or informal - why further agitate it with trivial questions that the interviewee doesn't know if you take seriously or not?