Perihelion

Meltano | All positions are full time and remote | https://meltano.com (follow the code blocks on our website for a demo!)

We're a seed stage startup that recently spun out of GitLab. A bit about us:

Meltano is an open source DataOps platform that brings together best-in-class open source tools and technologies for the data lifecycle, including the Singer standard for data integration, dbt for transformation, Airflow for orchestration, and soon Superset for visualization. It simplifies configuration, deployment, and monitoring, and lets data teams benefit from DevOps best practices such as version control, code review, and CI/CD.

Stack: Meltano and the Meltano SDK are written in Python. Vue.js (as part of VuePress) and Bulma CSS are used on the front end.

Open Roles:

- Backend Engineer - Senior Backend Engineer - Senior Frontend Engineer - Head of Partnerships - Content Marketing Manager - DataOps Evangelist - Senior Support Engineer - Technical Marketing Manager - Senior UI/UX Designer

Apply online at https://meltano.com/jobs. If you have questions please reach out to us on Slack: https://meltano.com/slack

Thanks! This is really useful feedback. To date, Meltano has been geared towards data folks who are likely to understand these concepts and acronyms, but there's definitely a need to explain it for folks who aren't as familiar. We're going to be working on the website copy in the coming weeks to make it easier to understand with as little digging as possible. If you think of anything else please feel free to reach out to us.

Definitely. That they're trying to position this as an oversight is frankly disgusting. That code was intentional.

This so much. It works really for your house too. I find that decluttering my physical and digital workspace at the end of the day means I'm not stressed about mess in the morning.

Yeah, it was there (along with a note on how to get free stickers) but now it's gone. Keybase stuff is still there though. Random.

Thanks so much for your kind words! We're always trying to improve, so even though some of the comments are negative, it's still good to hear about pain points so we can fix them.

Hmm, not sure what happened. It was there, now it's not. It's amanda@gitlab.com -- sorry about that.

I've actually experienced this exact thing. Usually a refresh fixes it for me so I never gave it too much thought. I'm not sure what causes it exactly but I'll follow up with the team about it. It usually happens to me on merge requests -- do you notice it on specific pages at all?

I'm really sorry to hear about the crappy experience you've had with GitLab. If you'd like to detail some more complaints, I'd love to hear them and open some issues about these things. Feel free to shoot me an email (located in my profile) or reply here. Either way, thanks for the feedback you've provided here.

As far as the frequent upgrades go, we've been using .com as a way of dogfooding GitLab at scale. Sometimes this goes well and other times it doesn't. We're actively working to improve this process so that downtime and breaking changes are less frequent. The end goal is to eradicate both issues so that upgrades are seamless.

Since the first part of your comment is addressed to Sasha I'll let her reply to it, but to address the second part:

There are multiple people involved in the hiring process here at GitLab, specifically several people who handle phone screens and resumes. The responsibility of vetting doesn't rest solely on one person and is actually a pretty collaborative process in my experience. As an example, I was able to vet every single candidate's resume myself for roles I was involved in hiring for.

Totally agree with this. Having to join 10+ Slack-like groups to collaborate on open source projects is unrealistic for me. As a result, I don't frequent some projects' chats and stick to bug trackers/mailing lists -- as a result of that I miss out on a lot of the camaraderie that comes with contributing to open source. I've missed out on a few conversations where decisions were made too. Being in multiple groups on these services is a huge pain point for me, whereas being on multiple IRC servers in multiple channels is far less invasive to my time and computer resources ;D. I'm not necessarily advocating that everyone use IRC for everything, but it seems like a lot of us had standardized on IRC for OSS before most of these services came along.

Also I'm salty that most of these Slack-like services have no ignore feature/minimal moderation tools which are both things I've leaned on heavily when working with communities. That's probably a rant for another day, but it's related to why I really dislike using some of these things.

This might just be my perception, but it seems like most people I come across in this field were on IRC at some point.

Valid point, but there are other things to consider. The reason I buy Windex is because it saves me time. Instead of buying vinegar, lemons, and rubbing alcohol and mixing them together with water every time I want to clean a something, I just grab the Windex/Lysol/etc. Likewise, I can spend time messing around with getting configs for various things in order, or I can one click deploy something to Heroku/AWS/DO/etc and not have to worry about it too much. It all depends on what's valuable to you.

We're in the process of migrating the swag store to another provider. Shoot me an email (see bio) and I'll see what I can do for you in the mean time.

No problem, thanks for clarifying.

Ah, okay. Sounds like they were trying to focus on people with a specific type of experience and not blacklisting people based on a specific employer or anything.

