Fly.io runs apps close to users. We take Docker containers and transmute them into Firecracker micro-vms that run on our hardware in data centers from Chennai to Syndey to Dallas. The easiest way to learn more is to sign up, and you should try that now; it’ll take you just a minute or two to get up and running.
We write a lot at Fly.io. It’s our most important tool for reaching potential customers.
We write mostly in 3 different places:
In our documentation, which is all public and online, and which (of course) targets people already working with our product, and
On our engineering blog, in long- and short-form pieces about how our product works, with an audience of basically all the nerds on the Internet.
In conversations with our users on our community forum and places like Twitter.
We’re looking for people who want to do this kind of writing with us, full time.
The predictable next thing for us to say is that we put a high value on writing. But, you know what turns out to be hard to write? A paragraph about how seriously you take writing. A paragraph like that needs to be pretty well-written itself. Its quality signals how seriously you take the process. Is this paragraph good enough? We could be here editing for all night.
So, rather than talk about how we’re good writers (we aren’t), we’ll say instead that we’re opinionated, enthusiastic writers. Also, that writing isn’t just something the rest of the team throws over the wall to “writers” to do.
More importantly, though: technical writing at Fly.io isn't an anonymous cost-center role. We've all worked at places where writing was treated as a necessary evil, something to get out of the way with the minimum possible investment. We are emphatically not that kind of place. Anything we can do to raise your profile, we're going to want to do (and if you're a low-profile sort, you should keep that in mind).
The Job, In Brief
We have a couple problems we’d like to solve. First, our documentation is inconsistent and weak in places. And then, we have a lot of stuff to say about what we’re building and what it all means, but our team members with interesting things to talk about have wildly varying levels of comfort writing stuff.
In this role, what you’d be doing is:
- Surveying our existing documentation, identifying and closing gaps (learning whatever random technical stuff it takes to write that stuff), and building a process that keeps our documentation sane going forward.
- Working with our whole team to spot opportunities for public writing, about features we’re working on, or the inner workings of our stack, or the technology ecosystem we fit into, or whatever interesting thing is bugging someone on a particular day.
These are two very different kinds of writing, and we know that. Our product and the kinds of problems we work on are very technical and can be somewhat subtle. On a dial with “technical writer” at “1” and “technical journalist” on the other side at “10”, you’ll probably be happiest if you’re at, like, a 4. But the tone of all of our writing is conversational, so you also want to be the kind of person who doesn’t, like, flinch when they see “like” in the middle of a sentence.
Mostly, we want to work with people who love to write and who find the problems we work on exciting. Global Anycast, modern language frameworks like Elixir/Phoenix, containers and virtualization, and security are all part of our beat. If you want an opportunity to nurture or develop opinions about these topics and then broadcast them emphatically on the Internet, this is a fun way to do it.
Things To Know About Us
- We’re a small team, almost entirely technical, and everyone wears a lot of hats. Once again: you won’t be the only person writing here!
- We’re remote, with team members in Colorado, Quebec, Chicago, London, Virginia, Rwanda, and Utah.
- We’re an unusually public team, with an online community (at community.fly.io) that we try to be chatty with. If we’re doing things right, this role will likely increase your public profile.
- We’re a team, not a family, but we have families and want to be the kind of place where work doesn’t get in the way of that.
- We’re a real company – we hope that goes without saying – and this is a real, according-to-Hoyle full-time job with health care for US employees, flexible vacation time, hardware/phone allowances, the standard stuff. The compensation range for this role is $120k-$160k plus equity.
How We Hire People
We are weird about hiring. We’re skeptical of resumes and we don’t trust interviews (we’re happy to talk, though). We respect career experience but we aren’t hypnotized by it, and we’re thrilled at the prospect of discovering new talent.
The premise of our hiring process is that we’re going to show you the kind of work we’re doing and then see if you enjoy actually doing it; “work-sample challenges”. Unlike a lot of places that assign “take-home problems”, our challenges are the backbone of our whole process; they’re not pre-screeners for an interview gauntlet.
For this role, we’re going to give a couple of deadline writing assignments. We'll ask you to document a feature from a rough description (not a technical challenge! we'll talk you through it!), and also have you punch up and flesh out a draft blog post.
If you're interested, mail <firstname.lastname@example.org>. You can tell us a bit about yourself, if you like. Either way, include a paragraph or two about the most frustrating technical blog post or article that you've read recently. Bonus points if we wrote it.