00:00:00.320
How many of you wrote Ruby in your first engineering job? Hands up. How many people have interviewed? Keep your hands up. And how many people have interviewed someone for what would become their first job? Cool! It is super terrifying on both ends. I'm Rebecca Poulson and this is The Junior Jump. Today, we're going to talk about onboarding, particularly focused on onboarding new engineers.
00:00:20.000
I think this conversation is particularly relevant for us to have here at Rubius because over the past several years we've really become the welcome gate for a lot of people, including myself, into the programming community. Who I've become as an engineer is largely a result of the resources and opportunities I've had at my job rather than anything I did in preparation for landing that job. It’s a lot of responsibility for us as a community because not only are we training the engineers we work with, but it's very likely that we're onboarding engineers who will eventually train future engineers.
00:00:45.120
Before I was an engineer, I worked as a bartender and a playwright, so I got pretty good at talking to people professionally. I might be super awkward if we're in an elevator, but if I have a problem to solve, I really like talking it out with others. As I was putting together this talk, I spoke with many people who are currently in their first jobs, along with those who mentor and hire these individuals, and many more senior engineers about their onboarding experiences.
00:01:02.640
One commonality I noticed was that you can really structure an onboarding experience in terms of three Ps: planning, projects, and pairing. By 'pairing,' I actually mean mentorship, but I figured you'd remember it better if I used alliteration. Let's break down these points, starting with planning. Spoiler alert: it's all planning. I want to talk very specifically about planning because we need to address a maddening part of my job search.
00:01:25.760
The most frustrating aspect was that everywhere I wanted to work had never hired a candidate like me, and they all asked some variation of the question, 'What do you need to succeed here?' Honestly, that's a tricky question for candidates to answer. Junior candidates don’t have that experience coding in a production environment; they don’t know what resources are practically available at the company. When you ask a candidate this question, you’re expecting psychic abilities they don't have.
00:01:56.680
However, what candidates can provide is self-awareness regarding how they learn best. That is a valid question to ask during an interview. When you're hiring at the junior level, you're not just hiring for coding ability but also for how much fun it'll be to teach that person. It's really tough when you're just starting out to know what resources to ask for. I nearly didn't include this slide because it's visually unappealing, but then I realized it represents the core of my talk.
00:02:26.720
These are things that are valid for you to ask for and for you to offer. Conferences, for example, are fantastic. If your company can’t fund them, at least seeking them out is useful. Identifying those opportunities is often tough. Hosting meetups is also an excellent option, especially if your company has many senior engineers. If you have the space, hosting meetups can provide a peer group for the juniors that you’re mentoring.
00:02:50.560
Books are great tools, too. They can provide structured mentoring. For instance, working through resources together is a valid experience. Then, there’s face time. When I started, I was advised to set up a 30-minute meeting with every single engineer on my team. It required a lot of time, but it allowed them to tell me whatever they wanted, which varied greatly from introductions to casual conversations.
00:03:11.120
Although it was a significant time investment and not always practical, it made the entire onboarding experience much less daunting. You learn surprising things that coworkers want others to know. It's crucial to empower people to ask to pair and to be proactive about seeking pairing opportunities yourselves. I believe pairing can create an environment where it’s acceptable to not have project work because that time can be about learning.
00:03:33.280
In my previous experience, I came from an environment where everything was transaction-based—where you were either actively engaged in a task or not. It took me time to realize that not directly working on a product wasn’t wasted time. I asked my supervisor for an hour a week to read about design patterns, and he suggested I take an hour a day. Setting aside dedicated time was incredibly important and beneficial.
00:04:01.600
Transcriptions can also be a valuable resource. It is difficult to follow along when someone speaks at an advanced level for a long time. However, there’s much value in reviewing those notes later. Recaps, in particular, were beneficial for my learning style. I’m a writer, and I have a private blog for documenting new things, which serves as a fantastic educational tool for me.
00:04:29.440
The second most important aspect of planning for junior engineers is getting your documentation game on point. The phrase 'ask the guy who wrote it' is not an effective strategy. You should generate a lot of documentation while preparing for new engineers, and once they get some experience, they should also create documentation. Obviously, you don’t have to print everything out, but it's crucial to document everything comprehensively.
00:05:01.360
Having a well-documented codebase is vital not only for operational reasons but also for social reasons. When transitioning into a production environment, written documentation gives you something to work on while waiting for direction. It helps alleviate feelings of awkwardness at work and offers hope to individuals who are trying to find answers—believing that what they seek might be in something they haven’t read yet.
00:05:29.680
One of the most technically challenging aspects of preparing a new engineer is to plan an appropriate first project. At one point, I considered using a construction metaphor for this section, but instead, I thought about how helpful it can be to think about ongoing work that needs to be done. You all know what a 'round tu-it' is, right? It’s a cheesy phrase, but I think it helps when considering how to assign work to new engineers.
00:06:02.640
Assuming you have the resources to mentor your new engineer closely for her first 30 days, her first project shouldn’t necessarily be the easiest. It could involve work that you have always meant to get to but hasn’t been mission-critical. You’re looking to balance exciting work the junior can do with the help of a mentor and mundane tasks that promote independence.
00:06:34.720
Even tasks that seem tedious for someone with a few years of experience can be very exciting for a new engineer. Don’t feel guilty assigning some of these less thrilling tasks, as long as they are not all that your junior is working on. This not only allows you to delegate tasks that don’t excite you but also empowers juniors by enabling them to contribute independently.
00:07:06.320
This kind of work is particularly useful if it involves interacting with a broad array of products, as it provides an overall view and context for the new engineer. When discussing projects, it's also essential to talk about admin tools. Your admin tools can be an excellent resource for assigning new work to engineers.
00:07:39.600
I find that the concept of making internal tools not only enhances education but also encourages personal growth as you gain experience. You get the advantage of education while engaging with your product. Recently, I spoke with a friend from Etsy, and while they use PHP, they still share valuable insights and experiences within their engineering culture.
00:08:12.000
When I think of Etsy's culture, I think about their strong commitment to mentoring new engineers and their approach to building everything from scratch. I don't think those two philosophies are unrelated. Internal-facing tools are appropriate projects for junior developers, while having a controlled environment lets them hit the ground running.
00:08:44.720
For my first project, I built a tool to automate the posting of DMCA claims to Chilling Effects, a database ensuring transparency in how intellectual property laws affect internet users. This was a manageable project that I could own completely. I wasn't building on top of someone else's work. It was ‘nice to have’ rather than a critical necessity.
00:09:16.560
It's essential to remember the impact of providing new engineers with a story about their work. It’s difficult to explain more abstract concepts to someone outside tech, but having a tangible tool or project to point to makes it much easier. You can say, 'I built that,' which is a story that holds weight beyond the technicalities.
00:09:45.440
The final and perhaps most important P is pairing, or implementing a mentorship model that suits your available resources. Finding someone in your team who can convey the values of your engineering team to the new developer is crucial. Knowing some specific skills is important, but the most valuable role a mentor can fulfill is lowering the threshold for asking questions.
00:10:13.440
Most people who care about being good at something feel like they are failing almost all the time. Communicating with those who are more experienced is the best way to alleviate that feeling. Even if your organization is small, where it's just you and the hired person, write into your onboarding guide the expectation that every new hire will have a mentor.
00:10:36.720
It’s important to meet with that mentor weekly. Some might take full advantage of that resource, while others might not; however, the ones who need it the most are the ones least likely to ask for it. Making this expectation explicit can ease a lot of pressure on new engineers, adding clarity to their onboarding experience.
00:11:10.000
When you're prepared to make an offer, your team should ask these three essential questions: What resources can we provide this person? How can we best assist them? How can they help us to help them? The answers to the latter two should be outlined in your documentation. How many here didn't have a formal mentor in their first role? It's remarkably common.
00:11:39.360
I was fortunate that my first job was with a well-established company deliberately investing in helping someone launch their career, but not all organizations may prioritize this when choosing to invest in junior talent. If the only resource you can offer a candidate is time for them to ramp up, know that our community is full of independent, self-motivated learners. This can be a beneficial investment, but ensure that time is explicitly communicated.
00:12:05.760
However, if your team enjoys a wealth of mentorship resources, you should look at structuring your mentorship like a band—think of U2. The structure of their public persona is a strong metaphor for an effective mentorship team. You need a 'Bono'—this person's role is to explicitly mentor your new engineer.
00:12:37.440
Just as Bono serves as the public interface of U2, this mentor is the go-to person for your new engineer's knowledge needs. This mentor's role involves regular meetings with the new developer in the early days. A critical part of the mentor’s job is to answer questions without passing judgment. New developers often struggle in discerning which parts of the codebase are typical versus the ones they could find via Google.
00:13:07.200
The second key person in the mentorship team is the 'edge.' This role may not be as public, and you might not have extensive face time with them. Perhaps your mentor's mentor or your supervisor could fill this role, but someone excellent at handling it should be available to the new developer for additional perspectives or assistance when necessary.
00:13:33.440
Now, regarding the 'Larry Mullen' role, this often goes unrecognized but is extremely valuable. Being the Larry Mullen of a mentorship team involves being that supportive colleague who doesn’t roll their eyes when a junior developer asks questions. This doesn’t need to be an officially assigned role, nor does it have to reside with the same person every day.
00:14:01.680
Being involved in this role means you can find commonalities with your junior, whether it’s a shared project, gender, or hobbies. Importantly, anyone can be a Larry Mullen; your level of experience doesn’t matter. Everyone in this room has the capacity to take on this supportive role, which can foster a more welcoming environment.
00:14:25.760
To summarize: the first P is planning—work closely with your new engineer to develop a structured onboarding plan. It’s exciting to invest time in launching someone's programming career; work to support that investment. For projects, assign tasks that offer opportunities for growth, ensuring a balance between supervised, exciting work and independent tasks. Finally, focus on pairing to lower the barriers for asking questions—ensure mentorship is formalized, and empower yourselves to be the mentors for others.
00:15:16.720
Thank you!