Slashdot Mirror
Hiring Developers By Algorithm
Strudelkugel writes in with a story about how big data is being used to recruit workers. "When the e-mail came out of the blue last summer, offering a shot as a programmer at a San Francisco start-up, Jade Dominguez, 26, was living off credit card debt in a rental in South Pasadena, Calif., while he taught himself programming. He had been an average student in high school and hadn't bothered with college, but someone, somewhere out there in the cloud, thought that he might be brilliant, or at least a diamond in the rough. 'The traditional markers people use for hiring can be wrong, profoundly wrong,' says Vivienne Ming, the chief scientist at Gild since late last year. That someone was Luca Bonmassar. He had discovered Mr. Dominguez by using a technology that raises important questions about how people are recruited and hired, and whether great talent is being overlooked along the way."
Whoosh. I think the whole point is that having a phd isn't the best measure of anything. I've worked with phds and high school dropouts and I've never noticed any difference except that the dropouts are less entitled.
It's not just that, though. The interviews based around brain teasers or algorithms that very few people use in real life, which are supposedly used to see how the candidate thinks, are generally extremely biased towards people who either just got out of school or spent a lot of time studying for those sorts of questions. Neither of those things have much, if anything, to do with predicting job success.
At my old job, we had a pretty revolutionary strategy for picking someone: We talked with them. You can see who's in over their head very quickly, and the interviews at least seems like a lot less pressure because we shot the shit about programming and past jobs. There was no requirement or bias towards you reading otherwise useless brain teaser books, no requirement that you have to memorize all the terms from gang of four, etc. We had a great track record with our hiring. It amazes me more companies haven't tried of this method.
At my old job, we had a pretty revolutionary strategy for picking someone: We talked with them.
I've always done that too. Just get the interviewee to talk about their work, what was interesting about, the problems they encountered, etc. If a person doesn't know their stuff they won't be able to talk about it intelligently. Some people you have to coax out of their shell a bit, but that's it. If a person is reluctant I'll even ask them to pick something out of their resume to talk about instead of me suggesting a topic. I accept that most resumes have some exaggerations in them, so just let them pick something that isn't exaggerated. Also talk to them about the project they're being hired for, see what kind of questions or suggestions they have, etc.
It's purposely a low pressure technique. Some very good technical people don't do well being drilled about nonsense or brainteasers, or clam up if the interviewer starts playing Mr. Tough Guy and tries to trip them up on everything. Remember, you're trying to hire good technical people, not good interviewees. For other type of work this technique might suck.
It amazes me more companies haven't tried of this method.
Too simple and obvious - takes away the mystique of being a great interviewer. Also you've got to know your stuff to use the technique.
No one is good at everything
I've worked with legendary programmers throughout my career and I can tell you this --- you must understand the strong points of a particular programmer (even the legendary ones) so that you can tap into his potential and let him/her perform
That "hiring by algorithm" is indeed a new way of looking at things, but it does take experience - excellent programmers all comes with their own particular quirks - and you need to provide them the room to stretch, the freedom that they need, in order to get them to do whatever they are good at
Muchas Gracias, Señor Edward Snowden !
We're Artisans - not engineers.
As an electrical engineer I can assure you that engineers largely work the same way. And the job titles that they're always playing with are ridiculous. Programmer, system analyst, software engineer, computer scientist, blah, blah, blah. Please, nobody try to educate me on the fine distinctions. I know them, I don't care, and I think anybody who really does care is either a stuck-up ass or so insecure about their abilities that they cling to buzzwords. At least EE's just call themselves EE's (and I've never met anybody who bothered to distinguish between electrical engineer and electronic engineer). The best programmer I ever knew (who also had a Ph.D. in CS from a fancy school) simply called himself a programmer.
So, at my previous job (at a games company) I regularly worked 8.30 till 8 or 9pm. I'd get home at 10, eat, workout a little, then go to bed. I often worked full weekends (crunch time) and there was no way I could ever code outside of work, I was simply too burned out. In fact, I barely had time to do much else other than eat, sleep, and do chores. As such, if someone tried to find any open source work done by me, well, there is none, but that doesn't mean I can't program.
I kind of hate this recent assumption that all open-source programmers with work on github must be programming geniuses.
Depending somewhat on the kind of company doing the hiring, the prospective new hire shouldn't just be evaluated for the job at hand, but also for how well they'd do at other jobs, both at and above their current level. This means testing for adaptability, versatility and future potential. This, by the way, is where I find that people with college degrees far outperform self taught high school dropout programmers.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Disclaimer: I'm a high-school dropout.
Theoretically, hiring a PhD would give you some guarantee about what the programmer is capable of doing - you can expect him to know not only how 2nd degree equations work, but also the basics of transcendental functions and how to apply base concepts into real-life problems. Theoretically. In practice, shure, maybe most dropouts don't have the basis to understand a lot of stuff - but many PhDs don't understand it either. And some of them, while understanding it, are unable to put in in practice.
I'm one of the few (only?) completely self-taught developers on the company I work for (>100 developers). For most tasks, no "special" knowledge is needed - a monkey could do it. Even so, some academic folks struggle with concepts. For non-trivial, conceptual tasks, I'm usually at the top of the list of the guys to ask stuff. I've done stuff ranging from math coprocessor emulation to signal processing, image processing, 3d programming, embedded systems, compression algorithms, data processing/mining, etc. I'm probably not better than a good PhD (or a guy like me with proper academic background), but I'm way better than *a lot* of median ones.
I would recommend to anyone that wants to be serious either in programming or CS to get a degree - proper mathematics is something that is usually hard to learn without a teacher - but having expectations on a guy just because he has a degree is just stupid. As it is having great expectations regarding a high-school dropout.