Hiring is not about shopping for skills, but exploring the potential for a good relationship with someone. What the person knows today is important, but you need to look at it not as a simple snapshot of instant productivity with specialised tasks, but rather as retelling of past experiences, decisions, choices and efforts. Look at a candidate's knowledge as their personal garden: the seeds they chose to sow; the quality, the variety and the constance of the care they showed for their burgeoning understanding; how deliberate the knowledge landscape they designed for themselves ended up being. How much of this garden is the fact of a caring hand, and how much is the simple fruit of external factors? People's skills open a window onto who they are, who they used to be and who they ambition to become; this is your chance to meaningfully engage with all of them at the same time.

A team is a delicate jigsaw puzzle you build over time. Sometimes, people leave, sometimes, people join: it is in constant flux. Every time such a change occurs, the structure and balance of the team change as well, every time this occurs, the team is grown again. Key dynamics are gone, born, transformed, challenged or strenghtened, and the care this new teams needs is also different to that it used to require so far. In this context, hiring someone is akin to hiring the team again. Once you understand the individual, focus on the group dynamics that exist in your team, and those demonstrated and suggested by the candidate. It is this new team you're about to hire; be certain its members will work well together, and that you want to work with them.

You might feel sometimes pressure to hire: a project that needs to be done or a budget that won't come back if not spent this quarter. So you start recruiting, reviewing applications and interviewing candidates and after some time, you feel like you should be hiring one or some of these people. Whilst this can have a happy ending, this approach very often leads to mutual disappointment between you and the new hire, as well as affect negatively your team. The reason is that you never need to hire. Simply because you have the budget or are in the middle of a recruitment process doesn't mean you should be hiring. Projects to deliver, budgets to spend are not reasons to hire, they are useful excuses to execute on a long-term growth plan for your team.

In this perspective, recruiting is very much about timing: you get to interview only those people who found themselves available at the moment you were reaching out. This says nothing about their qualities as additions to your team, and their being available should not dictate that you act on that. Sometimes, it's worth closing a recruitment process without hiring anyone. What about the late projects and the budget? Immediate needs call for immediate solutions: hire a contractor. Long-term plans, like shaping your team, are a poor fit for pressing decisions, and evolve in different planes: a team is the fruit of strategical thinking, whereas projects thrives on tactical decisions. Feeling pressured to hire only means you should refrain and wait.

What the three points above tell us is that the moment you start recruiting, you should have a very clear plan in mind. What have you seen in the dynamics of your team that need changing, mending or strenghtening? Can you picture a desirable situation, that would address all this? Then, what personal qualities would you wove in the fabric of your team to realise this idea? It's important to note that none of these questions involve borrowing answers from others, but demand that you seek in your own perception of the situation the fragments of understanding you can compose a solution with. Knowing what you want helps convey this understanding in the job ad you publish, express it during the interviews and consider the possibility of a relationship on meaningful grounds.

Understanding can't be made of borrowed opinions and in this instance, this can lead to hiring the wrong people, for the wrong reasons and with wrong consequences for the team. This doesn't mean you shouldn't ask others for their opinion, but there is a difference between trying on new perspectives like clothes to see the fit and dressing up your views with pre-made thinking. Intellectual cosplay never pays off.

Now, just because you know what you want doesn’t necessarily mean you know what you need. Having developed your own opinion gives you an excellent starting point to approach the recruitment from but it will only fully blossom with cross-pollination. This means remaining open during the interviews and trying to see how each candidate, in their own way, can transform the situation and re-state your understanding in different terms. This new vocabulary spells out what you need, which can be different to what you want. A candidate might present personal qualities you didn't think could rearrange the dynamics of your team for the better. This doesn't invalidate your understanding, this on the contrary gives you the opportunity to grow it even deeper and, so to speak, see the dynamics behind the dynamics, including your own. It puts you back in the picture, so you can once again take a few steps back to see an even bigger picture. It literally gives you a new perspective. This is always what you need, and this is what you should always strive to want.

