Web News

Working with Junior Developers: Teaching, Training, and Mentoring

January 23, 2024
February 6, 2024
Episode Number:

When a junior developer is assigned to your team, it's easy to give them the "new guy" treatment. You might give them jobs you don't like to do or play some sort of harmless prank on them, but take it a step further and you're in danger of becoming a toxic workplace. Handing over jobs that are simply too difficult for a junior developer and ridiculing them when they inevitably fail is one large example of how a team joke can take a dark turn, forming a habit of treating junior developers poorly in the hopes that they'll "rise to the challenge." In reality, most teams would benefit from having another experienced developer, so why not help the newbie grow into someone you can trust? In this episode, Matt and Mike discussed how to challenge and mentor a junior developer by giving them achievable challenges, avoiding a "trial by fire" that they will inevitably fail.


Also available on...
...and many more, check your podcast app!

Who’s in This Episode?

Show Notes

How to support the show


Prices subject to change and are listed in USD

  • Support the show from as little as ~$1/month
  • Get a shoutout at the end of the episode (while supplies last) for just ~$3/month
  • Help support the HTML All The Things Podcast: Click Here

Scrimba Discount!

We receive a monetary kickback when you use our link

  • Learn to code using Scrimba with their interactive follow along code editor
  • Join their exclusive discord communities and network to find your first job!
  • Use this URL to get 10% off on all their paid plans:

Show Notes



  • The polarizing comment section got me thinking about how I would treat a new junior developer on my team, assuming I’m no longer a junior myself
  • This lead me to think about my own experience as a new IT tech, how I grew out of that beginner stage, and how I would handle helping someone new (or would I even help them)
  • The conclusion: 
    - It makes more sense helping a junior developer out of the junior developer stage so that they’re a reliable team member 
    - It does not make sense to make the workplace toxic as a sort of “trial by fire” or “sink or swim” as it may work on some people, but others that could have been really valuable team members may be turned away
    - A new junior is experiencing a new workplace with all new people, and they’re new to the trade…so the situation is already a “trial by fire” arguably

Trial by Fire

  • Some people believe in the sink or swim method, piling work that would be expected from an experienced team member onto the back of a new junior dev 
  • Others will make the situation more extreme than the normal workload expected from an experienced team member in order to “see what the junior dev is made of”
  • Reasons for this management style:
    - Current team members feel as though it isn't their job to teach a junior dev
    - Workload may be too high on team members so they feel as though they don't have time to do any training (this may be true)
    - Some believe that it this is the way to weed out the weak, only those “worthy” make it on their team 
  • Beyond some light joking like “oh give this crappy task to the new guy haha” I find this management style can easily give way to a toxic workplace 
  • This does not mean that there aren’t useful parts of the “trial by fire” method, it can be good to challenge yourself and team members as a way to push yourself through difficult tasks or to see what people are made of - within reason

Helping Out

  • My preferred management method is more so about helping the junior dev “grow” into a fully fledged team member
  • Having another set of fully capable hands on the team is more helpful than hurtful

Helping the Transition

  • Gauge where you junior dev is coming from
    -If they’re transitioning from another office job, maybe even another tech office job, then they may not have much of a transitionary period outside the new tech they’re working with
    - But if they’re just come out of school (potentially their first “real” job ever) then the transition will be more of a shock
  • Teach the work and team culture
    - Instead of having your junior dev not ask any questions out of fear, or ask too many questions out of turn (ie breaking people’s deep work time) teach them the ins-and-outs
    - For example, maybe everyone from 1-3pm on the team does a couple hours of deep work, let the new team member know that
  • Teach their place in the company
    - Ensure your junior dev knows what their tasks are, where the team stands in the company, and what their role is within the team
    - This prevents stepping on toes, or under stepping and seeming lazy accidentally
  • Teach proprietary company methods
    - All companies are organized a little differently internally
    - If something is not Googleable…(examples below)
    -- The company has a specific way they’d like tickets filled out and responded to
    -- Pull requests are done in a particular way
    -- Commit messages must be written in a certain way
    - Teaching these methods whether verbally or through documentation will help problems stay more technical than logistical

Trial by Fireish

  • Assign Useful Not Pertinent Tasks
    - Assign your junior dev tasks that will allow you to see their strengths and weaknesses - so you can gauge where they are overall
    - A useful way to to do this is to assign them tasks that if completed successfully will be really helpful to the team, but if they don’t it won’t affect the team negatively 
    - For example, a task that is a few months out that the team isn’t planning on touching soon may be a good task for a junior who is slower and may fail at to attempt. If all their work is scrap, the team wasn’t going to touch it any, and if their work is good but just slow, there was time allotted to it
  • Figure out how they learn
    This is time consuming and may be challenging for some teams to balance, but if you can figure out how your junior dev learns best by investing some initial learning time, you can help speed up the learning process by directly teaching the way the junior learns best
    - Some people are example based, written based, need help once all the way through then extrapolate
  • Challenge your junior dev
    - You can’t handhold someone forever, you will need to let them go and prove themselves at some point
    - The best way to do this is to give the junior dev challenges that they have a good chance of rising too but may fail at, in a controlled environment
    - That means that you shouldn’t be:
    -- Giving them a huge deployment to do on their own
    -- Giving them a huge task that the whole team relies on, even though they will likely fail and be ridiculed for it
    -- Expecting for everything to be perfect so the team can move on to the next thing
    - Challenges should increase with the skill of the dev and sometimes will outpace, or underpace their skill as you (the team member training them) figure out where they’re at in their learning and how fast they learn new things
    - Think of this as a trial by fire with a huge safety net underneath

Reality Rears its Ugly Head

Sometimes helping a junior developer in this way is not possible because of:

  • Tight deadlines on the entire team
  • Extremely high workloads
  • Company culture - the entire company may believe in a “trial by fire” training method and therefore as an individual (or a single team) you may not have the pull to change that
  • You may be assigned to train a junior dev, but the tech lead above you may tell you exactly how to do that
  • Competition in the workplace, especially amongst layoff season, can make people standoffish to new team members - leading established team members to want the new guy to fail, or to use them as a way to prove that they themselves are really needed in comparison to the shotty work the newbie is doing (trying to give themselves job security)


  • Michael LaRocca
    - Author of the Self-Taught the X Generation blog, at