Serena partners with Karat to expand Brilliant Black Minds. Sign up for free practice interviews.
Making technical interviewing predictive, fair, and enjoyable with the Interviewing Cloud.
Learn how Karat supports leading technical recruiting processes.
Explore our best practices, research, customer stories, and more.
Our flagship purpose program, created to empower a new generation of Black software engineers.
Our mission is to make interviews fair, predictive, and enjoyable.
What developer candidates need to know about the Karat interview.
You did all this work to recruit, interview, and hire an amazing new teammate. Let’s keep this party popping! HR and IT have just completed the remote onboarding of your new engineer. Now it’s your turn. The only catch is that you and your team cannot interact with the new engineer in any way, except over the World Wide Web [dun dun duuun!].
It’s not as scary as it sounds. In 2018 I was responsible for onboarding hundreds of Karat Interview Engineers from around the world. Thanks to a particularly creative and empathetic team — plus applicable expertise in remote interviewing — we not only cut onboarding time in half but also improved both new hire happiness and overall community satisfaction. Yep, we ruthlessly tracked metrics and took feelings seriously. What were the actionable secrets to our success?
Engineering managers, I give you three things you can do to remote onboard like a boss:
Being explicit is crucial for interviewers and candidates to know how to succeed. Karat Interview Engineers come to interviews prepared with detailed question guides and assessment rubrics while candidates are informed of the agenda and objectives before the interview even begins.
Being explicit is just as crucial for speedy and enjoyable onboarding experiences, especially for remote teammates. Someone sitting alone at home won’t happen to run into the product manager while making coffee and learn about the upcoming roadmap and Q3 business goals. Nor will they happen to sit next to the staff engineer at lunch and learn about that authentication refactor impacting the codebase. All of that learning and relationship building that is critical for new hires to get up to speed, and that casually bombards us in an open office, is missing from the hermetic isolation of working remotely.
The best way to handle this problem is by making an onboarding schedule with explicit meetings. Here are some that I find useful:
Meet-and-greets with specific cross-functional or cross-team colleagues. This clarifies who does what, and makes it easier to reach out with questions or answers informally in the future.
Remote onboarding twist: Join the beginnings of the meetings yourself to do introductions, set the context, and then check-in with the new hire during long gaps in the schedule. Leave extra room for bio breaks, and keep in mind that working remotely is extra hard on the body and mind without explicit encouragement (and time!) to get up and move around.
Technical meetings, especially around architecture, data models, data flow, and user experience principles. An approach that utilizes both documentation and discussion is best.
Remote onboarding twist: Find ways to reproduce a whiteboard. You can go the analog route of taping paper to the wall, buying a small whiteboard, or the digital route of buying a tablet and pen for drawing online.
Process conversations, where someone explains our specific git workflow, and the cultural rules around our version of continuous deployment. This could be a formal meeting, or it could be a pair programming session for the new hire’s first feature or bug fix.
Remote onboarding twist: Give the new hire a “Reverse Code Review.” This is when a senior engineer reviews their own code in front of the new hire. It’s a great way to explain code review best practices and culture in a non-threatening, comfortable way, including what kinds of things to look for in the code and when leaving comments.
Replacing intimidating interviews with inclusionary interviews — as in encouraging and enjoyable — is critical for enabling candidates to do their best. Even great engineers can get stressed and confused during interviews. A little encouragement, especially for candidates who are new to interviewing or haven’t seen many successful engineers who look like them, can prevent minor misunderstandings from turning into expensive missed opportunities.
An onboarding process that quickly turns “The new hire? Shrug” into “That’s our teammate, Lus! They’re great!” is much more likely to result in a productive employee and a high-performing team.
Of course, relationship building and team cohesion are tightly linked to proximity. How can we get our teams to gel when remote hires receive so few social signals, not even a friendly wave in the morning and a smile at the tea station? Sitting invisibly at home, it’s even easier to forget to explain that in-joke on Slack or forget to invite the new hire to that spur-of-the-moment design discussion.
My solution is to go above and beyond making the new hire feel at home. Here’s what I do to make it easy on myself:
Create a team calendar with all of our team meetings, including planning, standup, retrospective, and one-off design conversations. Anyone on the team can create and manage these events. When someone changes teams, we don’t have to recreate “their” meetings. When someone joins the team, they can easily access the calendar themselves and ensure they get the invites.
Remote onboarding twist: add your team calendar as a Slack integration, so everyone gets the reminder and a convenient link to join.
Hold regular staff meetings. In engineering, we often split these functions across planning meetings, retrospectives and team activities. Staff meetings are a time for the team as a singular whole to define itself, make team decisions, build and repair trust, and more.
Remote twist: Because it’s easy to be all business on Zoom and miss out on socialization, I start one weekly meeting with a fun whip-around question. Each week, we rotate who brings a question for everyone to answer. Something like: What did you eat for dinner last night? If you could instantly learn one new personal skill, what would it be? What is your most-used emoji? Here’s a big list if you’re on the spot and drawing a blank.
Throw a few non-meeting meetings into the onboarding mix. It’s common to assign new hires a buddy, someone who the new hire has explicit permission to bug with “silly” questions. On the flip side, the buddy has explicit permission to be outgoing, explain those slack jokes, and check that the new hire’s dev environment is working as expected.
Remote onboarding twist: Make it clear that the new hire and their buddy should make space and time to casually chat. They can use private DMs away from the intimidating mile-a-minute team channel, or create co-working Zooms after lunch to make it easier to ask little questions while working on different things.
The beginnings and ends of interviews are the most vulnerable times for candidates. This is when candidates look to interviewers to provide guidance when they’re confused, and feedback after they’ve poured out their hopes and dreams.
Onboarding is a vulnerable time, too. New hires know so little, and want to prove so much! In some ways, onboarding is a time of grace, where you can get away with asking someone to repeat their name again, or help you with an inexplicable Docker error. Eventually, though, onboarding gives way to a not-new employee receiving a not-new performance review.
The first law of middle management is to avoid surprises, especially in performance reviews. That’s why we set expectations at the start of the review period, and check-in with reports incrementally.
In onboarding, incrementality takes on a second dimension: starting small, with easily verifiable fundamentals, growing step by step until the new hire is unsurprisingly making the breadth and depth of contributions that we originally predicted during interviews.
When it comes to onboarding, I recommend starting with that initial onboarding schedule: “here’s what your first two days look like.” Then set goals for the first two weeks, two months, and the next performance review (about 6-9 months out).
A senior engineer might quickly catch on to completing backlog items and is soon picking up the hardest stories, leading new projects, and mentoring interns. An early career engineer might work through these milestones more intentionally, celebrating their hard-earned backlog deliveries one-by-one, each contribution a meaningful demonstration of their widening and deepening skills.
Of course, the point of incremental milestones is to know when someone is going too slowly or veering off track. That way you have time to give feedback and adjust your guidance before your team misses important long-term milestones.
Remote onboarding twist: Difficult conversations don’t become less difficult when they’re remote; if anything, they’re easier to shy away from. However, you can make sure to have regular 1:1s scheduled. I don’t mind turning some 1on1’s into walking phone-calls, but for onboarding 1on1’s and especially for difficult conversations, I like to stick to my home office as a symbol (and reality) of giving my full attention.
The second advantage of remote meetings is that every conversation happens at our computers, with access to shared documents. I like keeping a shared spreadsheet of our weekly check-ins: what can we celebrate from last week, and what am I expecting to see next week. I even put a “notes to take note of” section on there. It’s win-win: either it is blank and my report explicitly knows they’re doing fine, or there is something kind but important written there, which I want to make sure we talk about together.
* * *
Who you hire is intimately connected to how you onboard. Thus it’s no surprise that best practices for one might inform tips for the other. I hope you found these three remote onboarding tips helpful. And if you have tips of your own to share, please leave a comment or tag us on social media to keep the knowledge flowing!
Your email address will not be published. Required fields are marked *