HN Explorer

Ask HN: How do you make sure you have a successful onboarding for SWE

12 points by wreath ↗ HN
I recently resigned from my position as a (mid-level) software engineer at a product company and I will be joining another product company in the next two months. At the same time, at my current company we are expecting three other (mid to senior level) engineers to start before I leave and I will be helping them with the onboarding.

So I am wondering what are the best approaches to have a successful onboarding/start both from an employee and company perspective. Can you share your experience/tips/anything really!

Cheers

12 comments

[ 0.22 ms ] story [ 41.3 ms ] thread
meric
I suppose if their job description has changed since their application process make sure they know what their new role is by writing, instead of hoping he'll pick it up from social cues.
twunde
Does this happen often in your experience? Can you elaborate on what seems like a personal experience?
meric
It happened once.

I applied for jobs to build API's, and got into this company that wants to get some API's done. First week in, the project to build the API platform was deprioritised and placed on the back burner. Then in the sprint meetings they're trying to find some python work for me to do. Two months later I'm shuffled to another team to work on the enterprise planning platform. In this role I'm supposed to communicate to all stakeholders and help them get information easily to make decisions. I'm in a "flat" team of 3 reporting to an executive. Half a year in, I did not pass probation because my communication skills to gather and implement a consensus of all company leaders is insufficient as well as my ability to working in a team where expectations are implicit (no roles assigned) are deficient, especially because I'm still trying to stick to my original job description.

I probably should have started looking for another role three weeks in. But I did not have the judgement at the time.

partisan
I'm a big fan of "each one teach one". When we brought on new team members, we had the last arrival show the newest employee the ropes from setting up a workstation and accounts to identifying the right resources when help is needed. If time is short, then you may not choose to take that approach, but you would be leaving them in better hands if you allowed them to work through some of the core issues and answered whatever questions they may have.
romanhn
Every new hire is assigned a "coach" on their team, another engineer. We have a formalized onboarding plan with first day, first week, first month expectations outlined for both (set up such and such software, get these repos running, teach/learn about the product/architecture/tooling, do a deploy + rollback, etc etc). The coach picks up the easier tasks and pairs with the new person. It's important that these are not throwaway tasks but actually contribute to current team goals - that way the new hire is properly part of their new team and absorbs relevant team conversations through osmosis.

This works fantastically. It's a bit overwhelming at first, but results in a functioning, contributing team member in a very short period of time. New hires are expected to push code to production within first week (often happens within first couple of days). There obviously needs to be a lot of cultural support for this. It certainly helps that we have a solid culture of pairing, so all of this is quite natural.

You'd have to modify this a bit if you're the only coach to three new hires. At a high level though, the approach is - have a plan, have a helper, pair on relevant tasks, rinse and repeat until both are comfortable.

codeonfire
As someone who recently quit a new job soon after starting (my choice) you need to make sure your current employees are not dicks or they are managed. There are people out there whose dickness far exceeds their background and capabilities. Pair them with an equally bad manager who doesn't see the big picture and you have a couple of low end c players making thing shitty enough that no one will want to enter the company. It's sad because the company was a very exciting place to work. It is like seeing someone who put a four cylinder in a Ferrari.
twunde
Always remember that the goal of onboarding is to get the new hire working effectively as soon as possible. Some practical tips to abolish this:

1)Make sure they have a computer and access to all the systems they need by the morning of the first day. If you offer a choice of equipment, email the hire before they start do you can purchase the equipment in a timely manner. Bonus points if you can preconfigure the computer using a MDM solution. Have instructions on how to set up their computer. This should invite setting up their dev environment, db connections, running tests etc.

2)Pick out a simple bug or feature for the new hire to work on the 1st day. They should be able to finish it that day. Hopefully they should be able to deploy that day.

3) Give a product/domain knowledge demo. This should include any domain knowledge necessary.

4) Print out architecture and database diagrams. Plan out time to review the product architecture.

5) schedule 1:1s with the rest of your team as well as other important people they should know. My current team had new his grab coffee outside the office for this.

6) Assign a dedicated mentor, besides the boss.

le-mark
If they're senior they shouldn't require any on boardinag other than dev environment set up and account set up for ci, ticketing, etc.
afarrell
Note in interpreting this: If someone graduated from uni less than 3 years ago, then they might not be senior even if the recruiter who called you about them said they were. They almost certainly need onboarding. At the very least, a project that they should start working on. If you want them to come up with their own project, at least intro them to the current strategic goals of the company and whom to talk to find and prioritize pain points. But your best bet is to give them onboarding and at least a first project.

Folks with 7+ years experience: Is it true that you don't need an onboarding besides getting shown your machine and accounts? What is your approach to finding a project and deciding that it is what you should actually work on? Do you approach it as if you are basically a startup within the company?

marktangotango
Generally when you're "truly" senior, it's pretty trivial to come in and start working tickets ie bugs and features so long as it's the tech stack you're used too. You've seen most of the bugs before, and implemented a lot of the same stuff (dashboard? KPI's? yawn). If it's a different stack, then sure there's some ramp up, but weeks not months. Like if I went from 15 years of java to .net, I'd be uncomfortable for a while, but basics are the same; version control, IDE's, building, deploying, etc. It's just a matter of learning the particulars.

So far as projects to work on, generally managers and project/product owners have a back log of stuff they want done; some feature or other. Or maybe there's some crippling technical debt that needs to be resolved (example I saw recently; using ant for building deploying, and needing to move to maven).

>> If you want them to come up with their own project, at least intro them to the current strategic goals of the company and whom to talk to find and prioritize pain points.

Rereading; this is a bizarre statement. If I encountered a situation like this, I'd start looking immediately. This is a strong signal the org has no clue what they're doing ie leadership is incompetent.

seanwilson
One tip I would give is get new employees to document what would make things easier for the next person in their position. When you're trying to contribute to existing projects starting from scratch, that's when you really find out what libraries, commands etc. are missing from the documentation.
brad0
Get them to understand why the architecture does the things it does. If they can tell you why you used technology x or design pattern y then you've had a good onboarding.