My Job Interview at Google | Hacker News Reader

My Job Interview at Google

catonmat.net

86 pointspkrumins107 comments

Isn't this level of interviewing kind of excessive and time-expensive? If I were Google, I would do the following:

1) Have the first interviewer be the best/most-appropriate interviewer for the position (manager, lead dev, whatever). Have them write down in a sealed envelope a "hire" or "no hire" statement after the interview.

2) At the end of the assorted interviews, measure how often the first interviewer is correct in his hire/no hire assessment.

My theory is that interviewing is a great opportunity for "thin-slicing" (a la Blink) and that you'd get 98% of the value with 10% of the time invested.

Related anecdote (from gladwell dot com):

One of the stories I tell in "Blink" is about the Emergency Room doctors at Cook County Hospital in Chicago. That's the big public hospital in Chicago, and a few years ago they changed the way they diagnosed heart attacks. They instructed their doctors to gather less information on their patients: they encouraged them to zero in on just a few critical pieces of information about patients suffering from chest pain--like blood pressure and the ECG--while ignoring everything else, like the patient's age and weight and medical history. And what happened? Cook County is now one of the best places in the United States at diagnosing chest pain.

Not surprisingly, it was really hard to convince the physicians at Cook County to go along with the plan, because, like all of us, they were committed to the idea that more information is always better. But I describe lots of cases in "Blink" where that simply isn't true. There's a wonderful phrase in psychology--"the power of thin slicing"--which says that as human beings we are capable of making sense of situations based on the thinnest slice of experience. I have an entire chapter in "Blink" on how unbelievably powerful our thin-slicing skills are. I have to say that I still find some of the examples in that chapter hard to believe.

I think people can be convinced of this by explaining this is a signal to noise ratio problem. If we have a lot of sources of information but if a lot of them have a lot of noise, it's useless.

you'd get 98% of the value with 10% of the time invested.

Hard to say. The economics of hiring aren't intuitive - a bad hire can do a lot of damage, esp. if it's a management position (which this wasn't, I know). It's probably better to nicely turn down 10 people (and nicely ask them to re-apply in 6 months) than to let in 1 charming, but conniving and free-riding bullshitter into your team.

I dunno-- I'm a big fan of "fire fast". If you can't detect a charming, conniving, free-riding bullshitter in 1-2 weeks of working with them, how are you going to detect 'em with 10 man-hours worth of interviews?

I don't see how firing someone after they've left their previous job behind is better for either the employer or the employee.

In this case, you'd also have to pay relocation/visa fees...

that's not very easy to do in a big corp environment. in a startup- it's a lot easier for both one being fired and the one doing the firing: being fired from a start-up can happen for many reason others than pure performance, where-as if one is fired from a bigger corporation that carries a bit more of a negative stigma with it.

in addition firing in a company like google is expensive: there's three months of training for a position like SRE (given they're scale at which google operates), during which they're paid a competitive salary (as usual), provided free food, flown out to mountain view (if from remote office).

i can understand why google would have the requirements they would: they want to maintain the start-up culture (everyone is working there by choice, there is a perfect culture fit) at a much bigger place and for a longer duration.

for what it's worth they're also open to letting people interview multiple times as well, for the same or different position. to this experience definitely help the original poster. he could come back within a year to interview (say) for a munich office position, where the competition wouldn't be as intense.

Those are actually really good points... Hiring people is more expensive than saying, "Sure-- come on aboard. We'll see how you do!".

That being said, I'm still not convinced that 10 hours of interviewing is any better than 2 hours of interviewing in terms of predicting success/fit in an organization.

I think 2 hours would be sufficient for 90% of the candidates. That's acceptable when you're in a start-up environment (where you generally have to fight for candidates and the pool is self-selecting to start with), but the 10% at Google could really make a big difference: google's pool of applications is bigger and the "laws of large numbers" come into play.

Also there's something else I haven't thought which is also a matter of "laws of large numbers": you simply can't hire every qualified one (and there would be opportunity costs in hiring the first person to pass the minimal qualifications).

Maybe there is a secondary objective for excessive interviewing:

"Hazing is often used as a method to promote group loyalty and camaraderie through shared suffering (male bonding in fraternities), either with fellow participants, past participants or both."

