Earlier quoted context omitted.
For advanced roles I'd suggest separating out the evaluation of coding ability from the evaluation of a particular language. Let the candidate pick their language when you want to test how well they can write new code, and then do a separate evaluation of how deep they are on the language and technical stack you are using.
I agree with the sentiment. Honestly we don't check for syntax or even require the code to compile. We let the candidate write puesdo code which usally isn't super far python and javascript implementations of our challenge. We try to pay attention to the types of questions the candidates asks about context of the code and choices they make in designing a solution. That being said i'd be curious how you evaluate gener…
Are they (me in this case) going down rabbit holes? Are they painting a clear picture? Are they communicating that picture? Are they suggesting edge cases? Are they minimizing bloat? Is it too complicated? What are the most important aspects of the design in their eyes? Can they argue for them? Do they understand where a piece fits and if not, do they understand that something has to go there? Can you both step back and definitely outline a logical flow?
There's not always one solution, but the approach counts.
Lower level is logical problem solving.
Can they reason the problem space? Do they start naively? Can they iterate? Can they optimize? Can they explain each of these steps for future iteration? Do you understand what they're writing? Would you work on that code yourself?
There's not always one solution here either, but 90% is getting a naive solution that can be optimized by taking a second look. I feel that the naive should be found in 5-15 minutes and you can spend the rest of the time talking about how to optimize.
I know I'm rehashing what you probably already know, but at a certain point interviewers are just playing games.
If you've found someone you want to work with who can also reason about problems in a timeframe you see fit, well... that to me looks like gold.
I like these questions because that's how real systems are going to be built.
Take-homes are great, but there is just so much effort wasted in the process if the product can't be understood.