Onboarding Engineers: How to Tackle the First 30 Days

When you’re a tech lead, the most important work you do is helping other engineers grow and setting them up for success. That means making sure they have the tools, guardrails, and confidence they need to have an impact from day one. But, that’s easier said than done. Pretty much every engineer I’ve worked with has a different learning style, and every engineering manager I know has a different leadership style. There isn’t really a one-size-fits-all method to onboarding but I think we all agree that the first 30 days are critical for every new hire.

TLs at HubSpot are very hands-on with new hires and, personally, I think that’s better than sending them to a week long “boot-camp”. I’d say we do a pretty good job at onboarding engineers, but we’re working on how we share best practices and standardize a little bit of the process where it makes sense. So I shared these thoughts internally about a few onboarding pieces and how I’ve approached the first few weeks with a new hire, and hopefully they can be helpful to external engineering managers, too.

Task Selection

The number one, most important, super-critical thing you can do is to think hard about task selection. That means putting together a detailed list of tasks for your new hire and thinking hard about what skills they'll need to approach each one. I forced myself to write a plan for each new hire. I keep it in a Google Doc to strikethrough each task as they’re completed.

Tips on Task Selection:

1. Have small wins every week so they get comfortable owning tasks and projects. Save some bigger, tastier morsels until they start to ramp up. That way, the impact they’re having on customers will be that much more rewarding.

2. Avoid company-specific things to start. The ideal first task is a medium sized method, with a unit test that needs a behavior change. I typically don’t dive into HubSpot stuff until they’re ready.  

3. Start the task yourself first. If you find you need to tweak Mothra, PR another project, read source for another project, opengrok something, then this is not a good first task for someone new. 

4. Think hard about how long you expect these tasks to take. Split them up by week so you can see how they're progressing relative to your expectations. (Factor in time for them to get their workstation setup.)

5. Develop weekly themes (and don't forget to tell your new hire what the themes are). I'd skip JIRA / Sentry / Monitoring to start. They're great things to do as a week 3-6 "theme".

6. Work towards a moderate sized feature in week 4 that is challenging but has clear bounds. Ideally, this will be their first major work on whatever section of the code base you’ve decided to give them ownership of.

When you’re writing your plan, think of it as "telling a story" to your new hire. "First we're going to learn A. Then we'll learn B. Then we'll see how A+B can work together." "The reason we are doing A is because ..."  “Don’t worry about anything ops related, we’ll be doing that in a few weeks”. Giving people a timeline can make the ramp up period much less stressful because they don't feel like they're expected to do everything at once.

Coding Mentor

Pairing new hires up with a coding mentor isn't something we do all the time, but I think it can be really useful for certain people. Ideally, a mentor will be a more junior coder who is looking to expand their scope, or is just a few steps ahead of your new hire on the learning curve. (Save a super-coder for a few in depth code reviews.) This person should be on the front-line for questions before they need to ask in Slack, ping their their coding style/formatting helper, or check your resources reference. This is particularly beneficial if you’re a backend tech lead trying to onboard a frontender or a frontender with a new backender.

Wait, but why not do this yourself? There are a few reasons. First, it will introduce them to other people in the organization and since tech leads are more likely to get waylaid by interruptions, it should provide them with a more reliably available resource. Secondly and I think more importantly, this makes your role more like a coach than a teacher. It orients you toward guiding their approach to learning rather than being their oracle.

Pull Requests

Pull requests are the lingua franca of engineering culture at HubSpot, but there are a number of pitfalls to be avoid.

1. Consider what PR behavior you "model". If all a new hire sees is you aligning code and and fixing style conventions, then that's what they'll fixate on. If you’ve paired them with a coding mentor as suggested above, then their mentor should be in charge of style conventions.

2. Be careful not to do too much QA. Fixing subtle bugs in a new hire's PRs can lead to a dynamic where they code and you're in charge of QA. Rather, push back on PRs to make sure that they have a plan about how to deploy it safely, and how they'll verify it's working in production. You don’t want your “lgtm” to mean “I put my personal seal of approval on this code and confirm that it works as expected in production”.

3. Agree upon a system sketch before they start coding. PRs are an unfortunate and expensive place to redo the architecture of a solution. It’s very discouraging to code, put up a PR, and then hear they’ve re-invented the wheel because "ServiceXYZ" already did that. If that's happening to your new hire, you're not giving them what they need to succeed. Work through each task with your new hire in detail before they start coding to limit wasted work. I have had great luck working with Sketch to bat some complicated proposals back-and-forth; here's an example of a final Sketch my team and I came up before starting a fairly complex project: 

4. Focus on naming and clarity of code. PRs should be easy to review because the variables, methods, and code organization are clear. Optimize and nitpick until PRs are easy to read because the intent and effects of the code are so very clear.

5. Avoid massive PRs, but always keep your primary branch deployable. That’s easier said than done though. How can we reconcile a deployable primary branch with an avoidance of long-lived branches? Feature flags are our primary weapon here. Help your new hire figure out a strategy to get all of their code into production, but hidden behind a flag. Better yet, break that PR down into a few logical chunks that can be independently verified to work and even then put them behind a feature flag so you can deploy safely even if they don’t work.

Pair Programming

Wouldn't it be neat if there were a way to convey all of your wisdom without having to spend nights and weekends working? Do you feel like you don't have time to make a detailed plan for onboarding and coaching your new hire? Why not try pairing? In just a few hours a week you can successfully onboard your new hire by just sitting down next to them and working with them for an hour all for the low low price of free.

All kidding aside, pairing (two people coding on the same problem, be it small or large) is a great way to onboard your new hire. IntelliJ tips and tricks? Check. Working on how to break down a problem? Check. Super fast ability to give feedback on coding style? Check. Efficiently teaching them what tools and services are available? Check. So, what are you waiting for? Call now to start pair programming today.