Hmm, really good point. And I suspect beyond that you can exploit elitism by making the process seem artificially hard.

It seems clearer if you think about the converse: If you were offered a job 10 minutes into an interview, would you value it as highly?

The "I got interviewed by Google" articles are getting old for me. I just don't care, and their process isn't that interesting anymore.

Agreed. They have, what, 20,000 employees now? It's as exciting as getting an interview at HP or IBM.

This is my recent job interview with one of the above comapany . Aug - 1st Interview Sep - We really like you but can you wait for 2 months? Oct - I have another job offering .. I called the Hiring manager to confirm if he is really going to hire me. his exact words :" Yes of coz , reject the other company . It's confirm we'll start in the new FY. Don't you trust me? End Oct - hey , I need you to meet up w another dept hiring manager .. and when I spoke to the new hiring manager I found out that the role is totally different and doesn't fit my profile and my experience

Later did I know he hired someone else for the role.

Too big a company , too many employess , to value you is not the 1st thing in mind.

My interview at Google:

First basic recruiter basic questions.

Second part, call from Mountain View to London. They couldn't organize a VOIP line that didn't sound underwater. They tried calling again and the line was still bad. They proceeded anyway.

I spent 5 minutes answering a basic question about deploying some changes across a thousand machines, then the interviewer mentioned he'd heard part of it, but how would I deploy it across a thousand machines?

I talked about things stored in inodes, including POSIX attributes, he asked for an example, I mentioned immutable. Google: WHAT? Me: IMMUTABLE. Google: WHAT? Me: IMMUTABLE. INDIGO MIKE MIKE UMBRELLA ...

The whole call went along those lines and was generally a massive waste of time.

Apparently they were going to organize a second interview with a working phone line. They haven't gotten back to me in the two weeks since.

Recruiters' decisions have nothing to do with how you actually are as a candidate, but are usually made on somewhat spurious grounds. Apparently, this is also true at Google!

At least the blogger that is linked to got the tired "well uh we've decided you're good but you don't have enough experience hurrrrr" excuse instead of silent treatment.

To give them credit, they are probably shoveling through thousands of candidates, so it's very hard to actually give them all a proper chance, and there are positive consequences (narrow the pool) for cutting people out.

I've seen this guys articles get posted on reddit/hacker news over the course of the past few years and he just seems like a tome of knowledge that keeps expanding at a rapid pace

Buddy, you have a lot of time on your hands and you're using it well, keep chugging along, looks like you're close to your dream job

About time to see the light and decide to start up his own company I'd think :) You always have to ask yourself whether a dream job is really about doing the work, or is it about being validated by the cool kids.

And yet Google didn't hire this guy for a lowly SRE position... Clearly their process doesn't work or they are just bluffing on interviewing people to cover their stock from falling and losing mojo with techies.

What I would really like to read is "My Job Interview at X"

X - any startups like Twitter, Friendfeed, Posterous, Kashless. etc

I think sometimes even the very well qualified (and Peter should be) do not survive the interview grind.

Would be simply silly if that off by one error was the cause for rejection.

Could be they didn't have any more H1B slots left. In my experience large companies just call in people for interviews, and only afterwards do they think about how/when they could hire them.

If that were the case, I suppose his big mistake was specifically requesting the Mountain View campus. It looks like they asked that question up front so that they could figure out which teams he should interview with; he might have stood a better chance at another campus.

He seems pretty excited for not getting the job.

Life goes on, why should I worry!

So why do you think you didn't get the job?

This is probably just interview #9 - seeing if he'll break NDA or trash talk Google after finding out he didn't get the job. You have to know how your employees will handle stress and frustration. ;)

"I got the green light from Google to publish this article"

No idea, pal.

I hear ya. Perhaps you should just tone down the exclamation points, though. It reminds me of the Seinfeld episode when Elaine used too many exclamation points in the manuscript she was editing.

Up until now, I thought your name was Mat Caton.

haha :)

Enough with the exclamation points. People at Google already sound so absurdly fake on a daily basis that it's nauseating. btw: They gave a BS reason for rejection -- they're in a hiring freeze now. Just look at the stock chart.

