Interview with Google

Recently a friend of mine at Google put a shout out for positions at Google over in Sydney for Software Engineers (SEs) and Site Reliability Engineers (SREs). Not exactly sure what to expect, I sent in my resume for an SRE position - knowing that if I didn't make the cut, that would rule out applying for Google for the next 18 months.

Much to my suprise, I got an email back from Google the next week asking for a brief pre-screen interview. After a bit of back and forth with the guy over email we scheduled a short phone interview.

By this point, I was getting a bit anxious about what kind of questions they'd be asking. I've conducted a fair few interviews from, and whilst I understand the basis for behavioural questions during an interview - looking online at other people's Google interview experience makes it seem like the type of interview that could only be thought up by a crazy Japanese game show director.

It also doesn't help that the majority of technical positions at Google are in Software Engineering, not Systems Engineering (or Site Reliability Engineering, should I say). This rules some (but in no way all) questions about algorithms and complexity.

Anyway, on to the good stuff - on the day and hour of my interview I headed down to a cafe around the corner from work and took the call from one of the HR folks over in Sydney.

Skills self-assessment

The first thing they cover is a self-evaluation of your skills in a number of areas, mostly programming languages and linuxy stuff. Ones I can remember are: Linux Kernel; Java; Perl; Python. (PHP definately wasn't in there folks, in case anyone was wondering).

Rating yourself between 1 and 10 sounds easy right? Not so. In a Google interview, 10 means you invented the technology, 7 means you've written a book on it and 5 means you consider yourself competent in it. So you'd hope most of your answers lie between 5.0 and 6.0. The upside to this evil scale of doom is that it really makes you think about where you fit on the number line, and I guess that at the end of they day they must get much more realistic figures because of it.

So after answering those questions the interviewer confirmed that I do have some industry-relevant skills (I know what a computer is, and I don't wait tables) and that my skillset leans strongly towards systems administration/engineering - which is even more reassuring as that's what I do for a living. Affirmation is good.

Now onto the hard stuff! Following are a bunch of questions that pretty much reflect what you see on other Google interview sites. I didn't make notes so these are written down as best as I can recall them.

Question: Of the following protocols (TCP, UDP, ICMP), which would most commonly used for the following uses: HTTP, Ping, and Video Streaming.

My answer: HTTP uses TCP, Ping uses ICMP, and streaming video would use UDP.

In retrospect: I should have mentioned that DNS supports TCP, and if the request exceeds the UDP packet size, it will force over to TCP.

Question: Order the following operations in order of speed (fastest to slowest): disk seek; access cpu register; read from memory; context switch.

My answer: Access CPU register, read from memory, context switch, disk seek.

In retrospect: I'm not actually 100% certain that the read from memory would be faster, it depends whether or not the program code is already in the L1/L2 cache. More thought required.

Question: What is the linux system call to retrieve most of the metadata associated with a file?

My answer: Pass (it's been ages since I've done anything this direct).

In retrospect: The guy doing the interview half prompted me asking if "stat" sounded familiar. It surely does and is the correct answer, so I said yes - not sure what the marking for that would be like though.

Question: What are the three datatypes in PERL?

My answer: Array, Hash, Reference and... Scalar.

In retrospect: This one tripped me up a little bit, because PERL is really an untyped language... I listed the primitives but had a mental blank when it came to the name of the scalar. I explained my thought process through this however, so I think I still did favourably.

Question: You have an array of 10,000 16-bit integers, and you want to count the number of set bits on each one. Available memory is unlimited, how would you proceed to perform this task.

My answer: I'd just do a single pass.

In retrospect: Okay this question is a bit complicated. First off, I asked what the data would be used for - as in, whether we'd be doing lookups on it or just wanted to process the data. The interviewer told me it was only needed once. For a straightforward operation like this, on a relatively small number of objects - I can't see any application specific reasons you'd need to get fancy (unless I've missed something obvious in the question), however I didn't convey this justification to the interviewe - so I'm not sure how I faired on this question.

Those are all the questions I can remember, though I seem to recall something about optical media coming up. I'll have to refresh my memory with a friend of mine who took the interview the day before (interestingly he had the exact same set of questions with one exception).

Anyway, the interviewer seemed to think I did okay, and he seemed to think I'd be getting a second interview (though he couldn't make any promises obviously). In either case, I'll hear from them within two weeks from the initial interview and find out what the go is.

If you progress past the pre-screen interview, there are another two telephone interviews between 30 and 60 minutes long each - and if you progress past those you get an on-site interview at your local Google HQ.

Cripes! I'll keep y'all posted on how I go :)