Ask HN: Strategies for mentoring junior developers?

There's not really any value. This was many years ago, and the company has changed a lot. It also isn't a company many people have heard of.

Don't write code. Break down a feature into tasks that you would take 30 mins or less to accomplish. Have them build each task one by one. If they take longer than 1 hour, you know that they are stuck on something so you can go help them. While they are working on 1 task, you are figuring out the next 2 tasks. Your job becomes quick prototyping to make sure the tasks are feasible.

Eventually, after many small merge requests, junior developers will be comfortable to take up entire features. After a few features, you teach them how to break down tasks for other junior devs, just like what you were doing before.

We have been actively following this method for the past 2 years and have taught engineers with 0 coding background all the way to become tech leads in our org.

I would leave, if someone made me do pair programming.

I don't think it's about years of experience -- someone who does the bare minimum for five years and never provides input could very well still be categorized as "junior"

Junior developers and newbie in general have one incredible quality: they don’t know and they are not supposed to. You absolutely want to tell them that their role is to criticise and occasionally write the documentation. Start from things that are obvious and leverage their question: anything they ask, tell them it’s now their role to document it. How the business makes money, what that metric means, what is TDD, what happens with this fails, whether the company actually ships bug-free code.

One pattern that I use:

- pair program initially; I would do that even for principal, just to be familiar with the code base, but for probably one or two days, after that, they should be autonomous; for very junior developers, a week make more sense, but rarely more;

- gradually replace that with code review, but more than once a day for more junior people; ask them kindly to commit; make sure to point out one or two issues in each very small PR: linting, method naming convention, then testing patterns, structure, etc.

- have scheduled 30 minutes 1:1 meetings, preferably thrice or twice a week; make sure there is something nice at some of those: ice cream, walk out if it’s sunny, and have that meeting have four very explicit parts: what they have done, what blocked them; what they have learned; what they have taught (or documented). The last one is often overlooked but it’s very important for them to realise that they start owning some code, that they should think not of they direct impact but how to empower people. React to blockages by offering solutions, both from them and from you: they need to learn to unblock and that’s how you do it. Move that meeting to once a week for senior developer, once a fortnight for principals.