Camspi

My company is dusting off some job descriptions and considering expanding our team, which got me thinking of a blog post I’ve been meaning to write. Hiring developers can be tricky business, so I wanted to share some practices that have both worked well for me as a candidate and hiring manager. But first…

A Little Story

In the not too distant past, I found myself attracted to a fairly new company with a veritable A-list of Perl developers. After being declined, I was offered some feedback by the hiring manager which I gladly took the opportunity to hear:

It was a mixed decision with several weak hire votes and several weak no-hire votes. The consensus was that you have some programming skill, but struggled with some simple problems and didn't have a good sense of how to keep programs simple. It [sic] seemed like someone who could get things done, but would need a lot of oversight to make sure they were done in a reasonable way. And as a remote employee it would be more difficult for us to provide that oversight.

Yikes! With that feedback, I'm lucky to find employment at all!

Successful companies using Perl are good for all of us; which is one of the core reasons I applied (I already had a great job with a fantastic team). Nothing markets Perl better than demonstrating its potential to create value for the rest of humanity.

I fully support the reasoning to pass on my candidacy given their assessment of my skillset. Having been on the other side of the table as a technology director hiring developers myself, I know how important it is to match an employee with the right resources to accelerate their transition from new hire to seasoned contributor. With the hiring team having doubt about whether I was going to be able to make that leap, it was the right decision to save us both from the expensive risk of failure.

So how did I go from resume > quiz > longer quiz > phone interview > flying to an in person interview > FAIL? Based on what was shared with me (the reasons for rejection could have been more numerous, who knows), there was general concern about my ability to solve simple problems reasonably without supervision.

For example, here's one of the several algorithmic questions I was asked to solve on a whiteboard (paraphrased):

Given 3 arrays of integers with lengths 10k, 100k, 100000000k respectively, find the intersection of the three arrays.

If you have infinite processing power, memory, etc., using a few loops to iterate over the values of these sets is pretty trivial (and inefficient). As we discussed how I would approach this problem, it was pointed out that I should have used one less loop and leveraged instantaneous hash key lookups instead of what I was proposing.

Five hours of whiteboarding later, I must have demonstrated I was a certifiable buffoon.

It's entirely plausible that the company’s architecture is so successfully being maximized by user volume that the perfect is the enemy of the good. In that case, I am definitely the wrong hire, because I'm just... well... good enough. If my code pleases its users, passes its test suite, has appropriate pod and test coverage, and maybe even been perltidied to the dev shop's content, I am satisfied with my work (implementation details be damned). God knows I don't concern myself with the inner workings of any of Perl's meta object systems or XS as long as the end product works well - it's not until there is a problem that I am going to muck around in something like Kavorka to submit a pull request.

Which leads me to the long-winded point I'm trying to make: the company already knew that (or should have known, just like I should have known about the efficiency of hash keys!)

The top of my resume has my Github link. I have two modules posted on CPAN. I took 2 quizzes, the latter of which was a repeat of the same algorithmic questions I was being asked in the interview. For much less than the price of last minute roundtrip airfare, a lovely night at a boutique hotel (free champagne!), a tasty lunch, and 5 hours of interview sessions that kept executives and developers idle, I should have been disqualified much earlier in the process. If I was one of the venture capitalists that has contributed millions of dollars to this company, I would want my money better spent.

Quintessential Golf and Algorithm Questions

I’ve been through enough interviews in my career to know that contrived algorithmic whiteboard questions are some archetypal thing we feel compelled to incorporate into our screening processes. They do happen to be useful at revealing how a person deals with the stress of coding on the spot, their background at solving certain types of problems, and their mental workflow and ability to communicate that to the interviewers. As a candidate, I often use these types of questions to engage the interviewers with questions and include them in the process of solving the problem to underscore how much I value collaboration and my willingness to incorporate feedback. As a hiring manager, I use these questions to explore what a candidate knows about the problem domain and where I would want to supplement their knowledge.

