Ask HN: Tips for a new team lead who is hiring

I've been interviewing software engineers for around 15 years. In total, I think I've interviewed around 600 people in a range of roles.

My main advice is to listen to your gut instinct. Things that mildly annoy or worry you in the interview will probably come to dominate your working relationship with them. Don't assume you can fix someone's flaws after they join. Get other people to give their gut instinct too, and everyone has a veto. When a new hire doesn't work out, it's extremely expensive and stressful for you, the person themselves, and the whole team to manage the situation, so it's better not to hire in the first place.

This means you'll need to be patient. On average, I've needed to interview 30 people to make 1 strong hire. A few extra months looking for the right person will deliver far more long-run productivity. However, treat every candidate with dignity - get back to them promptly with helpful feedback.

The best hires I've made have come through personal connections, and niche job boards. Most recruitment consultants are working merely for short-term commission, and don't care about your or the candidate's long term interests.

Don't underestimate how much work a junior causes so it's a valid risk. Most importantly, hire for someone you like on personal level and could go on for a drink.

One of my past managers said i shouldn't have to be "friends" with any of my reports and only look for their output qualities. I disagree with this. Having a good connection with your teammates will make your life as a manager so much easier and if you can decide who will be hired into the team use this.

Here’s how I did this at my last job at a growing start-up.

My background is in engineering, but I found myself responsible for hiring people outside of my expertise for roles like marketing, sales, finance, and operations.

The process:

1) Define the role. What do you need this person to do day in and day out?

Write the exhaustive list of tasks and the exhaustive list of behaviors.

Task: Write code that does X.

Behavior: Write maintainable code I can understand.

2) Stack rank the tasks and behaviors. What is the number one most important thing? Decide on a cut-off of must-haves, step-ups, and nice-to-haves.

Must haves: you’re not talking to a candidate unless they’ve shown they’ve done it.

Step-ups: a candidate is good to move on if you think the candidate can reasonably achieve this in 6-12 months.

Nice-to-haves: between two equal candidates, you’re going with the one who can do these things.

3) Level the role. Given what you need this role to achieve, is this a staff, senior, junior, etc? Hopefully this is straightforward. Sometimes this can be between levels and that’s ok. You should decide/work with HR on comp here too.

4) Build your interview flow. Who in your org or team will screen for must-haves and step-ups, run your technical assessment, run your cultural assessment, and run your structured interview for leadership behaviors? Assign responsibilities, come up with questions, and bucket those into each interview section.

5) Decide on your rubric. After each interview, what do you want to find out? Make sure each interviewer knows the questions they need to answer and send to you after each interview.

That should be most of it. I’d be curious to hear everyone’s feedback on this.

PS: My biggest piece of advice is to not settle. If you go with a mediocre candidate to wrap up early or to save money, you’re going to miss out on special people who may have changed the trajectory of your team.

* ensure that the person can acknowledge mistakes and handles criticism/feedback in a positive manner. obviously that needs to be communicated in a fair and responsible manner

* do you want to have a beer/coffee/social interaction with the person outside of work? does not mean you will but you will need to build a relationship with the person

* make sure you know what you are expecting from the hire, write that down, not in MBA speak but in a way that you will be able to review the list in 3/6/12 months

* know you are going to make mistakes, be honest about it with the team and keep on improving. it never ends but it is such an awesome journey.

(no capital letters, speed has a price :D)

Hire for someone who works most effectively with your team. Communicate to the candidates what it is actually like to work on your team and set expectations accordingly so you hire the person who actually wants to do that work.

Hiring juniors is always a worthwhile risk as long as they have the necessary support to grow into being effective in the role. Just don't hire a junior because you are afraid of hiring someone senior as your first hire.

Effective teamwork will always outpace individual contributions.

Just remember, a junior is someone who has little work experience, NOT someone who isn't qualified.

If you hire someone that knows the work but just needs experience you will find yourself working with someone who is engaged and enthusiastic. If you hire the latter you will spend all of your time holding their hand.

Here's a long story, tldr: It will be a bumpy ride but can be very worth it under the right circumstances.

A couple of years ago, I worked at a small company where the management asked me to Interview someone for a Junior role. They were a recent graduate. They did not do that well in the technical interview. Failed to answer some very basic questions, even when given the option to google the answers.

So my review for the candidate was: If hired, do not expect any useful (read: big feature) contribution from them for at least 2 months or so. Expect at least a couple of major screw ups in the first month or so. It would have been safer for us to hire the guy with 2-3 years of experience for that junior role at a slightly higher cost.

