I have to agree, I see more excuses then actual proof that you can write good code. In short for most organizations the ability to write perfect code is nearly impossible. The aspects of what is considered good code are mostly academic and abstract in nature, rarely consider real world problems, such as speed to delivery, compatibility with legacy systems, having to try to justify to share holders why there isn't any visible change to the product...
As someone who had started out as a programmer and had advanced to Architect and Manager, I find myself having to direct the less experience coders to do things in a way that I know myself would had issues with doing such back when I was started, with my head fresh with ideas on what was right and what was wrong. There is a real balance that needs to take place. In terms of interviewing and explaining your code examples if you could explain the reasons why you did it that way vs other ways, chances are the hiring staff would be able respect your code more.
Normally if I am reviewing a potential employee code samples, I am trying to gauge their technical skills by seeing that they can in fact produce complete code, ingenuity seeing how they are able to work around problems, organization making sure their code is done in some sort of logical order. I am not going to nitpick on how well they isolate classes, or if they decided to make a polymorphic class structure with overloaded operators.
At one employer I had made a test that was rather good at getting good employees.
Problem 1: HTML/CSS I had a picture of an overlapping boxes on top of a grid, and ask them to reproduce it.
Problem 2: I had a SQL command that returned no rows, however the table and logic obviously shows that it should. They were to debug the code and fix the problem.
Problem 3: Make a basic Input form in the language needed asking for an American Address fields (with leading 0 zip codes) with appropriate checks to make sure the address is valid.
I have found that more most people this test actually takes them 4 hours to complete they are allowed to use Google to search for help, but they are not allowed to chat with someone else or ask a direct question, so they are proctored. I had found out that this test weeded out a lot of bad developers as retained mostly good ones. As they knew how to search for information they didn't know, analyse and break apart complex code to find problems and deal with problems which may have a hidden twist to them.
But back to the point, blaming your CTO for bad code is just a lame excuse. I have dealt with bad CTO with stupid ideas, and I found ways to make them work.