This particular writer seems to always be stoked on life. A solidly curious mind.

SREs are on call. That means they carry a pager/cell phone and must be accessible at all times. He should be happy he didn't get picked ;).

> must be accessible at all times

Nope, just when they're on call. I was snowboarding in Montana for a week last winter with my google SRE buddy, so I'm pretty sure about this :)

So he's not on call when he's on vacation and on a ski hill. Ask him about getting late night calls while with family during regular workdays!

When you work for a big company and you're getting paid a corporate salary, being on call just plain sucks. Period. I worked one job like that and hated it. I'd never do it again. If you work for your self or your own startup, well... then that's different :).

They have a call schedule, and only get called when they're on call. The size of google makes that a more solid rule than it is at smaller companies, I think. Plus they have a more lax work schedule when they're on call, to try and compensate.

I've worked jobs where you really are on 24x7x365 call, and it does suck, and google SRE is not like that.

And hey, it could be worse! Doctors can get called any time, by their most hypochondriac patients...

Could anyone point me on how to solve this(either a solution or preferrably a pointer on how to get to it): "Q: Given a function which produces a random integer in the range 1 to 5, write a function which produces a random integer in the range 1 to 7."

First I thought it was simple but the I got stuck, maybe I'm just tired. No matter how I twsit and turn it I seem to get only an even distribution over 5 numbers.

The elegant solution escapes me for now, but you could treat the odds and evens from the 1-5 function as a biased bit stream, apply a von Neumann corrector and then use the resulting stream.

Now I remember why we computer scientists always looked up to the Math majors...

Execute f 7 times, add all numbers, call that x. Then you do mod(x,7)+1, and you get a random number between 1 and 7. If the original function was unbiased, this one is going to be unbiased too.

This won't work. f gives 1 to 5. 7 * f gives 7 to 35. But 7 to 35 will not be evenly generated. Think about it: There are more ways to get a 20 than there are to get a 7 or a 35. Same thing with rolling 2 die.

That was my second thought too (my first thought was to upvote the comment), but at least in the 2-die case, the modulus takes care of it. If you work out the probabilities, the chance of getting 0mod2 = 1/36 (2) + 3/36 (4) + 5/36 (6) + 5/36 (8) + 3/36 (10) + 1/36 (12) = 18/36 = 1/2. Same goes for getting 1mod2. So you end up with a fair result even though the chances for each individual outcome are biased.

I didn't want to go through all 5^7 possibilities for the 7-die case, but I figured it's likely enough that he's right that I'd keep my mouth shut.

experimental evidence says that it is in fact a uniform distribution:

  r = random.Random()

  def one_to_five():
    return r.randint(1, 5)

  def mod_seven():
    return (sum(one_to_five() for x in xrange(7)) % 7) + 1

  def test_dist(lst):
    return [(x, lst.count(x)) for x in [1,2,3,4,5,6,7]]

i've tried it out experimentally in google docs and it looks really good for big numbers. No real proof tho and it might be that the errors counter each other by chance:

http://spreadsheets.google.com/ccc?key=pq4tB7LQWN03gF7ImGhIP...

Have a look at the distributions for each sum here: http://brianpmearns.com/ext/dice/dice.html

edit: Oops bad addition on my part, could be uniform, but you'd have to work out the actual number exactly.

here are the exact numbers:

1 -> 11177

2 -> 11172

3 -> 11158

4 -> 11144

5 -> 11144

6 -> 11158

7 -> 11172

...not quite

I've done a lot of Python but never knew about xrange - thanks!

f * f gives you 25 boxes, number 11, 12, ... 15, 21,...25...55. Assign 3 each of 21 of those to 1..7. If f * f doesn't fall into one of those 21 boxes, repeat until it does.

Runtime: O(infinity)?

Technically speaking, yes.

But, if you want to uniformly map a random number from set X to set Y where (IIRC) lcm(|X|, |Y|) != |X|, it seems you need an infinite worst-case running time.

Here's an informal proof that you can't have a finite upper bound to the number of iterations. After n iterations, you have |X|^n possible outcomes. But, since lcm(|X|, |Y|) != |X|, |X|^n cannot be divided evenly by |Y| (since its factors are the same). So some outcomes in Y must be more likely than others.

