Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitLab Handbook

about.gitlab.com

Post reply on HN
Print view View original

61–70 of 82 posts

Re: GitLab Handbook

#61

Post by oblio »

stonogo wrote: post #42
orf wrote: post #13

Gitlab Unfiltered[1] is pretty cool. Say what you want about Gitlab, but they go hard on the openness aspect of things. I can't think of another company that is on the same level as them - streaming meetings and other stuff on Youtube almost seems like overkill. 1. https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A/

They're open when it doesn't matter. When it does, they go just as hard in the other direction: https://gitlab.com/gitlab-com/diversity-and-inclusion/issues... About which more here: https://www.theregister.co.uk/2020/02/06/gitlab_sales_women/

The first link 404s.

Re: GitLab Handbook

#62

Post by mikekchar »

JimDabell wrote: post #59
bad_user wrote: post #57

Earlier quoted context omitted.

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…

> 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…

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.

Re: GitLab Handbook

#63

Post by Vinnl »

nbulka wrote: post #7

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 question…

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.

Re: GitLab Handbook

#64

Post by ThePadawan »

dsetaos wrote: post #41
Tade0 wrote: post #28

Earlier quoted context omitted.

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 i…

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.

Full disclosure: I have a very patchwork CV.

I think it's disingenuous to put "the slightest hiccup" and "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.

Re: GitLab Handbook

#65

Post by mhd »

piokoch wrote: post #60
nbulka wrote: post #7

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 question…

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 wit…

> 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?

Re: GitLab Handbook

#66

Post by bad_user »

JimDabell wrote: post #59
bad_user wrote: post #57

Earlier quoted context omitted.

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…

> 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…

> "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.

[1]: https://en.wikipedia.org/wiki/Survivorship_bias

Re: GitLab Handbook

#67

Post by ilammy »

gherkinnn wrote: post #14
dvtrn wrote: post #9

Earlier quoted context omitted.

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…

I’m fine with the location-based pay. Regarding the handbook though, I feel its entirety is cold and dispassionate. Devoid of anything human.

> Handbooks are devoid of anything human.

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.

Re: GitLab Handbook

#68

Post by JimDabell »

bad_user wrote: post #66
JimDabell wrote: post #59

Earlier quoted context omitted.

> 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…

> " 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 remo…

> 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.

Re: GitLab Handbook

#69

Post by a_imho »

dvtrn wrote: post #9
nbulka wrote: post #7

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 question…

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…

cold and dispassionate

I recall them rationalizing how it is beneficial for employees getting payed low salaries, so it does not disrupt their local markets ...

Re: GitLab Handbook

#70

Post by inertiatic »

__blockcipher__ wrote: post #16
nbulka wrote: post #7

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 question…

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 tha…

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.

Post reply on HN