I am expecting this is especially the case where the person assessing the code does not understand what the code does (i.e. a "lesser" programmer assessing the work of a "greater" programmer)
I wouldn't be terribly surprised if "lesser" programmers cannot recognize good code - that's just Dunning-Kruger. That was why I suggested looking for crappy code instead - more people can recognize crappy code, because more people are beyond that skill level. If you ask for samples of good code and your replies all differ in their assessments, you don't know whether that's because "good" code is intrinsically hard to recognize, or because all your respondents were crappy programmers.
When deciding if code is good or not, surely there should be quantified criteria for assessment. Code cannot be judged to be "good" or "not good" without specific pre defined measures of assessment. I would suggest that close to 0% of employers that want to "see your code" are assessing against pre defined assessment criteria.
A good experience would be get 4 experienced developers to read and evaluate a piece of code; that'd raise some interesting practical aspects of their evaluation of its goodness.