Remote Full Stack Ruby Engineer

Hello, we’re OpenPlay! 

• We make enterprise web applications for record labels (music industry)
• Looking for full-stack Ruby engineers (Rails-like or Python/Django + want to learn Ruby)
• Would like 2 or more years of professional web development experience
• Positions are full time, fully remote and/or we have an office in Los Angeles
• Starting salary 100-150k (depending on experience) + benefits

We’re hiring full-stack Ruby software engineers to work with us on our suite of enterprise web-based music industry apps. You’ll work with us to architect, build, deploy, and maintain applications used by the world’s largest record companies (and some of the world’s smallest). This is a full-time position that can be in our office (Los Angeles/Santa Monica) or fully remote (US only at this time). We are looking for engineers with two or more years of full stack web application development experience. Starting salary range is 100-150k depending on experience.

Engineering at OpenPlay

Thousands of record labels around the world use our flagship product OpenPlay Music to manage and distribute their music. We work with the major US record distributors and many independents. We are onboarding another 300+ record labels this year and we need to grow our engineering team to handle increasing demand for both client services and new product growth. OpenPlay is a bootstrapped, growing company started in 2013.

In your role at OpenPlay you will be collaborating with a team of 4-6 other engineers and a UX/visual designer to design, build, review, deploy, maintain, and iterate on OpenPlay’s web applications. We follow a minimal agile process focused on rapid deployment and incremental improvement. Engineers participate in a weekly planning meeting, a daily engineering meeting, choose what to work on, and then spend the rest of their time getting their work done, collaborating as needed.

You will share the same responsibilities as the rest of your engineering team, which include:

• Participating in a weekly planning meeting where we review our goals and prioritize work to be done for the coming week.
• Participating in daily engineering-only meetings (roughly 30min) where the team collaborates on technical decisions, resolving issues, and reducing complexity.
• Writing tests: we write mostly full-stack integration tests and use a single testing framework for all parts of the code.
• Writing application code: mostly Ruby, some HTML, some Javascript. CSS is mostly handled by visual design.
• Reviewing code: We do round-robin code reviews as a means of knowledge sharing. All pull requests are reviewed by another engineer. You’ll take turns reviewing everyone else’s code and they will take turns reviewing yours.
• Deploying code: We deploy small changes to production code multiple times per day. Deployments are automated with lots of fail-safes and we rely on third party services for devops as much as possible.
• Maintaining code: Maintenance is a part of all code changes but we also plan specifically for improving code quality and updating to newer conventions, techniques, and technologies. You will also be reproducing and fixing the occasional bug.

Some things you won’t do:

• Estimating work to be done. Instead we try to break work down into small enough chunks that they can be done quickly.
• Reporting progress. Work is done when it’s deployed. Instead we try to reduce the scope of work that is growing complex.
• Stakeholder meetings. While agile processes are all about open channels of communication we find too much can be overwhelming. We have technical product managers who work with stakeholders instead, allowing everyone else to focus on their work while getting their questions answered.

As a small company with a flat management structure there are lots of opportunities for everyone to make an impact not only on our products but also on how we build them. We apply the same methodology of incremental improvement to our code as we do to our tools, processes, and conventions. You will be able to participate in these discussions as much as you like, and we would like to learn from your experience, but the degree to which you participate is up to you.

The main thing we’re looking for is experience in full stack web application development. Specifically, we think you’ll need at least two years experience working on all parts of a database-centric web application to be a productive member of your team. In particular you should have experience with:

• Relational database concepts such as: foreign keys, indexes, normalization and denormalization, SQL queries.
• Writing Ruby code in an MVC web framework. We don’t use Rails but we follow many of the same conventions. We’ve had success bringing people on from Python/Django so if you have Python experience and would like to learn Ruby it might be a good fit.
• Some familiarity with Javascript. We push as much behavior as possible to the server but features often do have small client-side components.
• Writing tests. We practice integration-test-heavy outside-in test-driven development. If you’ve practiced any sort of test-driven development you will pick it up fast.

In addition to being able to get things done we are also looking for someone who can research and implement best practices in order to get things done well. Code smells and poor architectural decisions can slow everyone down and make everyone sad. We collaborate frequently and we don’t always get things right on the first try, but we are looking for people who will do the work to build things well to reduce the maintenance burden for themselves and their team.

Technologies we use

• OpenPlay Music is a monolithic application backed by a PostgreSQL relational database. Heavy operations are processed asynchronously by scalable background workers that notify clients via WebSockets. At present we have plenty of room to scale.
• Our server-side code is MVC-structured and built on Sequel (ORM), Sinatra, and HAML. If you’re familiar with Rails (or similar MVC frameworks) you’ll find a lot of similarities and many of the same conventions here.
• On the client side we use StimulusJS to apply bits of dynamic behavior where it improves the user experience, most of which ultimately requests updates from the server.
• There are currently around 2500 full-stack browser-based integration tests covering every feature from user input to expected output. CI runs on every git push and completes in about 15 minutes.
• We do things typical of web applications like:
• Store data in, and query from, a relational database (PostgreSQL)
• Index data and query it with filtering and full text searching (Elasticsearch)
• Handle slow tasks with background processing
• Push asynchronous updates to clients with WebSockets
• Export XML files, PDFs, CSVs, Excel spreadsheets, and other formats that just won’t seem to go away
• Import data from Excel spreadsheets, (music-industry standard) DDEX XML, JSON, and various other sources
• Communicate with lots of external systems across all manner of bespoke APIs
• Provide JSON APIs for our customers to build on top of
• Use git for version control, build features in branches, and take turns reviewing pull requests
• Run everything on cloud infrastructure
• Rely on service providers for devops as much as possible (Heroku, etc)

• Starting salary 100-155k depending on experience
• Medical, dental, and vision insurance
• Whatever tools, services, books, etc you need to do your job
• Low stress environment: The industry we’re in is comparatively low scale and high value. While we work with lots of data we avoid some of the technical issues and constant urgency you might find with consumer applications.
• Good work/life balance: We expect that everyone works full time (40 hours/week). We do sometimes have deadlines and we haven’t always limited scope appropriately. The last time we worked late nights was in 2019 for about a week. The time before that was in 2016 for about 3 weeks. Our most recent deadline we met two weeks early.
• Flexible work and vacation schedule. You are free to work the hours that work best for you (outside of our scheduled meetings) and we don’t have a set limit on vacation days.
• Free to work remote. We’ve been doing remote work as long as we’ve been around and our process is built around it. Some of our team is permanently remote, others work out of the office part time.
• Office near the beach in Santa Monica you can use any time.
• Free lunch at nearby restaurants when you’re in the office. Some of which are delicious.

How to apply

Send us your resume! Include a cover letter to add additional details and context if you feel so inclined. We’re mostly looking for two things:

• Prior work experience that looks like it might be a good match for what you’ll be doing at OpenPlay.
• Some understanding of how to program well. Maybe a computer science degree or other academic background. Code contributions you can point to. Blog articles you wrote. A particularly enlightening reddit comment.

We’d love to know a bit about you as well but it can be a challenging prospect for an initial job application. Feel free to include anything else you’d like, but don’t worry too much about it, we’re mostly looking for the above qualifications at this point.

We look forward to hearing from you, good luck on your job search wherever it leads, and thank  you for considering joining OpenPlay!