7 simple rules for hiring great developers

The war for programming talent is full bore. Here's how to hire the best coders when competing with the big boys

Page 2 of 5

"The term 'rockstar' creates a perception that the individual developer is greater than the team," Sarantakos says. "Great software products are built by teams, and truly great teams fully leverage the individual strengths of their members. If you have problems that can be solved by a single lone 'hacker' working late into night alone, I'd venture that your problems are too small or your solutions are too inadequate."

Alvin Richards Headshot_175.jpg

"You can't be dependent on just one or two people, because if they are run over by a bus then you will be in a world of pain. You need redundancy and flexibility, and to have as many eyes as you can focusing on a problem at any one time."

-- Alvin Richards, technical director of performance and quality, MongoDB

The other problem? Relying too heavily on a few top devs to carry the load can leave you vulnerable to the "run over by a bus" problem, notes Alvin Richards, technical director of performance and quality at MongoDB, an open source NoSQL database vendor.

"You can't be dependent on just one or two people, because if they are run over by a bus then you will be in a world of pain," he says. "You need redundancy and flexibility, and to have as many eyes as you can focusing on a problem at any one time."

Of course, all developers are not created equal. If one or two devs rise above the others, you can raise everyone's game by sharing the knowledge between them, says Edward Hieatt, chief operating officer at Pivotal Labs, a software consultancy that teaches paired-programming techniques to its clients.

"What you want is to get the best out of everybody," Hieatt says. "When you're paired with someone who's better than you are, you can learn what's in their head at an amazing rate. So instead of the 80/20 rule where there's one superstar and four OK people, the idea is to get everyone up to 100 percent. That's much more powerful."

Developer hiring rule No. 3: Go for talent, not longevity

If you're doing your job correctly and hiring the right people, you're unlikely to hang on to them for long, notes Famo.us' Newcomb. Top talent will almost always move on to better things, so you need to get as much out them as you can in the time you have, while continuing to bring in fresh blood.

"I've always said I'd rather rent gold than buy silver," says Newcomb, now on his sixth startup. "I have several people right now I know I'm going to lose eventually because they're just too good. I know they're going to found their own companies. So I just tell them, 'Code fast -- give me everything you've got right now.'"

Kyri Sarantakos TheLadders VP of Engineering HI-RES_175.jpg

"We'd much rather have our developers learn new skills and eventually leave, than not invest in people and have them stay. It's better for us and for our customers."

--Kyri Sarantakos, VP of engineering, TheLadders

When TheLadders recruits fresh talent, it isn't looking for coders who want to hunker down in one place for the next 20 years, says Sarantakos. One of the firm's strongest selling points is that anyone who signs on will leave the firm a more polished and more valuable employee.

"You need to be honest and realistic with the Millennials," he says. "They want to make a big impact on the world with their work. So we tell every developer that comes in that we offer a lot of hard work and growth, and if they stick around they will leave a better engineer than when they came in."

Playing up the investment not only makes TheLadders a more attractive place to work, it also benefits the company as a whole, adds Sarantakos.

"We'd much rather have our developers learn new skills and eventually leave, than not invest in people and have them stay," he says. "It's better for us and for our customers."

| 1 2 3 4 5 Page 2
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies