How to run a remote technical interview

A remote technical interview is trying to answer one question: would this person be good at the job? Most of them instead answer a different question — how does this person perform while being watched by a stranger through a webcam under time pressure with no internet access — and then treat the answer as if it were the first one.

The gap is mostly caused by the format rather than the questions. This guide is about the format.

Decide what you are measuring before anything else

Write down, in one sentence, what a pass looks like. If you cannot, the interview will default to measuring similarity to yourself, which feels like judgement and is not.

Reasonable things to measure, and the fact that they conflict:

• Can they write working code? Surprisingly worth checking, and cheaply checked.
• Can they work with an unfamiliar codebase? Closer to the actual job than anything involving a blank file, and rarely tested.
• Can they debug something they did not write? The highest-frequency real activity in most engineering roles.
• Can they explain a decision and change their mind? What determines whether working with them is pleasant.

You cannot assess all of these in 45 minutes. Pick one, maybe two. An interview that tries to cover everything covers nothing and mostly rewards people who have practised interviews recently — which correlates with having been unemployed, not with being good.

Set the environment up before they arrive

The first ten minutes of a badly run remote interview are spent on logistics: sharing a link, installing something, finding the right tab, working out why the code is not appearing. That is twenty per cent of your time, spent while the candidate is most nervous.

Eliminate it entirely.

• Send the link in the calendar invite, so it is where they will look for it, not in an email from four days ago.
• Use something that opens in a browser with no account. Any sign-up wall is a chance for the interview to start with the candidate creating a password. It also puts them at a disadvantage if they have never used the tool, and that disadvantage is pure noise in your measurement.
• Put the problem in the document in advance, with any scaffolding, sample data, or starter code already there. Have them read it while you do introductions.
• Open the link yourself ten minutes early and confirm it works.

A shared editor beats a screen share here for a specific reason: both people can type. When the candidate gets stuck on a typo, you can fix it in a second instead of dictating a correction out loud while they hunt for the line — a genuinely humiliating experience that also burns your time. It also means you can drop in a hint, a test case, or a clarifying example as text rather than as a spoken sentence they have to hold in memory.

Structure a 45-minute session

Keep it boring and predictable, and tell them the shape up front.

Announcing the structure costs thirty seconds and measurably calms people down, because uncertainty about the format is a large fraction of interview anxiety and none of it is information you want.

How to behave while they work

This is where interviews are usually lost, by the interviewer.

Say that thinking out loud is optional. The convention of demanding continuous narration selects for people who can talk and think simultaneously, which is a real skill and not the one you are hiring for. Plenty of excellent engineers go quiet when concentrating. Ask instead for occasional checkpoints: “tell me where you are every few minutes”.

Let them look things up. Method signatures are not knowledge. If your process penalises reaching for documentation, it penalises exactly the behaviour you want on the job. Say explicitly at the start that searching is fine — otherwise they will assume it is not, and waste minutes trying to recall an argument order.

Intervene early on the wrong path. Watching someone spend fifteen minutes on an approach that cannot work is not a test of resilience, it is a waste of your only session with them. If they are stuck for more than two or three minutes, nudge. What you learn from how they take a hint — do they understand it, integrate it, push back on it — is more informative than watching them flounder.

Write down what happens as it happens. Memory reorganises an interview around its ending within about an hour. Keep notes in a separate document — not in the shared one, for obvious reasons.

Do not multitask. They can tell. Someone visibly reading email during your interview tells the candidate exactly how much the company values their time, and good candidates have other options.

What to avoid

Whiteboard-style algorithm puzzles as a remote default. Their defenders argue they measure raw ability. What they mostly measure is recent practice on a specific corpus of puzzle problems, which is available to people with time to grind and unavailable to people with jobs and children. There are question shapes with far better signal.

Silent surveillance. Some tools offer tab-switch detection, keystroke playback, and webcam monitoring. Aside from the ethics, they change what you are measuring: a candidate who knows they are being watched for suspicious behaviour is now spending cognitive budget on appearing innocent. If you do not trust the process enough to run it without surveillance, fix the process.

Unpaid multi-day take-homes. A two-hour take-home is reasonable. A “build this app over the weekend” filters for people with free weekends, which is a demographic filter dressed as a technical one.

Trick questions. Anything with a single non-obvious insight produces a binary outcome that says nothing about the ninety per cent of candidates who did not happen to see it.

Afterwards

Write your assessment within the hour, against the criterion you set at the start, before you hear anyone else’s view. Debriefs converge on whoever speaks first, and independently recorded judgements are the only defence.

Keep the artefact. The code they wrote, and the session it was written in, is the evidence for whatever you conclude. “Weak coding” with no code attached is not a reviewable judgement.

Reply either way, quickly. Silence after an interview is the most common complaint candidates have about the industry, and it is free to fix. A rejection sent in two days is remembered better than an offer sent in three weeks.

For the mechanics of running the session itself, the techniques that make remote pairing work transfer almost directly — an interview is a pairing session with worse power dynamics, and most of what makes pairing effective makes interviewing more accurate.