I don’t know with just this one question compared to others, but as part of a suite of what I classify as “technical thinking questions” I think it’s predicted well programmers who are mid level and up who can figure out problems independent from languages or vendor solutions.

I never actually care about the literal code written and usually just ask for pseudo code to understand the logic of how walk through it. So it will fit on a white board or maybe sheet of paper and take maybe 5 minutes or 10 minutes with commentary.

I think it’s better if the candidate has never actually written a linked list.

Similar questions I ask are “write a database connection pool” or fizz buzz.

They are parts screening as a surprising number of applicants can’t write loops or even if statements, which is weird. And part seeing how they ask questions to figure out what’s important requirements or assumptions or limitations.

It’s probably worse, in my mind, to write out amazing code without asking questions than to sketch out simple statements asking “how important is multi-threading” or “what libraries can I use” or “where will this get called from?”

I don’t have an empirical litmus test from this, but for a few candidates who sucked at this but still got the job, I regretted it. Although one or two moved within the org out of programming to business analysis and project management and did, I think, a good job.

In my limited experience, they're a good screening test. Even something FizzBuzz level is valuable to weed out applicants who interview well but lack basic competence. Doing well is necessary but not sufficient, mind you.

(I interviewed someone who fundamentally failed to understand a trivial question, they were hired despite my negative assessment, and while in all fairness they did better than I expected, they were still an overall liability.)