Hiring is Matchmaking, not Selection

Friso is the co-founder and former CTO of GoDataDriven, and previously held CTO roles in both product and professional services startups. He has been hiring software engineering and data science professionals for at least a decade. Today, Friso works as a self employed interim CTO, or technology and strategy execution advisor to startups and scale-ups. You can find him on LinkedIn or through his personal website.

When discussing hiring practices a question that you will often hear is “how do I find a React developer?”. Meanwhile, nobody has ever asked me “how do I find a mission aligned software professional who fits in our team and who happens to be capable of learning React?”. You can benefit a lot from a stronger focus on that latter question, though. Great teams are made of people with matching purpose, culture, skill, and engineering philosophy. In this article we discuss how to set yourself up for building such teams through matchmaking as opposed to standard selection procedures.

You are a SaaS product vendor and are looking to grow your team. Your product has a web based frontend and a couple of backend services, you deploy to a cloud provider, and there are some auxiliary systems humming along. Now you are looking to hire an additional frontend engineer, like everyone else in your territory. Now what?

First thing, you create a vacancy. Your frontend is built with React, so you put that in there. And Typescript, and HTML5, and CSS3, and Sass, and Stencil, and Cypress, and Storybook. Finally, you add the requirement for at least 3 years of experience, because why not. You post the vacancy online and ask everyone in the team to share it on LinkedIn and wherever else it may make sense.

A challenging aspect of this scenario is of course that perhaps 95% of all frontend engineering vacancies fit the description above. But that’s not even the biggest problem. As a SaaS vendor, your engineering team is by definition the most leveraged human capital in your business. Your product, literally, does not exist without them. That product is the number one outcome, not the technology that underpins it. None of your customers will ever endorse you because your frontend is built with React. In fact, what really sets you apart from the competition is not your team’s selection of frontend technology, but instead, their engineering agility that allows them to consistently and predictably chase a potentially volatile roadmap. Let me repeat that:

“What sets apart great engineering teams is their ability to reliably execute on a volatile roadmap, not their ultimate proficiency with bleeding edge technology”

 

The next day you receive five emails and seven messages on LinkedIn related to your vacancy. All of them are from agencies promoting freelancers, or independent recruiters with no apparent track record or prior affiliation. Some of them come with attached CVs which you casually eyeball just in case miracles do exist… In reality, while most of the CVs do fit your list of technology keywords, none of the profiles feel like a true match for your team.

What is a Match?

In the end, you are looking for candidates who are excited about your business. Ideally not because of the technology that you use (that will change), but because of the product that you make, or the people involved, or the processes that you have in place which make for a pleasant way of working. Preferably a combination of all of that. When it comes to finding a match amongst engineering candidates, you are looking for a healthy combination of four important factors:

• Purpose
• Culture
• Skill
• Engineering philosophy

You are looking for candidates who understand and appreciate the purpose of your product and business. Any person, however brilliant, can only focus on something they do not care about for so long. Complete indifference towards the product is near impossible to compensate with technology skill. If truly the only thing someone cares about is building better frontend technology, they should find work at a frontend technology vendor. For everyone else, the technology is a means to the product.

As a full time professional, you almost spend more time with your colleagues than with your direct family. When building a team you are looking to assemble a group of people who first and foremost care to see each other in a professional setting every weekday. That is what culture is about.

Skill is the foundation of computer literacy that a candidate must have to quickly enough pick up on your way of building production software. Depending on how much you are prepared to invest in onboarding, skills must be very specialised (e.g. proficiency with React) or can be more general (e.g. web development).

Engineering is the application of knowledge to build systems. Engineering inherently has trade-offs. Engineering philosophy defines how you decide between different trade-offs. You will find that it is much harder to work with people who have a sufficiently different engineering philosophy than with people who lack relevant experience.

Signs of Selectionism

I know. That is not a word. You still know what I mean. Here are five signs that your process is optimized for selection.

1. Increasing Traffic at the Top of the Funnel as a Solution

If those five CVs you received after posting the vacancy did not find you any matches, then surely getting fifty CVs would, right? Or five hundred?

