Hacker News Reader

Comment by sytse | Hacker News Reader

GitLab the company exists because of HN https://news.ycombinator.com/item?id=4428278

Ask me anything.

What's your policy on employees' side projects? Let's say I want to work on a side project and one day hope to turn it into a business (and get into YC), do you allow me to retain intellectual property for the side project which is of course unrelated to my gitlab work?

You have to declare the project and get permission to ensure it doesn't conflict with GitLab.

I don't recall us ever denying permission.

I can't find the handbook link right now.

I am interested in working at Gitlab as a software engineer and will be applying approximately 6 months from now. Do you have specific suggestions on how I can improve my chances of landing a position? I had the following in mind :

- Start contributing non-trivial patches to the community edition

- showcase my skills through side projects which will be rails webapps

- brush up on my CS fundamentals for the interview

From the outside, the bar seems quite high, I remember coming across a tweet mentioning 20,000 applications over the past few months. Any other suggestions on how I can improve my chances? And how long does the hiring process take from my application to accepted/rejected? Thanks.

I think contributing to GitLab itself would send the strongest signal of the three things mentioned.

Please note that this isn't required, we hire a lot of people who never contributed to GitLab before getting hired.

I've asked our recruiters to comment as well.

I am one of the recruiting managers here at GitLab. I would agree with @sytse that contributing to GitLab would be the strongest signal.

While we do keep the bar quite high from a technical perspective, we also do so as it relates to our values. https://about.gitlab.com/handbook/values/ With us going through this current hyper-growth phase we have to make sure that everyone who comes into GitLab aligns with these.

For Engineering hires in the month of June we averaged ~65 days to move someone all the way through the interview process.

I am more than willing to set up some time to chat with you 1:1 if you have any more questions.

I am interested in working in GitLab.

Do you have some foreign engineers staying in Japan? I want to stay in japan with proper visa if necessary.

As far as I recall from their website. Japan is one of the countries they do not hire in due to what I presume to be legal reasons.

You can look for that info on https://about.gitlab.com/company/team/ As far as I can see there is 1 GitLab employee currently working from Japan.

> I am more than willing to set up some time to chat with you 1:1 if you have any more questions.

That's very kind of you to offer! Can I send over a few questions over email closer to the time I'll be applying? I don't see an email address in your profile, can you post your email id here? Thanks.

Hi, I live in Japan and I'm very interested in applying for a job at GitLab. It says on your website that you aren't currently hiring in Japan. Is the situation likely to change in the future? I found this link circulating on Twitter: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... Does this mean that there will be 1-3 positions available in the near future? What can I do not to miss them?

Thanks for your time!

I was in the team where we decided what to use to serve git repos + to do peer reviews for a big German car manufacturer. We decided on GitLab because it had a normal fork-workflow but was open source and we wanted to divert some of the money into one of the open source projects. Now we have around 600 users in that project.

Most of the things work great but we have the problem that we want to use Jenkins instead of the build in CI/CD solution but the only way to trigger MR jobs from GitLab forks in Jenkins is this non maintained plugin which has been in alpha since we started two years ago https://github.com/Argelbargel/gitlab-branch-source-plugin

So I wonder, what is the reason behind not investing into integrations with other CI systems like Jenkins which are hugely popular and used by so many people?

We are investing continually to have integrations with tools such as Jenkins, GitHub, and JIRA.

I'm not sure why https://docs.gitlab.com/ee/integration/jenkins.html apparently doesn't support forks and our CI people to comment here.

In the meantime before someone from CI jumps in, here's the issue that has some more information relevant to your question: https://gitlab.com/gitlab-org/gitlab-ce/issues/58301

Why would you want to use Jenkins? Genuinely curious.

Jenkins has been nothing short of the devil for me.

Mostly historical reasons.

Hey there, PM for CI/CD here. Can you point me to an issue in either GitLab or the Jenkins Plugin repo that has more info specifically on what you're looking to do that isn't possible today? Or share specifically what you need here so I can make one? That other project seems to have a few different features and I'm not sure which use cases exactly are important for you.

In any case, we definitely want to make sure you have the right functionalities you need.

Basically what we need is functionality which makes it possible to do:

- there is a canonical git repo for a component

- a dev doesn't have write access to it

- they fork it into their own private user name space

- they change it and create a merge request for the canonical git repo for one of the branches

- the merge request creates (or triggers) a job in Jenkins => this is where our research showed that only the unmaintained gitlab-branch-source-plugin plugin can do that https://github.com/Argelbargel/gitlab-branch-source-plugin

- Jenkins builds it and reports the status back to GitLab

- If it created a new job that job is removed after the MR gets merged.

It would be nice if, like the other plugin does it one could have it's own job for this MR with it's own history but I guess we could live also with a shared history if you could have the MR buld history in GitLab only.

update: I forgot to write that we use Jenkinsfile based pipelines, not sure if this is important.

Thanks for the super clear description! Doing some internal research on this.

