5 ms·
As someone who has not yet worked professionally as a programmer (nor hired one), I might not be the best person to comment on this article (so take what I writ
by shioyama 15y ago
As someone who has not yet worked professionally as a programmer (nor hired one), I might not be the best person to comment on this article (so take what I write with a grain of salt). But as someone aspiring to do so, I find this article and others like it on HN frustrating.
For one thing, as mbenjaminsmith noted, for small (and I'd argue medium-sized) companies, setting up so many hoops for a programmer to jump through doesn't strike me as a very smart strategy -- you'll likely end up with very few candidates. But more importantly, the "hoops" listed in the article mostly filter for a particular type of candidate. In fact, the whole "jump through hoops" approach to hiring itself frustrates me -- not because I don't think I could jump through them, but because of the place I would end up in if I did.
I come to programming with (what I consider to be) a fairly diverse background. One of the things that I immediately sense in recently having crossed over (in my free time, currently) into coding and into the profession of coding is how homogeneous the community tends to be: on the surface (for example) almost exclusively male and dominated by a relatively narrow demographic, but deeper down also lacking in a diversity of life experiences.
I would argue that the process described in this article is partly responsible for maintaining this lack of diversity, by the simple fact that it encourages the "hoops" mentality.
Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny? I have no idea. Can I find the largest int in an array? Sure, but why in the world are you asking me this?
And FizzBuzz (linked in #1): yes I get it, it's easy and it filters out 199 out of 200 candidates, but what about those 199 other candidates? Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons?
People have such a diversity of skills and experiences. Sure, a portfolio can express some of this. Selecting from your community (#3) also strikes me as very sensible. But to find the outlier candidates who have broader potential and knowledge of problems outside the "canon" of standard programming practice, I think you have to take a more open-ended approach.
In the end, I guess maybe the problem for me is that the whole "How to Hire a Programmer" idea itself strikes me as somewhat misguided. A guide to "hiring a <fill_in_the_blank>" is only ever going to filter for cookie-cutter representations of <fill_in_the_blank>, whatever that profession may be.
- jbri 15y ago> In the end, I guess maybe the problem for me is that the whole "How to Hire a Programmer" idea itself strikes me as somewhat misguided. A guide to "hiring a <fill_in_the_blank>" is only ever going to filter for cookie-cutter representations of <fill_in_the_blank>, whatever that profession may be. If your team needs a programmer, and you're looking to hire a programmer, then it doesn't matter how knowledgeable, well-rounded, or otherwise interesting someone is, if they're not actually capable of programming. I don't think anyone would consider it a failing of the interview process if they were looking for an accountant and their hiring process weeded out the people who couldn't actually do accounting.
- shioyama 15y ago> I don't think anyone would consider it a failing of the interview process if they were looking for an accountant and their hiring process weeded out the people who couldn't actually do accounting. Not to knock the accountants, but I think programming involves a lot more creativity and open-ended thinking, and I'm not at all convinced that a focus on "hoop"-like testing brings out those aspects of a potential candidate. (As noted in my other replies, I didn't mean to imply that programming skills are not important for a programmer to have.)
- nandemo 15y ago> Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny? I have no idea. Can I find the largest int in an array? Sure, but why in the world are you asking me this? The first question is silly. It's probably intended as a shibboleth, but it's a pretty useless one: people who can answer it probably understand what is octal/decimal/hex, but lots of people who do know octal/decimal/hex have never heard of that silly joke. The second question is very easy and it's good as a first filter: if you can't answer it then it's very very likely you cannot code. They're asking it because there are indeed people who interview for that position yet cannot answer it. > And FizzBuzz (linked in #1): yes I get it, it's easy and it filters out 199 out of 200 candidates, but what about those 199 other candidates? Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons? I think the 1/200 ratio is rather hyperbolic and not based on any actual data. In my experience interviewing candidates for a not very well-known company (so we didn't have 1000s of candidates for every position, more like dozens), more than 2/3 of the candidates would pass the really easy questions. But yes, if the candidate fails Fizzbuzz then it's probably pointless to continue the interview. Of course the candidate might have other skills, but we're talking about interviewing for a programmer position.