Write a TypeScript async/await function that requests webcam access and handles errors
This tests async/await error handling for getUserMedia and stream attachment. A good answer uses try/catch, sets video.srcObject, and branches on NotAllowedError and NotFoundError. A red flag is omitting catch or using src instead of srcObject.
What's really being asked
This question evaluates whether you can integrate a modern permission-based Web API into TypeScript using async/await, correctly attach a live MediaStream to a video element, and reason about specific failure modes rather than treating all errors the same. Interviewers care that you understand getUserMedia returns a Promise that resolves to a MediaStream, that it runs only in secure contexts such as HTTPS or localhost, and that different DOMExceptions signal different root causes that affect user messaging and fallback logic.
The full answer
First, verify navigator.mediaDevices exists to avoid runtime errors in unsupported environments or older browsers. Second, define an async function that awaits navigator.mediaDevices.getUserMedia with a constraints object such as { video: true }, remembering that both video and audio default to false so omitting them causes rejection. Third, on success, assign the resolved MediaStream to the video element's srcObject property, then call play if needed, because srcObject accepts the stream directly whereas src expects a string URL. Fourth, wrap the await in a try/catch block and branch on error names: NotAllowedError means the user denied permission or the system blocked it, NotFoundError means no matching camera is available, AbortError means permission was granted but a problem prevented device use, and InvalidStateError means the document is not fully active. Fifth, note that the promise might never settle if the user dismisses the prompt without choosing, so consider a timeout or cancellation strategy for production code.
The mistakes people make
Using video.src instead of video.srcObject is a classic mistake because src expects a string URL, not a MediaStream object. Another red flag is omitting try/catch entirely and letting an unhandled promise rejection crash the application or leave the UI in a loading state forever. Many candidates also forget to mention secure context requirements or conflate all errors into a single generic message, missing the chance to show they understand the difference between user denial and missing hardware. Failing to stop tracks when the video component unmounts is another subtle sign of inexperience.
What usually comes next
How would you stop the stream when the component unmounts or the user navigates away? What happens if the user ignores the permission prompt and the promise never settles? How do you apply specific video constraints like resolution, frame rate, or facing mode? Can you request both audio and video simultaneously, and how does the error behavior change if only one track is missing? How would you handle multiple cameras or switch inputs on mobile devices?
A concrete example
Imagine a React useEffect hook inside a video chat component. You call getUserMedia inside an async immediately invoked function, set videoRef.current.srcObject to the returned stream, and return a cleanup function that iterates over stream.getTracks and calls each track.stop to release the hardware. If the user clicks deny, you catch NotAllowedError and show a localized UI message explaining that camera access is required for the feature, while logging the specific error name for debugging.
Interview question
Which approach correctly uses async/await to request webcam access and handle specific failure modes in TypeScript?
- a.Omit try/catch and assign the resolved MediaStream directly to video.srcObject
- b.Wrap the call in try/catch but treat every error with a single generic message
- c.Assign the resolved stream to video.src and wrap the call in a try/catch block
- d.Use try/catch, assign the stream to video.srcObject, and branch on specific DOMException namesCorrect
Why? this is the answer
The correct approach assigns the MediaStream to srcObject rather than src, because src expects a string URL, and branches on specific DOMException names to distinguish user denial from missing hardware. The most tempting distractor includes try/catch but uses src, which prevents the video element from rendering the live stream.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
- #typescript
- #webrtc
- #async-await
- #dom-api
- #error-handling
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on typescript — each one lists the topics its interview covers.
See open roles