Oxide Interview Preparation: Written Materials, Work Samples, and Technical Conversations

Oxide is unusually explicit about how it wants to learn from a candidate's past work. Its public hiring RFD 3 describes written questions, work samples, and conversations built around materials rather than a generic promise to “show your skills.” The best preparation is therefore an evidence packet you can discuss honestly: what problem you faced, what decision you made, what changed, and what you would do differently. This article distinguishes Oxide's published process from my editorial preparation advice. I found no reliable independent, same-cycle candidate reports that would justify claiming a standard question list or exact interview sequence beyond Oxide's own material. Your current invitation and role description control the details.

To warm up on the kind of project explanation this preparation requires, try Explain a Project Problem That Required In-Depth Analysis. That is adjacent practice, not an Oxide-reported question.

Read the public process as a preparation brief

Oxide's RFD 3 says it asks candidates for materials that show their work, writing, and analysis, plus responses to eight written questions. The RFD specifies one to three work samples, one to three analysis samples, and no more than one writing sample per category; it also describes optional domain-specific samples. It describes reviewing materials before conversations. Interviewers may share some of their own past materials with candidates, and conversations vary rather than following a rigid quiz script. Oxide's careers page is the current entry point for roles and application instructions. These are first-party statements about Oxide's process; they are not promises that every applicant will have the same number of calls, interviewer mix, or timing.

The RFD discusses a substantial time commitment, generally around nine hours in three three-hour blocks. Treat that as the published approach described in the RFD, not an appointment already scheduled for you. A current recruiter message may specify a different arrangement. Plan calendar space and ask the recruiter about the format when invited; do not build a calendar from a public document alone. The RFD also points to further internal evaluation material that is not publicly readable. Do not claim to know its criteria because a link exists.

This is an important evidence boundary. A third-party company guide can summarize the RFD, but it cannot turn a public description into a verified account of what recent candidates experienced. The preparation below is a way to use the primary source without inventing insider knowledge.

Choose work samples that reveal a decision

My recommendation is to inventory work, writing, and analysis separately, then select the strongest permitted examples within the RFD's ranges and your current application instructions. A strong sample may be a design document, a code change with review history, an incident write-up, a technical article, or an analysis that changed a decision. Public GitHub code is useful only if you can explain the problem and your contribution. A large codebase with no clear ownership is harder to discuss than a small artifact that exposes a trade-off. Do not treat two examples from the same category as a substitute for a requested category.

For each sample, write a short cover note: context, your specific role, the decision you made, the alternatives you rejected, evidence you had at the time, observed outcome, and what you would change. Distinguish your work from a team's work. “We redesigned the storage layer” may be true but leaves your reasoning invisible. “I owned the failure-recovery design and wrote the first prototype; another engineer implemented the on-disk format” gives a reviewer a fairer starting point.

Sample	Claim you can defend	Evidence to show	Reflection to prepare
Design memo	I narrowed an ambiguous requirement to a testable interface.	Revisions, rejected alternatives, constraints, and decision record.	Which assumption would I test earlier now?
Code or review	I improved a failure path while preserving behavior.	Diff, tests, review discussion, and rollback consideration.	What hidden coupling did the change reveal?
Incident or analysis	I found a cause under incomplete evidence.	Timeline, measurements, hypothesis changes, and follow-up work.	Which signal was missing, and how would I add it?

The table is an editorial selection tool, not an Oxide scoring rubric. It helps you ask whether a reviewer can inspect the claimed contribution. If a sample contains employer confidential code, customer data, security details, or material you lack permission to share, do not upload it. Use a public artifact, a redacted explanation that has been cleared for sharing, or a fresh example built from your own knowledge. Redaction should preserve the decision logic without leaking the private implementation. If the only compelling work is confidential, tell the recruiter what you can discuss at a high level and ask what format they accept.

Prepare written answers that can sustain a conversation

Oxide's eight written questions are part of its published process, but the current application prompt is the authority for the exact wording. In the RFD, they ask about challenging work, proud work, the happiest and unhappiest professional periods, an Oxide value reflected in your work, a value violated in an organization or project, tension between two values, and why you want to work at Oxide. Prepare separate evidence for each; a single triumph story pasted into all eight responses will not answer the distinct prompts. Before writing, identify what each asks for: a technical judgment, a collaboration example, a motivation, or a reflection. Answer the question first, then supply one concrete event, the evidence available at the time, your action, and the result or uncertainty. A polished essay that avoids the question is less useful than a precise paragraph that a reviewer can probe.

