How to hire a real star developer

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

What makes the difference between a star developer and a day coder? First of all, with a star developer I don’t mean star as in ”famous”, rather as in ”elite”.  And, a day coder is OK to be, no disrespect here. We need you as much as we need the elite.

My point here is that if you wish to hire a real star, you need to know what to look for.

Expensive but valuable

If you hire a star, either on contract or employment (less likely), expect to pay more. They know their value. With that said, a star will give you more than you pay. A more productive person is better not only because of that in itself, it will also mean you can get the same job done with fewer people. The communication cost for a team increases exponentially with the number of persons. This means that while the cost for stars is in linear increase, the benefit is exponential.

Communication paths

Team player

In the old days, when I started coding, the best developers could sit in a dark corner and crank out cool solutions that they reluctantly maintained when somebody dared to ask them.

That kind is no longer considered a star, more of a pain in the proverbial. Nowadays, developers are supposed to work well in teams, stars or not. Therefore, a star is a person that lifts the team and makes the other players better. Compare to any team sport, ice hockey, football or motor sports. We play at different positions with different skills but the star player lifts the rest.

Needs challenges

If given a mundane task and no one in the team wish to take it, the star will find a way to automate it. I usually challenge with the phrase “how can we not do it?” which gets the discussion rolling. Thus the challenge will be to remove the mundane and make room for real challenges.

Beginner’s mind

You don’t learn new things unless your mind is open, that has been known for thousands of years. But still we must actively be on our toes to keep it that way. In our industry, changes are fast paced and you don’t become a star unless you keep up.

A star developer keeps a beginner’s mind to be open to new influences, which also makes a great listener. It is a joy to sit in a room with real stars having a discussion.

Clean code

A star developer is proud to write readable code that is easy to refactor thanks to back up from automated tests. Years of experience has taught the lesson that maintenance starts from day 1.

Deliver, deliver

Another thing that is prominent with a star, is the recognition of customer value. Instead of “interesting” solutions that will pay off eventually, a star delivers working, valuable software here and now.

Sharing

If you’re good, then there is a moral obligation to share. There are many ways to do that and as a team player, pair programming is natural. Here the star excelles with patience for the slowest of beginners.

When there is a new challenge for the team, the star picks up and will do a 30 minute presentation just to get all in the same direction.

Honest and transparent

A star is always honest about skills. You’ll never hear a star claiming to be knowledgeable in something they’ve only heard about on a conference.

Nor should you need to be in the dark about what the star is currently doing. At any time, it should be evident what is on the agenda.

In summary, a star developer is someone that you will want to have on your team and that everybody in the team appreciates or perhaps is even proud to work with. To hire one, I think that what I mentioned here is what you should be looking for.

Happy hunting! 🙂

9 Comments

  • 1
    2012-08-31 - 15:27 | Permalink

    Great post that describes a truly professional attitude! I don’t know if I’m a star developer but I try to be guided by similar principles:

    • Honesty. Never give the impression that you know stuff you don’t. Always ask questions when you don’t understand.
    • Transparency. Let other’s see what you are doing and share knowledge. It pays back in so many ways.
    • Be humble. You can learn something from most people. Never assume you know best. Leave prestige outside the door step.
  • 2
    Mats Henricson
    2012-08-31 - 15:28 | Permalink

    Great summary! I would perhaps add something I have seen in a few colleagues recently – an impressive drive to kick out technical debt. It may be the hairiest ball of code that nobody dares to change, until a real star developer tackles it. I have seen Jan Grape and Olle Hallin do just that. Humbling.

    • 3
      2012-12-07 - 00:39 | Permalink

      I don’t think working at Google is the cosleot thing right now. Google is loosing its appeal, and also loosing the battle with the spamers. Their neglect of metadata is taking its revenge right now, and although Google is hiring lots of NLP people the company has not figured out to really answer queries by combine information from multiple sources.The catalog and froogle services are steps into the right direction, but Google need to go far beyond these simple types of information.I noticed the hiring ad if someone searches for Semantic Web but no community involvement of Google.

  • 4
    2012-08-31 - 16:23 | Permalink

    And have fun while working!

  • 5
    Mia Kolmodin
    2012-08-31 - 18:29 | Permalink

    This is exactly the kind of developer I like to work with. Knowledgeble, no fear of saying their point in a humble way. Thats why we hire them, and like to work with them. They dont do as you say, they do what works best, and they make the product as well of the team work, and deliver! Great post Per!

  • 6
    2012-08-31 - 21:55 | Permalink

    Thanks to all of you for your kind comments. The reactions to this post have be remarkable.

  • 7
    Peer Törngren
    2012-09-02 - 22:54 | Permalink

    Good post, especially the initial part on how communication cost impacts productivity. And also the part on sharing knowledge and being transparent. And also … well actually, all of it 🙂

  • 9
    2012-09-05 - 00:13 | Permalink

    The title, even as you say might be misleading, got me to think of a presentation I listened to many, many, many moons ago. Yes, it was so long ago. I just have to share it.

    It was held by a company working with logic programming in Prolog. They claimed to be able with a small team to outperform a much larger team using conventional languages such as C both in time and cost. Still management wouldn’t buy it. Why? Risk!

    They claimed that to management the star team or star developer was a high risk. Since star developers really are ordinary people they can as such get sick, quit, etc. You get the picture. So to management is was better to hire more people to reduce risk even though it doubled the time to deliver and would cost four times as much.

    I don’t know if that management culture is still around, I hope not, but risk is something you should consider. You see, you might want to hire a star developer, but only to build a team!

  • Leave a Reply

    Your email address will not be published. Required fields are marked *