How do I test my screen share before a meeting?

Start a meeting with nobody in it but you, begin a local recording, then share each source you plan to use for about thirty seconds each while doing real work in it. Stop the recording, end the call, and watch the file. The recording is the encoded stream, so it shows the compression, the crop, the lag and anything that leaked into frame.

Can I start a Zoom meeting with only myself to test screen sharing?

Yes. New Meeting in the Zoom desktop client opens a working meeting with one participant, and as host you can share and record in it. Google Meet does the same through Start an instant meeting, and Microsoft Teams through Meet now in the calendar. No invitees are needed and nobody is notified that the meeting happened.

How can I see what my screen share actually looks like to other people?

Watch a recording of the call rather than the small self preview in the client. The self preview is drawn on your own machine at your own resolution, so it flatters the share. A recording written by the meeting client is much closer to what the other side received, including compression artefacts and dropped frames.

How do I test screen sharing if my account cannot record the meeting?

Join the same meeting a second time from your phone and record with the phone's built in screen recorder. Mute the microphone and the speaker on both devices first, or the two ends will howl. The phone tile shows the received stream, which is the honest test, and the video stays on your phone.

What should I look for when I watch the playback?

Shrink the player to about a quarter of your screen and check that code is still readable. Then look for notification toasts, taskbar badges, bookmark bars and file paths in title bars, black rectangles where a window failed to capture, frozen frames when you switched away, and how far the picture lags your cursor.

Should I share my entire screen or a single window in an interview?

A single window or browser tab leaks far less, since notifications, other windows and your taskbar never enter the frame. Entire screen is easier when you need to move between an editor, a terminal and a browser. Whichever you choose, rehearse that exact mode, because they fail in different ways.

How to Test Screen Share Before a Meeting: A Solo Rehearsal

Start a meeting with nobody in it but you, record it locally, share each source you plan to use for about thirty seconds each, then end the call and watch the file. The recording is written from the call rather than grabbed off your monitor, so it carries the compression, the crop, the lag and every accidental leak in the same shape the interviewer would have seen them. The whole drill takes five minutes, and you only repeat it when your setup changes.

Why the self preview is not the test

Every meeting client gives you a little thumbnail of your own share. It is drawn locally, at your resolution, on the machine that already has the pixels, and it looks fine almost no matter what you do. The stream that leaves your machine has been scaled, compressed and rate limited on the way out. Those are the two things that go wrong in an interview: text that was crisp on your 27 inch monitor turns to mush in a tile, and a fast scroll arrives as three smeared frames.

A recording made by the meeting client sits much closer to the truth. It also does something a live preview never will. It lets you watch yourself work without having to work, which is the only way you will notice the notification toast that sat in frame for four seconds while you were busy reading a problem statement.

The drill, start to finish

Open a meeting with one participant

In the Zoom desktop client, New Meeting. In Google Meet, New meeting then Start an instant meeting. In Microsoft Teams, Meet now from the calendar. All three run perfectly happily with one person in them, nobody is invited, and nobody is told. Join with computer audio so the audio path is real too.

Put the meeting window where it will really be

If the call will sit on your laptop panel while you code on an external monitor, set that up now. Half of what this drill catches is geometry: a window straddling two displays, a cropped ultrawide, meeting controls parked over the line you are typing on.

Start recording before you share

In Zoom, Record on the toolbar, or Alt+R on Windows, then choose the option that saves to this computer. Zoom writes to a folder under Documents by default and converts the file when the meeting ends. Teams recordings land in OneDrive or SharePoint and depend on your tenant policy. Meet recording is a paid Google Workspace feature and is simply absent on a personal account, so if the button is not there, use the phone method further down rather than hunting for it.

Share each source in turn, and use it

Entire screen, then the specific application window, then the single browser tab. Thirty seconds each, and do the real thing in each one: scroll a long file, type a line of code, run a command, open the whiteboard. Idle screens hide every problem worth finding. If your interview involves an editor and a browser, share the pairing you will actually use, not a tidy version of it.

Do the transitions on purpose

Alt+Tab away from a shared window and count to five. Open a file dialog. Switch browser tabs. Stop the share and start a different one. These moments are where the stream misbehaves, and they never show up in a test where you sit still and admire your own desktop.

Stop, end, and watch it as the interviewer

Stop the recording, leave the meeting, wait for the file, open it, and shrink the player to roughly a quarter of your screen. That is close to the tile an interviewer gets while they also have their notes and a scorecard open. Watch it through once without touching anything, then go down the checklist below.

What to look for in the playback

Work down this list once. Most setups fail two or three items on the first pass and none on the second.

