What I learned interviewing with Google

http://wesbos.com/interviewing-with-google/

by wesbos • 14 years ago

164 137 14 years ago

wesbos.com

findm• 14 years ago

Your site is down for the count.

wesbos2• 14 years ago

hah sorry :\ Just refresh and it should load. Time for a new server.

oinksoft• 14 years ago

I'd not use GoDaddy hosting if I were you :^)

Matt_Cutts• 14 years ago

I'm glad that you had a pretty good experience overall. I know that lots of folks at Google have worked to try to make interviewing less painful (like limiting the max number of interviews you'll have to do). It's nice to get an independent datapoint where the experience was pretty good, even if it didn't work out this time.

uberPhil2• 14 years ago

Sometimes I feel like it's a total crap-shoot with getting interviews at some of these large companies. There were quite a few positions available in the DC Metro area that I was probably more then qualified for or at least qualified enough to get a phone interview. Needless to say, I was never contacted. It's good to know that some people actually get to a phone interview :)

thinkdevcode4• 14 years ago

Do you really want to be subjected to coding on a whiteboard?

Edit: Instead of down-voting, why don't you explain to me why you would want to code on a whiteboard when it's completely pointless. Might as well throw in some of those pointless questions like why are manholes round?

uberPhil2• 14 years ago

do employers really expect candidates to right syntax accurate code on a whiteboard? I just always assumed that pseudo-code was appropriate. There are a lot of key strokes that my fingers know but my brain doesn't. It's very easy to get confused and thrown off your game.

knieveltech• 14 years ago

I'm with you on this one. I don't get the whole whiteboard code thing and I have no idea why you're getting downvoted. :/

jemfinch• 14 years ago

I work at Google. We write (diagrams and code) on whiteboards on a regular basis. We don't ask you to do it during an interview because we're sadists, we ask you to do it during an interview because working here, you will be doing it in the course of your ordinary work.

Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.

jimbobimbo2• 14 years ago

I can't downvote, but I fail to see what's the problem with "coding" on a whiteboard and why people are stressing out over it. When I interview people I ask them to write code on the piece of paper. All I'm looking for is a presence of a half-decent idea and them not using things like strlen() when iterating through a C-string in their doodles. The rest we will talk over. I never expect polished code on the whiteboard, it's always a starting point for a conversation that follows.

csallen2• 14 years ago

Not too long ago I would have agreed with you, but I've recently changed my mind. Coding on a whiteboard is not completely useless:

1. It's a good indicator of how much you know for simple problems.

A few weeks ago I started helping a friend with a particular language and framework. He claimed to know it, having read several books on it. So I said great, go to the board and write a function that adds two numbers together. And he couldn't do it. Who knows, maybe he could have done it on a computer? Maybe he would have Google'd it quickly, or relied on code autocompletion, or the muscle memory from his fingers typing it, etc. But that's not what I wanted to know. Anyone who's written thousands of functions in a particular language could write a simple one like this on a wall, using paint, while hanging upside down. His inability to do so told me: he is not well-versed in this language. PERIOD.

2. You can practice.

"So what", you protest. "Google isn't going to ask simple problems. They'll ask hard ones." And maybe they will. And maybe having to solve it in a foreign way really will fuck you up. But my question to you is: If you know you're interviewing at Google soon, why the hell would you allow whiteboard coding to remain foreign to you? If you suck with whiteboards and you care at all about getting the job, then buy one and practice solving problems on it. Why would Google want someone who doesn't care enough to prepare for their interview? It's not that hard of a skill to pick up. And I daresay it will make you a better, easier-to-communicate-with programmer.

jrockway4• 14 years ago

Yes. I like it.

Whiteboard coding is good because interview questions are not about specific 100% solutions to complex real-world problems like programming usually is. Interview questions are about general problems whose solutions will fit nicely onto a whiteboard. You lose the ability to get realtime syntax highlighting, but you gain the ability to have multiple trains of thought, the ability to draw diagrams and arbitrary symbols, and the ability to point at things as you explain your thoughts to the interviewer. Do you really enjoy it when someone comes over to your laptop to ask you a question about code? Now imagine that for four hours in a row. That's what a laptop interview would be like.

