Hear, hear. Obsession with trivia and a supercilious tone are sure signals of a B-player in my experience. "Name and describe the four states in MESI cache coherence"? Sorry, memorising an algorithm for determining if a graph is bipartite pushed that knowledge clean out of my head...no doubt I'm very stupid.

For what it's worth, I'd never (so far as I can remember) known the four states in MESI cache coherence, but worked out roughly what they had to be; when I checked after submitting my answers, it turned out I was right. And I've no idea whether anyone's ever told me an algorithm for checking whether a graph is bipartite, but I worked one out.

On the other hand, I know nothing about pthreads, made a handwavy guess about that question, and got it very wrong. The underlying failure was a bad guess about the semantics of condition variables. I could whinge about that, but I bet that if I spent more of my life writing multithreaded software -- which is, make no mistake about it, an important skill -- then I wouldn't have made that wrong guess even if I'd still never used pthreads. My answer might still have begun "I've never used pthreads, but ..." but that would have been followed by a better guess than it actually was.

Something may look like a trivia question but give much more information than just "does this person have the information stored in their brain right now?". In this particular case, Colin could (if he chose; he probably has better things to do than go into such detail on the hundreds of responses he's getting) guess that I haven't written much multithreaded software, don't spend a lot of time optimizing things for the memory subsystem but have a good grasp of principles, and am good with algorithms. Not so bad for three trivia questions.

And, whatever cperciva's failings (which may for all I know be many and serious) one thing he certainly isn't is a "B-player". (But then, in my experience talking about "B-players" is itself a bad sign.)

He's definitely not a B-player, but that makes it all the more mysterious why this project is missing the target so badly.

I don't think the questions are awful, though they do tend to have a trivia component to them.

What I think has really happened is that the whole thing is completely mispackaged. By calling it a "software development final exam" and saying it's things every programmer should know, he's set up an idea that it would be fairly broad and comprehensive, when in reality it's fairly narrow.

Plus that terminology is a bit socially off-key since it sets people up to be defensive rather engaging in meaningful discussion.

Indeed, presenting this more 'guide to interesting things you should know' rather than 'here's an exam I've condescended to set for everyone dumber than me' would have worked out much better.

Maybe B-player is harsh but in my career I've worked with some very good programmers and some real stars. When I talk to the very good programmers I always feel dumber, but whenever I talk to the real stars I always feel smarter myself (though heaven knows that's not actually true). This seems to fall firmly in the "very good programmer" category.

I thought that the bipartite graph algorithm question was the best so far. It was a question that, in addition to remembering what a bipartite graph is, required a little bit of thinking instead of just rote memorization (if you know what a bipartite graph is you can come up with the algorithm on your own -- no need to memorize that). Question #2 in this set is also pretty good.

Remembering the relation of a bipartite graph to graph coloring helped me coming up with an algorithm fairly quickly. Although that might in fact require a little familiarity with graphs and the associated terms. I guess most of my former fellow students who didn't hear a graph theory lecture won't really remember that.

"Name and describe the four states in MESI cache coherence" is mostly about having at least basic idea of how multiprocessor systems work that is pretty crucial to any seriously meant multi-threaded programming. It's something that anyone who wants to call himself a programmer has to know (or at least have some idea that something like that is happening, which is almost equivalent to knowing how it works, because it's really straightforward).

I don't think the question as phrased is about having a basic idea of how multiprocessor systems work. It's a question about naming(!) of the component parts of a specific protocol. That's trivia. It's as if the question about the TLB was about the acronym rather than the function.

