Meanwhile, during the act of writing code, I crib off existing code to remember how the hell method invocation looks in the current language I'm writing and similar important details. If I haven't touched a language in 3 months I very likely can't FizzBuzz without syntax errors or using the wrong function somewhere or whatever. I put Go on my résumé because I have written quite a bit of it, and can talk to someone fluently about the parts that are likely to seem odd to a newcomer and some of its strengths and weaknesses, but without some cramming ahead of time or a cheatsheet I probably can't demonstrate a bit of that in code. I'll likely mess up keyword order and all kinds of basic things just trying to "hello world".
In short: I've realized, later than I probably should have, I need to get the fuck out of development per se and into something that's still basically developing software since I'm actually pretty good at that, but doesn't judge me on whether I can, in the moment, recall what a print statement looks like in a language I was writing literally yesterday (it's entirely possible I'll blank on stuff like that!). In my defense I've been easily landing jobs doing this stuff since I was 15 so my blinders were, I feel, well justified—it'd just not occurred to me previously that I might shine better, at least in interviews, which is kinda important, by seeking roles a bit adjacent to development rather than in the thick of it, until I got mumble mumble years in the field and started to think about what I'll be doing when I'm, you know, not even sort of young anymore.
[EDIT] and yeah, of course I could put together Anki decks and do daily drills to get better at the parts I'm bad at and it'd certainly help, but another part of this series of mid-career revelations I've had is that if you find yourself wondering why other people are having trouble with something that's easy to you, that's what you should put your effort into, and conversely, if you can find some way to ignore the parts you find harder than most people seem to (not always possible and sometimes you just have to work on things you suck at, sure, talking about ideally) then you should do so, to free up more time for the easy-to-you-but-not-others stuff.
You might have seen the same thing, but any title that sounds managerial in some way - even if in the day to day work, it's completely meaningless - goes a long way toward jumping the line and convincing non-technical people involved in the process that you're a good bet.
Some indication that you have the soft skills and social skills to get along well with non-technical staff helps short circuit the whole thing, as well as convince the type of technical staff that put too much emphasis on coding challenge questions, etc., that they need to cool it and consider the whole candidate, not just a score on a quiz.