When I was interviewing at Google, someone asked me a question that required me to remember some math. I did not remember it, but I knew how to derive the answer I needed. So I went to another whiteboard, talked my way through the sub-problem while drawing some math symbols, and then transferred the answer back to the original problem, halfway completed on a different whiteboard. Try doing that while hunched over your laptop.

I agree that this process is nothing like the job you're interviewing for. That's because it's an interview, not the job. We try to get a picture of who you are and what you know in a few hours, and that's just not enough time to let you loose with a laptop to see how you approach real-world problems. Not to mention, real world problems don't often involve much "computer science" knowledge. But you still need to know that so you can confidently attack problems that venture into that area.

And largely, the process works. There are very few programmers at Google that can't program. If I have an idea, I can explain it to pretty much anyone, and get good feedback. At other jobs I've had, I've had to explain thing like arrays to coworkers. That means I'm not going to get any feedback on my complex idea, and that sucks. Google is not like that, because we filter those people out at the interview.

matwood• 14 years ago

Coding syntactically correct code on a whiteboard is a waste of time. Drawing pictures, diagrams, and pseudocode while trying to solve a problem with others is a great way to get collaborative work done.

dblohm7• 14 years ago

Once upon a time I was working with a psychologist who wanted me to do a take-home exercise. Knowing that I was a software developer and an excellent typist, she insisted that I perform the exercise while writing by hand. She said that it was because I would be using a different part of my brain when handwriting than if I were typing.

Which brings us back to the whiteboard interview. I ask: If I am correctly interpreting what the psychologist said, why force interview candidates to use their brains differently than they normally would while coding?

marcog1• 14 years ago

The big companies get so many candidates that they can't possibly do all applications justice. So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen.

barik• 14 years ago

"So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen."

This is probably the best piece of advice you can give for starting the job application process. Having an internal person already working in the company recommend you to HR will immediately put you on the top of the queue. At the very least, you'll get an initial phone interview quickly. This is, in fact, the only way that I've able to have successfully get in the door, at both small companies and also larger companies like Google and Microsoft.

The other option is the "career fair", but that tends to only work if you're still a student or near-student status.

varelse6• 14 years ago

