On hiring developers

This post from Alex MacCaw on Sourcing.io has been making the rounds over the past couple of weeks. It’s a list of his favorite interview questions, which are largely technical in nature and focus heavily on nuts and bolts of JavaScript. They aren’t bad questions, but I do think they’re the wrong questions.

My interviews are very practical and are entirely coding.

The worst offense an interviewer can commit is omitting the personality portion of the interview. Meritocracy is a concept for those who don’t understand opportunity. “Practical” interviews that don’t focus on personality fit or employee potential are very impractical. A great candidate is someone who is smart and motivated to get work done. Your candidate’s personality is their Big-O complexity. Their technical background is a coefficient. Optimize accordingly.

What are you trying to accomplish?

I hear lots of meaningless platitudes from people in the tech industry about resumes. “If it’s on your resume, it’s fair game to ask about” is one of the most awful cliches in the business. This phrase has become the calling card of narcissistic hiring and the rallying cry of those who believe that exaggeration on a resume is immediate grounds for dismissal from the process. Through cargo-cult repetition of this phrase, interviewers have become convinced that their primary function in screening is to sort candidates into bins: ones who are true subject matter experts in every technology appearing on their resume, and those who are poseurs. Having fallen into this trap for a number of years, I’ve found it to be startlingly unproductive at finding the right candidates.

When designing interview questions, a good rule of thumb is, “can a candidate learn the thing I’m asking about in under an hour?” If the answer is yes, toss the interview question. It’s a waste of time. It tells you nothing except that you feel smarter than a candidate when they get it wrong.

One example can be found in this innocuous situation:

Next I’d ask a few simple questions designed to show me how well candidates understood the arguments object. I’d start off by calling the as-yet undefined log function.

Now this is where it gets a bit trickier. Good candidates will know that arguments is a pseudo array, and to manipulate it we need to convert it into a standard array first. The common pattern for this is using Array.prototype.slice, like in the following:

It’s certainly helpful to understand vararg constructs in JavaScript, and this context is important to understand when passing callbacks. But these are things that can easily be covered in developer orientation by a competent team lead or manager. Anyone who understands object-oriented programming can spend an hour or two thumbing through Reg Braithwaite’s excellent JavaScript AllongĂ© and come out with a terrific understanding of function binding, argument application, and currying in the language. If you make simple things exclusionary criteria for hiring, you are not hiring the best people that you can.

My rules for hiring developers

Try your best to understand your biases. By understanding this, Alex MacCaw is doing a great job of starting down the right path. This level of self-awareness is one of the most important perspectives that a person can have when they’re working with others.

Hire people who can work within a team. This is very difficult to suss out through one-on-one interviews, but I rely on a few heuristics when interviewing developers to determine their fit on a team-centric environment. To me, one of the most important indicators of a programmer’s fit is how much time they spend reading code versus writing it. This is a fairly controversial point, but I’ve anecdotally found that people who are great at reading and comprehending others’ source code are more literate at writing idiomatic code, more productive at debugging, and kinder in turn to people who need to read their own code. With enough time working on diverse teams, you’ll figure out the team-orientation heuristics that work for you.

Know your maximum allowed ramp-up time. Many tech companies are convinced that we’re in the midst of a talent shortage. I disagree; I think we’re in an opportunity shortage. If you’re lucky, one in a thousand candidates you’ll interview checks every box on your list, is motivated to do great work, is easy to get along with, and helps advance the mission of the team and the company. If you’re really lucky, they’ll take your offer instead of the dozen others they’ll be receiving that week. Most candidates, even the best candidates, are not this candidate, and you’ll need to explicitly train them or provide them adequate ramp-up time to learn the technologies and practices they’ll be using day-to-day. Hiring smart people and giving them time to learn the ropes will often lead to much better results than hiring language pedants who can’t problem-solve their way to the bathroom with the light turned off.

Similar technical skills are largely interchangeable. Sure, some things are really tricky. If I wanted to make a website that supported Internet Explorer 6, I would want someone battle-scarred who understands all the quirks of an awful and non-compliant environment. But if I need someone to write normal front-end code, I don’t care if the bulk of their experience is in JavaScript, Python, Ruby, or Smalltalk. If they’ve demonstrated competency in a similar language, and can explain how they would solve a problem in their most comfortable environment, that’s largely good enough. (Caveat: do be sure that candidates are capable of learning to write idiomatic code, because nobody likes working with that developer who writes Perl or obfuscated C in JavaScript.)

1 Comment

  1. Hello I am so delighted I found your blog, I really
    found you by accident, while I was browsing on Bing for something else,
    Regardless I am here now and would just like to say thanks for a
    tremendous post and a all round enjoyable blog (I also love
    the theme/design), I don’t have time to browse it all at the moment
    but I have book-marked it and also added in your RSS feeds, so when I have
    time I will be back to read a lot more, Please do keep
    up the great work.

Leave a Reply

Your email address will not be published.

© 2017 @jgoldschrafe

Theme by Anders NorenUp ↑