Posted on
How We Should and Should Not Hire

Why is hiring so difficult for leaders? Well, there are many moving parts. Also, the decision comes with long-term implications. We can’t predict how new members will interact with the rest of the team — especially under ever-changing circumstances.

Introducing a new member is a significant addition to a small team that will consume ample resources before we start to see any benefits. Hiring a good developer and onboarding them can each take several months. Ultimately, every hire (or firing, in the worst-case scenario) requires a considerable amount of financial and motivational resources.

So let’s take a step back. Can we avoid hiring someone altogether? Instead, we could dedicate those resources to optimizing internal processes or the product hypothesis flow in order to decrease the team’s development load.

We can consider internal delegation as well. How can we make the system more effective by forming a team out of an existing group of employees? Why not promote someone internally? What processes should we implement to help developers reach the level required for a certain job more quickly?

This is worth thinking about on a regular basis.

If we do decide to hire, there are some considerations to keep in mind:

Why do we want to hire? What do we really do as a team/company? What problems will the new member solve? Is this position even interesting to candidates? If not, how can we make it interesting?

Addressing these questions will provide transparency to the hiring manager and recruiters who may be assisting you.

Moreover, we should tailor our interviews to match our hiring goals. Since our goals may differ from those of FAANG companies, we shouldn’t merely adopt their interview processes in the hopes that they’ll help us too.

Now let’s get to the actual interview. Try to avoid having a complicated process that features too many steps, takes too much time and comes with technical aspects like puzzle-solving.

What do we actually want to learn about the candidate? As always, it boils down to intellectual work. If their experience in a particular area isn’t strong, it doesn’t make much sense to test them on that topic.

I use a lot of whiteboard interviews—not to see whether candidates know special algorithms but to confirm their familiarity with basic language data structures. When I hired team members this way in the past, they turned out to be pretty good. However, I didn’t get any information on the candidates who failed to make it past this stage. Maybe some of them could have still been valuable team members in a different setting.

Companies often look at the entire field of candidates in order to choose the best one. We don’t need to do this. We simply have to find the first candidate who suits our requirements. Of course, we should know those requirements before the interview takes place. Otherwise, that can affect our decision-making.

Finally, I try to reflect on a few key questions that I hope to have answered during the interview process. Please note that these are based on my experience and preferences:

Do we share the same basic and ethical values?

  • How does the candidate fulfill the needs of this position?
  • How can the candidate help the team rebuild its responsibilities?
  • Will the team enjoy working with this candidate?

Additional reading:

  • How to make a team from a group of people. The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni, Amazon

Previous article reference:

Edited by Vinh Cao.

Comments & email subscription


I’m Alex, a software engineer with technical and engineering management experience from startups to middle-sized and big-tech companies. Loves to make effective and friendly team processes.

You can freely drop a message to [email protected] or linkedin.com/in/aptakhin to greet and ask questions about any topic.

I’m also mentoring pro bono at meander.so/m/aptakhin