The management hired them anyway. The first few screw ups did happen. They messed up the master branch with some broken commits. (Not sure why we did not have master branch protection rules back then). They did not know certain basic things and needed a bit more hand holding by various team members. We had to make them rewrite their bad code on every other pull request.

But very quickly, the new hire became a very useful part of the company. I was so glad to be wrong about my interview. They were happy to test out and automate a lot of the manual tasks. That would have costed us a lot of "senior developer time". The product needed to work on windows, linux, mac, mobile devices etc.. So a lot of things needed to be tested. They created so much documentation and examples for our product, that we ended up finding many bugs in our own code. They fixed a lot of those minor bugs too and came up with new features and implemented them. Honestly, the product got most of the polishing because of them.

I am not too sure what exactly I learned about interviewing juniors from this. But I can tell you, In all of the small companies I worked, there were a lot of badly defined tasks that needed to get done. Juniors can grow themselves AND the company by fixing a lot of those things. I think it is more about "What work do we have that the candidate can / will get done?" As opposed to "Are they a good candidate for us?".

It's a short one but has always worked.

Hire slow fire fast.

I'll put just one tip here: a 'maybe' is a 'no'.

In my experience most bad hires that don't work out in the end were a 'strong maybe' and for whatever reason I convinced myself to still go ahead. One common reason is hiring fatigue, when you interviewed a lot of people and just want to close the position.

If it's a 'maybe', identify why it's a 'maybe', and schedule an additional round where you get signal on those specific topics. If at the end it's still a 'maybe', then it's a 'no'. Doing an additional round may suck, but it's less of a suck (for both sides) than firing the person after they left their previous job, started working, completed onboarding, and it's their last week of probation in your team.

Good luck!

I'll tell you one thing I got taught in management training that rung true to me, and had I known this earlier, would have saved a ton of grief. Your technical team will be gauging the candidates technical competence. You need to focus on other things .. most important being grit, ability to be a team player/collegiality and communication.

A few quick thoughts:

1. Make sure that your focus is aligned with the expectations of the management. You are probably right that the team needs more members and that you should hire some, but it is quite possible that the management expects other short-term results (either in preference ot at least in addition to growing the team).

2. When hiring, there are two equally important areas you need to figure out about each candidate: a) their experience and skills in relation to the requirements of the role, and b) how well would they fit within the existing team. In your case b) might easier since there is only two of you, but make sure that you keep that in mind when interviewing.

3. When assessing the technical ability -- the a) in the above point -- keep in mind that your interviewers are at least at the same general skill level as the candidate; and ideally higher. It is very difficult for a junior to interview a mid-level candidate, and basically impossible for a senior one; the same patterns repeat on all higher levels. This also applies if an interview is of a similar level, but in a wrong area - a senior Java developer will not be able to interview a senior Python one, and vice versa.

A bit tangential perhaps but a key thing in interviews is always dig a little on the 'why' of a question. Most can rote learn the 'what' but you want people who know 'why' whether they're junior or senior.

It may seem obvious but I've seen some otherwise good candidates get undone after an initially reasonable "you mention working with X, what is X" exposes only a superifical understanding of "why X"?

e.g. candidate mentions upgrading a service from JSON to gRPC/binary, why..?

Most will claim "it's faster" but you want to know why it's faster. I've found digging a little is great for finding good juniors but also 10YOE who can't explain UDP vs TCP to a level that matches their background. It also exposes insight to their underlying ability to reason which is, ultimately, what I'm looking for.

We're in an age where, increasingly, knowing the what is automated but knowing the why is still crucial - if only to interrogate the LLM on its decisions.

Hunger. You can’t teach it. You can’t train it. You might be able to rehabilitate it if the individual is in a low spot.

Consider all of the work now. Not just the “work.” Team lead. Is your team ok? Your team does the “work,” you are part of the team, but don’t forget that keeping a team running smoothly is also work.

Update your availability calculations in your head. You were estimating 70% of your day was going to be actual work, with 30% towards meetings etc? Time to reduce that 70%. It’s ok, that’s why you are growing a team - to get more done - but it isn’t free.

Understand the company, the product, the business model and the vision. As a lead it's expected from you to be autonomous and take good decisions. I always used my sincere common sense to find answers to these problems and often i took my time to research, ask others, overall i tried to understand the domain as best i could while ignoring the impostor fear, and then things start falling into place. If you like to code, you know how code should be written. If you respect yourself, you know how to handle others. If you ever had your own company, you would know how to treat others' company as well. Don't hire from a dry feeling to step up to your lead role. Hire because you have arguments, hire because the company needs investment in fresh blood everyone and make it fun for everyone

