3 ms·

If their blog is to be believed, that bunch of brainless drones represents 0.5% of the applicants. I find it hard to imagine that the best talent in the market

If their blog is to be believed, that bunch of brainless drones represents 0.5% of the applicants. I find it hard to imagine that the best talent in the market would get those questions wrong, though in spirit I agree with you.

InclinedPlane 15y ago
It's easy to monday morning quarterback and say "oh, OF COURSE any competent dev. should know all this inside and out, it's basic stuff from 200 series CS courses, if that". But that misses the mark. For one, it's enormously Java specific. For another, some of it isn't very relevant to most coding. How often is it really necessary to code an abstract class in Java? How often is it really necessary to know all the trivia of protected access? This ranks pretty high on the least useful knowledge that you could probe for in a developer. The only reason it's even remotely successful is probably because there's a general correlation between experienced coders and coders who know these subjects well. But it's nowhere near a perfect correlation, you can be certain of that. It will eliminate people with talent and select for people who know trivia but lack talent. Imagine it like this, you spend several weeks and thousands of dollars courting potential candidates for the love of your life. And on your ultimate date you ask them what their favorite band is and move on or forward based on their answer. Reality is a lot more complicated than that. Try this test at your work. Identify your developer coworkers who you look up to, and come up with equivalent topics for their coding platform of choice then randomly ask them about them. For example, drop by and say something like "hey, I always forget, could you explain abstract classes to me?" Or something like that. I'd be curious what the results were.
- fusiongyro 15y ago
  Let's make some distinctions. I'm not saying this is the ideal way to hire. I also dislike recruiters, and Java for that matter. But I don't find this practice indefensible, because: 1. Whenever you open a position, you get a ton of applicants that simply aren't qualified, and the faster you get rid of them the better. 2. A majority of programming jobs use Java, C# or C++, which all have 4 or 5 of these keywords with similar meaning. This is a quick and easy filter. Of course, any quick and easy filter is going to have a false negative rate, and it's fair to protest that. Fundamentally, hiring programmers by their programming language competencies is also a very poor idea. But there are a lot of places that simply need a bunch of competent cogs and I don't think it's worth getting too worked up over the unintended negative consequences of their poor decisions. They want a ton of cogs, this is a great way to get a ton of cogs. You're not a cog and neither am I. I don't think either of us would want one of these "supercoder" jobs anyway.

InclinedPlane 15y ago

It's easy to monday morning quarterback and say "oh, OF COURSE any competent dev. should know all this inside and out, it's basic stuff from 200 series CS courses, if that". But that misses the mark. For one, it's enormously Java specific. For another, some of it isn't very relevant to most coding. How often is it really necessary to code an abstract class in Java? How often is it really necessary to know all the trivia of protected access? This ranks pretty high on the least useful knowledge that you could probe for in a developer. The only reason it's even remotely successful is probably because there's a general correlation between experienced coders and coders who know these subjects well. But it's nowhere near a perfect correlation, you can be certain of that. It will eliminate people with talent and select for people who know trivia but lack talent. Imagine it like this, you spend several weeks and thousands of dollars courting potential candidates for the love of your life. And on your ultimate date you ask them what their favorite band is and move on or forward based on their answer. Reality is a lot more complicated than that. Try this test at your work. Identify your developer coworkers who you look up to, and come up with equivalent topics for their coding platform of choice then randomly ask them about them. For example, drop by and say something like "hey, I always forget, could you explain abstract classes to me?" Or something like that. I'd be curious what the results were.

fusiongyro 15y ago
Let's make some distinctions. I'm not saying this is the ideal way to hire. I also dislike recruiters, and Java for that matter. But I don't find this practice indefensible, because: 1. Whenever you open a position, you get a ton of applicants that simply aren't qualified, and the faster you get rid of them the better. 2. A majority of programming jobs use Java, C# or C++, which all have 4 or 5 of these keywords with similar meaning. This is a quick and easy filter. Of course, any quick and easy filter is going to have a false negative rate, and it's fair to protest that. Fundamentally, hiring programmers by their programming language competencies is also a very poor idea. But there are a lot of places that simply need a bunch of competent cogs and I don't think it's worth getting too worked up over the unintended negative consequences of their poor decisions. They want a ton of cogs, this is a great way to get a ton of cogs. You're not a cog and neither am I. I don't think either of us would want one of these "supercoder" jobs anyway.