Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

321–325 of 325 posts

Re: Dear open-source maintainers, a letter from GitLab

#321
post #227

Earlier quoted context omitted.

We never interview people to test the salary waters, we know interviewing is serious for you and it is serious to us too. We're very aware of the salaries in SF (writing this from SOMA). But since we're a remote first company we can hire for anywhere in the world and because we're open source we get a lot of great applicants. So the bar is high and for the Bay Area it is even higher. Feel free to email me at sytse at…

So sorry I missed this thread when it was hot. If you know you're not going to pay SF (or even US) sized salaries, why waste everybody's time with multiple interviews then? State up front "We're only willing to pay $80k, even if you've got the history (previous salary, measured prior project impact, demonstrated skill in the areas we need, etc) to justify 2x or 3x that". You won't be able to pick your interviewees br…

We don't want to waste anybody's time, actually efficiency is one of our values https://about.gitlab.com/handbook/#values. We do pay SF and US salaries (see https://about.gitlab.com/team/ for an idea where our team is). But as said the higher the salary the higher the bar. We think there are exceptional people in the SF Bay area and we would like them to work for us.

I tried to figure out a salary range for positions to prevent wasting everybody's time. But we still very frequently go higher or lower than I guessed based on the person's ability and their location (and cost of living).

I would like to prevent disappointing people like bitshepherd and I'm open to suggestions.

Re: Dear open-source maintainers, a letter from GitLab

#322
post #321

Earlier quoted context omitted.

So sorry I missed this thread when it was hot. If you know you're not going to pay SF (or even US) sized salaries, why waste everybody's time with multiple interviews then? State up front "We're only willing to pay $80k, even if you've got the history (previous salary, measured prior project impact, demonstrated skill in the areas we need, etc) to justify 2x or 3x that". You won't be able to pick your interviewees br…

We don't want to waste anybody's time, actually efficiency is one of our values https://about.gitlab.com/handbook/#values . We do pay SF and US salaries (see https://about.gitlab.com/team/ for an idea where our team is). But as said the higher the salary the higher the bar. We think there are exceptional people in the SF Bay area and we would like them to work for us. I tried to figure out a salary range for position…

My suggestion would be to be completely up front in what you're willing to pay, even going so far as to add it to the job description. If that means you have salary 'bands' dependent on what region of the US an applicant is from, put 'em up.

Ninja-edit: also, if the money just isn't there, consider taking on someone on a part-time basis. $80k/yr is terrible FT wages for the senior-level folks you're looking for, but if you say "We'll pay you $80k, and you just clock in M-W 9-5 (or M-F 9-1, however the math makes sense for you to divvy up a 20-hour week)" I think you'll see an uptick in interested, qualified applicants. Yes, it's a compromise (just like asking a senior-level anything to show up for $80k) but at least you'll get the senior-level brainpower on the team and still be within your budget.

Ninja-edit x2: Looking at the 'Team' page, I'm not getting a good sense of where your devops/engineering talent hails from. The folks who appear the most USian are the guy who lives 'on a farm', another who 'attends SFO Giants games', a third who 'enjoys the slopes in the Sierra Nevadas', etc. Everyone else's location is either unmentioned, or they seem to hail from Brazil, the UK, Greece, etc. The interactive map at the top seems to be mapping the accounts of suits and c-levels, but very few devops/engineers.

Re: Dear open-source maintainers, a letter from GitLab

#323
post #321

Earlier quoted context omitted.

We don't want to waste anybody's time, actually efficiency is one of our values https://about.gitlab.com/handbook/#values . We do pay SF and US salaries (see https://about.gitlab.com/team/ for an idea where our team is). But as said the higher the salary the higher the bar. We think there are exceptional people in the SF Bay area and we would like them to work for us. I tried to figure out a salary range for position…

My suggestion would be to be completely up front in what you're willing to pay, even going so far as to add it to the job description. If that means you have salary 'bands' dependent on what region of the US an applicant is from, put 'em up. Ninja-edit: also, if the money just isn't there, consider taking on someone on a part-time basis. $80k/yr is terrible FT wages for the senior-level folks you're looking for, but…

Thanks for looking into this and your suggestions.

I think the salary bands per region is an interesting idea. If we would have these today we would put them up.

In some functions (for example finance) we have part-time team members. But in a fast growing startup it makes sense to have many full-time people to reduce (communication) overhead. We are prepared to pay up where that is needed. We do allow flexible workdays for everyone. And based on ability and responsibility we also consider 4 day workweeks.

The map at the top is something we invite all our team members to join. Currently we don't have any engineers living in SF/NYC. We do have other team members in sales, finance and marketing living in SF and NYC. I do expect us to higher one or two engineers in SF in the coming months.

Re: Dear open-source maintainers, a letter from GitLab

#324
post #321

Earlier quoted context omitted.

So sorry I missed this thread when it was hot. If you know you're not going to pay SF (or even US) sized salaries, why waste everybody's time with multiple interviews then? State up front "We're only willing to pay $80k, even if you've got the history (previous salary, measured prior project impact, demonstrated skill in the areas we need, etc) to justify 2x or 3x that". You won't be able to pick your interviewees br…

We don't want to waste anybody's time, actually efficiency is one of our values https://about.gitlab.com/handbook/#values . We do pay SF and US salaries (see https://about.gitlab.com/team/ for an idea where our team is). But as said the higher the salary the higher the bar. We think there are exceptional people in the SF Bay area and we would like them to work for us. I tried to figure out a salary range for position…

Consider setting up an office in Bangalore, you can find great developers here and considering the cost of living differences you won't have to pay a lot.

Re: Dear open-source maintainers, a letter from GitLab

#325
post #166

Earlier quoted context omitted.

We've been using Phabricator for a few months, coming from private repos on Github.com. We initially liked it because it "ticked all the boxes" for the features that we needed from a source code and issue tracker. However, we ran into major issues along the way, basically because some of the concepts in Phabricator aren't compatible with our workflow. We decided to switch to Github Enterprise and haven't looked back…

> 1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team. The features which aren't explicitly marked "experimental" work very, very well in my experienc…

Hi, sorry for my late reply, apparently I'm not notified of responses to comments :-).

1. That's true; the non-experimental parts of the suite are mature and work really well.

2. This was most apparent in experimental features like Harbourmaster/Drydock, where you need a lot of clicking around to configure a basic build setup. Granted, that didn't apply as much to the core applications, but we didn't find those very user friendly too. The task detail screen in Maniphest, for example, is super-cluttered with all kinds of labels, links, and text in the main panel of that screen. Also, the fluid layout in Maniphest makes it hard to read task descriptions/comments because lines of text get very long.

3. No, we didn't, because we were going to switch away to Github Enterprise anyway. You're right about responsiveness of the team, we noticed that too, and that's really nice.

4. Exactly, code review is how Phabricator started and I can definitely see merits in their approach. However, we aren't interested in changing the core workflow of 15 engineers just because it's theoretically a better way of doing code review. We're getting actual work done just fine with Github's PR system, despite the flaws it has, and that was one of the main motivations to go back to Github (Enterprise, in this case).

Like I said earlier: I think Phabricator is actually a very nice tool and I can see how it works really well for large teams that are willing to commit to the code review style. It just wasn't the right tool for us :-).

Post reply on HN