This, absolutely this! I did a lot of interviews (as interviewer) at a non-fang-but-close-enough, the guideline was to tell interviewees to pick the language they most prefer. Even if we didn't know it, the valuable part was the problem solving, and the candidate could display good communication skills by explaining the language features you were not familiar with. This is much better than picking a language that you don't know (happened several times that someone picked python, and when asked to write a class said "I know how to write classes in java". We switched to java, no problem.)

Python is beneficial in that everyone understands or can learn to understand basic Python in the time it takes to do an interview.

However, due to the whiteboard and performance focused aspect of the typical coding interview, Python is actually kinda an awful language to interview with. Plus, if you want to be terse with Python (whiteboard space is limited after all), it quickly becomes alphabet soup.

If I had to describe the perfect interviewing language, it'd be something with C/Java-like syntax, but without the cruft, that can optionally be typed, with easy fine grain control over looping. All the big-tech companies work with way too much Java, but Java is way too verbose for coding by hand. C# is about as close to Java as they come. Scala/Kotlin is excellent if you write it like Java.

O(n) is O(n) in any language. And how does Python become alphabet soup?

It took me 1 second to think that Python has divmod built-in whereas you must import Math in C# to use DivRem. It's just little things like that - as well as boilerplate - that really makes a difference in these interviews. How many of these interviews resulted in a job offer? I disagree with eyelid-batting being the new success metric.

I feel that you think of the interviews as if they were a competitive programming contest.

If I needed a DivRem function I'd just write it in, `import Math` optional. In fact I probably wouldn't remember the exact name of the function and would've just 'created' a new one: `Tuple<int, int> DivideWithRemainder(int dividend, int divisor)`. You can just write signatures for functions like that on a separate side of the whiteboard and invite your interviewer to tell you if they want to see any of them implemented.

I would advice this as a general approach -- split things into (reasonable) parts and implement them in order of importance. In one interview (Amazon) I ended up implementing every small thing I parceled out. In others my interviewers seemed to appreciate that we both care a lot about the `solution flow` and the `technically hard` parts and not at all about `DivideWithRemainder` or `import Math`.

I got offers from most of the places that I interviewed at.