Google only hires 1 in 1000 applicants or so (at least that's what they tell you on day 1). Try not to take it personally that you failed buzzword bingo with their recruiters.

Perhaps someone should take a look at your resume to find out why?

djb_hackernews• 14 years ago

DC office is funny. It's so small it doesn't have it's own recruiters. The recruiters in Denver handle recruiting in DC. So if you want to interview, talk to them.

Also, if you do interview, keep in mind you'll have to travel to MV for a full day interview and also a full day interview in DC. Which is actually nice if you have the time; the DC team is so small that they want to be selective with future team members.

The DC projects were cool too, one was google code I believe, and the other was a tool to allow the collection of data sets such as water well tests in developing Africa, etc.

shtylman• 14 years ago

Why would you sign an NDA for a job interview?

mapleoin• 14 years ago

Some big companies make you sign an NDA the moment you enter the door. I always assumed it's natural for ugly corporatey giants.

bstpierre3• 14 years ago

I've interviewed for small companies that want an NDA at the front door too.

jrockway4• 14 years ago

I don't know if this is the case for interviews or not, but in general, you do not have to sign the NDA to visit Google. If you choose not to sign it, you get a different looking name sticker, and Googlers have to be careful not to show you anything that could be confidential. You're also restricted to common areas; you can't see your friend's desk. If you sign the NDA, you are allowed to see everything (within reason), and Googlers can be a little less guarded around you. But if you just want to have lunch at Google or attend a LUG meeting, you can do that without signing anything. In theory.

objclxt• 14 years ago

This might just be me, but I interviewed with Google on-site about 10 months ago and never signed an NDA.

It wasn't even offered to me - and this was for an engineering job. So I wouldn't say it's 'standard', even at Google. That said, I've also never seen anyone blogging about their Google interviews who hasn't signed one, so maybe they just forgot the paperwork for me!

spacemanaki3• 14 years ago

There are some extraordinary situations where it really does make sense: an example I read on HN a long time ago was the first cellular radio engineers that Apple hired before building the iPhone. The simple fact that they interviewed for a job might have been under an NDA. This desire to protect secrets probably gets extrapolated and trickles down to every technical candidate.

paganel• 14 years ago

> Why would you sign an NDA for a job interview?

Because they're Google. I know that's tautological, but I remember a blog post from some time ago about a guy complaining that all his friends that had been hired by Google had suddenly stopped chit-chatting about technical issues that they encountered at their workplace. They stopped doing that during the usual "at-a-drink-complaining-about-our-daily-job-ordeals" sessions, or on their blog, or anywhere else that might be publicly shared (and, why not? , maybe help other people learn from their (Google's) mistakes). The guy even compared Google with a "vortex", if I remember correctly.

jarek3• 14 years ago

post in question: http://apenwarr.ca/log/?m=201103#24

HN discussion at the time: http://news.ycombinator.com/item?id=2362207

prostoalex• 14 years ago

Because that allows for more casual conversations than "So what are you working on here?" - "Oh, can't tell you".

illumen• 14 years ago

I make development software for companies like Google. Currently their biggest demand is to be able to use their white board instead of the keyboard+IDE for input. We call it an IDW, Integrated Development Whiteboard.

Also, they need tools to help them develop different sorting algorithms and link lists. Plus they are having trouble with binary trees, but link lists and bubble sorts are their number 1 priority!

Instead of more advanced performance modeling, they want to use this non-sciency thing called Big O notation. Once they write a Big O notation on the IDW(Integrated Development Whiteboard) they expect it to go that fast. If it doesn't go that fast... they just chuck more servers at it (we supply their servers too, so Big O makes us happy).

They also want us to provide them with flannel shirts and dr martins for uniforms. They say that 90s clothes help them with their interviewing techniques, because it helps them remember how interviews were done in the day; when they were edgy.

ender7• 14 years ago

Part of the point of the whiteboard is that it's not a real development environment. Google interviews are usually designed to test how you think, not how well you can place a semicolon. The point is, it's okay if you miss a brace or forget the name of a method. It also allows you to mix diagrams and psuedo-code in with 'real' code in an easy way. (also, I can't think of a better environment to give them. You can't provide everyone with their favorite IDE with all the code hints, so in the end it's just going to be a dumb text editor anyway)

Working on a whiteboard is definitely a skill, but one that's worth developing if you plan to work with others on a complex project.

That said, they really shouldn't have been giving this guy standard CS questions. Sure, you want to make sure that he understands why writing his string concatenation loop the wrong way will result in O(n^2) behavior, but he was interviewing for a front-end position.

nostrademons8• 14 years ago

The front-end interviews are a mix of front-end focused interviewers and gen-eng interviewers (usually 3 & 2, respectively). That's because the frontend-SWE position involves writing JS/HTML/CSS to run in a browser, but it also involves writing the server code that generates that JS/HTML/CSS (same reason that Java or C++ is part of the job req). We care very much about efficiency when your code runs on tens of thousands of servers.

There are also a bunch of algorithmic questions that come up in the browser as well, because unlike a lot of sites, Google actually cares about latency. You often can't use a library function if it involves pulling in a 300K library, nor can you write an O(n^2) algorithm if it involves locking up the browser.

minikomi• 14 years ago

I heard they almost have their spam filter down ... They have discovered every third mail sent is some form of cola advertising, and every fifth mail sent is empty words used to drum up hype.. Can no-one think of a way to mark those mails?

alexgartrell2• 14 years ago

The forty yard dash provides one of the most important signals for football recruiting. Essentially, it's a measurement of the time from when the athlete takes his hands off of the start line to when he crosses the finish line. Most commonly, it is run in cleats on grass with no pads, and certainly no players trying to prevent you from reaching the goal line. In addition to that, the best technique for running a forty, literally falling forward to build momentum before lifting your hand off the ground, is actually illegal for offensive players (and pretty pointless for defensive ones).

So why is this completely unrelated activity so important for measuring football players? Because it takes ten seconds to measure, and a guy who can run a 4.2 forty can almost always play pretty damn well.

Tech interviews today are a low cost way of getting a rough idea of ability to code. Judging from Google's output, it's pretty damn effective for them.

rjsen2• 14 years ago

Except that the 40 really isn't a very good measure - if it were, the Oakland Raiders would be winning the Superbowl every year instead of missing the playoffs. Of the 15 fastest players in the last 12 years (http://en.wikipedia.org/wiki/40-yard_dash), only 2 are stars, and most are bench guys or out of the league. The 40 has its uses, but it needs to be taken as one fairly small factor in evaluating a player, and even then it's only really relevant for certain positions.

Similarly, coding algorithms on whiteboards doesn't tell you much other than how good the candidate is at coding algorithms on whiteboards. Given that the vast majority of their revenue comes from either search (which was built over a decade ago) or companies they've acquired, and the numerous well-hyped failures (Buzz, Wave, +, etc.), I don't think it's actually working all that well for Google either.

jumby5• 14 years ago

Really, then why aren't all 100meter dashers excellent football players?

jdlegg• 14 years ago

This is almost the definition of false analogy.

fingerprinter• 14 years ago

This thinking is exactly what Moneyball was all about in Baseball. Football looking at the wrong things.

For instance, 225# reps, vertical leap, reach, etc (all NFL combine measurements). Great, you are measuring and ranking, but are you doing anything meaningful? Are you actually looking at the right things? Probably not.

If they were, Wes Welker, Tom Brady, Victor Cruz (all in the past superbowl) would have been first round picks, probably top 10. Not undrafted, or late round picks. And JeMarcus Russell and Ryan Leaf wouldn't have been drafted #1 and #2 overall (all the physical tools but not the mental - flame outs).

The point is that we as people tend to think we know what to measure and track, but we likely don't. Frankly, we are probably making it up on the fly and we convince ourselves and others that these are good measures, and until someone figures out the next best thing, they actually are. But, as I said, they are probably not the best, or maybe even good, in the infinite wisdom sense.

But, think about it this way. Both football and programming have ways we can actually see if someone can do what they say that can do: literally, look at the film. Look at game day film on a player. Look at github or other places for programmers. And, just like with football players, give them REAL scenarios that test their ability to think through a problem, in real time. Do the same with a programmer. Put these two together and you get rid of the people who can't think (Russell and Leaf) and you get rid of the "physical specimens" that can't play (Most any Oakland WR drafted under Davis).

I personally think this is a much better way that weeds out the most people. Refine your questions and technique and you can spot the people who can and can't perform pretty quickly. If you are unsure, give them a simulated game (programming problem at home) to see what they can do.

kamaal2• 14 years ago

Strange, These days very little to zero development happens without IDEs. I don't really know why anybody should expect to test somebody's skills without an IDE.

That's because today a term called 'Productivity' has become massively more important than any thing else. Its something like this, Lets say there is an archer. He can shoot the red dot 9/10 of times with his bow and arrow. You take away the bow and arrow and give him stones and ask him to match the same 9/10 hits on the red dot. Guess what, he won't be able to, May be with time he can. But for the time being he can't.

What does this say? Does this mean he is a bad archer? No. Tools and their usage is part of the trade.

No skill can be tested in Isolation.

varelse6• 14 years ago

Well, here's what I learned interviewing at google:

Be very good at off-the-cuff 80% solutions to topcoder problems on a whiteboard, which I am. So much so, that when they told me to use whatever sort algorithm I wanted to, I used bubblesort on purpose, to prove a point, and got away with it. Later on, I reduced another interviewer's search problem to a polynomial equation that had integer roots when a solution existed (at which point he asked me what I'd do on an architecture that didn't have a square root or a divide function and I replied "and what modern architecture would that be?"). Which is to say their interview process is a computer science puzzle game IMO. The skills displayed here have at best a loose correlation with one's engineering skills, and that non-correlation shows up like crazy in their codebases (but Steve Yegge already covered that far better than I can).

So if you are a demo coder at heart, and you've been paying attention to whatever technologies are the flavor of the month at google interviews by reading blog entries like this (apparently javascript these days), you'll do just fine.

In my case, it only took one round for me to get the offer which I (unfortunately) accepted (but the tale of my 4 godawful months at google thanks to naively letting myself get blind-allocated into the wrong team is a different story).

Google is a great company, really it is. I know lots of relatively happy people there, but focusing on the interview process is a mistake. The real challenge is to get yourself hired onto a good team by resisting all the pressure they exert to persuade you to jump into the blind pool, which is a recipe for russian roulette. The solution, which in retrospect I smack myself for not doing the due diligence to find out, is to insist on getting allocated to and speaking with your future team as a condition of accepting an offer. Do not compromise on this point.

charolastrauno• 14 years ago

What team and why was it so awful? I agree that the pool system sucks.

Jabbles• 14 years ago

What point did you prove with bubble-sort? Was the list already nearly-sorted?

wisty2• 14 years ago

It sounds like it would have been like this:

"Next step - we sort it".

"How?"

"It doesn't matter. You just sort it. I'd use the inbuilt sort function".

"OK, but we still want to know you can sort a list."

"OK ... sigh ... what algorithm? Quicksort? Bubblesort? Mergsort?"

"We don't care."

"Um, OK, if you want me to roll my own sort algorithm, but don't care about performance, let's do it this way ..."

gcp2• 14 years ago

on an architecture that didn't have a square root or a divide function and I replied "and what modern architecture would that be?"

ARM?

What did I win?

varelse6• 14 years ago

A snarky reply about me having previously rolled my own divide and square root functions on videogame consoles in assembler, happy?

ned_roberts• 14 years ago

I'm in the process of negotiating for an engineering job with Google now and it's been extremely difficult to get any information about what positions they're actually hiring for. When I was there for the interview there was very little time for me to ask any questions about what the teams actually do and what I might be doing if I joined. This is very different from every other interview I've had before where I'm talking to the team members I would be working with.

Later, after talking with an engineering manager and getting agreement to be assigned to one team, they tell me I'll be working for some other team as if our conversation never happened. It's almost as if the attitude is that I should be lucky to have been offered a job and I should be happy with whatever I'm given.

varelse6• 14 years ago

My allocation seemingly had 3 options: one was completely unsuitable, one was desirable, and the third was where I ended up. I obviously chose the desirable allocation.

Unfortunately, two days into working at google, I was informed that my entire team was going to physically relocate in a few months and leave me with an 80-mile commute each way. So I said that was unacceptable and ended up with the third project, which I've already described elsewhere.

Do not let them do this to you. Hang tough.

nostrademons8• 14 years ago

Google hires into a general pool by design. It's because in companies where individual managers have hiring authority, every manager has an incentive to drop the hiring bar because it means he'll have more direct reports and more resources to accomplish his own goals. Perfect recipe for empire building.

The time to negotiate teams is after you get an offer. If you have any sort of negotiating leverage at all, you can probably exert some influence there. Basically, multiple managers "bid" on Nooglers, and then the manager from the highest-priority focus area gets him, modulo some input from the prospective employee himself. When I was hired, I was told I'd be working on Google Search, but the recruiter also said that if I didn't like that there were multiple managers in GMail and Apps that also wanted me, and I could go there.

In general, your goal should be to avoid getting marginalized. Typically, the highest-priority projects go to the best managers, who try to surround themselves with the best engineers, so your experience will be noticeably better on a high-priority project than a low one. The disgruntled Xooglers I know typically left because they got assigned to somebody's pet infrastructure project who somehow got headcount for a team of 3 or 4 but then has no idea how to run a software development project successfully, and no support for their ideas outside of their team. The happiest Googlers tend to be people in core Search, Ads, infrastructure (eg. MapReduce/Bigtable teams), research, or Chrome. These departments tend to feature large groups of loosely-knit, largely self-organized teams, and very hands-off management.

It could actually be a good thing that you ended up getting reassigned; it usually means that someone from a higher-priority area noticed your resume and swooped in with a bid. But you should be able to talk to the new prospective manager, or at least someone on his team. Every good manager I know will be happy to talk to a prospective Noogler that they want on their team if it means the difference between having them accept the offer or not.

BTW, I've noticed an interesting pattern where the culture of a focus area depends a lot on the first employer of the founder/SVP for that focus area. Search culture is Stanford culture. Chrome (which started from a bunch of ex-Firefox people) has a very open-source culture. Android culture is Apple culture with some Googliness thrown in (Android founder/SVP Andy Rubin worked at Apple for his first job). Google+ culture bears an unfortunate resemblance to Microsoft (Social SVP Vic Gundotra previously was in charge of .NET for Microsoft). Apps culture is a hodgepodge from various other companies (most apps were acquisitions). Infrastructure culture bears a strong resemblance to Bell Labs culture (former infrastructure SVP Bill Coughran was a VP at Bell Labs). I suppose the resemblance makes a lot of sense, and I wonder if other large companies have a similar effect.

vl• 14 years ago

Don't worry about first project too much, it's perfectly acceptable to change projects after being noogler for few weeks. There is an understanding that not all projects are a good fit for all people, so I know few people who changed projects in few weeks after they joined.

kpierre• 14 years ago

> Later on, I reduced another interviewer's search problem to a polynomial equation that had integer roots when a solution existed

well, you can reduce any computable problem to that form

see http://en.wikipedia.org/wiki/10th_Hilbert_problem

jules• 14 years ago

For the single variable case there is an algorithm: http://en.wikipedia.org/wiki/Rational_root_theorem

Whether it is a fast algorithm depends heavily on the sizes of the first and last coefficients, as you have to factorize them.

kachnuv_ocasek• 14 years ago

Is your horrible, godawful story published anywhere?

vilda• 14 years ago

he asked me what I'd do on an architecture that didn't have a square root or a divide function

My answer: I'd change the hardware

S4M• 14 years ago

Mine: I'd implement them myself, explaining how I would proceed (I would be able to implement square root on the white board easily, division I haven't tried yet).

peter_l_downs• 14 years ago

> Be very good at off-the-cuff 80% solutions to topcoder problems on a whiteboard, which I am. So much so, that when they told me to use whatever sort algorithm I wanted to, I used bubblesort on purpose, to prove a point, and got away with it.

You should have gone with bogo sort to really stick it to them :) (http://en.wikipedia.org/wiki/Bogosort)

garg• 14 years ago

>The HR rep sent over an email with some guidelines and things to brush up on which included comp sci 101 things such as sorting algos, hash tables, binary trees and so on.

Does your NDA allow you to post these guidelines? Is so, please do.

mundizzle2• 14 years ago

i hear stories like this a lot. serious question... why does Google ask standard comp sci questions when interviewing for front-end developers?

in over 10 years of front-end development for non-trivial business applications, i have yet to encounter a scenario where ignorance of bubble sort prevented me from doing my job well.

i can tell you what i value when interviewing a front-end developer - in depth knowledge of cross browser quirks and coding techniques to address said quirks (sans jQuery). someone who can tell me what OOCSS is and why it's beneficial. someone who values every pixel, http request, and div like it was their last and uses them wisely.

i don't discount the value of standard comp sci knowledge, but i get rage face if someone judges my skill as a front-end developer based on how well i answer those types of questions

lastly, ever view source of any Google app? that tells me all i need to know about their idea of a front-end development

derekdahmer• 14 years ago

Similar to how graduating college shows you were able to work hard and learn many different subjects effectively for four years, being able to solve a google problem shows that you A) are smart enough to have understood and retained it from when you were first taught it or B) were driven enough to sit down and learn tough conceptual problems in a few weeks.

So, its less that you know that particular subject, and more what you being able to pick it up is an indicator of.

mundizzle2• 14 years ago

Sure, I can understand that.

My point is that most of the very best front-end developers I've met don't have CS degrees. So it seems unfair to penalize them for something they've never been exposed too. There are other ways to assess someones conceptual ability.

ww520• 14 years ago

The questions asked illustrate what the interviewers know and don't know. Google is reputed to have a mono-culture of CS-heavy people. They know CS-related questions the best and that what they would ask.

brandonb• 14 years ago

When you're as concerned with frontend performance as Google is, computer science knowledge can really come in handy. For example, they wrote their own compiler for Javascript to check for errors and shrink down the code to an absolute minimum, by e.g., shortening variable names and pruning functions that are never called. This means they had to write a their own parser, run various graph-based algorithms to follow references, iterate and transform the abstract syntax tree, etc.

http://code.google.com/closure/compiler/

jumby5• 14 years ago

And I'm sure the frontend guys were working on that.

Don't you think it's better to hire compiler experts for that exact problem rather than worrying about whether some frontend dude can write his own JS parser?

spacemanaki3• 14 years ago

Using "view source" on an app like Gmail or Maps is a terrible way to judge their front-end developers. The JavaScript might have gone through the Closure compiler, which is a seriously cool piece of software. They might treat the markup with something similar, I don't know. I would base my judgement of their front-end team on the quality of the software as a user, and I think Gmail is the best web-based email app and Maps is the best web-based maps app... so I have a lot of respect for their front end teams, regardless of what the source looks like.

gaving• 14 years ago

probably the most boring thing I've read all day

jmsduran• 14 years ago

I had the opportunity to interview with Google. Overall it was a great learning experience, and demonstrated to me the skills and aptitudes required if I wanted to play with the "big boys".

Regarding their interview questions, you either know it or you don't. From my personal experience, Google's rounds of questioning are intentionally designed to weed out the people who fake it or try to cram up beforehand. For software engineering, they are interested in applicants who naturally demonstrate keen skill when it comes to CS fundamentals (algorithms, data structures, discrete mathematics, etc.).

Throughout my phone interviews, Marissa Mayer's quote "A good student excels in all subjects" kept running through my head. After interviewing with them, I believe Google holds all their employees to a similar standard.

feralchimp• 14 years ago

The most likely explanations for a company like Google using whiteboard questions:

- These interviews are easy to give for someone without good interviewing skills, which is basically everyone.

- These interviews are relatively easy to score.

- Google acquires superstars through acquisition. If you need some competent rank-and-file (i.e. a "pool") to support the superstars, whiteboarding is maybe an okay way to weed out people who definitely won't rise to the occasion.

It's a little insulting, but their pay scale probably balances that out.

nohup• 14 years ago

I got a call to interview with Google 10 months ago. Had two phone interviews which went well, could not answer a Javascript prototype object model question, but the interviewer was very kind go explain me where I was wrong.

After a few weeks went for an interview at their MV campus, awesome place. Of the 4 interviews of 45 minutes each and one lunch session that I had, I would say I did good in 2, fine in 1 and goofed up 1.

I did not get an offer, I had guessed that with how my interview went, but my hopes were high :-). All in all I learned new things, met some excellent people and had a great time.

