8 ms·
I interviewed with Google for a SRE position earlier this year and their screening process sure is tedious: Lots of grilling on obscure UNIX trivia and data str
by bnoordhuis 16y ago
I interviewed with Google for a SRE position earlier this year and their screening process sure is tedious: Lots of grilling on obscure UNIX trivia and data structures/algorithms but nothing on the broader picture, like how to write good, maintainable software. I like nerding about graph traversal algos as much as the next guy, but not for 90 minutes on the phone after a long day of work.
I'm sure the screening process filters out duds but it's bound to generate a lot of false negatives as well. People that would otherwise be a perfect fit but who get fed up with the interminable interviewing or simply don't do well under that kind of stress (for me it was both).
- deleted 16y ago[deleted]
- amichail 16y agoMaybe they didn't have people readily available to interview you on topics more relevant to your position. Or maybe they care more about IQ and the sort of interview you got is better at estimating IQ.
- harryh 16y agoFalse positives are way worse for most companies than false negatives. Interviews processes are generally designed around this principle.
- wheaties 16y agoThey've actually said as much. They understand that their process generates false negatives but they don't want any "crud."
- sabat 16y agoLots of grilling on obscure UNIX trivia and data structures/algorithms but nothing on the broader picture They understand that their process generates false negatives but they don't want any "crud." But quizzing on random trivia is irrelevant to the process of eliminating crud. It's quite likely that a cruddy performer will be able to rattle off all known sorting algorithms or all the option flags for GNU grep -- that has absolutely no bearing on true intelligence or any of the other qualities that Google professes to be interested in. Having some insider's knowledge of Google: the process does not appear to be working. There is a lot of crud in there now, and the crud only seems intent on hiring more crud. Lots of power struggles and posturing; less and less innovative thinking.
- X-Istence 16y agoAh, but this is not your normal unix trivia, the questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem and other questions along those lines. This is not just flags to give to a process to make it do something, this is system internals. When I mentioned that I knew FreeBSD fairly well I was asked questions specifically about UFS and the likes. I never did get asked about flags to grep and other UNIX tools.
- sabat 16y agothe questions I were asked were stuff like what is an inode, where are inodes stored, what is a scheduler, what is the difference between /dev/mem and /dev/kmem Precisely what I mean by unix trivia. What's the difference between /dev/mem and /dev/kmem? I think it's memory vs kernel reserved memory, but in my 16 years as a unix admin I have never once needed to know that. If I did, I'd go look it up. That is why I consider those questions trivial: they're not fundamental, although you can make them sound like they must be.
- smokinn 16y agoExactly. They've also said that their high false negative rate is why they clear out their records every couple of years. If you got rejected a couple years ago you can apply again and they won't be looking at your previous attempt's performance.
- illumin8 16y agoThis is the first time I've heard of this. I interviewed back in 2007 for SRE, and again in 2010 for SRE. I was told "we'll keep your resume in our database and let you know if anything comes up." It kind of goes against Google's entire corporate culture to ever delete information like this. Sometimes I wondered if their interview process isn't designed more as a data mining process to find out what interesting things technology leaders are working on. What Google should do if they want to hire really good candidates is to go with a contract to hire approach. Find good candidates, do one phone interview and a second in-person interview in the space of a few days (not 4 or 5, stretched out over months). If they pass your initial 2 interviews, hire them as a 6 month contractor. See how much they accomplish in 6 months. If they are contributing and integrating effectively, hire them full time. If not, just wish them the best and don't renew their contract. This is the way it works in most effective large companies. The cream that rises to the top gets offered a full time job within a 6 month to 2 year timeframe. My current job is like that. I've worked there for 4 years and started as a contractor. It became so expensive to pay my hourly rate that they were begging me to become full time after a while. I was doing a valuable job for them and was very effective at it, so I got the full time offer.
- LiveTheDream 16y agoNot to mention that in a couple years you can become a much stronger hire anyway, especially early in your career going from 0 experience to 2 years. Experience = Time * Density [1] [1] http://stevehanov.ca/blog/index.php?id=105 http://stevehanov.ca/blog/index.php?id=105
- BrandonM 16y agoI see lots of assertions to this effect. Is it really true? One point that no one seems to consider is that frustrating interview processes are a big contributor to smaller applicant pools; that is, a would-be good employee has applied a couple places, been filtered out by false negatives, and is thus disincentivized from even continuing to look for a better programming job. Personally, I don't like my current job but am growing frustrated with job hunting. I'm very close to just looking for a bartending job to go along with the part-time valet work that I picked up between jobs, and then maybe doing hobby programming in my spare time for pleasure and profit. I'm serious here: ridiculous interview processes are making the quality of the programmer pool worse by nudging programmers out of it altogether. Why is it so unreasonable to bring people in on an intern-like trial basis?
- greg_holsclaw 16y agoMaybe programmers nudged out of the process is a feature not a bug. People who self select out of a hard hiring process may meet not Google's criteria for certain attributes they want to see in their candidate.
- dlo 16y agoReminds me of property management: When screening possible tenants, merely saying that you will conduct background and credit checks will deter some people from even applying, most of them being people you wouldn't want to rent out to anyway.
- megrimlock 16y ago> Why is it so unreasonable to bring people in on an intern-like trial basis? We do that, in addition to an interview process biased towards false negatives. We still find it expensive to make hiring mistakes, enough that we are still circumspect about candidates. Not only does it take a lot to build up someone new, it's emotionally costly to tell them at the end of the evaluation period that they didn't make the grade -- and still give them full support and a real chance the whole way, in case they can turn it around. It does happen; sometimes it just takes time for ambient culture values and priorities to sink in before people "get" what's important to succeed. It's much harder to do this trial period with option to buy, than for interns who are going back to school, where the expectations and time frame are clear. It also seems that the most capable candidates aren't as interested in being hired on a trial basis, since they have other options willing to commit more fully to them. These are a few reasons it doesn't work as well as you might hope. (* note, not talking about google here)
- arghnoname 16y agoThis is asserted as a truism, and perhaps in Google's case it is, but if the difficulty in the hiring process dissuades enough people who have other options from applying I can see it hurting the job pool. If you were to get 100 applicants, and you were only interested in hiring the top 5% (5 people), and 3 of the good people decided to accept decent jobs they could get without giving blood samples and their first born, and 20 of the less capable people decided not to bother (Incompetents don't know they are in competent and have less choices), then now you have 2 good people out of 77. Now what if one of those two is a false negative? Google is attractive enough that good people go through all the trouble anyway, but is this always true? Since we are able to fire people easily in this country, is a bad hire really so ruinous? I don't actually know the answer to the question, but I am skeptical of your statement. Maybe the assumptions in my numbers are wrong (they almost certainly are), but what are the real numbers?
- Elite 16y agoYour argument holds weight in general but Google is a special case. I'm sure they knowingly turn away bright & competent engineers simply due to the large size of the applicant pool. Smaller companies would be wise to heed your advise though.
- KaeseEs 16y agoPerhaps the position they were interviewing you for actually involved writing efficient software, and thus required thorough knowledge of the fundamentals of computer science (data structures and algorithms &c) and systems programming?
- BrandonM 16y agoAnd certainly your day-to-day work would involve answering questions about those data structures and algorithms in real time, with your future career depending on it, without external references.
- KaeseEs 16y agoIf you know something well, you can reason about it in real time. Pressure is an artifact of the interview process that is controlled primarily by the attitudes of the interviewer and interviewee regardless the subject matter. External references are useful for things you don't know cold. For something basic and fundamental to your job (eg. basic graph traversals, the suitability of a hash or a balanced BST to some lookup task, etc), you shouldn't need them; for something more arcane which is accidental rather than essential to your task, or something relatively advanced (eg. specifics of tries for incremental string operations), a competent interviewer will help you out and supply some information so that he can evaluate your ability to reason, design and code. None of these things have any bearing on whether or not it makes sense for Google to focus on knowledge of the fundamentals of computer science and systems programming in their hiring interviews.
- illumin8 16y agoI think not. Your day to day work involves sitting in front of an editor of your choice and writing code that may or may not compile or interpret properly, may or may not contain bugs, and may or may not have the correct logic. Simply having a computer at your disposal with the Internet handy, a step debugger, or the ability to run a shell or interpreter in an interactive mode puts you light years ahead of someone struggling in front of a white board trying to remember the arguments and proper order for some obscure function they haven't used in months. How many people actually solve problems in their day to day jobs without every looking anything up online? Or at least checking to make sure they are correct. Just having a syntax highlighting editor is light years ahead of a white board and dry erase marker. edit: Sorry, my sarcasm detector doesn't work. I think we're agreeing.
- lutorm 16y agoI interviewed two years ago and I think it was pretty reasonable: one 45min phone interview and two 3h on-site interviews. I interviewed for a stat position and the questions were mostly a "see how you think on your feet" problems, talking through how you would solve some problem. I thought it was quite a pleasant experience, the whiteboard-discussion style was quite similar to what we do in academic research.
- X-Istence 16y agoWhen I interviewed with them for the SRE position I was extremely nervous (I was right out of college, and Google had contacted me rather than me submitting my resume) and the guy on the other end of the phone for my first interview seemed uninterested, had a really bad quality phone (I could hardly hear his questions), and kept asking the same questions over and over in different terms, and I really couldn't figure out what he was looking for as the "right" answer. The Unix trivia was not nearly as bad, that was easy as I had done a lot of reading on it, however some of the data structures I was asked about I had never learned in school and had just read about on Wikipedia so I didn't really understand them well enough. The second interviewer was absolutely fantastic, and was genuinely interested in me as a person, had checked out my resume and looked at some of the previous projects I had done (Near Space balloon launches were discussed). I felt much more at ease, but I did seem to have somehow mixed many of the different programming languages I know (C++, C, Python, Java, F#, Scheme) thus my code was less than clean. Ultimately after 5 different phone interviews I was unfortunately told that I was not a fit, that they would keep my resume on file and that I could try for another position when I had gained some more professional experience. The Google interview did help me get through many other interviews I had the pleasure of going to. I was less likely to be caught off guard, especially since it was my first MAJOR interview with an extremely large company. I do wish that Google had not been my first interview as maybe then I would have gotten further into the hiring process and maybe just maybe I would have been working at Google. That is an awful lot of maybes and it is not worth brooding on what could have been. I am extremely happy with my current job, I love what I do and the people I work with at a small new startup. I feel with a small company I can make more of a difference.