What I don’t like about these types of questions as a primary mechanism for evaluating someone’s talent is that they are 1) boxed by unusually extreme time constraints, and 2) fail to provide an analog to practical work.

If you simply must include these in the types of exercises you want candidates to go through in person, consider modeling the question after a real problem that was solved by your team. This helps you to see how a person might have contributed to the discussion when the problem was being solved, and also gives the candidate insight into the kinds of problems they would be tackling that are domain-specific.

In general, pseudocode is far more appropriate for whiteboards (curly braces are so obnoxious to draw). If you want candidates to do real programming, consider supplying them with a terminal and screen for the interviewers to see.

Evaluate Some Applied Code Before an Interview

If a candidate has open source work published, take the time to acquaint yourself and the hiring team with it before asking for an interview. How they’ve contributed to and/or maintain software out in the wild is easily the best indicator of what you’re going to get when you hire someone.

If they don’t have published work, ask them for a code sample. Don’t hold it against them if they don’t have a code sample readily available – it was many years before I decided (or had the capacity) to work on projects that were not proprietary. In this case, assign a lengthier homework question that is relevant to the kinds of problems your team is trying to solve. I typically keep these somewhere between 4-8 hour projects, appropriate to the level of experience for which I’m hiring.

Have the Candidate do a Code Walkthrough of Their Work

You know that project the candidate worked on for 4-8 hours? Or that CPAN module they maintain? Have your candidate perform a code read line by line to explain it. Ask them why they chose to solve the problem in a particular way, its advantages and disadvantages, and even things they may have learned (and how they learned them) from completing the exercise.

If you’re looking for a candidate that knows everything, I will plainly tell you that’s idiotic. You need candidates who know how to learn, and how to leverage resources readily available to them.

Ever Heard of CPAN?

In the story of my recent interview experience, something that really gets me riled up is the idea that how someone solves “simple” problems is somehow indicative of their potential contribution to the organization. Did you know there are modules on CPAN that provide a procedural interface to solve the intersection algorithm I described above? In practical everyday work, as a hiring manager I want my developers to at minimum take a glance at what modules might be available to solve a certain problem. If they work, awesome! If they could use a patch, submit one! If there’s a bug, file a bug report! The more the team participates in the ecosystem, the more the ecosystem can augment your team.

At some level, knowing deep internals of Perl’s implementation is useful. Somebody, after all, has to do that work or the rest of us will never benefit (thanks p5-porters!). With Perl and CPAN as mature as they are, most of the “simple” tasks have already been solved with a great deal of efficacy. In fact, in the era of Modern Perl we continue a march toward powerful declarative syntax (thanks Moops, et al.), so as beneficiaries of the volunteers maintaining these great object systems we mere mortals can focus on being expressive.

Hire someone who realizes the power of the community at their fingertips. If they aren’t aware of that power, extol its virtues! Even if you don’t hire them, maybe you just inspired someone who’ll eventually write the new-new-new-hottest-thing your company can use.

Hire for Heterogeneity and Collaboration

My last piece of advice is simple. Hire people who are different from your other team members, but who also demonstrate a clear appreciation for team effort. In our field, people with high IQs are dime a dozen. Combine ability with a high EQ (emotional intelligence), and you’ve got the cornerstone to build a high-powered, self-edifying team.

Empathy is a far undervalued technical asset. Too often, the knee-jerk reaction to hiring a developer is to think purely of code output, as though they are cogs churning out predictable quality product in a silo. The most successful developers I’ve ever worked for, with, and hired were those who actually cared about the people who were using their products on an emotional level. The empathetic reaction to the software’s users, and to the team members who will inherit the responsibility of maintaining the code, is the difference between mediocrity and greatness.

As a hiring manager, I want my candidates to have above all else an ardent desire to serve those around them; Get that right with the potential for mastery, and the mastery will follow.