191–200 of 969 posts
Is this for real? Wow. Reads like someone spoofing the real Google interview. For "Director of Engineering" they have a technical illiterate (nothing wrong with that, in other contexts) check for literal matches of answers? the mind boggles. (I'm really having a hard time believing this is for real)
Believe it. The depths of corporate absurdity know few bounds.
I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing. It's a bit strange to have someone non-technical interviewing a techie…
Uh, my main languages are PHP and Python (high level stuff) and I'm a student (not someone with 10 years of experience) but I knew that. 3 bytes for the vendor block, 3 bytes for the device.
> Or what the actual SYN/ACK etc tcp flags are?
Yeah the actual bytes, who ever uses that? A MAC address I've seen plenty of times in my life as hex, and I've seen the TCP setup flags being exchanged plenty of times in Wireshark and looked up the hex once when I was implementing TCP from scratch, but I still wouldn't expect anyone to know that.
> You just need to know what they're used for
Agreed on that. I wouldn't blame anyone for not knowing the size of a MAC address, I just didn't think that one is that obscure.
A friend of mine was offered a similar position and had a similar interview. Annoyed by the questions and the "my solution is the only right one because I have to stick to this script"-attitude he asked: "So what do you want me to do at Google, how can I help you" the recruiter could not really answer and ended the call shortly after.
IMO, the very first step in entering googleplex/facebook is accepting that it is OK to lend your talents to build a global surveillance & propaganda platform. These tests seem to be probing for other desired characteristics as the next step.
I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing. It's a bit strange to have someone non-technical interviewing a techie…
Earlier quoted context omitted.
I knew all these answers too, because I was a developer in the 1990s. There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part…
The question was what function "returns" an inode. Those functions return a error code, you pass in a stat structure and the function populates that structure. He was saying (correctly), that they don't return (in the classic C sense) the inode. They return an error code. To me that is a big difference... int lstat(const char path, struct stat buf); vs stat* lstat(const char *path); 2 completely different functions.
Without actually hearing the transcript verbatim, it's hard to give much enlightened perspective here, but there's a lot of "hur hur, dumb recruiter" responses here. What I will say, in general, is that figuring out what the "right" answers are here for what is obviously a technical phone screen by a non-technical person with answers on a piece of paper is also part of the challenge. This is a Director of Engineering…
"Dumb recruiter"? What? Nobody's calling the recruiter dumb. Everybody is calling the process dumb. A process that puts somebody that cannot answer these questions, in charge of asking them and evaluating the answers. Having the candidate evaluate the competence of their recruiter is not part of the interview process. What the hell.
Earlier quoted context omitted.
The question was what function "returns" an inode. Those functions return a error code, you pass in a stat structure and the function populates that structure. He was saying (correctly), that they don't return (in the classic C sense) the inode. They return an error code. To me that is a big difference... int lstat(const char path, struct stat buf); vs stat* lstat(const char *path); 2 completely different functions.
In C, what stat does is how you return multiple values from a function. lstat has the same signature as stat: it passes the stat structure back through an output pointer.
Earlier quoted context omitted.
Why not? Especially in a managerial position, you will occasionally need to build a rapport with people who are convinced they have good technical knowledge, but don't. Being able to talk to them productively instead of picking fights is a skill worth selecting for . If you can't figure out that the first person who's interviewing you has answers on a sheet of paper and you're supposed to parrot them until you get to…
Have an up-vote. This is the most plausible explanation. They're testing his social skills and how he deals with people who are less technical than he--not testing his technical knowledge. EDIT: To add to this, I've seen this tactic before on an interview. Interviewer asked me a pretty softball technical question, I nailed it, and then he said, "No, you're wrong, it's [OBVIOUSLY INCORRECT ANSWER]." He was clearly try…
I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing. It's a bit strange to have someone non-technical interviewing a techie…
People that have been around know such things. At one point, Richard Stevens (RIP) was god. Every programmer had a copy of TCP/IP illustrated, Advanced Unix Programming and Unix Network Programming. If you wanted to do anything network, you had to write your own servers, you had to understand the details. The breath of knowledge was wide and the depth was just as deep. Ask around on HN, and you will probably be shock…
I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing. It's a bit strange to have someone non-technical interviewing a techie…
I've had questions that drilled down into what bytes are in a TCP/IP packet on an interview. If you say you know about TCP/IP on a resume, it's fair game. FWIW I got all the bytes but the checksum; apparently no one ever remembers the checksum byte. :) What's completely wrong with the situation is that the recruiter was saying "wrong" when he was giving detailed answers. The right solution is to have a non-skilled re…