The Terrible Technical Interview

I think that's an unfair interpretation of what StevePerkins is saying.

I don't get the impression from him that VCS knowledge in particular will make-or-break a candidate. He's saying that IF the candidate put it on his resume, then the candidate himself is the one who opened that door for discussion.

Out of the infinite list of programming topics to discuss, what are some options to narrow it down? Well, the candidate (through his own volition) put on his resume... so... let's talk about Topic X! It doesn't matter what Topic X happens to be (whether it's "svn", "parallel algorithms", "Ruby", "TDD", "cloud scaling", whatever). What matters is that the candidate is the one who thought it important enough to highlight it. From there, it's reasonable to think it's something the candidate is already comfortable with discussing in depth. If not, he shouldn't put it on the resume.

Your response makes it seem like StevePerkins is playing Alex Trebek with Jeopardy random topics and asking "gotcha" questions. It's not random -- the source is the candidate's resume. It certainly seems fair and reasonable to discuss any topics the candidate put on his resume. Imo, it's also fair to augment with questions that are not represented on his resume (but that's a different discussion from StevePerkin's example.)

But put me in front of 3 guys I've never met whose purpose for being in the meeting is to expose every single one of my weaknesses, push me up in front of a whiteboard and ask me to explain the best way to solve a maze puzzle, and I'm going to freeze up and fail the interview. The reason is, this is simply not how I work. I work by sitting at my desk, thinking about the problem presented, and writing code to have the computer do all the work. It may very well be organizationally convenient to have these psychological lynchings occurring, but I highly doubt it gets the absolutely best candidate in the door.

I look forward to new solutions to the problems of finding qualified people; in my case, I feel I unjustly failed an interview at a company I could have been quite productive. Such is life in the modern software world, alas ..

iOS/OS X seems to do real MVC, with lightweight reusable view objects managed by ready-made controller classes. The obvious benefits are minimal memory and streamlined data flow. You only ever make/use the view objects you really need, you can recycle them to save memory, and - in OS X especially - controller objects include useful ready-made convenience methods.

Web frameworks often seem to do something that looks like MVC if you squint and don't think too hard. But when you're forced to use separate languages for logic (js), markup (HTML), and view design (CSS), and handle separate client/server environments, and there's inevitable overlap between all of the above (jquery etc) because stuff doesn't "just work", and you probably have yet another layer as a DB driver, it gets very complicated very quickly - to no great benefit.

The web has become a snarly ball of warty epicycles. That's why native is so popular - you get one common language for logic, views, and data, with a clean-ish interface to a remote server if you need one.

When everything works together like that, you can think seriously about MVC.

When the core concerns are all over the place already, it's a mess before you even start.

Which is not to say you can't work with it and build cool stuff - more that you can't just airdrop in a design pattern from a different tradition without thinking really, really hard about what, why, how, and what happens a year from now.

Of course this again biases against people who suck at interviewing (too nervous or whatever).

Not your cup of tea? Totally fine. Not everyone is interested in doing security.