(This is not nearly complete, but hopefully it's enough to show how it might be right.)

Of course, in practice it is highly unlikely that you will get past more than a couple iterations before determining an outcome.

since lcm(|X|, |Y|) != |X|, |X|^n cannot be divided evenly by |Y| (since its factors are the same)

Can you go into more detail about this part?

Sure. Sorry, I didn't take the time to work this out on paper before posting or I would have realized that the condition itself is wrong. The condition lcm(|X|,|Y|) != |X| instead should be that |Y| has some prime factor that |X| does not.

Here is an explanation with the new condition:

Let p be any prime factor of |Y| that |X| does not have. It follows from Euclid's First Theorem[1] that p cannot divide |X|^n for any n [2]. Since every integer (> 1) has a unique prime factorization, it follows that |X|^n can't divide |Y|, because the prime p divides |Y| but not |X|^n.

[1] http://mathworld.wolfram.com/EuclidsTheorems.html [2] We are given that p does not divide |X|^1. Suppose that p also does not divide |X|^(n-1) for some n > 1. |X|^n = |X|^(n-1) * |X|^1, so by Euclid's First Theorem, if p divides |X|^n it must divide either |X|^(n-1) or |X|^1. We know it divides neither, so p does not divide |X|^n. By induction, this is true for all n > 0.

You're right in that my original reasoning was wrong. Thank you for your comment.

Ok, a less elegant one then, but one that works for a reasonably simple reason. f gives 1 to 5, if it gives 5, try again, and so on, until you have a number from 1 to 4. Then, do that mod 2. You have a random binary digit, that's unbiased.

Now use that process to get 3 binary digits. You get a random number from 0 to 7. If the random number is 0, start again... eventually you'll get a number from 1 to 7, and all numbers have the same chances.

I originally thought (f-1)6/4+1 = (f-1)3/2+1, but it's an integer... hmmm

gonna have to think about that some more

int rand17() { int t = rand15();

  if(t > 3)
      return t;
  else
      return 2 + rand15();

}

I dunno? will that work?

My team uses this as a screening question, so I won't give you the answer - but you forgot to mention that both the rand5 and rand7 should have a uniform distribution. :)

I'll give you a hint, though - the solution is not elegant at all. Which is part of the point.

Here's my shot at a solution:

;; * SPOILER? *

  (defun rand7 ()
    (loop (let ((result (+ (1- (rand5))
	   		   (1- (rand5)))))
	    (if (< result 7)
	        (return (1+ result))))))

;; * SPOILER *

edit: If it doesn't work I'd like to know why...

If you want a spoiler:

http://ariya.blogspot.com/2007/11/random-number-15-to-17.htm...

He gives a few different ways to solve it, most with uniform distribution.

Dumb/obvious idea: Generate 7 random numbers, pick the index that had the highest value. (If theres a tie, run it again!)

(Note: not guaranteed to terminate.)

1) Given a number 1 to 5, get a new one if it's 5, else throw away the MSB, you get 2 bits of randomness per number. Subtract one and call it a.

(Now you have two bits of randomness evenly distributed among the set {00, 01, 10, 11})

2) Get another number 1 to 5, toss it if it's 5, take the LSB. Call it b.

(Now you have another bit of randomness, evenly distributed among {0,1})

3) if b == 1 and a == 11, start over. else return (4b)+a+1

Python implementation (with the -1 then +1 factored out):

  def one_to_seven(debug=False):
    a = one_to_five()
    while a == 5: a = one_to_five()
    b = one_to_five()
    while b == 5: b = one_to_five()
    b = (b % 2) * 4
    if a+b == 8: return one_to_seven()
    return a+b

patio11's solution is about twice as efficient as mine, and is a much simpler way to think about it.

Generate two random numbers with your rand5 function, let them be the two digits of your base 5 number. Each number from 0-24 has a 1/25 chance of being picked.

If the number is greater than 6 throw it away and repeat, otherwise you have your random number.

Works, but not as efficient as possible. Look at patio11's solution; you only need to throw it away and repeat if it's >= 21. Otherwise you can just take n mod 7.

Observe the following lookup table, which is a 5x5 matrix.