Personally, I’d begin from figuring out company strategy and how the team will deliver on it and what KPIs I’d use to measure the team’s output. I’d then map out what are the strengths and weaknesses of the team including skills gaps. This will include things like seniority, ability to deliver at an individual level. Since there’s only one team member so far, this would be more of a plan/roadmap of the team you’d like to grow into.

Junior members are great at knowledgeable tasks but may lack real-world experience to understand tooling, deliver quality work and put something into production (not always - there are exceptions of course). Since you’re in R&D, this may not be a huge factor/risk so junior engineers may be a good fit.

I’d be happy to discuss further over a call if you’d like. Happy to share my experience growing teams from 1 to 200.

In my opinion hiring a motivated junior is a good decision. Onboarding new developers is the harder part of the process, regardless of experience level. If you are just in a new established startup, the risk might be that the whole development process is still unstable and tasks you might assign to them are going to hit a bunch of unknowns/undocumented parts for the hire and you.

When I was a junior hire I think it took me somewhere close to a year to get fully competent for the role that I was hired (not needing oversight for my work anymore) and the platform we were developing. When picked up later in my career on other projects, it could take me somewhere from 3-6 months to operate at full capacity.

Keep basic probability in mind. No one is going to have a good answer to every question.

I'm serious about that. Look at other answers suggesting giving everyone a veto. Let's say you give five people time to ask two questions each. Even the best candidates are going to randomly fail because someone will veto them for getting one of their two questions wrong.

Would you be okay hiring the first candidate? If not, plan out what you're okay with.

Read the article "Interview guerrilla" from Joel: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid....

The best advice about recruiting new developers all this years was "hire people smart and get things done".

Technical stuff aside, hire someone you can work with, and others can work with. Don't tolerate "brilliant jerks" as Netflix put it. They're absolute poison to an organsation.

I'd vastly prefer a less-qualified person who is eager to learn more, work effectively and collaborate than someone extremely qualified who spends all day being snippy to others.

Being confident and relaxed is important for making a good decision, I think. I recommend the Manager Tools podcast, especially the “hall of fame” (HOF) episodes. Good advice but also friendly supportive chatter from people who’ve done this all before.

And concrete advice that worked for me. Share interview questions in advance. Give people a chance to think deeply, if they want.

When it comes to meeting new people who present themselves as knowledgeable, I have a philosophy. I believe in giving them enough rope to hang themselves or parade themselves, especially in situations like screening interviews where people tend to over-inflate their resumes. This is particularly true when a person's career progression seems out of sync with what you would normally expect for the role they're being hired for.

To gauge their actual knowledge, I go through their resume and pick out key pieces of their technology stack. Then, I have them explain how it works, how it interacts with other components, etc. This works even better if it's a technology stack I'm familiar with, since I'm aware of the competitors within that space and can find a better tool to use next time around.

To catch people who are lying or exaggerating their experience, I ask them to reiterate a tech stack that's not DNS (which is often overplayed) or a familiar tech stack that I can quiz them on. By doing this, I can test their knowledge both in print and in their own words. I look for people who can both talk the talk and walk the walk, rather than just talk a good game.

My goal is to hire people who are considered peers or adjacent to my current team, rather than those who are too junior to onboard quickly. Unfortunately, sometimes someone slips through the cracks and the team regrets it.

Likewise, when in a coding interview, most people aren't 100% code perfect on the whiteboard, so I don't require them to be exact. When I first learned how to code out of the back of a Compute! magazine, I was reading it... learning how BASIC in magazine print turned into BASIC the instructional code interpreted by a computing machine. Therefore, most all who code can read that or even Pseudocode down to the level that are able to reiterate the logic and function which is something that ChatGPT doesn't even have correct (how often does it produce buggy examples?)

But if a person can show me how their logic is processing by talking it through with descriptions - and they can do the same on shared desktop remote interviews as well, and I am able to understand when I question them or add in new features I ask for and can confidently interpret their answer, then I feel confident enough that with google, they will likely be successful building a solution just on rote description.

A person does not need to get my solution, they need to get a solution that works to solve the problem.

It's suggested but not totally clear from your OP whether you were promoted to TL in the team you spent 9 years in, or whether you are new to the TL role in a new team after 9 years in another team/role. That might be a relevant consideration for your questions.

Hire the attitude.