[bballant]

I've recently been on the other side, trying to interview and hire people. It's difficult.

My primary concerns are: Is the candidate going to be competent and capable of solving difficult problems and contributing to the team? Are they going to work efficiently and be productive? And perhaps most importantly, are they going to be enjoyable to work with?

It is less important to me that a candidate has a particular skill with a particular technology because those things can be learned easily by good programmers. I'm looking for more of an intuition, problem solving ability, and the ability to cleanly translate the solution into code.

To that end, I try to get candidates to code with me, usually by asking a challenging problem and then sitting down next to him or her to work it out. The whole process has been more difficult than I anticipated though. I find many candidates unwilling or unable to write code in an interview.

I'd love to hear some suggestions on hiring tactics and questions to help me better find my next co-worker.

[geuis]

This is the principle problem: "It is less important to me that a candidate has a particular skill with a particular technology because those things can be learned easily by good programmers. I'm looking for more of an intuition, problem solving ability, and the ability to cleanly translate the solution into code."

No, they can't be easily learned by people fresh out of college. I'm 31 and have been doing this stuff since I was a teenager. It takes years of hard won experience to really know the ins and outs all the various facets of frontend engineering. This particular sub-field isn't one programming language. It's knowing what html, css, and javascript do across at least 11 different browser platforms. It's knowing what kinds of interfaces work for different devices. It's knowing javascript as a true language and not a copy/paste thing. It's being able to know know to translate a 2 dimensional design into the correct underlying structure, in real-time.

So that's just my answer to your "any good programmer" statement. That just means you don't really know what you actually need to be hiring for.

I agree 100% about being about to get along with people. But problem solving is directly related to the field you're in. Ask a programmer to be a heart surgeon, I'm sure any smart programmer can easily learn those skills. The intuition will be there if the interview is about what the person should know.

Suppose your database queries are running extremely long and slow because you're a startup and you and your cofounder are generalists. Your company starts getting traction and now that database is becoming a problem. You're a frontend dev that knows python, and your partner is more of a biz guy that does some coding. Now you both identify that you need someone who really knows how to scale databases. Do you ask candidates random CS questions to see if they have some ill-defined "intuition", or do you find out if they know how to scale databases?

It's no different for frontend engineers.

I also agree about the coding part. But you have to do it in the context of the requirements. For a frontend, look at their previous work. Identify some area of your own product that you think can be improved, or was improved. Have the frontend candidate work through how they would improve the js/HTML/CSS etc. This should involve coding, and the person interviewing should have at least enough base knowledge themselves to know if the candidate is worth their salt or not.

[bballant]

You're right, a lot of things take years of experience to learn, which is why solving a difficult problem is not the only way I evaluate a candidate. I definitely look at their previous experiences.

But someone who is so specialized that they can't solve problems outside their area of expertise would worry me. I don't expect a programmer to learn heart surgery, but if you've been doing C++ for years, I'd expect you to pick up Javascript in a month or two.

Now, in terms of "knowing who we actually need to be hiring for," I know exactly. I want someone who can do their thing well but shift and learn as technologies change and as the business grows, and potentially do things they've never done before well. It's integral to have people like this in any start-up (any of USV's portfolio companies) or a fast-growing company like FB.

The trick for me is, how do I evaluate this?

Lastly, here's a real-life example that hope illustrates what I'm looking for. At an old job we had built a web app that monitored an embedded device via ajax polling. The client liked the solution, but found it impractical to always have a browser window open. None of the engineering team had any experience w/ XMPP, but our research and discussions with the client led to an XMPP-based solution. We didn't have time or money to hire an XMPP specialist and we didn't want to lose the client. We had to learn and adjust.

I've already brought my partner on that project aboard my new company. But every time I step into an interview, I am wondering how I can find someone like her.