It’s all about the app — or is it?
The blogger quoted below argues that today’s technical recruiter doesn’t know how to ask the hard questions, to make sure that “the new guy can code.” His radical proposal: Only interview people who have built an app with real users.
I’m leery of one-size-fits-all models. That’s explicitly what we were trying to avoid with Media Computation and Threads – we weren’t trying to get rid of the old way, but creating options for people who didn’t fit the old way. I know excellent programmers who can’t build a user interface, and exceptional user interface designers who can’t code at all. Does that mean that those folks should never be interviewed, that they have nothing to offer? Do you have to be the whole package, from Eclipse to Photoshop, to offer any value to a company?
So what should a real interview consist of? Let me offer a humble proposal: don’t interview anyone who hasn’t accomplished anything. Ever. Certificates and degrees are not accomplishments; I mean real-world projects with real-world users. There is no excuse for software developers who don’t have a site, app, or service they can point to and say, “I did this, all by myself!” in a world where Google App Engine and Amazon Web Services have free service tiers, and it costs all of $25 to register as an Android developer and publish an app on the Android Market.
The old system was based on limited information—all you knew about someone was their resume. But if you only interview people with accomplishments, then you have a much broader base to work from. Get the FizzBuzz out of the way, and then have the interviewee show and tell their code, and explain their design decisions and what they would do differently now. Have them implement a feature or two while you watch, so you can see how they actually work, and how they think while working. That’s what you want from a technical interview, not a measure of its subject’s grasp of some antiquated algorithm or data structure. The world has moved on.