I would draft each answer in two passes. In the first, write the unvarnished facts and mark every claim you cannot prove. In the second, remove background that does not help a reader understand the decision. Keep uncertainty where it is real. “The service improved because I rewrote the cache” is too strong if concurrency and traffic changed simultaneously. “Latency fell in our before/after measurements after the cache change, but we did not isolate it from the traffic shift” is more defensible. The goal is not to sound uncertain about everything; it is to know which claim the evidence supports.

Consider a weak versus stronger reflection. Weak: “The project was a success because I led the team and we shipped on time.” Stronger: “I proposed a staged migration because the old format could not be read by the new parser. We shipped the reader compatibility path first and monitored old-format reads for two weeks. I underestimated the operational documentation work, so the first on-call handoff required extra support.” The second gives an interviewer decisions, trade-offs, and a real learning point. These are original example sentences for preparation, not Oxide's preferred answers.

Turn each sample into a technical conversation map

Because Oxide says conversations can vary, prepare for depth rather than memorize a script. For each sample, draw four boxes: system context, hard decision, evidence, and second-order effect. In the context box, name scale, constraints, and what already existed. In the decision box, state at least one rejected option and why. In the evidence box, distinguish an observed measurement from a forecast or intuition. In the effect box, include operational consequences and what happened later. If you can speak to those boxes without reading your document, you can adapt to questions that approach the work from different directions.

Suppose your sample is a service failover design. An interviewer might ask why you chose a timeout, how you handled a partially completed write, what you did when the retry duplicated a request, or how you knew the recovery path worked. The map keeps you from jumping to a generic reliability slogan. You can explain the exact guarantee your design made and a failure it did not cover. If the interviewer changes a constraint, such as removing a durable queue, you can reason from your original trade-off rather than defend it as timeless.

The same method works for writing. If you submit an article, be ready to explain what you simplified for the reader and where that simplification stops being safe. If you submit an incident review, discuss which observations were direct, which were hypotheses, and which follow-up tests changed your view. The RFD's emphasis on writing and analysis makes these conversations plausible, but this exact mapping is my preparation exercise, not a claimed Oxide rubric.

Show collaboration without erasing your contribution

Technical conversations often expose a tension between “I” and “we.” Oxide's materials-oriented process gives you a chance to be accurate about both. Explain who framed the problem, who challenged the design, who built which parts, and who owned the final operational result. Acknowledging a colleague's better idea is evidence of collaboration, not weakness. Likewise, do not claim ownership of an entire release when you wrote only one component. The interviewers can ask deeper questions about the part you actually know.

Prepare one example where a review or user report changed your plan. Include your original hypothesis, the evidence that contradicted it, and the revised decision. This shows how you respond to technical disagreement. Avoid presenting every disagreement as a story in which you were ultimately proven right. A more useful answer can say that a teammate spotted a failure mode you missed and describe what you changed. That is especially valuable when the sample itself includes review comments or revision history.

If your work crosses hardware, operating systems, distributed systems, design, or documentation, do not force the same vocabulary on every interviewer. State the invariant problem in plain terms, then adjust depth based on their questions. You can ask what part of the sample they would like to examine. This is a normal collaborative conversation move, not a claim that Oxide mandates a particular presentation style.

Manage time, uncertainty, and current instructions

Before applying, inventory what can be shared. Pull your public writing links and code samples, confirm permissions, and choose examples that differ in what they show. When Oxide sends the actual written prompt, answer its wording rather than the remembered description of RFD 3. If invited to conversations, clarify scheduling, accessibility needs, and any format details directly with the recruiter. The RFD provides preparation context; an invitation provides operational instructions.

One rehearsal method is to give a trusted peer a sample and ask them to find three unsupported claims and two design decisions they cannot understand. Revise the cover note and written answers to close those gaps. Then rehearse questions about constraints you did not control: deadline, budget, hardware availability, or a team dependency. You should be able to say what evidence would change your mind. Stop rehearsing when you can explain the work without inventing precision or reading a memorized monologue.

Do not overread the public process. Oxide's RFD expresses a preference for substantive materials and conversations over trivia, but it does not guarantee that no one will ask you to reason through code or a technical problem. A candidate report from another year or another role would not establish your own schedule either. The strongest preparation is portable: know your work deeply, show its evidence, and ask for the current role's specific instructions.

Sources and further reading

• Oxide RFD 3: hiring process
• Oxide careers
• Oxide RFD index
• Oxide blog