I’ve been involved in hiring software developers for over a decade. I’ve seen which skills matter in building a successful career, and which ones don’t. And I’ve seen how the software industry over-focuses on too many tactical, fleeting skills, and fails to emphasize the skills that actually matter. What follows is an explanation of the skillset — the only skillset — that goes into my hiring recommendations. Whether I’m hiring a junior position or a senior position, these are the skills that matter.
Coding
A software developer needs to be able to write code effectively. It’s almost ridiculous, shameful, that I should have to call this out, but it clearly isn’t something one can assume. After over two decades in software development, I’ve found that there are far too many developers drawing paychecks for writing software that can barely write code, if at all. I say often that if I were hiring jugglers for a circus, I wouldn’t hire a single one without actually seeing them juggle. Therefore, I won’t hire a programmer that I haven’t seen write code.
What do I look for? I look for proficiency. Is this person comfortable with the syntax, or do they stumble along? Do they pay attention to the warnings and errors that the compiler, the IDE, and other tooling provide? Can they turn the idea they have in their head into actual working code in a reasonable amount of time? Are they good at using the keyboard? The editor or IDE? Do they format their code according to whatever the idiom is for the programming language at hand? Can this supposed juggler actually juggle?
Communication
The next thing I look for is if a developer can “think out loud” effectively. I need to see if this person can clearly communicate their thought process, because communication — especially in such a technical context — is the foundation of collaboration and productivity. Can I understand this person’s intent? If I can’t deduce what they’re doing from how they’re writing code, can they fill in the gaps verbally? Does speaking with them make things clearer… or more confusing? Do they answer questions clearly and directly? Do they use technical terminology correctly? When they’re confused or operating at the limits of their skills, can they be vulnerable and say so?
Responding to Feedback
I also look for a developer’s ability to respond to feedback. That is, can they productively change course when someone insists on going a different direction? Programming is often a team sport, and I need to see that someone can be a team player. In interviews, I will intentionally insist on asking developers to restructure their code in different ways to see how they respond. Too many developers, unfortunately, are married to their code, and struggle to incorporate another person’s perspective into it. When a programmer can abandon ego for the sake of productive collaboration, that’s a skill worth hiring for.
Managing Complexity
Complexity is a programmer’s eternal enemy, and I need to see that a programmer knows their enemy and how to battle it. Do they write good tests that clearly illuminate the intended behavior and keep bugs at bay? Do they use good names for variables, classes, functions, and so on? Do they break apart large functions, classes, and files into smaller ones when they get too big? Do they have a healthy distrust for repetitive code? Do they avoid deeply-nested control structures? I won’t hire a programmer that carelessly slings code.
If I directly observe that a programmer has the above qualities, there’s a good chance I’ll hire them (or recommend hiring them if I’m not the hiring manager). What might be conspicuously absent from my criteria are things like:
- Do they know React/Vue/Angular/Flerble/what-our-stuff-is-written-in?
- Can they do a linked list insert?
- Can they estimate how many ping pong balls would fit in a school bus?
- Do they know SQL?
- Do they know CloudFormation/Terraform/ARM Templates (or whatever our infra automation is written in)?
- Have they worked with ũberCloud HyperMessage BusFabricServer?
What I’ve discovered, after over twenty years, is that aptitude and core skills matter a lot more than having “the right answers”. I’ve seen what happens when hiring focuses on tech stack familiarity instead of skill and aptitude. Hiring for someone who already knows the stack with the intent that they can “hit the ground running” may sound good, but beware. Without those core skills and aptitudes, stack familiarity just speeds up the rate at which bad code and bugs pile up. In contrast, people that pass my criteria have invariably proven themselves to be good hires. I hire for that, and let them learn the details on the job. So far, it’s been working pretty well.
(pardon the shameless self-promotion, but if you need help with screening software development candidates, upskilling your team(s), or leading a software development effort, reach out.)
