Creating Early Career Software Engineering Learning Cohorts
I want to tell you about an effective way to grow your early career software engineers while giving them support and community. But first, I want to tell you about how I got here- at the start, I didn’t have any early career software engineers to grow!
A Super Senior Growth Machine
When I started at my company almost 8 years ago, the software engineers were almost exclusively senior engineers. Well, there was an intern. I had been a software engineer for about 13 years, working at companies ranging from startups to Fortune 500s. I had never worked anywhere where everyone was operating at such a high level. It was great, and a little bit intimidating. Our engineering team was about 10 engineers and our head of engineering made the decision, not unreasonably, to hire senior talent at this stage of our company.
Fast forward several years and now the engineering team was an engineering department of over 200. We still had very few engineers at the start of. or early in. their careers. Obviously growing as much as we had, it’s hard to argue with the success of our hiring plan. I am very proud of the hiring myself and others did. We had assembled a very impressive team of engineers.
Still, I was starting to have concerns. By this point I was a Director overseeing 9 teams and from my vantage point, there were some cracks in our leveling strategy. We weren’t seeing as many clear standout tech leads on teams. Who’s the technical leader on a team of people with over 10 years of experience? We saw either the one with the most tenure, the most social, or no one. This has obvious issues when there is contention on technical direction or in getting proper oversight. I wasn’t seeing clear ownership and direction of technical roadmaps. Every task on a team fell to a senior engineer, whether it required one or not. I felt filling out the lower levels of our career ladder would help teams grow clearer technical leaders and provide mentorship opportunities to our senior staff.
Another big concern was our diversity breakdown. When you hire senior engineers you are relying on the past and other companies to train and grow your engineers. It also means you are pulling on the gender and ethnicity makeup of our industry from 10 years ago. Unsurprisingly, we skewed heavily male and white, even by industry standards. Creating diverse teams has a ton of benefits that we weren’t getting and we weren’t providing opportunities to a new generation of engineers.
Reattaching the start of the career ladder
I was able to gather consensus among senior leadership to change our leveling strategy with our hiring plan. We made a few changes to our hiring process to make it more appropriate for early career applicants. We removed expected years of experience from our job postings. We changed our final live code test from “senior engineers watch you code” (Intimidating!) to “pair program with a senior engineer”.
The real work it turned out, was talking to hiring managers and interviewers, often 1:1, convincing them to hire non-senior engineers. My strategy was to work on individuals. For hiring managers, they had concerns about juniors slowing down the team, due to a lack of scale experience. For interviewers, I had to walk them through very different expectations for the qualities we were looking for. It was pretty unlikely these applicants’ resumes were going to look anything like their colleagues. Often I needed to follow up with an interviewer after reading their feedback for a candidate to ask simply “Is it that they don’t know X or that they can’t learn X?”
All of this paid off in the second half of that year. Engineers with less than 4 years of experience accounted for ~45% of hires, up from ~10% in the first half before we implemented the plan. The following year we sustained an average of ~30%. The average level on teams fell by a full level (we have 5 engineering levels). We hired people right out of college, from bootcamps, and folks just a few years out. We also made some real progress on our DEI stats.
Hiring is only half the battle
After that impressive 2nd half of hiring, I was hearing great things from managers and senior engineers about these new engineers. Turns out hiring bright, ambitious albeit inexperienced engineers was having a positive impact on teams. I did hear that junior engineers were more high touch in onboarding. That wasn’t very surprising, but something to look into. I decided to get these new early career engineers together and see how onboarding was going from their perspective.
The meeting was pretty interesting. On the positive side, they felt the senior engineers and managers were kind, patient, and helpful. They felt they were learning fast and already making real contributions to the team’s work but without unreasonable expectations. (Another proof for culture is everything) But there was plenty of feedback on where we could improve:
- Surprisingly, most of the junior engineers didn’t know there were so many other new engineers like them (we had spread the hires throughout the organization).
- Our documentation could be described as “for seniors by seniors”: lots of assumed knowledge and acronym soup.
- It was very hard to know where to ask their questions compounded by feeling intimidated speaking in a Slack room full of folks they may not know.
- Universally, they longed for more structured learning opportunities.
It was pretty clear these engineers were doing well, but could really thrive with a bit more structure. We briefly considered a bootcamp approach that many other companies do, but ultimately decided against it. These engineers were learning a lot “on the job” already, but we could help them in three clear ways:
1. Creating a community of peers
This is pretty simple- create an environment where these folks can talk amongst themselves, safely asking their questions and sharing with each other what they are learning. We made a private slack room and scheduled a bi-weekly hangout.
2. Providing structured, relevant, hands-on skill building sessions
I enlisted a principal engineer to create a curriculum of important topics. We’ve had sessions on resilience (timeouts, retries, circuit breakers), caching, security, AWS, SQL Tuning, Infrastructure as Code, Asynchronous Messages (SQS, Kafka), and Containers.
For each topic, we select a senior engineer to create and lead the course. We follow the following format:
- Provide self-study material. This is a combination of internal documentation, source code, and external articles on the topic.
- We also include a set of self assessment questions (“What are some of limitations of in-memory caches?”)
- Give a “take home” exercise. This should apply what they learned in the reading material to a realistic scenario. Examples have been “Extend this application to use our internal caching library” and “Remove the security vulnerabilities from this sample application”.
- Hold a discussion with the group reviewing the readings and the exercise. Have a few engineers show off their code (get them building those presentation skills!)
3. Hold talks on “what they don’t teach you in school”
For the majority of our junior engineers this is their first professional job or their first in our industry. There is a lot to learn to become strong business and product minded engineers. So we’ve held presentations and discussions such as “A primer on our tribal knowledge” and “How to embrace our culture” (held by that intern from when I started, now a senior engineer).
Wrapping Up
We’ve heard great reviews for this structured learning program matched with on the job learning. This has kicked off a flywheel effect of happy and growing early career engineers becoming more and more impactful. This in turn helps hiring managers justify hiring more junior engineers. Personally, I’ve found this work some of my most satisfying. We’ll continue to learn, listen, and revise our program in the future. We plan to kick off new cohorts as we continue to hire juniors.
I’d love to hear what others are doing to attract, train, and retain early career software engineers!
