It's probably different at bigger companies, but at the small-medium businesses I've worked with, Typescript was just something everyone struggled with and everyone collaborated on, and it wasn't used as any sort of gate-keeping. Sometimes the juniors would get lucky and figure out a typing that the staff dev couldn't, and sometimes we'd all shrug and go "eh, just // @ts-ignore and TODO it... not worth wasting any more time on". It's meant to be a tool to help developers and teammates, not restrict them, and most of the time it's not very different than using JSDoc comments.
Typescript is very much an 80/20 tool, as in 80% of it is very easy to learn (literally just telling the IDE "this var must be a string" or "this object must have these keys and these value types"). For your average codebase, those are generally the more useful parts of it, and that part only takes a few hours to learn. Yes, there's that 20% of it that's harder to wrap your head around, but that constitutes very little of day-to-day work in my experience.
Where it gets complicated is if you end up needing to write library code for re-use, especially external re-use. Then generics etc come into play and the syntax becomes less readable, e.g. https://github.com/googol/DefinitelyTyped/blob/6836f798cb186...
But you can totally get by with a weekend of self-teaching, maybe a demo project or two – find your favorite old single-purpose NPM package and rewrite it in Typescript – and then learn on the job. Go through a few tutorials and produce some workable sample repos and then just be honest that it's something you picked up later in your career while you were focused on more bigger-picture things, but this repo demonstrates the basics, and you spent extra time focusing on _____ and _____ (whatever you found complex or struggled with).
IMHO only, but if a senior is wasting their time creating super-detailed typedefs for everything, something is wrong with the team/project organization. There are much bigger fish to fry, like architecture, async, state sharing, UX, readability, code review & QA processes, etc. And even among the nitty-gritty, there's much more complicated nuances to tackle, like how Next.js caching works in different routing and async models, when/how to best use SVG/Canvas/WebGL/WebGPU/Web Workers/WASM. Nobody is going to sweat an unfinished typedef here or there, and sometimes a simple but well-written comment can be a lot more useful than just a technically "correct" typedef that the juniors can't even read.
All the roles say Typescript because that's just what everyone uses now, just like destructuring or other ES6 features are taken for granted. But Typescript doesn't make a break a senior (or any dev), IMO, it's just something to learn and use as appropriate, to the extent appropriate for any given team or project. ChatGPT is also increasingly good at it and can save hours of manual definitions (but always double-check its output, as usual).
Sorry, not a direct answer to your question since I'm not a hiring manager, but just echoing what others have said... it's really not that big a deal. I've never been quizzed on Typescript specifically, and the teams I've been on would routinely simplify (dumb down) types when we refactor code, just to save time. It's not meant to be an exercise in code prowess, just another documentation & write-time testing tool.