Elixir Dev Advocate

Fly is a hosting platform for applications. Our users give us containers; we transmute them into fleets of Firecracker micro-VMs and run them on a WireGuard-backed Anycast network that runs application code close to users, anywhere in the world.

Don’t get us wrong: at Fly, we write in Rust, Go, and a bit of Ruby. There’s no Elixir anywhere in our stack today. But as we’ve been playing more and more with it, Elixir’s pull has gotten stronger: it’s just amazing for building clustered applications, and that’s what we’re building Fly for.

Like a lot of people who arrived at Elixir by way of Ruby, we started with the wrong impression of Elixir. We thought “oh, it’s Erlang with Ruby syntax”, or worse, “it’s Ruby compiled down to the Erlang VM”. It is not either of these things. If you’re like us, and take another look. Elixir is:

• A functional language with immutable variables.
• Powerful macros, so you can win at code golf.
• Pattern-matched, with graceful error handling.

And that’s before you get to the library ecosystem, which obviously includes Phoenix, which might be the most pleasant web application framework in the industry, without the sprawl and lack of rigor we deal with in other frameworks that have optimized for developer happiness.

One of the first things everybody points out about the Erlang ecosystem Elixir lives in is that everything is distributed. At Fly, we’ve found ourselves with a flexible and easy private networking system that makes it straightforward to securely express clusters of server instances. We think Elixir might be the best language to take advantage of that, because of things like:

• A cluster configuration simple enough that a Phoenix app is 8 lines.
• Phoenix’s ridicuously slick LiveView, which links server-rendered DOM updates up with browsers over WebSockets to make dynamic client applications without writing Javascript.
• The Elixir community’s embrace of Postgres; we do high availability database clusters on the same private network, spanning multiple regions.

So, anyways, we’re hiring an Elixir developer advocate to help us figure this out. Do you enjoy experimenting with infrastructure so you can show devs how to get more from Elixir? We could be a fit for each other.

The work

Our developer outreach is content based, this is not a high travel job. We think the job will break down like this:

• 20% working on the Fly.io UX for deploying and operating Elixir apps. This will mean working in Go and wrangling Docker – so Elixir folks don’t have to.
• 80% community engagement: examples, blog posts, and community outreach. Hopefully you like working with open source projects and showing other people how to get the most out of them.

That 80% covers a lot! If you are actively working on a relevant open source project, you could theoretically spend almost all that time developing your work, posting about it on our blog, and showing people in the community how to use it.

Some of your content might be useful for talks. We want you to help us decide how valuable meetup and conference talks are. Later. When the pandemic is over.

This is our first attempt at focused developer relations. There is a lot to figure out. Your work will determine how we spend money on future marketing. If you’re the type of person who wants to try a bunch of outreach to see what works, help build a dev relations organization from the bottom up, and even hire people to do the same work in other communities, you might really like this job.

Hiring process

Our hiring process is project based. We want to let you try the job on, see your work, and pay you to do a little more work.

1. Email jobs+elixir@fly.io, tell us in a few sentences what you like about Elixir.
2. Schedule a call with us so we can pitch the company to you and answer all your questions. We’ll also tell you the bad parts.
3. Sample project: we have a small Phoenix + LiveView demo we want you to improve. This should only take about 2 hours, but you can spend as much time on it as you want.

We rate the sample projects as objectively as possible. The best projects do what they’re supposed to, use idiomatic Elixir, and are read-to-show.

In our experience, the hardest part of a sample project like this is just getting it done.

Have experience? Jump ahead

If you have already built a public, open source Phoenix example that fits Fly well, let us know! We will evaluate that instead and save you a little time.

A larger, paid project

If we like your sample project work, we want to pay you to work on a larger project. We will offer a paid project ($1,000 flat rate) to about half the people who submit complete sample projects.

The goal here is to get a real, firm idea of what doing the job will be like. We’ll get you setup with Slack access, a channel to work in, and future coworkers to collaborate with.

We want you to do four things for us:

• Write “Elixir community report” describing where Fly fits well with a plan for community outreach.
• Come up with a bunch of sample project ideas (like, 10). Single sentence descriptions of projects to demo Elixir on Fly.
• Build a from-scratch Elixir app to demo.
• Write a blog post about the demo app.

When you’re done, we’ll even publish it if you’re cool with that.

Have experience? Skip steps

If you are active in the Elixir community, show us how you’ve worked with the community in the past. Then skip the “community report”.

Likewise, if you’ve built open source demos of Elixir before, we don’t need a bunch of ideas. We’ll still want you to build a demo for us with a corresponding blog post, though!

Working at Fly.io

We are a remote-first company with people in Chicago, Montreal, Boulder, and London. We’re hoping we can take field trips to visit each other soon, right now all our work happens over chat with periodic audio breaks.

We’re not a family, but we do have families and try to keep work projects from dominating our lives.

Benefits are pretty typical for a company of our size – pretty-good healthcare for US based employees, flexible vacation time, and a hardware/phone allowance.

But, we’re small! We all wear many hats and sometimes multiple hats at the same time. Come wear a hat for us.