Ask HN: Strategies for mentoring junior developers?

One of the best ways I found is to hire in pairs. Don't just hire one junior (or entry level) at a time. Hire two or more at once so they can help each other learn your stack. At the university I work at, this is how we handle it. We hire a lot of students to help develop our application. These students are far from entry level when we hire them. Most have taken maybe one CS class at the university level.

It takes a lot of time to mentor these students, so one of the ways we handle that is have some of the more "seasoned" student developers help train. This works out very well for us, in that we have two seasoned student developers that help train the four fresh students we have. The questions that the newly hired students have can generally be answered by another student, because they probably had the same problem. While these seasoned students help out a lot, I still have to spend time mentoring and training. Be prepared to spend more time than what you think, but the rewards pay off in the end.

Also it helps if you find what the developer is passionate about and maybe find work that aligns well with that. We had a former student that once we found out they wanted to do iOS development, we put them on that task and they really shined. It does take some work to find out what they want to get into, but it has worked well for us.

As for getting up to the "senior developer" skill level, that is not something that we have baked into our student program. Once a student graduates, they can no longer work with us. It takes more than the typical 4-5 years to graduate university to hit that level.

As a Junior - Intermediate Dev, I'd say these are usually pretty good places to start. These usually give the codebase some easy wins and help the junior build up confidence.

In addition, since they're not part of the main project, it's not very stressful on the junior's side (assuming they realize that their work isn't blocking or holding up someone else). Probably one of the most stressful things I remember is trying to get up to speed as quickly as possible since I felt like I was holding back the work.

Pair programming works for specific people, for others it's an exercise in anxiety. Especially in the scenario you're suggesting with a senior watching a junior write code.

I think this largely depends on where in their career they are and how familiar they are with coding in the environment they just found themselves in (large org, small company, startup, tech stack, etc).

In general I find pairing a new hire with a less senior but relatively new hire to be a good way to get them ramped up quickly. Ideally this person has recently gone through the same process and can help get the new person unstuck. It also very much helps in the first few weeks to have a single point of contact to ask all the basic questions to get them up to speed before they feel comfortable reaching out to the larger org.

After this its all about knowledge transfer and task management. Helping them understand why things are the way they are, not just how. There is a tendency for new devs to come in and want to change everything to be "better" without understanding the reasons for the current state of the world.

Once they are up and running, giving them larger and larger tasks with less and less guidance will get them out of their comfort zone and needing to get better integrated into the team. They will need to ask for help from an area expert, sync with PM, and be responsible for something end to end (though likely already pre-defined by someone more senior).

If they've made it past that point they should start becoming more autonomous and a great candidate to be a mentor for new devs coming in. Once they hit this stage, I find giving them more responsibility and less guidance can help them grow, fail, and learn.

I could write a lot more about this subject but thats a general idea of how I look at the ramp up process. Getting to Senior is a whole different topic, but for context I've only ever worked at large tech firms so thats the only definition of Senior I know.

How you mentor has a lot to do with the particular topic and the relative knowledge and skill levels of the people involved.

For example, if you're trying to teach TDD strategy then pairing might be best because there's a lot of nuance to how things are done. Environment setup. Tests come first. Make sure all the tests pass before moving on. Refactor between. So for TDD it would be difficult to provide a big list of dos and don'ts and expect someone to navigate them.

Some skills are contextually less rigid than TDD. Debugging a problem for example: if a developer is trying to use an internal API but they are getting a timeout response instead of any actual output. You could simply tell them to see if the HTTP server is running, but it's probably better to ask questions and explore the problem vicariously. "What do you think the problem could be?" Then you can arrive at gaps in their understanding about how the system or HTTP servers work.

Asking questions when there's that too-familiar "we've gotta get this stuff done" atmosphere can be challenging. It's tempting as a senior developer to just provide the answer without slowing down and exploring the problem with your junior counterpart.

There's also institutional teaching. Is the junior developer asking questions which should be addressed in documentation? If so, you should probably commit those answers to the documentation and have the developer act as a litmus test for the completeness of the information.

So teaching can be showing, sometimes it's a matter of explaining, and other times it's more important to just ask the right questions. I think one of the most important parts of teaching is perspective-taking. You want to explore the areas just adjacent to the person's knowledge.

Also, blameless postmortems. It's easy to point fingers when shit goes wrong. Don't.

Developers junior to me ask questions which I find border on alarming sometimes but I suppress that reaction because I would rather fill those dangerous gaps than have a developer be too scared to ask.