A remote technical interview works when it is one extended problem, started from working code, with a third of the time spent probing what the candidate just wrote. That structure produces a stronger signal than a blank-page algorithm exercise, and it is far harder to pass with an assistant answering in a side window, because comprehension of code on screen does not transfer from a tool the way a solution does.
Two things sit outside the interview itself: a tool policy the candidate reads before the call, and a way to tell whether the session followed it. Neither is solved by recording the screen, since anything drawn outside the shared surface never reaches the recording.
Pick the format before you write a question
Four formats dominate remote technical hiring. They measure different things, and the common mistake is using the cheapest one for the highest-stakes decision.
| Format | What it measures well | Where it fails | Use it for |
|---|---|---|---|
| Live pairing on real code | Judgement, debugging, how someone works with another person | Needs a prepared repo and an interviewer who can actually pair | The decision-making round |
| Live problem in a shared editor | Reasoning under mild pressure, communication while thinking | Drifts into trivia if the problem is a puzzle | The main technical screen |
| System or architecture discussion | Trade-off thinking, seniority, failure-mode awareness | Rewards confident talkers over careful ones | Senior and staff rounds |
| Automated coding assessment | Filtering very high volume cheaply | Weakest verification of the four, and easily outsourced | Top-of-funnel only, never the decision |
A take-home is fine as an optional alternative for candidates who interview badly live, but it should be under two hours, related to the job, and followed by a live conversation about their own submission. That follow-up is the part that carries the signal. Without it you are grading an artifact of unknown authorship.
A sixty-minute structure you can reuse
Same shape every time, so candidates are comparable and interviewers stop improvising. The two blocks in the middle are where the actual decision gets made.
| Time | Block | What you are doing |
|---|---|---|
| Before, T-2 days | Setup note | Format, duration, language or stack, whether docs and AI tools are allowed, and what is monitored. Every dispute later traces back to something missing here. |
| 0 to 5 min | Warm-up | Audio, screen share and editor check. One easy question about something on their CV, so they are talking before they are thinking hard. |
| 5 to 35 min | One core problem | A single problem they extend from a working state. Not four unrelated puzzles. You are watching decisions, not typing speed. |
| 35 to 45 min | Probe their own code | Why this structure, what breaks at ten times the input, what would you delete. This block is the hardest to fake and the most predictive. |
| 45 to 55 min | Change a requirement | Add a constraint that invalidates part of their design. Watching someone adapt beats watching someone finish. |
| 55 to 60 min | Their questions, then score | Five minutes for them. Then fill the scorecard immediately, before you speak to another interviewer. |
Start from working code rather than an empty file. A repository with two functions and a failing test tells you more in thirty minutes than a blank buffer does in sixty, it mirrors the actual job, and it removes the blank-page panic that penalises good engineers who happen to interview badly.
Questions that still work when the candidate has help
Assume every question you ask may be answered by an assistant in a side window. Some questions survive that and some do not, and the difference is whether the answer depends on context only present in the room.
These survive
- Walk me through the function you just wrote, line by line
- Why this data structure and not the obvious alternative?
- What breaks first if the input is a thousand times larger?
- Which part of this would you delete, and what would you lose?
- Here is a new constraint. What changes in your design?
- This test now fails. Talk me through finding out why
- Tell me about a decision in your last job you would now reverse
These do not
- Any published algorithm puzzle with a canonical solution
- Syntax and API recall questions
- Definition questions: what is a closure, what is a deadlock
- Write this well-known function from scratch, no context
- Anything with a single correct answer and no follow-up
- Brain teasers unrelated to the work
The left column is also the fairer set, which is the useful part: questions that resist outside help are questions about the candidate's own reasoning, and those are the ones that predict whether someone can do the job. See the technical interview integrity checklist for a printable version.
Score the same four things every time
Remote rounds drift towards vibes faster than onsite ones, because there is less shared context and the panel debriefs in text hours later. Fixed dimensions, written down within ten minutes of the call, are the fix.
One practical note on the second row: a candidate producing correct code they cannot explain is the single most common pattern worth pausing on. It is not proof of anything by itself, and there are honest explanations, but it is the point at which you slow down and ask more about the code that is already on screen. If you use an ATS with scorecards, keep these four dimensions on the card so every interviewer fills the same form.
Knowing the work on screen was theirs
Remote interviewing adds one problem no amount of question design removes: you can see a shared window, and nothing else. Not the second display, not the phone below the camera, not the person off screen, not the overlay drawn on top of everything.
What screen sharing cannot show you
- An answer overlay excluded from the shared surface
- A second monitor with a chat assistant open
- A remote-control session driven by someone else
- A virtual camera replaying pre-recorded video
- A phone or tablet outside the camera frame
- A local model running with no network trace
What signals actually catch it
- Hidden overlay windows present but excluded from capture
- Known AI assistant processes and interview-specific tools
- Remote control and proxy sessions during the round
- Additional displays connected mid-interview
- Virtual cameras and microphones
- Typing and paste patterns inconsistent with authoring
Two rules make this fair rather than adversarial. State it in the invitation, in plain language, so consent is informed and given before the call rather than clicked under pressure at the start of it. And treat the output as evidence for a human decision, not a verdict: signals are collected, weighted and reported, then an interviewer decides. InterviewWatch runs on the candidate's machine for the length of the round, records no screen, audio or video, and returns a signed, timestamped report with an integrity score. The consent language guide has wording you can paste into an invitation.
Seven ways remote technical interviews go wrong
Ordered by how often they show up, not how bad they are.
| Mistake | Why it costs you | Fix |
|---|---|---|
| Tool policy stated verbally at the start | Honest candidates self-limit, others do not, and the result is not comparable | Put it in the invitation, two days ahead, in writing |
| Four small puzzles instead of one problem | Measures recall of published solutions, which is exactly what transfers from an assistant | One problem, extended, started from working code |
| No time spent on the code they wrote | Skips the block with the highest signal and the lowest fakeability | Reserve a third of the round for probing |
| Silent interviewer taking notes | Candidate cannot calibrate, and you learn nothing about collaboration | Talk. Pair. Disagree with them and see what happens |
| Scoring written up hours later | Memory reshapes itself around the first impression | Fill the scorecard within ten minutes, before any debrief |
| Ninety-plus minute marathon rounds | Measures stamina, and your own attention has already gone | Sixty minutes, or two shorter rounds on different dimensions |
| Screen recording treated as verification | Anything drawn outside the shared surface never appears in it | Signal-based monitoring on decision-making rounds |
Remote technical interviewing: frequently asked questions
What is a remote technical interview?
How do you interview technical candidates remotely?
Are remote technical interviews as good as onsite?
How do you stop cheating in a remote technical interview?
Should candidates be allowed to use AI tools?
How long should a remote technical interview be?
What tools do you need to run one?
What should you avoid?
Know the round was theirs
Signal-based monitoring for live remote interviews, with a signed report on the candidate record. No screen, audio or video recording. First five interviews free.
Start free How monitoring works