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."
I've been programming professionally since 1994. I'm sure I'll get around to taking a computer course one of these days. My first task with any new job is "Get past the HR moron" followed by "Find someone who actually knows something." If you're lucky, this is a manager. Frequently, however, describing the code abstraction structure in your overall application design often whizzes right over a manager's head.
My suggestion? Keep it simple. Have some apps to show them, or a a web site with your latest web apps. Talk about how it solved a problem. Don't worry about the details until you get to another developer.
Please do not read this sig. Thank you.
Sorry, this article did not make it past my keyword scanning filters. Moreover, it does not have 7 years of experience to back up it's introductory claims. Since I cannot find a suitable article, I will have to source one from India.
Sounds like one more boost that will give impetus for more people to become involved in open source projects.
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.
He is the only one who reacted to the spam?
I get tons of job offers and the only algorithm they seem to be using is that I at some point in the past was looking for a job. By pure chance one will fit me, I am sure.
Don't fight for your country, if your country does not fight for you.
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.
At my old job, we had a pretty revolutionary strategy for picking someone: We talked with them.
The beauty of hiring people based upon a program is that it's not the hiring manager's fault when the new hires are terrible. It's the computer's fault.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
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...
I've hired about a hundred programmers in my career, and education and career background are a good set of indicators, but they're not the be-all and end-all of selection. I've had the best results from avoiding agencies and their filtering methods, believing it's worth plowing through a lot of crap myself, in order to not lose that one gem that can transform your entire development effort.
And again, oddly enough, some of the best indicators were clear, intelligent, structured English and an interest in music. There seemed to be almost no correlation between those factors and their achieving a degree, or their lack of one.
On a whim once I interviewed someone who had a non-standard resume that consisted of a well-reasoned argument for her self-taught programming skills, in impeccable English. I brought her in, and she showed me code samples that were sophisticated, well-written, well-commented and offered proof that they worked. Her background was "housewife", no job background at all, no degree. I hired her, and she ripped through the workload like a veteran.
Don't be lazy, do your own filtering.
Do not mock my vision of impractical footwear
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.
As much as HR would like to see "out there" people with tons of blog posts and lots of check-ins on open source repository sites the fact remains that many great programers labor on in obscurity because they're too modest to promote work that while useful isn't exactly brilliant. Just because somebody checks in a lot of code and writes me-too blog posts doesn't mean that they're a great programmer. You want to know what really attracts good developers, especially experienced ones with grown up responsibilities and families to feed? How about making them some basic promises when you hire them, like a 2 year deal with a guaranteed severance package and some time at work to either work on personal growth projects or work on new skills that will be useful in future projects? The problem with these Silicon Valley types is that they want bright young hotshots fresh out of school and not experienced enough to recognize the fact that they're being used up and thrown out by people who don't really care about their careers or their futures. The other thing about bright young hotshot coders is that you can't tell them anything. They think that they know everything and that everyone who came before them was a dumbass and then proceed to make every mistake in the well worn programming book of things not to do. If you want to relearn the programming mistakes of the past, hire that hotshot fresh out of school. If you want it done right, look for the experienced programmer described above and pay him what he's worth. It's just better that way for everyone in the end, even the blue flame special straight out of school.