I think a code sample is really just a launching point for a discussion. Some people would probably use a resume the exact same way. When I've offered code sa

I think a code sample is really just a launching point for a discussion. Some people would probably use a resume the exact same way. When I've offered code samples to hiring managers, what I've tried to do is demonstrate technical mastery needed to help them get work done. My goal is to explain design choices, trade-offs, and situational information. Stuff like, "I see you used this really weird and complex table function here - why?" I like to explain what I did, try to provide some general fundamentals as part of the explanation, "Well, we were able to eliminate x KLOC of Java by using this table function to simplify our db access layer. Over here on this other stuff, we did what amounts to some duct tape work because it was a one-off for a customer, who btw, based a purchase decision on our ability to provide this solution in a couple of days, which is why the code isn't commented in a nice way, etc." This type of conversation is what I'm expecting from a candidate as well. But, you're dead-on on not being able to catch a destructive, lousy programmer if you don't know what to look for. If you put me a room with some rock star Lisp programmer, I'm not going to have the foggiest idea how to ferret out a conversation based on a code sample. I'd probably try to have the candidate teach me based on their sample. Avoiding lousy, rock-star programmers . . . well, in reality, I simply haven't had to make enough hiring decisions to hit this too often. I have noticed that rock stars seem to be more ego-driven, code "hoarders" who struggle to explain their designs without being condescending, can't talk about people they've mentored (because they haven't), and seem squishy on details when you really dig into code. But you might be awesome and just a lousy communicator. In which case, you probably won't work well with me anyway and you're not passing the "culture fit" test. So much depends on context. Right now, I'm driving a project with two other people working for me and I'm purposely making design choices that aren't that great - we are incurring some technical debt as a trade-off for meeting a big demo day deadline. Plus, we're focused heavily on iterating with our actual users (who on this project are prone to ask for stuff and then when you show them implementations tend to respond with "oh, what I really meant was . . .") In the past, I've designed db access layers that were used by larger team, so I had to do more measured, thought-out design and education of that team. The ways I would talk about both projects in an interview would be very different.