Test the complete setup you will use for the interview: your computer, headphones, meeting application and the sharing mode you expect to use. A microphone permission switch only shows that access is allowed. It does not show that the right microphone is selected, that meeting audio reaches an assistant, or that the other person sees the intended window.
This checklist separates sound, transcription and screen sharing to help you identify a problem and choose the next step. The browser limits are checked against the MDN screen-capture reference; permission steps link to the relevant vendor guidance below.
Write down the actual call setup
Before changing settings, identify where the conversation will run. A browser meeting, a desktop meeting app and a call on another phone have different audio paths. The fact that you can hear all three does not mean one capture method can read all three.
Use a small setup record and update it whenever equipment changes.
Computer and operating system
[Model and version]
Meeting application
[Browser tab or desktop app; browser/app version]
Microphone
[Selected device; physical mute switch]
Meeting sound
[Where the other person's sound plays]
Headphones or speakers
[Device used during the actual interview]
Screen sharing
[Tab, application window or entire display]If you expect to switch from a browser call to a desktop application during the interview, test both routes beforehand. A backup that has never been opened is still an untested setup.
Separate what each check can prove
|
Check |
A useful result |
What remains unproven |
|---|---|---|
|
OS or site permission |
Access is allowed for the correct application/site |
The selected source contains the intended sound |
|
Microphone meter |
Your voice reaches that input |
The other person's audio is captured |
|
Meeting-source meter |
That source contains audio |
Every spoken term is transcribed correctly |
|
Transcript test |
The test phrase appears with reasonable accuracy |
Future questions will all be recognised correctly |
|
Receiving-device screen check |
The other device sees the intended shared picture |
A different sharing mode has the same result |
This avoids a common dead end: repeatedly changing permissions when the permission works and the selected source is simply wrong.
Run a one-speaker-at-a-time sound test
Use a partner or a second device. Put on the headphones you plan to wear. If the second device is in the same room, prevent its speaker from feeding directly into your microphone.
First, speak while the partner is silent and check the microphone input. Then stop speaking and ask the partner to say a sentence; check the meeting input. Swap again. You want to know which source responds to which sound.
If both sources react strongly to the partner, inspect speaker leakage and source selection. Distinguishing microphone from meeting audio is not voice identification. Two interviewers in one meeting source are still on the same audio path.
Without a partner, playing a short clip in the selected meeting tab can check whether audio arrives. It does not reproduce every part of the live call, so repeat the check with the actual meeting when possible. The OfferWoo audio guide provides source-specific recovery steps.
When the screen is shared but meeting audio is missing
A browser can provide a video track without an audio track. Availability depends on the browser, operating system and selected source, as described in MDN's capture documentation. Selecting a screen is therefore not sufficient evidence that sound was included.
For a browser-tab workflow, select the actual meeting tab and include tab audio in the chooser. If the application reports no shared audio, stop that source and choose again. Check that the tab is producing sound and is not the wrong meeting, a waiting room or a silent presentation tab.
For a call in a desktop application, check the capture support for your exact environment. Do not assume instructions for a Chrome tab apply to an entire desktop or to another browser. If you use a desktop assistant, check its release requirements and test that route separately.
Check transcription accuracy
Once sound is present, test a short phrase containing a name, a technical term and a number. Compare the captured words with what was actually said. The aim is to find a failure you can fix before a consequential conversation, not to calculate a recognition score from one sentence.
A moving meter during OfferWoo's local preflight does not send audio for transcription or start paid usage. A started test interview does use the normal interview flow and time. End the test when done. Do not describe a full transcription test as a free local sound check.
If a technical term is wrong, clarify the question and check the related cue before repeating it. A fluent suggestion can still be based on a misheard word. Keep essential names and verified project details in your preparation notes.
Inspect the shared picture from another device
Use the receiving device to view the exact tab, window or display being shared. Open the windows you will actually need, move between them as you expect to during the interview, and inspect the received picture again.
A full-display share can include a cue window, notifications or a private document. A compact window is a layout choice, not a universal exclusion mechanism. Sharing one application window and sharing an entire display are different tests. Taking a screenshot inside an assistant is also different from broadcasting your display through the meeting app.
Close unrelated private content before the check. If the wrong material is visible, stop sharing and select the intended source. Follow the interview organiser's policy on assistance and permitted notes; a visibility test does not determine what tools are allowed.
Common audio problems and fixes
|
Symptom |
First action |
If it persists |
|---|---|---|
|
You cannot hear the meeting at all |
Check the meeting's speaker output and system volume |
Confirm the meeting itself plays before changing the assistant |
|
You hear it, but the assistant does not |
Check selected source and shared-audio option |
Re-select and test that source |
|
Your voice is missing |
Check device and physical mute |
Check site and OS microphone permissions |
|
Speech is duplicated |
Check whether speakers feed the microphone |
Use headphones and repeat the isolated source test |
|
Sound stops after reconnecting a headset |
Inspect the newly selected device |
Re-select the affected input before resuming |
|
Both meters move but no text arrives |
Check started/paused state and connection message |
Follow the service recovery path rather than changing every permission |
For Chrome, consult its microphone permission instructions. For macOS screen and system audio, use Apple's permission guide. When using a website, the browser may need OS permission as well as the site permission. Check the application named in the prompt.
Finish the test and prepare a fallback
Find pause and end before the real interview. End the test, wait for saving when a session was started, then check the saved record. Keep a short, permitted set of your own project notes available in case the network or assistance stops responding.
A useful fallback is an action you have already tried: re-selecting one source, continuing from your notes, or contacting the interviewer if the meeting itself fails. Avoid making several device and permission changes at once; you will not know which change helped.
Record any remaining problem with the time, environment, exact error and failed source. Remove personal conversation content from screenshots before contacting support. Your next preparation task can then focus on the interview itself, such as a clear project explanation or practising follow-up answers.