I had read online about the white board process, so I was prepared for that. I really feel for the interviewers that they had to sit for 45 minutes looking at my bad handwriting ;-). The only thing that I could not understand was why when I was not being interviewed for a traditional engineering role, I was being questioned about Big O, algo design etc. The HR lady told me it would be related to the area of my work (Web development, Javascript, Open source contributions etc), but the interview at MV was not at all like that.

Having read other peoples experience with interviews at Google and the scale of their APIs, I think at some point they are looking for people who can do whatever is thrown at them and not just be bound to the technologies they know. All the CS questions they asked me, I feel they were justified to ask them, they wanted to find out if I will be able to work in other areas if need be and not just be "a frontend developer". The interview was easy, I was just not prepared to answer those questions.

Given a chance, I will do it all over again, but this time will go mentally prepared for a CS 101 interview as well.

justin_vanw• 14 years ago

I guess I don't understand the 'I failed to do this, let me give you advice now' movement. From his own description the author is woefully under qualified.

Interviewing is one of the purest Bayesian actions people do. We have to take a bunch of limited and incomplete information about a person and try to determine whether they are likely to succeed or not. Most interviewers would love to find people that are smart, able to learn quickly and well, and motivated, excited energetic. The best measure of these things isn't whether the person seems smart, or energetic, everyone is trying to seem smart and energetic and positive in an interview. The best measure is whether they were smart and energetic in the past, and the best guage of that is how deeply they learned in previous experiences. If they are a 'javascript programmer', not knowing javascript syntax by heart is a strong indicator they just kludged through without much deep interest in what they were doing.

