No, it's not. It's a trivia question. Nobody uses such techniques any more because looking at raw memory dumps is not the right way to debug these days.
Lastly (and I am completely going on a limb here, without any concrete information), this could also be used to gauge team/culture fit Google. This is a good way to see if you'll be a fit for a team that spends a huge amount of time finding and fixing low-level bugs: it's fun to read about infrastructure that Google has built, but the actual process of building it may be very frustrating to some. Not being a fit for such a group doesn't imply rejection, it could simply mean you're brought back to a different round with another set of people.
If you want to find engineers with talent then you need to do a lot more leg-work in plumbing their knowledge, experience, and skill than merely ticking off a checklist of shibboleths.
P.S. Personally I love hacker jargon and lore, I like knowing about scratch monkeys, core memory, the usenet cabal, and even 0xDEADBEEF, but I wouldn't take ignorance of those things to translate to ignorance of engineering fundamentals or of passion in software development.
It's not about hacker folklore, it's about a debugging technique.
No one implies that this question is asked of every candidate. That's why these lists are useless. It's also not the way I'd ask a question about memory markers (I'd ask them about how they go about debugging such a problem and how the tools they use e.g., gdb and valgrind work), but it's a fair question to ask those claiming experience with or interest in low-level development much like it's fair to ask candidates who claim experience with data mining what the kernel trick is (...but it would be misleading to ask a Linux kernel hacker that question as that would mean something else to him, much as dead beef would mean something else to a data mining guru).
It's not a knowledge question, it's a trivia question. A shibboleth. It is neither a necessary nor sufficient pre-condition for knowledge of memory debugging techniques and it probably has about as much correlation with them as asking whether they have read The Lord of the Rings.
It's a hexadecimal number, that should be quite obvious. It's a noteable and easy to notice one. Others may have used a different one (I used 0x12341234 for the task as others have used 0xdeadbeef) but it should be obviously what you'd use it for.
Is it one of the better questions? No. Is it merely a shibboleth or a piece of trivia? When asked to low-level hackers, no.
If someone were to change the question to "what is the significance of bad food?" would it be considered equally valuable?
cafe babe, dada dada would just as well as dead beef
In short, either you are familiar with magic numbers or you're not. If you're not, you're certainly not qualified to work on anything really low-level and may not be qualified to do C/C++ development in userland either (without strong evidence to the contrary).
However, I admit to asking a lot of trivia questions when interviewing candidates at Apple, partly as a culture fit, and partly because I could use them to segue into a chain of questions that dealt with the consequences of seemingly innocuous design decisions made by engineers long ago. This was something my group had to learn to foresee and deal with when we thought bad things would happen.
One of these questions had to do with 0xCAFEBABE.
That said, getting the trivia part right was a +1, and not knowing the info was a +0, so no harm if the job candidate didn't know it.
I'd also use them as a shortcut to validating their experience in an area. Again, a +0 if they didn't know the trivia, but if they do, I can move on to a different line of questions.
That seems very dangerous. I, for example, know about DEADBEEF and CAFEBABE as hacker trivia, yet have close zero experience in actually using those techniques for debugging real world problems.
So if some questions (like the "why are manhole covers round") are definitely fake, and others seem very weird (like the dead beef one), isn't is more likely that that question is fake too?
It may sound fake to you, for a specific team you interviewed people for. But, it's an entirely reasonable question to ask for someone who claims low-level experience for a team that actually does low-level work. Use a product your ex-employer has built to search for '0xdeadbeef' and you'll see this technique is not just a piece of esoterica.
There are many kinds of software engineers: a low-level hacker may just be as puzzled by "support vector machines" (why do they need our support?!) as you are by 0xdeadbeef.
[Edit: last point is why lists like this are meaningless. This question likely gets asked by teams who do low-level work, other questions get asked by teams who do machine learning, etc...]