Do you remember all the time in college where your professor explained the intricacies of cache hits, access latencies, and branch prediction when going over algorithms?

As it turns out, designing a fast algorithm involves a lot more than what is covered in the textbooks. This is why something like Timsort can generally outperform quicksort even though a naive algorithms course overview may well come to the opposite conclusion.

If my job is not to design these algorithms, why does it matter if I can write a naive implementation of one?

Kind of a coincidence that you should bring that up since several jobs I've been at involved stints analyzing performance and identifying bottlenecks in existing code and it is, unfortunately, rather easy to glue together even well designed libraries in ways that result in a slow, inefficient result. Developers simply cannot get away with not knowing how their tools and libraries work under the hood.

Choosing the correct algorithm is a different question from implementing the correct algorithm.

Sounds like the state of CS education should be improved to fill in those gaps of knowledge.

It matters because "algorithm" is just another word for "program". The question is whether you can think up a way to make the computer do what you want it to do at all at the level after FizzBuzz, even when it's something like reversing a linked list that can be done in two lines of code (see https://news.ycombinator.com/item?id=30616573, or seven in C), even when it doesn't need to be fast.

I mean, it's true that there's a lot of code that really is at the FizzBuzz level:

    switch (c) {
    case 'h': case 'D': menu.left(); break;
    case 'j': case 'B': menu.down(); break;
    case 'k': case 'A': menu.up(); break;
    case 'l': case 'C': menu.right(); break;
    default: /* no op */ break;
    }

    def find(self, name):
        for thing in self.contents:
            if thing.is_a(name):
                return thing

    vaders.hits(bullets, (vader, bullet) => {
        blam(vader, 2.5)
        score += vader.bounty
        vader.die()
        bullet.die()
    })

    if (vaders.where(({y}) => y > 400).count()) startGame(120)
    if (!vaders.count()) startLevel()

And I think you should write as much of your code as possible in such a painfully obvious way. Every once in a while, though, you do need to write something that can't be written quite that simply. Often, the reason why is something in your problem domain:

    async def take_token(self):
        self.update()
        while not self.tokens:
            await asyncio.sleep(self.recharge / 10)
            self.update()
        self.tokens -= 1

    // Animate explosions.
    poof.move()
    poof.each(p => {if (--p.ttl < 0) p.die()})
    // Chain-reaction explosions.
    poof.about_every(64).each(p => {
        if (poof.count() < 1024) blam(p, p.w/12)
    })
    // Limit number of explosion objects to guarantee responsivity
    if (poof.count() > 1024) poof.about_every(2).die()

You need to be able to reason through what your code will do once you've written it, and you need to be able to come up with possible ways to write it that might work. Often the code you need for your problem domain isn't already in the standard library, so you have to write it. If it's on npm, you have to be able to read it to see whether it might work.

Reversing a linked list is just about the simplest task that requires that kind of reasoning, and it has the advantage (or disadvantage) that understanding the puzzle doesn't require, or benefit from, any problem-domain knowledge. You could substitute binary search or insertion sort or something. Another example I got, which takes a few more lines of code, was "implement an integer stack ADT which can always tell you the maximum number on the stack in constant time".

I've held several senior developer positions and I'd have to study up on how to reverse a linked list. (Other than the obvious answer: "use a library/built-in function to do it", which would probably would not be a satisfactory answer.)

I think the problem is that there are over a dozen different kinds of "seniority" but we collapse them all into one term. I got so frustrated I wrote a blog post about it: https://www.mooreds.com/wordpress/archives/2812

It might depend on what the measure of "senior developer" is. There are junior-developer positions where nobody could perform adequately without being comfortable manipulate linked data structures (Linux kernel development, maybe, or working on a garbage collector or JIT compiler or the Postgres query optimizer) but senior developers on those teams probably don't know a tenth of what you know about SQL.

Also there are ancillary skills that make the problem much less difficult, so if you can't solve it, you don't have them. Joel Spolsky famously said that nobody can reverse a linked list without drawing diagrams on paper, and that's probably true if you're doing it imperatively in C. But it's in the category of "problems that become much simpler with functional styles of programming." The following took me 5 minutes, most of which was struggling with the syntax of OCaml that I'd forgotten:

    $ ocaml
            OCaml version 4.08.1

    # type 'a list = Cons of ('a * 'a list) | Nil;;
    type 'a list = Cons of ('a * 'a list) | Nil
    # Cons(3, Cons(41, Nil));;
    - : int list = Cons (3, Cons (41, Nil))
    # let reverse lst = let rec rev xs ys = match xs with Nil -> ys | Cons(x, xs') -> rev xs' (Cons(x, ys)) in rev lst Nil ;;
    val reverse : 'a list -> 'a list = <fun>
    # reverse(Cons(3, Cons(41, Nil)));;
    - : int list = Cons (41, Cons (3, Nil))

The full session with all my dumb errors:

    $ ocaml
            OCaml version 4.08.1

    # type 'a list = Cons of ('a * 'a list) | Nil;;
    type 'a list = Cons of ('a * 'a list) | Nil
    # Cons 3 (Cons 41 Nil) ;;
    Error: Syntax error
    # Cons(3, Cons(41, Nil));;
    - : int list = Cons (3, Cons (41, Nil))
    # let reverse lst = let rec rev xs ys = match xs with Nil -> ys | Cons(x, xs') -> rev xs' Cons(x, ys) ;;
    Error: Syntax error
    # let reverse lst = let rec rev xs ys = match xs with Nil -> ys | Cons(x, xs') -> rev xs' Cons(x, ys) in rev lst Nil ;;
    Error: The constructor Cons expects 1 argument(s),
           but is applied here to 0 argument(s)
    # let reverse lst = let rec rev xs ys = match xs with Nil -> ys | Cons(x, xs') -> rev xs' (Cons(x, ys)) in rev lst Nil ;;
    val reverse : 'a list -> 'a list = <fun>
    # reverse Cons(3, Cons(41, Nil));;
    Error: This function has type 'a list -> 'a list
           It is applied to too many arguments; maybe you forgot a `;'.
    # reverse(Cons(3, Cons(41, Nil)));;
    - : int list = Cons (41, Cons (3, Nil))
    #

(These error messages look appalling, but the OCaml interpreter was underlining my errors, which of course didn't paste.)

Similarly, there are problems that become much easier with other paradigms of programming, such as backtracking search.

Honestly I dont know the answer for this, its a trick you never need in the real world, but maybe it does test if you did compsci 101. I failed this as a Senior dev inverviewee, went back and learnt it so was preprared for the next time. It didn't make me a better programmer but now shows I've learned the basic tricks.

What is the trick in reversing a linked list? The solution is just some while loops...

Anyways it is a bad question to ask because it is very easy and is frequently studied so candidates just memorise the answer.

One while loop. Maybe you need to memorize again :).

There's no need to memorize anything at all; if you can code you can come up with a solution on your own within at most minutes.

I do not need to memorize it that was the point I was making, as it is so simple I can and have worked it out on the spot.