Hirewolf: The pitfalls of hiring filters
hirewolf.com
hirewolf.com
Sure, you shouldn't hire a developer merely because he went to the right schools and did well, but I can say with some certainty that if you compare candidates who went to good schools and got good grades with candidates who went to lesser schools and got poor grades, the former will as a whole be much stronger.
While you will hire some bad candidates and skip some good candidates if you work this way, your strategy will be pretty close to optimal. Some very successful companies have been using this strategy for many years.
With that said, if this company thinks they have a better way to do things, they are welcome to give it a try. If they can improve hiring even a little bit (either in improving the positive or negative filter), I'm sure there is money in it for them.
Nope. I know developers who don't even have degrees that you'd be /crazy/ to ignore.
On the average you will do pretty well with your "good school, good grades" strategy. However, I believe you will miss out on the occasional truly extraordinary candidate, the one that was bored with school and quit to do Neat Stuff.
But (you may argue) these people are prima-donnas, or easily-distracted flakes, or won't fit in culturally, or they don't bathe. Or something.
Look at their track record /outside of school/ and see if they did indeed do anything Really Neat. If not, they were fooling themselves. But if there's evidence to the contrary, you're crazy to ignore it.
Frankly, I don't even look at the education history any more. It doesn't tell me anything. I'm far more interested in what projects they've done and their exposure to computer science and software engineering than what dorm they had an opportunity to occupy.
I wonder what percentage of say, Google engineers have public open source projects?
After a hard day of work coding, I'd much rather, for instance, spend the evening reading Russell and Norvig's AI book and working on the problems therein to learn in depth the things that were covered in an introductory fashion in the online Stanford AI class, than dabbling in some open source project (and the often associated social drama).
I've got a lot of books besides that one that need more attention.
And in any case the subject at hand is identifying good developers. They aren't paying you to read books, they want to know if you can produce software. If you want to show them that you can, then producing software is an awfully good way to do that.
However, that is going to tend to teach you things that are narrowly focused on the needs of that project.
For example, there are several occasions in my career where it would have been very helpful to know more about statistics than I do. I have learned some by taking open source projects that needed to do the same kind of statistical test I needed and studying their code, and adapting it for my needs (unfortunately my needs were sufficiently different from those of the open source project that nothing worth contributing back came out of my adaptations). However, what I learned there was how to do certain specific things in certain specific situations. I did not learn the boundaries of when those specific techniques are appropriate, nor did I acquire an understanding of WHY we use those techniques.
It would be much more productive overall if I were to sit down with a good textbook on statistics and study it, cover to cover, as if I were back in school. That will overall improve me in this area far more than looking at open source projects (or closed source projects) that happen to do some statistical calculation.
I aspire to be more than a coder just coding up implementations of things where others have done the deep thought. I aspire to be like a Knuth or a Dan Bernstein, who can code well but who has a deep and broad understanding of the theory behind what he codes and why it is being coded that way.
If you stick to people who do a lot with open source because open-source measurement is all you can do, you're going to miss out on people who have been studying certain deep, interesting things, because while open source is great for general-purpose computer programming practice, it can be a lousy place to play with advanced, in-depth computer science.
For the projects I tend to work on, reading 100s of pages of documentation is necessary. To create a good solution, I must understand the domain well. I spend many evenings reading books on kernel construction, networking, algorithms and so on. This is improving me technically. When I go into work, the knowledge then helps to make better software.
But the GP post seemed to be arguing the opposite: that focusing your effort and learning on a practical goal was not a way to "improve yourself technically". And that's the part that lost me.
About ten years ago I read a bunch of books on MPEG2/4 and some other video-related stuff. I wasn't doing much in the field, it just seemed interesting. Eight years later it turned out that the project I was on needed this type of expertise, so I was able to contribute on stuff that people hadn't expected me to be able to. It was fun.
You can't easily foresee this kind of thing. I'll probably never need to know the details of how Vax/VMS did its free page management, but I might run into a related problem, so reading that OS book 25 years ago might pay off.
What I see from people who /just code/ is that their skills rot far faster than people who like to learn stuff. If all you do is code, after ten years you have another 100KSLOCs of Java or C++ or SCHLOPBOL under your belt . . . and who cares?
I like to learn stuff and hopefully get a chance to apply it. Otherwise I'm just a garage mechanic who fixes bicycles in my spare time.
I came up with ZERO.
As much as this service probably tries to harvest social media information about the developers a company might want to hire, most of my developer friends are VERY social media agnostic. They don't like it, won't use it, and most of the time, don't want people to know what they're working on in their spare time.
>> Google engineers have public open source projects?
At the same time you are also expected to be doing great things on your 80% job, surrounded by brilliant people who are also doing great things.
I can't speak for Steve Yegge, but the energy that he put into blogging before going to Google seems to not be available now (unless he is getting internal pressure to blog less).
While you seem to be targetting startups (which often have little money and maybe, just maybe, think they don't need the outside help), I'd consider the rest of the employer spectrum right up to the BDM's (big dumb companies). You could pitch it as similar to a background check but instead of looking for criminal history, you're digging into past performance.
Our biggest hope is that Hirewolf will be able to help highlight candidates that our other recruitment channels aren't picking up -- not just great coders from great schools, but killer coders with unknown pedigrees.
How long before a startup named Hiresheep figures out how to game their metrics, and sells it as a service?
So good luck!
Definite room for improvement but I'd hate to be passed over because a potential employer doesn't have a complete picture.
Basically, why should a hiring company use you over tools all ready available?