Ask HN: Engineering managers, how do you onboard new hires?

I work in a small startup (<20 developers) and the following is what I am doing for my team:

1. A week before their joining, we ship the laptop

2. I'd have a calendar ready for them, which gives an overview of what they will be doing for the next three months

3. First week goes into setting up the tooling on the machine. Someone from the product team gives an overview and entire product walkthrough. Next, they spend some to play with the product as a user. This week also involves the initial orientation session.

4. We use Golang heavily, however, the people joining might not know it. The second week goes into doing the tour of Go.

5. Third week they spend on onboarding tutorial that shows how to write a small service, generate APIs, build, and deploy it in our infra.

6. Fourth week they will spend shipping a really small feature to the production.

7. Since day one, they'd have assigned a buddy who becomes their go-to person. Buddy also explains them about the culture, how things typical done here etc. The buddy also creates a new slack channel just for them, where they can interact.

8. They pair with the buddy in the initial weeks, where buddy is the driver.

9. First three months, they'd spend working on a feature along with someone which also involves some good amount of pair programming.

The advice so far in this thread is great, but I'll add one thing I did back in my former manager life, which was to have a scheduled time block each week of a few hours for general Q&A.

Each week I'd have them pick a topic or area they want to learn more about, and I'd go in front of a whiteboard and explain things to them in as much depth as they wanted. We'd go over the codebase, how it fits in with the rest of the organization, historical reasons why things work they way they do... or even just help getting their dev environment set up, reviewing code, etc.

Of course, everything was already pretty well documented and explained in other places, but nothing beats actual 1:1 time to help with any confusion they may have. It helps build confidence because they know that time is a safe space to ask any question, no matter how "dumb", and that it's all for their benefit. It's also beneficial for there to be multiple hours of time set aside, so that we could actually dive deep and not just leave things as an exercise for later. I was told this was their favorite part of the early months on the job, because it helped build confidence and skill more than any other single thing.

One of the hardest parts for onboarding is determining which code is relevant.

If you're dumping a 300K line codebase in your newly hired engineer's lap, you're failing them.

This is one of the reasons why I developed Call Stacking - it records all of the method calls for a given endpoint (trace).

This is the perfect documentation for new hires - because they can look at these traces and get an instant idea of what is happening on the backend.

https://callstacking.com/

We're a mix of remote, on-site, and WFH, but it's roughly similar for most people:

- Before you start we send an onboarding plan: As detailed as we can for the first 7 days (e.g. onboarding call, intro to this or that, pairing up with another Engineer), and much more high-level of expectations after 30 days and after 3 months

- Everyone has an "onboarding buddy": This is an Engineer on their team and makes sure the other Engineer feels like it's their responsibility to spend time getting the new Engineer up-to-speed

- If you're fully remote we try to fly you into our HQ (Copenhagen, Denmark) for the first week. We've had overwhelmingly good feedback on how big of a difference this makes in establishing connections and making people feel a lot more comfortable with the colleagues much earlier on.

- We focus on giving you a lot of context initially: The organization, the team and their purpose, meeting up with your manager weekly so they can fill in the gaps continuously, intro to the overall tech infrastructure

- We dive into the specifics via work: Finding smaller projects that are well scoped to get you into the various corners of the teams' domain

- We knowledge share a lot via PR Reviews: Onboardees always add two people on the PRs to maximize knowledge sharing over speed initially. After a month or two they go down to just the regular 1 person and they themselves also start reviewing code

- From then on: We freestyle, but have a continuous focus on learning. At this point, people are so unique and varied that we adjust on to their learning style, gaps, etc.

Everyone in the team is quite communicative. One thing we explicitly focus on is for new people to get comfortable asking in public channels instead of via DMs. This comes naturally to some, but not to others and they need some nudging and you showing off how its safe to do.

There's many more things we do, but those are some of the important parts of the top of my head :)

EDIT: Some context around our environment. We have our own CLI tool to quickly setup a dev environment as well as using GitHub Codespaces as a fallback. There's strong coverage of CI for checking everything is good, and things are deployed very often. We try to automate most of our flows, at least as much as we can to keep friction low, but also to minimize "things you need to just know".

