pouët.net

btw. my answer to question 1. would be something like (given your number wouldn't be 23 but something WAY HIGHER):

=> 10111 (that's the complicated approach - for numbers as little as 23 not really needed)

Now for turning bin to hex you just look at 4 bits (3 for octal! - ask for octal - that will kill some guys hard :D) each - that's the most simple conversion approach and also works for pretty high binary numbers (maybe you should ask for a 16bit binary to octal conversion!).

=> 0x17

Ask this as the first question.

I guess that's a killer ;)

023 is an octal number, so: 2 * 8 + 3 = 19.

psenough somebody who has C++ experience will use the right piping direction - not thinking of it at all - he's a liar.
It's like you are asking a test driver to drive forward and he directly goes for the reverse. FAIL.

I still prefer the 1st guy - he doesn't fail on negative values.

Adok: o'rly?

las: not to mention that he could stop at n == 1, since 0! == 1! == 1. ;)

I don't think so. If there was another character after it (like [+-Z]) it would be treated as a character range, but if it's the first or last character in the group it's treated as a literal '-'.

ok, he could not, unless n is > 0, always :] lablabla... ;)

tomaes: exactly. ;)

las: i have c++ experience and might not have gotten that right without checking examples or docs to refresh my memory. unless they're also experienced with linux scripting i dont see why anyone would brain print that info. :p but maybe its just me, my eidetic memory never been that good :p

border cases are hate - btw. the factorial thing overflows for pretty "small" values of n.
That might be a good question for the "what could possibly go wrong" part...

Quite easier than test I have gone through, but ok it was in notepad as you said and shorter time. Regexp would be challenging because I know shit but given that I was allowed to look at the links who knows? File API would be a bit challenging too because I don't know but I would try to guess. I see people screwing on simple hex stuff (I wish they ask me such questions) but there is the difference, one might happen to know this because of low level coding exp and others not regardless the experience in C#, Java, NET, whatever.

I have never used cout, I don't know what correct piping is.

Ok, since we are all about silly test wanking, here's a simple one (in plain ANSI C):



This is simple, but I guess 90% of all comp.sci bachelor guys would get this wrong. :)

Gargaj:
lol, I was laughing so hard I almost fell from my chair :)

las: I agree with you that I should have talked with some of them after the test, especially with those that almost make - it like the last one, I wish I could tell him "hey, make an effort to clean the code...".

las & psenough: regarding piping direction, I don't think it's such a big deal. but in a test, if you're not sure at something like that, why not use printf?

Optimus: I'm no regex expert myself and frankly I hardly use it. The idea in this question is to test the applicant with something new that he/she doesn't know --- testing their learning curves. However, this gets pointless if preliminarily regex knowledge exists. I'm planning to add another question that require "learning" during the test. I was thinking of some assembler code understand or something similar. Ideas?

tomaes: I personally think that 99% would fail your question, I also think that it can accidently filter out guys I'm interested in. As I said, I'm not looking of an expert/system architect. I'm looking for smart guys with 2-3 years of experience and I believe many of them will fail this question.

TLM: i'm tempted to say brainfuck but i would really recommend having something related with practical applications instead. debugging someone else's code from an unknown API might be more what you're looking for.. like, giving them the docs and a few examples and telling them to debug or implement from scratch or write some test cases for it. you can throw in some obscure hexadecimal, recursion and such stuff in there while you're at it. actually the whole test could be based on that.

ask them to debug some stuff from http://underhanded.xcott.com/?page_id=2

Or write a smashing demo in Malbolge -> http://en.wikipedia.org/wiki/Malbolge :)

psenough: The problem with having something practical is that you quickly start to test experience and not for ability. so, I actually like the brainfuck idea,
it toke me about 5min to understand the hello world sample, so I think it is fair to give in a test.

I might ask what the following program does... This is so nasty - I like!

"programming" is not a job, it's just the means to do your job. a job is "making robust and fast websites" or "make pretty images for a game" or "make an crossbrosser web sound api". you should make questions relevant to the job, not to the tools the candidate will (probsably NOT) use...

iq has a point

strange.. my job is to "do what the boss says, don't ask questions".

iq: The company is an software/hardware design-house. Often, the "job" gets defined by the clients. One of the main problems here is the diversity of the problems a developer faces in the day-to-day. Not only that, it is often required to quickly understand the business aspects of the clients.

So the "job" description would be "a developer that will be quick to adjust and learn new technologies, tools and business aspects along the way". That why I'm focusing on abilities and less on experiences.

well, i guess i was just trying to compensate for all those opinions who are focusing no how good of a low level bit-hacker or C-magician one is supposed to be in order to be a good programmer. if understanding clients, solving problems and being flexible and adaptable to new techs is what you need, the i'd totally NOT test them by making them write a mutithreaded memory pool in paper without errors. i'd aske them, "if you had to solve this problem, which approach (tools, development phases, modules, technologies) would you use?". you can bring them projects from old clients, and see if they hit any reasonable approach. dunno, whatever. i'm just saying, don't judge them by how good they are at writing regular expresions or do the SBB assembler trick to clamp values without conditional branches. i'm just saying that, i guess.

@TLM: guess why it's called brainf*ck? Are you sure you want this kind of programmer?
If so you could also give the following (Single Instruction Computer):


And ask what the following program does:

I think judging programmers by their ability to "crack"/debug code is a good start.

Understanding clients when you (design) code for the moniez is essential, IMHO.

Testing for coding-corner-cases in a job interview is usually not helpful, I think.
(nice obfuscated loop there, Tigrou. made me think for some minutes)

for everyone failing the fizzbuzz test: "rly?" (how could you ??? :D)