Geoff Harcourt’s team currently has zero C.S. majors. Only one of his developers is a lifelong software engineer, and she didn’t major in Computer Science – she majored in Math.
Instead, engineers at CommonLit hail from the following backgrounds:
- Schoolteacher
- Journalist
- Motorcycle Mechanic
- Graphic Designer
- Environmental Protection Agency Employee
- Web Project Manager (that’s Geoff)
Something else that makes Geoff’s engineering team unique: it’s half women engineers. CommonLit is a woman-lead 501C3 nonprofit where a majority of both the marketing and product teams are women as well.
According to Geoff, software developer bootcamps like Flatiron School and General Assembly are a primary reason for their uniquely progressive team.
“Looking at bootcamps and finding early-career engineers is a great way to go outside your network to build your team,” Geoff says. He adds that it’s not a perfect solution. “This strategy requires a commitment to invest in junior engineers to help them grow.”
But, CommonLit is a consumer-facing product with hundreds of thousands of lines of code. It has to work nearly flawlessly all the time. It’s a key resource for many students, especially those in disadvantaged school districts. If a teacher dedicates a lesson plan to CommonLit and it’s down for 45 minutes, that’s a problem for both the teacher and the students.
How do you dump bootcamp grads into a huge consumer-product?
Geoff knows first-hand how intimidating it can be to jump into a product like CommonLit. During our interview, he described it as being similar to parachuting into a foreign country. He started his career at a government consultancy and only become interested in engineering later on. His first project out of bootcamp was a karaoke voting system. It had to work for 50 people at a time, not thousands.
That’s why Geoff created a unique onboarding experience for new coders. We sat down with Geoff over Zoom and asked him for his advice. How can companies create an awesome Bootcamp-grad-friendly onboarding experience? Here’s what he had to say:
1) Two-Week Pairing
When new engineers arrive at CommonLit, they’re instantly paired with a more experienced engineer for two weeks. After those two weeks, they’re paired with another engineer. If there are 7 engineers on the team, that means the newest team-member gets a solid 14 weeks of collaborative training and mentorship.
2) Holistic Training
Some companies expect employees to hyper-focus on the product from day one, but not CommonLit. Their training is designed to teach new employees everything from how to do code reviews to the product and style guide. Meanwhile, new engineers get to know their teammates – and not just in the engineering department.
According to Geoff, “it’s not gentle but it’s as gentle as we can make it.” His goal is to make sure that joining the team isn’t “scary.”
3) Canary Testing and CI Monitoring
Geoff doesn’t trust anything to chance. He’s created a thorough system of testing that removes a lot of the stress from shipping code. For example, the team uses Percy to create visual snapshots in CI. It takes pictures of web browsers and flags snapshots if they differ by more than one pixel.
The team also does a second series of tests called “canary tests” every time they deploy. Each time, a hook gets fired that tells the build system to queue up some Cypress tests. Every public page and workflow gets visited and snapshotted by a real web browser. That way, the team will know quickly if the font moved or the color changed or a teacher can’t sign up anymore.
(For more on testing, check out Part II of our interview with Geoff where we discuss three testing tricks he developed at CommonLit.)
4) Onboarding-friendly Code Reviews
Geoff says that when he talks to engineers at bootcamps, he wants them to know that CommonLit supports their success in engineering roles. He knows that’s a concern for many bootcamp grads, especially if they have a background typically under-represented in tech.
But, the support doesn’t stop there.
“Our code review process helps people get acclimated really quickly,” Geoff shared.
He added, “we keep pull requests small” and they go through two rounds of review. Code reviews are “thorough, human and supportive,” and “empathetic and helpful.”
5) Learning from Each Other
“We had an engineer who was totally unwilling to just nod and say ‘yes,’” says Geoff proudly, “She always asked why would you do that and she didn’t take anything for granted.” Geoff encourages questions and believes that asking “why” is central to learning.
As part of their culture of learning from each other, the team holds regular lunch and learns (now called “brunch and learns” to include the engineers in California). Engineers teach each other about topics like how production traffic gets routed at Heroku or how timezones work in code.
As we finished up our conversation, Geoff ended with a bold claim. His code reviews are almost universally positive and constructive. We can see why. CommonLit lives its mission to provide the resources for success.