I've created https://gitlab.com/gitlab-org/gitlab-ce/issues/64995 - please join us in the conversation there.

I'm interested in learning more about car manufacturer and software - wondering if you'd be open for some questions?

I've interviewed with GitLab when I first changed my career into software engineering, a few years ago. It was a bad call in my opinion since I'm not as good as I thought back then.

However, is it a good idea to apply again since that was a long while ago and I've accumulated a considerable amount of experience compared to what I was?

And can you do your own independent security research when you're working for GitLab? What's GitLab's stance of this situation?

It'll be nice if you can post your/a recruiter's email ID here - I'd like to send over a couple more questions.

Thank you for your post and questions. We would welcome you to apply for a role at GitLab that looks interesting to you. Our guideline for security researchers is that if you are a GitLab employee, you would not be eligible for a bounty award through our public bug bounty program. Other than that, independent security research is fine, as long as it does not call out our customers in a negative manner. Here is our hiring page: https://about.gitlab.com/jobs/faq/

I see that Gitlab does not currently hire in some locations (e.g. France, Italy or Spain).

Is it because of local laws or other reasons ?

Local law is the most common reasons although there is also non-local law such as US sanctions and other reasons.

For a complete list see https://about.gitlab.com/jobs/faq/#country-hiring-guidelines

How come you're not able to hire in some countries in the EU? Sweden, Italy, Spain, and France are on the blacklist.

A Spanish citizen can work for a company registered in any other EU country without any problems.

There are 28 States operating their own legal systems in the EU and each is free to pass (and does pass!) its own employment and business related legislation albeit within some boundaries of EU law. While I can’t answer this question, it’s not that big of a shock there might be legal issues.

The EU’s “Freedom of Movement” alone does not guarantee a business a right to employ individuals in all 28 States, even if it does greatly help in removing some barriers and permits you as an EU citizen to work In any of them. Any of these states can place additional legal burdens on Gitlab as the employer that it may not be able to meet in its current form, which is presumably what has happened.

This probably has to do with local regulations. For example (this might be part of our reasons to hire there) in Spain all employees now have to clock in and out https://elpais.com/elpais/2019/05/13/inenglish/1557739540_96...

Have you ever had to deal with employees that "work remotely" but don't get a lot done (perhaps because they're spending all day on HN)? How do you detect that & deal with it?

Why would it be any different than someone in the office that didn't get a lot done?

Identifying and taking action on underperformance is essential to running a great company and we have a lot of information on how we do this on https://about.gitlab.com/handbook/underperformance/

I don't think that working remotely is the main cause of this. There are people underperforming in many companies who work on-site.

I'll be the last person to say something about spending a lot of time on HN since I do so myself. In general we don't want to talk about how you spend your time but about your output. We measure results and not hours https://about.gitlab.com/handbook/values/#measure-results-no...

How do you detect when someone doesn't get a lot done that doesn't work remotely?

Do you plan to switch from Ruby to some more performant language (e.g. C++17 onwards, Rust or Go)?

We tend to remake performance sensitive parts in Go.

GitLab consists of more than 30 services in multiple programming languages https://docs.gitlab.com/ee/development/architecture.html#com...

The backend engineer position lists ruby experience as a Strict Requirement. The linked explanation makes sense when trying for fast growth. However, the text is about 3 years old now so my question is: Do you expect this policy to change in the near future?

I don't. We had a few hires new to Ruby and I think it took them much longer to get up to speed and more of them never got up to full speed.

Are you guys planning on ever removing the "location factor" from your compensation calculations? That's the only thing that's preventing me from applying - apparently I'm only worth 0.4x as much as a "SF Benchmark" developer to you guys right now, because I choose to live in a cheaper part of the world.

The best response to this that I can give is a link to our blog post about this, where we break down why we pay local rates:https://about.gitlab.com/2019/02/28/why-we-pay-local-rates/

So disclaimer, I work for GitLab. But the draw to working here isn't the possibility of making an SF salary, it's to work remotely for the same salary as working for a local company. I don't really care if I'm making less than a colleague in SF, because the benefit of working remotely while not taking a pay cut is already worth it. It's not for everyone though, so if you don't see working from home as a big enough benefit then that's valid.

Your local adjustments aren't competitive, though. I live in a low cost of living area, but I could easily make at least 50% more than what your salary calculator shows at any of a number of local companies. And, in practice, I work remotely for a Silicon Valley company and make even more than that (while still saving them money relative to SV rates).

That's fair, I had the same experience coming from a lower COL area, and when I was interviewing I was able to negotiate for a higher salary and they adjusted. If GitLab wants you badly enough then they'll do what every company does and try and make themselves competitive. You just have less leverage to negotiate in general because you're competing with international talent vs local talent.

It doesn't bother you that one of your colleagues in SF doing the exact same work as you gets paid double to also work from home?

Not really, my motivation to accept a job at GitLab didn't come from how much I could make relative to everyone else in the company, it came from how I could be doing the same work I was doing for a local company but from home. Salaries aren't the only thing that make one company more appealing than another.

