Thread: Tricky C question asked in an interiew - display name?

That is the point of such questions, Soma.

O_o

Applying what you do know to areas you do not understand has nothing to do with resolving a "trick question".

I've never been in a situation as a programmer where resolving a "trick question" has been useful. Neither have you.

Being capable of independent research is useful. Being capable of asking for and processing requirements is useful. This question can not gauge such abilities. It only gauges the ability to recognize a "trick question". Sure, if the candidate recognizes a "trick question" they may also have the capacity to give one of innumerable "correct" answers, but if they don't recognize a "trick question" you've not learned "how they approach a new problem that is outside their experience" or "how they handle deficient or ambiguous requirements". You've learned exactly one thing: they suck with "trick questions".

[Edit]
Actually, you can prove this to yourself based on your own experience as an interviewer if you really have done a lot of interviewing.

How many times have you asked "trick questions" of any sort where upon receiving the answer you immediately had to ask leading/related questions to understand why a given answer was offered?

Let's look back at this question; the answer "I'd use a different library interface." doesn't tell you anything about my abilities because if you understand the nature of the "trick" that answer is obvious. (Look at what Salem said.) You must, to judge anything, follow up with "Why would you use a different library interface?". Unfortunately, the answer "Because you told me I could not use that one." is perfectly valid. You've put yourself into a position where you have to ask more and more leading/related questions in order to get the interviewer to a point where you can probe his abilities because so far you've learned nothing of value.

Why waste time with "trick questions" which don't tell you anything when you can just start with questions that actually gauge an individuals understanding of development? Why start with "How to display name on screen with a C program without using standard IO routines?" when you can start with "Here is the documentation for a system level IO API; write me a copy of `puts'."?
[/Edit]

This is exactly like "How do you get an elephant in a refrigerator?" question. It doesn't judge readiness; it doesn't judge "thinking outside the box". It judges the candidates familiarity with "trick questions". "Well, I'd cut the elephant into small pieces." perfectly answers the question. "I'd just drive the elephant into a very large refrigerator." perfectly answers the question. Neither of these answers gives you, as an interviewer, insight into my abilities as a programmer.

Give a candidate a list of requirements and ask for a criticism of the document; such an approach bypasses this "trick question" crap which means that it actually has a reasonable chance to gauge the development abilities of a candidate.

[Edit]

Would you want a candidate who would not bother to question or clarify these requirements?

I forgot to answer this; I'd want Subsonics. His answer doesn't seem to satisfy you because you think this question gauges readiness through the ability to recognize a lack of specificity and gather requirements. (It doesn't; it is a bad "trick question" with infinitely many interpretations and valid answers.) I think his answer is perfect; it solves the requirements as stated with very little effort and shows a level of familiarity with the C standard library.

But the selection of candidate here is meaningless. I wouldn't ask this question.
[/Edit]

I've had requirements come to me that were vaguer than that interview question.

And exactly how this is a bad interview question, those are bad requirements.

Soma