How many juniors should a senior mentor?

Question

Our shop's size increases dynamically, so we are planning to hire a few new junior developers but we would not like to overwhelm the seniors with too much mentoring and training. How many (usually fresh out of college) junior developers could (and should) a senior developer mentor while the senior is still being able to do his or her tasks effectively?

Answer 1

Anywhere from 0 to 5 or 7 (or so).

Arguments for the low side:

• Not everyone is set out to be a mentor. I have worked with some developers who were so gruff that they would have scared someone into a new career.
• If you expect the senior devs to maintain the same level of output, then keep the number low.

Arguments for a higher amount:

• Some devs have the ability to be just as productive by guiding others' work. Pair-programming would be an example. If you have those magical types of senior devs, then go ahead and give them more.
• If you're willing to lower the expected output from the senior dev, then you can assign more junior devs to them.
• If you have a dev that is really good at teaching they why's of governance, then you may explicitly want to take a hit in that senior dev's productivity and give them more junior devs. The idea here is a short term cost (loss of production) for a long term gain / investment (better conformance to team's development standards).

I would encourage having a conversation with the senior devs and see what they are comfortable with. Not everyone wants to mentor. Also remember to use the "full bookshelf" analogy: Their workloads are currently full. If you are going to add to their workload by having them mentor, then you need to take something else off of the shelf to make room.

Answer 2

No more than two per senior developer if you are hiring people straight out of college. The recent college grads I've had to deal with in the past have a good understanding of the basics, but they had no idea what it was like to program in the business world. You will you have to spend time teaching them how to program professionally, it is quite a shock when they realize that they will have to support the code they write for as long as they are with the company, no more turning assignments and moving on. But you will also have to spend time teaching them your business (and all it's rules), teach them how to code your architecture, reviewing their code, teaching them how to test, and answering question after question after question. Both times I was asked to mentor a junior I spent at least half my time at their desk for the first couple of months.

Answer 3

If you have a lot of juniors coming in, let's say >30, it might be worth it to dedicate a senior developer to mentoring them full time. At my first job they hired about that many of us fresh out of college and had a dedicated team member helping us learn the ropes for the first 6 months. It made the transition a lot easier and he taught us a lot.

Not only is it more efficient to have one person handling the job, there may be a single person in your office that you know would be a perfect mentor. A good programmer isn't necessarily a good teacher.

Answer 4

As many as they can while still being able to get their own work done on time.

The answer, therefore, depends on how effective the senior is as both a developer and as a teacher.

Answer 5

You don't mention the type of project work which in my experience has a HUGE impact on where that ratio should be.

On a scale of cookie-cutter repetition that could almost be automated to experimental things the developer isn't even sure will work you need to make sure you keep the jr devs to the left unless you are at a really low ratio and even more strictly to the left if the sr devs are trying to do something they consider to the experimental end of the spectrum because they aren't usually going to be as effective riding herd on a team of jr devs if they are pushing themselves hard at the same time.

It depends on the work as much as the people in my opinion.

Answer 6

Mentoring is less formal than managing. Mentors are not directly involved in the hiring, firing, reviewing and discipline. The environment will be a major factor. Here are the factors to consider:

• quality of sr. and jr. devs
• how well the company is run/treats programmers (this will compound the other problems)
• sr. dev current work load
• management's expectations on how fast the jr. devs need to become productive
• other training resources (instructor aided courses, reference materials, certification requirements)
• hiring to fit the team. Many times on this site people have mentioned the importance of the team needed to get a long and be able to function together. Someone with a higher skill level may need more mentoring if they don't fit in.

Mentoring usually involves some level of bonding and I just don't think most people can build any type of interpersonal relationship with more than 3-5 people in a given setting.

Answer 7

Ideally a junior works with a mentor on a project. In this way the senior can assign sub tasks and work with them towards completing a project. The more juniors the Senior has to manage the less work the senior will be able to complete of their own. I would not want more than 1 or 2 junior working with a senior at any one time. Though the senior can continue to mentor other programmers after 2 or 3 months a decent programmer should need far less time from the senior than they did originally. So a senior could conceivably have 20 or more people he is mentor for but really only 2 or 3 that really require much of their time.