Hiring Software Developers

Fairly often? There are lots of things taught in comp sci classes you could have used for your example here, but traversing a tree is not one of them. Huge amounts of software will have something as basic as traversing a tree and if you can't remember how to do it even 20 years out of comp sci classes, I'm not sure you should be writing code anymore.

I'd think that refusing a candidate who can't work out how to traverse a tree in 5 minutes for an interview isn't a strong candidate for any coding position. At least I wouldn't hire someone who couldn't. (Give it a try if you doubt me, if you've done any amount of coding you should be able to work this one out very fast without ever stepping foot in a CS class, although you might have to spend 2 mins on Wikipedia first to see what a tree is)

I agree with the article though: best way to hire someone is to give them a trial run. However, most employable developers will laugh in your face if you ask them to come work for you as a trial run without pay. At least, I definitely would.

Paid 1 month trial of remote work is a good bet, but relies on your candidate not being employed already - and if they're any good, they are probably employed already. I guess you might catch freelancers though, but freelancers are not going to agree with the rest of the points in your post.

With more seasoned engineers, I mostly just ask about projects they've worked on before. The good engineers that have been a great fit with the team are the sort that (when prompted) get really excited when I ask about their previous projects. They go into great detail on cool hacks they made and challenges they were able to overcome. People that aren't a good fit usually give simple answers to direct questions. If I have to goad the developer along during the interview process, it's a non-starter.

And, to agree with some of the other commenters, none of the best engineers we've hired have ever been unemployed during our courtship phase. We make every effort to accommodate their work schedule, including having interviews during lunch time or in the evenings and weekends. Good developers are generally not out of work for very long, if at all. If a guy wants a job with us and isn't currently working, it's almost always a sign of some deeper problem.

Trees are very useful. Graphs are occasionally useful. But you can't really say what is useful until you know it. One of the sadder truths of education/learning.

You might be representing a graph with a tree however if your nodes are labeled and you want to talk about the shortest path between two nodes quotiented by those labels.