Part of my octopus job is often to run a team - which sometimes means creating it, and so be in charge of hiring. While I'm no hiring specialist, I did hire around 20 developers during my career (depending on many time you count Stéphan), and so I developed some opinions about it.

Process

Write your hiring process down, and communicate it (as much as possible) with the candidate, already in the offer if possible. Name the steps, the people involved.

Give as many information as you can in the job posting - about the tech but also about the team (how many people? seniority?) and the product (what is it? what phase are you on?). Be clear and upfront about the remote status (none/hybrid/full remote)

My current one is generally a variation of:

Job posting

As outlined above, I try to be complete there - notably I mention who is in the team and our product phase.

I still ask for both a resume & a motivation letter - I like to understand why people apply (aside from "I want money to eat" which is completly ok)

I try to spread it broadly - linked in, company site, network, job boards if it means I can reach people I cannot.

Resume based selection

I take the applications and (if I get enough of them - it's not always the case) I filter them to keep around 5 - less is missing opportunities, more takes too much time to interview.

Interview 1

Who? Candidate, Me

• Me: explain the company, demo the product, describe the team
• Them: voiceover on their journey, reasons they want to join
• I try to select around 3 people out of this phase

Interview 2

Who? Candidate, Team, Me

• Come with the team that prepared some questions (they have my notes from the previous meetings for that)
• They present themselves quickly, ask a couple of questions
• Candidate can ask they own questions too

Interview 3

Who? Candidate, Boss

• When relevant, this is about "meet the CEO/head of X" stuff

From there we move to offer, etc.

Money

That's a tought one for me. One one side, I'm convinced that companies should "shoot first" (ie come with an amount or range) - mostly to avoid everyone losing time, if the expectation of one side are widely outside of the other range.

On the other side, in the small environments I work in, while we do have a job description, the person makes the job, not the other way around. This means I can generally accept someone too junior or too senior for the role or better at one aspect than other - it just means I'm going to shift the responsibilities around between the new hire, me and the team.

This makes giving actual meaningful range (ie not 50-150k€ or something stupid like that) complicated.

In addition, in Belgium you may end up with people under either employee or (fake) freelance status applying for the same position - and the way you frame the salary is very different from one case to the other.

In a nuthsell - I think companies where people fit a role with already 5+ people in it should have ranges and disclose them. Teams of 3-5 total with huge seniority or role differences are a bit a different topic.

Fun fact, when I'm applying as a freelance, I play that but on the opposite - which is that I'm going to disclose a range early in the process if the company did not - just to avoid losing time.

Juniors and Seniors

Ratio

I like coaching young devs... but you need to have your cadre in place. I generally feels like a 3/1 ratio is sane - that is three seniors for one junior.

This is consistent with the interests of the junior, the team and the company:

• As a junior, you want to have mentorship available - having several people around able to answer questions make sure it is (even with holidays, people being busy, etc)
• As a team, you want to mentor - but you also need to do your own tasks. Knowing that you are not the only person able to do it helps a lot.
• As a company, long term you want people to grow - so investing in the mentorship is very valuable... but long term you need to ship - so you want your team to spend a majority of their time on that

While this ration may seems high, if we look at demographic it should be easy to reach - depending on definitions, a junior developer will have less than 3 or maximum 5 years of experience. Out of a careers that is supposed to be 40 years long, that's between 1/10th and 1/8th of it - so should be easy to reach.

Hiring

Hiring a junior is making a bet on someone's capacity to learn and improve (massively) in delivery capacity in the next 6 to 24 months. Why? Because most people are not "operational" when they arrive - this is not a lack of will or a mistake in their training - it's just the way it is. Learning the ropes is something you do on the job - it has been for me and for everyone I know.

So we don't evaluate for what they know (we don't really care), but for what they can learn/how they think. It's tricky but it's the only thing that make sense.

What I found out being one of the most critical stuff is where they are on the "asking questions too early" vs "asking questions too late" spectrum:

• I want them to look for solutions, try stuff by themselves before asking
• I don't want them to spend two days banging their heads against a wall either
• I don't want to "checkup" on them too often as it's disturbing their work

Network effect

I've been hired by my network several time, and I've hired that way several times too. It's good and bad:

The Good

You're working with some "known values" - you know the people/companies the person has been working with/for, and this generally gives a good idea of the perimeter of the person capacity - ie you have an idea of the bottom line.

More often than not, it means hiring someone "similar" to me - so chances are good we are going to understand each other pretty easily.

All in all - it's a low risk option.

The Bad

It creates very homogoneous teams where everyone thinks a bit the same. As I grow older (damn) it also generate a sort of "cohort effect" of working with a bunch of other 40ish years old. We did mosly the same kind of stuff at the same time.

It creates a bit of an internal culture, but not always in a good way as it could stop "outsiders".

Now

I'm not blocked on any of those. I hired 5 people recently with no (or almost none) network effects and it worked great. I've also learned to diversity my hiring channels to reach people I would not normally be able too (ex: women via dedicated outreach program).

That does not means I'll never hire someone I know again, but at least it should come among a more diverse set of options.

Be honest

This is the other side of the coin to my advice to candidate - "be positive but don't lie". I apply this as the hiring manager. I try of course to paint the company/team in a good light (after all if I don't like it, I would not be there), but I stay honest. If things are complicated, I say it, if I don't know something I say I don't know, if we are not super mature in some aspect, I say it.

In the end, the candidate will join the company - and they'll make their own opinion. Painting an irrealist view of the company just increase the chance of the person leaving (possibly fast) something that's a loss for both sides.

Involve the team

That's probably the easiest one, and one I don't see applied a lot. Basically, bring the people that would be the candidate close collegues to one of the interview. Logic here is that both sides will learn something:

• The team can now have a say in the decision about a future colleague
• The candidate can forge a better idea of the people they're going to work with

What I usually do there is asking team member to present themselves and prepare a couple of questions, but the point is to trigger a conversation in the future team.

Technical evaluations

I'm generally wary of technical evaluations - mostly because the two most common types are for me problematic:

• Whiteboard: Asking someone to code something "live" looks artificial and stressful as hell to me - like it does not represent any real life situation (when is the last time you had to solve a problem alone, in 20 minutes, with someone looking at your back? Mine is University) and it may lead very good developers to fail.
• Take home exercise: I don't think we should ask people to work for free as part of our hiring process - so they can be ok if we speak about let's say 2 hours of work, but not more. Even there I think we should compensate for the time spent (but that's often complicated)

What I've done that I like:

• Ask the candidate to come with some code they have written, send it before, and walk us through it. It's their code, they picked it and we have a discussion similar to a PR one.
• Get the candidate to come work with the team for 3--5 days (paid of course): this is golden... but only works with freelances that have the time and status to do so. I did this only a couple of time, but generally by day 2 you know if you want to hire or not (and so does the candidate).
• For senior devs, ask them about good and bad experiences they have. I generally look for understanding of tradeoffs - our work is full of them, so it's all about understanding the ones they faced and the choices they made - not in terms of right or wrong but again it terms of what they did prioritize at the time and why.

Conclusion

I still think the interview process is broken - and I don't have a lot of ideas to fix it. My hiring process is still too much based on vibes (if not only mine) - but "factual" alternatives I've seen are generally equally problematic.

This being said, I've been mostly successful in my hiring process those last years - as in managed to create good teams that are working together quite well.

Opinions most welcome!

Opinions? Let me know on LinkedIn!