How we hire engineers at DOSS (and why there's no coding test)

If you're an engineer preparing to interview with us, the best thing you can do is have deep technical discussions with your engineering friends in the lead up.

We haven't asked a software engineering candidate to write a line of code at any point in our process in a long time. No whiteboard, no live coding, no take-home. We used to have a take home challenge (open book, open AI, fully unrestricted), and we nixed it once we realized it wasn't telling us anything our behavioral interview didn't already cover, and it wasn't testing anything close to the actual job. I built the process this way, and it's held up.

We test four things, all evaluated through scenario-based conversation, not code:

1. Communication and collaboration. We enjoy working together in-person. Proximity only pays off if people can communicate with each other, debate ideas, and have a shared desire for the best ideas to win regardless of whose idea it is.
2. Pace and drive. How fast can you move a project or a team forward. This one’s a bit tricky in practice but we want to understand how you would approach specific scenarios and also anything from your past projects that would indicate to us your bias for action.
3. Technical judgment. Do you reach the right call more often than the wrong one, whether it's a quick decision or the shape of a whole system. We are not interested in whether "you know the textbook answer" - we aren’t sure if there is one anymore. Building technology is contextual, you have to make informed decisions that have differing trade offs.
4. BIDEC (break it down, communicate). Can you take something messy and turn it into smaller parts you can execute and explain.

Two reasons, one practical and one philosophical.

Practically: coding tests stopped adding signal once we built a strong behavioral first round with the hiring manager. That conversation already tells us whether someone's written real code, and it tells us more, because it also surfaces how they think, not just what they typed.

Philosophically: writing code with an AI agent is table stakes now. It's not a differentiator, and testing for it wastes everyone's time on something that doesn't predict performance here. The person who built Homebrew, one of the most widely used package managers in the world, got rejected by Google. He could clearly build and ship great things. He just hadn't drilled the specific pattern-matching a big tech interview loop tests for. That process measured the wrong thing. We built ours so it wouldn't repeat that mistake.

Scenario-driven questions with no fixed answer. Something like: "your website just crashed, walk me through how you'd debug it." Not a puzzle, just your actual job, described back to you, the kind of thing that happens on a random Tuesday at 2pm. Two people can answer completely differently and both do well, because we're watching how you reason, not whether you land on our answer key.

Compare that to a classic algorithms round: if you don't know the specific pattern (an AVL tree, say), you're stuck, and none of that gap reflects your ability to do the job. We think that model is testing the wrong thing, and it's part of why strong engineers who aren't actively interviewing sometimes bomb those rounds cold. Given a week to prep, they'd probably pass. We'd rather hire the version of you that doesn't need the week.

It also runs both ways. While we're figuring out how you think, you're figuring out how we think, whether the way we frame problems and push on your answers is a style you'd actually want to work inside every day. By the end, you should know us about as well as we know you.

This only works because we invest in it. Every candidate for a role gets the same scenarios, scored against the same rubric, by interviewers we've trained and calibrated to run open-ended conversations well. The rubric scores how you reason, not whether you land on a specific answer, so two very different approaches can both score well. If you're excited about the problems we're solving and you operate well day to day, that should be enough to get you through. If you'd need two weeks of algorithm drilling first, the mismatch is with that kind of process, not with you.