5 ms·
I wonder about the technical knowledge of this person who's writing articles about hiring technical people. "Explain the significance of ‘dead beef'" is a perf
by ajg1977 16y ago
I wonder about the technical knowledge of this person who's writing articles about hiring technical people.
"Explain the significance of ‘dead beef'" is a perfectly valid, if somewhat unimaginative, technical question.
- InclinedPlane 16y agoNo, 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.
- gcb 16y agoIf the candidate is bragging about the time he saved the day with raw memory debugging, I'd start with this question to confirm.
- Gayle 16y ago@strlen Again, some of the questions are absolutely 100% FAKE. 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?
- strlen 16y ago> 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...]
- strlen 16y agoUsing a "magic marker" like this doesn't imply looking at a raw memory dump (which, however, is still needed in several places Google is involved e.g., kernel hacking, embedded devices). For example, I used it myself when debugging an issue where our processes morphed into un-killable zombies. I was dealing with crash dumps, where I was walking through the process list in the kernel (it's a doubly linked list) in crash/gdb (looking at kernel memory dump obtained via netdump from a production server that manifest this condition) so I could find a process that has acquired a specific lock to test whether a theory that I had was true. I wasn't (and still am not) at Google and I don't even claim to have any expertise in actual kernel development: it was a bug a customer was experiencing and it needed to be fixed. 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.
- InclinedPlane 16y agoIf you want conformity that's fine. What would you think if your company instituted a very specific dress code? Requiring specific trivial knowledge is just as restrictive and constraining. 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.
- strlen 16y ago> If you want conformity that's fine. What would you think if your company instituted a very specific dress code? Requiring specific trivial knowledge is just as restrictive and constraining. 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).
- ajg1977 16y agoThe "right way" depends on the task at hand and the tools you have at your disposal. For any type of low-level work, being able to view, understand, and observe regions of memory is pretty much essential.
- deleted 16y ago[deleted]
- jwatzman 16y agoWhen I was writing a malloc implementation for a class, I defined a value I used in place of NULL to terminate a structure sort of like a linked list. With debugging off, it actually was defined to NULL; with debugging on, it was defined to 0xDEADBEEF so that I could see the distinctive value when debugging.
- sayrer 16y agoyeah, I've read this blog post before, and this bit has always stunk to me. The pattern might be 0xDADADADA, 0xCAFEBABE, or 0xDEADBEEF. But it seems perfectly reasonable to ask what one might use this for. In fact, you'll find 0xDEADBEEF in the man page for libgmalloc. (and all of the replies are about "raw memory" debugging... wtf)
- danvet 16y agoFrankly, 0xdeadbeef is a rather bad value for a pointer poison: It doesn't have enough leading zeros to be caught in unmapped area used to catch null pointer access (it has a high change of being a valid kernel address on linux if you have about 700mb of ram). And there are not enough zeros at the end to still recognize it if the access is to a offset within the array/structure (as it usually happens). Not catching the usage of a poisoned pointer on first access creates enormous amounts of fun - normally preventing any meaningful analysis of dumps.
- demallien 16y agoAgreed - not only do I find "DEAD BEEF" as a rather gross concept, but there are technical flaws, as you point out. I personally prefer the simple, form-matches-function 0x0000DEAD. Yup, that pointer's dead baby!