12345 67123 45671 23456 7RRRR

R means "reroll".

Constant time execution in average case. Mathematically provable that it is as unbiased as your rand5() function. Technically not guaranteed to terminate but if you dock me points for that you're technically not guaranteed to survive to the end of the interview, are you.

Can't you just do this ?

    int rand7()
    {
        return (int)(7.0f * rand5() / 5.0f);
    }

No -- I get zero hits for 4 and 7 with this approach.

Ok, just to limit my embarrassment, I've implemented an alternative solution -- though not as good as the others.

First convert rand5() to rand2(). The LSB from rand5() has a uniform distribution for the integers 0--3:

    int rand2()
    {
        int n = rand5();
        return n!=4 ? n & 1 : rand2();
    }

Now we simply build a three bit number:

    int rand7()
    {
        int n = rand2();
        n |= rand2() << 1;
        n |= rand2() << 2;
        return n;
    }

This gives the proper distribution as well, but it's not branch free, so really nothing new here.

"The questions were about Linux systems administration, algorithms, computer architecture and C programming."

Couldn't you just Google for the answers to these questions in order to bring yourself up to speed where necessary? I'm not sure I see the value in trying to keep vast libraries of arcana in your head at all times.

Certain things goes a lot faster if you don't have to look them up evertime you have to do them. But then I haven't read the article, so what would I know? :o

They ask common questions as a proxy for experience in those fields. If you work with something daily, you will end up memorizing certain facts even if you don't consciously try to. It follows, then, that if you don't have those facts memorized, you haven't been working with that technology daily.

I stopped memorizing syntax a long time ago. It's been a few years and an the only thing I can recall about C's pointer syntax is ^ and & but the specifics are long gone. Not that long ago I had to look up the conditional shorthand (expression)? true: false in java etc. I have used around 12 different languages and I try and forget the stuff I am not using or I will mix and match syntax that does not work for the language I am programming in.

PS: I was classified with a learning disability back in school so this could just be me.

It's actually * and &. ;-)

Don't interview for positions in languages you've forgotten, then, or brush up and re-learn stuff before the interview. It's like riding a bike...it comes back to you.

Not being able to remember pointer syntax is a serious problem if you're being hired to program in C. I can understand why they'd want to weed out anyone who can't get that, particularly given how many candidates they have.

lol, thanks. I could have said x[i] is the same as ^(x + i) and really thought that was the correct syntax. The problem is I have used enough languages and dialects that I really can't brush up on it all. I just say if it's been five years, let me break out my cheet sheet for that stuff.

PS: Ok, if it was really just a C job of course I would focus on that.

Edit: Dammit it is like riding a bike. I have been having C flashbacks to horrible old code. O Malloc how do I hate the let me count the ways.

My solution to this problem was to make up sets of editor macros for the various languages I've used, with the same key chords producing the same semantics in varying syntax.

Maybe it was Visual C++ you were programming in. ^ is for a handle to a object on the managed heap so it's almost the same as pointer. http://msdn.microsoft.com/de-de/library/yk97tc08.aspx

I was thinking it was Pascal - I think ^ is the syntax for pointers in Pascal, but the last time I programmed in that language, I was 12.

Yep, pascal had ^ and @.

Around 5 years ago I was spent a lot of time working with really old Object Pascal and some C code that was upgraded to OS 8/9 and then left to rot. Let me just say that low level networking code on a OS that does not have threads is a PITA. They had something like interrupts but you could not allocate memory during them. You had to first allocate using Handel's and then do something before working with actual pointers as part of your run loop and then use that memory during the interrupts. Meh, I think it might have been the most fun coding project I have ever been on, but I don't want to do that again.

Not only that, but it seems like he was penalized for very common quick to fix errors. I'm not the best programmer ever but I always forget to initialize a data structure or forget a semicolon. I always catch the error when compiling or testing. It's like penalizing someone for a grammatical mistake. Some make more mistakes than others but no one is perfect.

Part of the interview is an intelligence/memory/experience test. They don't want to use rigid requirements ("must absolutely have five years experience") and it would probably be illegal to administer an IQ test (and the sort of intelligence IQ measures isn't always the same as the sort of intelligence needed for the job).

