Has it been two weeks already (since, you know, the last thread complaining about Google's hiring processes)?
You can know a library that does exactly what the question wants, if anything that's a plus, but you should roughly know how something like that actually works.
Our process isn't problem-free. We gets hundreds of thousands of applications a year. Who else has that scale of a recruitment problem?
There are a lot of myths about our interview process. Take this post: he says he doesn't have a degree from an "elite university". Neither do I and neither do most of my coworkers.
Having no degree at all is a problem but not an insurmountable one.
As for us allegedly not being interested in your open source contributions, nothing could be further from the truth. Recently the guy who did Firebug just got hired to work on Chrome developer tools. Do you really think his Firebug work had nothing to do with this?
As for what team you'll be working on, you as a candidate have a lot of power in that regard. You can specify you're only interested in working on something in particular or you can simply communicate some preferences. Those preferences affect the allocation process.
Our predilection for simple coding problems and requiring a certain level of algorithms knowledge is nothing new. What constantly surprises me is how many people I see go through the process that obviously haven't just picked up a copy of Skiena's book and brushed up on the fundamentals.
I can understand the motivation of people not to go through the process a second time. I was in the same boat. It can be a frustrating process. It's imperfect. Occasionally I'll hear people say they will never go through it because of what they've heard.
As Homer puts it, "trying is the first step to failing".
I'll leave you with three recommendations for anyone interested in applying here:
1. Go through the first half of Skiena's algorithm book (the last half is applications, which, while interesting, isn't as crucial). If you're not comfortable with graphs and dynamic programming, sorry but you just haven't prepared;
2. Practice some code problems on a whiteboard; and
3. Go through recruitment with a referrer. You're MUCH better off with a recommendation from someone who already works here. Even if they don't necessarily know you (and thus can't provide a strong reference), they can chase up what's happening with your application with the recruiter and probably get more information than you, as an external applicant, can.
EDIT: let me add a fourth piece of advice:
Treat your career at Google, if you're fortunate enough to have one, as a marathon not a sprint.
If you're really unhappy on whatever project you end up on or with the team you're with, that can all be changed. A lot of effort is made to make people happy. So you can express your concerns and disappointment with your manager, your manager's manager, HR or whatever is most appropriate.
Additionally, the ramp-up time at Google can be significant. 3-6 months. Possibly longer. Another approach is to do what project you end up, learn our tools, build system, processes, etc. In that time make connections to other teams. Find out what else is going on and what you're interested in doing.
There is an awful lot of internal mobility that's possible.
You can know a library that does exactly what the question wants, if anything that's a plus, but you should roughly know how something like that actually works.
Our process isn't problem-free. We gets hundreds of thousands of applications a year. Who else has that scale of a recruitment problem?
There are a lot of myths about our interview process. Take this post: he says he doesn't have a degree from an "elite university". Neither do I and neither do most of my coworkers.
Having no degree at all is a problem but not an insurmountable one.
As for us allegedly not being interested in your open source contributions, nothing could be further from the truth. Recently the guy who did Firebug just got hired to work on Chrome developer tools. Do you really think his Firebug work had nothing to do with this?
As for what team you'll be working on, you as a candidate have a lot of power in that regard. You can specify you're only interested in working on something in particular or you can simply communicate some preferences. Those preferences affect the allocation process.
Our predilection for simple coding problems and requiring a certain level of algorithms knowledge is nothing new. What constantly surprises me is how many people I see go through the process that obviously haven't just picked up a copy of Skiena's book and brushed up on the fundamentals.
I can understand the motivation of people not to go through the process a second time. I was in the same boat. It can be a frustrating process. It's imperfect. Occasionally I'll hear people say they will never go through it because of what they've heard.
As Homer puts it, "trying is the first step to failing".
I'll leave you with three recommendations for anyone interested in applying here:
1. Go through the first half of Skiena's algorithm book (the last half is applications, which, while interesting, isn't as crucial). If you're not comfortable with graphs and dynamic programming, sorry but you just haven't prepared;
2. Practice some code problems on a whiteboard; and
3. Go through recruitment with a referrer. You're MUCH better off with a recommendation from someone who already works here. Even if they don't necessarily know you (and thus can't provide a strong reference), they can chase up what's happening with your application with the recruiter and probably get more information than you, as an external applicant, can.
EDIT: let me add a fourth piece of advice:
Treat your career at Google, if you're fortunate enough to have one, as a marathon not a sprint.
If you're really unhappy on whatever project you end up on or with the team you're with, that can all be changed. A lot of effort is made to make people happy. So you can express your concerns and disappointment with your manager, your manager's manager, HR or whatever is most appropriate.
Additionally, the ramp-up time at Google can be significant. 3-6 months. Possibly longer. Another approach is to do what project you end up, learn our tools, build system, processes, etc. In that time make connections to other teams. Find out what else is going on and what you're interested in doing.
There is an awful lot of internal mobility that's possible.