Team Lead Mindset
Mentoring, Onboarding and Hiring
Context before answers, a first-90-days plan for a new hire, fair work-like interviews, and what the popular lists say about hiring.
On this page
In one line: a lead grows people (mentoring), helps new people become useful quickly (onboarding), and chooses who joins the team (hiring). In all three the good habits are the same: give context, make the task real, be clear about what you are looking for, and be fair.
Interviewers for lead roles ask: "How do you mentor?", "How do you onboard a new developer?", "How do you interview candidates?" This lesson gives simple answers and the reasons behind them, using what well-known reading lists and a very popular hiring list say.
Read Lesson 0 first for the answer shape. For the candidate's side of interviews see Full-Stack Lesson 37 (coming soon) (live coding and take-home) and Lesson 38 (coming soon). For 1:1s and feedback see Lesson 8.
Everything here is common practice and opinion. Hiring rules differ by country (what you may ask, how you must store candidate data). Ask your HR team. Use the ideas, not the exact words, and always use your own true examples.
What I checked. I read directly: the Mentoring, Onboarding and Hiring sections of charlax/engineering-management (about 8.3k stars in an August 2026 snapshot), and the README of poteto/hiring-without-whiteboards (about 50k stars in a recent snapshot; I read the first 100,000 of about 145,000 characters). For the first list I only have its description of each article (for example Gergely Orosz on mentoring, "How to Hire", Johanna Rothman's Hiring the Best Knowledge Workers); I did not open them, and several entries (GitLab's onboarding page, Fowler's "Onboarding") are title-only. The second list is self-reported by the companies on it; its own page says so. The sample wording is mine.
Words used in this lesson
- Mentoring is helping someone grow over time through advice, questions and feedback. It is longer-term than a single task.
- Onboarding is the first weeks of a new person: setup, learning the system, meeting people and doing a first real task.
- A buddy is a teammate who is the new person's first contact for questions.
- A structured interview means every candidate gets the same kind of questions and is judged against the same clear points.
- A take-home task is a small piece of work the candidate does at home.
- Pair programming is two people working on the same problem together.
- Signal is evidence in an interview that tells you something real about future work.
Mentoring: context before answers
Ideas from the list, in simple words:
- Give context, not only advice. One article in the list is titled "Advice is Cheap, Context is Priceless". Telling someone what to do without telling them why or what you know does not help them next time.
- Do not just hand over answers. The list summarises Gergely Orosz's piece on developers mentoring developers as: provide context, avoid giving the answer straight away, and let people learn by helping themselves.
- The supervisor teaches. High Output Management (Andy Grove) is listed with the idea that the supervisor, not the customer, should take responsibility for teaching.
- Help people see their own tendencies. Another entry encourages self-aware engineers who can adjust their habits to each situation.
A mentoring habit that works (my own): ask "What have you tried?" and "What do you think the options are?" first. Then give the smallest hint that unblocks them, and say why you thought of it. Review their work together, and tell them about your own mistakes.
Onboarding: the first weeks
The list has little detail here, but one entry gives a useful frame. Andrew Bosworth's "A Career Cold Start Algorithm" (as the list describes it) suggests that in the first 1:1s you spend most of the time asking what the other person thinks you should know, then ask about current challenges and who else you should talk to. That works for a new lead, and it also tells you what to ask a new hire.
A plan for a new developer (my own, built from common practice):
| When | What |
|---|---|
| Before day 1 | Laptop, accounts and access ready. A buddy named. A first small task chosen. |
| Week 1 | Run the project locally from the README (and note what is wrong in it). Meet the team, product owner and design. Read the main code paths and the decision records. Ship one tiny change through the whole release path. |
| Weeks 2 to 4 | Own a small feature. Join code reviews and the on-call training. Give a short "what confused me" list, and fix the docs. |
| Month 2 to 3 | Own a bigger piece. Agree goals with the lead. Give feedback about onboarding itself. |
A new person's questions are the best test of your documentation. If the same question is asked three times, write the answer down. One article in the list recommends a shared team knowledge base so that people can onboard themselves and stop asking the same thing.
Hiring: what the reading lists say
The Hiring section of the management list (again, descriptions of articles I did not open):
- Hire for trajectory, learners and doers. "How to Hire" is listed with: trajectory over experience, learners over experts, doers over talkers.
- Limited consensus. Johanna Rothman's book is listed with the idea that everyone should be able to accept a hire, even if not everyone is enthusiastic.
- Interviews should be a conversation. One article says they should be collaborative, not an interrogation.
- Do not let questions be spoiled. If prior knowledge of the question does not change the quality of the signal, you are probably changing questions too rarely. (My reading of the title and description.)
- Live coding is debated. One article in the list argues that live coding gives inaccurate signals. Other people disagree. See Full-Stack Lesson 37 (coming soon). It is an open debate, so choose on purpose.
- Senior candidates are also choosing you. "Trouble hiring senior engineers? It's probably you" is listed with the point that you are selling as well as buying.
Interview formats that resemble real work
The very popular list hiring-without-whiteboards collects companies that avoid whiteboard puzzles and trivia. Its tl;dr says that discussing a real-world problem is preferred, and CS trivia, technical puzzles, riddles and brainteasers are discouraged. The patterns it shows in the companies' own descriptions (self-reported, so check them):
- Take-home projects. Small and time-boxed (often about 2 to 5 hours) on a realistic problem, then a discussion. Some companies pay for them.
- Pair programming on a real or work-like problem.
- Walking through past work, including the decisions and trade-offs.
- Real design discussions about a problem the company really has, with no live coding.
- Paid trial work, from a day to several weeks.
- Culture and values conversations about how people work together.
Examples named on the page include Airtable (a take-home, then a five-hour onsite on the project, UI design, architecture trade-offs and debugging), Lob (technical problems that are simplified versions of real production problems) and Elvie (real code discussion, pairing and a paid day, and it says it avoids unpaid take-homes and abstract algorithm tests).
A simple plan for a fair interview loop (my own)
- Decide what you need for this role and write 4 to 6 clear points (for example: reads and changes unfamiliar code, explains trade-offs, works well with product).
- Ask every candidate the same kind of questions and score against the same points. Take notes.
- Use work-like tasks: a short code review, a debugging session, or a small design talk about a real problem.
- Respect time. Keep a take-home short, tell candidates how long it should take, and give feedback.
- Decide separately first, then together. Each interviewer writes their score before the group talks, so the loudest person does not decide.
- Be kind and clear about next steps and timing.
Check the law and your company's rules. What you may ask about (age, family, health, pay history and more) and how you must store candidate data differ by country. Ask HR. Do not copy a question list from the internet without checking.
Interview questions
How do you mentor a junior developer? (Must know)
I start by listening: what do they want to learn, and where are they stuck? I give them real, small tasks with clear goals, and I ask "What have you tried? What are the options?" before I answer. Then I give the smallest hint that helps and I explain why I thought of it, so they get context, not only an answer. We review their work together and I share my own mistakes. I check in often at the start and less later. I measure the result by how their questions change over time.
How do you onboard a new developer? (Must know)
Before day one: access and a buddy are ready, and a small first task is chosen. In week one they run the project from the README (and mark what is wrong), meet the team, and ship one tiny change through the whole release path. In weeks two to four they own a small feature and join reviews. In month two or three they own a bigger piece and we agree goals. I ask them to write down what confused them and fix the docs, because a new person's questions are the best test of our documentation.
What do you look for when you interview a developer? (Must know)
I decide before the interview, for example: can they read and change code they have not seen, do they explain trade-offs, do they ask good questions, and do they work well with others? I look for signs of learning and doing (what they changed after a mistake), not only years of experience. I ask every candidate the same kind of questions and score the same points, so that I compare fairly. I also look at how they respond to feedback during the interview.
What do you think about whiteboard puzzles, live coding and take-home tasks? (Senior signal)
I prefer tasks that resemble the real work: reading or reviewing real code, debugging, or a design talk about a real problem. Puzzles and trivia often test nerves and practice for the interview, not job skill. Live coding and take-homes both have trade-offs: live coding can give a noisy signal under stress, and take-homes cost the candidate time and may be unfair to people with less free time. If I use a take-home, I keep it short (a few hours), say how long it should take, pay if the company can, and discuss it afterwards. People disagree here, so I choose deliberately and tell candidates what to expect.
Two interviewers disagree on a candidate. What do you do? (Senior signal)
I ask each to write down their view against the agreed points (before they hear the other), and compare the evidence, not the feelings. If someone has a concern, I ask what question could resolve it: maybe a short follow-up conversation. The reading list I used suggests "limited consensus": the aim is that everyone can accept the hire, even if not everyone is enthusiastic. If the evidence is still unclear, I prefer a short extra step (a paid work sample or a second talk) to a coin toss. I also check that we are not biased by familiarity ("they remind me of me").
A new hire is struggling after a month. What do you do? (Senior signal)
I first check my side: was the onboarding clear, are the tasks the right size, do they have context, a buddy and feedback? Then I talk with them privately, ask how it feels, and look at specifics. I agree a small plan with clear expectations and dates, pair on the hard parts, and review progress each week. If it is a mismatch of skills or role, I say it honestly and early to my manager so we can decide fairly. I do not wait for the end of the probation period to say it for the first time.
How do you make sure you are hiring fairly? (Senior signal)
Same kind of questions for each person, written scoring points, notes taken during the interview, individual scores before the group talks, and diverse interviewers when I can. I avoid questions that are not job-related and I check with HR about what is legal in our country. I check that the process does not rely on things like free time for a long take-home or on insider knowledge. I look at my own patterns: who do I like, and why?
Key takeaways
- Mentoring: give context, ask "What have you tried?", give the smallest helpful hint, share your mistakes.
- Onboarding: prepare access, a buddy and a first task; get a tiny change to production in week one; ask the new person to fix the docs.
- Hiring: decide what you need, ask the same kind of questions, score against clear points, and decide separately before the group talk.
- Prefer work-like tasks over puzzles. Keep take-homes short, say how long they take, and discuss them.
- Senior candidates are also choosing you.
- Check local law and your company's rules for what you may ask and how to store data.
- This is common practice and opinion. Adapt it to your team.
What's next
Next: Stakeholders, meetings and change, Lesson 10. Practise: write the 90-day onboarding plan for the next person who will join your team, and mark which docs you would have to fix first.
Published by Jainik · Last updated · How these lessons are made
Keep learning
Part of the study guide
Related series