I would say, however, that your criticism boils down to the tactic of asking ‘why’ over and over again. I could have broken down exactly what I meant by ‘Trust’ or ‘Rules’ but these are fairly well known ideals. Philosophers have written books about the meaning and nuance of both these subjects. They are, at least, for the purposes of writing and maintaining software, pretty well known and understood. However, as you point out, there’s always room for better and more through definitions.

In the end, and I could see how I missed a little at this one, it was my desire to reveal that one must evaluate much more than programming traits when evaluating an engineer. We can quibble about exactly what those traits are (and I look forward to doing more of that in the future) but perhaps we could agree on just that small thing for now?

Let’s talk about trust. How do you build trust? By talking people into it? Um, really? Sorry, but I much prefer people who cannot talk me into their grand-designs (communicate), but is responsible and caring, as well as be proud enough about their career that they always uphold the utmost standard for their products.

Furthermore, I always hate the talking about abandoning rules. Assume that one of our rules is to produce clear, easy to understand code. Because the deadline is tomorrow, am I entitled to break that rule, to meet the deadline? The rules are there for a reason. If the rules are insufficient, then let’s create new set of them, and adhere to that set of rules. Trying to work around is just senseless and dangerous, if not irresponsible.

In the end, well, you still have not answer the question: what makes great programmers?

Your points emphasise why the ‘quick fire’ round in an interview is pretty much useless in determining whether a canditate is a good fit.

A candidate that can answer all the questions is just lucky (we all have gaps in our knowledge), and when their luck runs out, it’s how they approach the problem and people around them in finding the solution that matters most.