Problems without safe answers are great. They are infinite fodder for discussion.
P.S. Let's assume, oh interviewer, that your answer to my question "what kind of numbers?" is "integers, for now".
sort(a,b,c) {
exchange(a,b) if a > b
exchange(b,c) if b > c
exchange(a,b) if a > b
return (a,b,c)
}
I think that's probably the stupidest thing that could possibly work, not counting:
<?php
$sorted = sort($unsorted);
Assuming it does work, of course. It may have a bug. Probably does, in fact.
Now you could ask me to find the bug and I'd write out some test cases in the margin. Or you could ask me what happens if a string gets in there, or how I'd generalize this algorithm to N numbers, or what kind of language I'm using with this exchange primitive in it (answer: my own highly arbitrary mental pseudocode!) or how I'd implement the exchange primitive, or how fast this algorithm will run on N numbers (not very; it looks to be O(N!), and that's not counting the fact that my exchange primitive is probably wicked slow).
Or, depending on the job, you might head in some other direction.
My point is there is no default correct answer to that type of problem. In physics there are default approaches based on ignoring wind resistance etc. However, in computing knowing which questions to ask is the real test and they don't teach you that in your first year.
EX1: You wrote code before asking for more details you fail.
EX2: Then again some people view asking questions as stalling.
Perhaps they are thinking about sorting a vector and want you to use the the language library of your choice or write something. Or perhaps they want a few lines of ASM that include at most 2 swaps and:
x = x xor y
y = x xor y
x = x xor y
But if it's a high level ASM then you may have XCHG etc.
EX1: You wrote code before asking for more details you fail.
EX2: Then again some people view asking questions as stalling.
This is interviewing, not a mathematics competition or a judicial proceeding. It's not a test, it's a first date.
If your interviewer applies either of these rules so strictly that you "fail", you probably don't want to work for them...
...unless you really are the type of person who wants a work environment where such rules apply strictly, and you happen to have the same ruleset as the person who is interviewing you. In which case the two of you may work together very well, and the interview will be a big success.
The first rule of interviewing is: Although one of you is leading, and one of you is following, you are interviewing each other. It's a conversation. If I start out answering your question on a track that you don't want to follow -- integers and not vectors, Lisp but not ASM -- you need to lead me in the right direction, just as you would do if we were discussing a real problem. Your ability to guide the conversation, and my ability to follow, and our resultant ability to establish a rapport and keep the conversation moving, is what is under test here. The problem itself is far less important.
P.S. I have seen that XOR trick before, once, but it still blows my mind. I can never understand it without spending half an hour in a corner muttering to myself. Is there a field where that trick is so idiomatic that it's a reasonable thing to expect a candidate to come up with it an interview?
Yes, ultra low power embedded computers. 2 years ago a friend was working on a 32khz 8bit cpu with 384 bytes of ram and 2,000 bytes of ROM. The problem may have been simple but he setup multi tasking so he could do some networking while still keeping track of some other things and manual error correction because the memory was being flipped in the field. Basically, it needed to operate for years in a remote location on the power output of a watch battery and when your putting a million of the things in the field better code wins out over better hardware.
PS: In the end he still he still had 12 bit's of unused memory and in his words "you can do a lot with 12 bit's of ram".
P.S. Let's assume, oh interviewer, that your answer to my question "what kind of numbers?" is "integers, for now".
I think that's probably the stupidest thing that could possibly work, not counting: Assuming it does work, of course. It may have a bug. Probably does, in fact.Now you could ask me to find the bug and I'd write out some test cases in the margin. Or you could ask me what happens if a string gets in there, or how I'd generalize this algorithm to N numbers, or what kind of language I'm using with this exchange primitive in it (answer: my own highly arbitrary mental pseudocode!) or how I'd implement the exchange primitive, or how fast this algorithm will run on N numbers (not very; it looks to be O(N!), and that's not counting the fact that my exchange primitive is probably wicked slow).
Or, depending on the job, you might head in some other direction.