I don't agree with most of these points, nor do I find the tone of the author to be particularly productive, as they are effectively swinging bladed weapons around while blindfolded.<p>They propose a number of personal beliefs about what constitutes competency, whereas I will contend that there is no "silver bullet" by which a non-programmer (or XYZ profession) may assess the competency of the potential hire.<p>I could write a different article on programmers who seek to undermine existing code in order to get a green field project out of it.
While I can completely comprehend what may lie behind a total rewrite (and have plowed through some rather thick ones) I would be wary of hiring such a rigidly ideological person who suggested "throwing it all away and doing it over" as this person is likely somewhat obtuse in their own way.<p>Human factors also matter.
Why not just take some code and ask the applicant if he can read it and describe its function? Sure that won't tell you everything... but just saying you read "mechanics and thermodynamics of propulsion" doesn't make you a rocket scientist.