Slashdot Mirror
How Do You Find Programming Superstars?
Joe Ganley writes "You are a programming superstar, and you are looking for work. I recognize this happens relatively rarely, which is part of my problem. But stipulating that it happens, how do I, as a company looking to hire such people, connect with them? Put another way, how do you the programming superstar go about looking for a company that seems like one you'd like to work for? The company I work for is a great place to work; we only hire really great people, we work on hard, interesting problems, and we treat our employees well. We aren't worried about retention or even about how to entice people to work here once we've found them. The problem is simply finding them. The signal-to-noise ratio of the big places like Monster and Dice is terrible. We've had much better luck with (for example) the Joel on Software job boards, but that still doesn't generate enough volume." What methods have other people used to find the truly elite?
I'm right here.
Be Google.
The first thing to do is remove arbitrary barriers. IE, "must" have X years of experience, X degree, held X previous positions, must move to our area. That's the sum of major mistakes most operations make. The best programmers in the world don't typically get that way by being just another college / job drone (though some do... just don't slam the door based on mundane requirements - you want the problem solved, not a title you can be proud of.)
Secondly, market the job — make sure people can find out about it. That's perhaps obvious, but I know a lot of companies that try to stick to the back alleys of old boy's clubs, and it's no wonder they can't find anyone. Put an ad, a BIG one, somewhere programmers go a lot. Like slashdot. :-)
Third, salary, salary, salary, and benefits (particularly insurance and family coverage). Move 'em if you have to. We've even bought houses outright for our programming team members. You can't expect to hire a superstar by treating them like a drone.
The problem is almost always that really good programmers don't have to go looking, and if they do, they can - and will - turn their noses up at being treated like a commodity. Yet that's just what most companies do. Plus they throw up arbitrary and unrelated barriers to entry. Unfathomable, really.
I've fallen off your lawn, and I can't get up.
(Dodges ballistic vegetable matter)
Do not mock my vision of impractical footwear
Seriously, why do you need a programming superstar, why not settle for a programmer with substantial experience in the area you need?
For example, universities do not look for supergenius professors (if not only for label "Nobel prize winner"), they are mostly looking for a person who will be able to get grants
Supergeniuses are good in the environment that does not require any results any soon. That's the way they work.
Normally people are looking for good workers with a good experience able to fit in the environment.
I am actually glad that in my line of work there is no obsession with top level performers, like it happens in showbiz. As a result a lot of people are paid quite well.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
believe me , nothing your business is doing is so god-damned special that it takes a "superstar" to accomplish. Just find some people with some programing background and give them the opportunity to learn and grow. Anyway, the person asking of this question, if _they_ were a "superstar" HR person/manager, would already know the answer. Since the company can get by with plain old average HR/management I think it can live with average normal programmers as well.
...and be prepared to hire telecommuters, even in other countries. All of our software guys at Slim Devices (now Logitech) found us through our open source projects, and to this day every one of the telecommutes. The stratum of talent you gain access to when you are reaching the people who are so excited about the technology that they'll work on it on their own time.... unbelievable - forget about Monster.com, this is the way to do it!
Real programming superstars, usually love coding so much they take precautions so that they are not accidentally promoted to have management responsibilities like tracking vacation requests and authorizing the expense accounts. So they make sure their belts don't match their shoes, their pants, if and when they wear it, are never ironed. If they are forced to wear ties, they pair it with half sleeved shirts. They are the the programming superstars. But be prepared for huge number of false positives.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Great programmers work for who they want, on what they want. They take getting their personal needs met for granted, but they have grand ideas about things they want to see realized and not enough money of their own to do it.
So you advertise on the basis of the interesting work that you're doing, and aim for the ears of someone who has been itching to build such things rather than talking about the creature comfort and monetary perks.
Great people want strong leadership that will help them achieve beyond what they can do alone.
-1 Uncomfortable Truth
I've met very few superstars and this more than anything else set them apart as someone I would want on my payroll.
You want people who can lead by example, without even trying.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'd take a step back on that one. Before they're "programmers superstars", they're usually college graduates. Start by trolling for college students. Lower your needs from "must be" to "can be" and take those who actually enjoy programming and build them up into superstars by putting them in your super company. They'll probably turn into Superstars in no time if your company is as good to work for as you describe.
Cheers,
Fozzy
"The past was erased, the erasure was forgotten, the lie became truth." ~1984 George Orwell
Convey to the applicant that your company values *production* and *problem solving* over meetings, phone calls, "strategy" and any of the other abstract "big picture" bullsh*t that people with "soft skills" use to justify their positions at the expense of programmers. Bonus points if you can point to a programmer or two in your organization and demonstrate that they make more money and are more valued than the softies. Let the applicant know that "Yes, we expect you to function within our management framework, but that framework is here to help you be *more* productive"...every good programmer dreads the "Office Space" scenario where they are spending more time filling out TPS reports than doing the work that they love.
Every good programmer's worst nightmare is to step into a new job bright-eyed and ready to be creative, only to be told that their function will be to learn and maintain a piece-of-crap monstrosity that someone else created. Make it crystal clear that this is not the situation they are being hired into.
...as far as "where to find them"...The same principle that applies to "getting hired" (i.e. networking is always the best) also applies to hiring. Ask your five best programmers to give you the names of some of their friends and don't be afraid to aggressively go after them and lure them away from their current gig.
"We get brilliant results from average people managing brilliant processes. We observe that our competitors often get average (or worse) results from brilliant people managing broken processes." - Toyota
>I'd pose to you a give-a-man-a-fish metaphor. Why work on finding good programmers when you can find a good project manager - probably with a PhD - who can forge hard-working programmers into good and hard-working programmers.
.5-1% of the company and perhaps 10-20% more in base salary than you'd pay some one who's merely excellent, you'll get over 5X the output on product code (output would be higher if non-coding responsibilities didn't consume 1/2 - 2/3 of their time), build infrastructure, test infrastructure, an effective mentor for your junior engineering personnel, attention to system level interactions before the code is written instead of after it's integrated, and maybe a little management thrown in.
Because
1) You can't teach hard working programmers the creativity needed to come up with novel solutions to hard problems, where the right creative solution can net orders of magnitude better performance and/or reliability. The rough order here can be of a better PhD thesis or Digital labs paper (but with more attention to reliability).
2) Experience productizing solutions _well_ is needed to build reliable complex software. I know of distributed systems groups that had to flush their first products due to algorithmic bugs and others that needed heavy operator support to keep things running because inexperienced groups lacked sufficient practical background in simulation.
The best you can do is grow people towards their potential. Some engineers have a creative mindset and will solve problems when given a description, with the size of the problem dependant on experience and aptitude. You can get them working on bigger and bigger problems with more attention paid to practical concerns. Some engineers can implement something given a description (smells like a log structured file system, with a separate log for B+ tree nodes). You can teach them better engineering discipline.
>Why? Because if you hire savants, they'll do their work in 10 minutes and bill you for 2 hours because that's the time it takes for everyone else to build the same amount of code.
If you pick their brains on an as-needed basis on what you think is important, you'll be paying $500 for their 4 hour billable minimum and not getting fringe benefits.
If you actually hire them and they have interest in how the product and company go, they'll work 60-80 hours a week (it's not about the money) for options on
If you're solving the same problems over and over again, it doesn't matter and they wouldn't be interested.
If you have something that's too hard for other companies to pull off, the right handful of gurus can mean the difference between success and failure.
Some people are simply not up to the job of being a programmer. They cut corners and ignore good design in order to get the project done real quick. It may seem like they're getting the work done, and maybe they are, but crap code piles up. It takes time to work out the bugs. Over time it'll build up so much that it wouldn't even occur to people to refactor it.
I've worked with people like this. No matter how much you try to encourage them to follow good design, they will continue to just ignore all good sense. A typical example is a former coworker of mine who was asked to make a small change to an app that sent out email notifications. He needed to make a slight change to take care of one particular circumstance, so he copied an entire class (hundreds of lines of code) and changed exactly one line to do what he wanted.
When this code later broke (due to that single line) we asked him about it and he denied even writing it. We looked at source control and it was definitely him. (This in itself was surprising because he often deployed changes without checking in code. We tried many times to tell him never to do that.) I asked him why he had copied an entire class just to change one line when it was trivially easy to modify the class to handle both situations. He said he just wanted to get it done. I told him it probably took him longer to do it the way he did it. He just shrugged.
How do you respond to someone like that? I'm sorry, but he will never be a good programmer. Some people just don't have it in them. He was a very nice guy, but he was a terrible programmer.
Thankfully, most of my coworkers do have it in them. I've been privileged to work with some great people. But it's pure fantasy to think that everyone is capable of being a decent programmer.
Cow Cube
You touch on a piece that is often missed. It is a bad choice to only hire 'superstars'. Quite simply, not every problem is going to be interesting. There is very often going to be grunt work, or simple things that just need to get done. Your 'superstars' are going to get board really quick when they have to do grunt work. You would be much better off, hiring people of various skill levels, make sure that they know where they are, and match up really good developers with some that are not as good. Of course, to truly be a 'superstar', you have to be able to understand and appreciate the contributions that those with less coding skill often bring to a project.
At my work, I am teamed up with another developer that will simply never be a 'superstar'. She consistently needs help on code that is just not that difficult for me to write. That being said, she is immensely productive. She knows what level of code she can handle, and she does a LOT of work that, while I could do if need be, I would be far less interested in than the work I do. This would lead to lower quality code, and job dissatisfaction. Her presence on the team gives far more to the company than any 'superstar' could bring.
The key is that she knows what she does well, I know what I do well, and we appreciate each others contributions.
Now, maybe the question wasn't about 'superstar' coders, but in employees in general. If so, it didn't come off that way to me.