Honestly- The best thing that you can do is to figure out how they're going to get along with you, and how well they can find solutions to problems.
They say that the first few employees really determine the culture of a startup, and you want people who can adjust to whatever job is necessary, and solve problems quickly and move on to the next thing in the ever-growing list.
I read an article online (Was it Joel? Seth? Not sure), who argued that there are really two types of programmers- Problem Solvers, and Cogs.
Cogs are the people who can tell you every line of code in a TCP/IP stack, or squeeze amazing performance by reprogramming your server-code in assembler. They're the people you bring in to solve problem foo-
"We need a guy who kicks butt in SQL to optimize this thing" Let's find one."
That's great, and that's amazingly useful.. But not for the first few people for a startup.. For a startup, I'd worry more about coming up with solutions to problems that we have.
Someone who can pick up Lisp or Ruby or (insert language of the week) in a few days more useful in those crucial early weeks than someone who can eek every bit of performance.
Focus on the hard stuff first, like building something people actually want to use. THEN, hire people to help specific elements.
With any luck, by that point you'll have created a corporate culture that encourages flexibility, and they'll come around ;)
Honestly- The best thing that you can do is to figure out how they're going to get along with you, and how well they can find solutions to problems.
They say that the first few employees really determine the culture of a startup, and you want people who can adjust to whatever job is necessary, and solve problems quickly and move on to the next thing in the ever-growing list.
I read an article online (Was it Joel? Seth? Not sure), who argued that there are really two types of programmers- Problem Solvers, and Cogs.
Cogs are the people who can tell you every line of code in a TCP/IP stack, or squeeze amazing performance by reprogramming your server-code in assembler. They're the people you bring in to solve problem foo-
"We need a guy who kicks butt in SQL to optimize this thing" Let's find one."
That's great, and that's amazingly useful.. But not for the first few people for a startup.. For a startup, I'd worry more about coming up with solutions to problems that we have. Someone who can pick up Lisp or Ruby or (insert language of the week) in a few days more useful in those crucial early weeks than someone who can eek every bit of performance.
Focus on the hard stuff first, like building something people actually want to use. THEN, hire people to help specific elements.
With any luck, by that point you'll have created a corporate culture that encourages flexibility, and they'll come around ;)
-Colin