Sorry, Tech hiring is still broken.
In December 2024 I decided to take a year off to learn and explore some different things that full time employment didn't give me the chance to try. I wanted to learn a little more of the advanced theory by pursuing another Mathematics degree and as well to learn the details by taking on the Cambridge Data Science Accelerator. It's honestly been one of the best decisions I have ever made in my career, but now coming back to the job market i've noticed something weird.
We're still searching for engineers based on how much experience they have with brown.
I don't think people are at fault for doing this, software engineers are really strange creatures to hire. I think that this comes from a misunderstanding between what should be considered a skill and a tool in software engineering.
Let's dangerously extend the analogy from before, consider framing a house. This is a skill, learning where to lay out the joists etc, how to read architectural plans. A hammer is a tool that allows someone to frame a house, but there are lots and lots of different kinds of hammers!
- Claw hammers
- Ball-peen hammers
- MC hammers
Even if you take someone who had only used a claw hammer their entire life in construction, if you put a different kind of hammer in their hand then yeah, it's going to feel strange and you might be a little slower, but the house is going to get built.
Skills take longer to learn, and are more transferable. Tools are quick to learn, but are just there to demonstrate your skills.
Simultaneously, just because two separate skills have overlap with a tool doesn't mean that you have both skills! If you take someone with 10 years of experience with C++ in game development, put them in an environment doing High-Frequency-Trading and they are going to have a difficult transition because while they do use the same tool it's used in radically different ways with different constraints, considerations and paradigms.
With that being said, I need to echo the words of Jeff when he says:
Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language. — Jeff Atwood
Many years ago, there was a greater dividing distinction between those who worked on the back-end and typically had attended university, and those newer to the field working in the simpler front-end space. With the former being perceived as "real engineers" and the latter not. Whatever your feelings on this subject may be, I have personally taken "front-end" engineers and quickly had them implementing working software solutions, the same being true of "back-end" engineers.
The fact is, engineers are engineered to build, and learning is part of the process. Even with some "missing" skills, a good engineer can plug those gaps fast.
Where does this leave us with hiring? Honestly it's not an easy problem to solve, and I appreciate that there are other factors like financial incentives, ATS filtering, the AI wave, and pressure to fill roles quickly. But, here are a few of my recommendations:
- Understand where the skill overlaps are - Someone with experience in one cloud provider is going to have a really easy transition to another, an engineer with 5 years experience in Java making websites is going to have no problem making your .NET app, they're just going to have to spend two days learning some new product names
- Talk skills, not tools - "Have you managed software in production before? How did you handle performance?" tells you a whole lot more about a candidate than "Do you have at least 6 months experience with .NET4? Oh, you only know .NET3. Well I can't check this box"
- 50-80% - Good engineers are like plants, they need room to grow. If you treat your full list of requirements as a checklist of "must" haves you're going to miss some great people. Plus, those growth opportunities help with retention anyway
- Conversations > Tech Tests - Technical tests don't tell you much, it's artificial and all it does is make you over-select for the type of person that has memorized leetcode solutions. You're also leaving on the table talented engineers that don't operate well under extreme social pressure. Usually, a conversation about a problem is going to give you a better day-to-day represenation anyway.