GitLab Handbook
about.gitlab.com
about.gitlab.com
I never heard back from the recruiter or company after that yet their handbook says:
"If the candidate asks for further feedback, only offer frank feedback. This is hard, but it is part of our company values."
I always wondered if it was because I questioned the policy of paying people differently based on their location (more specifically, some algorithm's idea of the rent in their area) rather than the work they do.
It is obvious by all the recent news articles and information leaking out from current and past employees that it is just a facade. It won’t be long until they are fully exposed and we see they are just another greedy startup like WeWork or Away with some crazy CEO putting on a show for the public while putting fear into the employees.
Interesting, there was a moment maybe a year and a half ago where I wanted to work for Gitlab, but upon learning precisely this I changed my mind. Not necessarily just that pay was location based, but reading through the Global Compensation page just felt very...I dunno, cold and dispassionate?
There's probably a better way to phrase the sensation, because I'm certain this wasn't their intent, but the right descriptor eludes me presently.
Regarding the handbook though, I feel its entirety is cold and dispassionate. Devoid of anything human.
-- BEGIN: BIG ASS WALL OF TEXT --
Submitted for your thoughts: I toyed around with their salary calculator. Selected my job role and what I think is an appropriate guess of my own skill level with the options provided.
And then I got stuck. Because the "area" (my hometown in the rural southeast US, an economically depressed former mill town) I'm about to buy a house in isn't represented, it's not an option on the list. Neither was the city one county over, a city with a much more productive local economy. In fact, they don't even list the state Capitol, home to a pretty good business school and several engineering schools in the state. The nearest metro area that I could select to even calculate a potential salary is three hours away, separated by a state line with a completely different state tax rate than where I plan to reside.
It gets more complicated. The cost of living where I'd like to buy a house is objectively less than this city three hours away, separated by a state line. I know Gitlabbers love to comment and clarify things, so if one of you are reading this I'm curious to know how your salary sabermetrics adjust for this.
Then there's the fact that my significant other plan to start a family. If I buy a house in hometown, and I'm paid a lower salary than city three hours away, what's the discussion like if I get hired and two years later I have a child? That's not covered in the Compensation Handbook (if this is mentioned elsewhere in the handbook and I merely missed it, my apologies, I'll redact this complaint). Relocating requires involving a "written agreement" from my manager, and a recalculation of my salary.
On the one hand, it's VERY helpful I think to have all this laid out before applying, it's a level of transparency that more companies could stand to emulate, even while I'd say maybe don't emulate every practice employed by Gitlab...but the implementation of various policies just feel robotic, impersonal and quite rigid.
Again, I'll take full ownership of my words here if I've missed, or completely misread and misinterpreted aspects of this all, and I completely understand it's within Gitlab's prerogative to structure their company in a way that attracts the types of people for whom these things aren't considerations for their next job. It's just a shame for me personally, because I really like the product and really wanted to be part of solving some of the technical challenges their tools solve, having been a pretty vocal proponent of them in my current dev team.
Some clarifications, best of my knowledge, currently on mobile:
It would be impractical to calculate all the location factors in the world, and in your case it would be calculated. I agree with you that this is less than optimal, as it might stop people from applying if that data is missing. So this is an area where we could improve.
Internal discussions on the calculator have lead to changes, e.g. https://gitlab.com/gitlab-com/www-gitlab-com/issues/3396 So the calculator or location factors are also up for discussion and iteration.
When you move, higher location factor definitely needs approval, lower doesn’t afaik. To be honest often location changes with a big factor change are across state or country lines, which might mean change of Entities even in Europe. Compare that to a non remote job, if you are bound to an office location: you cannot move.
Personally I haven’t been involved in a location change of a team member, but as a manager I would definitely try to enable my team member to move let’s say from Manchester to London if they do wish.
It would be impractical to calculate all the location factors in the world
On the one hand I absolutely agree with you here, however I searched for multiple cities in the state of consideration, two of them are international destinations on the Atlantic coastline with considerable economic impact to the state and region at large, and as mentioned one of them is the state Capitol with nationally recognized colleges, I'm just a bit surprised that not this city is represented in your calculation.
That said, I do hope that area is improved on at least for the sake of other potential applicants.
Cheers!
The fact that the urban areas of South Carolina aren't broken out actually seems better for anyone who would plan to live in a rural part of the state. By comparison, "Everywhere else, Georgia", "Everywhere else, North Carolina", and "Everywhere else, Virginia" all have a multiplier of 0.633. This seems to indicate that you'd get paid about ~10.5% more in rural SC than you would in other rural places in the SE.
E.g I don’t see why I should take a pay cut moving from the US to the EU. Looking at Basecamp, they give everyone the US salary and they arrange their culture around remote work that way.
Note how it doesn’t even work this way between countries, through the ‘most favoured nation’ laws.
They're not going to say that because a lot of people have odd ideas about compensation that they're very emotionally attached to. There are people that would take a job with them for $X when told its about cost of living fairness that would not take the job for $X if they were told it's about capturing surplus value.
This is the same reason it's dangerous to share your compensation with coworkers as an employee. They don't just all say thank you for telling me and negotiate for a higher salary while acting discreetly with regard to your conversation, or start job searching; some will get real mad and irrational and there's a very good chance you'll be caught up in the fallout.
If you don't pay SF rates to somebody living in a SF bedroom, then you can't hire that person, unless they accept leaving money on the table and nobody wants that, especially because wages usually reflect the cost of living in the area.
So if you want to pay everyone the same wage, you either stop hiring from SF altogether or you give everyone SF salaries.
The later option isn't feasible because if you pay everyone SF wages, then you might as well open an SF office and hire only from SF. Is SF overcrowded by companies? Plenty of tech hubs to choose from, you only need a decent university nearby and developers don't need to be in the same location as the sales team.
As a matter of fact one reason companies hire outside of big tech hubs like SF is cost efficiency. Because remote work has disadvantages, like poor communications and the need for employees that can self manage well. You take cost savings off the table and remote work is much less appealing.
Doesn't matter where they bedroom is?
That's a socialist concept. Not in the world we live in.
The first option is a perfectly reasonable position to take. There's less than a million people in SF. There's over seven billion people everywhere else. The people in SF aren't magical; people outside of SF can do the job just as well.
> if you pay everyone SF wages, then you might as well open an SF office and hire only from SF.
This statement only makes sense if the only thing you are considering is cost. Even if the cost is identical, it's still advantageous to hire remotely. It's easier to hire, there's a much larger pool of candidates, it lets you hire people who would otherwise be inaccessible to you for other reasons, it increases loyalty, there's no commute draining people's energy, etc.
> Because remote work has disadvantages, like poor communications
In my experience, fully remote teams are much better at communicating than mixed or onsite-only teams. Why do you think remote work brings poor communications?
I think the obvious reason is because there is more to having a high tech worker than the work they produce. Remember that Gitlabs is still a VC backed company. In addition they still have to exit sometime to pay back all those VC investors. As much as I hate to say it, a startup staffed by people from eastern Europe or south east Asia doesn't have anywhere near the cache of a startup staffed from people in SV.
Right now Gitlabs has paying customers, but it's important to understand that its bottom line could depend as much on their investors (and potential investors) than its sales. Not only that, but the buzz you generate from being a SV startup leads to other SV startups using your service.
How many companies would (very unfortunately) give Gitlab a pass if it was staffed entirely out of India? I'm extremely sorry to say that I think it would be quite a few.
So, as terrible as I think it sounds (especially as a developer who works out of rural Japan), I can completely see the value of paying more for developers from certain areas. SF, LA, New York, London, Paris and even Tokyo are just much more impressive places for your staff to live than We-don't-even-have-a-train kuso-inaka Japan.
We agree. But if there's expertise in SF that you can't get anywhere else, then you end up hiring from SF too.
In my experience this is exactly what happens with companies working with remote workers, they only hire from SF or NYC or other expensive cities when they don't have a better choice.
---
> "In my experience, fully remote teams are much better at communicating than mixed or onsite-only teams. Why do you think remote work brings poor communications?"
I have more than 10 years of experience working remotely and sometimes I hate it. Functional remote teams are better at communicating, yes, but that's survivorship bias [1] in action ... the people themselves are better, due to the selection process.
Communication skills can be honed of course, but the people have to have an inclination for it and they have to be capable of self management. I have no idea if better education and better processes can indeed make a difference, but I've seen people and companies failing hard at remote work and the companies that succeed in working remotely are those with a strong culture for it, a culture that's not easy to build. And their hiring process does tend to select for those capable to function well remotely.
N.b. I know this is a total anecdote, sometimes I wish we used the scientific method in advancing this field, but alas we don't.
I agree with this, I just don't think that factor has any practical relevance to this particular discussion. Remote companies that aren't good at communicating are dead companies, and dead companies don't hire anybody. So what's the point in even considering them in this type of discussion? In this case survivorship bias is just filtering out irrelevant noise. If a remote company is hiring, then you can be pretty confident they are good communicators. With the exception of extremely early-stage companies of course, in which case all bets are off.
I could imagine that this is even protected information which your employer isn’t allowed to know in some countries.
Asked a better way: if, per your Handbook employees who relocate go through a process "to stay aligned with our compensation principlea" and "understand the impact to compensation or your role at GitLab"[0], do new or expectant parents not go through a similar process?
[0] https://about.gitlab.com/handbook/people-group/code-of-condu...
I could have clarified that inquiry a bit better, me thinks.
If I wanted to move to San Francisco I'd have to get my manager's approval, and I'd get a raise.
If I decided to have more kids, buy a bigger house, eat out more, start collecting vintage cars, etc I don't need my manager'd approval, but I won't get a raise.
I mean, I'd argue there are several things involved with having a family that have costs relative to where you live (access to schools/primary education for example), so I don't really see it as disparately.
Heh, that's probably by design. Pause for a while and think: this handbook would have been code executed by a soulless machine. And the business is that machine, detached from any humans that are necessarily in it.
I recall them rationalizing how it is beneficial for employees getting payed low salaries, so it does not disrupt their local markets ...
However GutLab, in their handbook, states
> the hiring manager should be prepared to let the candidate know why they were declined if they had progressed to the team or manager interviews. https://about.gitlab.com/handbook/hiring/interviewing/#rejec...
In the case of the GP the interviewer apparently wasn't up to that.
As I haven't interacted with them in any way I can't judge in any way further.
I am very early in my career, so I’d bet whoever handles the leftmost phase of the hiring pipeline saw that and basically immediately binned my resume.
But I was still pretty bummed. Since Gitlab’s development is out in the open I could see the tickets in the team’s backlog and knew that I would be able to work them. In my cover letter, I said that I wanted to help them architect and scale global code search for the gitlab.com instance.
Anyway, that’s a reality of applying for a job without a referral and so I’m not bitter about it. But man, I was so impressed with the notions espoused in Gitlab’s handbook. Principles like being a global optimizer and prioritizing unblocking others fit my natural working style very well. In fact, I’d used that exact terminology (global optimizer) to describe myself to my manager at my previous job.
Anyway, it would have been a great opportunity. And the position I’d applied for had been open for so long that I’d hoped they really wanted to fill the position. Since I didn’t even make it to the screen, I didn’t expect any feedback, and naturally didn’t receive any.
Their search infrastructure is built upon Elasticsearch, which I have direct experience scaling / putting out fires in my previous job.
So, I did have experience that was extremely relevant to their position (granted, not at the scale that they operate at, but that's always to be expected).
That being said, your point about "I've read they don't hire junior people" is precisely why I think I didn't make it past stage zero. So I totally agree with you there. I had a total of ~1.5 years of experience at my previous company, as an intern and then full-time, but since I was finishing up school during the tail end of my internship, I was only working full-time for ~7-8 months. So I'd bet it was certainly that.
--
Back on your idea about writing a search engine, perhaps I could see if there's some contributions I could make to Apache Lucene, which is the "kernel" that powers Elasticsearch.
I'm pretty sure if you can demonstrate how you can orchestrate a cluster of Elasticsearch nodes, it will go a long way. And if you can contribute to the many discussions they have about Elasticsearch in their issues, it will go a long way to demonstrate your domain knowledge.
As for Lucene, I wouldn't invest any time in contributing to it, as it has been iterated on for over a decade by very smart people. Just build something with Lucene or build something like https://grep.app
Which is not what most successful companies do, nor what makes sense to me.
I mean, if I have a developer applying with 8 years of experience and a successful career who has adapted to new languages 4 or 5 times, why would I have reservations about them being able to adapt to Ruby (supposedly a very user friendly language)?
I think I'll apply for that position at some point and see what happens. I've worked on search systems pretty extensively (query parsing, relevance tuning including learning to rank, performance monitoring and tuning) and I'd like to get a remote position working on search again but I'm fully expecting this not to matter compared to having no professional experience with Ruby.
First time I was rejected after the first interview because they found somebody better suited for the role(my lack of Ruby experience was likely a factor) - that at least was the response I got.
Second time I was rejected outright - the reason given was that for people with more than five years of experience, they expected candidates to spend more than two years in a single company.
Unless they can give me a reasonable explanation for the job hopping I'm not going to take the risk.
If I want mercenaries I'll just get some freelancers.
However in some cases its just hustle. I've gone from state government -> retail -> cloud automation. Every step of the way was a 50% raise. I can't turn those raises down and the previous employers simply didn't have the budget to counter offer...
I think it's disingenuous to put "the slightest hiccup" and "<2 years" in the same bucket. Even counting a 6 months warm-up phase, it becomes very clear from interactions with your managers, customers and HR, if a job works out for you.
Let's say you put out a plan for your professional development within the first year at a new job, and you point out within 6/9/12 months that you are instead put on dead-end projects, working on unchallenging problems that don't reflect your career interests - that's not going to change after 2 more years in that job.
The current place was not going to match the salary offered at the next place. Is this reasonable enough? Why do you think people change jobs in the first place? Your approach sends a signal you are hiring people who just want to coast and/or not aware of their market value. Which is also fine, I guess.
The problem was that they wanted me to refactor their permission layer as part of the interview and submit it as a contribution when it was done.
I abandoned it because the merge conflicts came in faster than the feedback and while i surely fucked up on my part, so did Gitlab. They wanted the contribution and the ability to say no.
In retrospect and after the news over the last year I think I dodged a bullet. Of course I dodged into a different one but I don’t wish to engage with Gitlab again.
I had the exact same experience. Even if you lived in SF, they pay way below market rate. I have sympathy for their engineers that don't have any other options but to take their deal.
I was told that this leaves more room for a discrimination suit. While the risk is low, the downside in time, money, and bad PR is significant. There's no upside for the company, except feeling good, in giving honest feedback to a candidate, though. So, strictly no feedback.
This is why we can't have nice things.
The funniest story I read the other day on HN was about some company which needed to fire 10% of their employees. After consulting with the lawyers, consulting company they have hired to help in the process they decided to take a contractor, who would not have any knowledge about employees. That contractor's only job was to randomly select 10% of people to fire. Simple, cheap, safe, no risk of being sued, maybe they have fired some people who would be worth to keep (if they really wish they could hire them back anyway).
This is the sad World we live in.
Oh come on. What country are you living in where they only managed to catch up with civil rights in the last three months? Last added protected class in the US was 2014, if I recall correctly.
Can't we keep those "we live in a society" posts confined to reddit?
In Europe, GDPR allows you to ask for your interview notes, and discrimination laws mean that companies need to actually have reasons in them for not hiring you. Given that a GDPR data request is more effort than just providing feedback you usually get some response to the question.
http://blog.interviewing.io/no-engineer-has-ever-sued-a-comp...
We do provide feedback to candidates who have passed the first interview stage and met with the team or hiring manager. Our recruiting team is working through more than 10,000 applications per month, so unfortunately it just isn’t scaleable to provide specific feedback for every applicant in earlier stages. You can find more details on the interviewing page of our handbook: https://about.gitlab.com/handbook/hiring/interviewing/
Thank you again for pointing out areas where we can continue to get better. We hope you’ll consider GitLab again in the future.
We work handbook first at GitLab (https://about.gitlab.com/handbook/handbook-usage/#why-handbo...) in line with our value of transparency so that each relevant page acts as a reference for company policies and internal operating procedures. In this case, that may mean the community would see how we define location factors, but also how they are calculated by the compensation team. I understand how the latter can feel very operational when reading through. If there is any feedback on how to make certain sections feel less cold, please open an issue in our compensation issue tracker (https://gitlab.com/gitlab-com/people-group/Compensation/issu...) or tag me in a merge request (@brittanyr).
With respect to our location factors not having all cities, this is due to taking a geographical areas approach. https://about.gitlab.com/handbook/people-group/global-compen... If there is a city that is 1) not listed or 2) not aligned to local market rates, please feel free to send us an email with this information (compensation@gitlab.com) or open an issue in our compensation issue tracker with the following issue template: https://gitlab.com/gitlab-com/people-group/Compensation/issu....
1. https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A/
About which more here: https://www.theregister.co.uk/2020/02/06/gitlab_sales_women/
https://www.google.com/amp/s/www.wsj.com/amp/articles/resign...
Or women
https://www.theregister.co.uk/AMP/2020/02/03/gitlab_proclaim...
Or my wife:
https://news.bloomberglaw.com/corporate-law/former-top-gitla...
He also came into one of our retrospectives, and said "I'm feeling really emotional today, so I might act a bit strange". Everyone asked him to leave so the rest of the team could have our retrospective, but he insisted on stay and just asked everyone to be aware of it. Of course nothing productive came out of that meeting, in fact, I'm pretty sure that's why a few engineers resigned.
The interesting question to me is whether the CEO needs to be a special case. We all have flaws, how should this be handled? Surely the important thing is that the company culture is such that people feel ok with (politely) pointing out these behaviours? Or is the CEO always going to be a special case where they're constantly in contact withe people many layers below them and that isn't a realistic expectation?
https://about.gitlab.com/handbook/business-ops/data-team/sql...
* https://github.com/fishtown-analytics/corp/blob/master/dbt_c... * https://github.com/mattm/sql-style-guide * https://gist.github.com/fredbenenson/7bb92718e19138c20591