My patent-pending 3 question technical interview

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.

HOWTO: Maintain a Rock Star Culture

In a recent post I described a few bullet points on how I’ve managed to go about recruiting great engineers. That’s all and good, but what happens when you manage to land a few of these people? A common retort to my recruiting efforts at SimpleGeo has been, “How are you going to get them to work together without killing each other?” It’s a common misperception that all top engineers are also prima donnas who are impossible to work with. I’d argue that the truly talented engineers are far from prima donnas.

So here is a small list of things you’re going to have to prepare yourself to do if you want to hire, encourage, and foster a team of top engineers.

  • Don’t skimp on making them comfortable. You’re paying this person over $100,000 a year so why cheap out on their hardware, desk, chair, snacks, etc.? What we do at SimpleGeo is we tell them they have about a $3000 budget to purchase an Apple MacBook Pro of their choice and whatever monitor setup they desire. We make sure there’s plenty of water in the water cooler, soda in the fridge, nice chairs, whiteboards, etc. in the office as well.
  • You need to be prepared to fire a great engineer. There are going to be great engineers on your team who, for one reason or another, are not going to work out. They’re causing more harm than good – act quickly and decisively when you identify this. Yes, I just told you to fire great engineers.
  • Do not allow language and other technology zealotry to take hold amongst your engineers. Truly great engineers will run benchmarks, be pragmatic in their technology choices, and abide by bake-offs. I hate Java with a passion, but if it will pull five times more jobs a second off of RabbitMQ than Python then we’re using Java for our queue processors.
  • Allow ample time for proper development and, if that’s not possible due to arbitrary deadlines, allow developers to circle back after the fact to clean up. Great developers loath writing shitty code; at least give them the opportunity to revisit quickly/poorly written code. They’ve got a reputation to uphold you know!
  • Institute and promote proper development cycles and practices. Great engineers will naturally do this on their own and, when they do, get out of their way or figure out how to help with the process.
  • Hire or promote a great engineer to manage them. Great engineers, for lots of reasons, tend not to trust non-engineers to ensure their voices are heard within the company. If you think about it, engineering is one of the only disciplines where people who were not trained in the vocation are allowed to manage a trained team. You wouldn’t put a marketing person in charge of accounting would you?
  • This is a personal preference of mine, but I don’t think you should hire or have any dedicated product/project managers.
  • Your engineers should, for the most part, drive new feature development. You’ve just hired a small army of the best technologists on the planet. Nobody in your company knows technology trends better. This is where it becomes crucial that you’re adequately communicating your vision for the product and company. If your engineers buy into that vision they’ll dream up and program things you never thought possible. If they don’t they’ll tell you they don’t and why; listen to them carefully as your business’s success might depend on it.
  • Within reason, give them flexibility in where, when, and how they work. It’s true that face-to-face time and pair programming lead to better code, but sometimes an engineer just wants to walk to his favorite cafe and work with IM turned off. Let them.
  • The phrase is “Work hard. Play hard.” not “Work hard and then work hard some more.” This applies generally to the entire team, but especially so with highly cognitive vocations such as accounting, engineering, etc. Give your team ample vacation time and encourage them to use it. I’ve gone so far as to enforce reasonable hours at the office. Your engineers simply aren’t producing great code if you’re forcing them to work 12 hours a day, 7 days a week. Some engineers will resist this, if they do, read Alex Payne’s great post on not being a hero.
  • Promote a culture amongst engineers where their first response to a technical question is, “I don’t know.” A good way to tell a good engineer from a great engineer after you’ve hired them is a willingness to quickly admit when they don’t know something.

The above is just a small list of things I’m actively doing in an attempt to maintain a team solely built of great engineers that are producing great products at a very rapid rate. The usual caveat being that your mileage may vary when you attempt to do this yourself.

HOWTO: Recruit Rock Stars

Yesterday, SimpleGeo announced the hiring of five new employees. Four will be engineers and one is an engineer moonlighting as a developer advocate for us. The feedback I’ve received about the team we’ve managed to put together in such a short period of time usually involves two statements:

  1. How on earth did you manage to build a team like this in such a short period of time?
  2. Will you please leave some engineers for the rest of us?

The answer to #2 is easy; no. The answer to #1 is somewhat funny; I’m a better recruiter than I am a coder or architect. No, it’s true. Ask Jay if he was more sorry to see his lead architect or his top recruiter leave Digg. My guess is he’s more upset his top recruiter left (I recruited about 40% of engineering and over 10% of the company by the time I’d left). The simple fact is that I would have made more money as a recruiter for Digg than as their lead architect.

But, how do I do it? Good question. I honestly don’t know, but I am going to share some insights that might help you land your own rock star. Here’s an arbitrarily ranked list of do’s and don’t’s for finding, recruiting, and hiring great engineers.

  • Make sure your ego is in check. My only rule in hiring is to hire people that are smarter than me. Top engineers like this will be smarter than you and most likely command a higher salary than you. You need to be fully prepared to pay handsomely for someone who will likely make you look and feel like a fool on a daily basis.
  • If you take nothing else away from this post, please remember this: amazing engineers are not perusing job boards for their next job. Do you honestly think Alex Payne or Ian Eure actively seek out employment?
  • Great engineers generally seek out two things when looking for new employment: interesting problems and awesome people. If your startup is “like Twitter plus blah”, you’re not likely going to be able to recruit top engineers.
  • Get involved in local meetups, bleeding edge protocols, open source, etc. I’ve found, and recruited, two of the best engineers I know via meetups (Arin Sarkissian) and open source projects (Chris Goffinet).
  • Do not, under any circumstances, send a recruiter after an engineer you covet. Send your most senior technologist after them. Pitch them on your team. Pitch them on your problem sets. Tell them about your strict adherence to TDD and Agile. My point on this is you need to send in someone who can speak engineering and sell that aspect of your company.
  • Pay them what they’re worth. If you don’t, someone else will. You aren’t going to lure these guys in with dreams of IPO or M&A riches. They’re smart enough to know that 1% of your company won’t lead to “fuck you money.” So don’t bicker over paying them an extra $10,000.

I’ve got a lot more ideas on how to manage and foster such a team once it’s been built, but those will have to wait for another blog post.