A lot of companies (including Red Ventures) direct most of their hiring efforts towards high-level, really experienced engineers. At RV, this is a tall order because we’re not just looking for the right technical skills for our particular environment (C#, Golang, PHP, Node, React, <new technology du jour>, etc ), but we’re also heavily focused on making sure we’re bringing in great culture fits (do you enjoy mid-day Nerf wars and impromptu dance parties?). Once we do hire engineers at Red Ventures, we spend weeks or even months on intensive training before they’re truly integrated and firing on all cylinders. All of that takes a ton of time and resources, but it’s pretty much universally agreed upon that this process is absolutely critical for any tech company
However, I would argue that bringing in junior and mid-level programmers and dedicating time and resources to developing them in-house is equally important – especially if you’re growing as rapidly as we are.
New coders often introduce innovation into the system.
Senior engineers tend to approach a problem with the same tool set they used to solve similar problems in the past, regardless of whether it’s still the best. Why reinvent the wheel, right? On the other hand, engineers who don’t have years of experience to fall back on are more likely to research multiple approaches and seek opinions from a group before settling on the best strategy. As long as it’s a managed process, this kind of thinking can be incredibly valuable and inventive.
They ask questions – lots of questions.
New coders want to know how processes work from start to end because they need to know the basics. And one thing I’ve found is that senior engineers often take those things for granted. We look right past them as they work to solve complex tasks. Unfortunately, we’ve all seen code bases that outgrow the initial design and systems that become strained as we continue to place layer upon layer of code on top of old work. A beginner’s questions often force us to consider how we’re doing things, and whether it’s time to refactor.
Most of us who have spent more than a few years in the industry are passionate about what we do, but we most likely don’t pursue that passion in the same obsessive way we used to. We may feel a little more stability in our careers, we start families, we fall asleep on the couch in front of the TV at night instead of playing around with some framework we’ve been dying to learn… Life happens. But everyone remembers first starting out, feeling that drive to get better, and being excited to devote time and energy into it. When you combine that momentum with the knowledge and skillsets of senior engineers, it pushes everyone to raise the bar.
Ego? What Ego?
If your first job enforces a culture where it’s ok to not know something as long as you’re working to find an answer, you don’t feel the same need to protect your ego the way a senior engineer might. It’s beneficial not just for their professional development, but for overall team productivity as well.
Hiring junior level talent is a great way to develop your mid-level talent.
It’s a virtuous cycle: by asking your mid-level engineers to serve as mentors and guides, mid-level engineers hone their own technical skills and develop the leadership skills that will mold them into the senior leaders your recruiters are searching for in the first place – faster.
Obviously, this strategy won’t work for all organizations. Developing young or inexperienced talent definitely requires a lot of time and resources, too. But for those willing to commit to the process, the rewards are tremendous.