Hiring Developers: You're Doing It Wrong (devinterviews.pen.io)

Depending on how much time you have to interview (and I suggest you take the time if you're going to hire someone!) the "standard" dev interview can do pretty well at weeding out candidates who clearly lack basic skills. Joel Spolsky is a proponent of this and I agree.

I've found that passion is a great indicator of future success, and you can usually get a good quick read on whether they are serious about software development by asking people about their favorite projects, what they spend their time working on, and what interesting things they see happening in the field.

I hate tech interviews so much, that I never do them. I mostly do unconsciously what this article lays out. I would say personally I've experienced better than average hires if I happen to be positive on the person, doing what this article suggests in an interview. I have missed good people (was overridden) and have failed tons of tech interviews where I thought I would be an excellent fit on the other qualifications.

You'll have to ask my co-workers if I'm good, but they tell me I am.

My response to my manager was "this dude wont work"

I still think asking coding questions is extremely important. Programming is one job where you can actually test skill in the interview (unlike management for example, where you mostly have to rely on personality, work history, and references). I don't know why you woulnd't take advantage of that opportunity.

As for culture fit, obviously you need to do that too, but that's somewhat orthogonal to what else you ask about in the interview.

1) Simple programming challenge (< 30 minutes) by email. To see if they can actually write good code. Resume/age/experience/location mostly disregarded.

2) Casual discussion-style interview to get to know how they think and behave.

3) Short term contract with a predefined project (< 3 months) to see how they work over time.

4) Full time hire with salary + equity.

This gets to the heart of the matter, and you very quickly feel out someone's knowledge, ability, and most importantly, how well they collaborate on a problem. Because in a startup you will need collaboration, and likely under the highest stress moments you've seen in your life.

I also feel like this gives applicants a much better opportunity to learn about their possible future company and coworkers, and whether they themselves would like the fit. If you have not done this sort of interview, even if you have never pair programmed, try it out. It's very effective.

What I'm still trying to learn, is what screening process to use ahead of this. Sadly, you can't invite everyone for an on site day long interview. The best I've come to is to look at what applicants have made on their own time or alternately how they talk over the phone about topics and problems they're excited about. Resumes are nearly useless.

I've never hired anyone, but I can tell you that I could write a linked list in a handful of languages. I can also tell you that it doesn't say much about what I know (or perhaps more importantly, don't). Problem solving is what is important, more important than ability to write code on a whiteboard.

Other people just never applied. I remember manning the booth at one of those college campus events and it was very lonely. I probably talked to three students that day. Nobody followed up with us. I even had the distinct feeling that students avoided eye-contact with us and made beelines for the booths of the big established companies.

In the end, our hiring interview process for interns was 'do you want to work for us? yes? you're in' and for full-time applicants it was simply non-existent. I think in the last three years we did not interview a single person.

I often wondered why that is but I have never found a good answer. In the end it worked out for us. The company was acquired by Google.

Still, I would have liked to have some applicants and interviews once in a while because I keep reading so much about them and I wanted to practice being an interviewer to avoid pitfalls as described in the article.

Depending on his answer, I know right there whether to end the phone interview, or fly him to the Valley so I can see him write code on a whiteboard.

The process was to work together with a senior coder on problems of escalating difficulty. Starting with

    1.upto 10 do |i| { print i }

And ending with "Here's a legacy application we maintain. Add a new widget to the dashboard. Think aloud."

During the day you had lunch with the team.

Even so, that process didn't work perfectly for them. They hired me and about 6 months later they decided to fire me.

Subsequently they've focused on hiring people they already knew. For example, they've hired Darcy Laycock (http://sutto.net/), who they've known through the Rails community for years.

... and in all fairness I'd sack about 5 of me to get a Darcy on board.

As far as "CS puzzles" - binary search, trees, linked lists, hashtables, etc: None of those should be puzzles. If you're giving interviews that people can "memorize" an answer to, then the problem is how you're doing the interview. A proper conversation, including code, will quickly sort out if the person just memorized a one-line Haskell quicksort, or actually knows what they're talking about.

1. A write-a-document test. I was given a fairly simple (contrived) scenario over the phone and was asked to write specs and a deployment plan with a deadline of an hour.

2. A programming test. Again, a description given over the phone and someone available to answer questions if I had them. After delivery, there was a followup programming task to extend it from a client app to a web app. It took about 8 hours in total.

Provided you're willing to put in the time (and I was), it seemed to be an excellent way of judging whether I could really do the work they needed me to.

It's not an issue for me only because I work for my own firm, something I had to do to get out of such bizarre situations. But it's an issue for many programmers who are told that working on their own projects is stealing time and mental energy from the company. I can certainly sympathize with the talented developer who, told that the company owns all his private projects done in his own time on his own equipment, simply chooses to leave at 5 and spend time with his family rather than have passionate private work seized and shelved by a firm who had nothing to do with its creation. It's really the rational choice if you think about it and something very valuable in a developer is rational thinking.

Programming questions certainly aren't the be all and end all, but as a filter they are useful.

Then they brought me in for a tech interview where they plunked me down in front of a computer to architect a small application for a type of problem I might encounter on the job. I thought it was fair and it probably gave them reasonable insight into how I code/think/present my solutions.

I've had a lot of "write a linked list" style and they're draining. The quality of the applicant being pulled in to do CS trivia is going to be all over the place since that type of an interview can be gamed fairly easy if someone has a desire to do so.

1. Phone screen (~45-60 mins). I'd spent ~15 mins going over what the company does, what the work environment is like, the team structure, the personalities, the technologies, etc... I'd try to "sell" our opportunity to jazz up the candidate and get them at least curious and hopefully very interested. I'd weave in a little of why-are-you-changing-job, what-was-your-experience-like, or what-would-you-prefer, and then ultimately we spent the majority of time on a recent project that he/she can talk about in depth. I pushed on a few related technical aspects to those projects to see if the candidate could clearly explain himself/herself technically.

2. First round (1.5-2 hrs). If I liked the candidate's potential after the phone screen, I'd invite him/her to our office to meet me and another engineer. We'd go into more depth about their recent project(s), and then go through a design/code exercise for a web application (the company builds web apps). The exercise was very open-ended (there's really no one correct way to do it). The design/coding choice depended on many factors, and we helped steer the conversations so the candidate could talk about those factors and what he/she would do to handle each of them (including when not to handle certain situations).

Along the way, we also probed into how he/she would work with other team members, how/whether to "challenge" another colleague, what/if any development process he/she would follow.

There was no trickery, no reversing a string, no linked lists. But I might ask how one would deal with concurrency conditions (two users trying to claim a single resource), how to scale with traffic, etc...

The candidate was encouraged to ask questions throughout the interview. It was a two-way street after all.

3. Second round (another 1.5-2 hrs). If first round went well, I'd invite the candidate back to meet a few other employees (e.g., another engineer, a Product Manager, a designer for example). I asked these other employees to ask anything they'd like, but at the end be able to tell me if this candidate would a) be smart, b) get things done, and c) have right cultural fit. If anyone had strong objection from this round, it almost always resulted in no-hire.

Equally important to hiring well is to let employees go quickly if they don't fit. That's a separate subject worth its own post.