Google needs the best brains in the business to keep on top of the highly competitive – and very highly lucrative – game of computer technology.
Computer engineer Pierre Gauthier recently received a telephone interview for the position of Google's "Director of Engineering” and shared his experience in a blog post. As he explains, the opportunity was a rare one, as it required both management as well as top-end coding skills.
However, even with his 37 years of coding experience and decades of working within the industry, Gauthier didn’t get the job. Here’s the 10 questions he was reportedly faced with:
- What is the opposite function of malloc() in C?
- What Unix function lets a socket receive connections?
- How many bytes are necessary to store a MAC address?
- Sort the time taken by: CPU register read, disk seek, context switch, system memory read.
- What is a Linux inode?
- What Linux function takes a path and returns an inode?
- What is the name of the KILL signal?
- Why Quicksort is the best sorting method?
- There's an array of 10,000 16-bit values, how do you count the bits most efficiently?
- What is the type of the packets exchanged to establish a TCP connection?
Yup, we're sweating too. But by other accounts, these questions aren't too tricky if you have a fair amount of knowledge in this area of computer engineering. So then, how come Gauthier didn't pass the interview? In his words, “Is Google raising the bar too high or is their recruiting staff seriously lacking the skills they are supposed to rate?”
› Google's "Director of Engineering" Hiring Test
Recently, I have been interviewed over the phone by a Google recruiter. As I qualified for the (unsolicited) interview but failed to pass the test, this blog post lists the questions and the expected answers. That might be handy if Google calls you one day.
For the sake of the discussion, I started
coding 37 years ago (I was 11 years old) and never stopped since then. Beyond having been appointed as
R&D Director 24 years ago (I was 24 years old), among
(many) other works, I have since then designed and implemented the most demanding parts of TWD's R&D projects* – all of them delivering commercial products:
Google's representative stated that both management and up-to-date coding skills were required (a rare mix). But having exercised the former for more than 2 decades and the latter for almost 4 decades was not enough: I failed to give the "right answers". Is Google raising the bar too high or is their recruiting staff seriously lacking the skills they are supposed to rate?
Let's have a look!
GOOGLE'S "DIRECTOR OF ENGINEERING" Q&A TEST
Here are the "highly technical" questions and their answers – until the test was interrupted as it was obvious that I did not fit the task:
1. What is the opposite function of malloc() in C?
Me: free().
Recruiter: right.
Thought: I imagine that in these rare moments you are supposed to feel proud of your 35 years of programming in the 40-year old C.
2. What Unix function lets a socket receive connections?
Me: listen().
Recruiter: right.
Thought: Does this make me really qualify as a network guru?
3. How many bytes are necessary to store a MAC address?
Me: six.
Recruiter: right.
Thought: I figure I just earned the [Ethernet] badge...
4. sort the time taken by: CPU register read, disk seek, context switch, system memory read.
Me: CPU register read, system memory read, context switch, disk seek.
Recruiter: right.
Thought: Typical Computer Science University (1st year) lectures.
5. What is a Linux inode?
Me: a unique file identifier for any given file system.
Recruiter: wrong, it's file metadata.
Me: the inode is an index uniquely identifying a file on a given filesystem, and you can lookup this index to fetch file attributes like size, time, owner and permissions; you can even add your own attributes on some file systems.
Recruiter: wrong, not "attributes", it's "metadata".
Thought: "Metadata" is more informative than "file attributes", really?
6. What Linux function takes a path and returns an inode?
Me: I wrote a custom LIBC for G-WAN, our app. server, but I can't remember any syscall returning an inode.
Recruiter: stat().
Me: stat(), fstat(), lstat(), and fstatat() all return an error code, not an inode; they fill a stat structure holding the file attributes discussed previously and not only the file's inode index.
Recruiter: that's not the answer: the inode contains all the metadata.
7. what is the name of the KILL signal?
Me: SIGKILL which #define is set to 9.
Recruiter: no, it's "TERMINATE".
Me: SIGTERM (15) is different from the KILL signal (9).
Recruiter: that's not the answer I have on my sheet of paper.
Thought: I guess that's what happens when AI bots discover recreational drugs.
8. Why Quicksort is the best sorting method?
Me: It's not always the case, nor even suitable.
Recruiter: Quicksort has the best big-O.
Me: "big-O" ignores data storage latencies, topology, volume, available memory, and even the computational cost of every CPU instructions involved in a given implementation – instead, it merely counts the number of algorithmic operations! Big-O can be a valuable indication when designing algorithms but the best performing and scaling solution depends on the particular constraints of any specific problem and environment.
Recruiter: wrong, you had to give me the Quicksort big-O score.
Thought: When will the OMS will recognize the tobacco-scandal patterns in the damages caused by Academia to public mental health? The Linux kernel (that Google relies on) opted for Heapsort rather than Quicksort... for its lower memory usage and more predictable execution time.
9. There's an array of 10,000 16-bit values, how do you count the bits most efficiently?
Me: you shift the bits right on all the 64-bit words, the Kernighan way.
Recruiter: no.
Me: there are faster methods processing 64-bit words with masks but I can't explain it over the phone, I must write code.
Recruiter: the correct answer is to use a lookup table and then sum the results.
Me: on which kind of CPU? Why not let me compare my code to yours in a benchmark?
Recruiter: that's not the point of this test.
Me: what's the point of this test?
Recruiter: I have to check that you know the right answers.
Thought: How long is this crap going to last? A 8-bit lookup table can process bytes one after another, while the 64-bit mask-based method processes 8-byte words at a time (on top of that, modern CPU instructions even let you process 128-bit words with a 10x speed gain if portability is not a concern). As a 64-bit lookup table is out of reach for today's computers, there's no doubt on what is faster.
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.
Thought: When you have to read hexadecimal packet dumps to find what's happening, 3-letter mnemonics won't help you to troubleshoot a dead network service. Maybe Google should have stated that practice is not necessary for the job.
On another hand, my score is four on ten, that's better than my best Google pagerank** ever!
(*) Google and TWD were both founded in 1998.
(**) Google pagerank: the ultra-secret mathematical formula demonstrating that sponsored search results rank higher than reality can.
Tip: hiring people that know things that you don't know helps more than hiring people who merely know what everybody knows.
Update: on October 13th 2016's night (almost 7 months after this blog post was published) we received reports that the gwan.ch hosted server was unreachable for a few hours and many emails were referring to a
"Hacker News" discussion where people claiming to work for Google denied that the questions above were really used by Google recruiters while others stated that they also have been interviewed by Google with the very same questions.
I did not find the time to read all the discussion thread but some entries were clearly not published to help others make any progress. Above all, my criteria for relevance in a debate is good will. I want to congratulate those who succeeded in doing just that, in a somewhat difficult environment.
I have not solicited this Google interview. Nevertheless, following the "Hacker News" episode, I received very interesting job offers and CVs from candidates willing to work with us at TWD – proof that many (if not most) understand in what world we are living. Many thanks to all for the great feedback, kind support, and for making me feel hope for the next generation of engineers.
I really wish I could afford to teach (and hire) everyone willing to learn. If I can't do better, one day I will write a book to help others do better than me – and I promise to publish information not seen anywhere else (open-source code, Academia, etc.).
All the best (Google
included).
