Hiring on the smaller scale
So you are looking to build or grow an engineering team for your startup or scaleup and try to hire new software engineers. How can you attract talent and stand out against your competitors? How do you have to present your company to find highly qualified programmers? It is not as hard as you think. But there are certain factors at play that are not completely obvious. To make a conscious decision about which path to take, you should at least be aware of the stakes.
About the author
What qualifies me to write about this topic? Let me clarify that first, before going deeper into the topic:
20 years ago I made the decision to go into software engineering as a profession. I studied computer science, and was employed as a software engineer ever since. My first experience with the employer side of hiring was when I joined the team to evaluate applicants at jambit in 2016. Since then, I was always in the loop for engineering hires wherever I worked. When I became a lead engineer at FoxInsights in 2020, I also started to make strategic decisions around acquiring new talents and led dozens of interviews myself.
Why hire at all?
First, let's take a brief look into why you should hire at all. Let's assume you want to build something, like a product or service, and need somebody to implement it for you. Or you already have a small engineering team and want to grow it so you can move faster. Instead of hiring, you could also employ an agency to do the programming for you. But in my opinion, this is a very bad idea.
Software Design is knowledge building. The code that comes out of it is worthless if you have nobody who knows how to operate and adjust it to your needs. In case you decide to outsource your software engineering, you will end up in a relationship of dependence on some supplier, even if it is just for a part of your code. Do you really want that?
Agencies tend to make great job opportunities for junior engineers. Those engineers have to be staffed to some project. Most of the time you will end up with one or two (if you're lucky) experienced developers per team, while the rest of the team will be stocked up with graduates. The price you pay on average will be aligned on the more experienced developers, of course.
It is also quite easy for an external team to hide completely unproductive contributors (not necessarily correlated with their experience) without you ever noticing. And who would give up their fellow employee to a customer when they notice that somebody is not doing a good job?
There is also the option to augment your team with individual contractors. While the chance for getting someone with higher skills is better in that case, they made a clear choice about staying independent. So you can also not rely on their knowledge to stay within your company forever. Of course you can never do that for any employee, but you have more control over your retention rate for employees than for contractors, and there are no legal limits for how long they are allowed to stay with you.
Your best choice is to actually commit to it and try to find dedicated developers who have the chance to understand your domain and excel at programming. Long-term, this is the only viable strategy, and everything else should only be used as a bridge.
The Mythical 10x Programmer
There is a lot of controversy around the 10x programmer. While some deny their existence or claim that the whole team is more relevant than individuals (with which I can't argue), one bad apple can spoil the bunch.
It is very hard to measure individual productivity but there is solid evidence that some programmers are indeed 10x more productive than others, and the low end is even lower. Depending on how you look at it, compared to the 0.1x programmer, everyone else is a 10x programmer. Instead of trying to find the rockstar programmer, make absolutely sure you don't get one of those 0.1x developers and you should be fine.
Do your best not to have very weak engineers on your team at all.
The only way to be sure about that is to make applicants actually write code. This was a known fact 25 years ago, but it is even more applicable now where LLMs are able to solve hard coding challenges.
Do whatever you want during interviews, but make the candidate write some code.
I have seen programmers with years of experience who made a really good impression in the first interview but then failed to write code that sorts a list of numbers. I'm not talking about implementing a sorting algorithm, I'm talking about not being able to call a sorting function correctly from the standard library in their language of choice, in their own IDE.
I have also seen (and hired) programmers that failed at a coding challenge because they were nervous. How I could tell the difference? I actually watched them work. They could explain what they were doing, produced a cohesive train of thought and were proficient using their tools.
But how do you get those skilled engineers to actually pick up interest in you?
Don't go with the flow
Recently I was invited to a reverse recruiting event. This is where a handful of tech companies with open positions pitch their business and answer questions. I rarely skip a chance for free dinner, and since the FAANG layoffs and the aquisition and subsequent shutdown of my preferred hiring portal Honeypot it was hard for me to assess the job market. I took this chance to get a temperature reading of the situation and joined.
The one thing that completely dismayed me that evening was the fact that all of the presenting companies put their money on Java. There was not a single thing that stood out in any of them. All the same boring OOP sweatshops, selling your lifetime to the highest bidder. They all were talking about diversity, but they didn't consider it in their tech stacks, just in how their employees look.
In a conversation with other attendees I swiftly found someone else who felt similarly alienated. This opened up a great chance: Looking for an engineer myself, I could give them an option with a lot more appeal, because we're not building on a run-of-the-mill solution. I got an application, and I didn't have to do much for it.
If you want a 1% outcome, you need to do something different than 99% of people
There is so much variety in how you can solve problems, especially as a startup you should not default to the most common tech stack. This gives you an edge and the chance to stand out in the crowd.
How do you find people with years of experience in some exotic tech you might ask now. It does not matter!
Focus on other things instead that’ll make much more of a difference. Platform experience is merely a baseline, not a differentiator of real importance.
~DHH
Every good engineer with a solid foundation will be productive in a few months in any programming language. What matters a lot more is that you pick the right tech to solve your problems, not the tech everyone else is using because it is taught at university as the one-size-fits-all solution.
The high number of potential candidates for programming languages like JavaScript is often used as an argument in favor of it. While it is true that you will always have a full pipeline of applicants for JS, the time I had to spend weeding out terrible ReactJS developers does not make up for it. Go with something a bit less common, and most of the below-average engineers will stay away by themselves.
Especially as a small company without a big name, it is hard to appeal to applicants, so use it to your advantage that you are more flexible than big corporates. Having an interesting tech stack is a great ice breaker and will reveal talents who look beyond their own nose.
Now that you have their attention, how do you actually convince people to come work for you?
Don't be cheap
There's nothing more to be won with free coffee and a fruit basket. Every medium sized tech company I've visited in the last 5 years had that and much more. You can only lose by skipping what is now considered as basics.
The one thing every job can be directly compared by is total compensation. Use this to your advantage and put up a competitive salary range on your job offers. Nobody wants to go through an application process to just find out in the third interview that you didn't have the budget for them.
Going too low for the position you are hiring for will leave you in a tough situation. You will have to deal with lots of applicants in any case, but not offering enough is a surefire way to miss out on the good engineers. They usually know their worth.
You pay peanuts, you get monkeys.
You might say that you can't afford much as a small company. But the one thing you really can't afford is bad programmers. A good one will be worth many times their cost, and as detailed earlier, the productivity in engineering ranges in the powers of ten, while salaries only differ by small fractions.
Another thing you can score with as a startup is equity. I am not talking some made-up incentives that scale with made-up business figures. Nobody wants that. Your company is worth close to nothing in the beginning, so it should be easy to hand out a piece of it. There is a realistic chance that its value will go up a lot faster than fixed salaries. So give the people who invest their lifetime in making your company successful a chance to take part in that success, and they will thank you with their loyality and dedication.
Not everyone is looking out for the highest possible compensation though. There are other factors that are just as important, but harder to compare.
Display your values
We spend almost one third of our life at work. So what we are doing there should matter. Be aware that the prevalence of neurodivergence is a lot higher in engineering professions than in the general population. Cater to their needs. Besides that, what matters to people can be very different. Give people agency. Make their working life enjoyable. How exactly you do that is up to you. You will benefit in the long run by having less sick leave, lower churn and better outcomes.
Engineers are most likely to suffer from the symptoms of autism-related disorders than any other profession.
The important part your values play in hiring is how you display them. Show applicants what matters to you as a company, and be honest about it. This way the people fitting to your venture can associate right from the beginning, and the rate of mishires will be much lower. If you don't care or even lie about your values, they will find out latest on their first day, and you will end up with a bunch of indifferent wage slaves instead of motivated employees in the best case.
As part of your culture, you should consider bringing in people from other countries. There is no line of work in which it is easier to bring in foreign workers than in software engineering. Most of our tools are globally recognized, remote work is easier than anywhere else, and we have to write the same programming languages anyways. If your native language happens to be different from English, don't obstruct that path by writing your requirements, documentation or even code in that language. Keep it international, it will be worth it.
tl;dr
Don't outsource software development. Focus on eliminating low-performers. Be different than the mainstream. Pay the price for good engineers. And be honest about your values.