failing like never before

My Google Interview

Its been a while now, but here it is anyways...

About six or seven weeks ago, I scored a phone interview (technically two) with Google's IT department for a summer internship. Nobody was more surprised then I was that Google actually found my resume somewhat impressive enough to warrent a phone interview, especially considering my less-then-stellar GPA and the enormous number of super-intelligent applicants Google recieves every day. The two interviews were each forty-five minutes long, and the interviewers (both intelligent IT guys,  and not technically incompetent manager types) took pretty much all of the alloted time.

These days, almost every CS guy dreams of working for Google and so I've heard a few things about their interviews before, which I would like to mention before I get into my interview. A few years ago when I was an intern at Intel, they had a lady come in to tell all the high school interns about how to be successful in scoring future jobs. She spent a lot of time teaching us how to walk properly, shake hands, sit in a proper manner, dress, and answer generic interview questions. She told us that Google interviewers like to ask broad open ended questions like "how would you sell ice to an eskimo" and "why are manhole covers round," and promptly put us to answering similar questions. A few months later, I went to a Google Tech Talk at my University, where a Google software engineer was asked by someone in the audience if Google did in fact like to ask interview questions like "why are manhole covers round." The Google rep resonded with the following:

"In my time at Google I have interviewed several software engineers and I have never asked a question like that before. Google is not in the business of making manhole covers. If we did make manhole covers, we might ask those kinds of questions."

I think occassionally, a Google interviewer might throw in a brain teaser if they just want to burn some time, but apparently they don't do it too often.

Anyways, going on to my interview... I was interviewing for an IT position, so unlike the software developer positions where they barrage you with an endless stream of algorithim and programming questions (Why is quicksort log(n)? Whats the best sorting algorithim to use in this scenario? What data structure would you use for this? etc.) there was almost no programming invovled in my interview. And since the recruiter and HR person told me pretty much nothing about what I should expect, I went into the interview pretty much cold.

The first guy I interviewed with started off by asking me how comfortable I felt operating in OS X, Windows, and Linux. This was a bit of a surprise to me, because the job description online said that I should be expecting to be working in an almost pure Microsoft environment. But as the interviewer told me, Google employees have a wide range of choices in what OS they choose to run on their company machine, so the IT department has to support pretty much every system avaliable. I'm really not much of an Apple guy, so I couldn't really answer more then a few of his OS X questions, things like, "how would you kill an unresponding application," and "how to boot from a CD on a Macbook." I think that since I told him that I've never been more then a casual user of OS X, he decided to keep his questions on Apple OS X brief.

But then he really got down to quizzing me on Linux stuff, which is were I pretty much pwned. He started off with some fairly basic questions like and scaled them up a little bit.

How do Linux permissions work, and what does "chmod 741" do?

How do you check running process on a system? How would you force-kill a program that is totally unresponsive? And what happens if the program doesn't respond to a "kill <PID>"?

Briefly describe the TCP/IP stack.

How would you check file sizes using the command line and how would you make the results "human readable?"

How would you list all the files that start with the letter "t" in a directory and all subdirectories with one command?

What commands would you use to check your internet connection, and how would you go about "debugging" your internet connection?

How would you set a static IP?

If you were setting up a new installation of Linux for a personal computer, how would you set the partitions?

(Note that these aren't all the questions he asked, its been a while so I can't really remember everything.) He seemed to really care alot about network type stuff, so I would suggest that anyone else interviewing with Google's IT department definitely review networking. As I said, I pwned this section of the interview, and it was probably all the Linux questions that got the interviewer liking me. I don't think it was the fact that I answered all his questions accurately that he liked so much, but rather the fact that I barely had to hesistate when answering him. Also, on a few of them, I was able to give more details then I think he really expected.

There were also a few Windows questions asked, but I can't quite really remember any of them. Most of them tended to be networking type questions.

When it got towards the end of the first interview, I asked a few questions and in talking about things, the interviewer found out that I had been an avid Linux user for a few years now and that I was currently running Arch Linux. This seemed to impress him a bit. The interview ended on a pretty good note, the interviewer saying they would find my skills useful, and even though I had been weak on the Windows and Mac questions, I felt pretty good about the interview as a whole.

The second interviewer was completely different from the first. He was a desktop support guy, and instead of focusing on broad software questions, he would present me with a real world case of a failed computer and ask me how I would determine the cause of the failure and how would I fix it. His questions were rather long, and sometimes a little irritating; whenever I gave a possible explanation for a failure he would respond with, "but lets say there is nothing wrong with that part, then what would you do?"

Here's one of the problem scenarios he started out with:

Let's say that a user comes to you with a Windows machine, and they tell you that when they click on a program icon on their desktop, nothing happens, what do you do?

<my response>

Now lets say that no error messages are being printed. And lets say that even when you start the program from a command line, you get no errors.

<my response>

Now lets say that the user hasn't installed any updates to their operating system lately.

<my response>

Now lets say that even after cleaning out the configuration files, still nothing happens.

<my response>

Now lets say there is nothing wrong with the registery files.

<my response>

Now lets say that no updates have been made to this program they are trying to start, the program hasn't been changed at all since it last worked.

<my response>

Now lets say that you haven't done anything to your antivirus or firewall.

<my response>

Now lets say that you even after reinstalling the program you still have the same problem.

<I think that even after this, he kept going, but by then I was grasping at straws.

And yes, he would always start off with "now lets say..." I'm not going to  lie, it got a little annoying after a while. So as can you see in the above scenario, his questions could get pretty tough. Here are a few other questions he posed to me:

How would you figure out why a computer wouldn't boot?

How would you recover the data from a computer that won't boot (because of a corrupted boot-sector or something)?

How might you go about fixing a computer with a corrupted boot sector?

How would you help improve the performance of a Windows machine? (You'd think that would be an easy question, but he wanted alot of answers.)

I was always able to provide answers to his questions, but in the end, I don't think I was able to provide as much as he wanted. In my opinion, this is were I lost.

Anyways, this is about all I've got. Feel free to drop me a comment.