Because learning 64-bit architecture is impossible for somebody that have proven that they can learn a field, perform research, and successfully write and defend a dissertation? '32 < 64' is beyond them?
I've had candidates with PhDs in computer science who thought that pointers on 64 bit operating systems were two bytes wide. Do they believe that there are only 16000 possible allocations before the allocator fails? Not likely, because that's ridiculous. So how could they have that belief? because they understand so little about pointers that they don't understand the implications of their false beliefs.
I need someone who is going to command the salary that a PhD-level candidate will demand to be able to hit the ground running.
For example: I'm a midrange DevOps/Sysadmin/Whatever-it-is-these-days. I will likely never be a senior. The (real) seniors are the folks who go home and mess with hardware and pull new toys apart to see what chips they were made with and so forth. I like to go home and play games. I do my job competently, but I don't have the underlying knowledge that those guys do. If I was up against one of those in a job application, then you'd be crazy to hire me at the same salary as a senior - there'd have to be a pretty big black mark against the senior, like being completely unpersonable or abusive or somesuch. Or the role used some of the other things I'm decent at. Perhaps a colloquial way to put it is that I live these things, but the seniors live and breathe them :)
But it tells a lot about the amount of "just 5 min" things they don't know.
I was asked once what load average knows (and I didn't know it). Because my background wasn't in sysadmin.
The fact that you know one fact or doesn't is immaterial, but it's a good proxy.
Your hiring decision should not be based on only that, of course, but let's say it's a pixel in a picture.
I guess it is lucky for us that when they interviewed they didn't have an interview question that involved hash tables, because they would have been bounced for not hitting the ground running.
I bet I know a lot about a field that you don't. I wouldn't bet that you couldn't walk in and pretty quickly become useful, given that you've learned other things, and at one time I didn't know this field either yet somehow, somehow, learned it. I think you would do just fine; and I think somebody that can get a PhD in CS can handle the math that 2^16 < 2^64, even if they haven't thought about the implications re allocations.
Not sure that I agree on the choice of this specific "red flag"; on the other hand, having PhD in CS is a red-ish flag to me per se.
I would be interested in hearing your reasons for that.
But in my experience people with advanced "pure CS" degrees seem to be focused on the process not the result. I mean, they went to CS because they like to tinker with type systems, elegant algebraic concepts, nice abstract problems -- and not just as a hobby, they like it so much so they commited several years of their lifes to do that. Not that this is bad area of research, but generally when you look for a software engineer you look for someone not only smart but also pragmatic, who can get stuff done in a simple and efficient way, and this is kind of the opposite.
Of all PhDs, in my experience people who have degrees in areas that use programming as a tool not the goal in it self, e.g. physicis/EE, make the best software engineers.
If I ask somebody ten factual questions and they know the answers to five of them, how should I interpret that? Sure, it would be easy for me to just fill in those particular gaps in their knowledge. But assuming my questions were well-chosen, it's reasonable for me to expect that they'll continue to hit similar gaps in the future, about 50% of the time.
That's not to say that a good interview consists of drilling someone on facts; more often, they come up implicitly in the context of solving a problem. And as an interviewer, I'll look much more favorably on a candidate who recognizes what they don't know, because I give them the benefit of the doubt and assume that in a real-world situation, they would be able to do the necessary research. But even so, if there are basic things they don't understand, it's a red flag because it tells me they're encountering these concepts for the first time.