Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Tips for a new team lead who is hiring
36 points by noam_k 69 days ago | hide | past | favorite | 58 comments
Hi all,

I'm moving into a Team Lead position after ~9 years of technical work (mostly R&D). The team deals with cryptography for a hardware startup, so we have a very diverse set of subjects we need to understand (abstract math, a few open source libraries we are integrating with, hardware requirements, to name a few). At the moment there's only one team member I'll be in charge of, so I'll be focused on hiring.

My main question is what should I put emphasis on in the recruitment process? Is hiring a junior a valid risk? Are there gotchas I should be aware of?

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'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.

My problem is that we're trying to hire for a very niche position, where we get maybe 3-4 candidates A YEAR. So we don't really have the comfort of waiting a bit longer to interview those 30 candidates - we have to look at whether the people that come in could maybe work in the position we have.

Yes, hiring for a niche position is hard because you don’t have the luxury of choosing between many candidates.

It seems like there are three approaches:

1. Pay above market rate. Retention can be expensive with this strategy because you get into an arms race with the competition, but if you’ve got the budget, it’s the quickest.

2. Hire for attitude and re-train. Probably the slowest route to success as it can take years to build up true expertise, so it depends how much expertise you need and how quickly as to whether this is viable.

3. Hire for the niche skills and accept some other trade-off. I had limited budget to hire a strong MySQL DBA, and hired someone that wanted limited and extremely flexible working hours and could afford a paycut.

How do you handle it?

Wild, what area is that? Maybe it's a pipeline/intake/compensation issue?

Rendering programmers in video games industry. The problem is that any rendering programmers are immediately hoovered up by medical/automotive/research industries at ridiculous salaries that very few gaming companies can compete with, and even then there are very very few programmers who are interested in that area.

Yes, the answer to the problem is "just offer more money" but that decision is way above my paygrade - I have to hire someone though, and the choice of candidates is very small.

I had this problem recently trying to hire people good at and willing to work with a big Angular v1 codebase.

Angular v1 can be picked up a lot easier than what OP describes. You could/should cast a wider net

Compensation might also have been an issue.

>rendering programmers

How many months will it take for 'regular' programmer with 5 years experience to say have the skills of say a 5 years of a rendering programmer ?

What is the pay range for rendering programmer with 5 years of experience?

