I had an interview for a systems administrative position way back when that was my primary gig, admittedly this was in the twilight after ten years of experience and I had already mostly gotten sick of systems administration and was deeply into coding so maybe I was just too jaded, but the single question I recall that they asked me I actually found so stupid it was insulting;
What's the default bytes per block in random linux distribution x version y when using filesystem z?
My response;
I'd google it.
Perhaps this is unique to the Australian branch of Google or something but I get the impression that they're much more into the whole meaningless rote memorisation of facts than is often let on.
I had a contact from another Google HR person a couple months back in Estonia, this time for a development position. I can't say I wasn't tempted but this time I turned them down flat.
Perhaps the point was not merely regurgitation of facts but an analysis of your thought-process. It is almost impossible to have such an esoteric bit of trivia but you could have at least given them something:
"...Well I dunno but let's see...Filesystem Z(let's say reiserfs)...so this one's pretty good with really large files...its preferred to other ones(say ext2) for both support of larger files and better disk checking...at the time of distro x, version y, filesystem D(that you may be familiar with) hadn't even come out and was probably an improvement over Z, so I'd wager less bytes per block than filesytem D but more than...."
...or so could be a possible response...I hope I am getting my point through, though of course you're the one to have lived through the day and not me and I'm sure your reply was what you felt best, at the time.
That does seem like a strange question but then again I'm not a sysadmin so I really don't know what's reasonable.
I'll frame this in what I know, which is programming. I think it's entirely reasonable to ask someone how a hashtable or even a quick sort (or some other O(n log n) sort) works because programmers should be familiar with that even if 99.9% of the time (if not 100% of the time) you're using a HashMap or std::map or dict or whatever.
The lack of feedback is crippling. I interviewed at a similar company and I thought the interview went GREAT. I'm usually a great judge of whether or not someone likes me, I pay attention that kind of thing, I got all the answers to their satisfaction while explaining, in detail and concisely, my thought process.
Didn't get the job. I didn't make one mistake and I thought they liked me. I have zero clues as to why. I'm not really upset about it, it was just a very frustrating experience.
I actually came out of my Google interview thinking I'd blown it. I was making contingency plans in my head on the plane ride back, of what business I'd start next, since I apparently wouldn't get the job. Then the recruiter woke me up the next morning (I had a red-eye back) and told me the interview feedback looked great and they were fast-tracking me through the hiring committee.
The lack of feedback does suck, but I wonder if it says more about our own ability to judge our competence than about the interview process itself. As btilly points out, companies in the U.S. are almost required to not say what you did wrong, for fear of lawsuits. Plus, the hire/no-hire decision usually comes down to a visceral reaction, so the decision-makers may not even know why they decided one way or another.
Also - if you think the lack of feedback for interviews sucks, it's ten times worse when you're doing your own thing. I was an entrepreneur before Google, and we launched like 4 websites before I threw in the towel and got a job. Each one of them was met with a resounding...silence. Nobody saying we were bad, but nobody saying we were good either. We were just irrelevant. That's the way most startups go: if you're successful people will just quietly use your product and never acknowledge you, and if you're unsuccessful, people will just quietly not use your product and never acknowledge you. The only startups that get masses of haters are the ones where the founders were previously famous but royally fucked up (eg. Cuil), and the only ones that get massive acclaim are the ones that solve a hair-on-fire problem in a particularly spectacular way (eg. Google).
Google started in the USA. In the USA if you give feedback, no matter how well-intentioned or apparently harmless it may be, that can be used to sue you. Even if those lawsuits are unlikely to go anywhere, they are a distraction. So no US company will give you feedback.
And that's become standardized in Google's procedures.
I was contacted by Google Pittsburgh about 4 years ago. So I went through their phone interview process. I got through 3 interviews and really thought I did pretty well. All three interviews were entirely about solving problems that are heavily algorithm based. After interview three, bam!, they said they didn't want me. I looked over my notes and thoroughly researched the algorithms in question, I had come up with rather optimal solutions. I honestly have no idea what went wrong. But then maybe that just means I'm not smart enough to work at Google. Entirely possible.
This experience bugged me for a while. Man what I would have given to see that guy's notes about me :)
This is pretty much why I hate the idea of applying for a job. Supposing I get the interview, based on my past experience there's at least a 80% chance I won't get the job. I never got feedback for any of my "no hires" so I just have to assume they will all turn out that way.
The lack of feedback makes me just assume every interview is a crapshoot and there's nothing I can do to try and improve.
A good time to elicit feedback is right at the end of the interview, in a casual manner along the lines of "well, so how do you think I did?". You don't want to push it if they try to avoid the issue, but I find I generally get better feedback than when trying to get it after a rejection.
TL; DR: Google's recruitment process is opaque and arguably leads to many false negatives. True 3 years ago and apparently still true.
I suspect they would argue the impact of false positives (hired but don't work out) greatly outweighs the loss of false negatives (potentially great employees that can't pass through the filter). This may be true for the one company everyone and their dog wants to work for, but I wouldn't apply this kind of process to my startup.
It also feels like it might result in a surfeit of homogeneity. Genetic diversity is important; if everyone is a clone, all it takes is one pathogen to wipe out the population.
In my opinion, the biggest problem with the google-style interview (other companies do the same thing) is that you can practice and get better at it. In fact, you can probably improve how well you do so much that even a mediocre developer can come out looking very good.
So why is that bad? Well, for one thing, the questions asked usually aren't directly to being good at your job. Consider the classic "How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?" Very, very few people are going to come up with the correct answer to that question without having seen it before especially in a high pressure interview environment. Yet people ask it all the time in interviews. Why? You're just selecting for people who have had to interview a lot (got rejected a lot).
A newer style of interview that I quite like is to ask someone to write a moderate chunk of code with a laptop, access to the internet, and a few hours. At least you're measuring something that's directly related to software development.
I seem to always fail spoken interviews, but easily pass ones where I get to write code. As a particularly hilarious example, this spring I completely failed a phone-screen on the subject of 3D graphics, then sometime later I released a 3D terrain engine that is apparently the best of its kind in Flash as of today (http://news.ycombinator.com/item?id=1500338). And I can't say I know much more about the subject now! I just tend to learn stuff "situationally" and immediately forget it when the problem is solved. That applies to concepts too, but it's like 100x worse for APIs: my work nowadays is mostly ActionScript and JavaScript, but I can't even fill a polygon in AS without having the reference open.
I'm the same way. If I'm not currently working in the specific area I'm given a question in, it can take me a few minutes to access that information in my head. And therefore, I look like I don't know the answer.
I recently was in an interview for an iPhone dev job. I was prepared to talk about Objective-C/Apple SDK since I was working with that. However, they started digging into projects I had done at my last job (in Java). I struggled. I just hadn't thought about that work for a few years, and probably came off like I was embellishing my resume. After the interview, once I caught my breath and thought about it, all the details started coming back. Needless to say I was kicking myself for not being able to recall it sooner.
Clearly, many of us agree that this process is broken; not specifically at Google, but broken more or less everywhere. So fine, what would you do differently? I hate everything about job interviews, on both sides of the transaction: I don't want to ever job-interview or be job-interviewed again. So let's hear some radical ideas about how else to approach the problem. The crazier the better.
I really wish we had a culture of portfolios like other professions do. Of course, it's hard to do this because of the nature of our work; the code we create every day is not only company property that is generally kept secret, but is very hard to judge the quality of by means of a quick review with no sense of context. Furthermore, if you choose to merely judge the products the person has coded, assuming they've coded the lion's share of it, it's hard to tell what is going on behind the scenes and any judgment would be based on hypotheses, which would generate tons of false positives and negatives.
Still, something like portfolios are a very practical way of evaluating candidates because you're looking at real, concrete things the person has actually created. A modern coder interview is more like kicking the tires on a used car and then immediately deciding if you want to buy it or not.
I've mentioned in an earlier thread that I'd try to hire anyone who showed up for an interview with a working robot they'd designed and built by themselves because it's directly related to the kind of software we do.
Another option is having an application (desktop or web) you've written that we could then discuss during the interview: why do you have that feature? how did you implement it, let's look at the code, etc.
I have never had an applicant show up with code examples or anything to demonstrate what he had done (though I did prescreen someone who managed his own OSS project. He was hired) and really it would have a big impact in the hiring decision for a number of reasons. It doesn't have to be OSS or protected company work. If you've ever done a side project for fun you're already ahead of most applicants I see.
If I have an interview scheduled to go through lunch hours and the company does not offer me lunch, that makes a very bad impression on me. To me it's part professional courtesy as well as an indication of how well things are planned. Also, if you are able to lunch with the team, it lets you get to know each other in a less stressful situation.
That seemed very weird to me. When I interviewed, it was customary to have a Googler who was not an interviewer take you to lunch at one of the cafes. If you were a referral, it's usually your referrer; if you know someone at Google, they try to match you up with that person. It's your chance to ask questions of an employee in an informal setting, where they won't be making a report back to the hiring committee. And I know they still do it, because I was the lunch interview for a friend of mine that just applied a month or so ago.
The only thing I can think of is maybe they couldn't find interviewers for the normal time slots, and so they had to schedule one at lunch as well. Qualified interviewers are often a scarce resource at Google, mostly because of people like me who never sign up for it, and they try to avoid assigning more than two interviews/week/person to avoid burnout and let them still get actual work done. It may've been a choice between "schedule one during lunch" or "wait another week until a different interviewer is free".
The key, I think, to hacking most interviews is to take into account the fact that most interviewers overoptimize for their own contribution to the process; i.e., you want to put yourself on a path where the interviewers have some sort of insight into why you're valuable.
This can be the traditional: wow, this person has mastered all these fields very well. But it can equally be: wow, this person did extraordinary things with this thing that I've heard good things about; or, wow: I could totally use a person like that on my team -- I think culturally this type of person is valuable; etc.
Basically, you want to figure out the selection of likely thoughts the interviewer will have about you -- choose the set of most optimal, most distance-traversing in their mind (some of which ideally differentiate you for your peers), and give them some excuse to figure those out.
It's, sadly, not completely unrelated to PUA, as our minds are trained to seek and, with cognitive dissonance, to esteem the general direction of what we've verified before.
Fwiw, same pattern as setting traps in poker. Though hopefully you're not being duplicitous, but rather smoothing out an already error-laden, discontinuous situation.
But everyone knew C++. I’ve read about this before. This combined with my own experience now leads me to believe that C++ isn’t optional for any Google applicant. Not because you need to use it to work there. I have no direct experience of this. But because of “interviewer lottery”. Some at Google (it seems) do nothing but C++. You might be interviewed by one of these people.
Not true one bit. I don't know a lick of C++ and never encountered it in my interviews there.
In fact, the questions I was asked there could have been easily answered in any language, as they were language-neutral and heavily on the side of pure algorithms.
Your experience may have been thrown off by having C++ on your resume, assuming you do.
My experience (having interviewed at Google NYC twice, turned down both times) was that if I asked what language I should, they would always reply with either C, C++ or "C-like."
Only once was a particular language required (I was asked to implement memcpy, in part because the interviewer wanted to test my knowledge of low-level C and void pointers).
That said, I did write one of my solutions in OCaml even though the interviewer did not know the language (I asked him if I could, and he got the gist of my solution).
I had an on-campus interview where they were processing a lot of people quickly. C++ was non-optional. Of course, I have little C++ experience. I would suggest anyone seeking a job at google know C++.
I don't know Cletus, I just noticed his profile somehow in StackOverFlow. However, as a brilliant StackOverFlow member with over 100K of points and 3K answers, I really wonder if he is not above the average developer.
Only experienced developers can contribute and answer question in Stackoverflow. Questions are generally hard and random.
So if Google hires only from the top 10% (say in Australia); isn't this a critical fail in the hiring process? (considering cletus with ranking 4 in sof, I can safely say he's among the top 1% or 0.5%)
I don't think you can "safely say" that he's among the top 1% of developers based purely on his StackOverflow profile, regardless of how impressive it is.
The only way you can really "safely say" that someone is within the top 1% (That's a pretty elite group. That's like saying "I can safely say he'll get into Harvard.") is if you've seen a significant amount of their actual code (working with them, OSS, etc) and been consistently amazed.
There's also the issue of company fit. Google turns away a lot of very good developers because they're not good in a way that will translate to success within Google's culture.
Most of the questions asked on SO generally fall upon a spectrum of either "super domain specific" or "fundamental misunderstanding about a language". And then you have questions orthogonal to those classifications such as "what's the best IDE" or "do you think programmers MUST have two monitors?".
There are comparatively few questions that would fall under the category of computer science. I would be hesitant to say that having a lot of points on SO would automatically mean you are a genius programmer or problem solver.
Go look at Jon Skeet's top grossing answers. Only one of them is related to computer science.
"But the process does seem to be a lottery to some extent."
They go to great lengths to ensure this is not the case. If the feedback from five different interviewers led to a 'no hire' decision, the chances are good that it was the right decision. Of course, no system is perfect. They tend to err on the side of exclusivity; it's much cheaper to decline a suitable candidate than it is to hire someone who won't work out in the long term.
They go to great lengths to ensure this is not the case. If the feedback from five different interviewers led to a 'no hire' decision, the chances are good that it was the right decision.
As a recent hire at Google, I don't really think this is the case. There's not just a bias towards false negatives, there's a strong bias. It's well understood here that lots of qualified people are turned away.
And for whatever it's worth, the offer to keep your resume on file wasn't just lip service. I interviewed two years ago unsuccessfully, and was recruited a year and a half later based on the strength of that failure. It's also maybe worth mentioning that my only prior work experience was four years of desktop software development in C#, so I don't think the Microsoft thing is that much of a black mark.
Yeah, no. Of the dozens of Googlers I've met, their take is that this is just not the case. As others have pointed out, it is _not_ a lottery as to false positives, but it certainly can be for false negatives; Yegge himself points it out with "interview anti-loops."
But you know what? From a certain perspective, that's fine. We're currently going through a hiring phase at the startup I work for, and I'd much rather turn away people who might be ok than lock someone in who slid by. From his StackOverflow profile, cletus is a top-notch developer (or at the very least passionate and knowledgeable), it just sounds like he encountered his anti-loop. The biggest problem I see (and encountered this myself with them) is that there's no real feedback, even if your raw score was only just below the mark, where it might behoove everyone if you came back and interviewed with a little more experience and/or preparation.
> They go to great lengths to ensure this is not the case.
That may well be the case and I can't dispute the conclusion because I am unaware of the position. Were they looking for a hardcore C++ programmer? That's not me.
This goes to my observation that feedback is important. I've applied for positions that were slim chances before but I knew they were slim going in so I could set my expectations accordingly.
As for the lottery part, 2/5 didn't know my primary language. That seems open to interpretation.
Interesting how they are scouting stackoverflow profiles for potential hires. I suppose it takes more than 10k reputation (talking about my own profile of course).
The part about being denied because he was Microsoft-centric and yet Jon Skeet was accepted was quite amusing.
When rejection occurs after an interview, I generally try to my best to identify what I did wrong and prepare to the next interview.
My advice don’t feel disappointed if you don’t get the OK there are many reasons why someone get rejected, most of them not necessary skill based; so JUST MOVE ON.
We're currently going through a hiring cycle, and while admittedly, there's a lot of people applying, I get annoyed by some of our guys doing interviews removing people from consideration for things that simply do not matter.
I would likely have failed our own interview processes, yet I was one of the guys let know I was indispensable and not to worry about my job security by upper management when we were going through layoffs in the middle of the financial crisis, going so far as to offer me a raise in the middle of it.
The post-interview review of candidates needs to be:
(1) Are they smart?
(2) Do they practice self-improvement? A given if (1).
(3) Can we work with them?
But not many people have the balls to take a chance on someone from the left field, so they'll settle for the mediocre plodder who has learned how to game the interview process.
Why don't companies just hire people after a quick discussion at 50% salary for the maximum of four months and see how they do.
If, after four months, the people turn out to be "smart and get things done" and the company wants to keep them, they'd get the missing 50% from the first four months as a one-time bonus and 100% salary afterwards.
It costs something but it also costs a lot of time and money for both parties to engage into this mutual guesswork game called job interviewing. It might even cost everyone less as I bet many candidatepeople would have to be fired after only a few weeks or days.
I agree with the fact that not getting any feedback (good or bad) hurts people in the long run. Having feedback and either improving in those areas or adjusting how you approach them would help people and if you don't know their an issue how can you improve them?
I've sent previous interviewing managers questions asking what I can improve when I didn't get a job this year, and none of them returned my e-mail. Very frustrating, especially if you're someone who would like to improve themself!
That would assume communication between job applicants. In general, job searh is conducted in secret. When I wa interviewing, nobody but my family and closest friends knew I was doing. I wouldn't appreciate if a candidate kept talking about our hiring processes. Even because they change, vary according to the position and are explained early in the process to the candidate by the HR folks who conduct the first steps.
I have nothing to say about Google's process, with the exception being that I was interviewed by a guy whose research paper I read, something that didn't really surprise me.
Part of the problem that bit him, I think, is that the traditional interviewing/hiring process is fundamentally flawed and handicapped.
Superficial elements have way too large of an impact. it filters out things that should not be filtered out. and way too big of a judgement is made too early, and on too little information, and with too little confidence in the correctness of that judgment. resumes are demanded and then either not read or not remembered. small comments can be magnified in the mind of the listener and used to conclude things that cannot possibly be concluded. ridiculous questions are asked. and lastly, there's very often too much of an attitude that the company/interviewer is in the superior/owner position and the applicant in the subservient/inferior/slave situation (perhaps carried over from blue collar industry) when in reality it should probably be considered an exchange of equals.
the company/interviewer is in the superior/owner position and the applicant in the subservient/inferior/slave situation (perhaps carried over from blue collar industry)
Agree 100%. It's a kinder-gentler master-slave dynamic. That's part of why it's so fucked. So what's the alternative? Let's figure something out.
[+] [-] etherael|15 years ago|reply
What's the default bytes per block in random linux distribution x version y when using filesystem z?
My response;
I'd google it.
Perhaps this is unique to the Australian branch of Google or something but I get the impression that they're much more into the whole meaningless rote memorisation of facts than is often let on.
I had a contact from another Google HR person a couple months back in Estonia, this time for a development position. I can't say I wasn't tempted but this time I turned them down flat.
[+] [-] Caligula|15 years ago|reply
[+] [-] shubhamharnal|15 years ago|reply
"...Well I dunno but let's see...Filesystem Z(let's say reiserfs)...so this one's pretty good with really large files...its preferred to other ones(say ext2) for both support of larger files and better disk checking...at the time of distro x, version y, filesystem D(that you may be familiar with) hadn't even come out and was probably an improvement over Z, so I'd wager less bytes per block than filesytem D but more than...."
...or so could be a possible response...I hope I am getting my point through, though of course you're the one to have lived through the day and not me and I'm sure your reply was what you felt best, at the time.
[+] [-] cletus|15 years ago|reply
I'll frame this in what I know, which is programming. I think it's entirely reasonable to ask someone how a hashtable or even a quick sort (or some other O(n log n) sort) works because programmers should be familiar with that even if 99.9% of the time (if not 100% of the time) you're using a HashMap or std::map or dict or whatever.
But number of inodes does seem somewhat esoteric.
[+] [-] endlessvoid94|15 years ago|reply
Didn't get the job. I didn't make one mistake and I thought they liked me. I have zero clues as to why. I'm not really upset about it, it was just a very frustrating experience.
All the more reason to do your own thing :-)
[+] [-] nostrademons|15 years ago|reply
The lack of feedback does suck, but I wonder if it says more about our own ability to judge our competence than about the interview process itself. As btilly points out, companies in the U.S. are almost required to not say what you did wrong, for fear of lawsuits. Plus, the hire/no-hire decision usually comes down to a visceral reaction, so the decision-makers may not even know why they decided one way or another.
Also - if you think the lack of feedback for interviews sucks, it's ten times worse when you're doing your own thing. I was an entrepreneur before Google, and we launched like 4 websites before I threw in the towel and got a job. Each one of them was met with a resounding...silence. Nobody saying we were bad, but nobody saying we were good either. We were just irrelevant. That's the way most startups go: if you're successful people will just quietly use your product and never acknowledge you, and if you're unsuccessful, people will just quietly not use your product and never acknowledge you. The only startups that get masses of haters are the ones where the founders were previously famous but royally fucked up (eg. Cuil), and the only ones that get massive acclaim are the ones that solve a hair-on-fire problem in a particularly spectacular way (eg. Google).
[+] [-] btilly|15 years ago|reply
Google started in the USA. In the USA if you give feedback, no matter how well-intentioned or apparently harmless it may be, that can be used to sue you. Even if those lawsuits are unlikely to go anywhere, they are a distraction. So no US company will give you feedback.
And that's become standardized in Google's procedures.
[+] [-] city41|15 years ago|reply
This experience bugged me for a while. Man what I would have given to see that guy's notes about me :)
[+] [-] nihilocrat|15 years ago|reply
The lack of feedback makes me just assume every interview is a crapshoot and there's nothing I can do to try and improve.
[+] [-] gcheong|15 years ago|reply
[+] [-] danbmil99|15 years ago|reply
I suspect they would argue the impact of false positives (hired but don't work out) greatly outweighs the loss of false negatives (potentially great employees that can't pass through the filter). This may be true for the one company everyone and their dog wants to work for, but I wouldn't apply this kind of process to my startup.
It also feels like it might result in a surfeit of homogeneity. Genetic diversity is important; if everyone is a clone, all it takes is one pathogen to wipe out the population.
[+] [-] btmorex|15 years ago|reply
So why is that bad? Well, for one thing, the questions asked usually aren't directly to being good at your job. Consider the classic "How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?" Very, very few people are going to come up with the correct answer to that question without having seen it before especially in a high pressure interview environment. Yet people ask it all the time in interviews. Why? You're just selecting for people who have had to interview a lot (got rejected a lot).
A newer style of interview that I quite like is to ask someone to write a moderate chunk of code with a laptop, access to the internet, and a few hours. At least you're measuring something that's directly related to software development.
[+] [-] dtcavallaro|15 years ago|reply
[+] [-] vecter|15 years ago|reply
[+] [-] cousin_it|15 years ago|reply
[+] [-] cyunker|15 years ago|reply
I recently was in an interview for an iPhone dev job. I was prepared to talk about Objective-C/Apple SDK since I was working with that. However, they started digging into projects I had done at my last job (in Java). I struggled. I just hadn't thought about that work for a few years, and probably came off like I was embellishing my resume. After the interview, once I caught my breath and thought about it, all the details started coming back. Needless to say I was kicking myself for not being able to recall it sooner.
Just the way my mind works....
[+] [-] gruseom|15 years ago|reply
[+] [-] mstevens|15 years ago|reply
You'd have to come up with some suitable toy problems that you could make significant progress on in a day.
[+] [-] csl|15 years ago|reply
Their puzzle archive: http://www.itasoftware.com/careers/puzzle_archive.html?catid...
[+] [-] nihilocrat|15 years ago|reply
Still, something like portfolios are a very practical way of evaluating candidates because you're looking at real, concrete things the person has actually created. A modern coder interview is more like kicking the tires on a used car and then immediately deciding if you want to buy it or not.
[+] [-] HeyLaughingBoy|15 years ago|reply
Another option is having an application (desktop or web) you've written that we could then discuss during the interview: why do you have that feature? how did you implement it, let's look at the code, etc.
I have never had an applicant show up with code examples or anything to demonstrate what he had done (though I did prescreen someone who managed his own OSS project. He was hired) and really it would have a big impact in the hiring decision for a number of reasons. It doesn't have to be OSS or protected company work. If you've ever done a side project for fun you're already ahead of most applicants I see.
[+] [-] photon_off|15 years ago|reply
Hire him to work for 1 week at a decent hourly wage.
If he's good, he's good.
[+] [-] gcheong|15 years ago|reply
[+] [-] nostrademons|15 years ago|reply
The only thing I can think of is maybe they couldn't find interviewers for the normal time slots, and so they had to schedule one at lunch as well. Qualified interviewers are often a scarce resource at Google, mostly because of people like me who never sign up for it, and they try to avoid assigning more than two interviews/week/person to avoid burnout and let them still get actual work done. It may've been a choice between "schedule one during lunch" or "wait another week until a different interviewer is free".
[+] [-] tmsh|15 years ago|reply
This can be the traditional: wow, this person has mastered all these fields very well. But it can equally be: wow, this person did extraordinary things with this thing that I've heard good things about; or, wow: I could totally use a person like that on my team -- I think culturally this type of person is valuable; etc.
Basically, you want to figure out the selection of likely thoughts the interviewer will have about you -- choose the set of most optimal, most distance-traversing in their mind (some of which ideally differentiate you for your peers), and give them some excuse to figure those out.
It's, sadly, not completely unrelated to PUA, as our minds are trained to seek and, with cognitive dissonance, to esteem the general direction of what we've verified before.
Fwiw, same pattern as setting traps in poker. Though hopefully you're not being duplicitous, but rather smoothing out an already error-laden, discontinuous situation.
[+] [-] brown9-2|15 years ago|reply
Not true one bit. I don't know a lick of C++ and never encountered it in my interviews there.
In fact, the questions I was asked there could have been easily answered in any language, as they were language-neutral and heavily on the side of pure algorithms.
Your experience may have been thrown off by having C++ on your resume, assuming you do.
[+] [-] aplusbi|15 years ago|reply
Only once was a particular language required (I was asked to implement memcpy, in part because the interviewer wanted to test my knowledge of low-level C and void pointers).
That said, I did write one of my solutions in OCaml even though the interviewer did not know the language (I asked him if I could, and he got the gist of my solution).
[+] [-] jacoblyles|15 years ago|reply
[+] [-] csomar|15 years ago|reply
Only experienced developers can contribute and answer question in Stackoverflow. Questions are generally hard and random.
So if Google hires only from the top 10% (say in Australia); isn't this a critical fail in the hiring process? (considering cletus with ranking 4 in sof, I can safely say he's among the top 1% or 0.5%)
[+] [-] jackowayed|15 years ago|reply
The only way you can really "safely say" that someone is within the top 1% (That's a pretty elite group. That's like saying "I can safely say he'll get into Harvard.") is if you've seen a significant amount of their actual code (working with them, OSS, etc) and been consistently amazed.
[+] [-] nostrademons|15 years ago|reply
[+] [-] tkahn6|15 years ago|reply
There are comparatively few questions that would fall under the category of computer science. I would be hesitant to say that having a lot of points on SO would automatically mean you are a genius programmer or problem solver.
Go look at Jon Skeet's top grossing answers. Only one of them is related to computer science.
[+] [-] enneff|15 years ago|reply
They go to great lengths to ensure this is not the case. If the feedback from five different interviewers led to a 'no hire' decision, the chances are good that it was the right decision. Of course, no system is perfect. They tend to err on the side of exclusivity; it's much cheaper to decline a suitable candidate than it is to hire someone who won't work out in the long term.
[+] [-] prospero|15 years ago|reply
As a recent hire at Google, I don't really think this is the case. There's not just a bias towards false negatives, there's a strong bias. It's well understood here that lots of qualified people are turned away.
And for whatever it's worth, the offer to keep your resume on file wasn't just lip service. I interviewed two years ago unsuccessfully, and was recruited a year and a half later based on the strength of that failure. It's also maybe worth mentioning that my only prior work experience was four years of desktop software development in C#, so I don't think the Microsoft thing is that much of a black mark.
[+] [-] slpsys|15 years ago|reply
But you know what? From a certain perspective, that's fine. We're currently going through a hiring phase at the startup I work for, and I'd much rather turn away people who might be ok than lock someone in who slid by. From his StackOverflow profile, cletus is a top-notch developer (or at the very least passionate and knowledgeable), it just sounds like he encountered his anti-loop. The biggest problem I see (and encountered this myself with them) is that there's no real feedback, even if your raw score was only just below the mark, where it might behoove everyone if you came back and interviewed with a little more experience and/or preparation.
[+] [-] cletus|15 years ago|reply
That may well be the case and I can't dispute the conclusion because I am unaware of the position. Were they looking for a hardcore C++ programmer? That's not me.
This goes to my observation that feedback is important. I've applied for positions that were slim chances before but I knew they were slim going in so I could set my expectations accordingly.
As for the lottery part, 2/5 didn't know my primary language. That seems open to interpretation.
[+] [-] timcederman|15 years ago|reply
[+] [-] btilly|15 years ago|reply
[+] [-] codexon|15 years ago|reply
The part about being denied because he was Microsoft-centric and yet Jon Skeet was accepted was quite amusing.
[+] [-] kno|15 years ago|reply
My advice don’t feel disappointed if you don’t get the OK there are many reasons why someone get rejected, most of them not necessary skill based; so JUST MOVE ON.
[+] [-] heresy|15 years ago|reply
I would likely have failed our own interview processes, yet I was one of the guys let know I was indispensable and not to worry about my job security by upper management when we were going through layoffs in the middle of the financial crisis, going so far as to offer me a raise in the middle of it.
The post-interview review of candidates needs to be:
(1) Are they smart?
(2) Do they practice self-improvement? A given if (1).
(3) Can we work with them?
But not many people have the balls to take a chance on someone from the left field, so they'll settle for the mediocre plodder who has learned how to game the interview process.
[+] [-] yason|15 years ago|reply
If, after four months, the people turn out to be "smart and get things done" and the company wants to keep them, they'd get the missing 50% from the first four months as a one-time bonus and 100% salary afterwards.
It costs something but it also costs a lot of time and money for both parties to engage into this mutual guesswork game called job interviewing. It might even cost everyone less as I bet many candidatepeople would have to be fired after only a few weeks or days.
[+] [-] bosch|15 years ago|reply
I've sent previous interviewing managers questions asking what I can improve when I didn't get a job this year, and none of them returned my e-mail. Very frustrating, especially if you're someone who would like to improve themself!
[+] [-] bosch|15 years ago|reply
Has anyone ever thought they randomly fail someone who might pass just to keep all future applicants on their toes?
[+] [-] rbanffy|15 years ago|reply
I have nothing to say about Google's process, with the exception being that I was interviewed by a guy whose research paper I read, something that didn't really surprise me.
[+] [-] known|15 years ago|reply
[+] [-] mkramlich|15 years ago|reply
Superficial elements have way too large of an impact. it filters out things that should not be filtered out. and way too big of a judgement is made too early, and on too little information, and with too little confidence in the correctness of that judgment. resumes are demanded and then either not read or not remembered. small comments can be magnified in the mind of the listener and used to conclude things that cannot possibly be concluded. ridiculous questions are asked. and lastly, there's very often too much of an attitude that the company/interviewer is in the superior/owner position and the applicant in the subservient/inferior/slave situation (perhaps carried over from blue collar industry) when in reality it should probably be considered an exchange of equals.
[+] [-] gruseom|15 years ago|reply
Agree 100%. It's a kinder-gentler master-slave dynamic. That's part of why it's so fucked. So what's the alternative? Let's figure something out.
[+] [-] didtrade|15 years ago|reply
[deleted]