> For juniors to be cost effective/neutral, you can only really have 1-2 per mid/senior engineer. Most companies don't have that many mid/senior engineers to begin with, much less ones that are willing to take on a junior to mentor for a year or two.
I think you're off by the reciprocal of the ratio. It should be something like two experienced devs per junior dev. Any more junior devs than that and your senior devs are spending too much of their time mentoring and not enough time getting their tasks done, which is going to frustrate them. Fortunately, with a good junior dev, it doesn't take long at all to reach mid-level dev. I've seen it happen in under a year for smart new grads.
When I say cost neutral, I mean from a productivity standpoint. The 2x junior+senior accomplish the same amount of work as the senior would by themself.
It takes about a year for a junior+senior combo to be more productive than a senior alone. And another year before they're not a noticeable cost on the senior. 2x senior to a junior definitely brings the junior up to speed faster, but I think it's less efficient use of the seniors cause it also introduces a synchronization cost between the seniors.
I like to stagger the juniors so they're not at the same level; the +1 junior can take some part of the workload of mentoring the fresh junior. Plus it starts them on practicing mentoring early in their career. The fresh junior still has two mentors, and there's a clear pecking order.
I think you're off by the reciprocal of the ratio. It should be something like two experienced devs per junior dev. Any more junior devs than that and your senior devs are spending too much of their time mentoring and not enough time getting their tasks done, which is going to frustrate them. Fortunately, with a good junior dev, it doesn't take long at all to reach mid-level dev. I've seen it happen in under a year for smart new grads.