Planet4iT Blog

rss

Providing you with information on the IT and Digital marketplace.

Working at the World’s Largest Remote Company: Hiring, Onboarding, Day 1 and Going Forward.

 

Many of our clients and candidates are struggling with a forced adoption of remote work. We thought it would be a good idea to speak with a friend of ours, Hordur Freyr Yngvason, who works at the world's largest all-remote company Gitlab, on everything from hiring to onboarding, day 1, water cooler chats and working in an all remote environment. If you are interested in receiving more content like this in the future please subscribe here. Without further ado, let's see what he had to say.

Please provide a brief introduction of who you are, what you do, and GitLab.

I’m Hordur Freyr Yngvason, a Backend Engineer at GitLab. We are the world’s largest all-remote company. GitLab aims to solve the entire DevOps lifecycle. Our core offering is git-based code hosting with integrated merge requests, issue tracking and CI/CD. GitLab is open-core (the core is open source, but we also have paid solutions), and comes both as SaaS and as an on-premise solution. I’ve been here since June 2019, working on a team responsible for GitLab’s Kubernetes integration and parts of our Auto DevOps solution. Before joining GitLab, I was a Backend Engineer at Booking.com.

Interviewing

We are told that a lot of communication is non-verbal. When you don't have in person capability how can a manager properly assess this during the interview process? Is video interviewing the same as in person?

I’m not involved in the hiring process at GitLab, but I suggest having a look at our handbook page on interviewing.

 

For a remote position, I think remote interviewing should suffice. The way we interview reflects the way we work. So in order to understand our hiring process, you should also understand our communication guidelines.

 

Are there any additional authentication, security measures taken by the potential employer during remote interviews to ensure the candidate is who they say they are?

Yes, there is both a background check and a reference check.

Offer Acceptance

Interviewing can also serve as an important part of helping candidates evaluate offers in that they get to meet their future boss, team, coworkers and can see the work environment. In your experience how different was the offer acceptance decision making when it came from a company who is entirely remote?

Absolutely. And we also give the candidates the chance to do this at GitLab. Typically, you interview for a specific position and that team’s manager will be one of the interviewers.

 

This is also where our handbook and openness helps: Every candidate can read the handbook, on which all decisions are based. And almost all our work is public: Take a look at https://gitlab.com/gitlab-org/gitlab: You can see everything! Candidates can use this to research their prospective team’s work.

 

Finally, we do offer chances for the team to meet up. For example, the whole company gets together every 9 months. We also encourage local meetups, and have a visiting grant to encourage people to participate in local meetups when traveling (though this has been temporarily suspended due to COVID-19).

 

Many people are already remote only, do you find that there are any particular challenges in convincing people that haven't worked remotely to accept an offer?

I can only speak for myself, but a big reason I applied at GitLab in the first place was because it’s remote. I do, however, remember a variation of this question being brought up by all of my interviewers: “How do you feel about working remotely?” So they certainly made sure I knew what I was getting into well before it came to the offer stage.

Onboarding

Okay, the candidate has accepted the offer and is ready to get started. How do you handle secure equipment, do you have a dedicated remote onboarding team?

Candidates on-board with the team that hired them. On your first day at GitLab, you get a huge on-boarding issue assigned to you (see also our handbook page). Last I heard, it included a checklist of over 200 items and is expected to take up your first week or two on the job. No other work is expected in the meantime.

 

Equipment procurement depends on the country (see our laptop ordering process). In some countries, candidates will receive a laptop from GitLab directly, in other situations they will have to purchase the laptop themselves and expense it.

 

When it comes to securing the equipment, GitLab is implementing a zero trust policy. And part of each employee’s on-boarding issue is familiarizing themselves with our security practices and securing their equipment.

 

Onboarding for some of our Enterprise clients can take a couple weeks, is there an advantage to all remote in that it lets you get the new worker started faster?

I do not think there is a direct advantage to all-remote here. There is, however, a huge advantage in having the handbook as a reference for all company processes, and using a tool like GitLab for all our work. When I have a question about a company process, I search the handbook. When I have a question about why something was built in a particular way, I can refer to the history of work done on GitLab. I really can’t overstate the importance of working handbook-first.

Introductions to the Team

Day 1's seem to be pretty standard for in person roles. Come in, see your workspace, meet the team, get setup for day 2. What does day 1 look like for an all remote worker?

Day 1: Hopefully, your laptop will have arrived. You start configuring your computer, setting up the necessary software and accounts. Once you’re online, you start working through your on-boarding issue. This will take up the majority of your time for the next week or two. You join the company Slack and introduce yourself asynchronously to the team.

 

In the days that follow, you will meet your on-boarding buddy, join the company call, go through a variety of trainings and spend a lot of time reading the handbook.

 

I could see non-remote workers struggling with the concept of who to ask the easy questions, in a workplace you can just turn to the person next to you and don't have to bother your manager for everything. How does GitLab's remote workplace enable workers to communicate with each other easily?

Your on-boarding buddy is there to answer any questions you have and are not comfortable asking in public. But as people grow into their role, we prefer that they ask questions in a public Slack channel for everyone’s benefit. Every team has their own channel, so you can go straight to the domain experts if you know the right channel, or just ask on #questions and someone will try to help. Asking on #questions is always appropriate.

Going Forward

What were some of the challenges you faced in your first few weeks? What kind of support systems are in place?

There is a lot of information to process. Everyone feels it, and it is completely normal. Your on-boarding buddy, your manager and your team are all there for you to rely on. Over time, the nature of the information changes away from learning company processes to work-related notifications, but there will always be a lot of information to process. A big part of getting good at the job is learning what is relevant to you at any given time and where to spend your time.

 

Does anything change in terms of judging performance? Does it become more results based or is effort still measured?

The performance evaluation process felt very similar to what it was like at my last job: I made a case for my performance according to a framework, then my manager made theirs, and then we had a meeting to resolve any differences. The key difference I found was that since most significant work happens on GitLab, it was very easy to go back and find examples to support the evaluation.

 

Is there a need for additional structure (ie- more scheduled meetings) since there aren't any impromptu "water cooler" type discussions?

Slack (or equivalent) is actually a great place to start such discussions. They occur all the time. If an idea gains traction, then it gets quickly moved into an issue or a merge request for further discussion. We also have regular team meetings, and any team member can bring any topic, but the diverse audience makes them less suitable for e.g. intensely technical discussions.

 

Software Development under the agile methodology is a highly collaborative process... can this be done as effectively in an all remote environment?

I believe so. I’m a big advocate of remote work and really hope it catches on.

 

Previously you worked at Booking.com in Amsterdam in a more traditional set up... what do you think is better about 100% remote work, and what doesn't work as well?

 

The key benefit for me has been the personal freedom and flexibility. I have close family in Iceland, Switzerland and Canada and being able to work from anywhere, and structure my day how I want, has made a big difference.

 

Booking.com also had open-plan offices, which I am not a big fan of. To be fair, their offices did improve a lot while I was there, but I still prefer the comfort and privacy of a home office.

 

The main downside has been the risk of social isolation and the feeling of stagnation when I forget to leave the house. You need to make an extra effort to socialize (you can do this remotely!). And I’ve found intense exercise, daylight and fresh air to do wonders for that cabin fever.

 

Booking.com also had amazing catered lunches and fancy cafes in every office. I miss those.

 



Showing No comment