
Ask HN: How do you onboard remote employees? - avinium
I&#x27;m starting to think about future recruitment for my (still small) company, as well as possible future product ideas.<p>For those of you who are 100% remote, I&#x27;d be interested to hear what your onboarding process looks like.<p>I&#x27;m aware of platforms like CodePair &#x2F; etc for the recruitment process, but I&#x27;m more interested  in hearing about best practice for signing up a a new employee (i.e. offer&#x2F;contract&#x2F;pension&#x2F;payroll&#x2F;etc), onboarding (creating e-mail&#x2F;accounts&#x2F;keys&#x2F;etc) then getting them performing at 100% as quickly as possible (getting familiar with features&#x2F;codebase&#x2F;customers&#x2F;etc).<p>So far I&#x27;ve done most of this all manually, which is fine when someone is sitting next to me (though sub-optimal). I don&#x27;t think that&#x27;s going to fly for a remote employee.
======
angelmass
I just started my 100% remote dev job last week. It’s been pretty interesting.

My laptop and some earbuds were shipped to me. They arrived my first day. I
had emailed my manager beforehand to let her know that I would probably be
missing any morning meetings I might be scheduled for, as I didn’t know when
in the day it would arrive. The expectation was just that I had a functional
computer the first day, so that made the process pretty relaxing. I really
only verbally talked to one person (my buddy) for ~30 mins on my first day.

As far as setup goes, there was a stack of stapled paper (~6 large print
pages) indicating how to log in (I was verbally provided a password, but
that’s as far as the verbal walkthrough went) and perform basic setup -
installation and authentication to VPN (globalprotect), security/management
software (DUO), video software (Vidyo), Slack, and urls for further
references/setup (confluence, extended setup documentation via Google Docs, HR
sites, benefits sites, etc). The setup was pretty straightforward, so in
reality I spent most of the day configuring alacritty, tmux, vscode and
documenting that for my own personal use next time I have to do this. However,
this was mostly done while waiting for various people/teams to provide me
access to the resources I’d need to do dev work specifically, like source
control, and CI/CD, and all the associated necessary environments.

My company starts new devs on 2 6-week rotations to begin with, so I asked my
current team’s tech lead for arch diagrams, and _up to date_ docs on general
things like story lifecycle, responsibilities of various people within the
team, their git process, the team’s definition of done, valid contract
definitions, and relationships/interactions with other teams. Once I got
access to the codebase, I went through the local env setup, and my first PR
was changes to the README based on that process. I generally try to take as
best notes as I can to improve the process for the next person (also selfishly
to save me time troubleshooting in the future).

On my 2nd or 3rd day, I scheduled 4 meetings:

* one with a tenured backend dev in a room with a whiteboard to go over architecture review

* one with a sr frontend dev to go over inconsistencies within the codebase and where to look for the current best practices

* one with a stakeholder to go over how they communicate requirements for the app, both initially and throughout the dev cycle, and any follow up stuff for after dev work is done

* one with QA to go through their process (also revealed some more things I needed to request access to) what the interaction is with devs, and where their responsibilities lie within the story lifecycle

Also it’s perhaps worth mentioning that I also prioritized asking the devs
about how to test the codebase thoroughly. Not only is it how I like to
explore a codebase initially, it also provides a good framework for what level
of test coverage is expected, and what is required to be able to run them (ie.
VPN, docker/AWS login, various states of local and remote servers running, any
local config changes that make dev’s life easier that might not be explicit in
any docs).

It’s been very DIY tbh, and it’s been really nice. The documentation is 98%
accurate and up to date, which has been amazing. My only real complaint is
that here have been quite a few coincidental business-wise meetings in my
first week, and I don’t have context for anything at all. Being in a video
call with 200+ other people doesn’t lend itself well to asking questions, and
it gets aggravating to ask “what is X?” “What is Y?” continuously. It’s
something that’s much better done in person.