In addition their culture seems to be that once you're on the job (as a salaried employee vs. a contractor) they'll do all in their powers to ensure you aren't laid off, get fired or quit out of boredom: you can freely move from team to team, you generally work flexible hours and with little micro management. The tough hiring (with far too many false negatives but no false positive) requirement is why they're able to mantain such a culture.

I've heard you can freely move from team to team, but only if its one of the locally staffed projects at your office. Location makes a big difference.

What are the likely reasons that he did not get hired?

Seems like a brilliant programmer, but for whatever reason that wasn't enough.

It's not clear whether they actually hired anyone for the position (there are contradictory opinions in this thread as to whether or not Google is hiring at all right now).

Possibly meaningless anecdotal evidence: I know a number of people who have had internship offers from Google in the last couple months. I don't think any of them accepted though, so maybe they aren't paying as well as they used to. Also, I don't know what hiring interns says about hiring regular employees.

I'm curious too. I've enjoyed his blog posts ever since they first appears on Hacker News.

"... Then I found all the other blog posts about interviews and interview questions at Google ... She told me she was working at Google for two years and was very happy about it ... We went to Asian food restaurant (located in Googleplex) and I had all kinds of delicious foods. All free! ..."

I'm still wondering, who's trying to game who?

Worry not, take that as an opportunity. I'm sure you're a talented hacker. I've been reading your articles and I guess you like to learn a lot on your own. Match made in heaven for a startup guy. I sense that had you been employed by Google you might have left it after some time to start something on your own. Why not now :)

Google isn't hiring anymore out of top management or very specific exceptions.

Citation needed.

I thought it was on the front page http://www.webguild.org/2008/11/google-layoffs-10000-workers...

Similar leaks are being posted every other day.

It seems today it got broader attention.

http://www.reuters.com/article/ousiv/idUSTRE4AO1LI20081125

http://www.forbes.com/afxnewslimited/feeds/afx/2008/11/25/af...

And everybody mentions WSJ as source but couldn't find the original, perhaps it's offline only.

Yeah, no mention of (mostly) not hiring but I am very sure of that, too.

Not true.

Citation needed.

(Seriously, two totally contradictory opinions on this, wondering if there is any actual evidence either way.)

I asked my recruiter specifically if they were in a hiring freeze (I'm in the middle of the application process now), and she was very adamant that they were not. If they were, they would lay off the whole HR department, except for a skeleton crew needed for benefits and such. After all, why spend ~40M/year on recruiters if you're not recruiting?

Retention. Turn-over. Keeping a "hot list". Getting rid of under-performing groups by replacing them with new blood.

Those are some of the reasons. Also sometimes HR departments are just several months behind the times.

Not trying to rain on your parade. I just wouldn't take that argument too seriously in a general situation. In this particular situation, I think Google is doing great and believe they probably are hiring.

Who lays off the layers-off? HR departments look after themselves.

Executives?

One company I worked for, they always used to be run by people who'd come up through the line of business, the thing the company was known for. Somehow, tho', they ended up with the company lawyer as CEO and the former head of HR as his lieutenant. It was all downhill from there but the HR department I assume were happy, since they were now consulted on every action...

"500 of them were recruiters for Google." (link above)

Lay off the entire HR department? The only reason you'd do that is if you were in a permanent hiring freeze death spiral. Recruiting works as a pipeline. So even if you're in a hiring freeze, which Google likely is, you still want to have folks lined up for interviews.

Worst case scenario is that you end up interviewing a bunch of folks and can't offer them a position. However, if you just stop recruiting activity altogether then you'll have more than a month worth of lead time to start getting new hires after the hiring freeze is lifted.

2 of my friends have been hired within the last couple of months.

One of the Dojo guys just got hired yesterday:

http://alex.dojotoolkit.org/2008/11/joining-google/

So obviously they are still hiring, they're just really, really picky.

Looks like you just dodged a bullet given the layoff announcement

Seems like the engineer in the comments section summed it up the best. You were probably really close to getting the job, but a few to many mistakes tipped it against you.

There are 2 types of interviewers in corporate environment.

1. One who hires 2. One who recommends to hire

Avoid getting interviewed by 2.

Reply on news.ycombinator.com