[...] while there is no correlation between the scores that any individual interviewer gives candidates and the job performance post-hire, there is a strong correlation between the mean scores given by the four to five interviewers who interview a candidate and post-hire performance.
So, the performance does not correlate with the individual scores but it correlates with their mean ? How does this even work?!
It's just the Central Limit Theorem at work. You have four interviewers. Think of each as a function that take a candidate and outputs a score which is perturbed from the "true" score by an error function. Each error function is different, and has a different distribution. But the Central Limit Theorem tells us that given a sufficiently large number of interviewers, the distribution of scores will converge on a normal distribution, regardless of the error distributions. The mean of this normal distribution will even converge (in this case) on the true score.
In practice it's not this neat and tidy, and four is far from enough to make the aggregate function converge, but it turns out that it does a good enough job of approximating the true score, even though the individual interviewers don't.
Are you sure that he was really asking you to display your *knowledge* of command piping?
No, he did not want go test if I knew how to pipe data from the 'ls' command to the 'grep' command using the | character. He wanted me to explain exactly how it is implemented on a system level as in: How is it coded? I have studies many aspects of the *nix operating systems but the nitty gritty of how piping is implemented in code is something I have never felt the need to explore.
Ah, okay. That's an excellent question, but only if you don't know the details of how it's implemented. If you do know, and tell the interviewer what you know, then all he's learned is that you spent some time looking at obscure code. If you don't know, then you have to think, you have to dig into what the issues might be, what options are available, and figure out how you would build such a thing.
Watching how you go about working your way through something like that is exactly what the interviewer wants. He really wasn't asking to see what you knew, he was asking to see what you would build.
And the couple of technical questions I didn't know I just described how I would find out the info or approach the problem
As an interviewer: That's absolutely the right approach. In fact, it's what interviewers really want... to give you something you don't know how to deal with, then watch you find your way through and around it. The candidates who flounder helplessly are not who we want to hire. People who dig in, use what they do know and start looking to figure out what they don't know... those are the people who will do well on the job. Real problems never come neatly packaged with all of the information and knowledge required.
Sounds good, but, WHO IS WATCHING THE WATCHERS?
Frankly, i have no problem with "smart" interviews, but tell me, what about the other side of the equation, the INTERVIEWER. Who is evaluating him?
Frankly, the bar for the interviewer is low, that it would result in many good candidates to just leave the interview process in the first minute and never ever come back....But, again, not my problem.
The hiring committees evaluate the interviewers. In some cases they actually send feedback to the interviewer. I suppose there may be rare cases in which they send feedback to the recruiters who schedule the interviewers, suggesting that one particular interviewer not be scheduled any more, though I've never heard of that happening.
What basis do the committees use for evaluating the interviewers? Obviously they can glean some information from the writeup the interviewer did. What's actually more informative is the interviewer's history. The system provides the committee with a histogram of past interview scores, with the bars colored to indicate what percentage of candidates the interviewer scored in each bucket were rejected or received an offer. An interviewer is considered "calibrated" after they've done 25 interviews, which is enough that the histogram provides useful information about how that interviewer rates people.
HR does some additional statistical analysis to correlate interview scores with post-hire performance, but what that has found is that while some really good interviewers' scores are strongly correlated with offers (perhaps because committees trust them? There are some potentially destructive feedback loops here), there don't seem to be any interviewers whose scores are strongly correlated with post-hire job performance.
However, the aggregate interview scores for a candidate do turn out to be quite a good predictor of post-hire performance. This seems like a good indicator that the system works well. It seems that while individual interviewers may get a bad read due to, for example, personality conflicts, the averaging of four interviewers washes out some of those sources of error.
Frankly, the bar for the interviewer is low, that it would result in many good candidates to just leave the interview process in the first minute and never ever come back
If a candidate leaves without completing the interview, that definitely raises a lot of red flags, and if it happened repeatedly you can bet that action would be taken. Probably just sending the interviewer back to interview training, but if that didn't fix it then that interviewer wouldn't be interviewing any more. Similarly, recruiters poll candidates about their experience in being interviewed (before an offer/rejection is sent), and that feedback is also used to refine the process and, if necessary, correct interviewers.
I'll give you Google's answer to this question, if you like.
You missed the prior stuff like the online coding test.
I got contacted by a google recruiter once, presumably because of my reputation within the field and publication record etc. They wanted me to do an online coding exam. I think it was only a couple of hours worth plus another few hours for boning up on the sort of stuff that's going to be in it.
I think maybe you're talking about the phone screen? I've never heard of an online coding exam at Google.
I did leave out the phone screen, which is a one-hour phone interview that includes similar questions and in which coding is normally done in a Google Doc (when I did the phone screen the recruiter who set up the doc neglected to give me edit permission, so we just skipped it). The phone screen is similar in style to the face to face interview but there's only one (for full-time hires; internship candidates do multiple phone screens and no face-to-face) and the bar is much lower because the goal is just to decide whether it's worth bringing the candidate in for interviews.
tldr; I have one example that disproves the average google engineer is a start anywhere else
Counterexamples disprove theorems, but not trends. I'm sure there are plenty of counterexamples, but that doesn't mean I'm wrong about the overall situation. I should point out, though, that my comment about "anywhere else" is obviously limited to the places that I worked. Because I was a consultant for quite a while, I saw a broader selection of places than perhaps most would in a 20-year period, but it's still only a sample and perhaps not a representative one; I can't know.
What's more relevant is the statistical evidence that demonstrates that Google's interview scoring correlates with job performance, of course, but that's only relative to other Google employees, not relative to people at other shops.
> average Google engineer would be a star virtually anywhere else in the industry.
How could you possibly know that? Do you have access to parallel universes where they work for other companies? Nah. It's just while your fingers doing the typing while your pompous asshole dictates.
I'm taking a wild guess that OP is or was an average Google engineer, and therefore, gosh, a star.
Actually, I'd characterize myself as a below-average Google engineer. I mean, they're not going to be firing me or anything, but I feel like most of the people I work with are better than I am.
And, yes, at my previous employers I was a star. Further, I spent better than a decade as a consultant, so I worked in a different company every six months or so. That gave me the opportunity to meet a lot of programmers and see them doing non-trivial amounts of work in lots of different companies. So... I think I have a reasonable basis for comparison.
You might wonder why, if I was a star elsewhere and I'm below average at Google, I'd want to be at Google. The answer is that at Google I don't have to deal with idiots. It's possible my co-workers think I'm the idiot (though they hide it well, if so), but that's their problem. Also, being below average at Google pays better than being a star most other places.
However, my anecdotal experience is obviously far less compelling than Google's statistical analysis of interview performance vs job performance.
Genuine question, because I occasionally have to interview people: how do you interview people, and what sort of questions do you ask to try and work out if they are the right kind of person?
I'll give you Google's answer to this question, if you like.
Google does a series of four interviews, each with a different interviewer. All interviewers submit their responses to a hiring committee in writing. Each gives a hire/no-hire recommendation as well as scoring the candidate on a 1-4 scale (0 == if you hire this person, I'll quit; 2.5 == I have no opinion[1]; 4 == if you don't hire this person, I'll quit). Each interviewer also provides a detailed account of what they asked, how the candidate responded and what conclusions the interviewer drew. If the interview included writing code, the code is included in the feedback. The hiring committee, which includes no one who interviewed the candidate, takes the feedback from the interviewers and comes to a hire/no-hire consensus decision.
Each interview is nominally 45 minutes long, scheduled one hour apart, leaving 15 minutes between interviews for bio breaks, logistics, etc. Between the second and third interviews an additional "interviewer" takes the candidate to lunch. The "lunch interviewer" submits no feedback and answers the candidate's questions about the company, as well as giving them a break (and food).
For the actual interviews, each interviewer is instructed to focus on evaluating how smart the candidate is and how well they solve problems, not on how much they know. Basic CS knowledge is necessary because that's the language of the interview, and the candidate must know some programming language, but it doesn't matter which one.
Interviewers select their own questions to ask, but there are some criteria. First, the answers should not depend upon having some particular bit of knowledge. Other than basic CS knowledge, it's expected that the interviewer can provide the candidate with whatever information is required, though not necessarily all at once. It's good to provide partial information and see how the candidate goes about determining what else is needed, and obtaining the missing information. Similarly, answers should not depend on the candidate having some flash of insight. Such "aha!" questions say little about ability. The best questions are also progressive in nature; they start simple and build in difficulty and complexity as they're explored. This has a lot of benefits, not least that it allows weak candidates to feel like they had some success and walk away feeling like it was a good experience... even as the question showed the interviewer that the candidate isn't qualified.
Interview questions must also be calibrated. That is, the interviewer must know before going into the interview how well different kinds of candidates respond to the question, and must have a pretty deep understanding of the solution space. The calibration process begins by running peers through the question in a mock interview. That allows the interviewer to get a feel for what Google-caliber engineers do and do not see when looking at the problem and potential solutions. Different people are different, so it's recommended to have at least three or four peers help with initial calibration. Calibration is further refined by using the same question with many candidates. Google engineers have a small handful of questions they always use. They should always enter an interview armed with a well-calibrated question, plus a backup question or two in case the candidate is really outstanding and flies through the first question, or in case the first one turns out to be unsuitable in this particular case.
The interview begins with a few minutes of introductions/small talk to help the candidate relax. Most interviews consist of a single problem. The candidate is asked to devise an algorithm to solve it, describing the algorithm first verbally/pictorially, and then implementing the algorithm either on a w
The interview consisted of a teleconference where a Google employee quizzed me about various really technical issues with most of the interview revolving around the nitty gritty details of how command piping is implemented in different *nix versions. I have been asked by employers to solve all kinds of programmatic and system administration related problems in my two decades as a programmer but why on earth would I be an expert in the command/data piping mechanism in *nix type operating systems and why would I be a bad developer if I don't know that?
Are you sure that he was really asking you to display your *knowledge* of command piping? If so, that was a very bad Google interviewer, because Google interviews are supposed to test problem solving ability, not knowledge. It's assumed that smart people who are good problem solvers can learn whatever they need to learn, so testing knowledge is a waste of time.
My guess is that the interviewer was actually using the discussion of command piping to see how you thought about problems, and didn't actually expect you to know all of the details. I could be wrong, of course -- I certainly wasn't there! -- but people aren't chosen to do phone screens until they've proven themselves to be good interviewers in face to face interviews, and what you describe is an extraordinarily bad Google interviewer.
Or perhaps you'd like me to put together a web service in C/C++?... but please don't ask me to solve differential equations programmatically off the top of my head. That is not something I have ever been asked to do by an employer in 20 years of programming
Heh. As it happens solving a differential equation programmatically is something that I've done for an employer. Google, as it happens, though I could see having used a similar method elsewhere, given the right sort of problem.
Google is making sure they only have employees that think a certain way by using their hiring process. But is that the only kind of employee they need to be healthy long-term?
That's a valid question. It seems to be working reasonably well so far, but you're right: Google's process strongly favors selecting engineers who are fascinated by hard technical problems and are able to think and solve problems on their feet. There's also a strong element of luck in the process. Being capable is a requirement for being hired by Google, but it's in no way a guarantee.
I am a dev, and for a long time was a hiring manager. The idea that grilling, testing, or creating "challenging" interview questions for candidates, and thinking that it will give you ANY introspective on how they will perform on the job, is complete and total poppycock.
I'd actually really like to agree with you, because there is a huge amount of error in any hiring process that tries to evaluate engineers in anything less than a few months of focused work.
But, I don't, for the very simple reason that I have seen the outcome of Google's hiring process firsthand, after 20 years of work in the industry to provide context... and I can state with absolute certainty that the average Google engineer would be a star virtually anywhere else in the industry. So, whatever errors there are in the process it actually works, in the sense that it effectively ensures that vanishingly few candidates who aren't highly capable get hired. Even better, Google's process seems to do an excellent job of weeding out prima donnas who can't work well with others.
So, while in the abstract I agree that it's extremely difficult to figure out who's good and who's not in a 45-minute interview with a coding problem or two... Google's process actually works very well. Google HR even has empirical data to back that up: they've found that while there is no correlation between the scores that any individual interviewer gives candidates and the job performance post-hire, there is a strong correlation between the mean scores given by the four to five interviewers who interview a candidate and post-hire performance.
Of course, that evaluation can only consider the candidates who were hired, and it's widely believed at Google that therein lies the major flaw in the hiring process: It's great at excluding unqualified candidates but does so only by also excluding lots of qualified candidates. My first tech lead at Google put it this way: If you take any successful Google engineer and run them through the hiring process anonymously, they've got a roughly 50% chance of being hired. I wonder if it's even that high.
Statistically women earn 70% of what men earn, why?
Because gender discrimination is widespread. Duh. And the reason for that is quite obvious as well.
If Google ensures gender equality women's salaries will have to be equal to men's even if their performance is not.
This is a classic example of begging the question. You're assuming that women are less productive everywhere and using that to argue that they must, therefore, be less productive at Google. But your premise is flawed, and therefore your conclusion is also flawed.
As it happens, Google HR also keeps a close eye on performance metrics. There are no metrics that completely and accurately capture a software engineer's (for example) performance, but if women really did produce less, surely it would show up somewhere. It doesn't.
Actually, even if your premise were true, your conclusion still wouldn't follow logically, because to get from A to B you have include another assumption, namely that the men and women at Google represent the same portions of their respective populations. But, given that unlike most companies Google doesn't have a gender wage gap, it would be reasonable to expect that a higher percentage of really capable women would gravitate to Google over other, more discriminatory, companies.
But I see no evidence whatsoever that your premise is true.
That wasn't name-calling, it was a characterization of your decision to redefine common words.
Sorry, you lost the argument. You also lost my respect.
Okay, sure. I don't know how you define any of those words, so I don't know what that means, but I couldn't know even if you explained it. There's a disadvantage to using your own definitions.
it's worked fine for over 3 years that way. Up until version 5.1.3rc1 that is.
Anyone else concerned that general user infrastructure is getting release candidate software versions?
A release is (or should be) identical to the last release candidate. You cut a release candidate and start testing. If you find bugs, you fix them and generate a new RC. When the RC passes your tests, you deploy it. It's common to change the name on the final RC but it's not really necessary, and if you don't then all released versions will have an "rc" suffix.
Ah, you should have mentioned that your name is Humpty Dumpty.
When you resort to name calling, it means you lost the argument.
Do you not get the reference? That wasn't name-calling, it was a characterization of your decision to redefine common words. Here's the reference, if you need it: http://www.goodreads.com/quote...
I asked you about the relevance. Instead you simply restated your original erroneous claim.
No, you made an erroneous — and quite narrow presumption — of what I meant by management.
Ah, you should have mentioned that your name is Humpty Dumpty.
It can be problematic when a company is structured between regular employees (1%) and contractors (99%).
Are you claiming that ratio for Google? I'd guess it's more like 60/40, not 1/99.
Whenever discussion of Google's compensation comes up, I love to point out that not everyone at Google is so richly compensated. Some people find that relevant, others do not.
Okay... but the discussion was about the disclosure of compensation information (whatever it may be), not about level or type of compensation.
Regular employees are managers and engineers. Everyone else are contractors. It's a distinction that most people overlook when talking about compensation at Google.
I asked you about the relevance. Instead you simply restated your original erroneous claim.
Let me put that to bed. Yes, there are lots of contractors at Google. The people running the cafes, the buildings, the buses, security, many of the recruiters, many of the people in data centers, etc. are all contractors. But there are also a *lot* more regular employees than just managers and engineers. Sales, finance, business operations, partner and customer account managers, HR, tech writers project managers and legal are just some of the categories of non-managerial, non-engineering regular employees that I've worked with.
Google has around 60,000 full-time, regular employees (that's per Wikipedia; I'm not looking up actual numbers because I'm not sure if they're confidential). In general, about half of Google's full-time employees are in engineering -- note that that includes all of the engineering management. So that means there are some 30,000 employees who are not engineers and not managers of engineers.
But I'm still wondering how this relevant to the question of whether it's problematic or beneficial to know one another's compensation.
Keep in mind that employees who earn "total compensation" are either managers or engineers. Everyone else works for contractor agencies that provides a paycheck and a standard benefits package. If someone is fretting about the current stock price, they're not a contractor.
True, except for the part about only managers and engineers being regular employees. Relevance?
... BlackBerry devices that are being marketed as having "military-grade security."
To be fair, Blackberry / RIM never said whose military.
Any time you encounter a product which claims "military grade" security, encryption, etc., run away. "Military grade" is a meaningless appellation, and the best case scenario is that the vendor has good security people who are frustrated by their inability to get product marketing to understand that. But that scenario is pretty unlikely. What's far more likely is that they're clueless and the product sucks.
Some employees chatting about salary openness decided to take it upon themselves to do it. Someone created a Google Form and shared it on a very widely-used internal mailing list (~40K subscribers). People could choose to provide their username or not; many did. About 3000 employees added their data in 2014, which included career ladder, level, location, gender and base pay rate. For 2015 the form was revised to add "total compensation", because a significant part of Google employee compensation is in the form of stock grants and bonuses. Analysis of the numbers shows that compensation is pretty fair. There's no gender gap (not surprising because Google HR watches those stats closely). There are some significant differences between people at different locations, but those correlate pretty well with cost of living differences.
No, to stop someone like Snowden you don't need an absolute dictatorship. You need to restrict access to systems so that employees only have access to the things they need.
That won't work if you're doing things that are morally outrageous, because employees that need access do need access, and if one of them develops a conscience there's no way you can stop them from sharing the information. With draconian measures you can make it hard for them to extract solid proof, but that's all you can do, and that's very hard.
You know, the things that competent corporate IT usually does already.
LOL. In 20 years in the business, what I've seen is that almost no corporate IT departments are competent to secure their own data.
"Also if you are to point blame you need to be professional about it, and make sure it isn't too sharp of a point."
Nope, I'm old enough to stop caring about this, if a manager fucked things up so that a project failed, I will not only call him out but also throw him under the bus and sick the dogs on his body.
The GP was talking about situations where you are at fault, not someone else. Is immediately deflecting blame to your manager your strategy for avoiding blame for your own mistakes?
Personally, I've always found that when I screw up the best thing I can do is to say so and then work to fix it. Worst case is that the company culture is one that latches onto any scapegoat and I get fired... but in the long term that's a place I'm better off not being anyway.
Slashdot Mirror
[...] while there is no correlation between the scores that any individual interviewer gives candidates and the job performance post-hire, there is a strong correlation between the mean scores given by the four to five interviewers who interview a candidate and post-hire performance.
So, the performance does not correlate with the individual scores but it correlates with their mean ? How does this even work?!
It's just the Central Limit Theorem at work. You have four interviewers. Think of each as a function that take a candidate and outputs a score which is perturbed from the "true" score by an error function. Each error function is different, and has a different distribution. But the Central Limit Theorem tells us that given a sufficiently large number of interviewers, the distribution of scores will converge on a normal distribution, regardless of the error distributions. The mean of this normal distribution will even converge (in this case) on the true score.
In practice it's not this neat and tidy, and four is far from enough to make the aggregate function converge, but it turns out that it does a good enough job of approximating the true score, even though the individual interviewers don't.
Are you sure that he was really asking you to display your *knowledge* of command piping?
No, he did not want go test if I knew how to pipe data from the 'ls' command to the 'grep' command using the | character. He wanted me to explain exactly how it is implemented on a system level as in: How is it coded? I have studies many aspects of the *nix operating systems but the nitty gritty of how piping is implemented in code is something I have never felt the need to explore.
Ah, okay. That's an excellent question, but only if you don't know the details of how it's implemented. If you do know, and tell the interviewer what you know, then all he's learned is that you spent some time looking at obscure code. If you don't know, then you have to think, you have to dig into what the issues might be, what options are available, and figure out how you would build such a thing.
Watching how you go about working your way through something like that is exactly what the interviewer wants. He really wasn't asking to see what you knew, he was asking to see what you would build.
And the couple of technical questions I didn't know I just described how I would find out the info or approach the problem
As an interviewer: That's absolutely the right approach. In fact, it's what interviewers really want... to give you something you don't know how to deal with, then watch you find your way through and around it. The candidates who flounder helplessly are not who we want to hire. People who dig in, use what they do know and start looking to figure out what they don't know... those are the people who will do well on the job. Real problems never come neatly packaged with all of the information and knowledge required.
Sounds good, but, WHO IS WATCHING THE WATCHERS? Frankly, i have no problem with "smart" interviews, but tell me, what about the other side of the equation, the INTERVIEWER. Who is evaluating him? Frankly, the bar for the interviewer is low, that it would result in many good candidates to just leave the interview process in the first minute and never ever come back....But, again, not my problem.
The hiring committees evaluate the interviewers. In some cases they actually send feedback to the interviewer. I suppose there may be rare cases in which they send feedback to the recruiters who schedule the interviewers, suggesting that one particular interviewer not be scheduled any more, though I've never heard of that happening.
What basis do the committees use for evaluating the interviewers? Obviously they can glean some information from the writeup the interviewer did. What's actually more informative is the interviewer's history. The system provides the committee with a histogram of past interview scores, with the bars colored to indicate what percentage of candidates the interviewer scored in each bucket were rejected or received an offer. An interviewer is considered "calibrated" after they've done 25 interviews, which is enough that the histogram provides useful information about how that interviewer rates people.
HR does some additional statistical analysis to correlate interview scores with post-hire performance, but what that has found is that while some really good interviewers' scores are strongly correlated with offers (perhaps because committees trust them? There are some potentially destructive feedback loops here), there don't seem to be any interviewers whose scores are strongly correlated with post-hire job performance.
However, the aggregate interview scores for a candidate do turn out to be quite a good predictor of post-hire performance. This seems like a good indicator that the system works well. It seems that while individual interviewers may get a bad read due to, for example, personality conflicts, the averaging of four interviewers washes out some of those sources of error.
Frankly, the bar for the interviewer is low, that it would result in many good candidates to just leave the interview process in the first minute and never ever come back
If a candidate leaves without completing the interview, that definitely raises a lot of red flags, and if it happened repeatedly you can bet that action would be taken. Probably just sending the interviewer back to interview training, but if that didn't fix it then that interviewer wouldn't be interviewing any more. Similarly, recruiters poll candidates about their experience in being interviewed (before an offer/rejection is sent), and that feedback is also used to refine the process and, if necessary, correct interviewers.
I'll give you Google's answer to this question, if you like.
You missed the prior stuff like the online coding test.
I got contacted by a google recruiter once, presumably because of my reputation within the field and publication record etc. They wanted me to do an online coding exam. I think it was only a couple of hours worth plus another few hours for boning up on the sort of stuff that's going to be in it.
I think maybe you're talking about the phone screen? I've never heard of an online coding exam at Google.
I did leave out the phone screen, which is a one-hour phone interview that includes similar questions and in which coding is normally done in a Google Doc (when I did the phone screen the recruiter who set up the doc neglected to give me edit permission, so we just skipped it). The phone screen is similar in style to the face to face interview but there's only one (for full-time hires; internship candidates do multiple phone screens and no face-to-face) and the bar is much lower because the goal is just to decide whether it's worth bringing the candidate in for interviews.
tldr; I have one example that disproves the average google engineer is a start anywhere else
Counterexamples disprove theorems, but not trends. I'm sure there are plenty of counterexamples, but that doesn't mean I'm wrong about the overall situation. I should point out, though, that my comment about "anywhere else" is obviously limited to the places that I worked. Because I was a consultant for quite a while, I saw a broader selection of places than perhaps most would in a 20-year period, but it's still only a sample and perhaps not a representative one; I can't know.
What's more relevant is the statistical evidence that demonstrates that Google's interview scoring correlates with job performance, of course, but that's only relative to other Google employees, not relative to people at other shops.
> average Google engineer would be a star virtually anywhere else in the industry. How could you possibly know that? Do you have access to parallel universes where they work for other companies? Nah. It's just while your fingers doing the typing while your pompous asshole dictates.
I'm taking a wild guess that OP is or was an average Google engineer, and therefore, gosh, a star.
Actually, I'd characterize myself as a below-average Google engineer. I mean, they're not going to be firing me or anything, but I feel like most of the people I work with are better than I am.
And, yes, at my previous employers I was a star. Further, I spent better than a decade as a consultant, so I worked in a different company every six months or so. That gave me the opportunity to meet a lot of programmers and see them doing non-trivial amounts of work in lots of different companies. So... I think I have a reasonable basis for comparison.
You might wonder why, if I was a star elsewhere and I'm below average at Google, I'd want to be at Google. The answer is that at Google I don't have to deal with idiots. It's possible my co-workers think I'm the idiot (though they hide it well, if so), but that's their problem. Also, being below average at Google pays better than being a star most other places.
However, my anecdotal experience is obviously far less compelling than Google's statistical analysis of interview performance vs job performance.
Genuine question, because I occasionally have to interview people: how do you interview people, and what sort of questions do you ask to try and work out if they are the right kind of person?
I'll give you Google's answer to this question, if you like.
Google does a series of four interviews, each with a different interviewer. All interviewers submit their responses to a hiring committee in writing. Each gives a hire/no-hire recommendation as well as scoring the candidate on a 1-4 scale (0 == if you hire this person, I'll quit; 2.5 == I have no opinion[1]; 4 == if you don't hire this person, I'll quit). Each interviewer also provides a detailed account of what they asked, how the candidate responded and what conclusions the interviewer drew. If the interview included writing code, the code is included in the feedback. The hiring committee, which includes no one who interviewed the candidate, takes the feedback from the interviewers and comes to a hire/no-hire consensus decision.
Each interview is nominally 45 minutes long, scheduled one hour apart, leaving 15 minutes between interviews for bio breaks, logistics, etc. Between the second and third interviews an additional "interviewer" takes the candidate to lunch. The "lunch interviewer" submits no feedback and answers the candidate's questions about the company, as well as giving them a break (and food).
For the actual interviews, each interviewer is instructed to focus on evaluating how smart the candidate is and how well they solve problems, not on how much they know. Basic CS knowledge is necessary because that's the language of the interview, and the candidate must know some programming language, but it doesn't matter which one.
Interviewers select their own questions to ask, but there are some criteria. First, the answers should not depend upon having some particular bit of knowledge. Other than basic CS knowledge, it's expected that the interviewer can provide the candidate with whatever information is required, though not necessarily all at once. It's good to provide partial information and see how the candidate goes about determining what else is needed, and obtaining the missing information. Similarly, answers should not depend on the candidate having some flash of insight. Such "aha!" questions say little about ability. The best questions are also progressive in nature; they start simple and build in difficulty and complexity as they're explored. This has a lot of benefits, not least that it allows weak candidates to feel like they had some success and walk away feeling like it was a good experience... even as the question showed the interviewer that the candidate isn't qualified.
Interview questions must also be calibrated. That is, the interviewer must know before going into the interview how well different kinds of candidates respond to the question, and must have a pretty deep understanding of the solution space. The calibration process begins by running peers through the question in a mock interview. That allows the interviewer to get a feel for what Google-caliber engineers do and do not see when looking at the problem and potential solutions. Different people are different, so it's recommended to have at least three or four peers help with initial calibration. Calibration is further refined by using the same question with many candidates. Google engineers have a small handful of questions they always use. They should always enter an interview armed with a well-calibrated question, plus a backup question or two in case the candidate is really outstanding and flies through the first question, or in case the first one turns out to be unsuitable in this particular case.
The interview begins with a few minutes of introductions/small talk to help the candidate relax. Most interviews consist of a single problem. The candidate is asked to devise an algorithm to solve it, describing the algorithm first verbally/pictorially, and then implementing the algorithm either on a w
The interview consisted of a teleconference where a Google employee quizzed me about various really technical issues with most of the interview revolving around the nitty gritty details of how command piping is implemented in different *nix versions. I have been asked by employers to solve all kinds of programmatic and system administration related problems in my two decades as a programmer but why on earth would I be an expert in the command/data piping mechanism in *nix type operating systems and why would I be a bad developer if I don't know that?
Are you sure that he was really asking you to display your *knowledge* of command piping? If so, that was a very bad Google interviewer, because Google interviews are supposed to test problem solving ability, not knowledge. It's assumed that smart people who are good problem solvers can learn whatever they need to learn, so testing knowledge is a waste of time.
My guess is that the interviewer was actually using the discussion of command piping to see how you thought about problems, and didn't actually expect you to know all of the details. I could be wrong, of course -- I certainly wasn't there! -- but people aren't chosen to do phone screens until they've proven themselves to be good interviewers in face to face interviews, and what you describe is an extraordinarily bad Google interviewer.
Or perhaps you'd like me to put together a web service in C/C++? ... but please don't ask me to solve differential equations programmatically off the top of my head. That is not something I have ever been asked to do by an employer in 20 years of programming
Heh. As it happens solving a differential equation programmatically is something that I've done for an employer. Google, as it happens, though I could see having used a similar method elsewhere, given the right sort of problem.
Google is making sure they only have employees that think a certain way by using their hiring process. But is that the only kind of employee they need to be healthy long-term?
That's a valid question. It seems to be working reasonably well so far, but you're right: Google's process strongly favors selecting engineers who are fascinated by hard technical problems and are able to think and solve problems on their feet. There's also a strong element of luck in the process. Being capable is a requirement for being hired by Google, but it's in no way a guarantee.
I am a dev, and for a long time was a hiring manager. The idea that grilling, testing, or creating "challenging" interview questions for candidates, and thinking that it will give you ANY introspective on how they will perform on the job, is complete and total poppycock.
I'd actually really like to agree with you, because there is a huge amount of error in any hiring process that tries to evaluate engineers in anything less than a few months of focused work.
But, I don't, for the very simple reason that I have seen the outcome of Google's hiring process firsthand, after 20 years of work in the industry to provide context... and I can state with absolute certainty that the average Google engineer would be a star virtually anywhere else in the industry. So, whatever errors there are in the process it actually works, in the sense that it effectively ensures that vanishingly few candidates who aren't highly capable get hired. Even better, Google's process seems to do an excellent job of weeding out prima donnas who can't work well with others.
So, while in the abstract I agree that it's extremely difficult to figure out who's good and who's not in a 45-minute interview with a coding problem or two... Google's process actually works very well. Google HR even has empirical data to back that up: they've found that while there is no correlation between the scores that any individual interviewer gives candidates and the job performance post-hire, there is a strong correlation between the mean scores given by the four to five interviewers who interview a candidate and post-hire performance.
Of course, that evaluation can only consider the candidates who were hired, and it's widely believed at Google that therein lies the major flaw in the hiring process: It's great at excluding unqualified candidates but does so only by also excluding lots of qualified candidates. My first tech lead at Google put it this way: If you take any successful Google engineer and run them through the hiring process anonymously, they've got a roughly 50% chance of being hired. I wonder if it's even that high.
LOL. This leaves me wondering if you actually expect anyone to believe your outrage is justifiable.
Anyway, this has been entertaining but it's gotten old, so I'll let you have the last word.
Statistically women earn 70% of what men earn, why?
Because gender discrimination is widespread. Duh. And the reason for that is quite obvious as well.
If Google ensures gender equality women's salaries will have to be equal to men's even if their performance is not.
This is a classic example of begging the question. You're assuming that women are less productive everywhere and using that to argue that they must, therefore, be less productive at Google. But your premise is flawed, and therefore your conclusion is also flawed.
As it happens, Google HR also keeps a close eye on performance metrics. There are no metrics that completely and accurately capture a software engineer's (for example) performance, but if women really did produce less, surely it would show up somewhere. It doesn't.
Actually, even if your premise were true, your conclusion still wouldn't follow logically, because to get from A to B you have include another assumption, namely that the men and women at Google represent the same portions of their respective populations. But, given that unlike most companies Google doesn't have a gender wage gap, it would be reasonable to expect that a higher percentage of really capable women would gravitate to Google over other, more discriminatory, companies.
But I see no evidence whatsoever that your premise is true.
That wasn't name-calling, it was a characterization of your decision to redefine common words.
Sorry, you lost the argument. You also lost my respect.
Okay, sure. I don't know how you define any of those words, so I don't know what that means, but I couldn't know even if you explained it. There's a disadvantage to using your own definitions.
it's worked fine for over 3 years that way. Up until version 5.1.3rc1 that is.
Anyone else concerned that general user infrastructure is getting release candidate software versions?
A release is (or should be) identical to the last release candidate. You cut a release candidate and start testing. If you find bugs, you fix them and generate a new RC. When the RC passes your tests, you deploy it. It's common to change the name on the final RC but it's not really necessary, and if you don't then all released versions will have an "rc" suffix.
Ah, you should have mentioned that your name is Humpty Dumpty.
When you resort to name calling, it means you lost the argument.
Do you not get the reference? That wasn't name-calling, it was a characterization of your decision to redefine common words. Here's the reference, if you need it: http://www.goodreads.com/quote...
Why would you assume that women are not as productive?
I asked you about the relevance. Instead you simply restated your original erroneous claim.
No, you made an erroneous — and quite narrow presumption — of what I meant by management.
Ah, you should have mentioned that your name is Humpty Dumpty.
It can be problematic when a company is structured between regular employees (1%) and contractors (99%).
Are you claiming that ratio for Google? I'd guess it's more like 60/40, not 1/99.
Whenever discussion of Google's compensation comes up, I love to point out that not everyone at Google is so richly compensated. Some people find that relevant, others do not.
Okay... but the discussion was about the disclosure of compensation information (whatever it may be), not about level or type of compensation.
Regular employees are managers and engineers. Everyone else are contractors. It's a distinction that most people overlook when talking about compensation at Google.
I asked you about the relevance. Instead you simply restated your original erroneous claim.
Let me put that to bed. Yes, there are lots of contractors at Google. The people running the cafes, the buildings, the buses, security, many of the recruiters, many of the people in data centers, etc. are all contractors. But there are also a *lot* more regular employees than just managers and engineers. Sales, finance, business operations, partner and customer account managers, HR, tech writers project managers and legal are just some of the categories of non-managerial, non-engineering regular employees that I've worked with.
Google has around 60,000 full-time, regular employees (that's per Wikipedia; I'm not looking up actual numbers because I'm not sure if they're confidential). In general, about half of Google's full-time employees are in engineering -- note that that includes all of the engineering management. So that means there are some 30,000 employees who are not engineers and not managers of engineers.
But I'm still wondering how this relevant to the question of whether it's problematic or beneficial to know one another's compensation.
Keep in mind that employees who earn "total compensation" are either managers or engineers. Everyone else works for contractor agencies that provides a paycheck and a standard benefits package. If someone is fretting about the current stock price, they're not a contractor.
True, except for the part about only managers and engineers being regular employees. Relevance?
... BlackBerry devices that are being marketed as having "military-grade security."
To be fair, Blackberry / RIM never said whose military.
Any time you encounter a product which claims "military grade" security, encryption, etc., run away. "Military grade" is a meaningless appellation, and the best case scenario is that the vendor has good security people who are frustrated by their inability to get product marketing to understand that. But that scenario is pretty unlikely. What's far more likely is that they're clueless and the product sucks.
Some employees chatting about salary openness decided to take it upon themselves to do it. Someone created a Google Form and shared it on a very widely-used internal mailing list (~40K subscribers). People could choose to provide their username or not; many did. About 3000 employees added their data in 2014, which included career ladder, level, location, gender and base pay rate. For 2015 the form was revised to add "total compensation", because a significant part of Google employee compensation is in the form of stock grants and bonuses. Analysis of the numbers shows that compensation is pretty fair. There's no gender gap (not surprising because Google HR watches those stats closely). There are some significant differences between people at different locations, but those correlate pretty well with cost of living differences.
No, to stop someone like Snowden you don't need an absolute dictatorship. You need to restrict access to systems so that employees only have access to the things they need.
That won't work if you're doing things that are morally outrageous, because employees that need access do need access, and if one of them develops a conscience there's no way you can stop them from sharing the information. With draconian measures you can make it hard for them to extract solid proof, but that's all you can do, and that's very hard.
You know, the things that competent corporate IT usually does already.
LOL. In 20 years in the business, what I've seen is that almost no corporate IT departments are competent to secure their own data.
as a girl she really needs to walk with a buddy
Why?
"Also if you are to point blame you need to be professional about it, and make sure it isn't too sharp of a point."
Nope, I'm old enough to stop caring about this, if a manager fucked things up so that a project failed, I will not only call him out but also throw him under the bus and sick the dogs on his body.
The GP was talking about situations where you are at fault, not someone else. Is immediately deflecting blame to your manager your strategy for avoiding blame for your own mistakes?
Personally, I've always found that when I screw up the best thing I can do is to say so and then work to fix it. Worst case is that the company culture is one that latches onto any scapegoat and I get fired... but in the long term that's a place I'm better off not being anyway.