This document is intended to capture the decisions made while revising our job descriptions (JDs for short) in February 2021, and propose methods for creating new job descriptions in the future.
This document contains a significant bias toward engineering jobs, because that’s what we’re mostly hiring for at the time of this writing. It is intended to apply to all sorts of jobs, but, write what you know.
tl;dr
Here’s the very short version without the nuance or detail. There’s a sample JD at the end of the doc.
Say what someone would need to do in the job.
Suggest some things that might make them more awesome at it.
Explain why Oxide is worth working for.
Don’t treat it as exhaustive.
Don’t confuse experience or degrees with skill (we want the latter).
The role of a public job description
A public job description plays several roles, and these roles are almost entirely for the benefit of applicants, not us. (We already work here!)
First and foremost, it presents a need we have (for work) in a way that will attract talented people who can help us with that need. Having jobs posted on our website makes it clear that we need help with stuff, and what that stuff is, so that people won’t think "gosh, I’d love to work at Oxide, but it’s probably full" or "they don’t need my skills."
The job description is often the first thing a candidate reads about Oxide, so it is also a useful tool for getting them interested or even excited.
A publicly posted job description can help to reach people who might not be in our personal networks.
If a public job description does a good job describing the position, it propagates itself, by helping each reader decide which of their friends they should forward the job to.
Finally, the job description is not exhaustive. The intent is to communicate a sketch of the job to applicants, not to enumerate everything they might ever need to do. (We currently include some text pointing this out.) We don’t require people to stay in their job description lanes once hired, either.
Titles
This is a complicated subject, since we don’t really use job titles internally. The purpose of the title on an Oxide job description is to help candidates scan (and, to some degree, for search engines). It seems odd to write a relatively narrow job description for an "Embedded Software Engineer" when that doesn’t exactly describe any of our jobs, but the title isn’t for us.
Like any communication skill, choosing titles is not an exact science. Here are some suggestions.
Try to use titles that are being used outside Oxide, or variations of them. Even if we think of a role as a "Hubris Engineer," for instance, we shouldn’t list the job with that title because that phrase is meaningless outside the company. This is an area where we want to be very careful in being original.
The title should not be too vague, but we’re also trying not to be too specific. "Engineer" describes everything from mechanical engineering to the person who runs a train. "Software Engineer" covers our entire industry. "Embedded Software Engineer" (for instance) is likely to get us better applications by helping people find the job they’re skilled at, and not mistakenly apply to the one they aren’t. By contrast, we’re concerned that "Storage Engineer" may be too narrow. When in doubt, shop it around the office.
Tone
This isn’t a problem we’ve had, so I’ll keep it brief!
Positive language in job descriptions ("you will do X") presents us in a better light than negative language ("you won’t have to work with those bastards over at MegaCorp" or "you won’t have to write C"). We can be excited about things without needing to tear others down.
Structure of an Oxide job description
The rough structure we’ve settled on consists of three parts:
What someone in this job would need to do day-to-day.
Qualities or skills that we think would help someone excel in this job.
A summary of why you’d want to work here, which touches on comp, benefits, and values.
Most job descriptions will repeat at least some material from other job descriptions — in particular, the description of Oxide. This is redundant, but it’s deliberate: we’d like a candidate to see all the reasons why we think Oxide is awesome without having to follow a bunch of links. So we link longer-form documents for people who want more reading, but we summarize the things we think are important right in the JD.
Describing a job role
The formula we’re using is: talk about what the person would need to do, not about who the person is or what they’ve already done. Focus on things like:
What sort of things would the person need to produce, for us to consider the job covered? (i.e. bring a printed circuit board to volume manufacturing, add new features to a hypervisor, develop sheet metal enclosures…)
What technologies or tools would they need to work effectively with? (i.e. are they expected to write code in Rust? read datasheets? draft layouts in Altium?)
What supporting activities that might not be implied by the job description are nevertheless critical? (i.e. writing documentation, interacting with contract manufacturing, training the dancing bear army)
What do we expect them to learn on the job?
This is also a good place to toss in a job-specific perk or two, particularly if you can phrase them in terms of work that needs doing, e.g. "work on security mechanisms that put the user/customer first" or "build really fancy flamethrowers."
Responsibilities are not qualifications. A job may need someone to write software in Rust and C, for example — say that! That’s different from "five years of Rust experience," as we’ve had people bootstrapping on the fly and it’s worked out okay.
Don’t spam this section. We’ve all seen it — the ridiculous job descriptions that throw every possible thing they could possibly need into a big bulleted list. This destroys the signal-to-noise ratio of the job description, and it does an odd thing to the applicant pool: it filters for cockier people, who assume they could get the job despite meeting only a small fraction of the list (or none of it, because the list is clearly made up!). If you’re past about five bullets, it’s time to refactor. Remember, it’s not exhaustive.
Talking about skills
The skills section (the "You’ll thrive here if…" section) gives some idea of things that we think would make someone really effective at / happy in the role. This is a narrower focus section that is separated from the "what you’ll do" section to give it slightly less weight, because, frankly, we might be wrong about this, and we include some text after the section pointing this out. (Maybe your background servicing racecars makes you particularly adept at rack manufacturing. Wouldn’t have thought to list that!)
This is the section for talking about things the candidate may previously have done, e.g. "you’ve worked with C before." One that’s likely to be universal for software jobs here is "you’re very comfortable at a Unix terminal."
This is also the section that, if we’re not careful, can turn into the dreaded List Of Unnecessary Qualifications. This section should only list things directly relevant to doing the job. Some examples of things not to do:
Someone does not need to have done the job in the past to be effective at it today. (Likewise, not everyone who’s done it in the past could be effective here!)
Oxide is not a university, and so applicants don’t need degrees from fancy universities (or not-fancy universities for that matter). What matters is that they can work with our team to build the system we need.
If a job requires physical presence at our work sites, it doesn’t matter whether a candidate actually lives nearby as long as they can reliably be there when they need to be.
People don’t need a particular hobby, or to be a member of a particular enthusiast community, to work here. For instance, retrocomputing enthusiasts fit in at Oxide in certain respects, but we aren’t all into it, and it has little to do with building the product.
Talking about Oxide
Unless you have a good reason, you should probably just copy-paste the existing verbiage about Oxide and benefits. It’s intended to be pretty general, and if it needs to change, we should probably update the other job descriptions too!
The basic intent of this section is:
Give people a sense of what our internal culture is like.
Specifically target, and poke holes in, common assumptions about startups.
Make it clear that we have benefits, we think they’re pretty good, and they’re pretty straightforward.
Demonstrate transparency.
The culture starts with the values, and this section gives an intro. (We’ve gotten pretty consistent feedback that the full Oxide Values page is…kind of a lot to read. We’ll ask people to read that after they get excited.)
How to avoid sounding like a crappy startup
We’ve gotten some feedback on ways we’ve said things in the past, and we’ve learned from it. For better or worse, a lot of startups out there have really crappy work environments, and applicants now squint at job descriptions trying to find hints that a company is awful. Here are some notes on how we’re trying to shine through that.
Certain terms imply a hyper-competitive internal environment, which we simply don’t have. Avoid terms like "aggressive," "win at all costs," "driven," "rockstar," "110%," "best of the best" — even "passionate" has gotten a bad rap from people abusing it. We’re avoiding such language, and including specific statements about collaboration and not expecting to be in charge of everything.
The term "blame" has gotten messed up, even when talking about its absence (e.g. "blameless", a thing we’re pretty good about), by companies repurposing it to mean ignoring production failures or flakiness in their pursuit of deliverables. (Really.) We’re trying to use synonyms.
A lot of startups expect people to work themselves to death, so we wind up having to say repeatedly, in several different ways that no, really, we’re not always "on" or working, we do take vacations, we have other stuff going on, etc. This one mostly falls on the "about Oxide" boilerplate, rather than a specific job description.
Appendix: Sample Job
This is one of the early JDs that tried out this new format.
Software engineer: Control plane
The control plane is the spinal column of Oxide’s software: it is responsible for managing and provisioning virtual machines, storage and networking.
As a software engineer working on the control plane, you will:
Collaborate with other engaged, friendly, systems-oriented engineers to understand customer use cases and implement the core of the Oxide platform.
Operate across multiple layers of the stack to build the fault-tolerant distributed systems and databases that support virtual machines, network-based virtual storage devices, and virtual networks.
Drive our device security by extending the verified boot chain from early boot to all the software running on Oxide systems. You’ll secure the interface to the control plane, build identity and access control, and work with the team to define and defend against threats.
Develop tools to test and analyze complex systems, including those deployed in production at customer sites. Logging, tracing, and metrics are critical pieces of distributed systems, and you’ll get the chance to dig into them all.
Write code mostly in Rust, read code primarily written in Rust and C. The vast majority of code you write will be open source (maybe all of it!), across many different codebases.
Code without fear, working with the team to create and maintain continuous builds, tests, memory-safe code, debugging tools, a constructive code-review process, and a supportive culture of identifying and fixing bugs. Contribute to other, non-control plane areas of the product that interest you.
These responsibilities are just a starting place! We’re a small company, we don’t have rigid roles, and we have a lot to do — we can help you grow wherever your interests take you.
You will thrive in this role if you:
Have previously worked with Rust or another low-level systems language such as C.
Are energized by the thought of jumping between handling multi-machine fault tolerance, analyzing storage latency patterns, and bringing kernel drivers to life.
Believe in fully documenting your ideas.
Enjoy reading the documentation produced by others.
Get excited about a wide range of technical topics and dig really deep into them.
Are very comfortable at a Unix terminal.
Don’t mind coworkers getting really excited about decades-old computer front panels.
If you don’t meet 100% of these qualifications you should still seriously consider applying — at least one of us was missing each of these at the outset!
Life at Oxide
(Note: this section is presented for example purposes, the real one has links. Copy from an actual live job description instead of this example.)
We are very explicit about our values, and they can be seen in daily life at Oxide, for example:
Our rigor means we enjoy and take pride in the craft of engineering.
Our urgency means that we are not above the judicious short-cut.
Our versatility is reflected in our greatest strength: the breadth of our team.
Our transparency can be seen in our consensus-driven RFD process.
Our responsibility means that we both lead and follow: we have our own domains, but we also help others on their parts.
Our curiosity shows in our insatiable desire to learn — and our empathy in our love of teaching others.
Our humor is a big part of our daily lives: we are inveterate wise-crackers whose video meetings spill into simultaneous text chat.
Our values also manifest themselves in our benefits:
Everyone makes (the amount that is correct at the time), regardless of location.
We offer the best health insurance we could find: medical PPO plan, dental, and vision that are 100% covered for both employees and dependents.
We are very supportive of remote work. About half of our team is outside of the San Francisco Bay Area; our only requirement is working hours with a significant overlap with Pacific Time.
Our families and lives outside of our jobs are very important to us; our schedules are flexible to reflect and support that.