We've actually been trying to back off of HN, but the community posts just about anything that appears on our blog.

Could you elaborate on this? I think DO has a right to hire however they want to but I'm curious about who they're auto-rejecting/why.

I'm in no way suggesting that people spend all of their time at work or have significant overlap between their work friends and after-work friends. However, it's nice to work with people and not robots. Some people can tolerate sterile work environments devoid of anything but neutrality, and some people can't. I'm not even saying you have to be friends with the people you work with, but being friendly goes a long way. You spend a large portion of your day with these people, so it's not a huge ask for someone to give a crap about them as people.

That definitely helps. I find there are other little cultural things you miss like inside jokes/shenanigans. They're not work-related but they're related to work and can make you feel like part of the team.

When I say process, I mean some of our operational processes like making sure backups work. There was an incident with data loss last week: https://news.ycombinator.com/item?id=13537052

Like any company, we have our own business operations issues too but it's still one of the best jobs I've ever had. We're pretty open about our flaws, to the point where the CEO even has a page that lists his out: https://about.gitlab.com/handbook/people-operations/ceo-pref...

Honestly, I haven't seen a company that does the hybrid remote/on-site thing well. I'm sure they exist, but every time I've worked at one the people who were remote were out of the loop on almost everything.

Hybrid remote/on-site requires some great discipline. If you have a watercooler chat with someone about a feature, it's easy to forget that a remote colleague wasn't there for the discussion/not document what was said.

+1 for working remotely on a team that makes an effort to make it work.

> First, no one has the discipline to write much of anything down.

This is why it's baked into the company culture. It's very common for someone to ask where something is in the handbook or if an issue has been created for something.

> It's a very boring process and it's always going to be low-resolution. Your most meticulous documentation writers will get fired for failing to get their "real work" done. If you personally recognize the value of the documentation they furnish and thus refuse to fire them, all of their peers will feel that they are dead weight, which is still a ticket out of the company.

Fwiw, everyone is responsible for maintaining the handbook/our process and procedure documentation. The docs team isn't on the hook for it, nor is it the sole responsibility of engineering.

> Second, after all that work, no has the discipline to read much of anything that you've written!

After enough reminders, you'd be amazed at how quickly people learn to RTFM at work.

> They skim. They glance. They Ctrl+F. They don't read. When you're in a pickle and you can pick out a life-saving bit of documentation, it's amazing, but that happens quite rarely and requires a lot of energy.

It's true that people skim the handbook (the guide with all of the "Here's how you get access to Twitter accounts" stuff), but runbooks are actually looked at when stuff hits the fan. I think it's important to differentiate these two things since they have different purposes. Imo runbooks should be as lean as possible for that very reason.

> Good programmers are both lazy and dumb!

This level of documentation is helpful for non-developers who make up a significant part of many organizations. We're not just talking about documenting code here.

> If you want documentation that means something, it needs to be part of the process of actually working.

100%, this is the only way it works.

Not that this excuses anything, but maybe it'll help explain it: This interview was recorded a little while before the incident when we were unaware of some of the issues we have in process. Now that we're aware, we are working on correcting these things.

But you're right, the timing of this piece was probably not ideal.

Hey Deepak, thanks for the feedback. We've built out a UX team and improving that aspect of the product is high on our list of priorities, but please feel free to reach out if you have any specific issues. Happy to document those for you.

.com is free -- paying customers/CE users weren't affected by the outage.

Hey Richard, we're actively working on fixing issues on the backend of gitlab.com: https://gitlab.com/gitlab-com/infrastructure/issues/947

Much of this work isn't front-end work and we have a separate team taking care of it.

Hey Daniel, I want to thank you for your candid feedback. Rest assured that this sort of thing makes it back to the team and is truly appreciated no matter how harsh it is.

You're absolutely right -- we need to do better. We're aware of several issues related to the .com service, mostly focused on reliability and speed, and have prioritized these issues this quarter. The site is down so I can't link directly, but here's a link to a cached version of the issue where we're discussing all of this if you'd like to chime in once things are back up: https://webcache.googleusercontent.com/search?q=cache:YgzBJm...

There's also this one if anyone is interested in helping out with the DB side of things: https://about.gitlab.com/jobs/specialist/database/

All of my non-production machines have emojis in PS1 somewhere. It sounds ridiculous, but I know that if I see a cheeseburger or a burrito I'm not about to completely mess everything up. Silly terminal = silly data that I can obliterate.

Haha, it wasn't intentional. I'm just a space nerd. That book ranks pretty highly on my list of things every space nerd should read though.