How can a recruiter evaluate software engineers?

Evaluating software engineers can be confusing without programming experience.

It can be even more daunting if you’re a tech recruiter that has to look at hundreds of candidates and make a quick judgment based on a pdf. Let me, a software engineer, guide you.

To evaluate someone, you need to understand where they come from. Experienced recruiters learn to recognize good engineers by their communication skills. That works because some engineers decide to invest time improving their presentation and online presence.

But that’s misleading, because those aren’t necessarily the best engineers. They’re the ones that realize recruiters don’t understand what they can do, so they extend an olive branch. They rewrite their resume in a way they think a recruiter can understand.

Some tech recruiters think they understand engineers, but they can’t. They’ve never written a line code, they’ve never worked in an engineering team and have no idea of what happens in there.

Agency tech recruiters trust the job description they get from the company. Engineers don’t. For example, when a job ad says they have little technical debt, it means they don’t know how much they have. From personal experience, it’s usually these companies that have the most.

Another one is testing. Every company has testing today, but few can do it right because few engineers and even less managers actually understand testing. Most times, they have 25% of the tests they should have, and in poor conditions.

Last one: CI/CD. It’s also become widespread for a company to have CI/CD. Engineers here know that a substantial amount of companies only have CI - of course the part that makes their life easier is CD. When they have both, it’s often atrocious because it takes 30 minutes - it should be 5 - and fails half the times - it should almost never fail.

If you want to impress a candidate, tell them you have a role at a company with a pipeline that takes 10 minutes and fails 1 time in 50. They’ll sign for it and I would do it too.

The way companies do software engineering is going to be another factor, because if you don’t know how they work you can’t match engineers to the right place.

The two types of software engineers

Programming, like other jobs, changes the way you think. Things are either a 0 or a 1. It’s easier to think this way when you’re programming, but it’s hard to remember the world isn’t just zeroes and ones.

There are two types of engineers, “native” engineers and “career” engineers. Native engineers are people that have always been interested in engineering. Since they were kids, they were instinctively driven by curiosity, pursuit of knowledge and creating things, accompanied by a limited desire to go out. Eventually they got their hands on a computer, and found in programming the perfect playground.

Career engineers came to that playground much later, as part of a conscious decision. Maybe they thought computer science was a cool degree or maybe it was the good jobs. Maybe they wanted to impress girls and couldn’t bother with law or medicine.

Career engineers can be decent engineers. But, best case scenario, they’re 10 years behind with a mindset that works only in everyday situations. You have a tough programming problem, they’ll be useless because they lack the instictive, creative, relentless approach to problem solving of native engineers.

Until then, it’s hard to tell these apart. They can look like each other, and sometimes the lines are blurred. There are few indicators that you can look at, for example self-taught engineers are likely native engineers.

Native engineers are stricter about how software engineering should be done, for them it’s a matter of principle. But then, career engineers stick to a single language while native enginers are more open. In principle, because many believe you should use right tool for the job, and in practice because they already know 5 programming languages and would love to learn their sixth.

Career engineers are more interested in getting promoted because it gets them a better title and higher salary…but so are native engineers, although they are in it to get more freedom in how they work.

Native engineers are more likely to go against management, for example if there’s an unrealistic deadline. But it’s out of knowing that it will be down to them, and other native engineers, to make it happen, as they’re the only ones that can.

Career engineers can be more diplomatic, but they’re not dumb. They know they would have to work overtime too, and no one likes that.

How companies deal with software engineers

Would it surprise you if I said that 80% of engineering managers have no idea how software engineering should be done? I know a few engineers that would say “more like 90%”.

But it wasn’t always like that. This is how it has been for the last 10-15 years and it’s bound to change in the next 2-3 years.

Companies choose their management depending on what they need to achieve. In the last decade, thanks to near zero interest rates they didn’t need to achieve much.

It was worth more to have a CTO that could convince engineers to join the company, so they could sell the bigger head count to investors.Now companies have to achieve, so in a a few years will be in an environment that cares more about effectiveness.

That affected which engineers they hired and which engineers they promoted. That would be career engineers because they’re more likely to say yes to every dumb idea the management has.

That’s a huge problem. Software engineering is a profoundly technical discipline. If you make a mistake, it’s going to stay there until someone fixes it and over time it will get bigger, because more code is built on top of that.

