
Ask HN: How do you make sure you have a successful onboarding for SWE - wreath
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.<p>So I am wondering what are the best approaches to have a successful onboarding&#x2F;start both from an employee and company perspective. Can you share your experience&#x2F;tips&#x2F;anything really!<p>Cheers
======
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.

------
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.

------
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.

------
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.

------
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.

------
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.

------
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.

------
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.

