Live data from Hacker News

Our Handbook is open source: here's why

about.gitlab.com

71–80 of 105 posts

Re: Our Handbook is open source: here's why

#71
post #45
post #39

Earlier quoted context omitted.

Isn't 14 days more than the US average. I thought it was 10 days. So she wasn't really taking less than other companies. > with no minimum number of vacation days in place, employers are not required to compensate employees for accrued vacation days when they quit. Hmm...how does that work for employees in other countries? In the UK full time workers are entitled to 5.6 weeks holiday per year (so if you work 5 days a…

Most places I've been have a distinction between personal or sick days (days taken with no notice) and vacation days which require at least 2 weeks notice before taking. Everywhere I've started I got 5 personal days and 10 vacation days.

In the UK, and I think most of Europe, sick days aren't limited and personal days would depend on company policy. Either can require documentation (doctor's note etc).

I have 30 days vacation, which is fairly typical. Giving twice the vacation length as notice (two weeks for one week off etc) is usually reasonable, but it's usually in the company policies.

Somewhere with unlimited vacation would need to ensure the employees used at least the legal minimum (20 days, plus public holidays).

Re: Our Handbook is open source: here's why

#72
post #50

Earlier quoted context omitted.

If you don't mind me asking, is the pay competitive? I definitely like the ethos of GitLab, but unfortunately most of the remote-only companies I've interviewed with just don't offer salaries competitive with either SV/NYC tech or what I can make doing remote contracting.

Our pay depends on your location. So if you're currently charging an SF rate without the expenses of living there you're better off.

From just above: "Interestingly, more and more of my colleagues (and myself included) are moving house to their favorite places to live."

How does pay vary with location changes? If I live in SF now, and get that pay, then move, do I wind up getting paid less? If I start in a small town with low expenses, does that mean I can never afford to move to SF?

Re: Our Handbook is open source: here's why

#74
post #72
post #50

Earlier quoted context omitted.

Our pay depends on your location. So if you're currently charging an SF rate without the expenses of living there you're better off.

From just above: "Interestingly, more and more of my colleagues (and myself included) are moving house to their favorite places to live." How does pay vary with location changes? If I live in SF now, and get that pay, then move, do I wind up getting paid less? If I start in a small town with low expenses, does that mean I can never afford to move to SF?

That is indeed what is difficult. Any time you move metro regions we'll need to negotiate about the compensation. And if you're moving from an expensive to an affordable region your compensation will be lower.

Re: Our Handbook is open source: here's why

#75
post #62

Earlier quoted context omitted.

Cool. I look forward to seeing a blog post when you have that compensation framework completed. :) I've seen/heard words like that meaning anything from a 10% paycut to a 55% paycut in practical terms, its too big a range for me to really take away an effective idea of GitLab's pay level which is why I was curious about the more concrete form. A 10-15% haircut for a place as good as GitLab sounds on paper seems reaso…

For sure we'll do a blog post about it. By the way if you want something now the Travis CI talk is really good https://www.youtube.com/watch?v=N8u9H6JDAzo We don't have any hard data on this but I think we're in the reasonable range.

when it comes to deciding compensation levels, what metrics do you use? what companies in the area pay? real estate prices? a mix or something else?

there are places in the world where, say, the real estate is red-hot (obviously making higher salaries more desirable) but where local companies have not kept up with that (making cross-company surveys skew really low) so in that case what would you do?

Managing a distributed remote-friendly company definitely seems challenging, of course you're open source and have an awesome reputation, so salary is very likely not something prospective employees consider as much as they would otherwise when joining (which likely works in your favor in creating a very nice working environment full of engaged folks)

Re: Our Handbook is open source: here's why

#77
post #24

Earlier quoted context omitted.

If you go over some secret 'limit' that no one will tell you about, you'll get put in the back of the line for promotions and raises and the front of line when it's time for cutbacks.

I believe opposite case is usually prevented, people don't usually take time off for no reason, they go on vacation, family emergency etc., an observed side-effect of unlimited time off is usually people don't take time off at all, purely a cultural(company's) thing.

having a remote company also means if you have a cold you're not going to come in and pass it to everybody, and often you can still work no problem (no coworkers getting grossed out/annoyed by constant sneezing, no getting cold on transit on the way etc.) which likely means you need to take less time off, and being remote also means being able to deal with random daytime appointments much more easily, making time off for that not necessary either

Re: Our Handbook is open source: here's why

#78

This handbook looks great! However my experience interviewing at Gitlab stands in stark contrast to what is outlined here. Is this a standard/process the company is working on achieving?

If your experience has been different, we'd like to hear what happened and how we can improve. I'm sorry if it has been unpleasant. Feel free to reach out to me (job at gitlab com) or our VP of Scaling Ernst (ernst at gitlab com), who is currently in charge of hiring.

We're always working on improving our hiring practices, which can be different for different positions. Anyone applying to GitLab should have a great experience, independent of the outcome.

Re: Our Handbook is open source: here's why

#79
post #36

From the handbook [1] : > Technical interviews > Try to get a real sample of work (which we already do for developers by working on GitLab issues) Avoid puzzles or weird algorithm testing questions. Probing for data structures is fine as long as it is relevant to the job the person is going to do. > Be mindful of the background of the candidate, someone who knows 10 languages already (and some languages in particular…

Thanks, credit for this goes to our infrastructure lead Pablo if I'm not mistaken. He joined us from Amazon so it might be inspired by their process of which he speaks highly.

It's a great process to have too. Hire personalities that fit and work well with teams, and train them to be the ideal candidate instead.

Re: Our Handbook is open source: here's why

#80

Does GitLab do internships?

We don't actively look for interns, as we don't always have the time and resources to properly mentor someone without prior experience.

We do have a few talented interns that could get started immediately as they already showed some experience with the position they'd be taking.

If there is a position you're interested in as an intern, you can consider applying to the position, but it's up to the team lead and the circumstances whether we could give you a position as intern.

Post reply on HN