You usually set up a system where you have constant feedback, like daily stand ups, weekly ( or bi-weekly) sprints etc. before closing out an issue have the devs demo the feature so it’s not based purely on word of mouth.

Personally: I would advice getting lunch with them and getting to know them better. Set up a 1:1 if lunch isn’t possible. Everyone likes honest feedback, or at least a chance to talk about their difficulties in getting tasks done.

> you dont figure it out for days or weeks?

If it was important and estimates on how long it will take are overrun, then don't wait to follow up on it and find out how it's going.

Unless the problem is more nuanced like a small component of a larger body of work? Like knowingly leaving flaws in an implementation, or something.

This sounds too simple, but you just don't let people go days without checking in.

I wrote about once simple process here: http://williampietri.com/writing/2014/simple-planning-for-st...

The key points to keep things on the rails: 1) it's a work queue for the whole team, and the whole team is responsible for every work item, 2) the units of work are small, so they should generally be finished in a day or two, and 3) you to quick daily checkins to make sure work is moving along.

If you add pair programming with frequent pair rotation (e.g., 2-3x/day) then you make it impossible for a person to get stuck for long periods. Even if two people are stuck for a couple of hours, when pair rotation happens then the pair can ask somebody with specific experience to tag in.

You'll want to find out what they are stuck on and help or show them how to remove the initial impediment (they might be waiting on someone else or having trouble breaking down the problem into smaller workable chunks.)

Exactly. Not all technical mentoring is about software engineering; many of the problems junior employees face are regarding soft skills that they need to get their job done. While you might understand what to do if you're blocked internally, or if you're waiting on third party software, or if you get feedback that you don't understand on a code review, these are - new - problems to a lot of people getting started in the workplace, that many try and fail to solve on their own.

That sounds like a manager type situation if you have devs just not doing things and not telling anyone, rather than mentoring.... that's pretty terrible.