I’ve done a lot of interviewing, hiring, and firing in my career. It’s inevitable as you start to build your own companies, become a team leader, or move into management. I fully subscribe to the notion that you should hire slowly and fire quickly. That being said, triaging candidates quickly is also important if you don’t want to spend half your time vetting candidates. Adding to the complexity of hiring an individual is that it can be extremely difficult to get to the heart of someone’s technical abilities without pairing with them.

In general my interview process is as follows:

1. Stalk the candidate on the internet via Twitter, LinkedIn, and GitHub. I look at Twitter to see what they talk about, what interests them, etc. I look at LinkedIn for obvious reasons. On GitHub I pay special attention to their commit frequency, what projects they’ve forked, and considerable attention to any repositories that they’ve created and put out there.
2. Meet with them for a coffee or have a short 30 minute phone conversation with them. This is when I’ll put them through my patent-pending 3 question technical interview. Due to the resources required for the next two steps, it’s imperative that I triage candidates quickly and effectively.
3. Bring the candidate in for a full day of pair programming across the stack. Spend half of the day fixing a frontend ticket and the second half of the day working on a backend ticket. I do this regardless of skill or specialties in an effort to evaluate problem solving skills, how candidates work others, and how candidates approach problems that they know little about.
4. A final, and optional, step is a 30 to 90 day contract. I consider this step to be not optional if the candidate lacks an established track record, wasn’t personally referred to me, or is an early hire at a startup when each hire has an enormous impact on company culture.

I actually have a mixed bag of questions that I’ve slowly added to over time. When talking with a candidate I attempt to match up questions with their experience and generally never go beyond three of them. Before asking them any of these questions I ask the candidate to tell me, on a scale of 1 to 10, where their expertise sits on each question’s topic (e.g. “On a scale of 1 to 10 how capable are you with the Unix command line?”).

So, without further ado…

There is a multi-level directory tree, say a local git checkout, that has a number of files all with the extension .tmp. How would you delete all files with the .tmp extension in a single command regardless of where they sit in the directory tree?

I’ve had candidates who will tell me they’re an 11 on a 10 point scale answer this question with rm -r *.tmp. In fact, I got into an argument with an existing Digg employee about that answer and how patently wrong it is. Overall, I’d say my pass rate on this question is below 20% Pretty poor, especially considering I’ve resorted to accepting any answer that mentions using the find command.

In PHP, what is the difference between isset() and empty()?

Every language has its edge cases and gotchas. This just happens to be one of my favorites from PHP because, quite frankly, PHP is a fucking moron when it comes to types. What I like about these edge case gotcha questions about languages is it really allows the language wonks and those who are true blue veterans of a language geek out and really shine. I’ve found that the pass rate on this, even with fairly seasoned PHP developers, was hit or miss. Maybe 50%

What is the -i option on grep used for?

I probably use grep a 100 times a day when I’m doing full-time development. Particularly when I’ve put my DevOps hat on. When I was in college I made myself read one man page a day on all of the major Gnu/Unix command line tools. Want to know what the flags on wc are for? Or how to scp a directory? I know this off the top of my head and I expect seasoned developers to as well. If you don’t know what the -i option on grep means, it likely means you’ve not committed yourself to ninja level status on the Unix command line. The pass rate on this question is also abysmal. Maybe 20-30%

What is the difference between an abstract class and an interface?

This is more of a theory question as it kind of spans languages. Anyone who has coded in PHP, C++, Java, etc. should have a pretty good handle on the fact that these two are different beasts. What I like about this question is that anyone who really, truly knows how to implement really effective OOP code will absolutely know the subtle differences between the two and how to most effectively use them. The pass rate on this has also been abysmal. At most 10% of developers have been able to clearly articulate the difference between the two.

What is the difference between an INNER and OUTER JOIN in SQL?

I love this question because it washes out every idiot who learned how to use the Rails or Django ORM and now thinks they’re some wizard at SQL. The most common answer to this question, I shit you not, is, “I don’t know. I just let the ORM handle that.” As my basketball coaches always would say, “It’s about the fundamentals!” Pass rate on this is also below 10% Bonus related question: What field of mathematics are RDBMSs based on?

What is your favorite OOP design pattern and why?

Another language theory question. I like this question because it doesn’t seem like a pass or fail question at first, but you’d be shocked how many developers have no idea what a design pattern is, much less their formal names, how to implement them, or where to use them most effectively. This is another question where true language polyglots will really shine. A true star candidate will find a way to talk about patterns that are more esoteric, such as the chain of responsibility pattern. While I’ll accept things like the factory or singleton patterns, I’m looking for more substance and look at those answers as a net neutral.

These days I don’t waste my time unless the developer can answer all three to my satisfaction. There is enough latitude in the questions that they work equally well for systems engineers, application engineers, and backend engineers. Any failures from someone purporting to be an architect should be seen as enormous red flags.