To expand on listening to your gut instinct: I find taking a "trust but verify" approach useful. Take the time to dig into what your instinct is telling you, try to match it up in words to your hiring criteria (which should go beyond technical stuff, including capturing whether or not you'd want to work with the person), and compare against other candidates to check you're being consistent. For instance, you don't want to unfairly penalise someone for being loquacious just because their interview was right before lunch and you were getting hungry, whereas you enjoyed interviewing the similarly talkative candidate that happened to be interviewed just after lunch.

Yes, unconscious bias is a huge risk in my “trust your got instinct” approach to hiring. For example, I bristle at the name “Daryl” because I went to school with someone with that name and I remember him laughing at me. Maybe this is why I’ve never hired someone called Daryl.

So I agree you need to articulate and challenge your reasons, even if only to yourself. Periodically review the ones you’re rejecting and ask others if there’s a pattern, then deliberately spend time with people represented by that pattern.

Unfortunately, this doesn’t come naturally to me and I have to work hard at it.

My 'agent' found me the perfect job, so I wouldn't avoid recruitment consultant.

But you have to ask the question : how long have you worked with him/her (the first job I landed with her was not a good fit).

I’ve also had good experiences with agents, but only when I learned how. Early on I was burned by pump-and-dump agents - they send you below-par candidates, bullshit both of you, pressure you into saying yes, and then walk away with their commission. They dominate the market because they send everybody as fast as they can, and have the lowest fees. So if it’s your first hiring experience the odds are that you’re working with such an agent, whatever they tell you.

Find an agent who takes a long-term view of the relationship by showing them you will be hiring many people over the years. Get them to send you their best candidates - respond to their messages quickly and with useful feedback. Nurture the relationship by also sending good engineers and employers their way. They are often more expensive and send fewer candidates, but the ones they do send are stronger.

I've also had reasonably good experience with agents. but it's important to understand their position. potential employer != recruiting agent

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.

Four subtle points to add:

- Be consistent in what you ask, at least for the initial round(s). Else the candidate comparisons will be invalid.

- If different people are involve (i.e., interviewers) make sure they prep as a team. Nothing is more annoying - and a red flag to the interviewee - than getting the same question multiple times across different meetings. It also wastes time.

- Along the same lines, when multiple people are involved, be mindful of any post-interview group discussions. Groups create biases (read: group-think). Consistency comes into play again. Prior to a debrief have each interviewer grade the candidate, hbave them form an opinion, then discuss.

- Listen carefully. Listen to the candidates' wants and needs. Short term and long. Professionally and personally. This is beyond (culture) fit. I've been W2'ed for more than one role that I was in the immediate a solid fit for. But the ceiling was too low, the decision making too slow. I left both asking, "Why did you hire me?" In short, don't fuck with someone's career/life simple because you're desperate for their skill set. Don't imply a situation that isn't accurate. Yes it happens. Too often.

You make an interesting point on career fit. I’ve heard the idea discussed but never explicitly named.

This is a great framework, and similar to what I follow.

One thing I would add: If hiring falls within your scope, it is one of the most important things you can do. I see too many new leads/managers try to "outsource" it to HR, etc. But while it can be super time consuming, finding the right people for your team has an outsized impact on your team's future success, so make it a priority!

HR can be a great partner, but they're not going to know the role like you do.

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.

Definition of "junior" missing.

A qualified junior is someone who can take a well-specified, narrowly-scoped, low-risk task and execute it in a reasonable, not record-breaking, amount of time. They fundamentally need someone to hold their hand, if only to ensure that the task is truly well-specified and narrowly-scoped.

If someone has any experience, and they're interviewing for junior roles, that should raise eyebrows. It's not an automatic disqualification - shit happens, people find themselves working for abusive bosses, whatever - but having any experience whatsoever should come with it a lessening of hand-holding (and its bureaucratic expressions in workflow).

The problem is that it's pretty difficult to identify which of those a junior is while with a senior candidate you can easily talk about their work experience.

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.

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 good to have the experience of being wrong when hiring. It's easy to be confident that you can evaluate people, until you run a test.

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.

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 don't hire a junior because you are afraid of hiring someone senior as your first hire.

I'd go so far as to say don't hire a junior person as your first hire. Someone senior can help you with hiring in general and hiring good junior candidates in particular.

That's a good point. Juniors are valuable, but only if there is sufficient scaffolding for them to grow and be led towards the most valuable work. Otherwise you're doing everyone a disservice.

In my experience, there are juniors who are on the verge of becoming senior... and juniors who will forever be juniors, sadly. (Even with lots of support.)

Any tips for distinguishing future abilities?

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.

> 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.

There are many reasons for this, but at least consider this: when team will grow, you will not be able to be friends with everyone, and those not included will feel that they are treated differently.

Then the trust will start to erode, because the only way to be included is to be "friends" with you - it will create all sorts of things in the working environment you don't want.

Working with friends is awesome, but only when they are on your level. Having friends as your reports is completely different beast.

Wonderfully put. A relation of subordination is a relation of domination : as a team leader OP has agency over his/her team members' agenda, raises, roles, etc.

You can be chummy all you want with the people you are hiring for, but the relation will never be as equals and you have to be cognizant of that.

> when team will grow, you will not be able to be friends with everyone, and those not included will feel that they are treated differently.

I will fix this: the other people will NOTICE that they are being treated differently. It wont be merely feeling and the feeling itself is not the issue. The reality of them being treated differently is what is the issue.

I think that it is possible for leader to be friends with people under. But, you gotta be really careful about not being unfair too much. The moment one makes "be my friend" hiring or other condition, it is clearly not the case.

I disagree about the being friends - its important to get along - but you dont need to be friends

I also think you risk excluding people from hiring who would make great hires because they dont fit into your view of "friend", and there are plenty people who cant do things like go for work drinks due to family commitments, being carers and just want to get the job done

I agree with this, especially for a small team like this seems to be. Teams are most effective when they enjoy working together.

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.

* 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)

> “do you want to have a beer/coffee/social interaction with the person outside of work”

Unfiltered and unanalyzed, this is a bad metric because it essentially brings out the lowest-level mental evaluation of whether the person fits your tribe or not. It’s easily subtly biased against women, introverts, other ethnicities, etc. — not because you hate them but because your lizard-brain doesn’t automatically associate them with comfort.

Instead think about whether you’d want to hang out with the person, and then try to intellectually disregard that evaluation completely.

I think both extremes are problematic; while you (rightly) cover the cliquey/othering/representation side, the counter is the introduction of people to the team who - at best - cannot or will not socially integrate, and at worst are positively frictional and demoralizing.

You see this happen a lot when (say) poor management look too much at cost or box-ticking over team morale and competence.

"Can they do the job?" and "can we get on with them?" are both important questions for a healthy team, but yes, it is important that those questions are asked in an open-minded spirit.

Working with someone professionally is not the same as a beer buddy. In fact, I value having colleagues who are distinct enough from me that I would feel a bit uncomfortable having them over/hanging out (e.g. political views, humor, world view), as long as they are 100% professional and technically excellent. Btw .. a lot of technically excellent people do not drink (religion or just choice), and a bunch of people would likely be classified on the ASD scale. Your colleagues DO NOT need to be your buddies.

I recall when I was in a team that was super buddy-buddy and everyone would hang out and go drinking, everyone shared the same view, etc. When we had a major crisis in the office, things devolved into a shouting match in a manner that may be okay with buddies but not in a professional environment.

You've read too much into my "can we get on with them?" which is just about having common ground and relaxed relations at work, nothing to do with drinking, being buddies etc.

thank you for explaining the thought much better than i did

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

purely on this point, having two cases does seem quite unnecessary and burdensome

you have to learn the alphabet twice, for one thing

and in fact, much punctuation is also superfluous

just put each 'thought' on it's own line, for example

no need for fancy untypeable punctuation like the recently popular —

excellent "point"

will implement

It's a short one but has always worked.

Hire slow fire fast.

I have no idea what that’s supposed to mean

Hire the attitude.

Applications are open for YC Summer 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact