Hiring Good Developers

It’s been a while since I’ve posted.  We’ve been very busy (this is good) but it cuts down on my writing time.  Here’s a random thought that popped up into my head this morning.

BKeeney Software has three full-time Real Studio developers, including myself.  The decision to add that first additional staff member was the biggest decision we’ve ever made as a company.  It made us anxious and filled us with concern.  Did we have enough work?  What if they didn’t work out?  How much would we need to supervise this person?

As usual, we did our research before we started interviewing developers.  We read the Joel Spolsky book “Smart and Gets Things Done”.  I’d highly recommend it if you are thinking about adding additional technical staff to your team.  We also came up with our own list of criteria to ask about.

When we started interviewing candidates we asked the following questions:

Are they smart?  Well, everyone we talked to either had degrees in Computer Science or certifications so that was really a nonsense question.  Of course they were smart.  But how capable were they of figuring out non-standard problems or things they’ve never seen before?  Were they able to take a problem and figure it out?

Do they get things done?  We wanted an experience developer so that we looked at developers that had some work experience.  Again, most technical people have fairly impressive resumes so it’s hard to tell.  The only way to do this is ask them and someone else (coworkers or past employers) about their project experience.

Can they work independently?  I didn’t want to spend a good portion of my day ‘babysitting’ my developers and with each of us working out of our home that makes supervision very difficult.

Do they work well in a team?  Obviously at that point it was just me but I knew we had a big Fortune 100 project coming up that was going to have multiple team members (from various companies).  I also knew that eventually we’d hire more people.  How did this person work in a team environment?  Was this person a leader or follower, a wall flower or a take charge sort of person?

The team question came from experience working with a local university professor who measured how well teams worked.  He measured things on a Energy and Motivation scale.  The fallacy was that managers always thought they needed High Energy/Highly Motivated people when in reality you needed only 1 or 2 of those (if at all).  Most of your team should have average motivation and average energy but the ones to avoid are the Low Energy/Low Motivation people because they can, and will, drag your team down.

Can they say no?  I didn’t want an employee that would simply say yes to whatever I, or perhaps more importantly what the client wanted, without thinking about the answer first.  They have to be competent communicators.

To start wrapping this post up (I feel like I’m starting to ramble a bit) is that we hired Seth 4 years ago and Robert last summer.  Each is very smart and gets things done.  They work well without much supervision and we’ve found that we work well as a team.  And trust me, they have no problem saying no to me or a client when they need to!  We all have different strengths and weaknesses, and that’s okay, because we’re whittling away at our weaknesses when we can.

I think I would sum up my thoughts like this: Hire someone smarter than yourself.  Some think that’s crazy but I don’t.  I want smart people who get things done without much supervision and who can function in a multi-functional team.  For that you want people as smart, or smarter than you.  (I can hear the chuckles now because finding someone smarter than me shouldn’t be too tough, eh?)

What are your thoughts on this on hiring developers?

Happy Coding!

4 thoughts on “Hiring Good Developers

  1. Well, what you write is right. Often a small team of smart guys is better than a big team. Especially as the few people know their work much better and spend less time coding against each other.
    How do you see future? Having a 4th developer? Do you plant to shift your coding to one of the developers and more do the management part with acquiring projects?

  2. I’m already spending more time doing project management than with the smaller team and yes, I also spend more time acquiring projects. Two more developers does NOT equal twice the development time so there is some loss in productivity with the larger team.

    I don’t know what the future holds, honestly. I usually start to look for another developer when I start turning work down or have to delay project starts for 2 or 3 months.

  3. Certainly with a small company things like team dynamics are very crucial to making sure everything works well & the team can be cohesive when you all need to collaborate on a project.

    Its hard to figure that out with everyone working remotely – but it does make a difference.

  4. In the year 2000 my brother in law and myself were selling our firm, a Microsoft Solution Provider in Switzerland. At that time we had 56 people working for us. I can confirm that hiring the ‘smartest’ people you can get is crucial to success. Try to find people who are better than you, in some field. Once I made the mistake to allow to a team to decide themselves on a new developer. They were choosing someone who was not scaring them, someone they believed was no danger for them. Expensive mistake of mine. This person had to leave after some months.
    When you start hiring people, your role changes completely. Soon you must be a good manager, you must learn any legal aspect and – more important – a lot about human interaction, empathic listening and more. You will no longer code yourself. You manage. The chance that you can make a lot of money increases when you have employees (in my experience). But you pay on another level. It can be pretty heavy to make shure all your people will get their salary at the end of the month. You may end up working longer and harder than ever before – and at one point you may ask yourself whether you get paid in the currency you actually wanted: life quality.

Comments are closed.