What We Learned Hiring 33 Engineers in Two Weeks | DigitalOcean

Log in<br>Sign up

© 2026 DigitalOcean, LLC.Sitemap.

Dark mode is coming soon.<br>Culture<br>What We Learned Hiring 33 Engineers in Two Weeks

By Janet Harrah

Published: June 9, 2026<br>7 min read

Back to blog home

Earlier this year, we needed to hire a cohort of engineers in Seattle, fast. We had a product launching at our marquee conference, Deploy, a hard deadline, and a clear picture of what the work would actually require. What we didn’t want was an interview process designed for a world that no longer exists.

So we rebuilt it from scratch and opened a brand-new office in Bellevue for everyone we hired. Here’s what we did, why we did it, and what we heard from the engineers who went through it.

The problem with the standard loop

The traditional engineering interview loop (recruiter screen, hiring manager screen, technical phone screen, take-home, onsite) was designed for a different era of software development. It tests for pattern recognition and syntax recall. It stages information rather than creating genuine signal. And it takes weeks.

More importantly, it doesn’t reflect how engineers actually work today. Production environments are collaborative. Most engineers entering the field right now have been working with AI tools since they were in school, not reluctantly adopting them, but building with them naturally. A hand-implemented sorting algorithm on a whiteboard tells you almost nothing about how someone thinks through a real system.

We wanted an interview that did.

What we changed

We made the work the interview.

The centerpiece of our on-site was a three-hour build session. Candidates chose from a short list of assigned prompts and were asked to design, build, and deploy a working prototype on DigitalOcean by the end of the session. They could use whatever AI tools they wanted: Claude Code, Codex, ours, whatever they were fastest with.

Three hours is the minimum window in which you can actually watch someone make real engineering decisions: what to scaffold versus what to write by hand, how they prompt, what they verify versus what they trust, how they handle the moment when the AI confidently produces something that doesn’t work. That moment always comes.

We shifted from hiring niche specialists to sourcing strong, well-rounded software development engineers. We weren’t evaluating whether candidates could produce code. We assumed that. We were evaluating whether they had the judgment to productionize an idea.

Shivani Shirolkar, one of the engineers we hired for our model catalog team, had never been in an AI-assisted interview. She prepared by using Cursor to work through sample problems herself. “I ended up creating a spec for myself that I could feed into Cursor during the interview,” she said. “For the first three hours, it was just heads-down building. They gave us the space to fully focus, which made it so much more engaging than a typical technical interview.”

We followed the build with a real conversation.

After the coding session, candidates walked interviewers through what they’d built: design choices, trade-offs, and what they’d do differently with more time. Then the conversation went further, into hypotheticals about scaling, business constraints, what it would look like if traffic spiked, and there were windows of downtime to work with.

Eric Daniel, now on our serverless inference team, found that the discussion after the build was where he could really show his thinking. “I was able to explain the architectural decisions I’d made and why they’d make future improvements easier to build on,” he said. “Then the conversation shifted into territory I’d never covered in an interview before: product trade-offs, business constraints, how the system would behave under real-world pressure. That’s the kind of problem-solving I actually do every day.”

That’s exactly the kind of thinking we were looking for.

We cut the steps that weren’t adding signals.

For candidates with directly relevant backgrounds, we removed the recruiter and hiring manager screens from the loop. For candidates with strong but adjacent experience, the technical assessment was enough to qualify them for the on-site without a separate call.

Every step we removed was either duplicating something we already knew or generating information we weren’t going to use. Redundant steps don’t just slow things down; they signal to candidates that the process wasn’t designed thoughtfully.

We made decisions the same day.

At the end of each interview day, the full panel (recruiters, hiring managers, technical program managers, and engineering leadership) debriefed all of the candidates together. Because we had aligned on decision criteria and pre-approved compensation bands ahead of time, we could move the moment we found the right fit.

Our fastest offers went out the next morning. Both Eric and Shivani had offers within 24 hours of their interviews, and both...