The point is to hire people who mastered skills different than what you have. You see interest in text editing as a major factor, but there are probably many software engineers who have no interest in text editing and just writes stuff manually with no focus on tricks, and are still very productive since really writing 100 lines of code is just a few minutes of typing but still plenty for a days worth of work.
> The point is to hire people who mastered skills different than what you have.
That's the job of the other engineers. I only know how to screen for the skills I do have.
Most engineers spend all day in their text editor and on Google, debugging code and searching for solutions.
I have never met a good craftsman that doesn't customize their tools.
I'm not saying everyone has to customize their editor. But if you move quickly and intuitively through the chrome debugger, the only way you got that skill was by doing it every day for way too many hours.
Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.
> That's the job of the other engineers. I only know how to screen for the skills I do have.
But to strengthen a team you want to add people who have skills the other people in the team lacks, so your interview needs to be able to find such people easily.
In general you want the interview to test that they have done the basics of the work before, that they are smart and that they are nice. Your test helps assert the first, they have done the work before, and the discussion tells you whether they are nice. But it doesn't tell you whether they are smart. And if you think a bit there are probably simpler questions you can ask to check they have done the work that are more general and will pass more people, you want to sort by intelligence and not passion for text editing so the "have they programmed before" question should be as low level as possible and not require any special skills.
The algorithm interview is what the industry settled on to solve this. It tests extremely trivial coding, so you can do the coding if you have ever coded before. The hard part is the algorithms, and that might require some to study, but since it is standardized that becomes a reasonable proxy for intelligence. And social comes from being able to talk about a technical problem and describe what you are doing in a stressful situation, that is good enough to work on a team.
> Also, you can learn a lot about how senior someone is by watching how fast they can parse out search results and SO answers.
This is true, but you don't need to customize anything for that. VSCode text search gets you 99% there.
> I have never met a good craftsman that doesn't customize their tools.
To the contrary, personally I even take some pride I can work on any PC you can possibly give me immediately. This has tons of upsides - from helping someone walking over to them, to knowing tools in their default configurations inside out and explaining keybindings or quirks that are guaranteed to work (and writing better docs).
Programming really isn't about my personality, I want to strip any of that and produce the least amount of very default, simple code anyone can work with. And you don't need to type fast or use scripts to produce that small amount of code.
Largely same goes for debugging, I better create a good logging and monitoring system than spend time tweaking my tools, because that'll immensely benefit the person who maintains the code after I'm gone. Nobody will install my personal tweaks to catch bugs. Granted I mostly work with very good tooling already (C#).
I customize my shell and tools all day. Editor? Not so much, CUA FTW. In fact had to think five minutes before I remembered my snippets. They’ve been in git for 5-10 years.
