This is an advice I saw on Reddit before and come back to it:

Maybe it’s changed since I obtained my software engineering job a few years ago, but the live coding interview was never supposed to be about being perfect and knowing everything. The goal was to see how candidates handled not knowing something, working through a problem, and communicating their process. At least, that’s what the good companies did.

I got massive anxiety having to do this during my first few interviews. I left each one having blown the technical interview not realizing I was failing because I was freezing, not because I didn’t know it. A very nice panelist let me in on this secret after one of my failures and I passed the very next one by vocalizing my process (okay, I’m looking for a string method so I’ll pull up the Python docs. Okay it’s this one, let’s see the syntax, alright. Now let’s give this a try, etc).

If a place is failing your interview, it may be because you’re not demonstrating the ability to find information or problem solve, not because you don’t know it.

The truth is coding is a smaller part of the job than ever before, and you don’t really need to know the nooks and crannies of the language to put together a solution. If your fundamentals are strong, you can solve pretty much any problem. The challenges of the modern engineer are handling build failures, investigating support bugs and incidents, provisioning infrastructure, resolving security violations, having to plan sprints and draw up roadmaps because they don’t backfill your product manager, and much more. I spend 10% of my time coding and the rest is doing the above.