We build an LMS, so the first thing we do is get them onboard using it. You only get one first impression, so it's normally really good to see and for them to feel the product as a new customer would. Take lots of notes, find the rough edges, things that hurt, and then typically pick one of them as the first week task.

Then it's getting the environment setup. Using lots of boring software means this is typically two docker-compose up's and done.

After that is the point you start to see what the candidate's really like we've found. Oftentimes they'll scan through previous commits, see how things are done. We'll set them running, lots of pair programming, for those first few days. An extensive testsuite/CD pipeline help here. The ideal is push to prod by the Friday. In an ideal world it's earlier, if not first day, but the reality is there's normally other business bits such as...

Because we're remote, we try and schedule a couple hour calls with different folks in different roles. We're a small company so it's much more about people then processes without falling into folksy management talk.

Biggest thing is just letting them get a feel for the codebase, people, practices, trade-offs between speed and correctness etc. Everyone's unique.

1. Psychological safety is key. 2. Onboarding buddy. Someone good at explaining the systems and not too oversubscribed. 3. Onboarding plan/doc/reading list. 4. Constant vigilance to keep your systems simple/understandable, and discipline to keep good documentation available internally.

Most of "procedures" i see is a waste.

I would just do a pair programming session to explain all the design patterns being in used. THen let the new hires hack on exisiting/new features.

The onboarding is a failure if you can't help new hires get productivity quickly.

Onboarding is probably one of the hardest parts of the job. Keeping code quality high and documentation definitely help. One thing I don’t see mentioned in the thread yet is mentorship. I try to spend more time with new hires to help them build a plan for contributing and identify gaps in their knowledge and how to fill them. I also look for opportunities for them to work closely with more experienced devs on the team. Besides having another person to learn from to who isn’t their manager, I find the experienced devs appreciate the chance to share what they know.

Step 0: Don't be on vacation the week they start.

They will need you. They will need to interact with you to ask questions (even if they have a "dev buddy", they will still need to ask questions of the manager). They will need to interact with you to have you fix problems. They will need to interact with you just for emotional reassurance. And, even if there is no direct interaction, there are things you need to be doing behind the scenes to make everything work smoothly.

So, what I said: Their first week, you need to be there.

1 day: - Overview of what they will work on - Give some time to install things and play around 2 day: - Ship your first (small) feature

I'm surprised at seeing how long time to production is. I'd be concerned if they went 2 weeks without shipping anything.

We don't do physical onboarding as no-one is close to any of the offices, but physical get-together are huge in boosting team building. We try to do them at least yearly. Churn is way higher without them (= people don't care about you unless you drink a beer with them)

My favourite tip is to assign them a technical buddy, which should ideally be the last person who joined before them on the same team or related group of teams.

At Toughbyte, our onboarding process looks like this: on the first working day, the new employee has all the necessary accounts set up and receives a document where we’ve detailed how we see their progress after one week, one month, and three months of work. An onboarding checklist helps the new developer navigate the company knowledge base, understand the technologies we’re using, our code base, and the most common mistakes to avoid.

We try to get the new employee to write code from the very first day. They start with simple tasks, such as fixing issues on the frontend, adding tests, and working on the business logic. Such tasks help them get acquainted with the code and lower the risk of breaking something critical.

The onboarding guide is also useful for mentors. It describes the learning plan for the new developer, as well as how to better organize the learning process itself.

More info here: https://www.toughbyte.com/blog/how-we-hire-junior-developers...

Day 1: laptop, credentials, hr and high level security/policy stuff. 2-3hr pair programming session to grab an editor, git checkout of their first assignments repo and to push a tiny edit (small bug or doc fix). This ensures they have the tools and access they need to get started. People report it as a long hard day but its pairing and collab so they meet the real people and real work

Goal is to ship a real contribution in week 1 if they know the stack. Week 4 if they don't.

Company culture, business etc goes in parallel at 2-4hr a week of formal meetings for the first month or so. It used to dominate the first week but was too much context to learn in one week.

There is an assigned tech buddy all the time and daily scheduled q&a time from a lead for the first month. 3 months in and they count as a full FTE on the schedule. Before that we expect a good chunk of the day goes to learning and understand that goes for the buddy as well.

