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
argumentsobject. I’d start off by calling the as-yet undefined
Now this is where it gets a bit trickier. Good candidates will know that
argumentsis 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:
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.