That's completely false, and anyone who says that is completely ignorant of Bayesian logic.
Here are some simple numbers.
Suppose that a "good" candidate is a 1-in-100 find. Suppose that a "bad" candidate has a 1% chance of tricking you into hiring them anyway.
Every time you pass on a "good" candidate, that is greater opportunity for a "bad" candidate to trick you into hiring them!
Counterintuitively, if you pass on too many of the "good" candidates, in your overzealousness to reject bad candidates, you're actually INCREASING THE ODDS OF A BAD HIRE.
This is management porn. "It's better to reject a good candidate than hire a bad candidate." It makes the manager feel good. "Wow! That candidate seemed smart, but I rejected him anyway! I'm such a great leader! I make the tough decisions!"
tl;dr summary
Because "good" candidates are rare, every time you pass on a good candidate that increases your odds of making a bad hire! This is simple Bayesian reasoning!
A bad hire can easily cause more friction than if nobody was hired at all. Net effect for the business is negative. You're also probably severely overestimating the likelihood of a bad hire going through.
FSK: If you pass on many good candidates, and you have a small chance of hiring any given bad candidate, then each good candidate you reject actually INCREASES your odds of making a bad hire.
Idiot: We made a bad hire once! Never again! Now we reject lots of good candidates to avoid that repeat disaster!
FSK: But, if you want to minimize your bad hire rate, you also have to minimize the number of good candidates you reject.
Idiot: NO! NO! NO! The way you make sure you hire no bad candidates is to be so strict that you reject lots of good ones! That's what everyone told me so it must be right!
In one ear and out the other. Why do people who don't understand statistics get to be managers? If you don't understand this statistics argument I made, you're unqualified to work in any sort of technical area.
Hiring a good employee is not nearly as impactful as hiring a bad one. If you can have a strategy that filters out 100% of bad employees, but unfortunately also filters out 90% of good employees, this is preferable to filtering only 50% of good employees, but also only filtering 90% of bad employees. You may have more good employees with the latter strategy, but the bad employees can kill the team.
Firms are hierarchy-based entities. "Technical Merit" is about a third or fourth order away from what really drives the hiring decision. Its also very imperfect predictor of actual performance.
The issues is that companies use the term all the time. They want people to believe they were hired for their merit, but merit is almost always 'fit' and not technical in nature. The technical hoops are just a CYA for when the 'fit' doesn't work out (mis-judgement) and they need something to point to as to that is not arbitrary in nature to explain how other people were not hired instead.
Whether or not this actually reduces the number of bad hires is beside the point. It's a classic principle-agent problem.
They fear they might be bad candidates. They'd rather reject too many than too few, so they make sure they reject everybody who they're not 100% is a good candidate. That means they may reject some good candidates that aren't easily identified as such, but it doesn't increase their chance of hiring a bad candidate; it decreases it.
But the cost and other effects of doing so vary significantly depending on where you are. Most of the US may have at-will employment, but much of the rest of the world does not.
We had a really bad hire about 2 years ago. So bad it caused us to review our entire hiring process to understand how he got in. It took almost a year before he was fired (and he was a contractor so it should have been easier). In that time, he used up untold resources while we tried to find work he could actually do, people helping him "just in case he just needed a helping hand" and so on. Finally after wasting other people's time for 9 months, a manager made the decision to get him out.
A year later I got an email from him asking for a recommendation. Nothing ventured, nothing gained I guess.
I.e., I don't know your particular situation, so I wouldn't dare to assume the reaction was wrong, but too often "we much at all costs make sure it never happens again" overwhelms any attempt at reasonable approach and cost/benefit analysis completely. Maybe getting one bad apple in occasionally is a reasonable price for quickly and efficiently hiring a lot of good people?
Why did the manager wait so long?
Employee X is hired. After a month it becomes clear to the whole team that X is a bad hire. But how do you turn a subjectively obvious feeling into an objectively obvious reason to fire. Because if that person decides to sue the company after getting fired that's what you will have to demonstrate.
Just imagine how hard it is to quantify what makes someone good at our job? Code Quality? Team dynamic? These are really fuzzy metrics.
You could document how many times the engineer affected production badly and how much that cost the company. But to be realistic even great engineers do that. Heck I touched production at Google and decreased revenue by millions of dollars and it was expected that this happens. So you'd have to let him affect the company enough times to be obvious He's worse than your other engineers.
You are going to have to have documented enough clear failures to do the job to justify starting the process of firing. If you don't have a performance improvement plan then you might be able to speed up the process a little. However not having a performance improvement plan is both a bad idea and, I would imagine (IANAL etc.), could cause problems later on down the road in a potential suit.
Taken in that light 9 months doesn't seem that long at all.
It is "at will employment".
There is no need to prove that employee is causing losses.
It's the employee who has to constantly "prove" to employer that this employee's salary is justified.
I personally have worked with several awesome people that have interviewed with Google, and none of them got hired. They all said the interview process was flat out insulting.
Interestingly enough, most of them ended up at Facebook.
Not sure if you have ever been a manager, because firing someone is NEVER easy. It hurts everyone emotionally. The person getting fired feels awful. The person doing the firing feels awful (unless they are a real sociopath). And team morale tends to take a big hit.
Here is my stance: if you hire someone who isn't a good fit, unless they actively deceived you, it is your god damn job to find a way to make it work. As a principle you should treat people with respect and dignity, and not as easily disposable and replaceable cogs.
That attitude is how bloat happens. There is a middle ground here. Not firing bad employees also hurts many people emotionally as does an underperforming, overbloated company. Employees are as replaceable as employers. To use a sports analogy, it's the big leagues and you may not make the team and often times it is hard to know whether someone can make the team without a trial. I believe these draconian interview practices and contract-to-hire approaches are a direct result of the never-fire-bad-employees attitude.
Ergo they own the problem, not so much the Noogler. Also generalists == mediocre code in my experience because there's no passion for such work in a lot of people who are fantastic with other in-demand skills, but I digress.
And when I joined, Google wasn't so much bloating as it was metastasizing. Most of the people I knew who joined around the same time have long since left. In contrast, I've been at the same gig ever since I left Google. The Google experience was the outlier.
I'm not sure if this is the norm--I believe it differs for industry hires versus those fresh out of school--but it's certainly not true that, as a rule, you can never meet potential teammates.
Because for the most part, Googlers aren't bozos (although a couple of the true believers in the Googleplex blew my mind with how crufty their skills and knowledge had become), but that doesn't rule out one of the many great engineers there promoted to their managerial level of incompetence. And that's what I had - a guy with no people skills whatsoever - and two teams with a total of 20+ engineers to "manage."
No, it isn't. This is why probation periods exist. If you hired someone and they aren't working out, then at the end of the probation period you don't keep them on.
Trying to force someone who doesn't fit the team dynamic to stay is going to hurt your org. It doesn't make you a "good" manager to say to everyone "I know this sucks but deal with it because letting them go would mean I was wrong."
> As a principle you should treat people with respect and dignity, and not as easily disposable and replaceable cogs.
Which is ironic because so many job descriptions I see today are basically written as "we want to hire someone with exactly these skills, who requires zero training, and can become an expert in our systems in their first week."
No one is that way, unless your system consists of pressing one button all day, but then the job description would probably require that the person have intricate knowledge of the button and is friends with the engineer who designed it so they know what to do if the button suddenly stops working.
If companies actually treated people with respect and dignity, I'd get the training I need to become a better employee, instead of going to management and begging them for any training every 6 months like the industry is now.
/rant
Doesn't this rather presume that your "team dynamic" is actually good to start with?
Let's say you had a team of not very good engineers. Then you hired quite a good engineer who looked at all the terrible practices (e.g. no version control, shitty or nonexistent testing, poor build processes) and said to themselves "look, I need to fix this shit or I'm leaving, and I've got ten better offers in my inbox".
They might not be a very good team fit, but that's because the team is filled with idiots who haven't figured out how to use version control or whatever.
So, you know, the best thing to do is to get rid of them for not being a culture fit or for not being good for the team dynamic...?
Yes, if you have a team like this and you hire someone who has a higher standard, there is going to be some friction between them and the existing team members. Letting that person go isn't your concern, because as you said yourself:
> and said to themselves "look, I need to fix this shit or I'm leaving, and I've got ten better offers in my inbox".
I've been in that situation before. I was hired to a company and when I got there I found out that every single day they were fighting fires because of stupid decisions management made with little foresight into how it would affect the team. Funny enough none of this was mentioned during the interview, although it was a definite red flag that they had high churn for this particular position.
I stayed there for my probation period trying to fix things so the team would fire fight every day and change management's mentality, but it wasn't happening, so I gave notice and went somewhere better.
> So, you know, the best thing to do is to get rid of them for not being a culture fit or for not being good for the team dynamic...?
No, you took me too literally. Obviously if you've got someone who has friction with the team, but they're a hard working individual who is trying to make your team better and more efficient, you should try to work through those stressful periods because in the long run it will be better for your team's health and the company's health. If some of your low performers leave during this period, that's okay, they were only going to hurt you in the long run. That being said, don't burn bridges with your existing employees. Try to find a happy middle ground that results in a better work environment for everyone.
I have also quit a job because they fired the wrong person.
In my opinion, if you fire someone and the reaction from the whole team isn't "thank god, that guy needed to go", then you made a mistake firing them and should have tried to make it work. In the past when I fired someone, the general reaction was much more along the lines of "what took you so long". In both cases I was the one at the table defending the person while everyone else said they needed to go.
Interestingly, in both cases the reason for firing them was that the person in question was not treating other people with respect. So what is worse, letting one person shit on your whole team and make everyone else feel bad, or getting that person off your team?
Managing isn't easy.
If the candidate cannot invert a binary tree and gets mostly there, and has demonstrable real world software, it's a different thing.
What does that even mean? Swap left-right child nodes? Write it linearly (n-th children at 2n and 2n+1) and reverse it as if it was a string? OP later described it as "to min-max the tree, ascending to descending." confusing me further.
That doesn't disprove what he said. In fact it strengthens it and makes missing a good hire even worse, because, as he said missing good hires -> MORE change of bad hires (that can "poison your team").
In other words, it's not a choice: "I'm better of rejecting a good hire than getting a bad one, because a bad one could poison the team".
By rejecting good ones, who're actually getting MORE bad ones. So it should be corrected to:
"I'm better of NOT rejecting good hires, or else I'll get more bad hires and poison my team".
Humans are more complex than that. I don't think you can assume that candidates will perform the same all the time. Sometimes an excellent candidate can perform badly for multiple reasons (e.g. nervousness, poor preparation, bad interviewer, personal problems, etc).
It seems to me, that rejecting a good candidate, and have him/her interview again after some time, if that candidate was a 'good-hire', then it would increase the chance of hiring him/her, since it is most likely they will prepare better, and know what to expect.
If your flawed process rejected a good candidate the first time around, what makes you think the same flawed process won't reject them a second time?
I'd never even apply to Google based on the stories I've heard, and I'm sure there are plenty of others in the same position who are even better at what they do than I am. There are just so many stories out there of how crappy the hiring process is that everyone who's any good must have heard about it. Some significant fraction will have said, "Yep, not for me."
The theory behind the "raise the bar" argument is that obviously good hires are easy to spot (this is the part most people reasonably take issue with), so people who do not pass that bar of "obviously good" aren't worth taking a risk on. The conclusion is statistically reasonable if you accept the premise (which, again, you probably shouldn't).
This is only true for new grads. The population of engineers with ten years of appropriate corporate experience (that match the technology survivor bias) and at the ~12 locations google can use is tiny.
When I look at my old corporation, only 3 people (of 500+ I would be aware of) were hired by google. One of them is genuinely great, but I doubt he passed the current process as a blind hire. The other two I wouldn't want to work with, but I bet they passed this process precisely because the right kind of focus. (I.e. everything people around them didn't know was their priority and since we normally focus on what's important to completing our project, none of that was so important..)
I was very interested in google when I was under the impression that (without experiencing menlo park on a daily basis,) I could either walk away with over $500k (gross) in 2- years, enjoy working there for 5 years, and/or work with the best >experienced< engineers in our field. When glassdoor and my own linkedin network revealed my best perspective into their setup, blind applying to them is now just a good filter to test my new age employability skills. So, now they've built themselves a new problem of true positive false positives who are just along for the ride.
The hiring market is already NP Hard for both sides when you are genuinely trying to get a good enough fit for yourself rather than the best deal on the market. If you try to misuse the other side they will see less ethical constraints in using the resources you'll have to put in.
How many developers genuinely want a job they can't do that they will have to be awkwardly fired from in six months and explain at every future interview?
Yes, but what hiring managers are doing isn't passing over candidates that they know are good, they're passing over candidates that they're not very sure about.
> Because "good" candidates are rare, every time you pass on a good candidate that increases your odds of making a bad hire! This is simple Bayesian reasoning!
Similarly, of course this is true, but again hiring managers aren't passing up candidates that they know to be good, they're passing up on candidates that they're not sure about, whom the acknowledge could be good.
Under certain conditions, every time you pass on a candidate you're not sure about, you decrease your chance of making a bad hire. The conditions are that increasing hiring standards must weed out more bad candidates than good candidates.
Let's work with your model. Suppose 1% of candidates coming for an interview are good and 99% are bad.
Hiring strategy A manages to hire all good candidates it interviews, and 1% of the bad candidates it interviews. End result: for every 100 people you interview, you get 1 good candidate and 1 bad candidate.
Hiring strategy B is more conservative and hires 50% of all good candidates it interviews, and 0.1% of the bad candidates it interviews. End result: for every 100 people you interview, you get 0.5 good candidates and 0.1 bad candidates.
The claim is something like, the team produced by strategy B is better than the team produced by strategy A, even though team B has less good candidates than team B.
1) This means that by raising your hiring bar (adopting B instead of A), you eliminate more good candidates than bad candidates. You now have to prove this empirical claim. 2) All I wanted to say was that the statements you made like "every time you pass on a good candidate that increases your odds of making a bad hire!" is only true under certain conditions (namely that raising hiring standards eliminates more good candidates than bad candidates), and it's not "simple bayesian reasoning".
As long as good candidates are rare, and bad candidates have a small-but-nonzero chance of tricking you into hiring them, it's very expensive to pass on a good candidate.
Even if you pass on 50% of the good candidates (no matter how many bad ones trick you), you're doubling the amount of time you're spending interviewing.
The only way to be sure about how many "good" candidates your are missing is to hire some random percentage of the people who fail your interview. Only a large tech company would have the resources to do that, and I'm not sure if it would be ethical, or even get the employer in legal trouble.
NO employer knows how many good candidates they miss out on, which makes this analysis very difficult.
Also, I question the ability of most employers to evaluate employees AFTER they are hired, so any analysis of post-interview performance might just be reinforcing whatever biases are present.
Also, candidates fall into THREE groups: great, mediocre, and toxic. The catch is that the toxic ones are most likely to trick you into thinking they're great. That makes it even more expensive to pass on a good candidate.
Yes, I agree with you. My point is that even taking this into account, even after taking into account all the other costs you mention into account, it might still be better to pass on candidates you're not sure about.
> The original slogan "It is better to reject a good candidate than hire a bad candidate." specifically says to make that fallacy.
So going by the slogan, even if passing on too many good candidates increases your odds of a bad hire (say from 50% to 80%), it's still better than hiring a bad candidate, since if you hire a bad candidate, the odds that you made a bad hire is 100%!
My interpretation of the slogan seems different from yours, mine is something like: if you hire a good person the value of your business will increase by X, if you hire a bad person the value of your business will decrease by Y, and Y is much greater than X.
In practice, they select for people with good memorization skills. If you can remember the details on a ten dozen different algorithms and data structures, you can pass one of these without having a single lick of creativity or skill.
I say this as an employee who has worked alongside many unskilled drones who made it past the algorithmic interview process.
Infatuation with "coding competitions" and high flux intelligence tasks is often an anti signal.
Sure, what they demonstrate looks good at face value, but unless you attach a micromanager over their tasks, they'll constantly deviate to the new-shiny every week instead of staying on task for the long haul.
I know even YC has been bitten a few times by accepting people who are top-performers in very narrow contexts (e.g. people obsessed with winning coding competitions every single weekend) only to see they can't do anything coherent for more than a week at a time.
Just because someone is great in a narrow context doesn't mean they can carry that over the months and years needed to deeply iterate (and suffer through the low points) on successful projects.
Basically, imagine that there's two ways to graduate college with a CS degree - you're either the kind of person who's smart enough to get things if you work your ass off for them, or you're a genius and you coast through. If you're a genius and you work your ass off, you get a doctorate or found a startup, and aren't in the candidate pool. So you wind up with a choice about what to compromise on: work ethic, or smarts.
Ideally, you compromise on whatever makes the least difference to your organization, compared to your competitors. Hiring smart/motivated people out of non-traditional backgrounds is a great option for this.
They're more interested in how you approach real world issues (the questions I got asked were conceivably real-life issues a company like Google would face with its products). If you can solve that issue by applying efficient and well understood data structures and algorithms, then that indicates you understand the problem space and solutions that may apply.
It's not like they get you in a room and ask you to draw a linked list or a binary tree.
And yet the OP was turned down for not being able to invert a binary tree (based on limited information, etc etc.)? What do you feel that is, if not a "whiteboard this algorithm" question?
As for many of the other companies who try and emulate Google - this is exactly what they do.
Your source is a series of salty tweets.
And in either case, my original comment was directed at the idea that "algorithmic interviews provide false negatives, but not false positives".
You say that as if it's a good thing. Do you expect that most people could be e.g. effective teachers, effective marketers, or effective taste-testers, with no previous experience?
On the other hand, knowing that DFAs are equivalent to regexes are equivalent to NFAs is already a step of theoretical knowledge that any "Just let me write code" so-called "dev" is likely to complain about being asked for.
I too don't remember much.
Regardless, I only meant to make the point that I disagree with the comment "They're more interested in how you approach real world issues" and that this statement is false: "It's not like they get you in a room and ask you to draw a linked list or a binary tree"
edit: by "expert" I just mean something I'm particularly skilled in, not something I'm an authority in from theory to practice.
I was later declined. Had a couple of friends at google ask the interviewer. He said I was declined for not finishing my data structure.
Their interviewing process was quite frustrating. I'm fine with getting declined but not under those circumstances.
That was my first technical interview over the phone so it was pretty obvious it was related to that single interview. One of the Googlers I knew that checked the system said the same.
I had the impression that they all had to agree for a hire. Hence one no means no hire.
Obviously he didn't give 1 shit about "how you approach the real world issues".
Once you get to that point, though, if they asked me "and how would you invert the tree in-place?" I'd answer "well, first I'd make sure we aren't just using a tree structure that already knows how to invert itself, or could easily be extended to know how. Then, assuming that didn't pan out, I'd google 'in-place invert binary tree' and read three or four solutions that already exist to burn the semantic structure of what I'm about to write into my head so that I don't subtly screw it up and have to fiddle with it for the next hour when I could be coding something else. Then I code it."
And that should be enough.
I had two phone interviews - the first had quite a few questions about my prior experience (over a decade) and how to approach real-world problems from a high-level, including some that I had worked on at my current position. The second was primarily purely technical, but did have some more theoretical/project-management-y type of questions. In neither one was I required to write any code.
On-site: one interview was entirely whiteboard-coding (in a collaborative style), on a set of related generic problems. Next was one with a set of problems related to my experience. Third was almost entirely telling war stories. Last two were some generic graph-theory-type problems and some simple problems involving data structures relevant to the my area of experience.
As I hadn't interviewed for anything in 11 years, I did spend some time brushing up on my basic algorithmic theory, and essentially followed Steve Yegge's suggestions. I honestly think I probably could have done the vast majority of it without any studying, but spending time practicing solving problems on paper (with a countdown-timer as an artificial pressure-inducing device) certainly did help me, I think, in the on-site. No amount of memorization could have helped with most of it, aside from basic knowledge that anyone who's taken Data Structures should know.
I didn't find the process to be insulting at all; it was an enjoyable challenge. Everyone I talked with on the engineering side of things I can only say the best about, and so far as I can tell the team I'll be with has some really great people. I am a more senior developer, so perhaps I got a different experience than some.
Another in the same interview got in my face (this should be easy) when he thought it was taking me too long too multiply two numbers like 637 and 41 during an estimating problem. I understand the point of most of these questions is quick and dirty estimation (600 x 40), but seriously...
637 is an awkward number, we'll start by rounding up to 640: 640 * 2 = 1280, anyone in tech knows 2x that is 2560.
Make up the missing 3: 3 * 4 = 12, 2560 - 12 = 2548.
2548 * 10 = 25,480.
25,480 + 7 = 25,487
25,487 + 30 = 25,517
25,517 + 600 = 26,117.
That said, I did make a screw up when calculating it, and added the 637 before multiplying by 10 (which may have been the differentiating part of that question, combined with the intentional stress, to see how you cope with pressure? Although I didn't sleep last night, which might be the cause :D). I dunno if they wanted you to do it as quickly as 600/640 x 40 though, which obviously makes it much more difficult.
Afterthought, due to sleep deprived state, quicker way to solve:
600 x 40 = 24,000 40^2 = 1600 25,600 quick and dirty, for accuracy: 3 * 40 = 120 25,600 - 120 = 25,480 25,480 + 600 = 26,080 26,080 + 37 = 26,117.
Sorry, this comment turned into a bit of a ramble.
It's important to know how a person approaches a hard new problem and how easily or not they give up. I'd guess that a person who didn't solve a hard problem, but got close enough by displaying creativity, curiousness and a solid thought process might have an edge over a person that implemented a familiar algorithm with ease but got a little flustered, and didn't show much creativity or inquisitiveness, when challenged with something new.
Whiteboard interviews might miss eccentrics who can't express their clever thoughts verbally or visually, but it can depend on how tuned in the interviewer is to these eccentricities or how much value their team puts on expressive skills.
Algorithm/data structure interviews, whiteboard or not, also have the added benefit of being exceptionally good at eliminating candidates that:
1) Drastically misrepresent their skills
2) Give up easily at difficult tasks
3) Don't seek help from others
4) Frequently have a bad attitude
I had them attempt to solve the problems on a whiteboard that I would give to our intern candidates. Both totally bombed hard, and our other "re-interviewers" had the same result when they asked some design-related and algorithmic related questions.
This wasn't "regurgitating algorithms". It was basic problem-solving and software design. From their track record of development we didn't believe them to be qualified (despite their own opinion of themselves), and they only confirmed it by totally bombing the "re-interview" process (which was identical to our normal interview process).
The only way to validate your highering process is to randomly accept people you would otherwise fail. Anything else is meaningless.
I recently interviewed for a security engineering position at a startup, and while I got offered the job, the interview was quite silly.
The first thing I was asked to do was to write a lisp interpreter. It was a pretty trivial task, but it left me scratching my head since not only did it not tell them about whether I would be qualified at all, but I had explicitly avoided writing parsing code since I found ANTLR during undergrad.
In the end I wrote a basic stream abstraction and wrote my lisp interpreter on top of it with no real difficulty, but it was a completely stupid question. I told them on the third interview that they weren't asking me anything relevant and I still got another question later on about how to iterate over a tree in a specific order.
Part of the issue was that most of my interviewers were fresh out of college, it was literally their first job and they had no idea what to ask besides the kinds of questions they had been asked in their own interviews.
In the end there were a lot of other issues that made me not take it, but not knowing what is necessary seems pretty typical wrt security. However, in those situations you want to have wide latitude to affect change because the thing they hire you to look at is probably not really where their problems are.
Say I pass the invert a tree question. Does that prove I am good? That I can design a product, listen to customer requirements, come up with ideas that elude others, read a research paper and turn it into something commercial, solder a circuit board, make a schedule, mentor junior engineers, write documentation? No. All inverting a tree tells them is I studied trees recently, and/or I'm at least superficially clever.
Google lets go of plenty of people. They aren't making perfect hires.
Other than to wonder why they still haven't done anything about it. (I interviewed there ~8 years ago, pre Android when they were looking for deep mobile expertise and got flunked out on a similar problem. I am not at all interested in working for them now)
But do you? How catastrophical would it be if Google accidentally hired not the top 0.001% but instead somebody from top 0.01%? I mean, same people that build everything else around us and the world still didn't collapse yet? I get it, you have to have standards, and you don't want to waste time and money on somebody that can't pass fizzbuzz test. But once you've moved past that - do you need to obsess so hard on ranking and quantifying it? There are probably some positions in Google that require people to invert binary trees (speaking figuratively) day in and day out, but my decades of experience in the industry shows that most positions aren't like that. I've not worked for google but I'm pretty sure it's also this way there. If you hire smart and competent people, it's OK even if they don't reverse a binary tree here or there.
Can they, though? Obviously they believe they can, but are they correct?
Google's not going away any time soon, but they could easily slip a long way down from the top of the heap. There are signs that's started to happen.
I don't think they can be nearly as casual about losing top candidates as they seem to believe. In five or ten years we'll know, I suppose.
I also know a few "top talent" engineers that rejected the google offer because they didn't like the process and the people they met. I know even more ex-Googlers that quit within the year of starting there.
It's not an issue for them? From where I'm looking, most of the experienced top talent (that it's not working at google already) is keeping away from it, in greener pastures and most won't look back.
Yep, google is not going anywhere anytime soon, but I'd be just a bit concerned if I were them.
Like I said, Google is still an amazing company, but it is by no means the only one out there. Talents won't come to work for it just because it is Google, without great compensation and interesting projects.
It never worked, what do you think happens when you start asking these kind of questions in interviews? People just go out and spend insane amount of time memorizing solutions to interview questions on the internet.
They continue the same after you have hired them. So their on the job productivity remains low. Please note, they need to prepare for their next job in the current one.
So the only thing this results is in people spending insane amount of time preparing interviews doing very little work in their day jobs.
I never realized that some people put as much effort into practicing interview questions as I put into learning how to actually write software.
Does this mean technical interviews, even a structured interview, are completely useless? I.e., if you follow an interview script, eventually candidates find out about your script, and then it's useless.
Good teams have a balanced skill sets I've found. You need some uber-algorithm guys who can pass questions like this, but you also need engineers who can fill in all the rest of the tasks that make up a production worthy system. I have not found that the uber-algorithm guys always pay attention to detail, put in good comments, think of all the edge cases, communicate well with outside teams, etc.
Those types of engineers are what you consider a "bad hire", and won't be working at Google.
What's to keep a good engineer like you describe from buying a couple of books and spending a couple of months working on becoming the type of person that can do well on these questions?
Google doesn't make everyone multi-millionaires anymore. If you want me to jump through a bunch of hoops for you, you'd better have a pretty solid case for what the outcome will be.
By actively selecting against people who don't want to answer bullshit questions, they're definitely turning away creative, talented people. They're selecting for different people instead. Perhaps that's what Google needs to feed the machine now that the company is mature, so I won't necessarily fault them for it. But that filtering or selection IS happening, even if they don't think it is.
IQ tests supposedly become inaccurate after 150/160, so you wouldn't really want to put too much emphasis on 180 vs 170 at those levels.
"Hmmm... it looks like this guy really gets around. He's on the same project at GoodProgrammer A and GoodProgrammer B. He also tweets about functional programming and was mentioned in GoodProgrammer C's latest blog."