Leapfrog Online Teaching Hospital
— 10:10 reading time
I was inspired by a blog post I read the other day about a junior software engineer’s experience of being hired by a company, knowing she was junior, and being let go because she was “too junior”. In her blog post, Jenn identifies several issues a company should consider before hiring junior engineers. As a company that regularly hires junior engineers I thought it would be a good idea to share our experience.
For all of my time at Leapfrog (going on seven years at this point) the technology department has been referred to as a teaching hospital. We hire junior engineers and give them the environment and tools they need to succeed as software engineers.
We view our junior engineers (test and software) as the latest batch of interns to our fine hospital under the tutelage of our other software engineers. We give the junior engineers the opportunity to apply what they have learned academically on the job and expose them to technologies, tools, and situations that they probably would never see in their classes. As they make the proverbial rounds their skills will improve and they will move closer and closer to being a software engineer.
Why do we do it?
Hiring in the Chicago area is tough. Due to a confluence of factors, we have found that hiring junior engineers and teaching them the skills they need to be successful creates a pool of candidates that we can promote into software engineering positions when they are ready. As these engineers are already in the building, we do not need to educate them on the problem domains and can focus on continuing to expand their technical and problem solving skills. Does this process take time? Yes. Does this process cost money? Yes. Does this process create slow downs at times? Yes. Does this process develop strong engineering talent? Yes. Is the organization better off because of it? Yes.
What is junior?
One thing Jenn points out in her post is that companies need to really think about what they consider “junior”. When I started writing this post I had to think about what Leapfrog considers a junior engineer. It is a term we throw around quite a bit and have a gut feeling about what it means but no real definition. In the past we did not have the concept of a junior software engineer: anyone we considered not ready to be a software engineer was considered for test engineering positions. Test engineers are responsible for the creation and maintenance of the functional test suite for the consumer facing web sites, developing tools to assist in the UAT process, and coordinating releases. Historically, our technical requirements for test engineers were limited. We were mainly focused on finding the right personality. Someone that wanted to expand their technical skills, wanted to learn, and had the drive to do it. With the increasing number of candidates that are graduates of dev bootcamps and other code academies we have started expecting demonstrable code experience from test engineer candidates along with the personality characteristics.
Leapfrog is also hiring junior engineers that are not test engineers. This results in some interesting discussions of whether someone is a junior engineer or a test engineer. The things we look for in a junior engineer include the ability to develop a full application, understanding of unit testing, experience with ruby/python or wanting to quickly learn one of those languages, and the desire to learn. Some of the things we look for are somewhat subjectively measured but the driving factor is that we are looking for a junior software engineer to be contributing to their team in three to six months.
What is the path?
The traditional path junior engineers take starts with them in the test engineering department followed by promotion into software engineering. Historically, these engineers were members of scrum teams along with software engineers, allowing for day-to-day mentoring of junior engineers by more experienced engineers. Recent changes in our platform resulted in test engineers being segregated more from software engineers—a pattern we are looking to change becase we want the mentoring to continue. Over the years, the test engineering path has been fruitful and resulted in numerous software engineers. We currently employ one senior software engineer and two software engineers that followed this path. Outside of current employees, there are several others who left the nest to pursue other opportunities.
Nurturing a test engineer to the point where we can promote them to a software engineer takes time: from eight months to over a year and a half, largely depending on the person. With a long lead time we either need to keep the test engineer candidate pool full or diversify from where we are hiring software engineers. The most obvious pool we are now drawing from is the pool of junior software engineers from outside the organization.
The external junior software engineering pool is difficult to navigate when you are only looking for a handful of people and they need to be the right people. What makes utilizing this pool more difficult for Leapfrog is our lack of experience. We depended on our test engineer promotion path for meeting our software engineer needs and did not develop the skills needed to effectively and consistently identify external junior candidates that would be successful. We have had some success and are iterating over our process to better focus our recruiting efforts.
How do we get test engineers up and running?
When a test engineer joins the organization we start them off with a project that is designed to, at a small scale, take them through the process of creating their own test framework. We have an existing framework in place for our functional test suite but we find it very educational for new engineers to make their own. This gives the new test engineer a low pressure project for them to establish a footing with python and become familiar with functional testing concepts. Following the completion of the onboarding project they begin working on tasks supported by other test engineers. As the test engineer continues to mature their work will also include updates to the testing framework and creating/improving other testing tools. When they are deemed ready, they are promoted into software engineering.
What is the environment like for junior software engineers?
Once a junior engineer is part of the team we need to provide support to help them be successful in their role. We like to see engineers contributing to their teams within three to six months of starting. The first task we give a junior engineer is an onboarding project. The goal of the project is to familiarize the new engineer with our microservice architecture and other tools that are the foundation of what we do. Pairing and asking question is encouraged along with allowing the engineer to work alone as they become more comfortable. After the oboarding project we continue supporting their education as they familiarize themselves with the applications that they will be working with on a day-to-day basis. When they first start working on a project, we encourage them to ask as many questions as needed and to pair with other engineers as often as possible. Pairing with an experienced engineer helps to increase the junior engineer’s familiarity with the system and provide real time technical feedback. As the engineer feels more comfortable they are encouraged to work on their own. We try not to limit what types of work a junior software engineer can work on but we do give some direction towards tickets they will be able to complete successfully. There is power in early wins because they boost the engineer’s confidence.
Throughout this process there is the expectation of failure. We do not frown upon failure as it is the primary mechanism by which we learn. However, if you fail and learn nothing from it, that is a problem. Failing, identifying why, and working to mitigate the problem in the future is a key indicator of an engineer that is going to be successful at Leapfrog.
Where does the path stop?
The next step for software engineers that want to continue being software engineers is to be a senior software engineer. The characteristics that we use to identify a senior software engineer are primarily “soft” skills built upon the technical implementation skills they have been developing. The senior software engineer role has a diverse set of responsibilities. Senior software engineers continue to implement features and fix bugs but they also are responsible for architecting the systems they are working on, working with product development to scope out new features and working with other teams to coordinate implementation activies and rollouts. All of these responsibilities are communication heavy and a senior software engineer’s ability to work with their fellow engineers and gather consensus is critical to their success. After being successful as a senior software engineer there is the option of adding management duties to become a practice lead.
We try to maintain alignment between the engineer’s interests and the duties at Leapfrog. As an engineer matures and they find themselves more interested in systems engineering or other technical disciplines, we try to allow them to explore that interest and even change positions entirely.
Today’s interns mature into tomorrow’s resident that matures into the next brain surgeon. Simiarly, today’s test engineer is tomorrow’s software engineer that is tomorrow’s senior software engineer leading the restructuring of Leapfrog’s platform. Not all of our test engineers stay with us but we hope that wherever they go they will continue to have a positive impact on the junior engineers that are looking to them for guidance.
Finding the right company to work for is especially important for junior engineers as the right company can put them on the road to success. An environment that enables you to apply what you have learned and to add more skills will enable rapid growth and allow you to contribute meaningfully to projects. I’m sure Leapfrog is not alone in its approach to training the next generation of software engineers, but it is an excellent place to learn. I am a result of this process. When I started here years ago, I was a young engineer and working in a team for the first time. I quickly realized how limited my understanding of the engineering world was and I had a lot to learn. Years later, I am now the tech lead for the platform that supports the majority of the web sites that Leapfrog operates.
Director, Software Engineering