Fixing one-way interview technical issues starts with your invite link

A one-way interview candidate can have a brand new phone, full signal, and still never see a camera permission prompt. Not because anything is wrong with their phone. Because of which app they tapped the link from.

You’ve probably chalked this up to candidate flakiness. Someone starts your one-way interview, gets stuck on the camera step, and never finishes. You write it off: they weren’t that interested, or their phone is old, or people are just bad at this now.

It’s an easy story, and it’s usually wrong. Most one-way interview technical issues trace back to a handoff problem, not a person problem.

The actual cause is almost always upstream of the candidate. It’s the channel that delivered the link, not the person who clicked it. Once you see the mechanism, the “some candidates just don’t work out” explanation stops holding up, and a specific, fixable problem takes its place.

The “they just didn’t want to do it” explanation doesn’t hold up

Here’s the pattern once you start watching for it. The candidates who stall out on your one-way interview aren’t a random cross-section. They cluster by how they found the link, not by how serious they seem.

The pattern that gives it away

A candidate who filled out three fields on your careers page, uploaded a resume, and wrote you a real note is not, on paper, a flaky candidate. But if they tapped your Position Link from inside a job board’s app instead of a browser, they can hit the exact same wall as someone who never meant to apply at all. Same effort up to that point. Same failure after it.

That’s the tell. If drop-off were really about who is and isn’t a serious candidate, it would track with the quality signals you already have (a complete profile, a real resume, answered qualification questions). Instead it tracks with something else entirely: where the link was opened.

What recruiters already sense but don’t name

Recruiters notice this without always naming it. In conversations we have with hiring teams evaluating screening tools, “it’s not supported on all browsers” comes up as a specific reason they left a previous vendor, not a vague complaint about candidate quality. That’s a recruiter describing a technical failure and calling it a candidate problem, because nobody ever showed them the difference.

What a phantom device problem actually costs you

If you’re hiring for one role at a time, every stalled candidate is someone you actually wanted to see, not a statistic you can shrug off.

One stuck camera step, in a real campaign

Say you’re running a single opening (a front-desk role, a coordinator, a service tech) and you post the Position Link across your job board listing, your careers page, and a follow-up text to anyone who calls in. Forty people start the interview. If eight stall out at the camera step and you assume they weren’t serious, you’ve quietly written off a fifth of your pipeline based on a guess.

The cost compounds in a specific way for a small hiring team. You don’t have a recruiter running fifteen reqs who can shrug off a bad week of drop-off. You have one role open and a shortlist you need by Friday. Every candidate who gets stuck on a permission prompt they can’t clear is one fewer real option you get to see, and you’ll never know it happened unless you go looking.

Why the number you’d trust doesn’t catch it

It also pollutes the number you’d normally trust to catch this. Application completion rate tells you how many people who started, finished. It doesn’t tell you why they didn’t. A recruiter staring at a 60 percent completion rate has no way to tell “candidates lost interest” apart from “candidates hit a wall they had no way to get past,” and those two stories call for completely different fixes.

Why the same link works once and fails the next time

Here’s the mechanism, plainly. When a candidate taps a link inside LinkedIn, Indeed, Facebook, or a text-message preview, most of those apps don’t hand the page to the phone’s real browser. They open it inside their own built-in browser, a stripped-down version of Safari or Chrome running inside the app itself, often called an in-app browser or webview.

That in-app browser looks almost identical to the real thing. Same address bar, same page rendering. But it doesn’t always support the same permissions.

Camera and microphone access on a phone has to be granted through a specific request, and in-app browsers have a long, well-documented history of handling that request differently than a full browser does, sometimes refusing it outright, sometimes showing no prompt at all. It’s a known, long-documented limitation of how in-app browsers are built. Developers have filed the same complaint about it for years, across a long list of different apps.

This is a different failure mode than the accessibility barriers that come up in making one-way interviews usable for candidates with disabilities, screen readers, captions, flexible timing. Those are solvable with design choices on the interview itself. This one is solvable further upstream, before the interview even loads.

Practically, that means three things can go wrong before your candidate ever gets a fair shot:

The in-app browser blocks the camera silently

The candidate taps “allow camera access” and nothing happens, or the permission prompt never appears at all. From their side, it looks like the interview is just broken. From your side, it looks like they gave up.

The browser itself is old or unsupported

A small number of candidates are still on genuinely outdated phones or browsers that don’t support modern video recording in a browser at all. This is the smallest slice of the problem, but it’s the one most troubleshooting guides focus on exclusively, because it’s the only piece that’s the candidate’s own device.

The session doesn’t survive a candidate leaving mid-way

A candidate starts on their phone, gets a call, backgrounds the app, and comes back ten minutes later to find the interview won’t resume. That’s not always a bug either. Truffle’s one-sitting policy requires candidates to complete a screening interview in one continuous sitting, by design, so that every candidate answers under the same conditions instead of researching answers between questions.

The tradeoff is real: a candidate who navigates away can land on a dead end instead of picking back up where they left off. If that happens because of a genuine technical issue rather than someone stepping away, support can reset the interview so they get a fair second attempt.

