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.
I've been in the tech (software) industry over 25 years now, nearly all of those years here in Silicon Valley. Worked in everything from 3 person startups to the largest of enterprises.
I feel good about saying I've never made a bad hire (meaning: I've never come to regret saying "hire", everyone I have given the thumbs up after an interview has turned out to be a fine contributor).
I don't ask candidates to code, I don't ask them to come up with whiteboard architectures out of the blue or any of these silly artificial techniques that don't measure anything relevant.
Here's what I do: I carefully read their resume. I have a conversation about the projects they have worked on. I encourage them to talk about what jobs/projects/tasks they liked and disliked and why. What they found easy vs. hard and why. And what they want to work on next and why.
That's it. Works extremely well.
I wish everyone would try it. You'll find it is very easy to pick out those who padded their resume. You can't actually have a meaningful conversation about what you loved and hated about working on foo if you didn't do it.
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.