This is nonsense for several reasons. tl;dr Don't use trick questions in your interviews. The candidate is not there to read your mind.<p>1. An interview setting is a terrible place to observe whether someone will "break" the specs. In someone's job, it's clear that their goal is to provide value to the company. Specs have a real purpose and real users. In an interview, candidates are likely to assume they're being tested on coding, not on coloring outside the lines.<p>2. Some of the "expectations" are directly contradicted by the specs. No one's job should be to do good work despite having shitty specs. If you need a developer who ignores explicit requirements in a spec, you either A) have a shitty developer who does her own thing despite what the specs say, or B) shitty management. Either way, why would you test for this?<p>3. Nitty-gritty details in an interview setting aren't a test of whether someone is a good developer. Example from the article:<p>> <i>A good developer will make sure to close streams in right way and release file descriptors while an average programmer forgets about that.</i><p>Are you fucking kidding me? You could pick any tiny "good practice" at random and say, "An average developer doesn't do this, but a good developer does." And most of them will be your little pet peeve that rarely matters in the real world.<p>Besides that, details are the easiest thing to screw up in a high-pressure interview (and technical interviews are <i>always</i> high-pressure).<p>Are you really trying to find out if someone is good to work with, or are you trying to see if they'll discover the tiny traps in your interview? And have you even tested this strategy to see what kinds of devs you get vs. what kinds you reject?<p>I genuinely hope no one in a hiring capacity sees this post and follows the advice. Or, if someone is in an interview like this, I hope s/he is able to get an offer somewhere else, because this company optimizes for terrible indicators of skill.