TL;DR
http://raganwald.posterous.com/why-i-downvote-tldr-comments-...
Thanks for telling me, so I could give this guy an upvote to counter :)
I don't hire unlucky people
131–140 of 281 posts
Re: I don't hire unlucky people
#132Just this morning, I was thinking about metrics. It should be possible to develop a set of metrics for code quality that would apply to apps using particular languages and libraries. These metrics would be general and very imperfect, but they would still have some utility. For example, it would be fairly easy to develop an automated metrics program to run on a given Ruby on Rails app. Things like depth of nesting in…
Probably really easy to go overboard with that but interesting idea.
http://en.wikipedia.org/wiki/Cyclomatic_complexity#Correlati...
Lower lines of code definitely correlates with lower defect count.
Re: I don't hire unlucky people
#133Just this morning, I was thinking about metrics. It should be possible to develop a set of metrics for code quality that would apply to apps using particular languages and libraries. These metrics would be general and very imperfect, but they would still have some utility. For example, it would be fairly easy to develop an automated metrics program to run on a given Ruby on Rails app. Things like depth of nesting in…
[deleted]
Re: I don't hire unlucky people
#134Earlier quoted context omitted.
> Ironically, a job seeker that rejects an ad based on a keyword or two is exactly the shallow reasoning this article criticizes; it's just the other side of the same coin. Not really. The situations are asymmetric -- an employer seeking a talented programmer needs to be rejecting potential employees on as few arbitrary criteria as possible, to maximize their chance at finding just a single qualified candidate. A tal…
> You need to winnow out any opportunity that is even the slightest bit unappealing just to get the flood down to a manageable level. This is precisely what the article was talking about but in reverse, like the GP said. You're implying that job ads that rub you the wrong way on a minor point are ads that are at the bottom of the desirability list -- this is the exactly the correlation/causation fallacy the article d…
> You're implying that job ads that rub you the wrong way on a minor point are ads that are at the bottom of the desirability list -- this is the exactly the correlation/causation fallacy the article discussed.
You've misunderstood.
The employer faces the problem of there being too few really good programmers, and so must do nothing that would prevent them from possibly seeing one in their candidate pool. It's like panning for gold; you need to get as much crap as possible going through your pan to find anything of value.
The good programmer has an entirely different problem. There are a ton of jobs out there that I would find stimulating, engaging, and fun. Finding them isn't hard at all. They show up on HN, they show up in my inbox, they show up in conversations at conferences and events, they show up in unsolicited offers from friends, acquaintances, headhunters, etc. They show up on a weekly basis.
If I'm in the market for a job, I don't need to carefully grovel through every opportunity to find the one good one. I couldn't possibly, even if I wanted to, because my attention isn't infinite. Talking with every potentially interesting employer would take more hours than I have in the day.
Instead I need to, like Berty Wooster, somehow winnow down the 100 equally plausible opportunities to something small enough that I can reasonably give my time and attention to picking between. That the heuristics for doing so are arbitrary is irrelevant; my only concern is grossly reducing the numbers I'm dealing with, because I have no reason to fear I won't find a good one among those that are left.
Re: I don't hire unlucky people
#135You simply can't "grill everybody hard" just to test for their success. The goal just can't be to knock out "luck" totally. The problem space is just too big to handle. If you can throw out 50 people out of 100 who are very likely (let's say 90%) to not include the one you are looking for, then your chances to find the one increased from 1% to 2.25%, which is more then double your chance with 100 people and also a lot less work.
Re: I don't hire unlucky people
#136This article is superb. We tried placing ads for ninjas, rock stars, and so on, but I discovered this was the cultural equivalent of advertising for white males who drink dry martinis. Not that white males who drink dry martinis can’t do the job, but there’s no real difference between advertising for a Ninja and throwing half your resumés away because you don’t like unlucky people. Either way, you end up with fewer r…
The article is almost completely useless. It claims you shouldn't throw out resumes based on simple heuristics and stuff that only correlates with programming ability because there are so few people applying who are any good, but has exactly one sentence to say about how to then actually find those few people: "I grill them, hard, on actual programming and actual software development." Right. Sure. Every single one o…
I'm with DarkShikari - this is a great article.
Hiring is one of the most important things for any company, at any stage, that it is worth doing right. If interviewing 100 people instead of 50 will increase overall talent, it's worth bending over backwards to do this. Even if it means sacrificing in other areas.
Ultimately, everyone ends up using heuristics at some level. But it is worth being very careful what heuristics you use, and the article does a great job of demonstrating this. Do you really want to exclude excellent developers who didn't major in CS? Do you really only want to hire engineers who self-identify as rockstars? Maybe - but be conscious about what you're doing.
Re: I don't hire unlucky people
#137Earlier quoted context omitted.
The article is almost completely useless. It claims you shouldn't throw out resumes based on simple heuristics and stuff that only correlates with programming ability because there are so few people applying who are any good, but has exactly one sentence to say about how to then actually find those few people: "I grill them, hard, on actual programming and actual software development." Right. Sure. Every single one o…
The article criticises the unquestioning use of bad heuristics. One needs to think very carefully about how accurate the heuristics employed are at describing the unseen (but directly desired) attribute(s) as well as what un-desirable attributes it may be silently signalling. As someone who worked at an investment bank, I'd go ballistic when managers would turn away candidates because their resumes weren't properly a…
Like in every skill you need to choose your heuristics carefully and like in most jobs, HR and CTOs often aren't the best. That doesn't mean the whole idea is crap.
The thing about formatting I can't answer if you are right or "most HR people" are right. The argument they bring seems as legitimate as yours: People who care about the looks of their result are more disciplined, probably faster (because they get the content and the formatting in the same time frame) and care more about working in that company. Does that sound unreasonable? Which one is right can only be told with data. And because of that I tend to support the HR guys. It's more likely (of course not 100%) they have more data and experience then you and me.
(So indirectly I also agree that work experience can be a good discriminator concerning future work quality expectations)
Re: I don't hire unlucky people
#138After a couple years trying to hire developers I feel bad heuristics have a tendency to become institutionalized if for no other reason than: if I admit this is a crap heuristic, that means I've been doing it wrong for the last 10 years--no way!
As a tangent, I find it astonishing that no one ever mentions that all these arguments are true for the guy or gal sitting across the table. She is using heuristics to find an employer based on much less information and in many cases is wrong in accepting an offer. This too has a real cost: low morale, productivity, and high turn over. I find this problem rarely discussed.
Re: I don't hire unlucky people
#139This is exactly what we've been thinking about for the last year while we've been building http://skillsapp.com . Exactly. Love it when lucid, articulate writers take my mess of a brain and put the right words to it.
Wow. That app is really bad for people like me.
I'm not on GitHub because I code for my employers. That work doesn't get put out there like that.
I don't tweet much at all about the languages I code in or cool bits of code I just wrote or any of that. I'm one of those weirdos that tweets pictures of my lunch and funny crap my 4yr old says.
I'm "on" StackOverflow since I have a log in... but I rarely comment on stuff and have never posted a question. I probably should I suppose but I don't.
I don't think my candidate brief on Skills would be a very accurate indicator of my actual skills.
Re: I don't hire unlucky people
#140Earlier quoted context omitted.
That is not true at all schools in the US. At least not when I applied around 10 years ago. A lot of schools, especially the top tier CS programs told me that I would not be allowed to go in undeclared and then transfer into their CS program. I had to declare as a CS or I wouldn't get in. I knew some people were able to get away with not declaring and transferring in but I didn't want to risk it.
10 years exactly, or a bit more than that? The reason I asked is that CS enrollment changed dramatically after the .com bubble burst. When I applied to CS a little more than 10 years ago the bubble was in full swing, and only the top 1/4 of applicants to the program had a hope of getting in. Transferring in was a no-go. 2 years later enrollment had dropped so low that the quotas were gone and transferring in was easy…
I tried to transfer into CS in 2004. The policies from the bubble had not yet been revised and so it wasn't possible. I received a degree in "interdisciplinary sciences" but had all the credits required for a CS degree (and only 4 credits shy of a physics minor, which was my original major).