How I joined GitLab and went from nothing to a Backend Developer

7 min readDec 22, 2017

Edit Aug 5th, 2018:

I gave a talk about this topic in one of local meetups.

Here is the link https://www.youtube.com/watch?v=DUVHC4K4I-E. This is more comprehensive and fun than reading through the below.

—

I’ve been working for GitLab for 6 months. I started my career as an Intern Backend Developer on the CI/CD team and recently I was promoted to Junior Developer. My salary is 2x better than it was at my previous company. And I’m very happy that I’m surrounded by awesome and quirky developers.

As I described in this blog title, applying for this job was challenging as I started from a level of almost nothing. Here was my situation before I decided to go for a job at GitLab.

I had never worked as a Web Developer
I had never worked in an English-speaking Company
I had never worked remotely
I had never contributed to open source projects
I didn’t know DevOps and CI/CD (Continuous Integration/Continuous Delivery)
I had never written tests for application code
I had no one to ask about web development
I had been working on Windows native apps (C#.NET) for 6 years
I had 3 months experience in Ruby on Rails
I could read/write at an intermediate level inEnglish

What would you say if I told you I had applied for a job at GitLab without telling you what happened? I remember when I applied for this job, GitLab was receiving about 100 applications per week. I thought that the hundreds of applicants for that position were far better than me.

Let’s see what I have been up to since I decided to go for a job at GitLab. This was one of the most exciting and crazy journeys of my developer life.

January 22nd, 2017

I decided only to apply to GitLab. I won’t elaborate the reason here though, I just really wanted to join this company. ENGLISH? Cool! Remote-only? Interesting! Transparency?! I like it!

I quit my job at my previous company to fully focus on my goal.

I thought I would need at 6 months to be minimally qualified for the job. So I decided — If I couldn’t join the company within 6 months, this challenge would be a failure. So July 22nd was the deadline. I had very little money — only enough to survive for 2 months, so I borrowed money for the other 4 months.

First, I needed to know a couple of things. For example,

What is GitLab?
Where were they come from? Where are they going?
What does GitLab want? Why are they hiring?
Why are people using GitLab over GitHub and BitBucket?
How are current employees working? What does GitLab expect from them?
How can I profit this organization?

I spent the first month on only that research. Those questions were very important for moving forward, especially for making sure I was on the right track to the goal.

To address the question “How are current employees working?”, I created a bot to track The Atom feeds of developers on the CI/CD team . So I was able to learn useful information, for example, their active working hours, what they were interested in, what their problems were, etc. I swear that I am not a stalker XD. But with that information, I could decide what issues I should tackle. Because tackling something they were not interested in would be meaningless.

Personally, I felt the last question “How could I profit this organization?” was the most important one. I would be paid after I joined the company so I felt I needed to contribute more to the company than what I would receive in return. In other words, my Merge(Pull) Requests needed to make a profit. It needed to be more than merely developer-satisfaction, like “This code looks better/shorter”.

To prevent burnout, I always set a timer when I was working. Every day, I worked for 50 minutes x 10times = 500 minutes. After each timer rang, I took a 10-minute break — just 8 hours and 20 minutes, no more, no less.

February, 2017

I decided to start contributing to the GitLab CE project. Because I read on a page that they hired from their contributors. I was bored with researching, so I was glad that I finally was able to start coding!

I tackled only easy issues that month. More precisely, issues labeled as “Accepting Merge Requests” and “CI”. “Accepting Merge Requests” means something easy to grab for beginners, such as refactoring, revising documents, etc. My plan was to warm up with only easy issues the first month, and then challenge myself with technical issues the next month. Here are the some of issues I actually tackled. Issue1 Issue2

Also, I drew a lot of diagrams to understand the codebase deeply. This is a good place to sort out complicated logic.

March, 2017

This month, I challenged myself with more technical issues. After I spent time on finding a relevant issue, I found a significant one — The Pipeline Schedule. This issue was upvoted by about 100 users, and clearly it’s an in-demand feature in GitLab CI.

But things were not that easy. I needed to follow the right processes to finish this properly. First of all, I sorted out the current implementation and summarized the MVP (Minimum Viable Product). You can check the report here. This issue was being discussed by a lot of users and therefore there were no clear paths to the goal at that moment. To go forward, I needed to convince all the community members that my plan would work.

After the specification/proposal was fixed, finally I started working on the merge request. It took a very long time to get it done.

April, 2017

My biggest MR was finally merged!

Since this feature was very complicated, we(me and other contributors) needed some follow-up MRs. I was also involved with that stuff. It was shipped in GitLab 9.1.

Meanwhile, I was working on other complicated issues such as Group-level secret variables. Around that time, I was comfortable working with them and web development. I could easily spot bugs and make patches.

May, 2017

I got an Job offer e-mail from from the CI/CD team. Finally, I started my application process. I had 3 interviews in that month. Each interview was conducted with a different person. In my case, the first was the CI/CD lead, second was the Head of Product, and lastly was the VP of Engineering.

Honestly, I am not good at advertising myself in interviews. Every time, interviewers show me a frowny face with awkward silence. My thoughts always get tangled while I’m speaking and I can not find a way out.

I was so nervous every day. And as I assumed, my performance was awful. But I had confidence that there was a chance, because I had contributed a lot up to that point . In other words, I was advertising myself without speaking a single word.

After a couple of weeks, I got an e-mail from recruiter. I passed! Yay!

June, 2017

From June 12th, I started working at GitLab. I introduced myself to my team mates. My assumption was almost correct that it took nearly a half year to get hired.

… Well, it was not a fresh start because I already knew them and so did they.

After the story

As of September 14th, I have been promoted to Junior Developer. My salary has been raised 150%.

Oct 19th, I joined the GitLab Summit in Crete. I had been dreaming of attending a summit since I started contributing. Last January, it was just a dream, and it became real afterwards.

Before you go

GitLab is hiring. I proved a-nothing-guy can get a job. That means most of you have a chance.

Thank you for reading!