Some perspective from the interviewer's side may help here:
- A Google interviewer's (and I would assume any interviewer's) primary goal is to come out of the interview with enough confidence to give a positive or negative score. If they sit down to write feedback and have to give a neutral score, the interview wasn't productive. This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
- Doing interviews at Google is volunteer work. You are not interacting with a professional interviewer, you're interacting with someone whose day job is being an engineer. They don't have an evil agenda; they are doing this because they want to help Google hire the best candidates, and by inference make sure their future coworkers are good people to work with.
- Interviewers overwhelmingly _want_ their candidates to succeed. It's a true joy when I have a candidate who glides through a question (or finds a solution that was even better than mine). When candidates struggle, it's not a pleasant experience for the interviewer either.
- In the end, the point of technical interviews is to avoid the terrible experience that is working with an incompetent or uncooperative teammate. Interviewers are trying to find people that (a) can work well with others and (b) can get the work done.
- The system is _highly_ prejudiced towards suppressing false positives. This is the right decision, but it comes at the cost of a high rate of false negatives. Were myself or any of my colleagues to re-interview for our jobs, I would expect about a 60% hire rate. This is not even taking into account the constant ebb and flow of hiring demand. Sometimes there just isn't any headcount. And sometimes you just happen to get questions that you don't click with. This is also the reason that recruiters are so eager to bring you back to interview 6 months later.
- Recruiters and interviewers have very different incentives. Recruiters want to maximize the number of people they get hired; interviewers want to hire people they want to work with. This can lead to behavior that seems schizophrenic from the outside: the recruitment side of the pipeline constantly pestering people to interview, but once the candidate enters the interviewing pipeline the process is slow, deliberate, and careful.
>The system is _highly_ prejudiced towards suppressing false positives. This is the right decision,
This is textbook Google propaganda that has been repeated at least since I last worked there 5ish years ago. It's bullshit though because the ratio of competent to incompetent engineers was the same as at FB, MSFT and NFLX (with the latter tending to prune the fastest).
Just because you generate a system that spits out a lot of false negatives, it doesn't mean it has done anything to reduce false positives. This should be immediately obvious given that the relationship between the questions asked in G interviews and actual software engineering is non existent.
Don't repeat the trope that Google's hiring system is actually better at eliminating false positives. There is no evidence of it and if it truly was better, everyone would adopt it in a heartbeat and we wouldn't be working with bad engineers who spent a few months on leetcode to get into jobs way over their heads.
The reason Googlers never care to critically question the sorting hat is because it picked them.
"The reason Googlers never care to critically question the sorting hat is because it picked them."
I think this is a truism about the quality of most organizations - people who thrive in a specific organization coalesce into the organization and enhance those qualities within the organization that are specific to them.
I presume the fact that Google uses non-professional recruiters makes the recruitment process more about cultural alignment than it absolutely needs to be to gauge the capability to add value in a software engineering process.
All the FAANGs operate under a very similar hiring model, because they all get far more applicants than they can hire and can afford to have a high rate of false negatives. "Everybody" can't adopt it even if they wanted to, because your average business doesn't get a million applications a year.
That isn't really what the comment you're responding to was about. That comment was specifically about the fact that Google purports to target eliminating false positives and the trade off is accepting a high rate of false negatives. In fact there is not necessarily a relationship between the two: or at least not one that Google's process measures.
Oh, but they can and do. The difference between 100 and 1000 resumes is not material—both too many to look at. What I've found is those in the second bracket simply throw out those without a degree and then cargo-cult common practice.
> There is no evidence of it and if it truly was better
Year after year the Googlegeist survey finds that one of the things Googlers most enjoy about working at Google is their fellow employees
> if it truly was better, everyone would adopt it
Google has an abundance of money and an abundance of applicants who would like to work there. Companies with fewer applicants per position or lower salaries relative to the industry average may need to be more open to false positives if they want to be able to hire anyone at all. Smaller companies also have the advantage that they can usually fire people more easily than larger companies, which helps lower the cost of false positives for them.
>Year after year the Googlegeist survey finds that one of the things Googlers most enjoy about working at Google is their fellow employees
Hiring has very little to do with that. Perf review, feedback mechanisms, and work environment are orders of magnitude more critical to that. I've worked two startups with completely different hiring processes from Google and the other employees were amazing to work with there too. The key is feedback to correct issues and a quick PIP/fire process for folks not cutting it.
>This is textbook Google propaganda that has been repeated at least since I last worked there 5ish years ago. It's bullshit though because the ratio of competent to incompetent engineers was the same as at FB, MSFT and NFLX (with the latter tending to prune the fastest).
But those companies use hiring practices that approximate, to a high degree, what Google does. Facebook and Netflix certainly do, and Microsoft has a high enough rate of bad hires that you are required to reinterview to switch teams, so that high performing teams can keep reject bad candidates who are already at Microsoft.
I don't work for Google, so I don't know how much this applies to you folks. In my experience, while what you are describing is ideally correct, it's often just that -- an ideal.
For example, you'll have people insisting (and consciously agreeing) that their objective is to come out of the interview with enough evidence to give a positive or negative score. In the back of their minds, though, they will often be projecting their own insecurities -- about their expertise, about their career, about their job, about their team. Halfway through the interview, things end up being about something else altogether, like interviewers trying to reassure themselves that they're better than who they're interviewing (it's especially hard not to fall into this if it's been years since you last had to implement a red-black tree and you're interviewing a fresh graduate who dreams this stuff in their sleep).
It's very hard to get past these things. I struggle with them every time I interview someone, and it's very hard to know when to chalk it up to "the system" and when to chalk it up to your own baggage. Pretending that it's only the former only perpetuates this stuff -- and empowers the ones who actively enjoy abusing candidates and making them feel like crap just for the heck of it. Which is very common everywhere -- including, from what I've heard among my peers, at Google.
So far, the most relevant compass I've found for these things is made out of two questions:
1. If I were a candidate, and I'd have gone through this interview, how would I feel about it?
2. If I were to go through this exact interview today, would I still get hired?
If the answer to #1 isn't too good, there's probably some individual-level things you can change, but if the answer to #2 is bad, the problems tend to be more systemic in nature.
> The system is _highly_ prejudiced towards suppressing false positives
I wonder if the algorithm centric interview style at Google can really achieve that. From my experience, algorithm centric questions + plus white board coding have bias towards academic people. (Maybe that’s fine for google) However, the way to crack that kind of interview is really just practice like hell on leetcode. Just take a minute and think, who are most motivated in doing that? Good, experienced engineers have no trouble finding jobs in Bay Area, and why would they waste their time on leetcode for skills that are mostly going to be useless in real work? New grads and engineers that have trouble finding jobs are most likely to spend hell of their time on leetcode. I think the interview style at Google is in fact increasing false positives instead of suppressing it. It also has high false negative for sure.
There are tons of other ways of doing interviews, in which interviewer gets a lot more and very relevant signals from candidates while keeping candidates pressure low, and not wasting their time, but Google is not doing it, like asking practical questions, letting candidates write and test their code in their own computers, has a debug session, etc.
I'm a UX Engineer at Google. The tasks we ask you to complete in an interview are very practical - sketching out the same kinds UIs that you might build in the real world.
The impractical part is that you'll probably be coding in a Google Doc rather than a text editor. It can be a bit disorienting.
I've also interviewed at Airbnb, where I was asked to code in Codepen for UI and in node for algorithms. I felt more comfortable in a more realistic coding environment, but one of their computers crashed mid-interview and the other's network access was broken. Coding in a doc and hand-waving when necessary is better than working in a more realistic environment if the hardware isn't reliable. (Realistic doesn't nec. mean unstable, but if you're expecting candidates to write working code in a fixed period of time, you need to make sure your communal interview machines are well-maintained.)
Do you (and the company) try to find new ways to interviews such that e.g. mid-career candidates don't need to practice in advance?
The current interview process at Google and probably at other companies as well seems to be frozen in time - one needs to be a fresh grad or prepare weeks/months in advance or be "into" competitive/sports programming, which in most cases has nothing to do with the daily job.
So no plans to have a fresh look on this?
Or maybe you keep these practices (and other companies follow) so that it is harder for engineers to change jobs easily?
I believe it is inappropriate to ask engineer to prepare in advance for the interviews.
Last time I got contacted by their recruiter and sent links to coding websites - I replied “Great for someone just out of college”.
Google, you are boring company with insane interview process. When I worked there 8 years ago I met many people, who thought passing the interview made them better than other. I regret I didn’t tell them that they should check their heads.
I got interviewed by Google twice, started by direct invitation from their HR team as I never applied to Google, naturally I bombed both times as I am not the PhD kind of developer they are after.
In every single time their recruiters were telling me our wonderful my CV was and they wanted definitely to have me there, naturally with a selection role totally unrelated for the kind of positions that I was applying for.
The third time I got a direct invitation from their HR team, I made it clear I wasn't interested if it was going to be again the same old way. Never got contacted again.
Recruiter's job is to get you there at any costs. I've being told before that cool team A,B and C wants to talk to me just to find that some boring team D is interviewing me.
This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
This is only true if the interviewer is uninterested in what happens after the hiring process. If they want to make sure they're winning a reputation doing great interviews for more good hires than bad hires then there's an incentive to be cautious, and that caution could well manifest as trying to catch out anyone who might be 'gaming' the interview process. Those false positives reflect badly on the interviewer; the false negatives don't because they might have been real negatives.
Such a feedback loop -- of identifying which interviewers give the "most accurate" scores -- doesn't exist. Nor is it clear how you would build such a system (how do you quantify a "bad hire" or "good hire" in such a way that isn't lost in the noise?). Interviewers are trusted to do the best job they can.
Remember, interviewing is volunteer work, not something that will advance your career. The results of the interviews and committee deliberation are confidential, so there's no way to gain a reputation for being a "great interviewer".
Ah, but you are woefully naive if you think some interviewers don't slip in who enjoy having people struggle with problems so they can stroke their own ego. There are also the ones that have seen the quality of engineers significantly decline over the last 6 years of massive expansion and just want to gatekeep.
One of the major flaws in Google's process is assuming that the engineers are incentivized to find good hires.
Yes and No. You want to build your reputation as a good interviewer, but that doesn't only mean you are tough and let only amazing candidates pass.
That also means that you are usually aligned with the interview committee, and if you constantly are a NO when 90% of the committee is a YES and the candidate ends up being hired, then you'll end up building this reputation of being too tough or just not getting the right signals.
I've done 300+ interviews at Uber where the process is somewhat similar to Google, and OP's points are true. As an interviewer all you really want is get good signals either good or bad. And yes, an interview is much nicer when the candidate is doing great.
It doesn't work that way. At Google, the only people who can see your ratings are the people directly involved in that candidate's hiring process. As a hiring manager, you do learn which of your reports/fellow interviewers take a tough line when scoring, but that doesn't make them great interviewers and doesn't factor at all at performance review time.
Source: I work & hire at Google. Opinions are my own.
I don't think that interviews really generate reputation in a large company... First, multiple people interview each candidate, so credit/blame is always distributed. Second, and more important, ain't nobody got time for that.
I agree that everyone has good intentions, but at the end of the day these interviews can be gamed really easily.
Before interviewing at Google I spent ~3 weeks doing leetcode style problems on a whiteboard I bought just for this purpose. Did not make me any better as a SWE, but definitely helped me clear my interviews. Without the practice I would have failed my interviews.
Having said that, I don't think I have any better alternatives; any interview process is ultimately going to be game-able in some manner.
I was confused about interviews in big companies before. Especially sometimes you have interviewers from not the hiring team. I was also confused about how leetcode questions are used, and sometimes feel that justification on hiring or not hiring are not based on evidence. Then one day I changed my view. I am seeing interviews a way to evaluate candidates' wanting to a job, and his effort of trying to achieve something. If he can invest in time in leetcode, he definitely can learn and do well in any tasks. We are humans, and we can improve. So the interview does its job. Nothing is perfect of course.
The issue with Leetcode and HackerRank as I see it, is that you're reproving to various companies each time and each interview that you know how to code. However, the only alternative to this seems be an SAT for programmers, which isn't better.
To be honest, coding is not difficult. Also many jobs do not require 'that' much knowledge of low-level informations anyway. Especially nowadays, for most positions, you don't need to know re-ordering lines of code can affect the cache, you use hash whenever it is possible and do not need to implement your own data structure. If you do need something in your work and you currently don't know, google and reading will definitely teach you. Programming is not a special power only few people can have. Actually, if you are consistently learning, you will probably do well in any tasks. If people are not willing to put some time into getting the job they want, maybe they don't want the job enough.
The engineers doing the interviews certainly have no financial incentives either way... Recruiters make contact and did a preliminary "do you have a pulse" conversation, and then shepherd the process, but don't have input into the decisions along the way. Their incentive is thus to find great candidates who they think will make it through the process.
I think that depends if you're talking about internal or external. At least everywhere I've worked our in house recruiters don't get paid a bonus when they hire someone, it just their job. If you're working with a recruiter that doesn't work for the company hiring you that person may have a more direct financial stake in your employment.
- A Google interviewer's (and I would assume any interviewer's) primary goal is to come out of the interview with enough confidence to give a positive or negative score. If they sit down to write feedback and have to give a neutral score, the interview wasn't productive. This means that the interviewer is just as eager to find evidence for a positive score as a negative one -- there isn't an incentive to "getcha" with cheap or tricky questions.
- Doing interviews at Google is volunteer work. You are not interacting with a professional interviewer, you're interacting with someone whose day job is being an engineer. They don't have an evil agenda; they are doing this because they want to help Google hire the best candidates, and by inference make sure their future coworkers are good people to work with.
- Interviewers overwhelmingly _want_ their candidates to succeed. It's a true joy when I have a candidate who glides through a question (or finds a solution that was even better than mine). When candidates struggle, it's not a pleasant experience for the interviewer either.
- In the end, the point of technical interviews is to avoid the terrible experience that is working with an incompetent or uncooperative teammate. Interviewers are trying to find people that (a) can work well with others and (b) can get the work done.
- The system is _highly_ prejudiced towards suppressing false positives. This is the right decision, but it comes at the cost of a high rate of false negatives. Were myself or any of my colleagues to re-interview for our jobs, I would expect about a 60% hire rate. This is not even taking into account the constant ebb and flow of hiring demand. Sometimes there just isn't any headcount. And sometimes you just happen to get questions that you don't click with. This is also the reason that recruiters are so eager to bring you back to interview 6 months later.
- Recruiters and interviewers have very different incentives. Recruiters want to maximize the number of people they get hired; interviewers want to hire people they want to work with. This can lead to behavior that seems schizophrenic from the outside: the recruitment side of the pipeline constantly pestering people to interview, but once the candidate enters the interviewing pipeline the process is slow, deliberate, and careful.