Edit: of course the learning never stops for any of us but this so far for me has been the quickest way to get to learning together while contributing as you go

First day at work: - Onboard with HR - Get the laptop, headphones, etc. - Credentials and VPN should work. - Office access (if needed. I insist all engineers MUST BE ABLE to work from the office... if they want, or the neighbour is making renovations, etc).

First week is for meeting colleages (we're remote), and get rid of as much mandatory training (legal, safety, compliance etc) you can. I expect some training yet to be done still on week 6.

The new hire is invited to agile rituals from day 2, but nothing is expected. Just to get used to the vibe. He/She might pick up things as they appear with the help of a buddying engineer. But no more than one task at time.

After week 2 he/she can start writing... words, not code. Code review is Ok, but might be too much for some people. The point is to make sure s/he knows where to ask, where are some things...

After week 3 should be allowed to code :-)

A lot of what is in this thread is excellent. I'm actually working on a fairly detailed HOWTO for creating a custom-fit onboarding program (send me an email and I'll send you a draft; I'll update here when it's ready for public consumption). Here are the key principles:

1. Know what you want the employee to do, and equip them to do it. (This covers things like shipping the laptop ahead of time, getting accounts set up, planning tasks for them when they start...)

2. Help the new employee feel supported. (Item #1 relates to this, but it's also things like welcoming them on their first day, assigning a buddy, giving them a tour of your company / application / industry, making their initial responsibilities clear...)

3. Have a plan for bringing them up to speed. They need to get to know the job itself, the company, the people, and that all takes time. Work sequencing is important in building a product. It's even more important when it comes to integrating a person into a complex network of activities and other people.

In all those items, the ability to put yourself in the new hire's shoes is essential. It's easy to forget how much you know about the job, the company, etc., that you end up giving them tasks that feel small, but that are daunting to them. That said, taking time with the new hire regularly over their first couple of weeks and building a good working relationship can help calibrate, and help smooth over any potential issues that come up from being miscalibrated.

Also, a couple posts I've written about onboarding might be helpful:

- https://www.cybadger.com/2022/07/02/a-tale-of-two-onboarding... is a reflection on two onboarding experiences I've personally had

- https://www.cybadger.com/2022/10/11/onboarding-gis-technicia... is creating a better onboarding experience for a non-developer role, but the principles are the same.

I manage a team of SDETs, and I've written a formal 90-day onboarding plan with 12 weekly sections that include checklists at the end of each week. We store this in Notion, so for a new hire, I just clone the entire page, hand it off to them as their own instance, and let them treat it as a worksheet.

Obviously, we also meet for 1:1s and do lots of hand-holding for new hires, but having that template really helps make our onboarding more brainless (for us, not the hire) and seamless (for both parties).

Not an engineering manager, but if I was, I would consider investing some time fine tuning GPT-3 (using OpenAI API) on the company's codebase, documentation and processes. Then create a Chatbot which can answer almost any question new hires might have.

It's a bit tricky for me. Suggestions like "fly them to the office" is great if you have lots of people in an office, we don't. I also don't agree with "give them the power to fix things" since one person's broken is another's "don't waste time fixing that, it's flaky".

I think it depends a lot on the person you hired and at what level. I can trust an experienced Dev more to know how to look at the more important parts of the system whereas someone with less experience won't necessarily know this and we don't want their first week being keen but everyone else hating them for breaking stuff!

Definitely agree with the Dev buddy and I think the pair-programming thing is probably the best way for them to learn quickly and for both them and us to get feedback e.g. are they not the right person for our culture? Are they too strongly opinionated etc.

I think this is a special case of what the OP was asking, but if you're a really big company, this is one way to do it.

Way back in the 90s I worked supporting IBM AIX compilers. IBM had an interesting technique for onboarding engineers that started with them being interns. If they liked you, they would hire you as an intern for the summer after your first year and plonk you down in the call center. Part of my job was training / orienting the young kids who were the first line of support for compiler issues. We spent a week with cultural indoctrination (the right answer is ALWAYS better than a fast answer) and basic training (AIX, vi, how your phone works, how the issue tracking system works, etc.) Compiler support interns got another week where I showed them how I put together test cases to find corner cases. I also trained the networking tools interns and showed them how to use tcpdump & perl (this was before ethereal.)

But the key here is they spent three months learning about AIX, TCP/IP and/or C/C++, FORTRAN and COBOL compilers.

In year two they could return to the support trenches if they really liked it, but we encouraged them to take a role in the QA department. There was a similar deal there... a week of indoctrination (a correct answer is PROBABLY better than a fast answer) and training (intro to shudder PROFS, IBM's tool for doing everything, custom QA tools people had built, etc.) We also gave them a bunch of example tests to improve / modify.

So after summer number two, they were trained up on what AIX + Compilers did and a little bit about the internals of several products; advanced interns got to look into the executive... er... kernel.

Summer #3, if they came back, they got do do a few coding tasks as junior developers. This is back before the web when we did REAL software: text editors that directly opened /dev/kmem and read/wrote data structures to various kernel queues (system calls? never heard of them), used IOCTLs to write data-structures into the networking subsystem that were only documented on bar napkins, and ksh scripts that emitted LISP compilers written in ksh that compiled to ksh scripts, etc.

In summer #3 they were given the secret manual that told them a FAST answer is many times better than a CORRECT answer, but don't be afraid to tell other people when you learn the fast answer you gave them was not entirely correct. Also, be aware other people are going to be updating their answers to you.

So... IBM tried to get their hooks in young developers early. Started with a summer where they learned what the product did, then a summer where they looked at how the sausage was made and then a summer doing basic coding tasks (almost exclusively in C, sometimes C++.) This was back when IBM had a LOT of job openings, so if they evaluated well in their internship, they would be given a job offer just before graduation, and there were PLENTY of jobs for them to choose from.

Usually their first three months was quite structured, but mostly focused on how to use various internal IBM tools.

So to recap... if you're a REALLY BIG COMPANY... onboarding begins before you hire people. It starts by engaging candidates early so they get an idea for what your company is like and what typical tasks look like.

IBM "invested" 9 months of intern pay (which was pretty good for interns in the 90s) to indoctrinate and evaluate potential long-term employees. Its unlikely any business would do that today, but I think there are some good lessons here for every company:

a. It's a good idea that your engineers know what your product is supposed to do. You might want to give them a little time with the manuals (oh. I'm sorry. I forgot, your code is self documenting so we don't do documentation anymore.) or your test code so they at least know how the API is supposed to be called. (related: if you can't explain what your product does to an engineer, in a way that an engineer can understand, you have problems.)

b. It's at least as important to immerse the new-hire in work culture as it is for the new-hire to demonstrate their technical chops. (if, as you're explaining your culture to a new hire, you use the word "meritocracy" or "wholistic," you probably have problems. consider reading anything by Isaiah Berlin.)

