It’s all about the app — or is it?
May 12, 2011 at 10:22 am 4 comments
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.
via Why The New Guy Can’t Code.
Entry filed under: Uncategorized. Tags: jobs, Media Computation, Threads.
Computing Ed Research - Guzdial's Take 
1.
sylvia martinez | May 12, 2011 at 2:34 pm
I don’t think it’s unreasonable to ask a job interviewee to DO something (or show evidence of having done something). Wasn’t it Tom DeMarco who said (paraphrasing) – A circus wouldn’t hire a juggler without seeing him/her juggle.
I would agree though, that every job and every candidate should not have a set list of requirements.
2.
andrew carle | May 12, 2011 at 3:49 pm
If you remove the superflous “all by myself!” from the brag statement, then it seems entirely reasonable. If you can’t build a UI to save your life, then you’ll have written something that doesn’t need one, or found a partner who can. On the interviewer side, it’s a matter of being specific about what you’re evaluating in the prospective hire and her code, which is remarkably similar to grading and evaluating student work.
As a baseline, no CS grad should expect an interview without non-academic projects to feature on her resume.
3.
gasstationwithoutpumps | May 13, 2011 at 8:13 am
“Non-academic” is rather ill-defined. I believe that students who have worked on real research projects at the university may also have good projects to talk about at interviews. I think the key here is to have worked on something real—something that matters beyond just picking up points in a course. Whether that real project is from an industrial internship, university research project, or hobby is less important than having done something that is not a toy exercise.
4.
Robert Cooper | May 13, 2011 at 5:12 pm
I think “All by myself” is the most important part of that. That someone was on a 12, 20 or 60 person team that built something says nothing about the candidate.
Any bit of non-trivial code, though, that the candidate wrote entirely on his own, with no environmental constraints on how it was going to be done (what tools/language/style/etc) says more about the candidate that past project history.