Comment by wheels | Hacker News Reader

Comment by wheels | Hacker News Reader

I call BS on this one. I'd even say that this will filter out the top level of folks (†).

If you give me a synthetic puzzle to solve I wouldn't bother applying to your organization. It's much better to craft a problem to the specific domain that your company is dealing with. Then you can test for both domain expertise and problem solving ability in one fell swoop with the extra bonus of it not seeming pointless.

† The important addendum on this is that you're not going to have the top level of folks sending out blind applications unless that person is in the process of making a lateral jump into another sub-field. And even then probably not. But if you give a top applicant a synthetic puzzle after your recruiting contacts them, expect a large portion of them to thumb their nose at you. Similar note on top folks, though this is mostly pedantry -- the top OSS projects aren't on GitHub and similar. The largest and most prestigious of the OSS projects host their repos themselves.

To clarify, I wasn't discussing recruiting Linus or Guido.

I'm actually more likely to apply if there is a puzzle. I've sent a few resumes out blindly, it usually goes into the black hole. If there is a puzzle, I figure my odds of getting a response (assuming I get it right) go way up.

Of course, if a correct solution results in a recruiter replying and asking me to submit to resumator, I'm probably ignoring your company in the future. (Yes, this happened to me once.)

"Not trying to hire Linus" is a bit of a straw-man. There are a lot of folks that fall between "Linus" and "have to actively look for a job". Probably tens of thousands of people in the programming field.

The important point that I'm getting at, however, is that the dynamics of hiring shift dramatically as you move up the skill / connectedness scale. As you move towards the higher percentages potential employees are not competing for employers, but employers are competing for hires. And the dynamics of hiring are dramatically different at that point. If you're designing heuristics for hiring, you don't want to create a low-pass filter, and I believe that synthetic puzzles are exactly that.

The point of raganwald's post was on the surprisingly high cost of false-negatives. What I'm postulating is that your suggestion is just yet another way to reduce the false-positives rather than a way to reduce the false-negatives.

If it increased the number of overall respondents as well as the number of respondents who were above a certain bar (passed a phone screen), then even if it created other false negatives, it still seems to have helped.

Good developers don't just go around submitting their resumes to every job in existence, and not filtering out false negatives was insufficient in and of itself to produce a good applicant pool. If doing something that produces false negatives (which, yes, are undesirable) nevertheless convinces enough developers to consider your company who never would have considered it otherwise, then it seems like the advantages have outweighed the disadvantages.

Obviously, an even better scenario would be to produce the same level of developer interest without also producing any false negatives. Perhaps by investing sufficient resources in networking or in making his company famous to other developers, he could accomplish this. This would still be a possibility to explore in the future.

But just because his tactic has not produced the best possible outcome does not mean it has not produced a positive one.

I don't understand. He tried one approach that didn't get many good candidates as a percentage of total applicants. He tried another approach and got more candidates with a higher percentage of good ones. One sample is far from conclusive but I don't see any BS here. Maybe its not an optimal solution for all top-level candidates but that doesn't mean its not a sufficiently good one for many.

Exactly. There's nothing stopping OP from using this method to get a bunch of applicants while also using other networking methods to reach out to the current top talent.

Most top level folks rarely respond to job ads, as they tend to get hired away before they'd realized they were ready to move, so I wouldn't worry too much about filtering them out in the first place.

"the top OSS projects aren't on GitHub and similar"

True, however if you're a contributor to a top OSS project, you'd tell me that when you apply, and send me an example of one of your contributions that you're particularly proud of (at least I hope you do, otherwise I won't know!)

Puzzles and challenges are useful when the candidate doesn't have any good examples of their work that they're at liberty to share with you. I'm very wary of hiring someone without seeing any of their work. We've been taking this approach for awhile now, and it's worked out well for us.

Why do these "top applicants" not want to do coding pre-screens? If I do a coding pre-screen, it means I will get to work with only people who are capable of doing it. That bar may be high or low, but it is often better than a bar that does not involve any actual programming. It also means that I won't spend a huge proportion of my time with the company talking on the phone to people who can't fizzbuzz, which is a pretty good perk if you ask me.

So far, 2 of 4 companies I have applied to have had a coding pre-screen and 1 of 2 companies that I have worked for have had a coding pre-screen.

>the top OSS projects aren't on GitHub and similar

Hmm?

https://github.com/torvalds/linux

https://github.com/rails/rails

https://github.com/ry/node

https://github.com/jquery/jquery

https://github.com/twitter/bootstrap

https://github.com/symfony/symfony

I can't tell if you're being intentionally dense or just naive.

Linus copied the kernel tree to GitHub when the kernel git repo was compromised. It is not the main repo. Of the others, only Rails and JQuery could even be reasonably be called "top" projects (Bootstrap? Seriously, you list a 7 month old project with 2000 commits?) and even those are a stretch. Major projects are well into the hundreds of thousands of commits. It's ludicrous to even muse of Bootstrap being in the same league as e.g. Mozilla, WebKit, et al.

Why am I either naive or dense? I was just pointing out some obviously large and important OSS projects on github.

"Top" projects are better defined by the number of users than the number of commits. By this standard, Bootstrap is a very successful project.

If you define success by the number of people who have actually checked out and built the code, Bootstrap is vastly more successful than Mozilla & WebKit.

Reply on news.ycombinator.com