5 ms·
> the interview process is something we won’t compromise on. Sounds like you're caught up in a big circlejerk, to be honest. Your interview process is terrible
by adbge 16y ago
> the interview process is something we won’t compromise on.
Sounds like you're caught up in a big circlejerk, to be honest. Your interview process is terrible and that's why you aren't finding any employees. You won't compromise on your process? What? You should be less worried about your process and more worried about finding quality employees (hint: your process isn't working).
Asking people to write a program over the phone isn't going to work. Have you ever written a program while on the phone? I haven't and I'm not going to. It's so far out of my comfort level that I'd probably end up looking like a moron.
Your test sounds like it's too much about what a person knows and not enough about how a person performs. You'd be much better off looking at a persons resume and, if you're satisfied with that, just talking to the person instead of worrying about whether or not they can reverse a linked list in C off the top of their head. If you want them to write you some sample code, let them do it at their leisure instead of with you breathing down their neck over the phone.
Frankly, reading about your interview approach just kind of pisses me off. What's more likely: all the candidates suck or your interview process sucks?
- starkfist 16y agoIn the OP's defense, this is how Google interviews, and they've done ok.
- chc 16y agoGoogle can afford to be ridiculous. Practically everybody would like to work for Google, so they can afford to have a high false negative rate — even if they reject 99% of good candidates, they can probably still fill their staffing needs. RandomCompanySoft, on the other hand, might only get five good candidates for a given position — so if they only recognize one out of every 10 good programmers, they can't find anybody with any skill.
- starkfist 16y agoI disagree. Google can afford to hire duds because they have infinite money. A small startup cannot afford to hire anyone they don't need. It's better to hire nobody at all than to hire someone who isn't going to work out.
- sghael 16y agoIf you are a startup, you can't afford to be NOT be "ridiculous" Possibly nothing is worse for a new tech venture than a bad hire. I've lived through a few at various startups. It's horrible. It's the worst kind of death because its often slow and painful and you're bleeding capital. Also realize that a bad/incompetent programmer is a NET NEGATIVE.... not just net 0! (obviously being 'ridiculous' is subjective, and highly dependent on the roles and responsibilities of the job). Google on the other hand actually could afford to be less ridiculous.. they just choose not to.
- chc 16y agoThis isn't about rejecting bad programmers — it's about rejecting good ones. If you can't afford a bad hire, that means you should spend more time and care trying to determine accurately whether somebody is good rather than relying on a rough heuristic with a strong negative bias — especially if you find that your heuristic is rejecting everybody.
- sghael 16y agoyou make a valid point, and i completely agree. It's about more efficiently honing in on the best candidates. And the trick is to do that early in the process, especially when the hiring process is typically front-loaded with mostly crap candidates. I've thought A LOT about this problem... so much so that my web-startup is attempting to solve one aspect of this problem (see my HN profile for the link).
- joe_bleau 16y agoI think it was in Dan Ariely's Predictably Irrational book that the story of some branch of the Israeli military came up. They only accept the absolute best applicants, but then they also accept a few that fail the admissions process. The reason is to provide a check on the process; if those admitted 'failures' work out in real life, there's something wrong with the selection process that needs to be corrected. Once big difference is that they require a certain amount of manpower, so they can't afford to throw away good material due to an inaccurate screening process. I guess in contrast Google can (probably?) afford to be wasteful.
- sgift 16y agoIf you can believe Peter Norvig maybe they do ok despite their interviews, not because of them: "One of the interesting things we've found, when trying to predict how well somebody we've hired is going to perform when we evaluate them a year or two later, is one of the best indicators of success within the company was getting the worst possible score on one of your interviews. We rank people from one to four, and if you got a one on one of your interviews, that was a really good indicator of success." http://gawker.com/5392947/googles-broken-hiring-process http://gawker.com/5392947/googles-broken-hiring-process (The first quote)
- tkahn6 16y agoThey're saying that they use http://typewith.me http://typewith.me And honestly those questions that they ask candidates seem reasonable for the type of work they're doing.
- shasta 16y ago> What's more likely: all the candidates suck or your interview process sucks? The numbers he is giving are very reasonable. Remember, that's 5% of the applicant pool that pass this test, not 5% of all programmers. It may be a bad economy, but the people looking for jobs are still skewed to the incompetent end of the spectrum. That might correspond to looking for the top 25% of programmers. I wouldn't consider anyone who couldn't come up with working code to reverse a list in an hour anything like a peer, and I'd only consider hiring them for easy work if they were cheap or had some other specific expertise.
- jrockway 16y agoI disagree with you and agree with the author. :) It's hard to find people that can answer programming questions while applying for programming jobs. People generally do OK on the "soft" questions appropriate for the phone. "Explain automatic testing." "What kind of editor / IDE do you use?" etc. People generally don't do well on simple whiteboard questions, and try to BS their way through. Our questions are very simply, along the lines of: in your favorite language, write a function to: "calculate the nth Fibonacci number" (we explain the sequence if you've forgotten), "capitalize the first character of a string", "reverse a linked list in place", and so on. The people that have been good fits for our team answered these questions without trouble. The people that hemmed and hawed and didn't get a working answer (or claimed that their favorite language already had built-in functions for each of the problems) simply didn't get hired. If people don't do well on one question, we ask more; trying to find one they can do. They usually can't do any of them. They couldn't show any ability to program, so we don't hire them to program. It's a large percentage that doesn't show any ability, but the people that do pass the interview are good to work with. I don't think it's unfair to expect people to produce code during an interview for a job where they will be producing code. Even if you're nervous, you should be able to do a little bit of your life's work, if only out of habit. You do this every day, after all! (Another thing I like to ask: after describing your grandiose project from your last job, tell us what you actually did. Oh, you wrote the build scripts, not the custom hardware for parsing FIX messages? That's fine, but why'd you tell us that the design was "ours" for the last 20 minutes? Did you think we wouldn't ask what you did? We're hiring you, not your entire team.) So anyway I think we've confirmed the OP's results. It's hard to find programmers.
- timwiseman 16y agoIt's hard to find people that can answer programming questions while applying for programming jobs. People generally do OK on the "soft" questions appropriate for the phone. "Explain automatic testing." "What kind of editor / IDE do you use?" etc. I have been surprised when doing interviews how many people fail the basic soft questions. I have had people saying they were senior programmers not know what automatic testing was and who did not understand what an IDE was at all. (I have also had people tell me they preferred simple text editors to full blown IDEs, but they always knew what they were doing.) And I concur with your basic concept. Even granted the pressure of an interview, if they cannot do the really simple stuff like fizzBuzz on the board or at least get an answer that only has minor syntax issues than I would be very dubious of their ability to program seriously.