At that point in the interview I stand up, shake your hand, and say, "thanks for revealing yourself to be a smart aleck before I made the mistake of working here."
LOL, that's one of about 30 questions I ask, nearly all of the rest of which which are straightforward. And to say it is the "incorrect" answer is a bit strong. The "incorrect" answer, I suppose, would be to say, "Quicksort? What's that?" (Don't laugh; it's happened.) Every question I ask has a series of followups, because the purpose of an interview -- in my mind -- is to determine the limit of the candidate's knowledge and experience, wherever it lies. If it happens to lie beyond my own knowledge, the so much the better. But if not, then I locate it so that I know where it lies. And I state this at the very beginning of the interview, adding that "I don't know" is a noble answer to any question. I also make it clear that I'm looking for "outside the box" thinking on many of the questions.
If someone writes Quicksort on the board, he'd better get it right. My followup in that case is, "Are you sure that's a correct implementation?" or "How would you go about ensuring that's a correct implementation?" whether the implementation is correct or not. This often leads the candidate into considering the answers I think are more appropriate.
But if you had left the interview on that basis, that's a perfectly reasonable action. The interview is bidirectional. If you don't like me as a boss, then an employment relationship is ill-advised in any case.
Life is too short for me to play mind games with an interviewer. If you don't like my choice of books, that's your problem. Not mine.
Nor mine, although I occasionally ask, "What is the airspeed velocity of an unladen swallow?" at some point in the interview. That's more intended to put a nervous candidate at ease.
But if you honestly think that when my job calls for me to sort an array, I'm going to be dumb enough to write the function myself instead of using a standard library, you're insulting me.
The question is intended to discover how a candidate solves a problem, not to discern whether the candidate knows Quicksort. If it takes several followup questions or a conversation to make the intent of the question clearer, then I'm happy to oblige.
"Is the standard C library available?"
"Yes."
"May I use it?"
"Yes."
Part of being a good engineer is knowing what questions to ask and when to ask them.
"Are you asking me to write the Quicksort algorithm?"
"I'm asking you to use the Quicksort algorithm; if you can figure out how to use it without writing it, that's preferable."
If I carefully word a question in order to present the candidate with a specific problem, I have no problem with the candidate trying to "defuse" the wording and get right to the issue. The ability to see through intentional ambiguity translates to the ability to see through accidental ambiguity.
If someone writes the "correct" answer, I'll often say, "That was the answer I expected. How would you solve the problem on an embedded system where the standard C library may not be fully there?"
If you then berate me for showing it to you, well like I said, I'm just glad that I won't be working for you.
Berating is never part of any job interview I conduct.
And besides, there are plenty of people out there who would ask the same question you did in an interview, but say the wrong answer (for an interview) is calling the library function.
You're right; and those people have no business hiring or managing good computer programmers. And good computer programmers won't work for such people for long. If you were interviewing me and disallowed my call to the library function, I would say, "I would consult Knuth or a similar reference to make sure I got the algorithm right." If that answer were disallowed, I would say, "Okay, I'll write Quicksort in C for you, but I make no representations about its correctness. I don't program key algorithms from memory, nor do I consider memorization of algorithm implementations a good guage of a programmer's skill."
Now I would expect any candidate to describe Quicksort and give its strengths and weaknesses. And so my next question would probably be, "When might it be inappropriate to use Quicksort?"
They'll justify it as, "when I give you a specification, I want you fill, I don't want you work around. And the specification I gave you called for *you* to write the function." Whatever.
Yes, whatever. And, like you, I would shun working for such people. As an engineer it's my job to make sure I understand the problem before, during, and after the solution. And that means presuming that no problem is fully specified at the outset -- either in a job or in a job interview. If the interviewer does not offer further specification, then I feel he has no right to restrict my answer post facto.
"Is the standard C library available?"
"Unknown."
"Then I'll call the qsort() function in the standard C library."
"You can't do that."
"Why not?"
"Because I asked you to implement the function."
"Is there any reason why I shouldn't copy it from a standard reference?"
"Well, for the sake of the interview. We want to see whether you know how to implement the algorithm."
Then at least the actual intent of the question is out in the open. If it seems appropriate we can discuss whether the basis of the question constitutes good engineering, but not ever interviewer wants to know that.
Like I said, life it too short to play mind games in an interview.
Agreed, but there is a difference between mind games and discovering how a candidate approaches problems.
I never say, "Bzzt. Wrong answer." If I hear an answer I don't like, I guide the candidate toward the correct answer. In that case, the exercise is in seeing how much conversation is required to get the candidate on the same page as me.
"Can you deliver me a piece of software by Friday?"
"No."
"Why not?"
"Because you didn't tell me what kind of software you wanted."
"That's absolutely right; and that means I can't argue you didn't satisfy the requirements. So if you wrote 'hello world' and gave it to me Friday, you'd have done what I asked for."
"Yes, I suppose so."
"So if I give you no other constraint right now than have it to me by Friday, could you tell me right now that you could do it?"
"Yes."
The follows a conversation about constraints.
"Can you deliver me a piece of software by Friday?"
"I'm not sure; what kind of software is it?"
"I don't know."
"Then I'm not sure I can."
"Why not?"
"Because I'm not sure what needs to be done by then."
"But you're sure it would have to be done by Friday, aren't you?"
"Yes, I suppose so."
"So any other requirements that might be given to you later, such as a feature set or reliability, would have to be balanced against that initial constraint?"
"Sure, I suppose so."
"Then the answer is 'yes'. So if I came to you Thursday and said the software I wanted was a POSIX-compliant operating system with no major bugs, by Friday..."
"No, I can't do that."
"But if I asked for 'hello world'..."
"I could do that by Friday."
Then the conversation about constraints.
or, "The correct answer is 'yes'. I didn't give you any other constraints but the deadline."
"Hey, that's kind of a trick question!"
"Yes, sorry, but it's to bring up a topic I want your opinion on. You realized that the problem I gave you was underconstrained, right?"
"Yes, I suppose so."
"And did you suspect that the software I was asking for probably had some other requirements like a feature set, even though I didn't tell you?"
"Sure."
"But that wasn't part of the problem I gave you, and that made you a bit uncertain."
"Yes."
"That's typical of most of the problems we'll ask you to solve. We know some of the constraints ahead of time, but we don't know all of them before we give you the problem. And so every time we discover something knew about the problem, we have to fit that into what we already know. And we need to revise estimates at every stage to see whether or not we're going to make it -- if I change the problem, you can change your answer: it's that simple. Deadlines are part of those constraints. Features are constraints. Allowed defects are part of the constraints. Does this mode of problem-solving make sense to you?"
So do you still not want to work for me?
|