I 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?
It is really true. As you would know if you'd been on a team that needed to fire the wrong hire.
As for why not to try people before you hire them, a lot of experienced people already have jobs. They aren't going to want to accept a "maybe yes, maybe no" position without a really strong incentive.
That said, a number of companies do have policies of liking to hire contractors, then make some of them permanent. This kind of works. But the best contractors they'll find generally are contractors from choice, and so aren't likely to want to make the transition.
To me, this is one of the big unspoken about benefits of working in a startup. There is no room for slack and if someone isn't doing their job it's immediately apparent. Nothing kills my motivation more than working with someone who is technically incompetent and/or generally unpleasant to be around.
Our interview process mostly consists of asking you questions you should know the answer to. If your answers make sense and you seem pleasant, welcome to the team. Oh, did I mention you'll probably make twice as much here than at Google?
Incidentally, more people want to work at Google than want to work at Bank of America, even though there is plenty of interesting code to write at the Bank, and plenty of boring paperwork to do at Google. It doesn't make sense to me.
There are something like 70,000 developers and 300,000 total employees, so it's hard to say anything other than "all of the above".
I mostly use Haskell and Perl. The rest of the department is mostly Perl. Sometimes I do C. Other groups are Python-heavy. There is a big Java and C# presence, and of course a lot of people that think C++ is the only real programming language.
There is some initiative to standardize on C++ and Python, but I doubt that is ever actually going to happen.
I recently went through financial difficulties that involved problems paying 5 different credit cards. Bank of America was by far the most helpful company, actually recommending that I enter into debt management to allow me to pay off my cards at a markedly lower APR without taking a huge hit to my credit.
Without getting into the evil/not evil argument: This is not quite correct. A bank can lend more money than they have/borrow. The bank must only maintain a specific ratio of equity and loans. For more details see Basel I, Basel II and the upcoming Basel III, which (should) regulate the loans of banks.
> 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.
Maybe 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.
Reminds 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.
As a bartender and a valet, I've easily averaged $15-25 an hour. Right now I'm making $25 an hour when I'm billing, and once I get home I'm not in the mood to do much computer work. Additionally, you can find service jobs anywhere, and start up very quickly.
I'd rather have the flexibility to move anywhere, the stimulation of constantly meeting new people, and some leftover desire for personal projects when I get home than to have a programming job I don't like.
Fair enough. Note that I'm not looking down on your choice of jobs (recently I've been thinking it would be cool to get a part time job as bartender but it's not feasible now) but I suppose they inevitably come with some hassle and that will be worse over time than the one-time hassle of the interviews. Besides I assumed your programming job would pay much more (well, it should).
This 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?
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.
This 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.
Not 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]
Lots 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.
Ah, 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.
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
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.
