I see this attitude all the time. It's usually from people who don't know anything about basic data structures like trees. How would you know that they don't apply?

It does apply. GUIs are fundamentally tree structures. Relational databases are fundamentally tree structures. JSON documents are fundamentally tree structures. Almost everything you're touching in a CRUD app is some kind of tree and you think knowing how to work with trees has "very, very little to do" with writing them? Again, how would you know?

I'm so serious that not knowing how to invert a binary tree is ludicrously bad. It's just a swap operation. You walk the tree and you swap the left and right branches of every branch you find. That's it. It's not black magic.

    invert(tree):
      if(tree not null):
        temp := tree.left
        tree.left <- tree.right
        tree.right <- temp
        invert(tree.left)
        invert(tree.right)

That's why it's used as an interview question. It's not meant to be a test of skill. It's a shiboleth. It's one of the easiest ways to quickly answer, "is this the sort of 'programmer' who is likely to import a whole package for padding strings with spaces?"

>It's one of the easiest ways to quickly answer, "is this the sort of 'programmer' who is likely to import a whole package for padding strings with spaces?"

But that's the sort of programmer who gets hired, because SOP for Javascript development (and oftentimes elsewhere) is to import the existing library, and any developer who insists on writing that code themselves would be considered a code cowboy wasting company time and resources, and likely writing less safe code in the process.

> How would you know that they don't apply?

Because implementing low level algorithms like that is almost never an issue for application programming in modern languages, for which robust libraries for such operations exist and are data agnostic.

Unless you are using Go, pretty much the only modern popular language that both features static typing and lacks generics, so that kind of algorithm re-implementation task might make some sense for screening application programmers using Go.

> Because implementing low level algorithms like that is almost never an issue for application programming in modern languages

Except it is. You spend a lot of time traversing nested tree-structured data, validating it, sorting it, filtering it. If you can't do the simple inversion operation you have no hope with the more complicated stuff.

You usually have a structure that is already tree-like and need to write custom code to walk over it. If you're taking a tree-like thing and first extracting it to another tree structure just to do basic tree operations, then you're already performing tree-traversal and just wasting a lot of time, disk, CPU, and memory just to bundle every person-under-the-sun's tree structure needs into one place.

> you're taking a tree-like thing and first extracting it to another tree structure just to do basic tree operations,

Why would you do that? The whole point of libraries of generic operations is that you can apply them to thing you have without copying.

So who writes the libraries? It certainly isn't people who can't manipulate tree structures.