I disagree with this. Unless your hiring practice is broken, or your code is in awful shape, hiring juniors should add immediate benefit to a team. They may not be as productive as existing team members, but they should definitely improve total output.
You don't need to devote lots of time to mentor newcomers. I've never really had it interfere with my own work.
I'm a professional PHP, Python and Javascript developer from the UK. I've worked with Django, Laravel, and React, among others. I also maintain a legacy Zend 1 application.
I think juniors are often better off working on their own projects if possible, rather than integrating into a larger project. Ideally these should be small and comparatively simple, and they can work their way up to larger projects. Code reviews would allow regular feedback on code quality and allow for potentially problematic code to be identified and refactored away.
I'd only feel comfortable bringing a junior onto a large existing project in cases where I already had good test coverage and continuous integration.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This 1000%.
I'll compound it with: hiring a junior will never speed up development. Hire juniors when you have the time and breathing room to train them.
I disagree with this. Unless your hiring practice is broken, or your code is in awful shape, hiring juniors should add immediate benefit to a team. They may not be as productive as existing team members, but they should definitely improve total output.
You don't need to devote lots of time to mentor newcomers. I've never really had it interfere with my own work.
I think juniors are often better off working on their own projects if possible, rather than integrating into a larger project. Ideally these should be small and comparatively simple, and they can work their way up to larger projects. Code reviews would allow regular feedback on code quality and allow for potentially problematic code to be identified and refactored away.
I'd only feel comfortable bringing a junior onto a large existing project in cases where I already had good test coverage and continuous integration.