Hiring programmers

Part of my job as CTO is to hire programmers and hiring good people can be quite a challenge these days. Plenty of jobs everywhere and it seems that everybody has a job (or two) already. But anyway when I'm interviewing a programmer I always search for three things (inspired by Joel Spolsky ). Smart, get things done and fits into the team. As Joel says:

First of all, the #1 cardinal criteria for getting hired at Fog Creek:

    Smart, and
    Gets Things Done.

That's it. That's all we're looking for. Memorize that. Recite it to yourself before you go to bed every night. Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute.

I added the "fits into the team" from my own experience. We are in need of team players. Programmers who are able to educate and help other programmers. If you hava a small team that must work the best part of the day together they'd better get along. So when I talk to people I always place them in the team and try to figure out how it will match. Also I won't hire anyone unless the candidate had a succesfull interview with a future team member and I get the thumbs up from them.

For smart and gets things done I already have a standard set of questions to ask. For "fits in the team" i'm really on tin ice. It's judgemental and therefor I'll never hire or dismiss anybody on my opinion alone and I'll make sure candidates that fit into the smart and gets things done but not in the  "Fits in the team" catagory will speak to others as well. Maybe not perfect but still better than nothing.

Innovation: stop talking, start walking

A lot can be said about innovation. But no bridge has been build just by talking. We have to start walking. But how? And in which direction? At work we have the classical problem: the only time we are able to innovate is when something new is sold within a project. But new things are rarely sold because the sales people don't know what the techies are capable of.

As CTO I'm also responsible for technical innovation and this problem was a hard one for me to address. On one side I hear a lot of programmers with great ideas but no time. On the other side I hear the non-technical projectleaders and sales people that we can't keep up with the competition.

So how do we innovate? We have adopted the idea of technical innovation days. On these days we will have brainstorm sessions where programmers will present some great stuff they've been working on. This can range from just some basic idea on a whiteboard to a working prototype. These presentations will last 15 minutes max and then there is time for brainstorming and discussion.

The second thing we are doing is building an internal brainstorm site (like http://www.dellideastorm.com/) where everybody can post their ideas and comment on and "Buzz" other people's idea's. Those are just some basic steps, but like every journey innovation starts with the first step. Giving room and platform for ideas and creating a brainstorm buzz!