Legibility at quarter size. Can you read your editor at that player size? If you cannot, nobody else can either. Raise the editor font a few points and the terminal font with it. A light background with heavy text usually survives compression better than a dark theme with thin strokes.
Black rectangles. Some windows come back as a black or empty box under window capture, particularly terminals, video players, PDF viewers and anything leaning on hardware acceleration or protected content. If a window is black in the playback, change that application rendering setting or share the whole display instead.
The frozen last frame. Look at what the recording shows while you were alt tabbed away from a shared window. Depending on the platform you get a held still image or a blank panel, and from the far side neither is distinguishable from a crashed call. The fix is a sentence, not a setting: say out loud when you are leaving the shared window.
Cursor and lag. Find a moment where you clicked something and count how long the picture took to respond. That gap is why interviewers ask you to scroll back up. Scroll in short bursts with a pause between them, and point at things by selecting them rather than by waving the mouse.
Leaks in frame. Notification toasts carrying sender names, unread badges in the taskbar, a bookmarks bar, tab titles, the Recent list in an open dialog, a title bar showing another company project path. Each of these is a two second flash in real time and a permanent frame in a recording.
Crop and aspect. An ultrawide or an unusually tall display gets letterboxed into the viewer tile, which shrinks your text further than the quarter size test suggested. If your monitor is an odd shape, share a window rather than the display.
Audio. Is your voice level and clear over your own keyboard? Did system sound go out when you did not intend it, or fail to go out when you did? Clients treat the share sound checkbox differently between share modes, so confirm it in the mode you will really use.
The re-share moment. When you stopped one share and started another, did the source picker itself land in the stream, complete with thumbnails of everything else you had open? On an entire screen share it usually does.

Which source to share, and how each one fails

	Entire screen	Application window	Browser tab
What the viewer receives	Everything on that one display, live	Only that window surface	Only that tab content area
Typical leak	Toasts, taskbar, wallpaper, other windows	Its own title bar and file path	Very little outside the page itself
When you switch away	The viewer follows you everywhere	Held frame or blank until you return	Usually keeps sending while you work elsewhere
Moving between applications	Seamless	Stop and re-share	Stop and re-share
Main failure mode	Something private enters the frame	Black box or frozen frame	Forgetting it is still live
So rehearse	Do Not Disturb on, desktop cleared	That it captures at all	That you notice when it stops

For a coding round, window sharing your editor is usually the calmest choice, with the caveat that you have to prove it does not come back black. For anything where you move between a spec, a terminal and a browser, share the display and spend the effort you saved on clearing it first.

If you cannot record the meeting

Plenty of accounts cannot, and the workaround is better than it sounds. Join your own meeting a second time from your phone, then record on the phone with its built in screen recorder. You are now watching the received stream rather than a local copy of your own desktop, which is the honest test, and the file never leaves your pocket.

Mute the microphone and the speaker on both devices before that second join, or the two ends will feed back and you will learn nothing except how loud your laptop is.

Recording your own desktop with OBS or a system recorder is a different test with a different answer. It shows what is on your screen, at full quality, with no compression and no crop. That is useful for checking whether a notification appears or whether something is visible to you, and useless for checking what the interviewer receives. Do not let one stand in for the other.

Where this drill stops helping

It tells you about your machine and your network at that moment. It says nothing about the interviewer bandwidth, their monitor, or whether their client downscales your share further on a bad connection. A share that reads perfectly in your test can still arrive soft at the far end, which is why the habit of asking "tell me if that is too small" is worth more than any setting on this page.

Since this question often arrives attached to our own product, here is the plain version. The OfferPilot AI overlay is excluded from screen capture at the operating system level, so it does not appear in a Zoom, Teams, Meet or OBS share, or in screenshots, while staying visible on your own monitor, and that holds on every plan including the free one. This drill is exactly how you should check that claim rather than taking our word for it: run the solo meeting, share every source, watch the playback. What capture exclusion does not do is just as plain. It has no effect on a webcam, on a person sitting in the room with you, on a lockdown browser, on eye tracking, or on a second device pointed at your desk. For a proctored assessment it is the wrong tool, and we would rather say so. It is also Windows 10 and 11 only, so if you are testing a share on a Mac, none of that paragraph applies to you. The free tier on the pricing page needs no card if you want to run the check yourself.

The short version

Solo meeting, local recording, every source in turn. The recording is the only view of your share that is not flattering you.
Test the transitions, not the still frames. Alt tabbing, re-sharing and file dialogs are where it breaks.
Watch it small. A quarter size player is roughly the tile your interviewer has beside their notes.
No recording available? Second join from your phone, both ends muted, phone screen recorder.

Run it once tonight, fix the two or three things it finds, and screen sharing stops being something you think about while an interview is happening.

How to test screen share before a meeting