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?

  • 7
    Why not ask them (seniors) instead of us? Commented Jun 16, 2012 at 16:20
  • 7
    @Mert: I have asked a few of them and I'll ask the others too, but I'd like to hear opinions from the community too (industrial averages, rules of thumbs, best practices etc.), because some of our colleagues seemed too optimistic to me.
    – palacsint
    Commented Jun 16, 2012 at 18:52

7 Answers 7


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.

  • 17
    I have worked with some developers who were so gruff that they would have scared someone into a new career. I don't remember you, when did we work together?
    – yannis
    Commented Jun 16, 2012 at 16:23
  • @YannisRizos Can't say much more than: +1
    – user53019
    Commented Jun 16, 2012 at 22:18

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.


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.

  • 2
    +1 for "A good programmer isn't necessarily a good teacher." However in this situation I would not call the senior a mentor but a teacher.
    – scarfridge
    Commented Jun 17, 2012 at 10:22

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.

  • 1
    Your answer implies that "their work" should remain a constant while the number of juniors is variable. That would be a terrible mistake.
    – pdr
    Commented Jun 16, 2012 at 18:07
  • 1
    @pdr - I implied nothing of the sort. That is your mistaken inference. What I said is that an employee who is a senior developer has responsibilities and their employer has expectations regarding their productivity. Unless their job responsibilities specifically include mentoring, the senior developer has a duty to meet their employer's expectations and can choose to take on as much mentoring as they can handle while still meeting those expectations.
    – Joel Brown
    Commented Jun 16, 2012 at 20:05
  • 1
    I would contend that an employer has an expectation regarding a team's productivity, not an individual's, and that the team should be at least partially responsible for setting those expectations. The manager of that team should set a balance (anywhere from 0:100 to 100:0) between a senior's mentoring and other responsibilities that both the junior(s) and senior understand so that, if the balance is thrown off, someone can raise a red flag early.
    – pdr
    Commented Jun 16, 2012 at 20:47
  • 1
    I would contend that any organization where individual employees do not have expectations set for them is not a place anyone with any sense would want to work. Some organizations may set a "quota" for mentoring, but in the vast majority of cases that I've seen in 25 years - more than 20 of them in contracting, mentoring is an informal process amongst workers and "staff development" is only a formally acknowledged responsibility for management.
    – Joel Brown
    Commented Jun 17, 2012 at 11:34
  • 1
    That manager has to understand that if they add an expectation of mentoring then they have to reduce their expectation of output accordingly. If nobody is clear about those expectations then, when the juniors need more mentoring than the manager expects, a senior cannot warn their manager, meaning that they'll (a) underdeliver or (b) end up obliged to work more hours or most likely (c) fail in their mentoring duties.
    – pdr
    Commented Jun 17, 2012 at 12:04

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.


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.

  • I would say the two are completely different jobs. More experienced teammate vs. boss basically. Commented Jun 17, 2013 at 1:54

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.