Ask HN: Engineering managers, how do you onboard new hires?
What are your best practices for welcoming onboard new developers?
62 comments
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.
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.
What are the kind of people your startup looks for when hiring? I would have thought that you'd be hiring experienced developers who would not need to dedicate time to learn things like Golang, and who could hit the ground running.
We hire people from different backgrounds and experience levels, from 1 to ~10 YOE. Only some require a week to get familiar with Go, but I have seen senior developers (say 6+ years) requiring time to get the hang of the language and the features. E.g., I have hired Python programmers, and the concurrency primitives, the concept of CSP, and channels are very new to them.
Go is simple, but it also has many gotchas. Knowing them also helps.
Also, when someone new has joined, the new environment could be overwhelming for them, and I'd like to ease all this and slowly induct them.
---
If you are curious, here are the Go onboarding resources (doing them in this order is preferred)
- The tour of Go - https://tour.golang.org/welcome/1
- Go concurrency exercises - https://github.com/loong/go-concurrency-exercises
- Common Go gotchas - http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
- Concurrency is not parallelism - https://vimeo.com/49718712
Go is simple, but it also has many gotchas. Knowing them also helps.
Also, when someone new has joined, the new environment could be overwhelming for them, and I'd like to ease all this and slowly induct them.
---
If you are curious, here are the Go onboarding resources (doing them in this order is preferred)
- The tour of Go - https://tour.golang.org/welcome/1
- Go concurrency exercises - https://github.com/loong/go-concurrency-exercises
- Common Go gotchas - http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
- Concurrency is not parallelism - https://vimeo.com/49718712
You honestly sound like somebody that I would like to work with. When you are next looking for developers, please contact me. My Gmail username is the same as my HN username.
Thank you for your kind words! I will be sure reach out when we are hiring.
This is great! Thank you for doing this. Never change! :)
First week is to set up tooling? If the new person does not ship their first PR the second day something is terribly wrong with your plan.
It should take 2 hours max to set up tooling.
It should take 2 hours max to set up tooling.
Lol. There's so much to unpack here that I started to suspect it's a bait. It is, right?
You're lucky if you got an access to everything you need on day 1, not to mention setup the tooling.
You can't improve the product if you don't know it yet and that takes time.
You're lucky if you got an access to everything you need on day 1, not to mention setup the tooling.
You can't improve the product if you don't know it yet and that takes time.
It is an old meme, but that said, a week to setup a dev environment is pretty ridiculous.
I try to have folks delivering business value even if very small within a week or two. I find it reduces a lot of new hire anxiety around performance if they can ship _anything_ relatively quickly.
I try to have folks delivering business value even if very small within a week or two. I find it reduces a lot of new hire anxiety around performance if they can ship _anything_ relatively quickly.
Most of the companies I worked with/for won't even have the security credentials set up in a week to have access to anything. VPN, keys etc. So not much you can do the first week accept sit with others to get tours of the codebase, frameworks, best practices etc.
You’re probably not working in startups, then. If a new developer can’t push code to production on the first day in a company of <100 people then there’s something wrong. If you’re joining a big corporate with thousands of employees and regulatory obligations then sure, a week or more for security credentials is normal, but in a startup, a week is a terrible sign of dysfunction.
Depends on the business I guess; I work mostly with companies (including startups and massive firms) in banking and gov ; there are companies with 20-30 people who cannot get people to do anything within weeks simply because of all the red tape.
I gravitate towards startups for this reason. In my experience with big orgs, everything takes forever and involves 20+ people. Often, still nothing really gets done. At startups, I or someone sitting virtually next to me is the one creating the initial integrations, accounts or credentials. Similarly, I am compelled by the MVP and the express lane it demands. I loathe red tape and process for the sake of process—and it's most evident as a new-hire, watching others scramble to onboard you, only to keep hitting corporate walls.
While I don't think as a blanket rule a new hire should push prod code on day or week one—they should be able to without being ham-stringed by needless bureaucracy that has nothing to do with security or engineering. (IMO)
While I don't think as a blanket rule a new hire should push prod code on day or week one—they should be able to without being ham-stringed by needless bureaucracy that has nothing to do with security or engineering. (IMO)
That's entirely due to the sector you're in. That 20-30 person company may be small, but it's attached to a massive external bureaucracy. They don't need to invent their own red tape, and all other companies are playing with the same handicap.
In a different sector, 20-30 people is the stage where you should be capitalizing on how much faster you can move than the large bureaucratic incumbent, and if there's red tape that takes weeks to navigate it means someone in the company put it there.
In a different sector, 20-30 people is the stage where you should be capitalizing on how much faster you can move than the large bureaucratic incumbent, and if there's red tape that takes weeks to navigate it means someone in the company put it there.
> That's entirely due to the sector you're in.
I am aware of that; I like it that way. I like long term stability and large bags of money without stress.
The capitalising and ‘faster’ and hurry and stress you speak off is nice if you want bankrupt-or-unicorn. We don’t need to be market leader or whatever; we need to have stability decade after decade and we do. I like profit of millions$/year and small teams, not some breakneck VC funded fast growing all-or-bust stuff. Each their own of course.
I am aware of that; I like it that way. I like long term stability and large bags of money without stress.
The capitalising and ‘faster’ and hurry and stress you speak off is nice if you want bankrupt-or-unicorn. We don’t need to be market leader or whatever; we need to have stability decade after decade and we do. I like profit of millions$/year and small teams, not some breakneck VC funded fast growing all-or-bust stuff. Each their own of course.
lmao right? My new hires spent the first week in corporate/domain training, then a few days getting situated, setup and stuff. Probably 2 weeks before I
"expect" a PR but even then the first few tasks are a gentle introduction.
I think the way I phrased it might not have been very clear. But many things happen in the first week, concurrently, like machine setup, product walkthrough, and a bunch of orientation sessions.
Considering the total time spent on the machine setup, it takes approximately ~2.5 days. This includes installing all the tools like Docker or IDE, setting up access to cloud environments, and VPN. Some of it is automated, and some of it is manual. It also involves installing homegrown tools, which new people won't be familiar with, and you can't find anything online.
Considering the total time spent on the machine setup, it takes approximately ~2.5 days. This includes installing all the tools like Docker or IDE, setting up access to cloud environments, and VPN. Some of it is automated, and some of it is manual. It also involves installing homegrown tools, which new people won't be familiar with, and you can't find anything online.
Many environments are complex. At a previous startup, they had a "setup" script that configured your laptop with all the tooling, dependencies, etc. It had bugs and could bomb out in the middle. Even with all the automation, it could take a day or two to get through it.
At an earlier startup, however, we expected someone to push to prod by the end of their first day. It was stressful for new and current hires alike!
At an earlier startup, however, we expected someone to push to prod by the end of their first day. It was stressful for new and current hires alike!
I highly recommend a documented walkthrough rather than a scripted setup. As you note: with a scripted setup if it breaks you're left debugging it and trying to work out what on earth it has done to your machine. I think 1-2 days of setup is entirely reasonable, but it shouldn't be taking an entire week.
Pushing to prod on your first day seems…interesting.
I can get Visual Studio and git installed in about two hours, mostly limited by network speed...
But, it's the "everything else" that takes awhile. Email filters, browser settings, bookmarks...
But, it's the "everything else" that takes awhile. Email filters, browser settings, bookmarks...
Wouldn't it be nice if that were true?
;-)
;-)
I don't understand why snailtrail is downvoted. Your ecosystem is a complete joke when it takes a week to set something up.
I will agree that I am not including tooling:
1. Set up all the tools and pull down repo. Confirm access. 2. The code should "just run" at that point.
That's why I don't welcome Docker & K8S - you are all a bunch of hype chasers. Most companies don't need it at all. If you work at FAANG, fine. If you are an ML startup that rents out GPUs from a datacenter, fine. Other than that, run it on a cloud instance and pay $5 more a month.
I will agree that I am not including tooling:
1. Set up all the tools and pull down repo. Confirm access. 2. The code should "just run" at that point.
That's why I don't welcome Docker & K8S - you are all a bunch of hype chasers. Most companies don't need it at all. If you work at FAANG, fine. If you are an ML startup that rents out GPUs from a datacenter, fine. Other than that, run it on a cloud instance and pay $5 more a month.
Because, shockingly people don’t respond well to overly generalized statements that might apply at some places but clearly not the vast majority.
Especially when those statements pretend to be gospel shared from the SWE gods.
Especially when those statements pretend to be gospel shared from the SWE gods.
If the company provides Linux laptops, Docker in your stack can be the fastest road to the code "just running". Docker on Mac and Windows can be pretty awful from what I hear, but on Linux it can be a huge time saver in getting a dev environment set up. It doesn't get much easier than "install docker, run docker compose up".
[deleted]
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.
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/
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/
The reason I don't really want to work with languages that are not statically typed is that my (very well paid) projects almost always start on day #1 with 'here is 300-500k lines of code and a list of crap it doesn't do but should, cheers!'. With C#/Java, but definitely with F#/Haskell, this is not a big issue. With Python, JS, Ruby, indeed, I need callstacking like tools or it will take a lot longer. Usually the original devs already left (often they were never employees, but contractors from big firms who peddled juniors for senior prices).
How does typing help with determining relevant code paths?
If anyone is interested in writing the PHP, Node.js or Java client implementation for Call Stacking, reach out to me so that we can chat.
You'll have a reference implementation with the Ruby client, so there will be a clear path forward in terms of what is needed functionly.
[email protected]
You'll have a reference implementation with the Ruby client, so there will be a clear path forward in terms of what is needed functionly.
[email protected]
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".
- 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.
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.
Same for us, with two things to add:
1. Make "living documentation" part of your culture, so that the new hire feels empowered to extend and improve the documentation as they are using it to come up to speed.
2. Have proper production access controls, so that the new hire can be comfortable poking around without being afraid they can break something.
1. Make "living documentation" part of your culture, so that the new hire feels empowered to extend and improve the documentation as they are using it to come up to speed.
2. Have proper production access controls, so that the new hire can be comfortable poking around without being afraid they can break something.
Absolutely. The whole broken window thing as well; if they see something wrong, anywhere, give them the power to change it. Everything should be versioned so there's no risk of them wiping old information out but also means they're in the habit of both creating and fixing from day one. Monday morning brain.
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.
Can you explain what you mean by psychological safety
I haven't thought a lot about that, but it's a great question.
Maybe:
1. Try to affect a culture of and signal "we're working together / collaborating, not competing with each other."
2. Make it clear that you're not looking for reasons to fire/punish.
3. Expect and tolerate mistakes, simple/"dumb" questions, saying "I don't know", and build support structures for learning collaboratively.
Maybe:
1. Try to affect a culture of and signal "we're working together / collaborating, not competing with each other."
2. Make it clear that you're not looking for reasons to fire/punish.
3. Expect and tolerate mistakes, simple/"dumb" questions, saying "I don't know", and build support structures for learning collaboratively.
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.
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.
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)
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)
I'm sorry, maybe I am not as competent as I thought I would be in this life. You want people to ship a brand new feature to your product on their second day?
The kind of people who can onboard and ship a feature in a 48 period turnaround aren't working for your company, they're building startups.
The kind of people who can onboard and ship a feature in a 48 period turnaround aren't working for your company, they're building startups.
I think, generally speaking there are a lot of contexts here clashing of what people mean by "feature" and "product". For some, "the product" might be a 30+ year legacy multi million loc codebase getting slowly improved, but still old and inadequate and probably full of technical debt and a lot of domain knowledge needed to navigate.
For others "the product" will be a website with a few 10k loc behind the scenes.
Getting a feature out in those two environments is not the same thing.
For others "the product" will be a website with a few 10k loc behind the scenes.
Getting a feature out in those two environments is not the same thing.
Maybe we need to define what a "Feature" is as well. I'm imagining a project that takes more than a day.
Fixing a submit button is not a feature. Perspective is weird though, adding to your point.
Fixing a submit button is not a feature. Perspective is weird though, adding to your point.
I'd say they should be shipping code of some kind in the first week.
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...
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
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 :-)
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.
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.
Updating to add the Onboarding Algorithm post I mentioned above. https://www.cybadger.com/2023/06/04/the-onboarding-algorithm...
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).
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.
I've wondered about doing something like this. How expensive is it? How often should you update the "finetune"?
> How expensive is it?
I have never done it, but how expensive would depend on the amount of documentation/code the company has.
> How often should you update the "finetune"?
No idea, but maybe once a week if there were significant changes? It doesn't have to be fully up to date since GPT is good at predicting.
I'm also not sure if fine tuning is the best way to go. A possibly better/simpler approach might be using OpenAI "embeddings" API to build a vector database that you can search and compose a chatbot prompt from questions new hires have.
I have never done it, but how expensive would depend on the amount of documentation/code the company has.
> How often should you update the "finetune"?
No idea, but maybe once a week if there were significant changes? It doesn't have to be fully up to date since GPT is good at predicting.
I'm also not sure if fine tuning is the best way to go. A possibly better/simpler approach might be using OpenAI "embeddings" API to build a vector database that you can search and compose a chatbot prompt from questions new hires have.
How are we doing this without uploading company proprietary to OpenAI to use however they want?
You can't. Though if the company uses Github to host its repositories, it is very likely they already have access to all your code through Microsoft.
Another option might be to use OpenAI embeddings API and build your own vector database, though you still have to upload company text when calling this API.
Another option might be to use OpenAI embeddings API and build your own vector database, though you still have to upload company text when calling this API.
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 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.
[deleted]
[deleted]
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...
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...