Let’s review that from an employer’s perspective.
The First Week Or Two
Someone with no practical skills and proven experience joins your team. You greet them, show them around, introduce them to the team, let them settle on their desk.
You share the access to your VPN, add them on Dropbox or Drive, give them the documentation of the first project they will work on. Organize a brief meeting with the other devs if you want to – that’s fine.
You let them install their technical stack and expect them to start triaging bugs and issues over the first days – and hopefully take it from there.
This will fail miserably.
What the Fresh Developer (Most Likely) Lacks
- Technical skills.
- Knowledge of the best technical stack they need to use (or whatever the company uses).
- Experience with GitHub/Bitbucket, continuous integration, deployment scripts, unit testing.
- No exposure to a large (or even an existing) project.
- Lack of familiarity with the concepts of a large product – architecture, infrastructure, foundations.
- No practical experience refining software with backward compatibility in mind.
- Limited experience in testing the problem in numerous ways, knowing what may fail on the technical end (edge cases or regressions).
What will likely happen is lack of progress whatsoever or a number of hot patches that break pretty much everything.
Then come the communication and management skills.
I’m not talking about “leading a team”, of course.
But while working on bugs (or even during the documentation review), a developer is about to:
- Estimate certain features or prioritize the backlog.
- Ask specific questions clarifying the business’s needs and the context of the assignment.
- Build a mental model of the problem in their head.
- Prepare a patch that complies with the rest of the code base (coding standards, expected code coverage).
- Adequately reassign the task with an appropriate comment explaining the fix and documenting it.
- Documenting the behavior elsewhere – in an actual documentation or a PM backlog repository.
- Look for existing approaches leading to reusability of code and effectively applying existing strategies for solving a known problem.
Here comes the problem with unexpected behaviors, unclear assignments, and inefficient communication.
Why Juniors Require Proactive Mentorship
The thing is, the freshman lacks technical skills, computer science background (in practice), actual expertise in working on existing projects, communication chops, teamwork skills and other things described above.
That ends up in a large set of activities that should be worked upon simultaneously. Each one may take months until you get a productive person on board.
Some get up to speed faster, others don’t. A company may invest over a year in onboarding and training until they get any reasonable results on fairly trivial tasks.
Add a year’s worth of salary to the equation.
And then add the weekly time of all team members involved in the mentorship process. The mentor should handle three things:
- Do their own full-time job.
- Help, coach, educate, mentor, support the beginner.
- Fix the mess after that which wasn’t assigned to them in the first place.
Many of my friends hiring their first junior employee as tech founders say that they work 2 shifts since it takes twice as long to handle your workload and a new person (and their work).
Juniors may look around fairly soon.
Software Engineers Tenure Versus Company Size
HackerLife shared a research[1] discussing the average tenure of software engineers in San Francisco:
It’s not unlikely to spend 3–5 years or more in the leading companies worldwide. But that usually applies to experienced senior engineers looking for a solid full-time job which lets them do what they love while taking care of their life (family, friends, travels).
This explains the tenure in small companies (1.5 years) – combined with the lack of other perks and often a lower salary (or a bonus package).
But if you’re a small or a mid-sized company, training a junior for a year with them leaving in a few months, how would that reflect on the business, the team morale, their ongoing progress?
Hiring a junior developer requires a leap of faith. What helps is experience in internships, working on pet projects, collaborating with other developers on side gigs, joining an open source community and other indications that the developer has spent the time and effort which would reduce the learning curve and increase the odds of an effective partnership for a longer period of time.