(So what's a good question to see if somebody understands cache coherency? Maybe describing a problem caused by cache-line contention, and asking for an explanation and fix to it?)

"They can be very difficult to work with."

Don't you think that is a bit harsh? From what I have seen of Colin's work and contributions here on HN he seems like a pretty knowledgeable and decent chap to me. I rather enjoyed myself contemplating these questions - although I haven't had the nerve to submit completed answers!

The red flag was this line in the blog that led to the questions: "If you can't answer the majority of the questions on these four papers, and you're working or intend to work as a software developer, you should ask yourself why".

This assumes an air of authority that the poster clearly cannot posses; that is, he does not have the right to judge whether someone is a valid software developer or not. Someone claiming this level of superiority seems to fit the personality type I described. Of course - I could well be wrong but that's what it sounded like to me.

Okay, so I agree that Colin's exam might be a bit too specific and that he might have phrased certain things poorly, i.e. "lucky enough to be working within a narrow area where your deficit doesn't matter". I think either his experiment will help him discover that "luck" (i.e. statistical distribution) doesn't lean the way he assumed or -- and this is more likely -- he'll obtain biased results because a lot of people will refrain from sending bad results.

That being said, I honestly prefer being judged by someone as accomplished as Colin Percival than hiding behind the attitude that we should not judge other people's abilities.

Let's face it, there's an abundance of downright bad and mediocre programmers. There aren't that many top-notch programmers, although each of us would love to think we're among that small group. This is what motivates us to speak out against any attempt to measure and assess abilities, especially if such an attempt is likely to rank us low.

I'm not ashamed to admit that, so far, I haven't been able to formulate an answer to more than 5 questions out of 10 he posted so far. While I freely admit that I don't consider myself to be a programmer in Colin's league, I think that's really beside the point here.

My knowledge is cached: what I work with all the time is easier to recall; what I've worked with or read about, but I'm not using all the time is not as easy; and, of course, there's a ton of things I don't know, have never worked with or read about. This means that I don't feel confident talking about B-trees without consulting Internet, but since I read about them previously, I do remember that they're a form of search trees and that databases use them (or their variations) a lot.

What's the point of this whole rant? Let's bottom-line it. I'm probably not as good as Colin overall and I'm definitely not as good as he is at what he, specifically, does. That doesn't mean I should feel threatened by his exam. Nor does it mean it has no validity whatsoever. Nor does it mean that Colin is "difficult to work with" or fits any specific personality type.

Those two claims about Colin's personality and intentions are what really bothered me about your reaction. I'm not a fan of straightforward ad-hominems, but I detest veiled ones even more.

Well said, but I'm still not inclined to send him my non-answers so that I can deliberately enjoy the feeling of inadequacy.

The author never judges whether someone is a valid software developer or not. He ASKS why people who work as software developers don't know the answer to (in his opinion) basic questions. Obviously, you would have to read the whole sentence and not just a part of it to understand the question asked here. For your convenience:

"If you can't answer the majority of the questions on these four papers, and you're working or intend to work as a software developer, you should ask yourself why — most likely you're either you're missing something you really should know, or you're lucky enough to be working within a narrow area where your deficit doesn't matter."

Not judging? "... most likely you're either missing something you really should know, or you're lucky enough to be working within a narrow area where your deficit doesn't matter."

Talk about reading just part of the sentence.

"not judging whether someone is a valid software developer or not" :) I didn't write that he wasn't judging.

"The author never judges"

yes you did...

Note that this refers to all four parts, not just the second. In this case one might lack detailed low-level knowledge of threading and a particular library used to do so on POSIX systems which may have no relation to performance in the other parts.

I liked the part of your comment where you cropped the rest of his sentence: "— most likely you're either you're missing something you really should know, or you're lucky enough to be working within a narrow area where your deficit doesn't matter."

I didn't crop that so as to take it out of context, I cropped it to keep the quote short. I don't agree with the bit you added either.

great conextualization philbarr, also I would add that CS is just one of the foundations of software engineering but certainly not the only one and many would think not even the most important one.

Having said that if these questions tickle your intellectual curiosity go ahead and figure out their answers, just throw away the belief that you can become a valid/invalid software developer just because you can/cannot answer some questions.

The questions are actually quite basic. It has nothing to do with CS degree. Anyone desires to learn would have learnt them. It just makes you a better developer. And people who know them are not difficult to work with. If you as a team lead feels threaten by people who posses basic CS knowledge, you don't qualify to be a team lead.

Is this what we are coming to? The dumbing down of software development? Have the mainstream anti-intellectualism been spilled over into software development?

The point is that you can be a software developer without knowing this stuff off the top of your head. Naturally I would encourage anyone who doesn't know the answers to these questions to go ahead and learn them if they want to, but you're probably not going to need them day to day, so his assertion that you're not a software developer unless you can answer his "final exam" is incorrect and demonstrates a certain level of ego I find unsettling.

I didn't say "people who know the answers to these questions are difficult to work with", I said, "people who declare their knowledge as an absolute requirement are difficult to work with".

There is a huge difference between not knowing the answers off the top of your head and not being able to learn and understand the answers given 30 minutes and access to Google. If you fail the former that's fine in my book, if on the other hand you fail the latter then that might be reason for concern.