
How would you interview people for your startup? Would you focus more on low-level implementation questions or higher-level application ideas? - amichail

======
e1ven
Neither should be primary.

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

------
shbrown
It would depend on the job I was trying to hire them for. But if I had to
choose, I would choose ability to implement over having high-level ideas.
That's my job anyway, and honestly I believe execution is more difficult than
having high-level ideas.

In practice, I try and hire people that have blogs wherein they showed
knowledge as well as serious and deep thinking about the type of problems I
want to hire them to solve.

The only person I've ever truly thought did an excellent job I hired this way.
I didn't know him. I didn't look at a resume. I had one conversation with him.
I just read his blog, and I could tell from his writing that he would do a
good job. Actually, his blog was just his fiction writing and he was a UI
designer and coder but I could still tell from his thinking. He was so smart--
a structured, logical, deep and creative thinker. It was clear to me that he
would do a good job. He did. I tend to be a perfectionist, and he was the only
person I've ever hired that did a perfect job. I had absolutely no criticisms
about him. He always exceeded my expectations. It was amazing. I love working
with the best people--nothing is more fun.

If they didn't have a blog, I'd tell them to write down their thoughts every
day for a few weeks and then I'd read it. I believe that you can't tell
anything about anyone except how they behave over time. People lie and
misrepresent themselves. But it's pretty much impossible to misrepresent
yourself over a period of time.

I might try and give them a few of my problems to work on as well. But, if
someone isn't the quickest thinker and can't answer a problem I give them in
an hour-long interview I really don't care. What if they're amazing problem
solvers but they just take overnight? One of the smartest people I know is
like this.

With a blog, or writing over time, you also get a sense of how well they can
articulate their ideas--if they have amazing ideas but they can't articulate
them well, then the quality of their ideas doesn't matter. If for some reason
they're terrible writers but still smart, you can just have them create a
podcast. If they can't do either, then they can't articulate themselves enough
to be useful to a company.

Watching their thinking over time, you can see how many ideas they generate,
since you don't just want people that will only solve the problems you have.
You want people that see things you can't and generate ideas themselves.

I don't care about how well people fit in. A start-up isn't a clique of best
friends, although you certainly need people that you can be bluntly honest
with and can be bluntly honest with you. It's better if you like them, of
course, but I'm never trying to build any kind of culture except a culture of
excellence--well, excellence on deadline.

Another thing I've always wanted to try is just to hire someone for two weeks
and give them non-critical tasks to do. I could see if they met deadlines and
how they actually worked. The best way of finding out if someone can do
something is to watch her do it.

~~~
comatose_kid
Although blogs are a good way to see if someone is a good fit, you're probably
excluding a lot of sharp people if you use that as your first filter.

I'd also argue that how people fit in is important. If you don't care about
fit when you hire, you end up with a company of individuals instead of a team.

I do agree that the best interview is one where the candidate actually does
the type of work that is to be expected of him/her.

------
comatose_kid
Depends.

For co-founders, you shouldn't even have to interview. Find the best people
that you have worked with before in school, or on the job. You can then be
assured of their creative and intellectual abilities, as well understanding
how you'll work together as a team.

For other positions, you're obviously going to want to look for smart people,
but a key thing for a small startup is to look for smart people who can do
many different things well. For example, I'd be more inclined to choose a s/w
eng who has done well designing a web app, and has designed embedded software
for a consumer electronics device than an eng who has worked only on web apps
for their entire career.

As for the second part of your question, I'd agree with e1ven - neither type
of question is key, although they do help establish technical ability &
creativity.

But my experience diverges from e1vens' in at least one respect - you don't
need to choose between problem solvers and cogs (at least as he has defined
them). I have worked with people who can give you tons of detail on specific
technical areas, but can also come up with great solutions outside of their
technical domains or pick up language X really quickly. It's rare, but people
that have both qualities certainly exist.

------
jkush
I would ask them real problems that I was currently struggling with and see
how they responded. Seeing how they work through it and how compatible their
solution would be with my own thinking would be invaluable imo.

------
budu3
Both, plus I would make sure they fit into the culture of my startup. Trust me
you do not want to be stuck with a bad apple at such a fragile stage.

