I am often on the other side interviewing the candidates for company I work for. For junior positions we do ask them to write some simple code e.g. matching parentheses or the like. It makes it very clear how much experience writing code given candidate has - typing speed, how they move around source file, even if they can seamlessly copy paste their code, etc., are all very telling.
For nearly 2 decades, vi(m) (or a vim emulator or integration layer) has been my daily editor.
I recently had an interview where I had to use some remote collaborative web application and it was genuinely a horrible experience. The main interviewer (lead for the team I was applying for) was visibly annoyed with me because, for whatever stupid reason, some of the keyboard shortcuts he kept trying to bark at me, as I was working through some truly asinine leetcode-style questions, for things like block indentation were not working on my end and I had to manually tab multiple lines, etc...
The entire editing experience threw me really hard and was so distracting that I was fumbling what would've otherwise been trivial algorithm questions for me. Despite my 15 years of professional experience and a deep understanding of their tech stack (which, of course, was not a main discussion point at any stage of my interview process -- one of many red flags for me), if you had watched this you'd have thought I barely know how to write code.
I don't know what the answer is here but I have decided, and thankfully I have the privilege of making this decision, that I am done interviewing for a while.
> how they move around source file, even if they can seamlessly copy paste their code, etc., are all very telling.
This reminds me of the test for cooks. Make them slice up some fruit or vegetable. If you have worked in kitchens for years, you can do it really quickly. Fast and easy test, and nothing to prepare weeks or months for.
