Slashdot Mirror
Defining Google
pbaumgar writes "Did anyone catch the 60 Minutes piece on Google this evening? They mention their hiring process a bit in the story: 'For example, Google is hiring about 25 new people every week, and receives more than 1,000 resumes a day. But they're determined to stick to their rigorous screening process. Google uses aptitude tests, which it has even placed in technical magazines, hoping some really big brains would tackle the hardest problems. Score well on the test, and you might get a job interview. And then another and another. One recent hire had 14 interviews before getting the job - and that was in the public relations department.' As a person who recently interviewed with them this past summer (I didn't get the job), I was wondering what others' experiences were like who interview with Google. I had 4 interviews, and it was by far the longest and most interesting interviewing process I've been involved in. I'd love to hear others' experiences in their attempt to get hired."
The insistency of some companies to require a batchelors degree often leaves otherwise qualified applicants out in the cold. Google is one of these companies (from my experience browsing the job postings), which sucks for college students looking for a job. Oh well.
Especially if you already have a job and the current employer doesn't know you're in the market.
14 interviews!? There are only so many flat tires and sick aunts one can come up with for missing a couple of hours of work.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
When answering a search request, Google does not search the Internet. It searches its index.
The index does not reflect the Internet, but the World Wide Web. And only a small part of it, with the Deep Web being much larger.
Algorithms are not computer code.
Please don't give us more of those regular media articles on Google. They mostly suck when it comes to the technical side. And we have all heard about the free food a gazillion times.
Just think - in any field you can think of - tennis, school, etc. - some people are 'A' players and consistantly outperform others - other people are 'B' and 'C' players, that really don't stack up to the 'A' players.
A company filled with 'A' players will win every time.
Google's just in a very enviable position that so many top people want to work directly for them -- as opposed to starting their own thing in the hopes of getting bought by Google later.
In my experience, such people are usually poor programmers. When faced with a problem, they may hack together a solution quickly, but the code they write is often poor from a readability, structural, and maintainability perspective because none of those things are "interesting" in their own right.
Google is discarding many people who are very talented programmers, but who just aren't good at solving puzzles in real-time during an interview. Additionally, the added pressure of you getting hired riding on not only your answer but how quickly you can give it is enough to make a lot of people freeze up.
Personally, when faced with a really hard problem, I often think of a solution when I'm not consiously thinking about the problem. Showering and that period between the time I get into bed and the time I actually fall asleep are two examples of such times. (I keep a notpad and pen next to my bed to write down stuff I think of just before falling asleep and often discover that the next morning when I try it it's the solution I was looking for.)
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
the 2 main job requirements in IT: the ability to RTFM/Google. ofc i suppose the latter isn't very relevant in the context of this article ;-)
People replying to my sig annoy me. That's why I change it all the time.
Although Google is a bit more on the extreme side hiring process wise, this is definitely very typical for the market today. Anyone planning on getting a job in the tech industry, here are the key things your employer is looking for:
1) Ability to work well with others and in a team environment. This is pretty much critical in tech industry today.
2) Ability to learn quickly and on your own. No one realistically expects you to know *everything*, there is just too much for most people to absorb. What they do expect you to do though, is to be able to teach yourself the things you need to know and learn quickly.
3) Background experience. What companies analyze out of your background really varies from company to company. But, in the end all they are looking for is data that backs up point number 1 and 2. They want evidence that you are balanced, that you can learn well, that you can work well with others. Be it college background, work experience, tech demos you build yourself, etc, all that stuff really is just hard data to confirm your background.
As for the aptitude tests, those are just a way for companies to narrow down the potential applicants. With so many people looking for a job, it helps to shrink the applicant pool any way you can. Trust me, your potential future employer knows you are going to BS on the aptitude test. In fact, they are pretty much expecting it. They just want to ween out the people who aren't serious enough about getting the job and who aren't smart enough or serious enough to BS the test based on what they feel the employeer is looking for.
Honestly, aptitude tests are just a quick and easy filter to get the dumbest of dumb out of the way. What really and truly matters when you apply for a job is the interview(s). That is where your potential bosses can really judge you.
80% of what matters in the hiring proces is all about the interviews. 10% is background, and the last 10% is your BS filter(aptitude tests, on the spot programming challenges, etc).
You are who you are, let no one tell you different. But, never close your mind to a new point of view.
Seriously, basing your business plan around hiring a bunch of geniuses is not automatically a smart idea. Geniuses can be lazy, they can be terribly hard to manage because think they know better than their managers, and the supply of grade-A ones is rather limited and competition for them will remain pretty hot. It may well be smarter if your business is set up in such a way that you didn't require all your employees to be geniuses, but through good training and good procedures equipped them to deliver the services that you wish to offer.
Sure, maybe your business is going to be less flexible and adaptable this way. Maybe you're going to need more staff, and more intensive oversight, than the "hire geniuses" route. But the supply and cost of moderately competent, reliable staff is much, much more favourable than competing for geniuses.
In 20 years time, when Google is a mature company trying to protect its patch, let's see whether people are chewing off their right arm to work there, and how the company copes then.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
If you're looking for a technical look at Google's inner workings, I highly suggest you view this talk given by one of Google's Distinguished Engineers at the University of Washington. He talks about how Google stores all of its data (the Google File System), and how massive amounts of data are processed (MapReduce), among other things.
So I was just hired by Google right out of college, I'm graduating from Carnegie Mellon Univ in May. Google came to our school to run interviews around October. Here's a summary of the process:
Google set up shop at one of our job fairs with about 120 other companies. Anyone could walk up to the booth and give them their resume and talk to the people there. If they liked you, they e-mailed you later for an interview
There are then 2 on campus interviews. The first on one day, and if the interviewer likes you, then you get called back to the next day. If that interviewer likes you, you get flown out to their head quarters by San Fransisco. For my trip, there were 8 kids from CMU, and about 25 total from 7 other schools.
Out in their headquarters, you have 3 interviews with different sets of people. One of my interviews had 2 people each asking questions. They also feed you though and give tours of the campus. They definitly treated the applicants very well out there, great hotel, very nice all around.
Finally a week later people found out if they had offers or not. I heard rumors that in interviews with Google, each interviewer has 'veto' power, so if just one person didn't like you, no luck.
As for interview topics, there was a large range. Most were data structure concepts and problem solving. One interview was very unique though, the guy had a sheet of general software eng questions ranging over topics such as application design and testing, server-client software design, internet concepts. He would ask you just to describe a general topic, and see how much you could explain about it. For instance, one question was like "If you wanted to improve one of your programs, what would you do?" So you had to talk about testing, bottle-necks, better hardware, etc, just about everything.
As for coding questions, some people have complained in this thread that they don't display if you are a good coder, and I quite disagree. The purpose of those questions are to find out how you think, not how you code. They look for if you can logically lay out a problem in entirety and solve it one step at a time. Yes it's under a stress you would normally not have, but I think the stress helps sometimes. The part that all my interviewers spent the most time with was if I could improve my current solution. To see if you could do it with less memory, less cpu. The hardest part is just not knowing if there's something obvious that you should see. But a hint, start with the worst solution, then 'think up' a better solution while you're writting out the first. Do not try writting out the optimal solution from scratch from your head. They want to first see that you can solve it, but then to make sure that you don't settle for that solution and instead cringe at every line to make sure it's perfect.
Other tips I would suggest, spice up your resume with team projects. Also, the breadth of experience you have, not depth. As for positions at Google, I was hired as a Software Eng, which means I can work on just about any project, so they wanted people with skills in many areas. Lastly, don't be afraid of saying 'I don't know' to a question. I did this a few times for 'quiz' questions where I knew I could just go look up the answer (for instance, one question was 'list and define all the different type casts in c++'). But just don't wait time trying to make up something or giving a wrong answer.
After that babble, I also wanted to mention that every interviewer seemed to love their job there, like some people in the thread have said.
I hope this might give some insight into the process, although it's specific for college grads. But the general idea I got was that Google was looking for genearally bright people with decent experience and good team skills.
One of the key things I remember reading about is their extraordinarily high employee satisfaction ratings, so it follows that a whole lotta people would want to work there.
It is standard human psychology to overvalue something that was dificult to obtain. That is one big reason that fraternities haze their pledges - the pledges that "survive" the hazing will usually overvalue their membership in the fraternity and behave accordingly.
Similarly, an extremely difficult interview process will tend to make the employees that put up with it feel that their new job is something really special and unique, when if looked at from an objective point of view, it might not really be so.
When information is power, privacy is freedom.
I hire people, and my organization went through a period of putting people through many rounds of interviews.
I put a stop to it - the problem was poor interviewing and poor decision making. Some interviewers were not skilled in asking good questions. And no one in the hiring process wanted to be the person to "veto" or "take the blame" when things go wrong.
But the fact is, we all had a good idea after the first round of interviews once we thought out our interview process. Subsequent interview rounds were just there to make some individuals happier with decision making - or to do a better job interviewing.
But I thought (and still think) subsequent interview rounds were simply abusive to the applicant.
So our new hiring proces is streamlined: (1) telephone interview, and then if still good, (2) a single round of personal interviews with a manager and then a peer.
If we don't know after this, then it's likely that there isn't a match, and the candidate is not hired.
If we think there is a match after this process, we make an offer to the person (which is sometimes accepted, sometimes rejected).
The candidate is initially hired with the caveat that it might not work out (in the USA it is very easy to release a new employee that isn't working out).
We only had to fire a new employee once, and this problem happened simply because my boss overrode my hiring veto (they attended the same university). Sadly, I had to do the firing.
The point of the parent poster, and though I haven't read it, I assume the book - is that once you have a few good years under your belt, any decent programmer will tell you that all languages are essentially the same. Sure, you have some that are OO, some are more procedural, some have some weird syntax to get used to - but, for the most part, they are all the same basic constructs and concepts, and anyone with a moderate level of skill can pick up a new language fairly rapidly. Sure, they will be no expert at first, but given 6 months to a year and they would be proficient enough that you just may have a hard time picking them out of a lineup with people who had 10 times the experience.
Programming is about algorithms and design. The language you use to implement those ideas is nothing more than a tool. If I was interviewing anyone this is where I would be focusing my evaluation.
The days of needing to know the language's API inside and out are over - Google took care of that. I don't want to know if you know what the method of creating a vector in Java is - any monkey can find that out with Google in less time than it took you to read this sentence. I want to know if you know what the *difference is* between a vector and a list, and if you instantly know when to use which. This is not something you find in 2 seconds on Google, and this is what you should look for in a good coder - the ability to quickly and easily identify the best algorithm for the situation.