index.html.md.erb 4.84 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
--- layout: markdown_page title: "Jobs" --- ## About GitLab GitLab is quickly becoming the standard for source code version management for any company, large or small. At GitLab, we help large enterprises move to Git and build better software. ## Why work for GitLab? GitLab is growing fast. Working for GitLab means joining a very productive, ambitious team, where independence and flexibility are both valued and required. Your work will directly have a large impact on the present and future of GitLab. We like to spend our time on things that matter. We are a [remote only company](/2015/04/08/the-remote-manifesto/) and you can work from wherever you want. For more background please see our [about page](/about/), our [culture page](/culture/), our [handbook](/handbook/), and our [hiring guidelines](/handbook/hiring/). If you see yourself as a good fit with our company’s goals and team, then please review the current job openings on this page, and submit your resume and cover letter to be considered! <iframe width="560" height="315" src="https://www.youtube.com/embed/GJP-3BNyCXw" frameborder="0" allowfullscreen></iframe> ## We don't accept solicitations by recruiters<a name="no-recruiters"></a> We do not accept solicitations by recruiters, recruiting agencies, headhunters and outsourcing organizations. If you email us we'll reply with [a link to this paragraph](/jobs/#no-recruiters) to indicate we would very much appreciate it if you stop emailing us and remove us from any marketing list. ## Available Openings <% open_jobs.each do |job| %> - [<%= job.title %>](<%= job.description %>) <% end %> ## Technical interview<a name="technical-interview"></a> For some positions, the hiring process includes a technical interview. In the technical interview, you will work on an issue from the [GitLab Community Edition issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues) in a 1-hour screen sharing session with the interviewer, and code 'live', with them there to talk and collaborate with. After the interview, you will be asked to spend some time to finish the work, get it as close to [done](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#definition-of-done) as your time allows, and submit a merge request with the changes to the GitLab CE project. The interviewer will then review it, leave feedback, and ask you to look at the feedback and potentially make changes to the merge request to address it. After at most 2 cycles of review by the interviewer and changes by you, the interviewer will let you know whether GitLab will move forward with your candidacy, or not. The work after the screen sharing session, before submitting the merge request for the first review cycle, is expected to take around one hour. But as mentioned above, feel free to extend this time according to your availability, there is no time constraint. The time taken on the review cycles should normally take around two hours. While you are welcome to spend more time on this if you choose to, we will never ask you to do so. If you do not have time to do everything you'd like to, please mention those extra items in the merge request description. You are encouraged to let the interviewer know when you feel like you are getting close to having spent more time on the merge request than is reasonable. In this case, they will make a decision on your candidacy then, based on the information gathered during the technical interview and the work on the merge request up to that point. We do need at least one review cycle before evaluating your candidacy, so please bear that in mind if you're spending more than one hour before submitting the initial merge request. We do this because we believe that it is the best way for you to see what the work is really like, and for our interviewer to see how you [think, code, and collaborate](http://zachholman.com/posts/startup-interviewing-is-fucked/#collaborate). Once the merge request is finished, the code you have written will go into the [GitLab Community Edition](https://about.gitlab.com/features/#community) to the benefit of the millions of developers using this free, open-source product, but will also go into the proprietary [GitLab Enterprise Edition](https://about.gitlab.com/features/#enterprise), which is a fork thereof. When contributing code, you should follow the [Contribution guidelines](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md), and you agree to the [individual contributor license agreement](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/legal/individual_contributor_license_agreement.md). If you prefer not to do the above, please let us know and we'll give you an assignment that does not relate to GitLab but does test the relevant skills. ## Questions? For further questions about our [hiring process](/handbook/hiring) or posted jobs, please feel free to send an email to firstname.lastname@example.org.