Propellerhead Software - Application Programmer Test
propellerheads.se
propellerheads.se
It's sort of like memorizing a chess board: A chess expert can memorize an actual game-in-progress quickly. But if you just place a bunch of random pieces around a chess board, a chess expert can't memorize it any better than anybody else.
The later examples with memchr are less painful, because memchr actually has well-specified behavior. But even there, the code (most likely) dereferences a pointer one past the end of an array, which is (1) invalid C++ and (2) not on their list of possible bugs. Granted, memchr is an internal compiler function, so it's allowed to rely on undefined behavior. But if this is a multithreaded system, that code potentially corrupts the heap's bookkeeping data structures while memchr is running.
Just looking at the first part of this test is like listening to somebody drag their fingernails across a blackboard. I'm sure that they're a lovely company, but ugh. To paraphrase Wolfgang Pauli, that code's so bad it's not even buggy—it's just semi-coherent nonsense.
Another interesting aspect of this test: Both the code examples and the bugs are pre-STL, pre-boost, and pre-TR1. For example, there's no question asking why you can't put a std::auto_ptr into an STL collection. And a huge fraction of the bugs in the test could be avoided by making rudimentary use of modern C++ APIs. Granted, some companies have legitimate reasons to avoid std::vector and std::tr1::shared_ptr. But avoiding those classes makes C++ vastly more error prone, which is usually a poor tradeoff in the modern world.
"But even there, the code (most likely) dereferences a pointer one past the end of an array, which is (1) invalid C++ and (2) not on their list of possible bugs."
There's a weirdo thing with array allocation in C++ at least which makes it valid to use arrays with all of the std:: algorithms that take a start and end parameter. Unfortunately I can't remember it well enough to find a good reference but as I recall it was more than just a pointer comparison as the std:: algorithms wanted to be able to dereference it occasionally.
Then again its been about four years since I've touched C++ so some of these details have leaked out and gotten mixed up.
The actual rule is pretty subtle, and I don't have a copy of the C++ standard in front of me. But let's see if I can remember the precise rule.
Given an array arr with length len, you're allowed to create the pointer arr+len. This is the end pointer you see everywhere in modern C++ APIs. However, if you try to deference arr+len, or try to create the pointer arr+len+1, the result is undefined. Typically, the former might point to a locked page, and the latter might overflow the pointer size. But if your compiler applies very aggressive optimizations, even stranger stuff can happen when you rely on undefined behavior:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
In the memchr example, the code potentially writes to arr+len, which has a decent chance of temporarily corrupting the implementation-dependent internal headers of the next heap block. In the presence of threads, this would very occasionally corrupt the internal state of new and delete, and debugging it would be a stupendously painful experience.
Reason may not be the most full-featured audio app but it's certainly the most stable.
Q1: I see a problem on all lines 1 through 6: The class doesn't do anything. There is also no documentation as to what it is intended to do. Here it becomes, as leon_ also comments, a game of "guess what the test writer wanted you to answer".
Q2: "It will work if..." is a meaningless phrase, because I am not told what the code is supposed to do.
Q12: "How many books have you read this year?" It is immediately obvious that "5 or more" is the answer that will give me the highest ranking from their application sorting robot. Everyone is going to answer "5 or more". The honest ones will then flip through the needed amount of books before the interview. The question is as meaningless as "are you a good developer or a bad developer?"
For example, what if the test was in Visual Basic, and instead of asking questions about non virtual destructors in virtual classes, it was asking questions about uses of various database Apis. " Oops, you used the wrong enum value in that function call."
Would that test yield top programmers, or just people who knew a database API very well?
Also, it doesn't demonstrate the ability to solve problems by writing code. At best it tests C++ code review skills.
I would have preferred to be able to get a result without actually applying for the job though...
Not to mention the function's name will be mangled, making it unusable for C users.
I don't like this kind of tests. I always stumble upon questions where I wonder if it's a trick question or just a typo/mistake by the test creator. Example:
Function D will loop for ever if size_t is an unsigned type. Function E won't even compile because of the comma and the missing * in the first line. Function C is an edge case. The external effect is the same only in a single threaded environment. If there's parallelism or interrupts the external effect might not be the same for certain conditions.
So what do I do? Do I check the box or not? If I do, it might fire back because "I didn't catch those obvious errors". If I don't then my application might fall through the grid because "too many wrong checkmarks". Maybe the recruiter is just a mindless HR bot and doesn't understand any of these questions. So arguing would be pointless.
If you want to determine my skills, give me something to do. Say give me 6 hours to implement a server or something (not too big, not too small for 6 hours), then shuffle through my code and see if its quality pleases you. Being bombarded with off-by-one trick questions just annoys me.