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.
I've found this sort of generic statement ignores the practical aspects of a hiring decision. Maybe we need to qualify the definition of 'coding position', but I'm thinking of my entire devops team. I'm pretty sure I'd get some sideways looks if I asked many of them how they would implement tree traversal. And my devops team kicks ass. I don't know that a filter on tree traversal helps me in hiring more people for that team.
In keeping with the article, what we really care about is whether someone can be productive and learning how they are productive. It's not uncommon to find a disconnect between computer-science competence and acceptable developer output. I've watched candidates execute whiteboard graph traversal & shortest-path exercises quite well, but their actual code output is just silly. We're still working on finding the right way to detect that ideal mix of "smart and gets things done".
Po-tay-toe, po-tah-toe I suppose.
The "software mechanics" resent an engineering question being used as a hurdle for a job they know does not involve "engineering". While the employers are looking for a "software engineer" at a "software mechanic" price.
Most importantly it relies on the candidate not having any other options. Why would anybody interrupt their job search for a month just for a possibility to fill your vacancy?
It could be a way to go if you are hiring in a small town with no competition and the prospective candidates value not having to move much more than possible better offers elsewhere. Same if the candidates are not able to get many offers and appreciate the value of just a good shot for one.
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.
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.
Or (gasp) not having a GitHub account at all.
Chances are, if you're a full-time software engineer, you're already spending a significant chunk of your waking life thinking about\working on code, just by showing up to work for >= 40 hours per week. Whatever happened to well-rounded employees?
I remember doing a task-based interview once, getting an offer, and having it retracted after I asked to meet with the team before accepting (they just moved on to another developer who would accept without meeting the team first). This was a reputable, respected small company. Clearly, task-based interviews let them determine who was competent and who wasn't, but I was the only one who was invested in the interview process.
Payment helps and it's great to see some companies pay for project interview that aren't even directly related to their technical needs. The company invests money and the candidate invests time.
Why do these companies not just give you a computer and an editor, hell, even one with code completion enabled, and let you solve the problem that way?
I agree completely with this article. I have not once needed to write an algorithm to traverse a graph, or find the shortest path, etc. I have RARELY ever needed to implement a common data structure myself. That's what libraries are for. People that write library code wouldn't be able to properly write these data structures in the allotted interview time. It makes very little sense.
Something else to note. Traveling from one coast to the other for interviews almost certainly has a mental cost. I have noticed it personally, that the jet lag reduces my concentration and ability to process.
I'd be interested to see statistics on what percentage of hires were actually successful when coming from the same coast vs the opposite coast.
No one is going to address the fact that there is only ONE possible path to a node in a tree? This guy seems to have no idea what he's talking about, no wonder he dislikes algorithmic questions. Instant no-hire.