[softwarelimits]

How do you know that they do not hire "any people with ops experence"? Do you have insight? Is there any public evidence for this or anything you could publish yourself to add some substance to your words?

It would be great if you understand that just saying something is not enough on the internet.

[dijit]

What you say is completely fair.

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

[toupeira]

GitLab engineer here.

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

[dijit]

Hi Toupeira,

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.

[toupeira]

That's certainly a valid concern! From my perspective, the programming skills in these job descriptions are one requirement among many others, and I'm not sure how much weight it really has in the hiring process for these roles, especially if your other skills are a good enough match.

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

[jeltz]

Why is significant Rails experience a requirement for a database engineer position? That will quite drastically limit your options. Yes, it is a useful skill but hardly necessary to do this job. I know a lot of really good database consultants and they can usually identify and fix bad queries in virtually any framework or ORM. The skills are really transferable.

[tyingq]

As recently as October 2017, they had exactly one database person. So I can imagine quite a lot of work and hiring needed to scale up a solid ops practice.

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

[dijit]

Almost to prove my point Yorick self-identifies as a "Ruby/Rust Developer" https://railsisrael2016.events.co.il/people/2644-yorick-pete...

Obviously this doesn't preclude operations or systems knowledge but again, it's at least telling of the mindset.

[YorickPeterse]

I would not call myself an operations expert by any means, but I have done quite a bit of infrastructure work in the past; both with bare metal setups and cloud based solutions.

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.

[jeltz]

To be fair it depends a bit on the context. I present myself sometimes as a database expert and other times a Ruby/C Developer. And I would argue that I, as a minor PostgreSQL contributor who follows the mailing lists, am more knowledgeable than most about databases and especially PostgreSQL.

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.