The hardest part of being a junior developer

Setting explicit time frames is really useful for both the mentor and mentee (or manager and employee etc).

If someone is unable to complete a task within a set time, but explains their thought process and what they tried, I consider that to be a completely valid use of their time. Even if they are completely honest and say: "This seemed too hard and I tried for the first 15 minutes and then got bored and procrastinated" that is also ok. We're all humans after all.

Its when someone spends their time on excuses and fobs that is really annoying and unproductive. Generally: most people will invent excuses. People that went to college (I went to college!) get really good at this since you need to invent excuses all the time to get past annoying social activities and classes.

In most cases, providing the space to fail and proceed allows developers to gain the confidence to be upfront. Of course there will always be those that don't get the message, or try to game the system. But they tend to fall really really far behind and it becomes pretty obvious that they're not doing well.

> What we both needed was the company setting very clear, explicit expectations. "X is your mentor. X's main job is to mentor you and help you swim in this deep end." Though I think the entire company was learning a ton of stuff at that phase.

It's been a while since I've mentored someone, but that was always one of the things I made sure to mention in my first conversation with any interns/new grads I'd mentor: "While you're here, mentoring you is the highest priority thing for me to do. If there are ever any times when I have something so time sensitive that it would take priority over answering your questions, I will explicitly let you know. Otherwise, always assume that it's okay to ask me something, because if for some reason I can't answer and you don't know that, it's my fault for not telling you." It helped that the company where I worked at the time had very explicit time periods where someone was considered a "new grad" versus a full team member (since they actually would rotate on 3 teams before ending up on one of them full time), so this strategy might not work as well in places where the expectations for mentors are not laid out as well, but I honestly think that it will almost always be the best strategy to just be open and communicative with anyone you're mentoring. Mentees are just people like anyone else, and them being inexperienced as engineers doesn't make them any less able to understand clearly communicated guidelines, and if you need to adjust the guidelines as you go, there's no reason they can't understand that too.

At the company I work for we've cultivated a very strong level of trust in terms of asking questions, and encouraging such. However, as the OP noted, it's never that easy.

The best formulae I've found is to gently prod jrs towards a solution, but to also keep an eye on their progress and then, if things are taking too long, to reach out and suggest that even though the task isn't complete, to go ahead and open a WIP pr for the team to look at. This encourages them to "let go" of the hangup and to put the work out there, effectively making things a team effort. The sooner they learn that code isn't personal (which is admittedly hard), the sooner they're on their way to more senior levels.

I have junior engineers try solving their problem on their own for an hour. If they make no progress, ask for help. If they make some progress, repeat. I think it's a good learning experience while also providing a safety net, and I've gotten positive feedback from juniors on this advice.

> When working with junior engineers nowadays, I go out of my way to let them know that any question at any time is acceptable. I'll put down what I'm doing and help them through a problem and then celebrate the solution with them. I never want them to feel the fear of work and failure that I did.

I go even further than that. I tell juniors there's literally no way you can screw anything up so badly that we can't deal with it. If they write code that doesn't do what it's supposed to do, and it's not caught in code review, the reviewers are more to blame than they are, because they're supposed to know better. A junior shouldn't have the access level necessary to do something like drop the production database -- that's on their more experienced colleagues to set up those guard rails.