> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
FizzBuzz also tests basic programming skill, and it's surprising how often people fail that part. FizzBuzz isn't necessarily the best test of that; I know one interviewer who instead uses "write a function to swap two numbers". But some test of basic programming skill does help, albeit it should happen long before the in-person interview.
The XOR trick is cute but you shouldn't use it on anything larger or more modern than a Cortex-M0. Just put it through a temporary variable and let register renaming deal with it.
(Perhaps a more interesting question would be a multi-threaded examination of swapping two numbers...)
It's interesting because this is a real answer that will get you hired. It demonstrates knowledge of: the "correct" way to do it, basic asm awareness, programmer culture, and computer architecture. This probably checks off like 6 boxes for most technical interviewers in one answer.
Finally it implies it could have asked a better interview question ;)
Thankyou. I try to strike a balance with these things - showing off is mandatory in interviews, but needs to be done politely. You don't want to go full "Hexing the Technical Interview": https://aphyr.com/posts/341-hexing-the-technical-interview
Part of the point of the question is to get people thinking about that, solving it on the fly, and explaining their reasoning. One of the lightbulb moments is when they realize the function needs to take pointers or similar (and typically ask if that's OK).
Yes, for code in languages that don't have it as a built-in library function. I've also written functions to swap strings, and implementations of various standard library functions.
Also: have you, as part of your day job, ever written code to solve a specific word puzzle? (Based on an actual interview question I've answered.) An interview question is supposed to be representative; that doesn't mean every interview question must come directly from a specific problem encountered in production code. You ask questions to prompt people and see how they think and how they communicate.
There are a couple of reasons why the 'function that swaps numbers' question is, in my opinion, a bad interview question.
1. it's a very simple thing to do, so why bother with a function? It's like asking someone to write a function that takes an integer value and returns an array of that length.
2. if you really do need a function that swaps numbers, then you probably also have some special edge cases that you will have to deal with that the candidate likely won't know about
3. each solution is language dependent
Maybe those aspects are why you consider it a good question, but when I have been asked those types of questions in the past I felt that the interviewer was missing an opportunity.
Would you consider solving an algebraic expression that was a string as a word problem - ie
“$x * (5/25) + 10 * $y”
Of course it involved variable substitution, converting it to rpn, and then using the “Shunting Yard Algorithm”. I’ve had to do that twice. The second time I was maintaining a proprietary compiler/VM/IDE written in C++ for Windows CE. Yes, that was a dark time in my life.
(Without detracting from the fun anecdote, I think we're firmly astray from the original question or the further questions down-thread. The latter was about interview questions versus real-world problems. And no, I wasn't talking about algebraic expressions; I was talking about word games or puzzles, as given in interview questions.)
It depends on what your “world” is. If I’m being hired to write yet another software as a service CRUD app, then algorithm questions aren’t the “real world”. But, when I was being hired to do low level cross platform C without any third party libraries that we didn’t write ourselves or to maintain a compiler - algorithm type questions were appropriate.
In fact, we were writing custom document creation software and outputting to industrial printers at the first job where we were doing a lot of text processing.
The XOR trick looks cool, but requires three CPU instructions to execute. My favorite way to swap variables is to use:
tmp = a; a = b; b = tmp
When a compiler generates code, it maintains a mapping from variables to registers. So when the source code refers to the variable 'a', the compiler might map this to register %eax, and 'b' to %ebx, and it will use this to generate assembly code (or IR or bytecode or whatever).
A good compiler will recognize the three-line variable swap above, and optimize it so that the mapping simply changes at that point. So any references to the variable 'a' before the swap will refer to %eax, and after will refer to %ebx.
This requires zero instructions, and zero is less than three :)
That doesn't necessarily work if you're doing the operation in a loop, unless the compiler also unrolls the loop to some degree (which isn't a zero-instruction change). It also only applies to local variables, and doesn't apply when swapping global or in-memory data.
I've rarely encountered a "swap" operation on local variables in straight-line code, as opposed to a loop, or a swap of global/in-memory values.
One nit, though:
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
FizzBuzz also tests basic programming skill, and it's surprising how often people fail that part. FizzBuzz isn't necessarily the best test of that; I know one interviewer who instead uses "write a function to swap two numbers". But some test of basic programming skill does help, albeit it should happen long before the in-person interview.