What I Actually Changed About Engineering Interviews Over Zoom

| 4 min read |
interviewing hiring remote-work engineering

Whiteboard coding over Zoom is broken. Here's what I do instead when hiring engineers virtually.

Last month I watched a senior backend candidate freeze for forty-five seconds on a Zoom call. Not because of the problem. Because CoderPad lagged, ate half his code, and he didn’t know if I could see his screen. By the time we sorted it out, his headspace was gone. We ended the session early and I felt like an idiot for not testing the tool beforehand.

That was week three of Decloud. We were hiring our first engineers and doing it fully remote from day one. Not because we were visionary. Because it was May 2020 and there was no other option.

Since then I’ve run maybe fifty virtual interviews across Decloud and the fintech startup. I’ve gotten some things very wrong and a few things right. Here’s what actually matters.

Whiteboard coding over Zoom is broken

I’ll die on this hill. Asking someone to solve an algorithm on a shared whiteboard tool while you watch through a webcam is a terrible experience for everyone involved. The candidate can’t think naturally. You can’t read their body language. The tool always has some lag or quirk. And what are you even measuring? Their ability to perform under artificial pressure on a laggy canvas?

I stopped doing it. Completely.

Instead I send a small take-home problem. Two to three hours of real work, a week to finish it. Then the live session is a code review of their submission. We walk through their decisions, I push on trade-offs, they refactor something live. This tells me ten times more than watching someone implement a linked list reversal on Miro.

The setup matters more than you think

The single biggest variable in virtual interview quality isn’t the questions. It’s whether the tech works. Sounds obvious. Almost nobody actually prepares for it.

My checklist before every interview block:

  • Open the shared editor, paste something, delete it. Confirm it works on both sides.
  • Test screen sharing. Every. Single. Time.
  • Have a phone number or Telegram handle ready as backup. Zoom dies more often than people admit.
  • Close Slack, email, everything. Notifications popping up during someone’s interview is disrespectful.

I also send candidates a prep email 48 hours out. Not a corporate template. A short note that says: here’s the Zoom link, here’s what we’ll cover, here’s the editor we’ll use, install nothing, and if anything breaks just message me on this number. People visibly relax when they know the logistics.

Keep it short

An hour-long virtual interview is thirty minutes of good signal and thirty minutes of diminishing returns. I cap everything at 45 minutes. The first five are small talk and tech check. The last five are their questions. That leaves 35 minutes of actual interview. Plenty.

If you need more depth for a senior role, split it into two sessions on different days. Two focused 45-minute conversations beat one draining 90-minute marathon.

What I look for changed too

On-site, you get all these ambient signals. How someone walks into the office. How they interact with the receptionist. Whether they ask good questions during the tour. That’s all gone now.

So I leaned harder into things I can actually observe on a call:

Communication under ambiguity. I intentionally leave parts of the problem vague and see how they handle it. Do they ask? Do they assume? Do they state their assumptions clearly?

Debugging live. During the code review session, I’ll point at something and say “this will break if X happens.” Watching someone debug in real time, talking through their reasoning, is the most reliable signal I’ve found for engineering skill.

Written communication. I added a short async component. After the take-home, before the live call, I ask candidates to write a paragraph or two about one decision they made and why. At a remote company, writing isn’t optional. If someone can’t explain a technical choice in a few sentences, that’s a problem.

The bias trap

One thing that caught me off guard: I started unconsciously judging people’s home setups. Nice bookshelf, good lighting, quality microphone — must be a serious person. Messy background, laptop mic, kids in the next room — less so.

This is garbage thinking and I had to actively catch myself. Someone’s apartment has zero correlation with their engineering ability. We made it a rule: cameras optional, background irrelevant, connection issues get a reschedule with no questions asked.

What I’d tell you to do

If you’re setting up virtual interviews for the first time, do three things:

  1. Kill the live whiteboard coding. Replace it with take-home plus code review. Your signal will improve overnight.
  2. Test your tools before every single session. Not once. Every time.
  3. Make the process shorter than you think it needs to be. Respect people’s energy.

Virtual interviewing isn’t a downgrade. It’s a different format. Once I stopped trying to replicate the on-site experience over Zoom and started designing for the medium, the quality of our hires went up. Not down.