c. Nowhere in this comment did I say IBM ever listened to anything the interns said. Don't do this. Schedule a meeting about 3 weeks out and go over the new-hire's questions / concerns about process / culture. Make sure you tell them you're going to do this so they can be prepared. (You should do this at least every quarter (I mean a 1-on-1 where you talk about process) but the OP asked specifically about onboarding...)

d. Your on-boarding process may be different for junior engineers as experienced engineers. IBM invested time/money to teach kids "the IBM Way" so they wouldn't have to un-train them later. Experienced engineers always need to be "un-trained" to a certain degree, but you'll need to have a good idea for what you want to un-train them on. So for experienced engineers, include a week or two in there where you slowly explain: 1. there's a reason we have at least one branch that can be deployed, that's part of why we do testing, 2. pair-programming is actually useful, but it's hard to explain when you should do it, you just have to learn it along with your team, 3. no. software developers write tests and documentation. 4. it's okay to use expletives in the office as long as you're cursing at JIRA or Confluence. 5. Markdown is a pox upon humanity, but it's a useful pox upon humanity so revel in the sickness until something better comes along. 6. no. we won't start using TLA+ until AFTER the whole team understands point-free and functional styles. 7. no. there are good reasons you can't use co-pilot. 8. ask questions. but the person you need to talk to might be in the middle of something else so you may have to wait a bit. have a backup task handy. 9. (related to 8) - asking questions about why things were implemented a particular way is not admitting defeat as a senior engineer.

Okay... now I'm ranting...