Being unable to program on a whiteboard means you don't really know the language you are using. Relying on an IDE to prompt you every time you make an error is a huge crutch, and IDE's can only help you with obvious cases, there are many times where you can get code past the IDE as syntatically correct but logically wrong.

nessus427• 14 years ago

Being unable to program on a whiteboard means you don't really know the language you are using.

This is nonsense. I have a degree from MIT. I've spent the last 15 years programming in C++, Python, Scala, Lisp, Java, SQL, and JavaScript, etc. I've worked on compilers, space telescopes, and brain surgery software, and I know all of these languages fine. There's no way that I would be able to program on a whiteboard without a lot of practice, however. Most likely, I wouldn't be able to remember my own name if you made me stand at a whiteboard to program in an interview situation. Fortunately when I interviewed at Google they let me use pencil and paper.

Btw, I use Emacs much more than an IDE, and much of the knowledge I have for syntax is built into my typing fingers.

atarian• 14 years ago

Coding with pencil/paper is in the same league as coding on the whiteboard. It's not nonsense and you know it too. You just deliberately missed the point of his post just so you could brag about being from MIT and all the stuff you worked on.

andylei3• 14 years ago

>> I wouldn't be able to remember my own name if you made me stand at a whiteboard to program in an interview situation. Fortunately when I interviewed at Google they let me use pencil and paper.

