> They're not looking to fill any particular role. They're just looking for smart people I've found this to be decidedly not true, from many recruiter contacts. They have a role in mind they're trying to fill and if you point out that it's far more junior than what you're looking for, the conversation's over. Think about how must companies hire. The hiring manager fights internally and finally gets a req for a very s…
Nobody does that because being smart is of no guarantee that this person can be of any use to a business.
You make it sound as if some other hiring method provides a guarantee.
the problem with the way Google interviews is that, despite it being heavily standardized, it is not sensitive to non-algorithmic skills and talents that interviewees have. It will _only_ pass candidates who are unusually good at algorithm puzzles, on whiteboards, under time pressure.
This seems to be the type of employee Google is looking for, in which case, it works great.
Maybe it's not what they are looking for. Maybe it's only the easiest test, like looking for the keys under the lamp post. It could also be that this way of hiring people turned the company into a specific direction, more attention to the sw and less to the customers.
The worst part for me is how long the process takes, and how much time is invested for an interview process where the success rate is so low. My recent experience with AMZN was: - get contacted by recruiter, schedule a call with recruiter a few days later - take a take-home coding test a few days later - talk to the recruiter again a few days later to tell me I did well on the coding test - talk to another recruiter…
Wow you're lucky they even tell you in the interview that they were close. Google can take many weeks to get back to you, from what I've seen.
> There is no point in giving me binary-tree-traversing questions; I don't know those answers and will never be interested in learning them. They are just looking for smart people. If you ever looked it up it's 5 lines of code. That's the whole point they're not forcing you to learn something: A) so esoteric you will never encounter in your programming career B) so complicated that you'd have to spend days practicing…
You mean like the famous inverting tree whiteboard exercise that the Homebrew author failed? Which lead them to refuse to give a job to the guy that actually developed a software used by those with higher IQ to come up with tree inversion algorithms?
Yes, I completely agree with you that their recruiting system has a lot of false positives, but I was just clarify that algorithm questions are really IQ questions, which is as you rightly point out is a flawed proxy for predicting how well someone will perform in their role.
I'd be interested in hearing from people who work at Google, and get to figure out a cool algorithm for solving an interesting puzzle-problem more an about once a year. I bet there aren't very many. In my experience, the stuff you do in this kind of interview has very little relation with the stuff you do in the actual job. (I wish it did! I love those algorithmic puzzles.)
I don't know about the average but at Google I probably write a new call to std::set::find twice an hour, and it's important to know that std::set is a red-black tree, and how std::set::find is implemented and how much that costs and so forth. Fluency with data structures and algorithms is not some kind of brain candy. It's absolutely necessary to get the job done.
I've been a developer for 30 years, helped start a half dozen companies. Since college I've never written a single tree traversing algorithm, and would need to Google red-black tree to know what it is.
There is a whole world of development that is OS specific, UI specific, shipping commercial applications. Shipping quickly is always a higher priority than performance, because adequate performance is usually trivial to implement with hash tables/arrays/linked lists.
Interviewing only with your eventual manager is massively inefficient. Imagine I'm a hiring manager with one headcount available. Let's say Google gets about 5000 applications per day and hires 50 people per day, so I need to interview around 100 people to fill that spot. If two of those people meet my criteria, the extra ones get rejected anyway. Even more time is wasted than with the algorithm question approach (and honestly, stuff like tree traversal comes up all the time, even in client application code, so you might still get asked about it).
I'd be interested in hearing from people who work at Google, and get to figure out a cool algorithm for solving an interesting puzzle-problem more an about once a year. I bet there aren't very many. In my experience, the stuff you do in this kind of interview has very little relation with the stuff you do in the actual job. (I wish it did! I love those algorithmic puzzles.)
figuring out a cool algorithm is not the same as learning 1000 algorithms by rote to prepare for an interview. Just because doesn't feel like doing test prep for an interview, it doesn't mean they don't have the brain capacity to actually solve the business problem when it comes up. If in my day-to-day I need to use an AVL tree, I will get a library for it, I won't be reimplementing it from scratch every single time.
This is what has confused me for a long time, I interviewed at Flipkart an Indian ecommerce major (ex?) and their process was horrible. At the second round they asked us to implement a toc tac toe program, others didn't even have compilers, I had Python because it was a Linux machine, was rejected because "code contained bugs and didn't run", the third round was algorithms. I think these companies don't know how to hire that's why they are sticking to algorithms, in real life nobody is going to implement an algo from scratch, if I can learn Go in a week, learn how to write a webapp in 2-3 weeks when I have never written a webapp before why does it matter if I don't know how to implement some random algorithm?
Unlike most of HN (it seems), I like hearing from recruiters, because despite the very low signal-to-noise ratio, there's always that remote chance that one of them could be able to set me up with a "dream job". It's zero cost to me to politely reply to a recruiter and ask for more info, and I try to at least respond to everyone. What I've found is that they must have a lot of candidates they're juggling because fall…
My partner works at a recruitment company. Here's the thing: most recruiters are not very good at what they do and are only chasing placements. To get the most out of recruiters you need to be more pro-active, and find a recruiter or two who really understand your skill set and career ambitions. Build a relationship with them, and don't waste time with the other 90% of batch mailed crapshoots.
There is no standard way to interview a software engineer. Whenever one of these threads come up we see multiple posters explaining their process, and while each process has it's upsides and downsides, no two are exactly the same. For a company the size of Google, with the amount of applicants they receive, I would assume that an interview standard is absolutely necessary. It's not perfect, but for 95% of developers…
What I don't understand is that this person hasn't even had a Google interview... They literally say
"I won't accept an interview at Google because:
1. I had a bad interview at Amazon (???)
2. I read a story on HN about someone having a bad interview at Google
I'm sorry but that's an awful excuse. As you mention, Google works at an insane scale, and as foolproof as you try to make a process, there will always be a very small chance that it'll fail. Doesn't mean the whole process is bad.
And there's the whole bias that you'll only hear from horror stories and never from success stories.