All over the world demand for good software engineers is increasing. Which means in order to compete, you’re going to want a strategy to achieve your hiring goals. But the strategy that works is probably not what you expect.
You see, when it comes to hiring a good software engineer - whether in the U.S. or in India - it’s all about knowing exactly what you want and managing expectations.
But what does that really mean? This guide is going to tell you. I’m going to explain to you what the real problem you’re facing in recruitment is, the 3 questions you should never be asking, and how to put it all together.
Let’s get started.
YOUR PROBLEM ISN'T WHAT YOU THINK IT IS
In all my years helping companies find good software engineers, I’ve learned that there’s one truth that comes before any other, and that truth is this: Your problem isn’t what you think it is.
Most companies think their problem is that they’re struggling to find a good software engineer. This seems simple enough - you find one, problem solved.
But this isn’t actually their problem. Their problem is that they don’t have any idea what they’re looking for. And you’re probably the same.
You might wince at this, but hear me out.
When it comes to engineers, good for one company is not necessarily good for another. And like good stocks or good houses - it’s difficult to determine in advance what engineering skills will be the most desirable in the future.
For instance, React.js might be desirable now - but in 5 years, who knows. It’s for this reason that a good engineer in 2005 is not a good engineer in 2020. What makes an engineer good is something that’s constantly changing, evolving, and subject to the context of the times. This makes it very hard to pick a winner.
Therefore the number one rule you have to have is:
Know what you need.
The ‘good’ engineer is the one that’s best for your business and your business alone. This means you’re going to have to understand your business's unique needs.
To do this you’re going to need to assess what your top hiring criteria are, and what your least important hiring criteria are. For example, a high level of React.js skill might be important to you and you might be willing to pay a large amount for a candidate who possessed that skill.
In which case:
Keep doing this until you have a clear target to aim your hiring strategy at. But be careful - you don’t just want to say 10,000 things are important to you. This will (1) make your search more difficult as it is imprecise, and (2) force you to pay Amazon-level salaries for A-grade all rounders - which you are unlikely to be able to afford.
Likewise, you want to think about your business itself. What kind of culture do you have and what kind of person is going to fit/not fit with that culture? The more you think about what you need, the better the results you will get. This rule reflects an attitude that is necessary for recruitment in general.
You aren’t window shopping, i.e. looking for something vague like a ‘good engineer’. You’re looking for something specific. This might sound obvious, but countless businesses make this mistake without even realising it. They approach hiring software engineers like they’re going to the supermarket with no idea what they need - something nobody in their right mind does.
And as a result, they never find a good engineer.
A NOTE ON SALARIES
Before we jump onto the next part of this guide, I need to address salaries.
Companies in India are paying wildly divergent salaries. Amazon for instance pays close to 11 times the salary of LG Electronics. This is because salaries in India don’t reflect an accepted average, but rather reflect the recruitment strategy of the business.
Amazon wants to soak up all the best talent so they pay the highest salaries. LG Electronics wants to run engineering teams at lower cost so they pay less. Your salary offering should reflect your attitude towards cost - and who you’re trying to attract.
3 QUESTIONS THAT DOOM YOU TO FAILURE
There are three questions I’ve received over the years - and each of these questions indicate fundamental mistakes in approaching recruitment. Mistakes that will make your efforts 1000x harder.
1. Don’t Indian (or Overseas) engineers suck - why should I spend $24k for one?
This question is possibly the most common I’ve ever received, and it always blows my mind - mainly because of the assumptions that underpin it.
The first assumption is that Indian or overseas engineers are bad, and therefore have to prove themselves to Western businesses. The second assumption is that because they are bad and (often) come from a developing country, they should cost as little as possible.
Both of these assumptions are way off base.
First of all, if, say, Indian talent was so poor, why would every large business in the world be competing to draw in as much of the country’s engineers as possible? Amazon alone is spending billions to do so. Ask yourself - why would these companies spend millions to hire a bunch of engineers who were bad at their jobs?
Answer: they wouldn’t.
Second, the engineers shouldn’t cost as little as possible. In many instances, you should aim for an equivalent salary. Why? Because in the U.S. a $24k engineer isn’t particularly good. They’re probably entry-level at best. But in India, a $24k engineer might have worked at Google, and is probably quite gifted.
This is why offshore talent is so great. You get access to great engineering talent for the same price as average talent back home.
“If Indian talent was so poor, why would every large business in the world be competing to draw in as much of the country’s engineers as possible?”
2. Why should I pay $150k in the U.S. if I can get a $20k engineer overseas?
This is the opposite of the question before. Those that ask this usually feel that engineers in the U.S. are too expensive, with salaries averaging around 150k. So they think they’ll just go abroad and get someone at a low cost.
But this reflects a mistaken attitude. Yes, offshore talent will generally be cheaper on average, but you need to understand that there are pros and cons to going overseas.
For example, when you hire someone from Silicon Valley, they’ve grown up in a creative environment - one that is going to deeply affect their attitude towards work and problem solving. You can’t really put a price on that. Indian culture is different - they might be great engineers but it doesn’t mean they’re going to have that same creative energy.
This is yet another reason why you can’t boil your recruitment decisions down to money.
3. Where can I find myself a 10x engineer?
Silicon Valley likes the idea of the 10x engineer. That being the engineer that can achieve 10x more than his peers can.
I mean, it sounds good right? What business doesn’t want that?
Well there’s a few problems with this. The first is that the idea of the 10x engineer has been overhyped and memed into oblivion - do you really need a 10x engineer? Or has the internet told you that you do?
The second is that while 10x engineers do exist, they’re exceedingly rare. It’s like starting a football club and refusing to buy any players that aren’t Cristiano Ronaldo. What makes you think Ronaldo wants you? It’s the same for 10x engineers.
Every business thinks they’re special until they realize they aren’t. What do you bring to the table? Can you afford a 10x engineer? Do you have a particularly enticing problem that needs to be solved? Is your company about to IPO and can you offer them a slice of the action? 10x engineers on the market have options - what can you offer that would entice them?
But again, and more importantly - do you even need one? Because if you don’t, why would you waste your time (and resources) trying to get one?
TRIAL & ERROR IS YOUR BEST FRIEND
There’s a paradox to hiring software engineers. If you need an engineer, then odds are their skill at coding is going to make or break your project. No matter how good your other team members are, if your engineer can’t code then you’re in big trouble.
This can incline you to make the recruitment process as strict as possible. After all, you don’t want to make a hiring mistake, do you? But here’s the paradox, although the engineer is essential to your project’s success, you actually don’t want to make your recruitment process too strict.
In essence, all you want to do is test. You want to do enough testing so you can tell whether they’re a good engineer or not, but beyond that you only need to ask a few essential questions to test soft skills.
Why? Because you can only really find out most of what you need to know on the job. Before then, you can only really rely on testing. Extensive soft skills testing is just going to waste your time. Sure, you might find out they’re incredibly charismatic and easy-going… But can they actually code?
At the end of the day this is all that matters. So don’t waste your time and focus on this instead.
WHAT ACTUALLY MAKES A GREAT SOFTWARE TEAM?
Every startup wants to be the next Amazon. They want to explode onto the world and gain unrivalled levels of success. This attitude leads them to want to have the best software team on the market - an Avengers level lineup strapped with back to back 10x engineers.
And while this is a nice idea, the reality is a little different. Not only will most companies not achieve this goal, most companies shouldn’t even be aiming for it.
Instead of Amazon, you want to be more like IBM - big, successful, but boring. They do the basics really well, and not a lot more. That’s why they’re still here and still competitive.
This attitude is not only more realistic for a prospect, but it will also help with your attitude to hiring developers. Because it will make you hire smarter.
When you aim for the 1-in-a-million engineer, you end up looking for a long time, then spending most of your budget on one person. To fill out your team, you have to find cheaper, lower-quality engineers to pad out your workforce. This means one person on your team might produce amazing code, but odds are, everyone else is going to produce headaches.
Instead of aiming for the A++ candidates, fill your team out with B candidates. Why? Firstly you’ll be able to afford them, and secondly, they’re good enough. They aren’t amazing, but they consistently produce code that is good enough.
This will leave you with a consistently productive team. What could be better than that? When I say aim for IBM as opposed to Amazon - this is exactly what I mean.
PUTTING IT ALL TOGETHER
To wrap up, the easiest way to hire an engineer is to know exactly what you’re looking for and manage your expectations.
Don’t buy into the hype of 10x engineers, find a team of excellent B players, and pay them what they’re worth.
