I applied for an Engineering role at Gitlab. I didn't make it past the initial interview screening and politely asked for feedback in order to grow professionally.
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.
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
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.
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.
Interesting. I have worked a bit on our calculator in the past (technical implementation).
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.
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.
I would like to ask why you feel a job should be rewarded differently based on location when the deliverables and other gains from the employee are the same?
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.
It allows them to capture extra value from employing people in areas with less competition from employers.
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.
Piling on here...”pay me more because I live in San Francisco” carries about as much weight as “pay me more because I’ve got twelve kids have to pay alimony to two ex wives.”. It’s one thing when there is an office in San Francisco where you need to show up most days. When you are working from a spare bedroom, it really doesn’t matter where that bedroom is.
It does matter, because payment isn't necessarily a reflection of delivered value, payment follows a supply and demand curve.
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.
> So if you want to pay everyone the same wage, you either stop hiring from SF altogether or you give everyone SF salaries.
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 taken to this logical extreme, the only conclusion you can come to is that they value having people from more expensive areas. I mean, from a business perspective, it seems insane to hire anybody from SV if you can fill your roster with equivalent people from poorer areas. Some areas are absolutely chock full of experienced developers used to working for a tenth of the salary that a SV developer can demand. So why would any rational company choose to pay up to 10 times more than they have to for workers?
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.
> "The people in SF aren't magical; people outside of SF can do the job just as well."
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.
> Functional remote teams are better at communicating, yes, but that's survivorship bias
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.
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.
Did you see that "South Carolina" is an option in the drop-down? It has a value of 0.7, which seems pretty generous: it's higher than New Jersey (0.633), and is the same as Atlanta, Charlotte, and Connecticut (0.7), all of which have higher cost-of-living than most parts of South Carolina.
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.
Well the 'child' inquiry was more related to how having a child can dramatically alter a family's cost of living, and how or even if this is considered with equal earnest in salary maths--less so a critique about the absence or presence of parental leave (which admittedly, yours is impressive).
Not sure I follow, admittedly I'm not entirely versed in employment law well enough to know better, but what would be the protected information that precludes a family planning calculation in the salary calculator but not parental leave?
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?
Not associated with gitlab or employment law in any way, but employers in my country may not ask if you intend to have kids. The reasoning is that will be less likely to hire people that will be absent on parental leave, have more sick days, won't be as likely to do overtime, etc.
Oh for sure, we have those laws too and I'm definitely aware of them. I guess my question has existing employees baked in mind. An existing employee who wants to move to a higher COL environment seemingly has to go through a process that existing employees who are expecting a child don't, even though having a child dramatically changes the day to day expenses of living for a household. Or at least, that is a situation that isn't discussed in the handbook.
I could have clarified that inquiry a bit better, me thinks.
You seen to be conflating a household's actual expenses with a city's relative cost of living. Gitlab (along with my own employer and most remote-friendly companies I know of) adjust's pay based on the latter, not the former.
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.
You seen to be conflating a household's actual expenses with a city's relative cost of living.
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.
Nowadays (almost) no one will give you post-interview feedback. The risk of being sued for "discrimination" because of whatever made-up reason is just too high. In the World when more and more people belong to unknown 3 months earlier "oppressed minority" nobody wants to take chances.
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).
> In the World when more and more people belong to unknown 3 months earlier "oppressed minority" nobody wants to take chances.
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?
> Nowadays (almost) no one will give you post-interview feedback.
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.
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.
Ding! Ding! Ding! You hit the nail on the hammer. They write it all down but do you really think anyone actually reads or follows the handbook? It has to be thousands of pages long! It is all for show so they can write blogs about it and try to impress the public with their so called “radical transparency.”
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.
I applied for a position (Backend Engineer in Search) that I felt I was a great fit for. I was rejected without even a phone screen.
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.
What I find very weird is the fact that almost every job has a hard requirement for Ruby (or now it seems Go, last time I checked their job adverts it was almost exclusively Ruby).
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.
I've read they don't hire junior people, which might explain why you haven't heard anything. As somebody that has written a search engine, I would suggest you implement one and make it accessible to overcome the junior title...if that is the case in your situation.
Blanket rejection of juniors is pretty short sighted. Not offering any rejection at all is even worse. If you're not hiring juniors, say so. If you're not hiring juniors and one applies, send a polite response to say "Oh hey, thanks but we're after more senior people, but please try again in a year or so!". There's no good reason for a non-response, and when it's in their handbook and they still don't do it, a big red flag for other candidates.
Agreed, but isn't the point of labelling an open position 'junior' or 'senior' so that candidates will know whether it's appropriate to apply? Everybody surely knows what these terms mean, right? And if it isn't in the job title, then why can't they put it in the job description so they don't get junior experience people applying for senior jobs?
> As somebody that has written a search engine, I would suggest you implement one and make it accessible to overcome the junior title
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.
Honestly the post for https://grep.app that was posted a few days ago is a perfect example of demonstrating what you can do. He had the CTO of GitHub reach out to him publicly.
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
It doesn't seem like it. I have applied twice and I have 4+ years rails experience. The feedback I got was that I wasn't ready and to come back in a year or 2.
I applied twice with a year between the two attempts:
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.
Not to be mean but I'm sceptical of CVs like that too. I expect people to stick around for a while. I need to know I can depend on them not to jump ship at the slightest hiccup.
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.
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.
I'll give this an upvote as someone with a resume/CV that would resemble a job hopper. I am skeptical of people like this(even though I myself could be construed as a job hopper) in interviews.
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...
Unless they can give me a reasonable explanation for the job hopping I'm not going to take the risk.
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.
Our company hires a lot. I once asked if we can give people feedback if we don't make an offer, to help them learn.
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.
> 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.
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.
We really appreciate all of your feedback about the GitLab interview process — it helps us improve as we continue to grow. Your experience as a candidate is extremely important to our whole team, and I’m sorry to hear that yours wasn’t positive.
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).
I applied as well, got rejected, and asked for feedback. I did get it, but it was not very actionable. Then again, the person who provided me the feedback just copied over the notes from the one person who did the interviewing, so this is probably somewhat hit-or-miss too: you just have to be lucky who interviews you. Which is not just the case for getting feedback, but also for getting the job, I suppose.
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.