Then a really cool opportunity came, and I accepted that offer because you can't just sit in a rotting pool for two months.
A friend of mine stayed in the rotting pool and was told at the beginning of summer that no one at Google wanted him.
This was 2009-2010. I hope Google changed their ways.
First time, I was told a manager would call me to explain me which team I was being matched with. I received the call to tell me I had an offer... two days after the deadline set by the University. And it is not like this deadline is unknown to employers.
Second time, again, I received an offer. This time, I had to call, one week before the deadline, after two weeks of hearing nothing from them. Two students in my class were in the same situation, one had to send a hate mail to finally get a reply. The other one got one only after the deadline.
To be honest, this really isn't the best way to go about it. Makes you fell like crap as an intern. I interned at fairly large and well known tech companies in the past (Facebook, heading to Bloomberg this Summer) and got offers from many more (Amazon, Microsoft, Zynga, EA, etc.) and my worst experiences were always with Google. As a freshman, Google looked like the dream internship, the company to aim for. Four internships later, it is now pretty low on my list.
Definitely not impressed by their recruitment process. And this all happened in the past 12 months.
Sadly the recruiter who knows this deadline and the managers who have "Look for suitable interns" as one of very many todo list items are not one and the same.
I did an internship at Microsoft and now work at Google; the MS internship hiring process (in 2002) was awesome and very, very fast. Your comments about Google's relative standing are definitely interesting and clearly not an anomaly, the issue is fixing them =)
Compared to MS, Qualcomm, AMZN (I'm headed to MS) Google's process is pretty weird.
I'll give MS recruiters the benefit of the doubt, as all other candidates I met had positive experiences. They just matched me with the wrong team, and it seems like the recruiter overlooked some paperwork related to scheduling and traveling.
Other sloppy recruitment experiences include some with trading companies such as Jane Street; one such company rejected me by saying "we're only looking for juniors" after calling me on-site. The only truly positive experience I've had is with a YC startup (I was eventually rejected).
Nothing, however, compares with how bureaucratic and mismanaged Google was. I went through a smooth but lengthy recruitment process the first time, and was given a rejection letter after 1 month. Second time, I had to do some juggling between 4 recruiters before getting the paperwork settled for my first interview. I was out of the country and clearly told a recruiter that I should be reached by a different phone number, after which I was asked "are you legally allowed to work in the United States?" even though I'd already answered that in the paperwork they had given me, and I had clearly stated I was studying in the US. Then, I end up scheduling interviews for 2am and 3am my time. The 3am interviewer is not informed about the change in phone number, and is a no-show.
A couple of interviews and 6 weeks later, I get no response. So I end up sending a follow-up mail to my recruiter, who, the very next day, tells me I've been put in the rotting pool. I get no more feedback after 3 weeks, and send another mail. Apparently, I'm still in this rotting pool. I'm guessing this is just equivalent to getting a rejection.
As for interview questions, Google isn't any different from other large companies. I found it odd that they still require candidates to code in Google Docs rather than some Etherpad equivalent that formats code.
So far, searching for an internship has been just a ridiculous time sink. I'd probably get more experience by hacking on my own projects, but that's no guarantee of job safety.
Renaud, I think you should give them another shot if you're still up for it.
As for binary search, I wouldn't necessarily be able to bang it out in two hours in C, but I'd easily be able to bang it out in that time for any language I use regularly. And with sufficient testing I'd take a good stab at converting to C.
Though I agree sometimes it can be a coin toss. Once I was asked to write some code that would take dates as inputs and do something with them, it was supposed to take two hours and run on a bunch of test cases they gave you. I spent much more than two hours on it, nailed all the edge cases and boundary conditions that I could think of (basically nuked it from orbit) and turned in something which ran on their test cases and also a much longer list of much more challenging test cases. I got that job.
I missed one where they wanted something written by TDD. Unfortunately, I only know how to design something that works, I don't know how to fake a bad design that organically grows into a workable design. As above I nuked all the boundary conditions I could think of, but didn't get that job.
(Probably wouldn't have been happy there, my experience is that people who do TDD or automated unit testing have way too much faith in those forms of testing, and they neglect other forms of testing, so their actual net amount of testing is well below my standards. Things like: every single programmer I've ever worked with who claims that automated testing is sufficient has always produced code that when they claim they've finished the task it fails the eyeball test. E.g. you run their code and within 10-30 seconds of looking at the result you can spot something wrong with it.)
So in under a week, I went from initial interview, to official offer. This is by _no_ means typical (and my recruiter even commented on how unbelievably fast it was), but it _does_ happen.
A while ago, I used to conduct job interviews like this. Sort this, insert that, search for the other. I still feel sorry for some of the candidates I did this to. That process was the largest single mistake I made when hiring people. I should instead have asked for the code of some projects they had been working on recently and maybe discussed a few more creative things with them.
In fact, if I could ask a candidate just one question, it would be "what projects are you working on in your spare time?"
I feel like the energy I could spend doing a side project is probably better spent getting these last two features in, or fixing those lingering bugs, or getting that automation solid, etc....
It seems really odd to actually penalize someone who leaves it all on the floor. It's like a basketball player saying, "If you really want to see my skills, come to the park. The NBA is just my paycheck." -- is that the guy you want on your team? The guy who will tell his next employer, "Company XYZ paid the bills, but my real cool work is this GitHub project I did on the side".
If, however, a programmer's day job is maintaining a legacy system that doesn't involve a lot of creativity then there's a greater likelihood that they have untapped passion which will express itself in a side project... and ultimately with them finding a new job that does require creativity.
Judging someone based on their side projects is the wrong approach -- judge them on their creativity and passion. Some are fortunate to have a job which gives them the ability to be creative and passionate during work hours. Others aren't as fortunate and need to express their creativity and passion outside of work hours. The big red flag to not hire is when someone has neither creativity nor passion inside or outside of work hours.
PS: All of the great developers I have worked with are both old (50+) and have a life outside of code. Spend some time around people with Genius IQ's and 30+ years of experience and you rethink just how important passion really is.
Now, for Google that might not be the case — they certainly should be trying to find the top talent they can get their hands on. All the more reason to ask about the extra projects, GitHub account, code samples etc. But just as many people, when they're students, don't appreciate or value the extra work you talk about, they won't do it when they work for Google and are tasked with hiring others. If all you spent time studying were algorithms and C, you won't appreciate the value of open-source contributions and feverishly learning new languages as much as someone else. And you won't hire based on that.
And yes, that's disappointing.
I think a question talking about the Django templating system when the interviewee mentions they use Django is fair game, though; and questions that revolve around 'here's a real world problem I want to do with a string, can you write a quick algorithm' are ok, but then I do things like the Greplin programming challenge for fun and I'm not even an engineer =(
I agree, but it was the only good one I could find in the article.
My feeling is that if they are claiming to be "programmers" but seem uncomfortable with basic algorithms/data structures, there could be a problem...no?
For example, when I was reading your writeup as a former interviewer (lots and lots of college candidates for MSFT -- I was a dev manager and did both my own hiring and was flown to colleges for those "interview days" for several years), I was far more worried that you had trouble finding the bug in binary search than that you got it wrong. Everyone gets problems wrong the first time unless they have just implemented them recently. Superior candidates are good at rapidly trying good normal and edge cases, hammering out a good solution, and writing inspired code when given hints at how to improve their solutions.
I really don't like the idea of solving contrived puzzles, but I'll never make the mistake of keeping my thought process hidden again.
I don't claim any responsibility for their success, though! The University of Chicago undergrads are a hard-working bunch. Much more so than when I was an undergrad :-)
Why are Google so popular anyway? I genuinely don't get it and would love to know from someone who has specific knowledge. Do they pay better than everyone else? Work on more interesting problems? Better perks, work environment, more status? I can understand it from the perspective of someone who joined years ago, when you got stock options and didn't have to do a full circus performance in order to get in, but not any longer.
The experience would have to be twice as good as the alternatives before I willingly submitted to this kind of process. A long process of interviews like the ones I have heard about hints at more pain and no autonomy once you actually join.
For an _internship_? If you're turning down other offers for the _chance_ to work at Google, you're selling yourself short and not getting full market value.
I've been a Googler for a little less than a year and so far I absolutely love it. Compensation is good, the perks are fantastic, the caliber of people I work with is stellar, the work is challenging and interesting, and the culture and processes are the best I've seen.
> A long process of interviews like the ones I have heard about hints at more pain and no autonomy once you actually join.
I believe it's the opposite. You have to run the gauntlet to get in because once you do, you won't be closely monitored and you'll be given a lot of autonomy. The hiring process is stringent to try to reduce the number of internal gates you need once you get in.
Because at this point in your career, you have no degree, no experience, and no income? He's a sophomore in college, not someone with 30 years of industry experience.
In my experience, though, I would make someone with 30 years of industry experience answer the same questions. Because I've asked people like that those questions and they have absolutely no fucking idea. The number of people that can start with a blank file and start writing a computer program is probably somewhere around 5% of programmers.
What?! There's no way this is true... is there?
The second year (last year), my experience was similar, except this time I bugged my recruiter pretty much every other week until I had a host interview (got TWO of them cancelled on me but finally the third one actually happened) and I got the job.
Despite the terrible process, it is an absolutely amazing place to work. Everything you've heard is true: the food is amazing, the work atmosphere is amazing, the people are geniuses. Also, the compensation is absolutely absurd for undergraduate interns (last year it was $69,600/yr prorated to $1338/wk, and this year they bumped it up to $80,000/yr prorated to $1538/wk, with a $3500 lump sum relocation stipend on top of that. I know it's even higher for grad interns but I don't know the exact numbers).
Despite the admittedly awful process (easily the worst I've been through), it was absolutely worth it to me and I'd recommend anyone stick with it and hope you get lucky like I did. It really does come down to luck whether or not you get a host interview once you've passed your two technical interviews.
In many years of programming I don't remember having to write a binary search in C, by hand, in a text document, without being able to compile and test. Or having to dictate a Python program over the phone to someone.
I certainly do not remember ever having to solve stuff like:"One train leaves Los Angeles at 15mph heading for New York. Another train leaves from New York at 20mph heading for Los Angeles on the same track. If a bird, flying at 25mph, leaves from Los Angeles at the same time as the train and flies back and forth between the two trains until they collide, how far will the bird have traveled?" NEVER.
I had to implement & modify algorithms from scientific papers, I had to work with complicated lockless versions of data structures, but I probably couldn't write the binary tree search in C over the phone. If that's that Google uses to hire then I will never work at Google.
EDIT: Alright, got a angry and used the 'fuck' a little too much.
They did, however, ask a whole bunch of conceptual questions, but I don't think this is all that surprising.
I'm going to try to find a way to feed it back to HR, because it really is much easier to think about code when what you're doing looks like code.
That was my first interview, and they said at first it was going to be a coding interview. My next interview was a design interview. We talked at length about designing a simple web application, which got increasingly sophisticated as we progressed. But my interviewer did ask me to write code to demonstrate what I had in mind from time to time and I had to code up some small methods and classes to show him. No puzzles. No CS theory or abstract problems. Just what I would do if I were building a real world application.
Oh, and they asked about what projects I had worked on both interviews.
I have been an interviewer in the place where I work currently, and I always asked candidates to write code. Some guys here ask puzzles, but I don't like that. Puzzles (like how to find you who's lying in an island on people or something) don't really show anything in an interview situation. But a short programming problem, demonstrating the ability to identify and use a well known data structure or algorithm, or to use good sense and understanding to design a solution to a problem does go a long way to show that a candidate can actually code and get stuff done. I've seen lots of bad candidates impress us with their knowledge of tech buzzwords, past projects in their CV and even talking about design patterns, but fail miserably when asked specific questions or writing even the simplest amount of code.
But if someone asks me about trains and birds, I would seriously reconsider working there
Agreed. It doesn't have to be perfect. They should be able to talk and explain it. Whiteboard design sessions are my favorite A good marker and a whiteboard are indispensable for me, and I use it in interviews as well. I present the situation as here is a typical problem we are solving, let's solve this together.
I also give plenty of chances to let the candidate tell me or teach me something they are excited about.
Personally I was in between jobs recently, so I sent Google my resume using their online application site. After about a month, Google still didn't get back to me -- meanwhile I managed to interview at 6 different places (all the way) and found a new job.
"I heard nothing for a month and a half" is the key problem I think. It's going to be very hard for any full time employees that are any good to stay off the market that long, they'd have to apply to Google before quitting their last job.
As for interns, I am not overly surprised since you applied in December. At my school we had the hiring booms in October/November and then again in March/April (that's when we had the 2 engineering job fairs), so anytime between that people weren't really finding a new internship (unless it was on their own).
One last thing, what exactly is a Google spreadsheet beta candidate form? Is that the same one as the optional Google "survey" where you had to rank your skills (1-5 or 1-10 was it)?
On the following: 1) Applications and Services: this is Google's term for the software that is directly visible to end users. People who focus on applications and services typically work on improving our capabilities in a variety of areas that span the range from new features to increasing performance and efficiency at Google scale. They will be tasked with devising and building new approaches to Google's problems, and exploring their effectiveness.
2) Systems: People who have a systems focus are oriented towards behind-the-scenes software and systems, often building them from underlying components and services. Systems work spans from platforms (hardware, OS, networking) to infrastructure (shared services such as storage, cluster management) and everything in between.
3) Sys-admin: Our system administrators keep all of Google's systems running, and help deploy new ones. They deal with issues involving single machines to those involving huge numbers. They work with native Linux environments, and Google extensions and services.
4) Verification and Test: Our test teams helps make our systems resilient and reliable - we put a lot of effort into this. Building world class applications at world class scales doesn’t happen by accident. It takes insight, innovation, and precision to verify our systems perform as expected.
I don't think it was optional, though perhaps I'm mistaken and filled it out assuming it was required.
- Every step of the process involved a new person. Overall, I had to be handed off through 4 different people, each one wanting a bit more information or a filled out form, until I was scheduled for the phone interviews. This was especially confusing when I had a recruiter assigned to me, and I was being emailed by both her and someone with whom she worked with at the same point in the process.
- The first interviewer was apparently a fill-in for the intended one, which is unfortunate, because he and I were a complete mismatch. He seemed to be a C/C++ guy and I have more high-level language experience, and we ended up doing what I would consider advanced bit manipulation / number theory. (The second interview was much more reasonable, and it is my own fault if I did not pass it.)
- The amount of time time that it took from the "Hi, we would like you to apply online" email to the you are not "a close enough match" email was over a month, which is much too long for simple back-to-back phone interviews. Waiting for their responses was the most frustrating and nerve-racking part of the process. I am glad at least the OP had quick responses.
Should I go through the process again, I would strongly consider asking them to expedite it in one way or another.
On a more optimistic note, I do feel like the interviews do help highlight weaknesses in your programming skills and resume presentation skills.
Google sure makes a lot of noise about how they are hiring and competing for talent, but continue to turn away good people for unknown reasons.
It's important to know that googlers are encouraged internally to do interviews (for extra cookie points? I don't know :P), they're assigned randomly to candidates for most of the process, so they're not a part of the whole process, just a piece of the machinery. No one oversees the interviews to make sure questions are not repeated and that there's a logical thread from one to the other (especially the onsite interviews), and you might not even be asked the questions that are actually relevant for the position they're considering you for, when you're in the latter stages of the process.
The stories I've heard from the hiring trenches are all pretty much the same. It's a great company, but their hiring processes are very weird.
First, I have had almost no actual CS lessons in my university, because it was more focused on general engineering and IT management than on code writing.
However, I've done quite a bit of code in various open source projects and I've touched quite many technologies...
I went through the sets of interviews, and I really seemed to work quite well, even if many design-patterns where unknown to me (I didn't know their names). But the last one wasn't the best one.
Therefore, I got the mail telling me that they got no positions for me, which I understood and accepted easily (I had another engagement at the time).
However, I dared to ask "why?". Was it my technical skills, my personal skills, my logic skills or the way I answered the process, the cause of my rejection?
They refused to even discuss about it, which is not even reaching the minimum of politeness I expect from a company. When they asked if they could keep my Resume, I told them to go away...
This recruitment process does not seem enough respectful for me and gave me a very bad opinion of the company.
And, sure, I don't take it personally :D I just don't like this behavior.
I didn't ask for details, just a general idea.
I've done a fair deal of job interviews, in order to get this kind of feedback and improve my skills; and Google was the only one that was that little polite on the feedback (even MS was nicer)
They didn't even say: "we can't tell you because of general policy or because of fear of lawsuit"...
But the fact that it's only "[s]ome companies" that do that still suggests that it's rude and unprofessional behavior.
If you're just a sophomore, you shouldn't feel bad about not getting an internship at Google.
Another reason not to "feel bad" about it is that AFAIK the people interviewing you just take notes, and then other people review those notes to decide whether or not to take you. So the people you interviewed with weren't even the ones that made the decision.
Perhaps for the C program, you should have done something simpler than a binary search, at least to begin with. The way you described it, they didn't require you to do a binary search.
I think it tests specific knowledge of an algorithm more-so than anything else.
The problem I'm sure, was being rusty at C, not the algorithm implementation. I make all kinds of silly mistakes on the whiteboard if it's with a language I haven't used for a while.
I got my call, was inquired about my projects and current offers by HR and then got a rejection letter next week. After I inquired, it turned out that my low GPA [ 7.03/10.0 ] was the cause. They want academically bright freshers with shining GPAs and with strong CS101 skills.
But, I believe there is a method to the madness. They have so many qualified applicants that they would rather err on the side of caution. They would rather reduce the false-positives even if the number of false-negatives grows. They can afford this luxury. They want the best and they can afford rejecting good candidates.
My favorite way of thinking about this was from Steve Yegge's blog post about the interview process : "Because of the inherently flawed nature of the interviewing process, it's highly likely that someone on the loop will be unimpressed with you, even if you are Alan Turing. Especially if you're Alan Turing, in fact, since it means you obviously don't know C++"
They employ a lot of people that can write code on boards, and can certainly churn it out at high velocity. But when you start looking at the actual code... it's bad. When I first looked at the chrome code, the layer they dumped on top of webkit to make it out-of-process, the only thing I could think of was "this looks like something a kid fresh out of college would cobble up together". Same thing with most of their projects - lack of clear design, hacks, hard to maintain, lack of standards, no portability. The projects that get visibility end up getting better (more competent programmers assigned to them), the rest lingers in crappiness mode.
They're not all like that, obviously. They have very smart and very competent people there. But the general low quality of their code, the lack of polish in their products, it clearly shows the consequences of hiring people based on how fast they can dump code on a whiteboard.
given two full hours and any high-level language
(including pseudocode) only 10 percent of professional
programmers implemented binary search correctly,
according to Jon Bently.
I'm not particularly intelligent and I'm not in the top 10% -- but I could implement an in-place quick-sort in C in 10 minutes that my interviewer could run with only a minor fix (forgot a semi-colon), and I even described the parallel version with OpenMP (although there I got the syntax slightly wrong). This was for my interview at Adobe, when I got hired by them a couple of years ago; went on to other things since then.
By that logic that should place me in the top 1 percent ... but so are my ~ 100 friends that are also software developers from my city, and statistically speaking, something smells like shit in those statistics thrown around.
Maybe binary search, when discovered, used to be a hard to understand problem, but now it is taught from high-school. And sure there are lots of idiots out there, but many of those idiots also believe they are in the top 10%, because some statistic told them so.
So cut the crap and build stuff. Only by that metric you can prove yourself.
-- EDIT --
I'm not referring or addressing the article's author directly. I'm also not saying that you SHOULD be able to implement binary search, or quick-sort or whatever metric du-jour -- in interview conditions. I get it that you may be stressed by eyes watching you, or that you may be bitten by edge-cases other people haven't noticed for years.
I'm referring more to these metrics flowing around -- like, if you read HN you're in the top 5%, if you read this stupid blog you're in the top X%, if you can implement binary search ... etc, etc...
We are software developers, mathematicians, computer scientists -- surely we understand selection bias and should be able to recognize bullshit, even if it doesn't appeal to our ego.
The HN post led to this perennially popular article from Joel on Software:
http://googleresearch.blogspot.com/2006/06/extra-extra-read-...
Jeff Atwood references a good example: http://www.codinghorror.com/blog/2007/02/why-cant-programmer...
The sad truth is that many people who program professionally simply cannot so basic programming tasks. If anything, I think top 10% might be overestimating how many can do it - I suspect 10% might have some kind of idea of how binary search would work, but most of them will fail with edge cases etc.
This was quite a contrast to my Facebook experience, where I had a contract signed after I think 3 weeks. :)
I'm really quite surprised that binary search is considered difficult, have you ever tried to implement quick sort? I can write AVLs with less bugs than quick sort.
I think an important factor in these interviews is the emphasis on talent in software development. Don't get me wrong - I don't deny its importance, it's more that I question the nature of the beast. To me talent is instinct, a feel for what you're doing, and the 'right' type of thinking for the thing. It's pretty obvious when somebody has it (or doesn't), and I think obvious whether you have it too if you're honest with yourself about it.
Tech interviews emphatically do not test for this. Nor do they, I believe, test for smartness; I think once you hit a certain level of intelligence the rest is far more preparation and experience (and yes I'm getting Malcolm Gladwell on your ass) - so all a failed interview indicates is (assuming you are an at least moderately talented, moderately intelligent candidate) one or more of the following:-
* Lack of preparation (knowing the stuff, and practicing the stuff)
* Poor/incorrectly focused preparation
* Lack of confidence
* Bad luck - e.g. haven't looked at binary search for x years they ask about it, or what Steve Yegge termed the 'interview anti-loop'[1] - basically the guy interviewing you just doesn't like you and that's that.
The biggest problem with these things is that people (and I'm kind of talking to myself here more than anyone) take these things personally and put it down to some idea of talent that you might just lack. Fuck that.
The problem is that - and I'm risking repeating a well-known cliche here - hiring good people is extremely hard, and a false positive is way more damaging than a false negative. It is right, IMHO, that (good) companies probe algos, os fundamentals, etc. as this stuff matters; however failing an interview emphatically does not mean you suck.
[1]:http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...
I cannot emphasize enough how much more awesome it makes your company look when you have a streamlined recruiting process!
Similarly, I wouldn't even bother to bring in a candidate who transcribed his interviews elsewhere.
"Similarly, I wouldn't even bother to bring in a candidate who transcribed his interviews elsewhere." - Well there are gazillion blogs and books written on technical interview questions including by ex google, msoft and apple employees. So is it really that bad that a sophomore student decided to blog about it for the benefit of fellow students.
> I got an internship with The New York Times
> the following week.
In any case, well done. Technical interviews are hit-and-miss at any stage in your career, although I have to say that a coder worth his salt should be able to code up a binary search in no time at all. Even a college sophomore.