It would be great if you understand that just saying something is not enough on the internet.
I’ve been looking at job postings and watching the way they work too for a little time since it’s all open.
DBAs are “ruby devs who have used Postgres”
https://about.gitlab.com/jobs/apply/backend-engineer-databas...
SREs are “ruby devs who have used docker/kubernetes”
(No job listing currently)
The only open job labelled “ops” is telling.
https://about.gitlab.com/jobs/apply/frontend-engineer---conf...
The "Ops" section actually consists of product development teams for features in GitLab itself (the Configure/Monitor "stages"), while the SREs are in the "Infrastructure" department. See https://about.gitlab.com/handbook/engineering/#engineering-d.... But yes, we don't seem to be hiring SREs at the moment, but I assume we'll add more openings in the beginning of next year.
Regarding DBAs, that job you posted is more of a normal Backend Engineer role with a database specialty. We also have dedicated Database Engineer roles:
- https://about.gitlab.com/job-families/engineering/database-e...
- https://about.gitlab.com/job-families/engineering/database-r...
The job description for SREs is here:
- https://about.gitlab.com/job-families/engineering/site-relia...
I didn't find some of those jobs, so thanks for linking them.
As a side note I just went through those job descriptions and I -really- like the layout.
On topic: Unfortunately they really do prove my point. There is a very strong focus on "strong" programming skills which is rather undefined. It's literally mentioned in every single role description.
The overwhelming majority of staff that knows how to run software reliably ironically are not software engineers, although there certainly are some software engineers who also possess this skill.
The people I'm speaking about typically understand concepts and solutions (like PAXOS, filesystems or public cloud) more than they understand software development methodology or software product structure.
I guess you have a global reach and can be quite picky about who you hire, maybe you /do/ exclusively hire architecture and systems focused programmers, or maybe "strong" programming skills are a different definition to mine.
We do have this note on all job pages, which maybe should be more prominent:
> Avoid the confidence gap; you do not have to match all the listed requirements exactly to apply.
Some amount of general programming experience is definitely required though, since SREs and DBEs frequently have to dig into our codebase and things like Ansible runbooks. And especially regarding SQL, a lot of it is heavily abstracted not only through the Rails ORM but also our own code.
Found some other jobs that focus less on programming, though we don't have current openings for most of these either:
- https://about.gitlab.com/job-families/engineering/cloud-nati...
- https://about.gitlab.com/job-families/engineering/infrastruc...
- https://about.gitlab.com/job-families/engineering/monitoring...
- https://about.gitlab.com/job-families/engineering/security-e...
- https://about.gitlab.com/job-families/engineering/vulnerabil...
We don't seem to have a good overview of all roles, I found these through https://gitlab.com/gitlab-com/www-gitlab-com/tree/master/sou... :)
"Until very recently I was the only database specialist which meant I had a lot of work on my plate."
https://about.gitlab.com/blog/2017/10/02/scaling-the-gitlab-...
Obviously this doesn't preclude operations or systems knowledge but again, it's at least telling of the mindset.
Edit: Admittedly while I have done a lot of DBA stuff and server operations on top of my software development, hardware and networking are not my strong points so if the company could afford it I would want a more traditional server/networking guy on my team (and at a previous job I did exactly that). And I agree their job posting seem to have a very heavy focus on development experience.
With that said, the old database specialist position was about 80% engineering, 20% infrastructure, with the infrastructure work being done in cooperation with the production engineers.
I left the database team a good year ago and quite a lot has changed since then. I think these days we have a handful of people focusing on the database side of things.