There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.
Reliance on online resources is, in my view not a substitute for experienced mentorship: there is the paradox of choice, and the plethora that creates this paradox is of generally poor quality. Except for textbook or trivial problems, moreover, much of the resource material online is too generic or only marginally applicable to the depth and breadth of technology issues that face a real business and its needs.
Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.
I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.
Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction.
As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them.
From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring.
This path will be different for each person. So: have a plan, but be prepared to adjust it regularly.
There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.
Sounds like there should be a thread to match mentors and mentees here on hackernews. Maybe a bunch of mentors post some open source projects that they want mentees for?
Every time I try to 'contribute to open source projects' online I get overwelmed by the size and complexity of most codebases, I have tried numerous times, and have never been able to fix a bug.
This type of thread is something I'm sure I and others would take serious advantage of.
It was a great experience, as other members of the team, who were more senior than you, may not have even understood how the application you were looking at worked (we had ~40 applications/services), so you would have to work together to figure it out - both completely clueless. Usually we would pair because of the unfamiliarity, but if we were familiar with the application we would occasionally work solo, even as a junior.
The best bit was the management: there was enough pressure that you knew you had to get this fixed soon, but not so much that you were stressing out.
Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it.
Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.
> They started humble and ended afraid to do anything except simplest tasks.
It's the job of the team leads to create an environment where people (especially new people) shouldn't be afraid to try something out and learn from it. I've had plenty of CRs which went for some huge number of iterations when I first started, generally this was solved by spending some time thinking about designs on my own and then having a meeting with senior devs to discuss pros/cons and any suggestions before writing any code.
> Also, they got only and exclusively negative feedback.
This sounds really shitty, and this seems like a problem with the people on the team. I always try to put at least one positive thing in a CR after lots of criticism, and if there isn't that much criticism even better!
All in all it sounds like with or without CR, the team you're describing probably wouldn't be a pleasant place to work.
It is not that CR is has no place in the process. It is that it should not be primary tool for teaching, mentoring and leading. Nor talked about that way. Every forum and blog posts talks about CR as teaching tool and every discussion about juniors puts a lot of emphasis on CR and none on other tools. A lot of people think and act that way.
Also, there is level of knowledge to be acquired about teaching and working with people. A culture that does not conflate code review with teaching nor talk about it as a primary means of how to deal with less experienced developers have better chance to develop that knowledge.
As in, admitting that those are different tasks is first step.
The person you're describing shouldn't be mentoring. The problem isn't the methodology, but their personality being poorly suited to the task at hand.
This industry frequently conflates effective producers of lines of code, with an ability to function in a senior role. If you look at other lines of work, seniority often implies things beyond "does the basic job quickly".
So yes, this person will do code review. And code review has more functions then mentoring.
2.) Mentoring starts on task selection. Latest when junior start working on it - with senior occasionally checking the junior out while the task is in progress. Code reviewer might be someone completely else who might have noticed that junior is working on code only after it is done.
Sane mentoring should not start when junior finished the work.