There are many ways to go from five to fifty to five hundred CVs at the top of your funnel, but all of them involve some form of buying traffic. And none of them do a better job of informing people out there what you are looking for. Increasing the top of funnel traffic will put more stress on your hiring procedure but does not in any way guarantee better outcome.

2. Vacancies with Endless Lists of Technologies

When you present a vacancy with a list of twenty requirements to a recruiter, the first thing they will do is limit their focus to a small handful of these. Based on their experience and view of the market, most will be dropped in the actual search.

The worst thing that a long list of technology requirements will do is fuel your own bias towards candidates who were clever enough to list all of them on their profile. This is what freelancers do in order to be found online; not what great candidates do because they are not in the business of being found online.

3. The “Correct Coding Style” Homework Assignment

I believe homework assignments can be a good tool, but only when applied appropriately. They are however not universally appreciated by candidates. A primary reason for this is that often the effort is substantial and the outcome is arbitrary. If you give a candidate a trivial assignment and then reject them for not producing the exact result that you had in mind, you are not providing an opportunity for someone to defend their engineering philosophy. Instead, you are creating an opaque selection criterion in your funnel.

4. Numerous Closed Form Interview Questions

Engineering is about trade-offs, remember? If you expect your candidate to know the only one correct answer to a question about which data structure is appropriate for one particular problem, then you are not hiring for an engineer. Ask an engineer “what is the fastest way to search for an element in an in-memory list?” and they should look for clarifications like “what is the distribution of the input data, and which CPU architecture are we optimising for?”.

5. The “Years of Experience” Fallacy

Some technologies have existed longer than others. Some are easier to learn than others. Working on a React codebase for two years making cosmetic changes is not the same as building a new UI from scratch. The lead time for any of this is irrelevant.

Setting up for Match Making

How do you defeat selectionism? How do we improve the quality of candidates at the top of our funnel? As it turns out, perhaps not surprisingly, the essence of improving your match making is to make sure that your employer brand is effectively communicated on all channels. Do you concisely describe your purpose, culture, sought after skills, and engineering philosophy in a way that any candidate can quickly decide “yes, this is me!”?

Purpose

When it comes to describing our purpose, we often tend to assume a lot of context, such as a basic understanding of our industry or customer profile. What you really are looking for is the best description of your business case in two sentences that an engineer will understand. Be mindful of vagaries. “Pushing the boundaries of online collaboration” might sound fantastic to you, but does not mean much to an engineer; how about “we build an online whiteboard that actually works” instead?

Culture

To describe your culture, you are answering the question: what are the people like? We like to use concepts like team player, or humble, etc. While that’s perhaps helpful, it still leaves a lot to the imagination. It helps a lot to provide examples of what your culture means for the day to day. So, you can say “In situation X, you would choose to do A, not B.”. While both A and B might be reasonable things to do in your example, the decision says a lot about your culture.

Skill

Think of sought after skill as the answer to the question: what do you minimally need to understand in order to have a professional conversation with us? If I have to explain what a React component is to my hairdresser, it might take me two weeks of lectures. The same explanation for someone who has been doing Python development for the past couple of years could easily be done in less than an hour. Ask yourself: what is the amount of time I am willing to invest in onboarding someone to do their job? Then the baseline of skills required before that time, that’s what you are looking for.

Engineering Philosophy

Whenever I join an engineering team, I do not care which technologies they have chosen to apply. I care why they chose those and not others. This is no different for your candidates. The why of your technology decisions is the most concrete description of your engineering philosophy. I have had good experiences with maintaining a document of Engineering Notes, which concisely lists the rationale behind all your technology choices. This can in fact be the single most meaningful piece of content for tech candidates. Share your engineering notes with candidates.

The several pieces of content listed above should be presented across all channels that you use for your hiring funnel, including recruiters and recruitment agencies. Otherwise, matchmaking is left to the interpretation of the recruiter, the reader, or whoever the first interviewer happens to be. It is better to take these matters into your control.

Conclusion

Of course focussing on better matches at the top of the funnel does not alleviate the need for selection further down the funnel. You never get to a state where all candidates are great matches. The point is that you focus on providing candidates and recruiters alike with a better intuition for who is a match with your business. And you do this consistently across all channels.