None of these three are the candidate deciding they don’t want the position. All three look identical from the outside: a candidate who started and never finished.

You can’t pick the candidate’s app, but you can pick where the link lands

The honest objection here is real. You don’t control which app a candidate uses to open a link, and you’re not going to start policing that. Some candidates will always tap straight from a job board notification or a group text.

What actually is yours to control

That’s true, and it’s also not the part you needed to control. What you control is how the link gets shared in the first place, and a platform that behaves the same way no matter where the candidate lands.

Three habits and one platform choice

A few things are worth doing regardless of what tool you use. When you share your interview link over text or in a message, add a short line telling candidates to open it in their regular browser rather than tapping straight through. When you post it on a job board or social platform, know that a meaningful share of clicks will come through that platform’s in-app browser whether you ask or not, so the tool behind the link needs to hold up on its own.

And when a candidate reports a stuck camera, ask what app they opened the link from before you assume anything about them. That one question tells you more than a support ticket usually will.

The bigger lever is the platform itself. If the interview tool only works reliably in one or two browsers, you’re handing every candidate a coin flip based on how they happened to click. If it’s built to work the same way across browsers and doesn’t require installing anything first, the in-app browser problem shrinks to the cases where the app itself blocks camera access outright, which a well-designed camera check catches before the interview even starts. It’s the same logic behind designing any automated step of the process well: automation only helps candidate experience when the mechanics behind it actually hold up.

What this looks like when the link is built to survive the handoff

Take that same forty-candidate opening. The Position Link goes out the same three ways: job board, careers page, a text to anyone who calls the front desk. Nothing about your posting habits changes.

The same campaign, a different platform underneath it

The difference is what happens after someone taps it. Truffle’s video screening flow runs a mic and camera check before a single question loads, so a candidate finds out immediately whether their setup works instead of discovering it mid-interview. It’s built to work directly in the browser, no app to install, and across the major browsers rather than just one, which is the specific gap recruiters have told us they hit with other tools that don’t support Safari or work inconsistently on mobile.

That doesn’t erase the in-app browser problem entirely. Nothing can force LinkedIn’s built-in browser to behave like Safari. But it does mean the failure shows up right away, as a clear camera check, instead of as a candidate who silently vanished twenty minutes later.

What changes for you as the recruiter

Of the forty who start, most finish. The ones who don’t are visible at the exact moment they get stuck, not three days later as an unexplained gap in your funnel. You can see, in the moment, that it’s a device or browser issue rather than a candidate who changed their mind, because the platform tells the candidate what to fix instead of leaving them staring at a frozen screen.

That distinction matters more than it sounds. A recruiter who can tell “stuck on tech” apart from “lost interest” makes a different decision about who to follow up with. One of those candidates is worth a second invite. The other genuinely isn’t, and you’d rather know which is which than guess.

What a stuck candidate is actually telling you

Once you’ve seen the mechanism, you can’t unsee it. A candidate stuck on a one-way interview is a data point: which app they used, which browser that app opened, and whether your interview tool was built to handle it.

That reframe changes what you do with a completion rate that looks lower than you’d like. Instead of assuming the number reflects candidate quality, you start asking where in the funnel people are getting stuck and why. Sometimes the answer really is that candidates weren’t a fit. Increasingly, the answer is a permission prompt that never had a chance to appear.

Truffle is a candidate screening platform that combines resume screening, one-way video interviews, and talent assessments, built cross-browser so a candidate’s device or the app they clicked from doesn’t quietly decide who gets to finish. If you’re setting up your first one-way interview campaign, start with the one-way video interview software built to survive however the link actually gets clicked, then layer in resume screening or talent assessments if you want more signal before you ever get on a call.

Frequently asked questions about one-way interview technical issues

Why does my one-way interview link work sometimes and not other times for the same candidate?

The most common reason is where the link was opened. A tap from inside an app like LinkedIn, Indeed, or a text-message preview opens the link in that app’s built-in browser, which can handle camera and microphone permissions differently than the phone’s actual browser. Ask the candidate whether they opened it from an app or a browser before assuming a device problem.

What should I do if a candidate says their camera won’t work during a video interview?

Ask them to open the link directly in Safari (iPhone) or Chrome (Android) instead of tapping it from inside another app, since that’s the single most common fix. If they’re already in a regular browser, check that the site has permission to access the camera in the browser’s settings, and confirm no other app or tab is already using the camera.

Can a candidate finish a one-way interview on a tablet?

Generally yes, as long as they’re using a supported browser directly rather than an app’s built-in browser. The same in-app browser limitations that affect phones apply to tablets, so the same fix (open the link in the regular browser) usually resolves it.

Why did my candidate get an error saying their application or interview couldn’t be found?

This usually happens when a candidate navigates away mid-interview and tries to resume later. Most one-way interview platforms, including Truffle, require candidates to complete a screening interview in one sitting rather than saving progress and returning, so the process is consistent across every candidate. If a candidate hit this because of a real technical issue rather than stepping away, ask your platform’s support team to reset the interview so they can try again.