Thoughts on Software Hiring

Date published: February 4, 2019

I've been wanting to write this piece for quite a while now, and I've finally done it. There's a lot of talk for and against different technical hiring processes. The goal of this highly unstructured piece is not to summarize what concrete processes to take (or not). It serves to raise more questions regarding your company's process, and how to recognize if it accomplishes what your team set out to value in a strong engineering organization at a higher level. Having sat through several on both sides of the table, there's more moving parts than what most people talk about.

When it comes to hiring, there's just really one major question about the whole process:

How do you and your team design a technical evaluation process that measures the signal at which a candidate is able to deliver on the job?

This question is simple to lay out, but not trivial to answer.

Whiteboard Interviews

I dread whiteboard interviews, and so do many programmers. How often does one work with red-black trees on the job? This further perpetuates ageism biases in industry, as younger candidates have a higher probability of having material like that still fresh from the college algorithms course. And if you can prepare for programming interviews, how is this any different than sitting for standardized tests that have little or no correlation to one's ability to deliver in the workplace?

The hard truth is that live programming interviews are painful for both sides of the table. I interviewed candidates and had to straddle between sympathy and frustration for them. The harder truth is that it's just the least worst way to apply a low pass filter on whether a candidate can write code.

I think simple programming questions should suffice. A candidate can probably go through a simple implementation of a made-up service, or for the younger kids fresh out of college, a strcmp / substring implementation. A good rule of thumb that I've adhered to is to give just enough live coding that prove that the candidate can code (not terribly) out of a paper bag and still have the experience talking through technical tradeoffs but still remain open minded to suggestions.

Engineers with some industry experience could be asked experience based questions, and I'd scale the weightage of the entire interview process this way linearly for candidates with more experience. You don't want to hire senior software engineers that use location names as IDs in your relational database (this is a true story).

Other Points that are Often Overlooked

The interviewing process almost always start with the phone screen. In an ideal scenario, engineer(s) of the hiring team can hop on the phone to talk to potential candidates. Realistically speaking, this is a huge time sink for the engineers and best delegated to technical sourcers or recruiters. The opportunity cost is having people that have less skin in the game to do the filtering.

I've worked with a fair share of recruiters that made me cringe. In some occasions, the engineers down the interview funnel were much nicer. Get your recruiters close to the engineers and hiring managers, as well as briefed about the subtleties that are valuable but not always best represented in the job description.

First impressions matter. Always remember that interviews is a two way deal. I've been through a fair share of interviews that I can tell within the first 15 minutes of the interview that I don't want to work there. Some of the engineers are too full of themselves. Candidates are sizing you up as an individual, potential peer, mentor and judging your company's culture here. Keep this in mind.

Referrals and general background check tend to give the biggest signal. A good chunk of that signal is to highlight issues above. There's better things that some of the candidate's peers say about them that you otherwise couldn't capture in your interview process. Listen up, and you'll make a more sound hiring decision.

Other Don'ts

Don't hire a resume driven engineer blindly. The resume driven engineer is one who claims that he/she created a whole piece of software to do this one thing by building something from scratch. More often than not, that over engineered monster adds little to no value. It adds a lot more complexity to the whole system. The engineer then leaves for a company that self selects for engineers with such traits, and the rest of what's left in the team has to shoulder the technical debt that plagues the stack.

In rare cases (at time of writing), reinventing the wheel is necessary. The software community has benefited significantly from new, innovative ideas in, say, database systems (NoSQL variants). Sometimes building off an existing solution and shoehorning it into the existing infrastructure in hopes of it supporting exponential user growth might not be such a bright idea. This is when reinvesting and even rebuilding certain parts of the stack could add much better value in the long run than limping on indefinitely. The tricky part is how do we draw the line then?

My approach to choosing between competing software solutions is this question: "What good does technology X bring that the previous technology didn't? And when should I not use this?" Use this question on candidates with shiny resumes. You might fall for hiring a resume driven engineer if he/she can't answer either of them well.