Hahaha, that is funny/tragic. Outsourcing hiring a director of engineering to a moron with a cheat sheet! Your answers were great, though, and indeed on the systems I have tried the popcount() computation with the bit shifts you suggested is faster than using an 8 bit lookup table. (however the SSE4 popcnt (https://en.wikipedia.org/wiki/SSE4#POPCNT_and_LZCNT) is faster still).
While I think these things are super interesting trivia, I really want to ask the question: "Why does a Director of Engineering for Google need to know this?" That is not only a rather unusual question (within the scope of daily tasks for a programmer, these tend to be an important minority for a project), but it's one that's best settled empirically and within the context of your execution environment.
There are a lot of different answers to the question depending on where you're doing it and how you want to impact the machine.
It's a bizarre question to pose to Director level, because the proper response even for a technical director should be, "The answer to that changes quickly, we should measure and check what our environment's latest capabilities are and if they are reliable."
I mean I'm all gung ho to program stuff, but I think that'd be a massive misapplication of my time with that title in my current job, and given my other responsibilities I'd only do it more slowly than someone with dedicated focus.
Maybe they set unrealistic expectations to see if the applicant lies about meeting them and give wrong answers to see if the person acts like a smartass.
terrible interview questions, that's why only technical people should be giving technical interviews. Most answers to questions are more nuanced than a straight quantifiable answer they have on a sheet of paper.
I had almost exactly this same engineering test when google interviewed me in 2006. It was terrible, and left a bad taste in my mouth. Given the complexity of the work I was doing at the time, the entire thing seemed ridiculous.
The inode question gave me flashbacks to my interview with Amazon. They wanted me to explain what a hash function is. I kept giving answers for about 3 minutes explaining hashing, common algorithms, reasons to use it and places it applies.
Recruiter: "I was looking for you to say it's a fingerprint"
So I guess I was wrong, because despite explaining them in decent detail, I didn't use the one keyword.
I know some hash functions are not meant to create unique fingerprints (they're to pick a bucket to put/look in), but what do you mean by the opposite of a fingerprint?
The goal of a fingerprint hash is to convert an input space of "large" values to an output space where the output space values are much shorter- typically fixed size and two similar input values have effectively random outputs (without spending the CPU cycles to implement a cryptographic hash). This permits a wide range of optimizations (a document can be fingerprinted, and looked up by its fingerprint, to see if it's a cache, has associated data, etc).
Thanks for the elaborate answer! I knew about things like acoustic fingerprints but not that people use the term "hash function" to describe something that indicates similarity.
Could something like Hamming distance be called a hash function too? It's not mentioned on its Wikipedia page.
it's worth reading and understanding the ideas behind LSH and hamming distance. there are some... fundamental mathematical relationshps there that are still being ... hashed out.
"The goal of a fingerprint hash is to convert an input space of "large" values to an output space where the output space values are much shorter- typically fixed size and two similar input values have effectively random outputs"
But this is also the goal of non-crypto hash function like those used in a data structure no? Basically mapping a large space of inputs to a smaller space of outputs.
I would say the cryptographic hash is one the that has "desirable" security properties, things like not being able to recover the original input message using the hash, a tiny change in the input causes a substantial change in the output, or that its very unlikely that two inputs will produce a collision.
both types of hash convert an input space to an output space where (typically) the input space is much larger.
What matters is whether similar inputs get mapped to the same output. For the case where you want to minimize the probability that two inputs which are highly similar land in the same bucket, you want a crypto hash, although those are expensive so you want a cheaper approximation, which is exactly what fingerprint hashes do. The problem is that as the input values counts approach sqrt(output value size), you're going to start getting collisions, and ideally, you want those collisions to be evenly spaced.
In the case of a similarity hash function, you want the opposite, the closer things are in some metric space, the more likely they end in up in the same bucket.
In someone is using words from level 2 that work together in the ways laid out, they're probably beyond level 1, and wouldn't use the word 'fingerprint' (in this case) - they're giving more detail (and probably better) than what was being listened for.
I've found the best way to answer those is "buzzword diarrhea"
first thing I do is try to get them to ask it a different way. then I play spew out every related buzzword possible as if its a question. Are you talking about .... oh, you mean .... I can usually get it in a few tries.
I'd have failed too, because I use a very particular way to describe a hashing function.
A hashing function is actually a sorting function. It's supposed to take an input space and sort it in an unpredictable and evenly distributed way across the output space. What's more, neighboring points in the input space, no matter the sort used to determine proximity should not result in neighboring points in the output space.
Fingerprinting is just an emergent value that comes from choosing fixed length hashes, and the fact that the mapping from input to output is stable.
On my phone screen a Google recruiter asked me "how much is 2^24", and I knew the answer by heart and answered immediately.
So he asked "how did you figure this out so fast?". I told him I didn't, I just remember all the "important" powers of 2. He said "well... that's not what I was looking for, I wanted you to calculate it, but... I guess a candidate who memorizes powers of 2 is a positive sign?". I passed.
haha, I got that question too, in stead I worked in MPLS for over 5 years, I know by heart that MPLS label has 20bits which translates to 1 million labels, times 2^4 that is 16 million. The recruiter asked me how I figured it out so fast, I explained to him, that recruiter had no idea of what I was talking about. I did not pass.
I got an interview with Amazon, but failed the first round, because I did not do well on the reasoning part of the online test. You couldn't skip questions, so I spent too much time on some of them and had to rush the ones at the end. They failed me despite getting the coding part 100% right.
Sorry, I only saw your comment now. They were asking stuff like finding patterns (like in IQ tests). Then they also had ones where you had to read text and then say what you would do with it based on certain requirements. You couldn't skip questions so I spent way too much time on the number ones.
I cannot obviously tell you the exact specifics because of the NDA.
I am curious what your opinion is of these? I personally find this practice loathsome. Was this something that happened after speaking to a human or was this the initial screening?
It was the initial screening and I was very upset that they rejected me since I did (very) well on the coding part but poorly on that reasoning test. If I have a good GPA at a Uni with a degree in Computer Science, then they can certainly assume that I can reason and there is no need to put me through a very strictly timed "IQ test."
Maybe I dodged a bullet there and Amazon would have been a bad place to end up anyway.
> Given the complexity of the work I was doing at the time, the entire thing seemed ridiculous.
I had the same a couple of years ago, at the time I was a Rails developer at a small startup. The first screening they asked me some basic technical questions (I guess it was a recruiter), then the second screening they asked me to walk through some data structures and algorithms off the top of my head.
I knew they would do this, and hadn't looked at any CS algorithms since university, so got a copy of Programming Pearls and studied through that every evening for the week before. I picked a few that I hoped would come up, and it turned out that's what they asked for. I think first a linked list (maybe doubly linked?) and then a tree sort.
I surprisingly passed, but the attitude of the interviewer really put me off. He said he knew Python, Java and Go - none of which I had used - and wasn't too happy when I said I wanted to use Ruby (which the first guy I spoke to, said was fine). Then throughout the interview it seemed very much like he was fighting against me and trying to prove me wrong.
After that I couldn't be bothered any more, I didn't really want a job at Google, it's just a recruiter contacted me and I decided to try it out. I guess this style of interviewing must work for Google, but it's just not the way I like a company to introduce itself to me. It just seems like they are approaching it with so much ego, as if I would be privileged to work there, but to me a job should be mutually beneficial.
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)
Director of Engineering is a soft-skills position that involves communicating with a lot of non-technical people. It doesn't surprise me at all that the initial screen would be a conversation with a non-technical person.
This hiring test makes me cringe. How is this any better than taking a multiple choice test in college? These questions asked should invite back-and-forth conversation like the author is providing, especially when the company is seeking out highly qualified candidates.
Sounds like somebody very butthurt that did not bother to do a quick search and see that first call is with a recruiter who knows little or nothing about technology and is looking for exact-word answers.
So apart from giving the right answers, you now have to intelligently predict when to give wrong or suboptimal answers to account for the inadequacy of the interviewer? Not that I'm blaming the recruiter here because he/she was just trying to do his/her job, but come on. If I were in his shoes, I would be pissed off not because of failing to land the job but because of being told that I gave the "wrong answers" when they were clearly right.
Dumbing it down and dumbing it down to precisely the words written on a piece of paper are different things. If the "correct" answer were simply any explanation that the interviewee understood, that would be entirely different and considerably more reasonable.
They asked me the same questions back in 2012. I was applying for a Java developer position.
The person asking the questions said right from the start that he is not technical (he was a psychologist) and that he had a cheatsheet in front of him.
I passed that telephone call and failed the process later on another call (on the lightbulbs and the 100 floor building)
Really surprised to see that 4 years later they still do this.
This is really weird and should not be happening. I am a software developer and do a lot of interviews including phone interviews.
These kind of questions are not expected, but I would say the lightbulb one is not super horrible as long as it is the discussion that was valued and not the answer. I have gotten weirder questions for sure when interviewing.
I didn't hear about the light bulb drop question until this thread, and was surprised how in-depth it can go.
Can you really "fail" an interview on a question like that? I assume the person conducting the interview is reviewing your process of coming to an answer rather than getting the most correct answer - right?
In theory, that's basically the idea of most questions asked during interviews (except maybe very basic CS ones). The idea is that they will look at how you approach the problems. If you already know it and spew out a memorized answer, it's much less interesting to them than if you've never heard it before and you approach it with a clever way (even if you don't get the answer).
It makes sense if they want a firewall from the public, a legally defensible position, while behind the scenes they hire via other channels ( close friends )
That's really interesting that he said he was a psychologist. I am probably giving them too much credit, but maybe they rare screening for personality with this test and not for technical knowledge. If you handle a frustrating and difficult situation gracefully, perhaps how many answers you got "correct" is irrelevant?
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. You end up with stupid discussions like the one about Quicksort. If you point out qs is one of several things with the same big-O, you'll probably also get it "wrong". But the real problem is that a guy who is just reading off a sheet can't give any form of nuanced feedback. Was the guy blagging the sort algo question? Did he know if in detail? Does he know what the current state of research on that area is? There's no way to know that if your guy is just a recruiter, but I'm sure even a relatively junior coder would be able to tell if someone was just doing technical word salad.
I wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face.
It tends to be incredibly helpful to know details like the length of a mac address and what tcp flags mean what if you're looking at an unformatted memory dump.
One example of how this can be handy is when doing low-level NIC bring up, I've read PCIe TLPs from a logic analyzer to correlate them to network traffic.
I bet you spent more than 30 minutes (typical phone screen length) looking at TLPs. Spending 2 minutes to google DLLP/TLP packet structure is not unreasonable.
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 of being a practicing programmer; knowing how to find out is.
This strikes me as an entirely trivial point, the meaning of the question was pretty clear. It wasn't "what is the literal return value". Many APIs will return error codes, and people still talk about them as "returning" certain values colloquially. Of course, if the OP's answer would've been "it returns an error code :) but I assume you're talking about..." I would think that's fine.
Btw, that is the only thing I really disagreed with OP on, the rest seemed just ridiculous.
There's a precise distinction, and thinking about it as "returning" anything other than an error code is chummy human thinking rather than the sort of precise knowledge the test was (supposedly) looking for. The question was actually worse than asking "I'm thinking of a number between 1 and 10, what is it?" because rather than applying a random filter to candidates, it punished the candidate for having precise knowledge.
The difference is memory management, completely different. Don't ask me for a function that "Returns" something in a technical interview and when I call you out on it say I'm wrong, when I'm not.
It's a technical interview, the question should have been technically correct. "What function passes by-reference copies of inodes?"
My worst offense of this was for a linux admin position when asked from another abmin about how to list connections on a machine. My answer was "lsof -i, since I've found it's easiest to pull granular information."
"lsof just prints open files... you would use netstat, not lsof."
I tried correcting him, but he wouldn't listen and ended the call soon after.
Most people don't know that lsof works into two modes- the typical one is to run it against a process ID. The rarer one is no args, which runs it against everything on the system. however, I observe that lsof needs to run as root to print the same information that netstat -tanp returns for a reglar user.
Yeah, you're right about needing root (edit: for processes not owned by the current user). Though, if you have the access, it's a very, very worthwhile tool to learn:
~ $ lsof -a -n -c chrome -iTCP:443 | head -2 #sanitized output
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chrome 1234 me 12u IPv4 12345 0t0 TCP 127.0.0.1:12345->127.0.0.2:https (ESTABLISHED)
Yes, but we are all chummy humans with our chummy human thinking :) We are generally gifted with the ability of shorthand, context, and understanding that surpasses a purely technical understanding of words, and this is exactly the kind of situation where that helps.
I personally wouldn't want to work with someone who wasn't able to understand what I mean (in such an obvious case, at least) and wasn't able to answer to that meaning.
(Of course, I'd also personally prefer someone who would point out that this is inaccurate, but do so in a charming and off-hand way, to make me feel comfortable. A high bar, maybe, but for a director that's definitely a bar they should clear).
I can't disagree with you enough. Engineers should always strive to be as clear as possible about what they're doing. The word "return" has a precise meaning in the C language. If the recruiter was unaware of that, that's their bad entirely.
Actually, OP replied exactly as he should because after the first few exchanges, you can tell how anal the interviewer is and as such you have to answer accordingly. Some easy going interviewers might say that its about right, some might say its technically right, etc.
Remember, you have to walk through the interview thru OP's mindset and how he took into consideration the interviewer's analness.
On the other hand, you are interviewing a programmer. Their daily life revolve around technicalities where the difference between returns and fills matter a great deal. Expecting them, all of a sudden, to throw that out of the window and parse technical questions in a hand wavy way is ridiculous.
But not if you're a literal lunatic who thinks that because you literally used the word return with an error code that's what it returns. And. Only. That.
To be fair, the rest of the questions were demonstrably pedantic, and I would completely expect a question like this to be on the bill of fare:
Q: What does lstat return?
A: A struct
>> Wrong, it returns an error code
That type of technical specificity about what well-known functions return is absolutely something I've heard people use as an interview question. Knowing it returns an error code (rather than the value you want) seems like a good indicator of "has actually coded in C" (whereas many other languages return the value you want and raise an exception if it had an error).
>In C, what stat does is how you return multiple values from a function.
IIRC, you can return structs from functions in C. You have to access the values in the returned struct with dot notation, of course, like point.x .
Pre-ANSI C may not have had this, but later, it did. Remember reading it in the 2nd (ANSI) edition of the Kernighan & Ritchie C book, and also used it myself in some programs.
I think the problem was that he didn't update his knowledge about what an inode is after the interviewer told him. He still thought it was an integer value, as opposed to a metadata structure. If inode meant inode number, it works be reasonable to assume there was a function that would return it.
Somebody sack the writer ;) - so, OK, I doubt I'd argue the toss if it were an interview situation. But when writing a comment or documentation I think I'd take inspiration from the documentation for either of these two fine systems.
OS X: (OK, so I lied about the "fine" part)
The stat() function obtains information about the file pointed to by path
Windows, here the VC++ CRT - fantastically poorly described, if you ask me, though of course you shouldn't be using any of this POSIX shit on Windows, so if it confuses anybody enough to make them go and find FindFirstFile then it can only be a good thing:
Ask Jeeves? Being able to find it in a book might be useful, but when Google is down I bet they would like to get things up and running as soon as possible.
I lost it at this one. As if there is some single point of failure that's going to bring all of Google down, and some intrepid director of engineering has to inspect some TCP packets by hand to fix it.
This is where I threw up my hands too. The Director of Engineering does not need to know the difference between SIGTERM and SIGKILL, or how many bytes are in a MAC address. I guess it's a nice bonus if he does, but he'll spending 10 hours per day in meetings talking about roadmaps, shielding his team from the execs, and removing productivity roadblocks. "Third engineer from the left" is doing the packet inspection--ask HIM about SYN and ACK.
Reading more closely, it sounds like they are not interviewing him for a director of engineering position; it just sounds like he thinks his current role, CEO-who-writes-code of a very small software company (http://www.gwan.com/about), qualifies him for a director-of-engineering-level position. He's probably being interviewed for an SRE team lead or thereabouts.
Why he's being interviewed for that position is a different question entirely, and I can imagine Google being totally right or totally wrong.
How can you imagine Google being totally right here? The disconnect between the questions being asked and the interviewer's lack of knowledge made the interview a waste of time no matter WHAT role they are interviewing for.
Take, for example, the sorting question. "Why is QuickSort the best sorting algorithm?" The answer being looked for was, "It has the best Big O."
And this is wrong. Its average case is O(n log(n)). Its worst case is O(n^2). Which do you call its big-O? Moving on, the average case of O(n log(n)) is matched by a wide variety of sorting algorithms. How do you choose one?
Here is a better answer.
QuickSort is a very simple to implement algorithm which achieves the lowest average number of operations on a randomly sorted list. Which is why it is so widely adopted despite sometimes being very slow.
However Timsort appears to be the fastest general purpose sorting algorithm for the mix of random and partially sorted lists seen in practice.
When I tend to notice that sorting is slow, generally that's a larger workload where some type of merge sort would be appropriate.
I can imagine Google being totally right because I can imagine the interviewee not accurately remembering the conversation here. (I expect, for instance, that he did not write down the interview as it was happening.) In fact, conditioned on the assumption that Google is right that this guy's experience is better suited for SRE than director-level, it is pretty likely that he did not understand the questions being asked / thought the questions were beneath him / etc. and therefore wrote them down inaccurately.
For instance, perhaps the interviewer asked "What makes quicksort a good sorting method," instead of "What makes quicksort the best sorting method"—a very small difference in phrasing. In that case, the answer of "It's not always the best, or even suitable" is still technically true, but much more wrong. (And an answer like the one you started with, "Its average case is O(n log (n)), its worst case is O(n^2)," would have been enough to pass... but sitting on the phone and arguing about storage topology is itself a failure.)
As I mentioned in another comment https://news.ycombinator.com/item?id=12702130 , my (five-year-old, faulty) memory of Google's SRE phone interview is that they asked another question here with a very small but important phrasing difference: "What is the signal sent by the kill command" instead of "What is the kill signal". If you make that change, the interviewee's answer of "SIGKILL" becomes wrong, and the interviewer is right to insist on SIGTERM (which would otherwise make no sense). It is a quite literal game of telephone.
(Again, I can also imagine Google being totally wrong and the interviewer mangling the questions.)
You are right that several of these questions could be due to his misunderstanding the questions asked at the time, answering the wrong one, and then remembering what he thought he was asked. But it is beyond my imagination to reconstruct a plausible conversation that could result in the one recorded without there being considerable ill will on both sides.
Here's a thought experiment: read the article, replacing the interviewer-side questions with ones that make them sound more plausible. (This is the side that we should believe to be less accurate, if only because the interviewer isn't reporting their questions.) Pretend you're the interviewer, and ignore the internal monologue.
For question 5, you asked about an inode, and were told about an inumber, and got back an answer insisting that the inode was an index.
For question 6, maybe change "inode" to "information in the inode". The interviewee still has not figured out the distinction between an inode and an inumber.
For questions 7 and 8, apply the changes I suggested.
At what point do you decide that the interviewee is hopelessly arrogant and not worth your further time? And how do you get them off the phone gracefully?
Maybe around question 10, when they're quoting bits to show off and not saying the words that would actually let them communicate with other engineers like "SYN" and "ACK"?
No ill will is required on the interviewee's side, unless you consider refusing to waste time on bad candidates "ill will".
The conversation that I'd have to reconstruct has a very combative interviewee. Which would also fit said interviewee deciding to write up the article that I read. Which would mean that Google dodged a bullet.
I find it interesting to note that his site is down. There are a lot of possible causes, but it isn't good advertising for his webserver software.
> they asked another question here with a very small but important phrasing difference: "What is the signal sent by the kill command" instead of "What is the kill signal". If you make that change, the interviewee's answer of "SIGKILL" becomes wrong, and the interviewer is right to insist on SIGTERM (which would otherwise make no sense).
But... the kill command is the command to send arbitrary signals. It sends them all.
> Its average case is O(n log(n)). Its worst case is O(n^2). Which do you call its big-O?
I know this is irrelevant to the larger point of your post, and I'm sure that you know this already, but the worst case is the big-O. This is just another reason why "big-O" is not the most helpful thing to discuss in practice.
Big-O is a way of categorizing the growth of mathematical functions. Those functions can represent anything. It is wrong to talk about the big-O of an algorithm without specifying what you are measuring. Be it average operations, worst case operations, average memory, worst case memory, amortized average time, amortized average memory, and so on.
It happens to be that when we talk informally, we're usually talking about the worst case we are willing to think about. Quicksort's worst case is a sorted set, so we think of that as O(n^2). But then we turn around and cheerfully call a hash lookup O(1) because its O(n) worst case is incredibly rare in practice.
Apologies. Throughout my CS undergrad I had only been given the impression and understanding that Big-O measured worst case (lower bound, no worse than), Big-Theta average case, and Big-Omega best case (upper bound, no better than). Looking into it more now, I see that there are some more subtleties I either missed in class or was never taught.
The subtlety here is basically that big-O and big-omega and friends are ways of characterizing functions, and functions map one input to one output. "Running time of a problem of size n" is not a function; it has a range of possible values for a given n. "Maximum running time of a problem of size n" is a function. That function itself, an² + bn + c for some constants a, b, and c, has lower and upper asymptotic bounds.
I thought you were right at first but then realized what was going on. This is a pretty subtle point and mostly uninteresting for well-understood algorithms like quicksort. But one slightly less subtle point is that big-theta isn't average case, it is the combination of big-O and big-omega, i.e., bounded from above and below (possibly with different constant factors) by the same asymptotic behavior.
If they are trying to hire for a position that will somehow be on the line for what happens when all of Google is down, I for real hope that they get some higher-power questions into that interview.
Not agreeing with the recruiters attitude but "if Google is down you will need to know this to diagnose what the problem is." was his comment.
In that case the developer should have cheat-sheets printed on their desks.
He wouldn't need to know it for the job, but as others have said he probably would know it if he really had the experience on his resume. That's the value for me sometimes in questions like that, especially in an initial phone screen, to decipher if you're bullshitting or exaggerating your credentials.
"I knew all these answers too, because I was a developer in the 1990s."
I think you're onto something greater. Maybe Google should hire more smart people who were developing in the 1990's as they're a nice, middle ground between ambitious, young folks and the been-there-done-that greybeards. Them realizing such people already know all the shit they're trying to teach their developers might be way to sneak older people into these tech firms. Haha.
Technically stat neither returns nor fills in the inode, because the actual structure of the inode can vary by filesystem, and the inode will contain more fields than struct stat.
In a recruiting situation, if the recruiter is going all "right and wrong" on the interviewee, they should know these dirty details.
I also disagree on the ethernet address length. You know how long IPv4 addresses are, you know how long IPv6 addresses are, why would it be so extraordinary to also know how long MAC adresses are?
I think it could be useful to find out in an interview whether the applicant knows stuff because they have actually implemented low-level code and gained an intricate understanding, or whether they just did used some high level APIs and were never interested in more details than "I have a handle right here, it does all I need". For some positions that would be an important distinction.
Personally, if I were interviewing people, I'd hire the guy that explains something to me that I did not know, but that I find interesting and would have attempted to understand, too.
> his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth
While I agree, I have seen interviewers where if he answered "fstat" they would have come back with "Wrong! fstat passes the structure back by reference, it does not return it!"
With this style of interview I can't blame him for thinking it might be a trick question and then trying to explain why he didn't say those other functions as an answer.
I don't think these questions are unreasonable as a spam filter. Yeah, they're trivia, but if you had actually worked in that space, I'd be surprised if you didn't know a lot of that trivia just by virtue of exposure.
The rejoinder, of course, is that it's probably misguided to structure your recruiting around a spam filter.
I agree with the first and second sentence. As to the third: what would be your thought process as to someone who claimed to be a network programmer on the phone but couldn't answer most of those questions?
I'm a network programmer and I forgot exactly how long an Ethernet address is. (I would have guessed 6 based on memory, but I wouldn't be 100% sure.) It's an opaque structure to me; if I need the size I'll sizeof it, which is clearer anyway.
Maybe I'm a bad programmer, but I don't feel like I would be a better one with that specific fact committed to memory. I dunno.
I do plenty of interviews, and so I do have some sympathy for the idea that some overwhelming majority of applicants simply cannot perform even the most basic coding tasks but are somehow trying to sneak in anyway, but at the same time I can't escape the suspicion that a lot of the stories are actually from badly-designed or badly-calibrated interviews gone off the rails.
I absolutely believe that the article we're discussing here gives a fair view of a Google phone screen, since I've been through it too and even got asked some of the same questions. The only reason I "passed" was that I recalibrated way, way down to meet the expectations and the technical understanding of the recruiter I was talking to (who did very clearly seem to be reading off a prepared script). This was surprising since Google had reached out to me to ask me to apply, which one would think indicates a confidence in basic technical skills, but if I hadn't caught that and adjusted how I was interpreting and answering the random trivia they threw at me, I likely wouldn't have passed the screen and would have been labeled just another impostor trying to sneak into a job I'm unqualified for.
So when I hear someone else talking about all the "unqualified" applicants they get, I can't help wondering how many really were qualified applicant talking to unqualified interviewer using unqualified interview process.
(disclosure: I don't work for Google, don't ever intend to work for Google, and in fact hung up on a later screening call out of frustration with the way they ran their process, which at least finally got their recruiters to stop spamming me)
I think you can probably predict it: I would generate a work-sample test for it. For a network programmer, I might have them implement a 3WH coded directly to pcap_write() (which requires you to populate the Ethernet frame header). Like the best work-sample challenges, doing a raw 3WH is kind of fun if you haven't done it before.
My friends and I used to spend bar nights drinking over torturous interview questions (yes, I have always been this nerdy). For instance: we had a gruesome sequence of questions on how to implement the fastest possible traceroute that you could only clear if you knew about a trick using the IP timestamp option.
Later, I got (what I thought was) smarter about interviewing, and moved to more surgical questions. I'd ask candidates to debug a C program that segfaulted in malloc, or ask them to describe the utility functions they carried with them from project to project.
After taking over recruiting for a company that really needed to hire at a specific clip in order to balance sales and delivery, I'm embarrassed that I thought I was interviewing effectively with stuff like this.
You can't learn about someone's capabilities by putting them on the spot with trivia questions.
> You can't learn about someone's capabilities by putting them on the spot with trivia questions.
But that's not the point of these questions. These questions are a 5-10min phone pre-screen before getting to the actual interviews. They test if the candidate has experience in a given field, not if they can search for information or what are the precise bounds of their capabilities.
It's trivia, but it's trivia that is a reasonably high confidence proxy for experience in e.g. network programming/design (resp. other fields). If someone claims they have networking experience and don't know SYN/SYN-ACK/ACK it's in my opinion a large red flag.
These screens pass people who can answer trivia but who can't effectively code, and they reject people who have a gift for solving engineering problems with code but who can't answer trivia questions when put on the spot.
The ostensible reason they get deployed (I say "ostensible" because we all know that in reality the on-site interview consists of the same stupid kinds of questions) is to keep the employer from wasting time conducting more sophisticated interviews for candidates who have no hope of passing. But that's dumb for at least two big reasons:
* The filters obviously reject candidates who would do well on more serious challenges --- worse, they do it insidiously, because you can't tell that they're rejecting good people, only that you're seeing fewer bozos, which makes them look like they work. In reality, a new norm has arisen where the most qualified candidates get to skip these processes entirely, because we all know they're a crap-shoot and don't want to lose good people.
* Properly administered work sample challenges actually take less employer time than these stupid trivia screens do. That means there's literally no purpose to the trivia screens whatsoever; they do nothing but harm.
In my last comment, I just wrote off the top of my head a sketch for a work sample test that addresses the same concern as the dumb TCP/IP trivia quiz from the original post. It took me I think something like 30 seconds to come up with it. Think about how you'd score that (remember: the bar here is "must be more predictive than that dumb trivia question"). I'm thinking something along the lines of "run the code and see if it opens a new TCP connection".
Assuming your team has enough sophistication to build work sample challenges like this, try to justify the trivia interviews. I think you can't.
> These screens pass people who can answer trivia but who can't effectively code, and they reject people who have a gift for solving engineering problems with code but who can't answer trivia questions when put on the spot.
SRE's are hired to fix outages and other problems asap, knowing trivia is very important then since at that point you might be losing a million dollars per second.
Thanks for the detailed response. Frankly, I was awful at recruiting: grilling candidates who claimed to know C++ on the intricacies of templates or whether they knew what Koenig lookup was. Caught a few fibbers but I don't understand in retrospect what the point was.
What's bogus about his comment on stat() exactly. It literally returns an int and fills in the struct that it takes as a parameter. If he had no idea what it did he could check Google or the man pages which are going to give him some variety of the same answer such as the two examples below.
Linux:
int stat(const char *path, struct stat *buf);
stat() stats the file pointed to by path and fills in buf.
Mac OS X 10.11:
int stat(const char *restrict path, struct stat *restrict buf);
The stat() function obtains information about the file pointed to by path.
Read, write or execute permission of the named file is not
required, but all directories listed in the path name leading to the file must be searchable.
It may be pedantic but stat definitely doesn't "return" an inode. One of the problems with technical interviews like this is you often have no idea what the interviewer is really looking for. Some might just want to know what you would use to get the information about an inode and another might be seeing how you describe it as a test of your knowledge of pointers or something. Often it's impossible to know and that could have been easily a trick question where the right answer is "there isn't one but you can use stat to get this information as it takes a struct pointer and will place the information into that struct". Of course you know that better than most or you wouldn't have made stockfigher.
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 shocked how many that know such things. :-)
And then, the world developed robust, well-maintained, open source libraries that do all of that for you. Now, in 99% of commercial software engineering, you don't actually need to know any of those details, in the same sense that you no longer need to know exactly how many transistors and diodes are used to build the adder on the CPU. It simply no longer matters in almost all cases. Your time is much better spent moving on to higher level problems.
If you're interviewing for the rare 1% case where the job will actually require you to tinker with a TCP stack, then by all means ask about those details. For 99% of programming jobs today, it's irrelevant trivia used as nothing more than an ego measuring device.
I feel like I've seen 2-3 articles alone in the last month that has rediscovered head-of-line blocking and UDP. I'd say 1/10 engineers I talk to even know what cache aware datastructures are.
The thing that separates someone who can just string together whatever they find on npm to people who build real systems is this deep understanding. You're not going to need this for your standard LoB apps. However if you're in the business of building software you're definitely going to want people like this.
There's a vast middle ground between stringing together npm and rewriting the TCP stack. Most jobs that exist today fall firmly in that middle ground.
Trying to find the TCP stack engineer to build your app is like hiring a petrochemical engineer to do oil changes. If your pockets are as deep as Google's, yes, you can do that, but it's by no means necessary.
"And then, the world developed robust, well-maintained, open source libraries that do all of that for you. Now, in 99% of commercial software engineering, you don't actually need to know any of those details.."
And that, ladies and gentlemen, is how we ended up with npm.
Whatever this thing... this... stringing together a 100 random github projects to get a webpage that kinda of works about 80% of the time is called -- please let's agree not to call it "software engineering".
You are jumping into conclusions too fast. There are plenty of good software engineers who work with high level languages and technologies on a daily basis. You just have to know your tools, no matter what you do.
Yep, I was doing network programming back in the late 90's and you pretty much had to have a good grasp of winsock and linux network calls and responses because the level of abstraction was much lower.
That said I can't recall any of that stuff mattering in the stuff I do for work for quite some time and most of it is a google search away.
That interview was just weird, it was like asking the boiler pressure for a steam train to someone who was a master engineer working on electric trains.
The amazing part here is that so many people still remembers all those little details. I still know how it works, but honestly I forgot all the details long time ago.
A lot of it depends on what you do day to day. A year ago, I knew what a MAC address was, but in an abstract way. Today I automatically know it's 6 bytes long because I look at them every day.
Is TCP/IP Illustrated still the gold standard of books on the subject? I read it fifteen or twenty years ago and would like to finally own a copy (I borrowed it from the library), but not if there is something better.
Applicant Doctor: "They're double membrane-bound organelles found in all eukaryotic organisms, commonly between 0.75 and 3μm in diameter, that generate most of the cell's supply of adenosine triphosphate"
Recruiter: "No. They are the powerhouse of the cell".
"Well, it depends what color model you are using, which differentiates between additive and subtractive color mixing, the medium used (print, screen, etc.)...
I legitimately had a huge argument with my (former) roommate over primary colors.
She was more artsy, I was insistent that the primary colors were RGB, she was insistent that they were RYB. We googled. We were both right in some senses.
Hilariously enough, my fiance now works in printing and actually mixes the colors (t-shirt printing).
I haven't brought it up yet because we once had a fight over whether that thing you put outside your shower is called a bath mat or a bath rug (Both are correct in different circumstances)
Not sure how much you're kidding, but... that's true for a subtractive colour system, where you start with a white sheet of paper (i.e. reflects every wavelength) and subtract colours (filter out wavelengths) by painting over the paper with crayons. For an additive colour system, where you start with a black monitor screen, and you add wavelengths, the primaries are RGB.
...and, strictly speaking, the subtractive colors that closest match the typical human eye are cyan, magenta, and yellow -- the "CMY" of CMYK printer inks. Using red, yellow, and blue as subtractive colors gets you a big enough gamut for elementary school color mixing, but it won't give you as big a range of colors as CMY.
Totally off topic (except for the fact that "correctness" of an answer can be a deeper problem than checking against a list) but when you look at how the cones in your eyes are connected to the brain to actually transfer color information it's indeed closer to Red-Green/Yellow-Blue (as described in Lab*). That's why we intuitively include yellow as a "primary color" even though you can just use RGB to describe it.
To be entirely objective, I have run into recruiters of that variety in my career. However I've also had plenty of recruiters that were able to pick up on one's deeper knowledge of a given concept and accept that as correct, even if it wasn't the "textbook answer" they were looking for.
You don't even have to give feedback in an interview. Just let them answer your question and if it's too detailed, write it down and look it up later. In fact, Google usually doesn't give back any feedback during or after their onsite interviews.
everybody who is a doctor aced intro to biology because they were premeds. That means they looked at plenty of cell bio pictures with mitochondria (properly scaled to the cell size).
Doctors know a ton of random crap tangentially related to their jobs that they were forced to memorize.
"I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are?"
This isn't even my domain, but I remember some of this stuff. I had to dig in to this area years ago, and was knee-deep in that level for several months debugging and configuring stuff. Some of it stays with you, even if you're not there any more.
For someone applying for a director of engineering, I'm kind of split as to whether this should be required "off the cuff" knowledge. Would certainly help, but seems it would depend on the culture of the company - how hands-on they expect director-level folks to be - some companies seem to want that, some don't.
>...but I'm sure even a relatively junior coder would be able to tell if someone was just doing technical word salad.
In interviews, I've had people give answers I'm not familiar with. The easy thing to do is to ask them to explain how their answer works. You get to vet whether it seems legit, and as a bonus see how good they are at communication in a genuine teaching moment.
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 recruiter take careful notes, asking the candidate to repeat if necessary, in the cases where the candidate insists they know the answer.
Then only in cases where the candidate can't answer a question should it be marked as "wrong." In other cases the answers should be run past someone knowledgeable.
I've gone through a phone interview with Google myself, and it was nothing like this: I spoke with a real, skilled engineer, and there was nothing like a "gotcha" question where I had to guess the exact term he meant. Well, except where he asked "I bet you know what my next question is" and I didn't guess "How can the algorithm be faster?" But he didn't count that against me. :)
My presumption was that, for whatever reason, they couldn't or wouldn't do screening at this level by technical interviewers. Obviously having a technical person do the interview is always better.
I may have gotten a technical interviewer because I can list a half dozen people who know me who work at Google, most of whom can directly vouch for me.
Not sure why the OP got an unskilled reviewer, but if they didn't list references inside the company, they may have been thrown in the "random unknown applicant" bucket.
I've been responsible for writing network code on embedded systems, you do end up memorizing lots of the structures and constants from the specification because you're constantly looking at them "on-the-wire" to make sure it's write (or debug it if it's wrong).
I'm just reaching here, but is there a chance at all that the test wasn't really about whether or not he knew the correct answers but more that he knew the correct answers and was able to simplify them to the extent that a non-technical user could understand and compare them? I have a feeling that Google is far more interested in someone being able to get their point across than someone that just wants to sit there and argue about whether or not an answer is right. Just based on reading his responses, I got a condescending vibe and a vibe that this guy always has to be right and would work terribly with people of different levels of skills. At a Director-level position, that kind of skill is the most basic skill you need to have.
That's not the problem, a non-tech recruiter cannot assess the correctness. Even the simplification can be done, which I disagree, the answer will be rejected because it's not a literal match. That, is the problem.
Yeah I agree. I think one issue is also the test. For a lot of these things, as with most things, there is a short answer and a long answer. I think by the second or third question I would have picked up on the fact that the recruiter didn't really know what he was talking about and was looking for the short textbook answer. Seems like the author refused to or couldn't do that.
That's not the point of the test. The point of the test is to see whether or not the person attempted to get on the level of the person they were talking to. I have a feeling that the interview would have kept going had the author not started to argue. They're looking for someone that can translate, not someone that will talk down and argue just so that they can be "right".
I did not see any argument here from the statement in the article. The recruiter clearly had little clue about what is right and wrong. And the way the recruiter assess the answer by throwing right/wrong seems more rude to me compared to the author "wanting to be right".
Please do not speculating based on something that is not present in the article.
I had done similar interviews before, the recruiters I worked with did not show the same level incompetence as this one. When I want to be more specific on details, they would suggest that they think it's enough and move on. Not like this recruiter who just throw a 'wrong'.
I'm not speculating. This all took place during a phone call so the post is completely the interpretation of the author with regard to how the recruiter answered the questions. For all we know, the author just paraphrased everything as "That's wrong" to make the recruiter look like a simpleton so that they themselves wouldn't look silly for not passing. We have no other information except for 1 side that happens to be the author's side. Others have commented that they took this same test and were told after that the person doing the interview was a psychologist that wasn't testing technical skill. That's where my speculation is based.
No, I'm talking about the person that wrote the post. Since this was a phone interview, this is a paraphrase of what happened, written by the post author. The whole thing smacks of "I knew way more than that person, they were clearly an idiot".
It strikes me as more along the lines of "I knew way more than that person, and they were completely oblivious to the fact that they didn't know this stuff, AND they were in a position that required them to know stuff."
I'm fine working with non-technical people (or who don't know any given field), but I wouldn't be fine working with those people if they were insistent that they did know about these things about which they actually had no clue, or if they were in a position where they really need to know this stuff.
I have coworkers who don't know how to use the command line, but they aren't engineers and they don't try to tell me what commands to run when I pull up a console, so it's fine. If they keep insisting that I should use "dir" and that "ls" is wrong, that would be a problem. If they were the CTO, that would be a problem.
When we hire engineers for customer support, the non-technical operations guy interviews them, but he always has at least one engineer do a portion of the interview because he knows he's not fully qualified to judge someone's technical chops.
The OP isn't being condescending just because someone didn't know stuff. It's because someone didn't know stuff, but because they acted like they did. You want to be insufferable, insist you know better than the experts in a given field.
I don't think that's the point, though. The answers and questions are meaningless to the test. It's how the person addresses the questions and answers that matters in the test. Someone else posted that the person interviewing the author is typically a psychologist in this test. That, to me, means that the technical correctness of the answers is not relevant and that an actual technical engineering screening comes after it's determined that the person is a culture/personality match.
I can't fathom a scenario where a tech person would need to dump down something like SYN-ACKs and iNodes for a non-technical person. It's one thing if you are trying to explain performance trade-offs to non-technical users or colleagues. But not lower level protocol details.
> I wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face.
The medical recruiter asks to see the diploma. The doctor shows his degree and gets the job.
Eh, that's really oversimplifying it. Yes, DOs are taught some fringe-ish things. But the rest of their education is very comparable to that of an MD. I expect in the long run that many of these quacky aspects of the osteopathy curriculum will quickly vanish.
> I mean who would know just how long a MAC address is?
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.
> 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.
That is why you know the answer. Come back in 10 years and let us know if you still know it. What you think might be mainstream in a computer science class are rarely used in application. And if they are they can be easily looked up.
I used to know the exact effective distance of a CATV cable when I was a student. Useful? Sure. Something I need to remember for the rest of my life? Definitely not.
As another example, in 17+ years writing ISO level 7 programs, I have never once needed to use the Mac address.
> Come back in 10 years and let us know if you still know it.
I've never taken a CS class, and I still know it. I've just stared at enough packet dumps and debugged enough issues that it happens to stick.
I think it's a stupid question to ask as a screener, as it tests familiarity with trivia. It's the kind of thing I'd be happy to see that somebody knew, but it's never something I'd downcheck them for not knowing. It could just mean, as in your case, that there deep knowledge is somewhere else.
> I've never taken a CS class, and I still know it. I've just stared at enough packet dumps and debugged enough issues that it happens to stick.
We are all a product of our environment. And there is certainly a chance in 10 years the OP will still know how many bytes are in a MAC address. I only mentioned computer science based on the "student" part of the quote.
Personally I've been spoiled by working on higher level stuff so if I do look at a packet dump I usually filter the packet headers out. But again, we're a product of our environment and asking questions that a reasonable skilled engineer might go their entire career without knowing the answer to except in that interview is a bit suspect and will likely disqualify people that would be otherwise great for the job.
I don't have the length of a MAC address memorized (because why would I need to?), but I know what one looks like, so I can pretty quickly work it out in my head. A hex digit is four bits...
Maybe 10 years from now I'll have forgotten everything about the hex/binary/octal representations of numbers, but I certainly hope not!
The point still stands though. First, it is much easier to have side projects when you are in school so the causal relationship might still be there just one step removed. But the more important point I was making was that school or a side project or even a project at work, if people go 10 years without using it, they forget things.
As an aside, you may want to drop the "Uh" in-front of your sentences. It conveys a certain tone that I'm not sure you are doing intentionally.
> 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.
Thanks for the refresher! I knew that too when I was in college. Good luck remembering that 5 years from now :)
Still know that 20 years down the line, but then I do networking stuff routinely. If the candidate was interviewing for anything network related (the article is down atm), it's fair game.
I did not learn this because some course demanded I learn a text book by heart. I'm not doing that kind of theoretical university. I knew that particular thing because I look at a lot of packet captures.
My father is a civil engineer and late in his career, he interviewed for a senior position at a construction company. He figured out that the interviewer didn't know what he was talking about early on the interview and confronted him with that. The interview came to a end, he was put in touch with a senior engineer at the company. He didn't take the job for other reasons. I don't think this kind of rubbish would fly in any other industry.
A professional engineer is not someone who professes to be an engineer. S/he is a "professional" per certification by "established" "institutions" within an "industry".
This is interesting. Is this similar to things like the bar council for lawyers? I don't know if there is something similar to this in India where I'm from.
I'm amazed people actually believe the account is accurate. The guy failed the interview, and goes to write a blog post to lash out at google (and try to mess up future interviews for them), So of course he write it to make him look good, and the questioner bad.
We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time.
Come on Hacker News, I know you hate recruiters, but do you really think that happened?
It's true this is probably not exactly what happened, but Google does certainly ask these questions in phone screens and the interviewers read the correct response off of a cheatsheet.
The fact that several Google people posting here literally can't believe this is true shows how fucked up their process is.
The fact that several Google people posting here literally can't believe this is true also may mean it isn't true. Not that the questions weren't asked by a recruiter with a cheat sheet, but the quality of response and the attitude of the recruiter has been grossly exaggerated.
"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?"
I was more impressed by how simply he explained many of them in real-world terms. Especially countering Big O. That plus what he's already built indicates he's exactly the kind of person to direct the sort of projects they're building. That they filtered him with this garbage Q&A speaks volumes about Google's ineffective hiring. Plus, indicates what kind of people might have made it into the organization.
Actually, most people with a networking background would know this kind of detail (and more). It's the relevance (and appraisal of answers) that is shocking.
1) His level of knowledge is reasonable for someone who does networking programming full time
2) We are getting description from him. When I interviewed at Google, they asked me to prove that P is equal to NP, and I did, but they said that it took me longer than allotted 45 minutes and I didn't get an offer.
I've been looking at them on NICs, adding them to DHCP databases and using them for simple authorizations in iptables (and prior equivalents) since, oh, 1992 or thereabouts. They weren't new then.
It would take me a moment to count them in my head, that's all. "aa, bb, cc, dd, ee, ff -- that's six bytes".
I was interviewed once by someone who would cut me off after just a sentence or two. He asked a fairly open question like, "Tell me about hash tables." I knew I should have just said, "Lookups are constant-time," but I started off with a description of their behavior instead, and sure enough he cut me off and said, "Lookups are constant-time." Some people are just not very good interviewers, but also some tech people's rules are too iron, with no exceptions, like they can memorize but not think. They say interviews are a two-way communication, and that one certainly was. :-)
It's actually pretty sad. It seems to weed out the smartest folks so that you only hire those mediocre enough to not understand these problems within the hiring test.
Personally, these questions and the way the recruiter asked them reaffirm my view that Google would not be a place I'd like to work at as a experienced software developer. First the recruiter's lack of technical knowledge points toward a beaurocratic or management first mindset common (necessary?) in such a large company. Second, the questions and expected answers seem biased toward just graduating but smart engineers who don't actually have experience to realize the subtleties present in complex systems. The recent lawsuits regarding age discrimination reinforce the notion that this interview setup is biased (intentional or not) toward inexperienced and thus likely younger applicants. Perhaps that's not a bad thing per se as Google's corporate development style likely would handle inexperienced but smart developers who can "mold" into the system better. Or it could be more nefarious as to lower salaries by getting younger devs. In reality, probably a mix of both.
I wouldn't be surprised if the interview process for experienced engineers is unrefined.
At this point in Google's lifecycle most of the qualified, experienced engineers who would want to work at Google already do. There are orders of magnitude more new-grad engineers to interview and so it makes sense that they would lack the practice and refinement on those candidates, even if those are the most valuable candidates to hire. The recruiter might have just been confused and gave him the standard list for any "technical" job that they have to use for new-grads and so cannot ask things with nuance.
When I was an interviewer at Google it felt like 90%+ of interviews were with candidates who had less than four years of experience. Probably half were fresh out of college. After the fifth candidate in a row who can't do simple recursion or algorithmic analysis (and I mean simple) you get pretty discouraged. In one phone interview I got to interview an experienced engineer with over twenty years of experience in C. He completed the question I usually have to spend 45 minutes on with a new-grad in <10 minutes. It was probably my favorite interview of all time because I actually got to discuss the subtleties and he reaffirmed that I could maintain high standards.
Google is still a tiny company relative to the US economy. They might be slightly above average on some metrics, but that’s about it. Large enough they have plenty of idiots, small enough that most smart people don't work there.
As to high standards, you are testing for things that have very little to do with someone being good at the job. High arbitrary standards often remove the most talented people who generally don't have the same background as you.
EX: Suppose you where looking for a CEO, well having a collage degree seems like a reasonable requirement. However, a surprising number the best CEOs don't.
I'm a software engineer who really didn't know much about recursion or algorithmic analysis- I was a bio major/computer hacker. I did terrible on my first set of google interviews, at least on the algorithmic questions.
None of that was a reasonable predictor of my future performance at Google. You would have filtered out a perfectly good candidate (and this is, IMHO, the biggest issue is that Google rejects a number of people who would be great employees with its early filters). I can't say I have a better system.
The only interviews that made any sense for the time I got hired were the ones with the specific team members I was going to join. Once we got to chatting it was pretty clear I was a good technical fit for the team.
I still want to emphasize I don't have a solution to the high false negative rate in the pre-screening procecss.
It makes me think there's a screening recruiter, non-technical, before the "real" interview process. At big companies like Google with so many people interviewing, I can imagine these kinds of kick out questions.
Still, it shows a massive company trying to streamline some things and failing terribly. I personally wouldn't want to work at Google today. What might have been cool once is now nothing but a standard large company like IBM or Amazon. There's a great Quora post by some former Google people that say as much.
I think the interviewee after realizing the shortcomings of the tester's understanding and the author of said "right answers" should have interrupted or ended the probing after a few red flags and politely suggested something along the following lines...
"Look I get the gist of what this screening is trying to do but please write down my answers and feed them to the technical staff who authored this Q&A and have them verify their misunderstandings and have them get back to me please. I am very confident you all have subtle details mixed up and could benefit by a strong candidate who understands such details with a higher level of fidelity."
Guess its another loss given to the recruitment focus on avoiding false positives over false negatives.
> 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
Depends on what you actually do in your job, I suppose. If you use that information regularly or troubleshoot networks regularly you would soon enough memorize it.
> and if you need the specifics, you'll find out with a single search.
Someone doing network programming _does_ need the specifics.
Understanding SYN/ACK, and what they are used for, can be quite useful in troubleshooting networking issues so I can see why this would be useful in a SRE or other role that dealt heavily with communication.
He's one of the best programmers you can get (in the world) when it comes to networking and friends. Gwan is less known around because it's not OSS but I believe still achieves unmatched performance.
This interview must be some kind of a mistake. It's like testing Richard Feynman's knowledge with questions about multiplication table (where you have wrong answers on your table).
It's so stupid that it's almost not possible to laugh.
Who would know just how long a MAC address is? Jeez man, these things are literally written as 6 bytes separated by colons. Asking a network engineer this question is about like asking a postman how long a zipcode is.
> 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?
It's what happens when you get old. There were commonly C compilers on 8, 16, 20, 24 and 32 bit architectures, some big-endian, some not, and you couldn't google things in 20 seconds back in those bad old days when old farts were building the networks that would be used to connect to us all to google.
> I mean who would know just how long a MAC address is?
Hmm, let me think. Somebody working with routers for 10+ years.
> ..what the actual SYN/ACK etc tcp flags are?
Same.
I mean, these things are just as familiar to me as grade school multiplication, by now..I bet there's things familiar to you which I couldn't even be bothered to memorise and instead had to turn to a search engine for.
Having had some experience with big companies, I doubt that. They'll probably just write this guy off as being 'non googley' or whatever, and keep on keeping on.
(assuming the interview really went down this way. Which I have a hard time believing)
> 10. what is the type of the packets exchanged to establish a TCP connection?
> Me: in hexadecimal: 0x02, 0x12, 0x10 – literally "synchronize" and "acknowledge".
> Recruiter: wrong, it's SYN, SYN-ACK and ACK; if Google is down you will need to know this to diagnose what the problem is. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time. Good luck, bye.
Why the hell is a non-technical recruiter giving these tests? Google engineers or managers should be administering it, not the high school dropouts who make up the recruiting industry. There's so much wiggle room here that have a rote-memorization style test for engineering is completely crazy. I've never had a technical test given to me by a recruiting firm. Its always a call with someone from the company, if not the hiring manager.
Perhaps this is what they give to 'second string' applications to make HR happy while the guys who actually get the jobs are friends of the hiring manager or team leads. Or its a H1B ploy to say, "See Obama, we need tech talent. Look how terrible our domestic talent is. They score 40% on our tests!" Meanwhile Bombay Upstairs University has a wink-wink-nudge-nudge deal with Google hiring managers who accidentally leak the test on a 'forgotten' ftp site.
Everything about this is fishy. I think there's fraud here, not just incompetence. I've been the hiring stooge for shops who have already made their decisions before and its always terrible and, frankly, hurtful. These are the signs of a non-serious 'stooge' interview.
I feel like someone that's not unusually unintelligent should have been able to make the connections between SYN and synchronize or ACK and acknowledge. I don't know why people are defending the recruiter. The process is dumb, but so is an interviewer that asserts himself as an authority when he has to read from a sheet of paper. I don't expect him to be a technical expert, but I do expect him to know when he needs to consult a technical expert about a particular candidate's answers. If this is an accurate representation of his interviewing skills, he needs a new job.
Is this common for higher level positions at Google? I've gotten a similar kind of phone screen, but for an entry level software engineer position, and getting a few "wrong" was not a big deal. It's just so they can avoid setting up a real interview with someone who doesn't know the basics.
If the call actually went like this, it seems like you just hit a new/not very good recruiter.
> It's just so they can avoid setting up a real interview with someone who doesn't know the basics.
They're (allegedly) interviewing for a Director of Engineering. If google can't even google the guy and look at his track record, code, whatever, they don't deserve to have competent people working for them.
I know, that's why I would be surprised if this is standard practice for high level positions. But even if it is, this is unusually bad execution. My recruiter had at least surface level knowledge of the concepts and was able to ask follow-up questions if I got something half right, he wasn't just looking for verbatim responses.
"Is this common for higher level positions at Google?"
No, and in fact, it's so far outside the norm i'm not even sure what to make of it.
Like I said elsewhere, my best guess is that he was really being evaluated for a much lower level TL/M position in SRE or somewhere.
(The detailed linux questions are usually a giveaway that SRE is involved)
This reminds me of the infamous Nigerian emails. They are so obvious for a reason - avoiding false positives - [1]. Cannot fit this same scheme in a Senior position recruitment at Google though.
> This reminds me of the infamous Nigerian emails. They are so obvious for a reason - avoiding false positives
Unrelated to the main topic but I wonder if email providers could effectively fight those scammers by having chatbots automatically reply to their emails. That would make a bunch of false positive to sort through and possibly make the whole thing uneconomical for the scammers.
Having been through several goog interviews I find it hard to believe that the interviewer would dismiss his highly technical explanations/rebuttals in that way. Seems more likely this is his interpretation of the tone of the interview, rather than a transcript.
The meta-question is, "Do you have the social savvy to give the conventional answers when being judged by someone who doesn't know what he is taking about?"
Yah I get the feeling you're supposed to "act stupid" so you can get to the next interview.
Definitely not an idea way of getting candidates - you are selecting for people who know how to manipulate screens (and thus increasing the risk of getting a bad candidate), or rejecting otherwise knowledgeable people who just don't have the time/inclination/"social savvy" to pretend to be stupid.
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 the second person, how are you ever going to figure out that the first person you're selling to has some business requirements on a sheet of paper and you'll never get to the second person until you parrot those?
"Oh, we're not actually using Docker, we're using rkt, which is a compatible reimplementation of --" "I'm sorry, I've been told Docker is a requirement. We can't use your Cuber Netty thing until you support it. Bye!"
It's totally dependent on the type of person being interviewed. There is a difference between "knowing how to work in a team" "knowing when to be civil, when to push, when to go to battle", and wanting to parrot answers in order to just get to the next step.
If it were me, I'd try to engage with the recruiter and make them go completely off book. I'd ask them about their career, and try to find a different job for them (instead of reading stuff off a sheet of paper), or if that's what they are content to do, try to escalate and get them to reveal their "client" or "person they report to" (which in recuiting is a no-no) - I think I have the confidence and social skills to try to do that (I've talked past border officials, and various recruiters, and having been in a tele-job where I had to follow a script, I know exactly where a script reader is most likely to go off book if I ask something at exactly the right time). I am in no way qualified for a director of engineering position, but I can very easily get past this telephone screening, because precisely I've been the person asking this kind of question and using this kind of script. If I got past this screening, I'd be wasting the time of the person next in line for the interview.
Of course, it is a valid strategy to get an interviewee to follow along, but it's misguided - using the entirely wrong tool (scripted questions/answers) for doing the job (finding someone with managerial and people talent).
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 trying to gauge how well I handle someone who thinks they know what they are talking about, but actually do not--which can a surprisingly large number of people in the office.
The most plausible explanation is the guy failed the interview, felt bad about it, then wrote a version of it to make him look good and Google bad to punish them.
I find the thought more plausible that Google had 100s or 1000s of candidates and they weren't willing to interview all of them directly because most are usually crap, so they let some incompetent contractor do a pre-screening.
I really wish our industry could create some generally trusted benchmarks of skill that we could take once and then be done with. As things are, we have to prove basic programming skill with every employer. You'd think this wouldn't be necessary with more than a decade of experience and several degrees in computer science from eminent institutions, but apparently it is. I'm fine with employers asking very particular questions about the domain of work, but we shouldn't have to prove sanity all over again every time.
Really doubt that based on those questions. Recruiters are human and fallible. They form opinions about people, sometimes incorrect, and act on those opinions all the time. This phone screen is the final step before they lose control of the candidate process to the technical team.
Recruiters do reject candidates and create false negative situations when it comes to positions that have a lot of candidates and very few openings. For Google, that would be every position, especially engineering.
> Being able to talk to them productively instead of picking fights is a skill worth selecting for.
Perhaps, but if the story is true, then it's wishful thinking to assume Google tried to do just that by putting a moron or someone acting like one in the recruiter chair. That way you risk hiring a quick talker who can talk, joke or laugh his/her way out of a wrong answer. If technical skills don't really matter, it's fine though.
While this recruiter probably failed at their task, I do agree that there is skill in communicating technical information to non-technical people, and it is a valuable skill. I wouldn't be surprised if the author of this blog post acted a bit curt or acrimonious to the recruiter, and stubbornly insisted on being "right" rather than communicative and agreeable.
You mean the wrong answers. Great, in a technical interview for the Director of Engineering (not legal, not HR) Google expects you to know when to lie and give the wrong technical answers and when to give the right technical answers because this is essential to the Director of Engineering position? What are they hiring someone to be complicit in their next wage suppression scheme?
Doesn't make sense given the end of the interview, unless the recruiter was being completely disingenuous. The recruiter recomended the interviewee getting some education in the topics he asked about.
Most people, at every level, are terrible at interviewing and hiring, and in fact a surprising number are conscious of that fact. As a candidate, you just have to know this going in, and expect to be made to jump through a lot of irrelevant/stupid hoops. Eventually you find someone who is adequately amused by your performance to give you a chance and hire you.
I don't think the recruitment industry is going anywhere anytime soon. I just wish there were some worthwhile recruiters in it (out of the dozens and dozens of recruiters I've dealt with, I've met one who is semi-competent (which is to say, not fully competent)). This is an area I'd love to try to startup in, I don't think any of the startups I know about are doing it right.
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.
It's a freaking psychological profile test dressed up as "tech screen". Your friend's personality was effectively filtered.
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.
It is scary if this is how Google hires engineering directors. Passing this test would select all the bad candidates! Answers to many technical solutions are "it depends". If you have a director that "knows" the right answer, they won't be very likely to encourage their engineers to experiment and find the best solution to the specific problem at hand.
I keep pushing the message that getting a "correct[tm]" answer to a technical question is probably not the answer you should be looking for. Problem solving skill trumps rote knowledge every time.
968 comments
[ 3.0 ms ] story [ 390 ms ] threadThere are a lot of different answers to the question depending on where you're doing it and how you want to impact the machine.
It's a bizarre question to pose to Director level, because the proper response even for a technical director should be, "The answer to that changes quickly, we should measure and check what our environment's latest capabilities are and if they are reliable."
I mean I'm all gung ho to program stuff, but I think that'd be a massive misapplication of my time with that title in my current job, and given my other responsibilities I'd only do it more slowly than someone with dedicated focus.
Recruiter: "I was looking for you to say it's a fingerprint"
So I guess I was wrong, because despite explaining them in decent detail, I didn't use the one keyword.
A non-fingerprinting hash function - well, one example of one- is something that for similar inputs, produces the same output (similarity being defined by some distance metric). See, for example: https://en.wikipedia.org/wiki/Locality-sensitive_hashing and https://en.wikipedia.org/wiki/MinHash
Confusingingly, many functions that are used for similarity detection are called Fingerprints, (https://en.wikipedia.org/wiki/Acoustic_fingerprint), but I consider that a distinct use of the term.
Could something like Hamming distance be called a hash function too? It's not mentioned on its Wikipedia page.
But this is also the goal of non-crypto hash function like those used in a data structure no? Basically mapping a large space of inputs to a smaller space of outputs.
I would say the cryptographic hash is one the that has "desirable" security properties, things like not being able to recover the original input message using the hash, a tiny change in the input causes a substantial change in the output, or that its very unlikely that two inputs will produce a collision.
What matters is whether similar inputs get mapped to the same output. For the case where you want to minimize the probability that two inputs which are highly similar land in the same bucket, you want a crypto hash, although those are expensive so you want a cheaper approximation, which is exactly what fingerprint hashes do. The problem is that as the input values counts approach sqrt(output value size), you're going to start getting collisions, and ideally, you want those collisions to be evenly spaced.
In the case of a similarity hash function, you want the opposite, the closer things are in some metric space, the more likely they end in up in the same bucket.
That's what I was trying to say:
"a tiny change in the input causes a substantial change in the output."
But I probably didn't articulate that very well. I think we are saying the same thing.
You mentioned:
"The problem is that as the input values counts approach sqrt(output value size), you're going to start getting collisions"
Can you elaborate on the significant a square root here? Does this relate to the load factor?
level 1: foo, bar, baz level 2: frobnitz, barfoo level 3: 42, etc
In someone is using words from level 2 that work together in the ways laid out, they're probably beyond level 1, and wouldn't use the word 'fingerprint' (in this case) - they're giving more detail (and probably better) than what was being listened for.
first thing I do is try to get them to ask it a different way. then I play spew out every related buzzword possible as if its a question. Are you talking about .... oh, you mean .... I can usually get it in a few tries.
A hashing function is actually a sorting function. It's supposed to take an input space and sort it in an unpredictable and evenly distributed way across the output space. What's more, neighboring points in the input space, no matter the sort used to determine proximity should not result in neighboring points in the output space.
Fingerprinting is just an emergent value that comes from choosing fixed length hashes, and the fact that the mapping from input to output is stable.
So he asked "how did you figure this out so fast?". I told him I didn't, I just remember all the "important" powers of 2. He said "well... that's not what I was looking for, I wanted you to calculate it, but... I guess a candidate who memorizes powers of 2 is a positive sign?". I passed.
Oh well.
I cannot obviously tell you the exact specifics because of the NDA.
Maybe I dodged a bullet there and Amazon would have been a bad place to end up anyway.
I had the same a couple of years ago, at the time I was a Rails developer at a small startup. The first screening they asked me some basic technical questions (I guess it was a recruiter), then the second screening they asked me to walk through some data structures and algorithms off the top of my head.
I knew they would do this, and hadn't looked at any CS algorithms since university, so got a copy of Programming Pearls and studied through that every evening for the week before. I picked a few that I hoped would come up, and it turned out that's what they asked for. I think first a linked list (maybe doubly linked?) and then a tree sort.
I surprisingly passed, but the attitude of the interviewer really put me off. He said he knew Python, Java and Go - none of which I had used - and wasn't too happy when I said I wanted to use Ruby (which the first guy I spoke to, said was fine). Then throughout the interview it seemed very much like he was fighting against me and trying to prove me wrong.
After that I couldn't be bothered any more, I didn't really want a job at Google, it's just a recruiter contacted me and I decided to try it out. I guess this style of interviewing must work for Google, but it's just not the way I like a company to introduce itself to me. It just seems like they are approaching it with so much ego, as if I would be privileged to work there, but to me a job should be mutually beneficial.
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)
If you can't dumb it down you're just going to waste peoples time.
The person asking the questions said right from the start that he is not technical (he was a psychologist) and that he had a cheatsheet in front of him.
I passed that telephone call and failed the process later on another call (on the lightbulbs and the 100 floor building)
Really surprised to see that 4 years later they still do this.
These kind of questions are not expected, but I would say the lightbulb one is not super horrible as long as it is the discussion that was valued and not the answer. I have gotten weirder questions for sure when interviewing.
Can you really "fail" an interview on a question like that? I assume the person conducting the interview is reviewing your process of coming to an answer rather than getting the most correct answer - right?
By most correct I found this article that broke down the question/answer: https://pointlessprogramming.wordpress.com/2011/03/11/2-ligh...
But yes, in practice, YMMV.
I've has similar issues with other companies. Network developer? Great! Let's ask some assembly / Java questions!
Uh... if you people are that stupid, I don't want to work for you. Thanks. <click>
It's a bit strange to have someone non-technical interviewing a techie. You end up with stupid discussions like the one about Quicksort. If you point out qs is one of several things with the same big-O, you'll probably also get it "wrong". But the real problem is that a guy who is just reading off a sheet can't give any form of nuanced feedback. Was the guy blagging the sort algo question? Did he know if in detail? Does he know what the current state of research on that area is? There's no way to know that if your guy is just a recruiter, but I'm sure even a relatively junior coder would be able to tell if someone was just doing technical word salad.
I wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face.
One example of how this can be handy is when doing low-level NIC bring up, I've read PCIe TLPs from a logic analyzer to correlate them to network traffic.
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 of being a practicing programmer; knowing how to find out is.
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.
Btw, that is the only thing I really disagreed with OP on, the rest seemed just ridiculous.
It's a technical interview, the question should have been technically correct. "What function passes by-reference copies of inodes?"
"lsof just prints open files... you would use netstat, not lsof."
I tried correcting him, but he wouldn't listen and ended the call soon after.
I never received a call back.
I personally wouldn't want to work with someone who wasn't able to understand what I mean (in such an obvious case, at least) and wasn't able to answer to that meaning.
(Of course, I'd also personally prefer someone who would point out that this is inaccurate, but do so in a charming and off-hand way, to make me feel comfortable. A high bar, maybe, but for a director that's definitely a bar they should clear).
Remember, you have to walk through the interview thru OP's mindset and how he took into consideration the interviewer's analness.
lstat has the same signature as stat: it passes the stat structure back through an output pointer.
IIRC, you can return structs from functions in C. You have to access the values in the returned struct with dot notation, of course, like point.x .
Pre-ANSI C may not have had this, but later, it did. Remember reading it in the 2nd (ANSI) edition of the Kernighan & Ritchie C book, and also used it myself in some programs.
https://www.google.co.in/?q=can+you+return+a+structure+in+c
Edit:
Might want to consider the cost of copying, depending on the perf requirements, size of the struct, whether the function call is in a tight loop, etc.
OS X: (OK, so I lied about the "fine" part)
Windows, here the VC++ CRT - fantastically poorly described, if you ask me, though of course you shouldn't be using any of this POSIX shit on Windows, so if it confuses anybody enough to make them go and find FindFirstFile then it can only be a good thing:Why he's being interviewed for that position is a different question entirely, and I can imagine Google being totally right or totally wrong.
Take, for example, the sorting question. "Why is QuickSort the best sorting algorithm?" The answer being looked for was, "It has the best Big O."
And this is wrong. Its average case is O(n log(n)). Its worst case is O(n^2). Which do you call its big-O? Moving on, the average case of O(n log(n)) is matched by a wide variety of sorting algorithms. How do you choose one?
Here is a better answer.
QuickSort is a very simple to implement algorithm which achieves the lowest average number of operations on a randomly sorted list. Which is why it is so widely adopted despite sometimes being very slow.
However Timsort appears to be the fastest general purpose sorting algorithm for the mix of random and partially sorted lists seen in practice.
When I tend to notice that sorting is slow, generally that's a larger workload where some type of merge sort would be appropriate.
For instance, perhaps the interviewer asked "What makes quicksort a good sorting method," instead of "What makes quicksort the best sorting method"—a very small difference in phrasing. In that case, the answer of "It's not always the best, or even suitable" is still technically true, but much more wrong. (And an answer like the one you started with, "Its average case is O(n log (n)), its worst case is O(n^2)," would have been enough to pass... but sitting on the phone and arguing about storage topology is itself a failure.)
As I mentioned in another comment https://news.ycombinator.com/item?id=12702130 , my (five-year-old, faulty) memory of Google's SRE phone interview is that they asked another question here with a very small but important phrasing difference: "What is the signal sent by the kill command" instead of "What is the kill signal". If you make that change, the interviewee's answer of "SIGKILL" becomes wrong, and the interviewer is right to insist on SIGTERM (which would otherwise make no sense). It is a quite literal game of telephone.
(Again, I can also imagine Google being totally wrong and the interviewer mangling the questions.)
For question 5, you asked about an inode, and were told about an inumber, and got back an answer insisting that the inode was an index.
For question 6, maybe change "inode" to "information in the inode". The interviewee still has not figured out the distinction between an inode and an inumber.
For questions 7 and 8, apply the changes I suggested.
At what point do you decide that the interviewee is hopelessly arrogant and not worth your further time? And how do you get them off the phone gracefully?
Maybe around question 10, when they're quoting bits to show off and not saying the words that would actually let them communicate with other engineers like "SYN" and "ACK"?
No ill will is required on the interviewee's side, unless you consider refusing to waste time on bad candidates "ill will".
The conversation that I'd have to reconstruct has a very combative interviewee. Which would also fit said interviewee deciding to write up the article that I read. Which would mean that Google dodged a bullet.
I find it interesting to note that his site is down. There are a lot of possible causes, but it isn't good advertising for his webserver software.
But... the kill command is the command to send arbitrary signals. It sends them all.
I know this is irrelevant to the larger point of your post, and I'm sure that you know this already, but the worst case is the big-O. This is just another reason why "big-O" is not the most helpful thing to discuss in practice.
Big-O is a way of categorizing the growth of mathematical functions. Those functions can represent anything. It is wrong to talk about the big-O of an algorithm without specifying what you are measuring. Be it average operations, worst case operations, average memory, worst case memory, amortized average time, amortized average memory, and so on.
It happens to be that when we talk informally, we're usually talking about the worst case we are willing to think about. Quicksort's worst case is a sorted set, so we think of that as O(n^2). But then we turn around and cheerfully call a hash lookup O(1) because its O(n) worst case is incredibly rare in practice.
Thanks for correcting me!
I thought you were right at first but then realized what was going on. This is a pretty subtle point and mostly uninteresting for well-understood algorithms like quicksort. But one slightly less subtle point is that big-theta isn't average case, it is the combination of big-O and big-omega, i.e., bounded from above and below (possibly with different constant factors) by the same asymptotic behavior.
But, obvs, the answer is that you Bing it.
I think you're onto something greater. Maybe Google should hire more smart people who were developing in the 1990's as they're a nice, middle ground between ambitious, young folks and the been-there-done-that greybeards. Them realizing such people already know all the shit they're trying to teach their developers might be way to sneak older people into these tech firms. Haha.
In a recruiting situation, if the recruiter is going all "right and wrong" on the interviewee, they should know these dirty details.
I also disagree on the ethernet address length. You know how long IPv4 addresses are, you know how long IPv6 addresses are, why would it be so extraordinary to also know how long MAC adresses are?
I think it could be useful to find out in an interview whether the applicant knows stuff because they have actually implemented low-level code and gained an intricate understanding, or whether they just did used some high level APIs and were never interested in more details than "I have a handle right here, it does all I need". For some positions that would be an important distinction.
Personally, if I were interviewing people, I'd hire the guy that explains something to me that I did not know, but that I find interesting and would have attempted to understand, too.
While I agree, I have seen interviewers where if he answered "fstat" they would have come back with "Wrong! fstat passes the structure back by reference, it does not return it!"
With this style of interview I can't blame him for thinking it might be a trick question and then trying to explain why he didn't say those other functions as an answer.
The rejoinder, of course, is that it's probably misguided to structure your recruiting around a spam filter.
Maybe I'm a bad programmer, but I don't feel like I would be a better one with that specific fact committed to memory. I dunno.
I do plenty of interviews, and so I do have some sympathy for the idea that some overwhelming majority of applicants simply cannot perform even the most basic coding tasks but are somehow trying to sneak in anyway, but at the same time I can't escape the suspicion that a lot of the stories are actually from badly-designed or badly-calibrated interviews gone off the rails.
I absolutely believe that the article we're discussing here gives a fair view of a Google phone screen, since I've been through it too and even got asked some of the same questions. The only reason I "passed" was that I recalibrated way, way down to meet the expectations and the technical understanding of the recruiter I was talking to (who did very clearly seem to be reading off a prepared script). This was surprising since Google had reached out to me to ask me to apply, which one would think indicates a confidence in basic technical skills, but if I hadn't caught that and adjusted how I was interpreting and answering the random trivia they threw at me, I likely wouldn't have passed the screen and would have been labeled just another impostor trying to sneak into a job I'm unqualified for.
So when I hear someone else talking about all the "unqualified" applicants they get, I can't help wondering how many really were qualified applicant talking to unqualified interviewer using unqualified interview process.
(disclosure: I don't work for Google, don't ever intend to work for Google, and in fact hung up on a later screening call out of frustration with the way they ran their process, which at least finally got their recruiters to stop spamming me)
My friends and I used to spend bar nights drinking over torturous interview questions (yes, I have always been this nerdy). For instance: we had a gruesome sequence of questions on how to implement the fastest possible traceroute that you could only clear if you knew about a trick using the IP timestamp option.
Later, I got (what I thought was) smarter about interviewing, and moved to more surgical questions. I'd ask candidates to debug a C program that segfaulted in malloc, or ask them to describe the utility functions they carried with them from project to project.
After taking over recruiting for a company that really needed to hire at a specific clip in order to balance sales and delivery, I'm embarrassed that I thought I was interviewing effectively with stuff like this.
You can't learn about someone's capabilities by putting them on the spot with trivia questions.
But that's not the point of these questions. These questions are a 5-10min phone pre-screen before getting to the actual interviews. They test if the candidate has experience in a given field, not if they can search for information or what are the precise bounds of their capabilities.
It's trivia, but it's trivia that is a reasonably high confidence proxy for experience in e.g. network programming/design (resp. other fields). If someone claims they have networking experience and don't know SYN/SYN-ACK/ACK it's in my opinion a large red flag.
The ostensible reason they get deployed (I say "ostensible" because we all know that in reality the on-site interview consists of the same stupid kinds of questions) is to keep the employer from wasting time conducting more sophisticated interviews for candidates who have no hope of passing. But that's dumb for at least two big reasons:
* The filters obviously reject candidates who would do well on more serious challenges --- worse, they do it insidiously, because you can't tell that they're rejecting good people, only that you're seeing fewer bozos, which makes them look like they work. In reality, a new norm has arisen where the most qualified candidates get to skip these processes entirely, because we all know they're a crap-shoot and don't want to lose good people.
* Properly administered work sample challenges actually take less employer time than these stupid trivia screens do. That means there's literally no purpose to the trivia screens whatsoever; they do nothing but harm.
In my last comment, I just wrote off the top of my head a sketch for a work sample test that addresses the same concern as the dumb TCP/IP trivia quiz from the original post. It took me I think something like 30 seconds to come up with it. Think about how you'd score that (remember: the bar here is "must be more predictive than that dumb trivia question"). I'm thinking something along the lines of "run the code and see if it opens a new TCP connection".
Assuming your team has enough sophistication to build work sample challenges like this, try to justify the trivia interviews. I think you can't.
SRE's are hired to fix outages and other problems asap, knowing trivia is very important then since at that point you might be losing a million dollars per second.
Linux:
Mac OS X 10.11: It may be pedantic but stat definitely doesn't "return" an inode. One of the problems with technical interviews like this is you often have no idea what the interviewer is really looking for. Some might just want to know what you would use to get the information about an inode and another might be seeing how you describe it as a test of your knowledge of pointers or something. Often it's impossible to know and that could have been easily a trick question where the right answer is "there isn't one but you can use stat to get this information as it takes a struct pointer and will place the information into that struct". Of course you know that better than most or you wouldn't have made stockfigher.If you're interviewing for the rare 1% case where the job will actually require you to tinker with a TCP stack, then by all means ask about those details. For 99% of programming jobs today, it's irrelevant trivia used as nothing more than an ego measuring device.
I feel like I've seen 2-3 articles alone in the last month that has rediscovered head-of-line blocking and UDP. I'd say 1/10 engineers I talk to even know what cache aware datastructures are.
The thing that separates someone who can just string together whatever they find on npm to people who build real systems is this deep understanding. You're not going to need this for your standard LoB apps. However if you're in the business of building software you're definitely going to want people like this.
Trying to find the TCP stack engineer to build your app is like hiring a petrochemical engineer to do oil changes. If your pockets are as deep as Google's, yes, you can do that, but it's by no means necessary.
And that, ladies and gentlemen, is how we ended up with npm.
Whatever this thing... this... stringing together a 100 random github projects to get a webpage that kinda of works about 80% of the time is called -- please let's agree not to call it "software engineering".
That said I can't recall any of that stuff mattering in the stuff I do for work for quite some time and most of it is a google search away.
That interview was just weird, it was like asking the boiler pressure for a steam train to someone who was a master engineer working on electric trains.
Applicant Doctor: "They're double membrane-bound organelles found in all eukaryotic organisms, commonly between 0.75 and 3μm in diameter, that generate most of the cell's supply of adenosine triphosphate"
Recruiter: "No. They are the powerhouse of the cell".
"Well, it depends what color model you are using, which differentiates between additive and subtractive color mixing, the medium used (print, screen, etc.)...
No. It's Red, Green, and Blue.
/colorblind
She was more artsy, I was insistent that the primary colors were RGB, she was insistent that they were RYB. We googled. We were both right in some senses.
I haven't brought it up yet because we once had a fight over whether that thing you put outside your shower is called a bath mat or a bath rug (Both are correct in different circumstances)
It reminds me of a classic Dilbert. https://goo.gl/images/7DhC9f
Like this one: https://www.youtube.com/watch?v=yu44JRTIxSQ
'a'
No. The right answer is 'A'. We will stop here because it's obvious that you don't have the necessary skills.
Doctors know a ton of random crap tangentially related to their jobs that they were forced to memorize.
This isn't even my domain, but I remember some of this stuff. I had to dig in to this area years ago, and was knee-deep in that level for several months debugging and configuring stuff. Some of it stays with you, even if you're not there any more.
For someone applying for a director of engineering, I'm kind of split as to whether this should be required "off the cuff" knowledge. Would certainly help, but seems it would depend on the culture of the company - how hands-on they expect director-level folks to be - some companies seem to want that, some don't.
In interviews, I've had people give answers I'm not familiar with. The easy thing to do is to ask them to explain how their answer works. You get to vet whether it seems legit, and as a bonus see how good they are at communication in a genuine teaching moment.
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 recruiter take careful notes, asking the candidate to repeat if necessary, in the cases where the candidate insists they know the answer.
Then only in cases where the candidate can't answer a question should it be marked as "wrong." In other cases the answers should be run past someone knowledgeable.
I've gone through a phone interview with Google myself, and it was nothing like this: I spoke with a real, skilled engineer, and there was nothing like a "gotcha" question where I had to guess the exact term he meant. Well, except where he asked "I bet you know what my next question is" and I didn't guess "How can the algorithm be faster?" But he didn't count that against me. :)
(Assuming they get no false positives, which, thinking about it, is a big assumption)
I may have gotten a technical interviewer because I can list a half dozen people who know me who work at Google, most of whom can directly vouch for me.
Not sure why the OP got an unskilled reviewer, but if they didn't list references inside the company, they may have been thrown in the "random unknown applicant" bucket.
Not surprised by the questions. Most are [somewhat] common and not particular challenging.
I am surprised by the stupid counter-answers from the recruiter thought. This guy should not be giving phone interview.
I did not see any argument here from the statement in the article. The recruiter clearly had little clue about what is right and wrong. And the way the recruiter assess the answer by throwing right/wrong seems more rude to me compared to the author "wanting to be right".
Please do not speculating based on something that is not present in the article.
I had done similar interviews before, the recruiters I worked with did not show the same level incompetence as this one. When I want to be more specific on details, they would suggest that they think it's enough and move on. Not like this recruiter who just throw a 'wrong'.
Are you talking about the recruiter?
I'm fine working with non-technical people (or who don't know any given field), but I wouldn't be fine working with those people if they were insistent that they did know about these things about which they actually had no clue, or if they were in a position where they really need to know this stuff.
I have coworkers who don't know how to use the command line, but they aren't engineers and they don't try to tell me what commands to run when I pull up a console, so it's fine. If they keep insisting that I should use "dir" and that "ls" is wrong, that would be a problem. If they were the CTO, that would be a problem.
When we hire engineers for customer support, the non-technical operations guy interviews them, but he always has at least one engineer do a portion of the interview because he knows he's not fully qualified to judge someone's technical chops.
The OP isn't being condescending just because someone didn't know stuff. It's because someone didn't know stuff, but because they acted like they did. You want to be insufferable, insist you know better than the experts in a given field.
Or to put it in terms you'll understand, clicking around on your comment history a bit, we get a pretty solid impression of what kind of guy you are.
The medical recruiter asks to see the diploma. The doctor shows his degree and gets the job.
https://en.wikipedia.org/wiki/Comparison_of_MD_and_DO_in_the...
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.
That is why you know the answer. Come back in 10 years and let us know if you still know it. What you think might be mainstream in a computer science class are rarely used in application. And if they are they can be easily looked up.
I used to know the exact effective distance of a CATV cable when I was a student. Useful? Sure. Something I need to remember for the rest of my life? Definitely not.
As another example, in 17+ years writing ISO level 7 programs, I have never once needed to use the Mac address.
I've never taken a CS class, and I still know it. I've just stared at enough packet dumps and debugged enough issues that it happens to stick.
I think it's a stupid question to ask as a screener, as it tests familiarity with trivia. It's the kind of thing I'd be happy to see that somebody knew, but it's never something I'd downcheck them for not knowing. It could just mean, as in your case, that there deep knowledge is somewhere else.
We are all a product of our environment. And there is certainly a chance in 10 years the OP will still know how many bytes are in a MAC address. I only mentioned computer science based on the "student" part of the quote.
Personally I've been spoiled by working on higher level stuff so if I do look at a packet dump I usually filter the packet headers out. But again, we're a product of our environment and asking questions that a reasonable skilled engineer might go their entire career without knowing the answer to except in that interview is a bit suspect and will likely disqualify people that would be otherwise great for the job.
Maybe 10 years from now I'll have forgotten everything about the hex/binary/octal representations of numbers, but I certainly hope not!
Uh actually my classes didn't teach me that. Side projects did.
The point still stands though. First, it is much easier to have side projects when you are in school so the causal relationship might still be there just one step removed. But the more important point I was making was that school or a side project or even a project at work, if people go 10 years without using it, they forget things.
As an aside, you may want to drop the "Uh" in-front of your sentences. It conveys a certain tone that I'm not sure you are doing intentionally.
Thanks for the refresher! I knew that too when I was in college. Good luck remembering that 5 years from now :)
I did not learn this because some course demanded I learn a text book by heart. I'm not doing that kind of theoretical university. I knew that particular thing because I look at a lot of packet captures.
This rubbish flies in our industry since we are not professional engineers.
[1]: https://en.wikipedia.org/wiki/Principles_and_Practice_of_Eng...
> Nonsense.
s/\./:
We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time.
Come on Hacker News, I know you hate recruiters, but do you really think that happened?
The fact that several Google people posting here literally can't believe this is true shows how fucked up their process is.
I was more impressed by how simply he explained many of them in real-world terms. Especially countering Big O. That plus what he's already built indicates he's exactly the kind of person to direct the sort of projects they're building. That they filtered him with this garbage Q&A speaks volumes about Google's ineffective hiring. Plus, indicates what kind of people might have made it into the organization.
2) We are getting description from him. When I interviewed at Google, they asked me to prove that P is equal to NP, and I did, but they said that it took me longer than allotted 45 minutes and I didn't get an offer.
The pain of being tossed out onto the pavement would totally be worth it.
I've been looking at them on NICs, adding them to DHCP databases and using them for simple authorizations in iptables (and prior equivalents) since, oh, 1992 or thereabouts. They weren't new then.
It would take me a moment to count them in my head, that's all. "aa, bb, cc, dd, ee, ff -- that's six bytes".
Which is really bad, when they're trying to hire people for a job where thinking is the fundamental skill...
When I was an interviewer at Google it felt like 90%+ of interviews were with candidates who had less than four years of experience. Probably half were fresh out of college. After the fifth candidate in a row who can't do simple recursion or algorithmic analysis (and I mean simple) you get pretty discouraged. In one phone interview I got to interview an experienced engineer with over twenty years of experience in C. He completed the question I usually have to spend 45 minutes on with a new-grad in <10 minutes. It was probably my favorite interview of all time because I actually got to discuss the subtleties and he reaffirmed that I could maintain high standards.
As to high standards, you are testing for things that have very little to do with someone being good at the job. High arbitrary standards often remove the most talented people who generally don't have the same background as you.
EX: Suppose you where looking for a CEO, well having a collage degree seems like a reasonable requirement. However, a surprising number the best CEOs don't.
None of that was a reasonable predictor of my future performance at Google. You would have filtered out a perfectly good candidate (and this is, IMHO, the biggest issue is that Google rejects a number of people who would be great employees with its early filters). I can't say I have a better system.
The only interviews that made any sense for the time I got hired were the ones with the specific team members I was going to join. Once we got to chatting it was pretty clear I was a good technical fit for the team.
I still want to emphasize I don't have a solution to the high false negative rate in the pre-screening procecss.
Still, it shows a massive company trying to streamline some things and failing terribly. I personally wouldn't want to work at Google today. What might have been cool once is now nothing but a standard large company like IBM or Amazon. There's a great Quora post by some former Google people that say as much.
"Look I get the gist of what this screening is trying to do but please write down my answers and feed them to the technical staff who authored this Q&A and have them verify their misunderstandings and have them get back to me please. I am very confident you all have subtle details mixed up and could benefit by a strong candidate who understands such details with a higher level of fidelity."
Guess its another loss given to the recruitment focus on avoiding false positives over false negatives.
Depends on what you actually do in your job, I suppose. If you use that information regularly or troubleshoot networks regularly you would soon enough memorize it.
> and if you need the specifics, you'll find out with a single search.
Someone doing network programming _does_ need the specifics.
This interview must be some kind of a mistake. It's like testing Richard Feynman's knowledge with questions about multiplication table (where you have wrong answers on your table).
It's so stupid that it's almost not possible to laugh.
ERR_CONNECTION_REFUSED
That last sentence is important.
It's what happens when you get old. There were commonly C compilers on 8, 16, 20, 24 and 32 bit architectures, some big-endian, some not, and you couldn't google things in 20 seconds back in those bad old days when old farts were building the networks that would be used to connect to us all to google.
(And he has apparently been in networking since)
Hmm, let me think. Somebody working with routers for 10+ years.
> ..what the actual SYN/ACK etc tcp flags are?
Same.
I mean, these things are just as familiar to me as grade school multiplication, by now..I bet there's things familiar to you which I couldn't even be bothered to memorise and instead had to turn to a search engine for.
Not only because of that interview, but the questions transforms into - who else have we missed from the great guys ...
(assuming the interview really went down this way. Which I have a hard time believing)
This is a pretty standard google first interview. Nothing out of the ordinary.
The recruiter will not suffer for following standard proceeding.
> 10. what is the type of the packets exchanged to establish a TCP connection?
> Me: in hexadecimal: 0x02, 0x12, 0x10 – literally "synchronize" and "acknowledge".
> Recruiter: wrong, it's SYN, SYN-ACK and ACK; if Google is down you will need to know this to diagnose what the problem is. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time. Good luck, bye.
That's embarrassing.
Almost feels like the recruiter was conspiring against you, but why?
Perhaps this is what they give to 'second string' applications to make HR happy while the guys who actually get the jobs are friends of the hiring manager or team leads. Or its a H1B ploy to say, "See Obama, we need tech talent. Look how terrible our domestic talent is. They score 40% on our tests!" Meanwhile Bombay Upstairs University has a wink-wink-nudge-nudge deal with Google hiring managers who accidentally leak the test on a 'forgotten' ftp site.
Everything about this is fishy. I think there's fraud here, not just incompetence. I've been the hiring stooge for shops who have already made their decisions before and its always terrible and, frankly, hurtful. These are the signs of a non-serious 'stooge' interview.
If the call actually went like this, it seems like you just hit a new/not very good recruiter.
They're (allegedly) interviewing for a Director of Engineering. If google can't even google the guy and look at his track record, code, whatever, they don't deserve to have competent people working for them.
No, and in fact, it's so far outside the norm i'm not even sure what to make of it. Like I said elsewhere, my best guess is that he was really being evaluated for a much lower level TL/M position in SRE or somewhere.
(The detailed linux questions are usually a giveaway that SRE is involved)
[1] http://uk.businessinsider.com/why-nigerian-scam-emails-are-o...
Unrelated to the main topic but I wonder if email providers could effectively fight those scammers by having chatbots automatically reply to their emails. That would make a bunch of false positive to sort through and possibly make the whole thing uneconomical for the scammers.
Definitely not an idea way of getting candidates - you are selecting for people who know how to manipulate screens (and thus increasing the risk of getting a bad candidate), or rejecting otherwise knowledgeable people who just don't have the time/inclination/"social savvy" to pretend to be stupid.
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 the second person, how are you ever going to figure out that the first person you're selling to has some business requirements on a sheet of paper and you'll never get to the second person until you parrot those?
"Oh, we're not actually using Docker, we're using rkt, which is a compatible reimplementation of --" "I'm sorry, I've been told Docker is a requirement. We can't use your Cuber Netty thing until you support it. Bye!"
If it were me, I'd try to engage with the recruiter and make them go completely off book. I'd ask them about their career, and try to find a different job for them (instead of reading stuff off a sheet of paper), or if that's what they are content to do, try to escalate and get them to reveal their "client" or "person they report to" (which in recuiting is a no-no) - I think I have the confidence and social skills to try to do that (I've talked past border officials, and various recruiters, and having been in a tele-job where I had to follow a script, I know exactly where a script reader is most likely to go off book if I ask something at exactly the right time). I am in no way qualified for a director of engineering position, but I can very easily get past this telephone screening, because precisely I've been the person asking this kind of question and using this kind of script. If I got past this screening, I'd be wasting the time of the person next in line for the interview.
Of course, it is a valid strategy to get an interviewee to follow along, but it's misguided - using the entirely wrong tool (scripted questions/answers) for doing the job (finding someone with managerial and people talent).
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 trying to gauge how well I handle someone who thinks they know what they are talking about, but actually do not--which can a surprisingly large number of people in the office.
Recruiters do reject candidates and create false negative situations when it comes to positions that have a lot of candidates and very few openings. For Google, that would be every position, especially engineering.
Perhaps, but if the story is true, then it's wishful thinking to assume Google tried to do just that by putting a moron or someone acting like one in the recruiter chair. That way you risk hiring a quick talker who can talk, joke or laugh his/her way out of a wrong answer. If technical skills don't really matter, it's fine though.
Know your audience.
I don't think the recruitment industry is going anywhere anytime soon. I just wish there were some worthwhile recruiters in it (out of the dozens and dozens of recruiters I've dealt with, I've met one who is semi-competent (which is to say, not fully competent)). This is an area I'd love to try to startup in, I don't think any of the startups I know about are doing it right.
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.
Well much like most things in life, there is no such thing as concrete answer.
I recently wrote a somewhat lengthy post on the subject, after realising how bad some companies are at this: https://smarketshq.com/notes-on-interviewing-engineers-a4fa4...