I know the plural of anecdote is not data, but I'd say that the typical PhD that I have interviewed has generally poorer useful coding skills than the person from a similar background who stopped at a masters or even BS and then wrote a lot of high quality code during the time the PhD was doing a whole bunch of theoretical work.
>To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.
It's MUCH easier to come along after someone has already spent days exploring the problem and can demonstrate the dead ends, then say "oh, you need a custom parser" than to start at the beginning and do the same thing. USUALLY writing a custom parser is overkill and it takes a decent amount of digging into a system to know when it's not. If you start out writing one every time something looks like it can be solved by an "if" statement, you'd never get anything useful built.
This can go both ways, though. Sometimes the fast elegant solution is too elegant for the nasty corner cases and a much bigger, uglier, but ultimately straightforward procedural block of crap is better.
The examples I've seen are from established businesses that occasionally slipped up in refactoring out hacks that were introduced to support deadline-driven requirements. A year or two later, that hack is powering the reporting for a huge portion of the traffic, and you have to be able to balance between (a) writing maintainable code that supports the hack for the short term and (b) working with the rest of the business to clean up the requirements so you can improve the system for the long term.
(b) is a skill that most interview processes I've seen completely ignore. And (a) often is downplayed (as "simple" or "easy") compared to more clever tricks - but knowing how to do the clever tricks might turn into a temptation to use them more than you should.
There's "need" and there's "need". The person without the solid computer science background may very well be able to solve all the problems at hand, but the person with the solid CS background is far more likely to come up with the fast elegant solution that doesn't fall over in obscure corner cases.
To use a concrete example for early in my career; I spent days and days trying to solve a problem by building a bigger and bigger pile regexps and if-else statements. Then my project manager (who had a PhD in CS) came along a just wrote a custom parser that solved the whole thing.