i don't think the top comment means literally a whiteboard. i think his argument is that if you can't program relatively basic things away from a computer, you don't really know how to program.

capkutay• 14 years ago

Coding on a whiteboard or paper/pencil may require you to use the academic portion of your cs knowledge. I know all my CS exams involve writing code on the test paper...

kamaal2• 14 years ago

And if a marathon runner can't run 40 kilometers without shoes he knows nothing about running, right?

sitharus• 14 years ago

I interviewed with Google at the end of last year. The only thing I took away was that their recruitment people aren't very good at pre-screening and they seemed to like wasting my time.

The first two interviews were OK, basic UNIX admin and software type questions, I could answer most off the top of my head. The third was with someone who certainly had a maths degree and wanted to make sure I knew it.

It all left a rather bad impression.

jumby5• 14 years ago

Typical Google waste-of-probably-a-decent-engineer. A javascript coder getting asked sorting algorithm questions and Big-Oh notation. What a waste of time. Google just doesn't get it.

I know all you fanboys out there will say "you need to know this stuff to be a generalist software engineer" but c'mon, hire experts in sorting algorithms if you need that for some obscure bigtable ultra-performant section of code and leave it at that.

Need another example of wasting everyone's time: "She told me they primarily hire strong C++ and Java developers, something which I have very little experience with." Gee, Google, glad you still brought him in when he clearly has no interest or background in that.

nbclark• 14 years ago

It's all about how you think under pressure. You have to know the basics, for sure, but the interview is much more about seeing how you think and work through problems. If you are getting asked to implement merge-sort or something, probably not a great question. But whiteboard algorithm questions let the interviewer see your thought process and how you think on your feet.

What I learned interviewing with Google

Related Stories