<aside> 💡 Technical interviews are a critical factor in hiring a Software Developer, but it's sometimes hard to know how to make them effective. In our extensive experience hiring Software Developers over many years, we find ourselves coming back to the same simple two-step technical interview process.
</aside>
It's tempting to think, especially early on in a startup journey, that the reason we run technical interviews for Software Developers is to determine whether or not they can "do the job". What this presupposes is that the ability to work with software is a binary skill that is either present or absent. But this is a strange perspective. After all, one assumes that the ability to perform basic plumbing tasks (like, for example, replacing a kitchen sink) is a fairly binary skill; yet how many of us would bother to give a prospective plumber a practical exam before hiring them? Indeed, how many of us would do any kind of due diligence on a plumber before hiring them? How many of us get three quotes and then hire the cheapest? How many of us don't even get three quotes...?
There are three important reasons we might attempt to technically assess someone:
Intuitively we know that there are degrees of competency in most fields, although the degree to which we care about that depends on the context. In the plumbing example, we might not mind particularly how competent the plumber is who replaces our kitchen sink. On the other hand, if we are having an entire luxury bathroom installed in our new extension, we might feel a little uncomfortable to know that our plumber had only been at it for four months after switching careers from high frequency trading in The City (hey, it happens!) One dimension which obviously applies here is the level of risk — usually financial risk — associated with the work. If the sink replacement goes wrong, we probably just lose the labour cost of the shoddy workman, possibly a few damaged parts. If the new bathroom goes wrong it could set us back the cost of our next holiday! First world problems!
Quotes for plumbing work tend to follow the market, rather than being strongly associated with competency. That's why it's usually more reliable to go by recommendation than by cost when hiring tradespeople[*]. Hiring Software Developers works a little bit differently, especially for permanent hires[†]. "The market" tells us that when we hire a permanent Software Developer with 1 year of commercial experience, they are worth £x; and that when we hire a permanent Software Developer with 10 years of commercial experience, they are worth £y — where y >> x.
Of course common sense, if not prior experience, tells us that years of experience isn't a reliable measure of competency [TODO: ref] and so we can therefore infer that the competency of individual Software Developers with the same years of experience must vary. If we're going to all the trouble of compensating someone £y, we'd much rather make sure that their true level of competency aligned with that level of compensation.
Early on in a startup, it's uncommon to be able to exactly specify the competency level you require relative to the cost. "As good as possible and as cheap as possible" seems to be the starting point. What this implies is that making the first technical hire or two is actually quite nuanced.
As a team grows, however, budgets tend to be better understood and the focus on competency can be more structured. An excellent tool for mapping out team members' competencies is the competency framework, of which many volumes have already been written; and my advice would be that the best time to construct such a framework is slightly before you think it's needed.
Assuming that you know at least the rough level of competency you want to hire, then, the first reason for technical assessment at interview is to gauge the competency level of your candidate relative to target (and to cost).