> For some reason most people seem to be born without the part of the brain that understands pointers

Well, that's just false. Everyone can understand pointers given both time and interest. I realize Joel likes to think him and people like him are "special" and born with innate super powers, but we have overwhelming evidence that it isn't true.

I certainly wouldn't recommend hiring someone to write embedded systems that don't understand pointers, but if you are hiring a generalist, a good engineer can figure it out if it becomes a job requirement down the road.

These are the reasons literally everything Joel says should be taken with the biggest grain of salt you can find. He seems like a smart dude, but like a lot of smart dudes that are aware of their intelligence he highly overestimates (and overvalues) his particular opinions.

My advice: don't be like Joel and use anecdata to drive your theories on what constitutes a good interview. You're already writing exactly like he does, and that's not beneficial to you or to those you're interviewing.

> Well, that's just false. Everyone can understand pointers given both time and interest.

I'd like to believe that's true, but I've spent quite a lot of time trying to explain pointers and recursion to people and either they get it right away or practically never. Sometimes they end up with some cargo-culted half-way understanding that lets them solve most problems but they still don't seem to understand what's happening. Joel is a bit pompous, that's true, but there definitely are people who cannot understand pointers when taught in a normal CS course, and if 4 years of university didn't teach them pointers I don't think they'll get them while programming in the field.

As an aside, the fact that some people can't grok some things shouldn't be controversial. I myself can't understand lots of things and probably would never understand them in the way that people who grok them instantly do. People have different modes of thinking, and I do not doubt that there exist people who cannot grasp pointers and recursion in the same intuitive way that I do. That doesn't make them less smart in general, but it does mean they're a bad fit for e.g. a C programmer position.

Speaking for myself, I was the person Joel described except that I didn't switch majors. The pointer wall first struck at the tail end of my HS years and then crushed me early on my Freshman year of college. It took me a couple of years but I finally wrapped my head around pointers. It could be that I really do fall into your half-way camp, but I don't think that's the case.

I was a terrible student more interested in playing games than doing any actual work, so that I'm sure was a large part in the problem being "years" instead of "months", but either way it was something I learned and not something I was just born with.

I do agree that for any person there will be things that they get right away and things that they'll never get. But I think those vary more than people realize.

It's not controversial that different topics are difficult for different people, but the idea of "innate" understanding is absurd. And the idea that code quality has a direct causal relationship to code quality is even more absurd. He certainly didn't qualify that statement to imply C programmers have lousy code when they don't understand pointers, but how many people that struggle with pointers want to jump on that ship anyway?

End of the day, learning its a personal thing, and some people struggle in some topics and not in others, but under no circumstances do I think there's an innate ability to understand pointers and some people are never going to have it. That just sounds like C programmers trying to pet their ego.

> I'd like to believe that's true, but I've spent quite a lot of time trying to explain pointers and recursion to people and either they get it right away or practically never.

Have you thought about may be you don't understand pointers and just think you do ? May be you should not start teaching and explaining about pointers before you understand it well. If you can't pin-point why your students don't understand and just say they won't understand at all (may be weak math background or something else), then I'm sorry you lack the knowledge to teach or use pointers.

A good excuse for struggling with recursion is that the person is a kernel programmer. There, on a very limited stack, recursion is so dangerous that programmers develop a strong reflex to get rid of recursion. If you tell them to produce something recursive, at every line of code their mind will be screaming DANGER and trying to fix the problem.

Such people are better tested on problems involving cache lines, TLB entries, memory-mapped IO hardware, DMA, atomic instruction opcodes, and interrupts.

I guess I'm more worried about false negatives (i.e. people doing poorly who would do well on the job) than false positives. I have worked with excellent coworkers who I think would likely do really poorly on DP questions because they didn't do contest programming or didn't happen to learn it in their education.

Recursion is a great thing to include in an interview (in moderation), no objections there. Many real-world situations are naturally recursive, and a good grasp of recursion helps build a strong intuition for many aspects of programming. DP (specifically designing recursion with overlapping subproblems) is a much more specific technique that I think isn't as beneficial for programming ability, though I certainly don't doubt that people who know DP well are often also good programmers.

That article by Joel goes into detail, but I agree with him that false positives (hiring someone who turns out to be a dud) are MUCH MUCH worse than missing out on someone who is potentially good (especially the rarer case of someone who is potentially good but still did poor on the interview).