It's not about salary, its about fairness. This is the kind of thinking that leads to the pay gap between genders -- because women are willing to accept less pay for the same work because "it's good enough and I don't want to cause trouble". It might very well be good enough, but it certainly isn't fair. Trouble needs to be caused when unfairness is involved.

As a woman myself, I don't see this as a slippery-slope argument like you're implying. The gender pay gap is very complicated, and IMO not at all the same as a company saying "we want to offer salaries that compete with your local companies, and then also offer these other benefits like working from home" vs "we want anyone within the company to make the same amount regardless of where they live".

The gender pay gap is a whole separate matter that I'd prefer not to get into because, tbh, talking about it in tech-spheres that are still male-dominated is intimidating. I guess all I can say beyond this is that if you're ethically against these practices then I support you voicing that, and while I can offer differing opinions, I still think you're within your right to openly disagree.

Why not compare with other remote companies, but with local ones?

Furthermore, I’d care a lot if I made a lot less than a colleague for the same type of work at the same company.

Living in a cheap area comes with drawbacks. It might be a good choice for some, but a necessity for others (maybe they have relatives to take care of). I don’t really see how my choice of location should affect my payment in a remote company at all. But then, maybe a company like Gitlab wouldn’t be the right place for me, because I don’t share their salary philosophy.

> Why not compare with other remote companies, but with local ones?

Because there really aren't that many of them, and even fewer who aren't also using local rates.

> Living in a cheap area comes with drawbacks.

I agree, I live in a cheaper COL location. But, I was already living here, so I'm not sure how my salary at GitLab affects that. Local companies don't pay you more because of the drawbacks of living in a cheaper location. If I moved to a higher COL location then I would be compensated for that [1]. The mechanics are the same, I just get to do my job from home.

> I’d care a lot if I made a lot less than a colleague for the same type of work at the same company

This is, I think, the most important factor. I didn't decline my offer at GitLab in favor of staying at my previous company because I knew my salary would be the same as every other employee. I compromised on that front so I could work remotely for a company that I really felt like was a better fit for me.

[1] https://about.gitlab.com/handbook/people-operations/global-c...

Really you’re not right for them because you don’t share their remote philosophy. Their comp structure is designed to filter for employees who value remote over all else. Kind of makes sense for a 100% remote company to do that. People who are wanting SF rates in Thailand aren’t really motivated by remote, it’s a perk, but geo arbitrage is the real motivation.

That's a great way of hiring people who aren't good enough to get a remote job at SF wages. The problem is that it cuts off the ability to hire the top of the market. I currently live in Boulder, Co, but I never even considered working for a business that wasn't in (and paying like) NY or SF.

For top talent you're not competing with the local crappy .NET consulting shop paying $60k a year, you're competing with every SV startup that's open to going remote for the right hires.

All that said, lots of reasons other than comp to take a position, and it seems to be working just fine for GitLab!

> The problem is that it cuts off the ability to hire the top of the market.

To be frank, I don't think the gap in skill between the top-top-top tier employees and those who are competitive candidates for non-SF salary remote positions is all that wide, nor do I think it's necessary for a company's success to only hire the absolute pinnacle of talent. We're also not competing in the same consumer market as many SV startups, so if a different remote company has a higher saturation of top-tier developers, I'm not sure why that affects us unless they're a competitor.

I do see this point though, and I'm sure Sid does as well, but the level of skill that the people I work with have vs the employees at my previous (local) company is incomparable. Everyone is very good at what they do, and are motivated to continue working here because of all of the other perks of working for a company like GitLab.

What happens if someone starts working remotely in a high cost of living area and moves? Do you cut their salary when they move or do they get to keep their original salary?

Salary is adjusted: https://about.gitlab.com/handbook/people-operations/global-c...

How did you get your first 100/1000 customers ? :)

We got 100,000 users of the open source distribution before we introduced a paid one.

In the first year that Dmitriy made the open source distribution (and I didn't even know it existed) 200 people contributed to GitLab and probably 10,000+ people used it.

Read more about how we turned that into revenue in https://about.gitlab.com/2018/11/09/monetizing-and-being-ope...

could you talk about your development model (people management). For example Basecamp recently wrote about its 6-week sprint mechanism.

What did you guys end up with ? im assuming you optimized it for your remote working style. Do you do daily standup video calls ? what works and what doesnt ?

We do month long sprints, GitLab ships on the 22nd https://about.gitlab.com/2018/11/21/why-gitlab-uses-a-monthl...

We do a daily company call and group conversation https://about.gitlab.com/handbook/communication/

You can find more details on what works for us on https://about.gitlab.com/company/culture/all-remote/tips/

How do you protect your copyright assignments in the face of an employee paying someone else to do their work?

How can I be qualified to get a role as Frontend/React dev at GitLab ?

Please see https://about.gitlab.com/job-families/engineering/frontend-e...

We're hiring for role and many others https://about.gitlab.com/jobs/apply/

Reply on news.ycombinator.com