Evaluate software engineering candidates the same way virtually every other skilled profession on the planet evaluates their candidates: through a series of conversational interviews that involve technical communication about their skills and past experiences, and perhaps some version of “sample work” that ideally should just come from GitHub, school project, Stack Overflow answers, etc., and only be based on some take-home (with tons of time to complete it) in the rare cases the candidate doesn’t have any samples they want to discuss with you.
I don’t understand why people keep overthinking it and believing you need any type of timed testing aspect at all.
Through many years of leading engineer hiring for my teams, a simple conversational style has helped me successfully hire effective software engineers much, much more than traditional software tests.
Imagine asking a plumber, lawyer, or tax accountant to solve a pipe problem, law problem, or accounting problem in ~40 minutes while you watch over their shoulder and iteratively add complicating details, while telling them to use some foreign interface they never use for their own work and confusing them by saying you don’t care about syntactical correctness and just want high level communication to “see how they think,” despite the very nature of the problem being rooted in sweating micro details about correctness.