How to Hire Exceptional Engineers

An approach to hiring exceptional engineers by focusing on six key traits.

By Gareth on 4th Feb, 2025

I have been involved with engineering teams as a junior contributor all the way through to lead over the course of my 10+ years in engineering. Having made a career shift from Subsea engineering in to Software engineering I also have the added experience of how engineering teams operate in a more traditional environment vs ultra modern. I now feel like I have a good sense for what makes a good engineering team and who makes for an exceptional engineer.

I also happen to be entering another period where I will need to build an engineering team and so I want to outline what I think is the best way to do that.

The first question you need to ask is; what makes and exceptional engineer? My answer to this questions is:

Communicates ideas and systems clearly (verbally and in writing).
Curiosity about new ideas and technology.
Cares about their craft, can point to projects they've put a lot of effort into.
Hunger/ambition, wants to grow and work on projects that make a difference.
Humble, able to admit when they don't know (small ego).
Pragmatism, able to get things done quickly, then constantly improve it. i.e. Make it work, make it right, then make it fast.

I'd argue these are the key characteristics of a great engineer.

If you can find a candidate who appears to have all 5 characteristics then you're in luck! Finding engineers like that is not easy. Note, I say "appears to have" on purpose because an interview process can be gamed. We need to re-assess successful candidates after some period of actual work to see if they are still the candidate you thought they were, more on this later.

But how do you actually find those people?

Well first you need a funnel. Write up a job description and post it far and wide. Next you need to design your interview process to assess each candidate for these characteristics.

In an interview process you essentially have two methods to obtain inputs from the candidate which will reveal their characteristics; questions and tasks.

I will now outline questions and tasks associated with each characteristic which can be used to design the interview process.

Communicates ideas and systems clearly (verbally and in writing).
- Question: Ask questions that get the candidate to talk about how some tech might evolve in the future. Should be something they clearly know about already from their experience.
  - What are you looking for? Does their idea about the future sound coherent? Does it sound well thought out. Is it logical?
- Question/task: Ask questions that get the candidate to describe a complex system they've worked on in the past.
  - What are you looking for? Do you understand the system they are describing? Can you relate to it? Can you ask secondary questions to go deeper? Alternatively, ask the candidate to write a 1-page document explaining a complex system that they worked on. Allow for diagrams.
- Question: Ask for examples of documentation or content that they have written.
  - What are you looking for? Code comments, API documentation, blog posts, tweets. Anything where the candidate has tried to explain something publicly or to other engineers.
- Question: Ask the candidate to explain how some critical piece of tech or tooling required in their tech stack works.
  - What are you looking for? At least a high level description of tech in question that is clear and concise. Bonus if they admit they don't know to some parts for point (5) but if they can't even attempt to describe it, this could be a red flag.
Curiosity about new ideas and technology.
- Question/task: Is there a controversial piece of technology or tooling in the engineers line of work? How do they feel about that technology? A good example for software engineers, at time of writing, is AI tooling. Do they use Cursor or something similar? How much are they experimenting with LLMs in their code?
  - What are you looking for? A genuine curiosity about the tech/tooling in question. Pessimism is not necessarily bad if they have logical reasons for it. Ideally they have some experience experimenting with it and can talk clearly about the pros/cons. Alternatively, in a challenge project ask them to use a piece of tech that is very new, ask them what they thought about using/implementing it.
- Question: Ask if they build side-projects? If so how do they do that? What tech do they use?
  - What are you looking for? Side-projects as a way to play with new tech. This is typical of someone who is genuinely curious. Note, side-projects are a luxury for someone with time, older engineers may not have great answers here because they are more likely to have family and other obligations which make extracurricular experimentation difficult. In this case, ask if they did this in the past, when they were more junior.
- Question: Ask if they have championed and/or implemented a new tech into a project they've worked on.
  - What are you looking for? If they don't build side-projects this is a good follow up question. Have they introduced new tech/tooling to projects they've worked on in the past.
Cares about their craft, can point to projects they've put a lot of effort into.
- Question: Ask the candidate to describe a project or something they worked on that they are proud of.
  - What are you looking for? A genuine care about the quality of the thing they are describing. Can they point to something specific they worked on that improved the quality of that thing.
- Question/task: Ask the candidate to describe how they have made a system more stable/robust. e.g. for a software engineer, ask them to describe a refactoring effort, some testing they put in place or some DX improvements they made. In addition, this could be combined with a task where you ask the candidate to improve an existing project in some way, by adding tests or improving DX.
  - What are you looking for? You are looking for some significant effort to improve a system/project that is not adding new stuff like features etc. This is likely to be 'back of house' type work. Re-organisation of code, improvement of tooling, robust testing that has prevented issues, etc.
Hunger/ambition, wants to grow and work on projects that make a difference.
- Question: Ask the candidate; if you could work on anything right now and money was no object, what would you work on?
  - What are you looking for? What is the scale of this thing they would work on? Is it small minded or big minded? Is it related in any way to the work they currently do? If not, this could be a red flag. It doesn't have to be exactly, but it would suggest they don't love what they're involved with in general.
- Question: Ask the candidate what they want to be doing in 5-10 years?
  - What are you looking for? At least some ambition. It's also a good sign if the candidate is humble here. It's not a great question but can lead to some interesting discussions. Alternatively frame the question more specifically, ask, if you were to guess how your career will play out over the next 5-10 years, how do you think it will go? You are looking for some foresight. Some evidence that they are thinking and planning ahead for growth.
- Question: Look at the candidates career history and ask them how they have got to where they are now. What struggles have they overcome? Have they been promoted internally before?
  - What are you looking for? Evidence of previous growth to overcome challenges in their past. How much have they had to work to get to where they currently are?
Humble, able to admit when they don't know (small ego).
- Question: Throughout any interview look for opportunities to dive deeper on anything you talk about, keep asking them to explain deeper and see how the respond.
  - What are you looking for? At some point they will hopefully just admit they don't know. If they start to talk too vaguely, or worse, confidently, about something you know to be false, this is probably a red flag. Challenge them on this and see how they respond.
Pragmatism, able to get things done quickly, then constantly improve it. i.e. Make it work, make it right, then make it fast.
- Question: In a sprint to release a feature or product under a tight time constraint, what has been a tough trade-off decision you have had to make and how did you make it?
  - What are you looking for? Simply, pragmatism. Were they able to put 'perfect' aside so that the deadline could be made?
- Task: A challenge project that requires the entire allocated time to complete a small part of a much bigger project.
  - What are you looking for? The ability to complete the task without going too far. i.e. over-engineering. The task could also be designed specifically as something that is easy to over-engineer.

Scoring system

The above questions and tasks should be used to calculate a subjective score from each interviewer. Give the candidate a score out of 5 for each characteristic. So the perfect overall score for a candidate would be 30. For example, say you have 3 team members interviewing a candidate, each interviewer would score the candidate out of 30 and an average could be taken. If the candidate's score is not above 20 you should probably pass on the candidate. The threshold score is really up to you.

The scoring system is more of a guide. A way to give each interviewer something specific to think about and look for. There will always be exceptions to the process where a candidate may not score highly but your gut tells you they will be a good hire.

Re-assessment, keep or let go

There needs to be a 3-month review scheduled at the time of hiring. It's all to easy to assume you will do this review and then forget about it or think they are doing well enough to justify skipping it. This review should be strictly performed regardless of how the candidate is performing. If on reviewing their 3-months of work, they do not meet your standard, you must let them go. It is difficult for all involved, but it has to happen to keep your team at a high standard.