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.
Joel Spolsky gave a Google Tech Talk about Stackoverflow. At one point someone asked him about something he said. He had to look it up. He opened up IE and did a search on live.com (pre-bing). It got a good laugh.
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.
If that's what they were really looking for, then they're really just testing whether you can figure out what they're really looking for, whether they know it or not. If you want someone to demonstrate their thought process, you give them a tricky problem and just tell them to solve it out loud. If it's a good problem, they're not going to be able to fake having an awesome thought process.
"I'd google it" is exactly the right answer, as far as I'm concerned. Unfortunately, it's never the answer interviewers want to hear. Regardless of whether they've asked good questions, it's invariably one of the most common responses interviewees will make when they don't know the answer. Whether or not the interviewer had a justified expectation that you should know the answer, "I'd google it" immediately gets you downranked by association with people who don't know their shit.
I'd agree. I'd rather hire someone who's willing to know what he/she does or doesn't know, and rather than pussy foot around the issue, trying to remember it, google's the answer, fixes the problem and moves on.
This jives with an interview I did with a Google SRE a couple of years ago. He basically took me down a path of increasingly esoteric concepts, until we hit a point at which I couldn't recall the answer off the top of my head. He asked how I'd implement it; once I reasoned through it (and recalled the bit of information I couldn't remember at first), we quickly moved on to another line of discussion.
I assume this was an intentional approach: find an area of knowledge the candidate should understand at a high level, but probably hasn't committed the details of to memory, and see if they can reason it out.
You learn significantly more about someone when they're a bit out of their element; does their confidence evaporate, or do they work through it and come up with a reasonable solution?
You're right actually; I've considered that a few times, but decided against it based on the guy's reaction to my reaction, he wasn't hedging for another answer, it was just "Ah, right."
That particular thought did only occur to me sometime later though so could be it certainly.
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.
In my view, it's stupid because it implies that if you're the kind of person that bothers to attempt to commit irrelevant or at best situationally relevant things like this to memory as a matter of course, you probably aren't making optimal use of your mental resources.
I found it pretty ironic actually as that's exactly the kind of thing we have search engines for.
On the other hand, if you are constantly working with certain systems, you will know this stuff. If they ask me something esoteric about a language or API that I know really well, I can answer all the tricky questions, or explain how I think it would work. If it is something I use rarely, then I could not.
I think these kinds of specific questions are justified, but only on the basis that (a) it tests that the candidate really does or has worked in this field in depth, and (b) you have a bunch of other similar questions, and knowing the answer to just one or two of them counts as a pass. Basically, it's like throwing spears into an opaque pool, hoping to find evidence of the salmon of knowledge.
I could totally see asking someone that question if they said that they were intimately familiar with some distro or another. Outside of that context, it seems like a really bad question. Maybe there was another purpose to the question (like seeing how you reacted to bad questions), or you just had a shitty interviewer.
Just checked the mkfs.ext4 man page and no, that doesn't seem to be the case. This was about five years ago so the precise question I can't perfectly remember, but the nature of it was as stated; It was a question about a specific filesystem setting default value, on a specific version of a specific distribution of linux, inode size, bytes per inode or bytes per block.
Apologies for sounding a little addled but it's been five years since I have been a systems administrator so it's all melted together in my memory.
-b block-size
Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and 4096 bytes per block. If omitted, block-size is heuristically determined by the filesystem size and the expected usage of the filesystem (see the -T option).
I remember that Red Hat and Fedora used 1024 on my computer.
As for the distribution specific thing, maybe some distribution had their own version of /etc/mke2fs.conf (settings for mkfs, including block size).
Perhaps a more "sysadmin-ish" answer would have been something more like "Whatever the command 'echo 1 > /tmp/one && du -h /tmp/one && rm /tmp/one' prints".
This sounds like a question used judge character. I'm not sure it makes sense to be doing such a thing at google, but sometimes these kinds of things are asked more to judge your reaction rather than your answer. I'm sure you replied confidently, but others may get flustered, which could be a sign of how they act under pressure.
And of course there are those who would answer take a best guess stab rather than appear to not know the answer which would be undesirable as well.
Typically if you get that one right, there is a serious of follow up questions each getting deeper and deeper into the understanding of the same topic.
That seems to assume that the deeper understanding necessitates the trivia. One can understand how a filesystem works without knowing the default block size.
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).
If the interview is adaptive (increasing difficulty till you can't handle it anymore), strongest candidates may end up feeling it went terrible, while weak candidates may feel it went very well (not being aware they were culled out early).
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.
The problem is that a certain fraction of applicants will become convinced, rightly or wrongly, that they were hard done by, and were blackballed for whatever reason. Any hard information you give them can be used against you.
And unfortunately not just obvious stuff like "we didn't hire you because you're black". You can say something innocuous like, "your grasp of algorithms didn't seem strong enough" and the candidate will flash to a particular interviewer who asked an algorithm question they didn't get, and become convinced that that was who blackballed them. And can further become convinced that that person actually had it out for them for unrelated reason X.
This might be unlikely to wind up in court, but it happens often enough that it shows up in nasty blogs, rumors, etc that every large company has learned that you just don't want to go there. And none of them do.
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.
As a consultant, I got to do lots of interviews. I found that questions and programming problems go in fads or cycles. I often get the same programming problem at more than one company. After an interview, I go over the problems to see if I can tighten up the code, or to see what the nut is. If I am weak or unsure about one of my answers, I immediately go over the literature to understand the domain. The same question is sure to come up again. A couple of years ago it was the new java concurrency. This yea, not a single question about Java concurrency. But I did get FizzBuzz. :-)
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.
Having been interviewing candidates for over a decade, I've noticed that in the vast majority of cases, this question is only asked by people who've done very badly. With a good candidate it doesn't feel like an interview at all, it feels like getting to know someone who's just joined your team.
I've been interviewing people for 15+ years and I've only had one person ask that question and he was by far the worst candidate I've every interviewed for a developer job.
I'd read stories about people doing this and being told they're not supposed to.
I'm usually a fairly good judge of this sort of this so I usually don't need to ask. Eliciting a response may not give an accurate response (eg putting someone on the spot when their view is negative could be somewhat confronting).
Practically speaking however, time constraints tended to prohibit such chit-chat anyway.
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.
> 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.
While this is true, isn't quite unlikely? Why not just invest the time into becoming a /good/ developer.
>"How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?"
What do you mean by "accounting" information?
In the real-world I'd probably just brute-force it and keep around a set of elements already gone over. However I couldn't imagine ever having a need for that as I'd (and hopefully anyone I was working with) stick to the standard push_back functions available or that I created. So it shouldn't come about...
I feel I've missed something here, so care to elaborate on the answer?
>"How can you detect loops in a singly-linked list without modifying nodes / keeping accounting information around?"
What do you mean by "accounting" information?
The usual way to state this problem is, "How can you detect loops in a singly-linked list without modifying nodes and using O(1) data."
The answer is that you start with 2 pointers to the beginning of the list. Then follow the pattern of advancing the first twice, and the second one once. You have your answer when the first reaches the end, or the first and second point at the same spot.
There are a lot of problems with a trick like that. And it is true that if you've seen the problem before, you're going to be at an advantage. So practice a few of them to get use to the form. But there are enough such problems out there that it is significantly easier to become a good developer than to learn a broad enough selection of them to have a good chance of getting through a set of interviews off of memory.
While this is true, isn't quite unlikely? Why not just invest the time into becoming a /good/ developer.
It might be unlikely for people applying to google, but I can attest that people will memorize what they think are details that will make them sound like they are competent to get through an interview.
The software development industry is one where you can really make it into a position with decent pay by bullshitting, and then surf the wave of nothing-getting-done-because-of-corporate-policy for a while, while making yourself appear like a magic technology man if you really feel like it. This probably isn't going to happen as much with a company whose hiring process is filled with competent software engineers (but there's also the opposite problem...)
It sounds like hell to me, but I'm concerned with writing code and feeling intellectually fulfilled, not just with making stacks of cash.
In the real-world I'd probably just brute-force it and keep around a set of elements already gone over.
That is what is meant by accounting information - keeping track of the elements in the list you've visited.
I believe the generally accepted answer for this question is to use two iterators, one moving faster (two elements at a time) than the other (one element at a time). If there is a cycle in the list, at some point the two iterators will be pointing at the same node. Otherwise, the iterators will reach the end of the list, meaning no cycle exists.
> 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.
It's a popular meme on HN that people's intelligence and abilities are fixed from the start. In reality, they're quite plastic and improve over time when they're put to a use.
Note that outside of few companies such as Google, Microsoft, Apple and some start-ups (and even for good chunk of roles within those companies) great deal of programming involves wiring together components somebody else wrote, while working around bugs in those components. There's nothing wrong with that, in fact, if someone already solved a problem adequately enough it's your duty to build an application based on that solution rather than re-invent the wheel, this time with new and exciting bugs (I'll confess to having done that bunch of times, going as far as writing my own RNG once). If you want to understand how the "magic" of those components works (so that you could get some of the most intellectually rewarding jobs which involve creating such "magic"), you have to do that on your own time.
Thus, if you have a regular programming job specific portions of your intelligence will atrophy as they're not being used. If you've found a job that is intellectually stimulating, then you have no reason to interview elsewhere unless you're grossly underpaid, have to commute to the North Pole and write firmware for machines that torture baby seals.
When an interview candidate is truly smart e.g., can figure out a more puzzle-like problem without ever having seen them before, that's great and respectable. Give her a few extra points. When a candidate shows persistence, passion (coding in her spare time on the sort of problems you typically don't see in day to day work), curiosity (learning about skip lists just because they're... really cool) and a way to apply her intelligence (even if that's not genius level) to her field of work (being able to keep multiple levels of indirection e.g., pointers and recursion in her head) that's even better.
In my (so far, limited) experience in the industry I've noted that there are several types of programmers:
1) The "99.9th percentile" or "10x" programmers. They usually have an innate ability that was well nurtured from the beginning. There's only a handful of them, fairly equally distributed between Google (prior to it Sun, Bell Labs), start-ups, academia and quantitative finance / hedge funds. It's very visible: they'll solve problems quickly, they'll write code and get many things right the first time. They'll spot tricky concurrency issues by just looking at the code. If you manage to find one, by all means move mountains to hire them. Problem is, why would they join you? Money is not a motivating factor for them (not always out of principle: they're generally well off already) and companies bend rules for them (e.g., let them work from home or open offices in their home town if they're not local). If you want to hire them, hire all of their (respected) coworkers and friends, first. May be then (if things turn sour at their workplace) they'll consider you. The other way is to spot one amongst the crowd of interns or fresh graduates (Joel recommends that).
2) Visible poor ones. Typically very nice people, sometimes highly persistent and entrepreneurial but without the ability and/or education (self or formal) needed to succeed in an engineering discipline. They may still be smart: surprisingly, I've seen several people with advanced degrees in Mathematics and Computer Science that fit that bill (how that could happen evades me). Typically these are the people that are always on the market: who can't do fizz buzz, reverse a linked list, etc... It's trivial to filter them out. If they're really eager to be involved in software development, project/product management may be a right fit for them if they're otherwise smart and technical (see "The Russian Lit Major" by Rands for more on that). Oddly enough, I've seen people like that found profitable and sustainable small businesses (even if they weren't technology start-ups with home-run exits).
3) Everybody else. They're intelligent and educated (again, whether self or formally) enough to be <b>a programmer</b> but it either took or will take them work to be a great one. They have no genial ability, they will write code that has bugs and will have to sit down at a debugger to figure out why their code doesn't work. Odds are most people on HN fall into that category. Question is, how persistent are they at this? Do they give up after getting a cryptic error message? Have they had enough experience to avoid common causes of bugs? Are they willing to take time to improve themselves (to be able to "work magic") rather than being content to be typical enterprise developers?
People in this category are very well capable of being 95-98th percentile programmers. It just takes practice (and not just paid practice at work) in addition to dedication and passion, not just innate qualities (such some forms of intelligence), to get to that level.
They range in their current ability from "framework developers" (who don't care how something is implemented, but know a particular implementation well enough to get the job done) to what I called "95th-98th percentile" developers. Finding people on the upper end of that range (who have worked/studied their way to that place) is what programming questions should be aimed at, not just at finding general intelligence.
Majority of employees in serious technology companies (Google et al) as well as a most start-up founders (with a few exceptions of some true "10x" programmers e.g., Bill Joy of Sun) fit that bill: they persisted at and practiced something they loved for a long period of time and became great at it. There are more of these people than there are "10x" programmers and many have earned the respect of the "10x" programmers and are going to be able to attract them to your organization in a "get an already great programmer, get introduced to his genius friend" deal.
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.
An amusing variation on this might be to pick the next n interviewees and tell them to spend the day working on something as a team. Observe via camera or one-way glass.
And yet, if you talk to managers, they'd complain at length about the inability to find even mediocre people.
Most states in the US have "at will" employment laws meaning that its easy to fire a person after a couple of weeks if its obvious they're not working out.
That's a false dichotomy. Google has a relative luxury here.
Companies that don't have a large enough pool of quality applicants to hire from need to turn that equation around: rather, they must try hard not to let the excellent applicant get away, as they may not find another.
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.
This is exactly why a candidate with an active GitHub account will always get fast-tracked through the screening process any time I'm involved in the hiring process. It doesn't matter if the projects there are 40-line utility scripts or heavy-duty middleware; the important thing is how they indicate willingness to write and share your code.
(Of course, if the code on a candidate's GitHub page or blog is terrible, that tells you something too...)
Google used to do that - if you remember their "Great people needed" campaign from 2002-2005, they did fun stuff like putting coding problems on billboards that solved to the phone number you had to call to submit to apply, or the "Google Labs Aptitude Test" that was basically a parody of standardized testing.
I think the reason they don't anymore is that they're a household name. They get tons of applications without any clever tricks. In some ways, I think this is too bad, because it attracts applicants who (in JWZ's words) "want to work for a successful company instead of working to make a company successful." But there's really no way to turn back the clock and make Google hip & unknown anymore.
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.
That wouldn't work at any company I've worked for, at all. It can often take a couple of days to get completely physically set up (desk, workstation, chair, laptop, etc), and up to 2 to 4 weeks to really get your environment completely set up so you're ready for real work (including figuring out how stuff works, and reading code and stuff).
I don't think 1 week is really enough to do anything important. For a good candidate, anyway. I'm sure a bad candidate can find lots of stuff to screw up in 1 week, especially if they're trying to "impress".
Two things about the latency period you mention. First, it can be mitigated, and second, it's going to happen regardless.
I think that physical essentials such as desk, workstation, etc, should be taken care of already. A smart company would have these items available in the chance that an amazing candidate could start immediately. It's a relatively small overhead cost on things that are going to eventually be required. With exception to the computer, the value of the items won't degrade with time so you might as well purchase them sooner than later.
I do agree that it may take some time for even a good candidate to become productive member. However, this period of time is going to happen no matter what. By having the candidate on as a consultant at first, you at least retain the option of not hiring him fulltime... which would be much a cleaner than hiring him, then firing him shortly after or dealing with a dud employee.
It's basically a "try before you buy" type of deal. No matter what car you're going to buy, it's going to take you some time to get used to it. Does that mean you shouldn't test drive them? As it stands now, the "test drive" is supposedly the interview. To me, it makes more sense to have a longer "risk free" test drive period, especially when you're going to be investing a lot into something.
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.
The "top 1%" is such a great phenomenon. I remember in the 2000 election the top 1% of earners were daemonized by then VP Gore. In a survey some 20% of people thought they were in the top 1% and another 19% aspired to be.
And that's with something easily quantifiable. How exactly do you quantify the percentile of a programmer?
FWIW I make no such claim about being the top 1% nor do I claim SO ranking translates to the nebulous concept of a programmer's ranking. If anything, SO reputation is a function of time more than anything else. It's also an indicator of persistence but only a positive indicator (meaning lack of a SO ranking obviously doesn't mean a lack of persistence).
By the same token, however, don't overestimate the competence of the vast majority of working stiffs who have titles describing them as programmers. Many (I would estimate well over 50%) just turn simple business requirements into business rules by copying and pasting earlier implementations, and getting things done by sheer persistence mixed with some googling, forum questions, etc.
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.
Top questions and top answers are almost by definition bikeshedding trivia, because those are the only kind which can draw a large enough population to get really high votes.
Definitely true. The point I should have emphasized is that the StackOverflow questions and answers usually are about a user's experience with a framework/language or lack thereof. Few questions require answers that are creative or profoundly intellectual.
"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.
"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."
This is pretty much exactly what I said. Do you think if I'd pointed out that I'm actually a google employee also, I might have been spared the down votes?
You said there was a good chance it was the right decision. That may be true in some amortized sense across all hires, but you implied that it was also likely the correct choice in this specific situation. I don't think putting that much faith in the results of the hiring process is justified.
Jobs interviews at Google aren't near perfection with a slight bias towards false negatives, and it's unfair to the people who don't make it through to suggest that they are.
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.
"Yeah, no. Of the dozens of Googlers I've met, their take is that this is just not the case."
I am a Googler. I mentioned explicitly that false negatives happen, and stated why they are preferable. Why, then, do you preface your comment with a disagreement?
> 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.
I can't speak to any particulars in this situation. I thought I would add that it's not necessary to know C++ (I don't :o). It is true that there are people who work on projects that are entirely written in C++. However, there's not generally a requirement that applicants write solutions in a particular language and pseudo code is usually fine.
I'm interested how this came about. They usually either try to match people who know common languages or they do more generic problems which don't depend on language. One important thing is if you said you knew C well (or even only "working knowledge of") then it's perfectly reasonable for them to ask you to write it in C instead of Java/Python/etc. Did the interviewers state they didn't Java beforehand? Did they say they knew another language you'd mentioned you knew on your resume?
My interview experience actually involved them hammering me on the languages I said I knew but wasn't an expert in. This is likely as they were trying to find out whether I was lying (or, put kindly, overstating) on my resume. From what I've seen there are a few people who put every language down that they've ever written hello world in ;)
(disclaimer: recent intern from Google Sydney office)
They won't give you feedback for the same reason they don't disclose their search algorithms: information about their process can be used to game the process.
I see the same behavior with VC's -- no usable feedback. It's like in poker -- there's no game-theoretic advantage to show your cards if everyone else folds.
It's also arrogant not to even let someone know what the specific position involves. It's a solid reason not to interview with Google if you're not going in there on the basis of contacts.
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.
I was approached by Google recently for an SRE position. I'm not sure where they found my contact information but I don't have accounts with any of the major geek sites - or much of an internet presence at all, really.
The recruiter was a tad vague about it but if I were to venture a guess, I'd say Google scans the high-profile OSS projects and associated mailing lists. That's about the only place they could have found me.
I think Google recruiters trawl places frequented by programmers and invite them in. A few years ago, when I was more involved in free software, I got an email out of the blue asking me to submit a resume. I was certainly not as visible in the communities I frequented as this guy appears to be in his.
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.
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.
Having an incompetent (or malicious even) developer on your team for four months is likely to cost your company much more than 50% of their salary for four months.
My point was that this is what happens in the practice: you just won't know until you know, so why not make it that way upfront and not spend lots of effort trying to select the best candidate when you could, based on a much more loose criteria, select the best dozen and see who's really good.
I wasn't envisioning a sweatshop: if the company tried to extract everything out of cheap hires for four months, the company itself would lose. And there are these leeching companies anyway, working within conventional hiring practices as well. I had a good company in mind, one that really needs good programmers and not cheap minions.
An incompetent or malicious developer wouldn't really last four months, not probably four days. The projected four months was the final threshold after which most programmers can tell whether the candidate is really worth hiring.
Having new semi-hires around might certainly add up to the team overhead but on the other hand, that's what happens with conventional hires, too. Lots of teaching, tutoring, and support and things might still get crossed in the first few months. Plus the whole process of interviewing and that some hires quit or get fired within months.
So, to reply to your comment: having a batch of new hires, some incompetent and some possibly stellar, and few weeks to sort out the final candidates and few months to seal the deal, might not cost as much as you're afraid. Even a single new hire (carefully selected by HR, phone interviews, face-to-face interviews, and all) can eat up surprisingly lot of the team's time. Further, like hires in general, you don't want to be doing this all the time, just once a year or when you really, really need more programmers.
The issue with this approach is that it doesn't weed out the mediocre. This is why big companies fire people by re-organization. You run into legal problems if you are firing people who are competent, but not excellent. So you round them up into another business unit and then drop the whole unit. I assume you would run into the same legal issues with the proposed 4 month trial period. If the person does a solid, but not great job and you let them go, you are opening yourself up to being sued.
And working at 50%, for a competent developer, is also likely to chafe quite a bit. Though hopefully, if someone's really able to tell, you'll be able to tell in much less than 4 months.
I could not afford to work for four months at half of my salary, and I don't have a family - so I can only imagine that people supporting a family would really not be able to do this.
> 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.
Because best developers already have jobs and aren't knocking on your door desperate to take a risk like this.
That's the problem with the "probation period" ideas, in addition to creating churn and other unpleasant hygenic effects, why would somebody with a great job willing subject themselves to limbo? It will likely end up being a filter for people who have no other options available to them.
Some places do that, and they're generally not places you'd like to work for.
Places that cold-call will do bulk hirings with the expectation that most people will leave. A lot of the time these arrangements allow employers to force a lot of work out of their employees with questionable tactics.
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.
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.