[RyanZAG]

> "Can you even remember when was the last time you had to write an algorithm to traverse a tree?"

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.

[jroseattle]

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.

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".

[okaram]

Would they be able to operate on folders and subfolders recursively ? That's tree traversal, and important for devops ... maybe you're talking about doing it in context vs out of context ? or your devops are mostly sysadmins ?

[jroseattle]

Certainly, and yes that is tree traversal, but we don't refer to it in that manner. We refer to this in the context of recursion and iteration. Our interview process for devops is focused much more on practical application.

Po-tay-toe, po-tah-toe I suppose.

[RyanZAG]

I think you've hit on the exact issue here: it's not that anybody disagrees that their coders they are hiring need to be able to do tree traversal. The issue is simply that we have given a complicated name for something very simple that every coder already understands. It's simply a communication issue.

[codex]

I think the source of the perennial confusion over this issue is that some software development is actually engineering, but most is greese monkeying. The software mechanics resent the engineering questions but the engineers can't understand how you could not ask them. In truth the work of both camps is fundamentally different.

[jared314]

> The software mechanics resent the engineering questions but the engineers can't understand how you could not ask them.

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.

[pandaman]

>Paid 1 month trial of remote work is a good bet, but relies on your candidate not being employed already

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?

[daniel-cussen]

For a month's income, and a much better shot at a job. In the context of the job search, that's a pretty good deal.

[pandaman]

Is it? I can only speak from my experience but I've never been in a situation where I had only one job offer after a couple weeks of search. Neither any of the candidates I'd been interviewing had that interview as their only option.

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.

[parallelist]

He says "traversing a tree to find the shortest path". Sounds an awful lot like he is confusing graphs and trees. You don't really tend to path find with trees. Am I right?

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.

[tel]

Definitely. In a (directed) tree there are exactly 0 or 1 paths between two nodes. There's no such thing as a shortest path. In an undirected tree there's exactly 1 path between any two nodes---even worse.

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.

[AYBABTME]

The shortest path in a tree is kind of a pleonasm.