I've been helping a client with their technical hiring. They need more developers and it's notoriously hard to select the good ones. It's extraordinarily difficult to tell the difference between someone who sounds good and someone who is good. It's practically impossible if you're not a developer yourself; that's where I came in.

One standard tenet of screening programmers comes from Joel Spolsky:

How do you know whether to hire someone? In principle, it's simple. You’re looking for people who are

1. Smart, and
2. Get things done.

That's it. That's all you’re looking for.

That's definitely a great starting point. But I think the list needs one more item: opinionated.

It's not enough to be smart and to get things done. I've interviewed a number of candidates who had a strong history of both. But as soon as I tried to get an opinion out of them I found myself stuck in a bog of equivocation.

Taste

Sometimes the opinions are matters of taste. I like to ask candidates what websites they like, what tools they use, and what they like about them. The last part's the key. I'm not trying to bond with you when I ask what websites you like; I'm trying to get a sense for your taste, your critical eye, and your ability to intuit what's under the bonnet. I'm not going to rule you out for using NetBeans when I like vim; if you're interviewed by someone who will, you probably don't want to work there anyway. I'm trying to figure out how you approach problems, what crutches you have¹, and how much thought you've given to how you work.

Here's an example: you interview two candidates and ask them for their favourite websites. Both say they like Twitter. "Why?" you ask. Candidate A mumbles something inoffensive about how he likes talking to his friends. Candidate B talks about the problem of distributing messages to millions of people, near-instantaneously, pushing the data to web browsers and mobile devices. Who's the stronger candidate?

But delivery is important, too: what if candidate A had spoken confidently about how Twitter's changed how he interacts with his friends, how the public interacts with celebrities, and completely reinvented breaking news: all of a sudden it's not so clear-cut. One candidate is more focused on technology, the other on sociological impact. The right choice depends on your company & the job role, but now you've got more information to make the decision.

Technology

Sometimes the opinions are about technology. I always try to include an open-ended design question in an interview; lately I've been using "How might you design a system that lets people play Monopoly with each other over the internet?"². The openness is a feature; good candidates will ask a few questions before diving in, and there are lots of dramatically different ways of answering.

One candidate proposed a peer-to-peer solution. That's uncommon, but not insane. You can make that work. But he couldn't explain the strengths or drawbacks. He couldn't explain why he'd chosen that instead of a client-server approach. "There's a number of factors involved" isn't an answer if you can't name some factors. I'm totally fine with a candidate changing their mind! A great answer would be "I started this as a peer-to-peer solution, but now I see problems with synchronisation and preventing cheating. So, in retrospect, I think a client-server model would be better." Unfortunately I couldn't get anything out of this candidate; I encouraged and cajoled, but he stuck with neutral platitudes.

The best people I've worked with all have strong opinions about how software & the Internet should work. We don't always agree, but being unafraid to express an opinion means we can discuss a problem and find a decent solution.

There's one final nuance: the people you want have pragmatic opinions and respect other points of view. I don't want people who insist they're right, don't listen to others, or ignore reality. Sometimes there are valid reasons to cut corners, do a hacky job, or do something that stinks. You need people who will roll up their sleeves and get stuck in. But equally, you should expect to hear about how you screwed up, how the situation should never have reached that point, and how to stop it happening in future.

I'm a developer. What am I supposed to do differently?

• Be fearless in interviews. Your goal is to demonstrate your skills & knowledge, not avoid offence. Let's say you discovered the company's using a PHP-based stack, your CV says you just migrated from PHP to Java because PHP was unscalable, and now the interviewer's asking you what the problem was. Trust me: he's not feeling hurt. He's not saying that PHP's great and Java's crap. He wants to know what the problems were, and how changing language fixed them. Don't apologise, or equivocate, or say things like "That's just my opinion." It's obviously your opinion. Explain why you hold it.
• Look at things with a critical eye. Pick a website or app you use daily. What's good about it? What sucks? If you could wave a magic wand, what would you change? What would you change it to? Why do you think it's not that way already? If that change made things better for you, would it make things worse for others? If so, do you still think it should be changed?
• Ask questions. An opinion isn't a snap judgement, and it's only useful if it's been thought through. Interviews aren't interrogations – you get to ask questions too. Don't immediately jump into an answer if someone asks you to design a system; you don't know enough yet. How many users are we expecting? How technical are the users? Are there budget constraints? Is it web-only, desktop-only, mobile-only, or some combination thereof? Is performance an issue? Is it more important to optimise for server-side performance or client-side performance? Can we presume that all our users speak English? Can we trust our data to be valid? Can we hand-wave past a particular bit for now, or would you like me to outline that first?
• Work on your interpersonal skills. Disagreement is fine. Discussion is great. But you must express that disagreement constructively, otherwise you're just being an asshole. Dale Carnegie wrote the classic book on this; The Usual Error is also worth reading.
• Sometimes you have to watch the world burn. Maybe your interviewer is offended by your dislike of PHP, your belief in semantic HTML, or your system design. Be open to the possibility that you're wrong, and be humble, but remember the interviewer's done you a favour. Do you really want to work with someone who isn't open to other people's ideas and won't listen to explanation? Do you want to work somewhere where disagreements are settled with "I'm right because I've been here longest?"