Even, say hiring the second-best engineer from a candidate pool, maybe they’re a bit cheaper, translates to a massive loss because of that.

The hiring sprees of last years were fueled by this mechanism. Managers that don’t understand engineering decide they’ll solve the problems by hiring more engineers. But more engineers, usually career engineers, will make the problems bigger, faster.

Native engineers could solve these, but first they don’t get hired and then when they do, they’re restrained from working at their best. They’ll leave, depriving the company of fundamental skills they can’t easily get anymore and important knowledge, as most likely they built the core systems and they are the few that understand of how everything works.

To add salt to the wound, there are problems that cannot be solved by manpower. They need a proper a solution, but many teams decide by majority and have grown accustomed to risk-free solutions that only delay the inevitable. In the hope that by that time, they would have what it takes to solve the root causes.

Surely there must be companies that approach software engineering in healthier way? Yes, there are. They’re so few that it’s not reasonable to expect to land a job at one of these.

Many engineers are going for least worst. That’s the reason they only care about salary and remote work, they know it’s going to be more or less the same soup.

What if the hiring manager is really good? That doesn’t last long. In a year, the manager might no longer be there. When they stay, managers that care about their team are eventually ignored or sidelined.

The interview process

Probably you already know: engineers don’t like long processes and hate coding exercises.

What about technical interviews? Most questions are taken from public lists, I’d say about half. Native engineers don’t care, so they’re more likely to fail. Career engineers should pass, but that’s because they read the answers.

There is however a clear indicator of an engineer coding ability: how tidy their code is. Native engineers here excel, but it’s not black and white. For DevOps engineers, clean code is less important and I’ve found the best tend to be messy coders.

On top of that, consider that it will likely be a career engineer or manager looking at the code. While they should be able to recognize bad code, they can’t always differentiate between good pieces.

There’s something else you can use to evaluate an engineer: skills adjacence. For a DevOps, network engineering experience is a good indicator that they’ll know where to put their hands. Even for backend engineers it’s an important know-how that it’s too often overlooked.

Software engineering happens in layers, and understanding networks can provide shortcuts to otherwise tedious problems. For backenders, it’s more complicated. They’re in the middle so they often end up doing front-end and DevOps work. If you want to spot a good backender, you should look at what they have done in outages. If they stuck around to help DevOps, you’ve hit gold.

And for frontend engineers, the adjacent skills you can use are UI and UX. Why not backend? Usually frontend engineers are poor backenders, and when company says they want a full-stack what they really want is a backend that can do frontend…but that’s a story for another post.

Ever had a great candidate that got rejected and the reason made no sense? Career engineers won’t vouch for someone that will demand they write good code. Managers will discard the best engineers too, out of fear their lack of engineering competence could be outed.

How software is engineered

This post wouldn’t be complete without a dive on how software is engineered. A lot of non-technical people think that’s it’s like writing a blog post, because it’s about writing.

The simplest way I can explain it is that it’s like writing a book. Except, every time a word is changed, maybe to fix a typo, other words change too. To find them, you have to go through the book every time and when you change them… you guessed it, you’ll have to through the book again, until all the words are correct.

To add some depth, some words can be wrong. But you don’t know which ones are going to be a big problem, and it’s always the small ones that are the most troublesome. Imagine a single-letter typo that changes the plot, and you only find out from what people are saying about the book!

The bigger the book, the more time consuming this becomes. There are techniques that help finding that words that need fixing, such as test-driven development but no one can agree on how the tests should be made.

Of course that book is not a standalone: it references books by other authors. They too need to be right, and this time you don’t control it, you hope they’re going to be reasonable about it.

Right engineers for the right company

Perhaps you could look at their enthusiasm to figure out which type they are. Native engineers are more disenfranchised by the way of how work offered by most companies.

But why care about the difference? If you can understand engineers, you’ll be able to gain their trust, place them more easily and increase customer satisfaction.

It’s still a candidate market, and that will also help your reputation. It’s no use to ask if they know someone who might be interested if they don’t trust you.

If a company is hiring by the bucket, it’s likely they’ll want careers engineers. If they are facing tough problems, they need native engineers and it’s just a matter of getting that information from the hiring manager, seeing what candidate thinks and let them give the native engineer a chance.

Yes, this does require a good working relationship with the hiring managers, but that’s how it will be. The restricted cash flow means companies will be hiring less, they haven’t understood yet that they need to hire better.