Slashdot Mirror
Skipping Traditional Recruitment, Going Straight To the Source
theodp writes "Out of necessity, reports Slate, tech startups are changing the way workers are screened and hired. Take database technology startup RethinkDB, whose old-school recruiting effort — job boards, external recruiters — yielded hundreds of resumes, dozens of phone screens, and numerous four-hour meetings with viable candidates, but no one who fit their criteria. 'They [recruiters] can't tell the difference between the competent ones and the stars,' complained Y Combinator's Paul Graham. Instead, the RethinkDB founders turned to sites like Github.com and stackoverflow.com to pick up six people (they're still looking), a mix of full-timers and interns, both senior and junior. 'You can see the code being written and how technically accurate they are,' explained RethinkDB's Michael Glukhovsky."
I'm 20 year old software engineering student and my resume... I wouldn't perhaps say that it is full of lies but I know that it is full of exaggerations. Gross ones. For example, I list Python under my skills even though my knowledge of it is pretty much limited to one course I took.
I don't like doing that but feel that I am expected to do that. When I browse job advertisements it is obvious that many claim to require skills you would never actually need in such a job. They have often been written by people who aren't software engineers themselves so my process goes like this:
-See a job that I think I would be skilled enough to do or learn quickly enough
-Ignore all skills they claim the job to require
-See if I can in any way justify adding them to my resume without outright lying
-Try to get to an interview and sort everything out there.
Of course, if I actually do get to an interview and there is a technical guy present and we begin discussing my skills, I will make it clear what I really can do and what I can not. If there isn't a technical guy present (IE: a mid-sized company is hiring their first in-house webmaster) I pretty much have to use my own judgement about whether I can do the job or not. That is a horrible way to do things because it sometimes wastes employers' time, etc. when I am not actually qualified to do something. But if I wouldn't do it like that, I might not even get to an interview for some job that I would be very competent at.
It pretty clear that Slava at RethinkDB is clueless about his problem. Sure, he has trouble finding top people. It apparently has never occurred to him that top people probably don't want to work there. I'm sorry, but from what I can see, it looks positively inane. My version of hell, because I like far tougher problems than can happen in that area.
Honestly, this strikes me as the narcissists' approach to interviewing. Wake up guy. You're not Bell Labs, and you're not going to get Denis Ritchie to come work for you.
There's a lot of recruiter hate going on here but it seems to miss the real problem. Having spent the last 6 years on the hiring side, it's very obvious that Jeff Atwood's FizzBuzz problem is too hard for 90% of the people applying for programming positions out there. When you end up with a situation like this, traditional hiring methods just don't work. Job board postings will get you hundreds of resumes in a single day but the quality is really crap and it is prohibitively expensive to do traditional interviews for every single resume received. HR recruiters, hated as they are, actually do provide higher quality candidates than posting on the job boards. However, it's something like an increase from 1% quality candidates to 5% quality. Still very poor.
We've ended up using a multi-prong approach to hiring ourselves. Besides using recruiters and posting to SIG boards, we've also optimized our candidate screening to handle the flood that comes in from job board postings. Since you can't tell much from resumes (some candidates lie, but an amazing number of good developers are also very bad at writing resumes), we try to call in all but the worst of the resumes received. Then we sit them through an automated testing system (we use Codility). Candidates that pass the equivalent of the FizzBuzz problem are then interviewed by technical interviewers that go over the code with them detail and attempt to thoroughly assess their true skill level. That automated testing step filters out the equivalent of 90% of our candidates, resulting in an almost 90% savings in our HR costs. It's very expensive to have good technical people spending hours interviewing after all, and they tend to hate it anyway.
It's not perfect. There are of course great people who get rejected or who even refuse to take an automated test. However, automated candidate testing means the difference between our top technical people spending 10% of their time interviewing or 100% of their time interviewing. With the scarcity of really good technical talent, we obviously chose to optimize our techie time.
All that is well and good, but it ignores my key point - the vast majority of IT failures have nothing to do with people's technical skills, but management's failure to communicate. Technical skills can be acquired (and when you're developing new technology, obviously it's the only way to go, since there is no prior art, etc.) - communications skills, obviously not so easily.
The use of extensive testing is an easy way to cover up for the lack of a proper way to assess the more important aspect - is the person a good communicator? Not in the "marketing/powerpoint/bs" fashion, but can they take a concept and teach it to someone else on the team?
Stick them in front of a whiteboard and have them give a talk about something. Did you understand it? If so, they've demonstrated 4 things - that they know it, that they know it well enough to explain it to others, and that others can understand their style of communicating, and that they also know how to listen (more on that in a sec).
15 minutes to a half-hour should be all that's needed. If they wash out on communications skills, then it doesn't matter how hot-shot prima donna they are with code. If they're good communicators, they got that way by listening to others, and adapting their "pitch" to the abilities of their audience.
It's a simple test, with a simple pass/fail standard - did you understand what they were talking about? If they bored the crap out of you, they're a poor communicator. If they kept having to pause for 15 seconds to 1 minute to "fill the pipeline", they're not really on top of the subject matter, so you've also eliminated the "BS-ers".
You also get to see if they're really enthusiastic about what they do, or if it's just a job, so you cover the "desperate for a job" motivation as well - someone who's enthusiastic will easily be able to go beyond the 15-30 minutes. It also lets you see if anyone else in the room is not going to be a good fit, personality-wise, during any Q and A. Do they get into a "pissing match?" If so, who started it, and how did the other person handle it? (You might want to have a "plant" for doing exactly that).
Of course, this is just too simple and obvious, just like using two screens is a simple and obvious way to improve productivity, from secretaries to coders and everyone else, but most companies won't do it.
Fear. They'd rather trust in some mythical scores so that if it doesn't work out they can CYA by saying "the checkboxes looked good." Do we pick our other relationships like that? I hope not - and work is just as much a relationship as any other.