TechInterviews

December 07, 2010
Ken Levine, Emmy winning writer on such shows as MASH, Cheers & Fraiser, writes about the best way to ‘interview’ writers:
Way back in the dark ages (the 70s), most sitcoms had very small staffs and relied on outside assignments. These freelance scripts basically served as auditions. No one got hired on staff until they had proved they could write the show. As a showrunner, trust me, that’s a far more efficient method of staffing. Today, you hire staff writers based on spec scripts and often times they don’t pan out. Then you’re stuck with some slug who you’re paying while more deserving writers are shut out.

I don't understand why most tech interviews don't involve actually writing code. Some will do some whiteboard coding, but the job isn't about whiteboard coding, it's about writing real code. My preferred method of doing things is to start with a prepared collection of projects with varying levels of quality, some simple, some more advanced. I'll email the source code to the candidate with simple instructions: You own this code. Go.

Hopefully they'll reply with bug fixes and enhancements. I'll review the code and then send it back for a second go round.

I've gotten a lot of feedback from peers that this doesn't seem too fair to just leave the candidate hanging, but frankly a lot of times on the job that's what happens: here's some code you've not ever worked with before, take care of it. Plus, I'm not necessarily looking for a stellar first effort (though a stinker first effort may warrant not taking the time to review the code). I want to go through a round of code review to see some additional things about the candidate, like how they respond to criticism or debate a design issue that is more about trade-offs rather than one right way to do something.

The only challenge I've really run into on this is that it does put a bit of a burden on the candidate to find the time to work on the code, so cutting them some slack in that regard is required at times. But still, I'd rather have a meaningful discussion about this source code than see if they can write a recursive function on a whiteboard, or, worse yet, figure out how many hubcaps there are in Minnesota.

tags: ComputersAndTechnology
comments powered by Disqus