The value of answers being a function of the quality of the questions asked, relying on a quiz to explore the technical aspects of a candidate's experience can only yield puzzle-like answers. Technical questions that are simple enough they can fit in a quiz-like format are bound to deliver little value anyway: does the candidate know the basics of language X? Can the candidate implement a classical algorithm under the pressure of a clock ticking? All this you can uncover by engaging in a conversation during the interview. Both of you are technical people, you might end up working together: simply exchange on these topics like technical people tend to do, that is by expressing their opinions. If you have a distrust of ORMs, then ask how was the candidate's experience working with them, and do some digging. Does the candidate believe that developing front-end solutions with a broken language such as JavaScript is a problem? Isn't a micro-service architecture bound to end up as a monolithic nest of intertwined functions? You and your team do things and think in certain ways, don't hesitate to state them clearly, and expect to be challenged in return. This will demonstrate true understanding of the topics, and genuine experience with them, as opposed to an ability to memorise answers to typical interview questions.

Asking for the realisation of a technical case, if it sounds ideal on paper, can prove difficult to achieve in real life. The case needs to go beyond the basics, and must remain open enough that the candidate can express opinions in the code. This implies that the case is also large and complex enough to allow for multiple, interesting solutions to be devised, and this in turns suggest it will take a long time to complete. A candidate accepting to go through a long, difficult case like this is certainly showing interest for joining your team, but not everyone can afford the time, including people you might want to hire. Putting together a case that keeps under a reasonable amount of time to complete (typically around 4 hours) and yet manages to spark complex thinking is not impossible but fairly difficult to achieve.

As suggested above, a technical interview does not constitute a brute assessment of technological prowress, but an opportunity to communicate around those. No matter how good a candidate is, if they can't communicate well with others, the value of they can bring to the team will be greatly diminished. As an interview can be a fairly stressful affair, and this can certainly limit a candidate's ability to express themselves as much as they would in a more relaxed, day-to-day setting, try to make the technical interview a plural media exercise: ask the candidates prepare a write-up of their solution to a given problem, and have them take you through it during the interview. Should their nerves negatively affects their oral explanations, you will still get to see the potential through the written support they will have prepared. This support can be anything, from a deck of slides to commented code (or, even better, literate programming-style code). The candidates should be free to pick what they believe is the best medium to help them drive and illustrate the discussion.

You might think this kind of setup requires a certain level of maturity only found in experienced candidates, but this is actually an excellent fit for people just starting out as well. As by definition they haven't covered a lot of ground yet, engaging in a series of direct technical questions can only end prematurely. Asking them instead to think about the concepts they have been manipulating so far, and how they would use them, will allow to talk about how they think rather than focus on the tools they possess.

The recruitment process you're engaging in really works both ways: as much as you will hire someone, you will get hired by that person. You don’t give a job, you offer an opportunity for mutual growth. Make it so: consider your job ad as the CV of your company, department and team, and keep in mind that what you offer is the product of your experience on this market and in this industry. The same way people's skills are a manifestation of their experience and background, so is the technological and social context you're ready to offer. There is a reason you're still stuck with some old technologies, and there's a reason behind your ambition to develop a data mesh; there's a reason why your team is organised by business line and follows a semi-agile methodology. None of this is perfect, but all is the fruit of continual effort to address shortcomings and accidents as well as to capitalise on successes and strengths in your team.

Show your strenghts and your weaknesses, the story behind a ugly scar is always more attractive than its existence suggests, as it tells about genuine experience and about who you are. It makes what you offer very real in the candidates' mind, and they will start thinking about what they could offer in this context. Not only does it place you ahead of the pack, as they are already picturing themselves in your team, but you get to simply remain transparent, and expect the same in return.

Not everyone needs to see the candidate. Some companies insist on having the candidates go through 4, 5, 6 or even more rounds of interviews. They meet recruiters, then a Technical Lead, their potential future colleagues, the Product team, Finance, Customer Success and all sorts of people from all across the company. Put simply, in my experience, having more than 3 stages is but misplaced pride. Such a layered, long-winded series of steps doesn’t say anything (positive) about the quality of your hiring process, but says a lot about how you hold yourself in high regards. You only need to understand how you feel about the person, how they feel about you (as a company and a team leader) and how you both feel about working together. Don't spoil a simple recipe by inviting too many cooks.