It was dead easy and I'm seriously surprised that anybody on HN that's here not for the 'startup' angle would have a problem implementing this quickly and correctly.

As code challenges come I don't think I've ever seen a more trivial example.

This was my sentiment. I've been asked (and succeeded, presumably so do other people) to write pseudocode to solve more complicated problems than this on a whiteboard, in an interview.

Maybe this seems harder to people unaccustomed to C. I don't know. It seems like it would make sense to aim just a little higher, though. I recognize that it has to be a small enough that people won't be put off by it, but most people will be willing to invest the fifteen minutes necessary to solve a mildly complicated problem.

are you this arrogant in real life?

It's not about being arrogant. Unless you have never done any real programming apart from simply calling library functions, the original problem is about as interesting as asking "Write a program to add 47 and 88 together".

I think the issue is that many programmers have never done real programming. They just chain library calls together. It's like comparing a furniture maker who starts with a tree, to a furniture maker who buys parts from IKEA and assembles them.

To be a really good programmer, you need to be really really at ease with bits bytes, moving stuff around, and getting your hands dirty with real programming.

I studied applied math instead of computer science, and the exercise took me a good 15 minutes plus some time to adjust to C as I've only worked with C++. Then another 5 to simplify some redundancies. I believe the solution I came up with was elegant, correct, and idiomatic.

Does this mean I'm not a good programmer? If I worked with C and pointers a lot then it might, but I find the attitude that not being able to slip into that mindset immediately equivalent to being an inept programmer arrogant.

I'd say that a good answer is a good answer regardless of language. I wouldn't personally care what language someone wrote the answer in as long as they got the key concepts which in this case are pretty damn simple -

Have a source pointer, have a destination pointer. Copy stuff from src that you want, over to dest. Leave out any bytes of value N. Don't forget to copy/make a new 0 at the end.

And that's it. That's being a programmer. Knowing some particular languages syntax isn't. That's the easy/irrelevant bit IMHO.

So it really depends on if that 15 minutes you spent was to arrive at the 'solution' I wrote out in words above, or if it was checking up syntax to write it in C as to wether you're a good programmer or not.

Just my 2c.

I just submitted a solution. I believe that one can tell "has this person written a non-trivial amount of C code?" from 15 seconds glancing at their answer in your peripheral vision.

I agree that it can be solved essentially the same way in many languages, but the idiomatic Erlang solution will look a lot different than the idiomatic C solution.

Edit: After reading some of the code posted here and linked from here, perhaps I don't have the same sense as others of what the idiomatic C solution is either. This should be interesting to read the followup posts by RoG.

That's very well possible, but it is also possible that it really was a simple problem.

As for my arrogance: http://jacquesmattheij.com/Mistakes+I%27ve+made,+and+what+yo...

I agree that it's a simple problem. I just don't type quite fast enough to do this in two minutes (especially if I count time spent making a main function and testing my solution).