> For some reason most people seem to be born without the part of the brain that understands pointers.

If you can understand P.O. box numbers, you can understand pointers. They're the same concept at the level of modern application programming, where the OS, MMU, and cache are comprehensively lying to your code to present the illusion of a completely flat address space. At that level, all a pointer is is a box number, and you can say things like "Get me the thing in box number 23" or "Get me the thing in box number 42 and the three boxes after it, put those four things together into a number and then get the four things at that box number and the three boxes after it" and, while the second thing is involved, it's straightforwards and it is precisely the kind of double-indirected thinking Joel is talking about.

To get a bit deeper, you can use the old "Paging Game", also known as the story of the Thing King, to introduce virtual memory:

http://archive.michigan-terminal-system.org/documentation/th...

This is wrong in almost every specific detail when it comes to modern systems, as it dates from circa 1972-1974, but you only need to change a few numbers around and it's good enough in a lies-to-children sense. The only substantial change that would be required is if you want to mention ASLR.

And that's it. That's it until they actually get intimate with a specific hardware architecture and OS and learn very specific, rather ephemeral details. Pointers just aren't all that special.

Yes, and then you have to make people understand that box [number 23] is itself in a box and 23 can change at any time. And you can ask for the thing in box [the thing in box [the thing in box [the number that was passed to this function]]]. It's a double and sometimes triple indirection and understanding that pointers and the things pointed to are the same kind of data is the hard part. It's numbers all the way down.

You're making a strong point here, which is that every real world analogy of pointers breaks down since everything is data. But I'm still not sold on the idea that pointers are intrinsically a "make it or break it" topic for people to learn.

In fact, I'm resistant to that sort of conclusion in general. I don't really think there are things that people of average intelligence can't learn, given enough time and pedagogy. And I say that as someone with a background in mathematics, which is one area most typically associated with people "not getting it."

If people don't learn pointers, it could be because they're not sufficiently motivated or don't have it presented to them the right way. It could be that the overuse of analogies does them a disservice, and they really just need to pick up a book. Whatever the case may be, I'd hesitate to say it can't be learned by any population of people.

Your reference to Joel and how you rely so much on your intuition tells me that you tend to have "I'm better than other" type of feeling just because you understand DP. This is the exact toxic I would want to avoid in the workplace. Same with Joel's reference, I'm shocked that he thinks understanding pointers is not a skill (may be I should interview him on pointer arithmetic and see just how good he is). My experience has been that these interviewers who say they are so good in DP, pointers, recursion and throw this aura of 'false negative' and know it all show true colors after the interview. They make wrong decisions on when to optimize, are clueless about scale and distributed systems, can't write complex sql, just don't know how to turn on little knobs to solve the problem so write huge unnecessary code. All this is probably because they never thought more than DP/recursion (which I would avoid at any cost in my code base).

I’m not seeing the connection here between DP problems or pointers indicating great engineers. I’ve worked with people who were great at programming problems but couldn’t actually solve real world problems without step by step guidance, folks who cannot communicate at all with the team or with product people, folks who have a terrible work ethic, etc. The ability to solve DP would be nothing but noise if we were to go back and time and hold these interviews differently... and to be honest, we almost always had at least some recursion or DP problem. All it really did was bias our hiring towards grads fresh from school.

Regarding understanding pointers... you may as well use the candidates understanding of object oriented programming or knowing how to test their code. Pointers seems like an arbitrary litmus test, and it comes off as you feel like understanding pointers make you special when it really doesn’t.

> They are having a good ol’ time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly, they don’t get it.

That's the first day, surely? That's how I remember it. You're not going to wait with explaining pointers, right?

And I don't think anyone didn't get it, despite being Engineering students rather than CS students.

It just seems like a huge exaggeration to me.

Come on, pointers are easy. In a 45 min interview you could teach someone pointers and still leave time to solve the problem.

DP is much less easy to understand unless one has purposefully studied and solved a lot of DP problems.

I agree with a lot of comments here. Interviewing for DP only nets you people who have studied DP.

There are several "hard" things in CS/software-development that I keep having to convince myself I do, in fact, understand, every time they come up in a discussion like this, because I find them really simple and wonder whether maybe I missed something. One's pointers. I don't get what's so hard about them. I mean I get why they might be tough the first time you're introduced to them but it's exactly the same kind of reasoning/structure that's used all over the place in programming, so if one can't understand pointers I'm not sure how one's programming at all, really.