4 ms·

I think a large number of programming jobs aren't - this is how we wind up with such a mind-numbing process for both job seeker and hiring organization. I have

by tom_b 16y ago

I think a large number of programming jobs aren't - this is how we wind up with such a mind-numbing process for both job seeker and hiring organization. I have interviewed at a number of places where the job description would have led you to believe the position was for a hard-core development person, with a desire for the type of experience in candidates that could only be obtained by being a tech lead dev or architect with dev responsibilities at a forward-thinking software shop. I've have generally been surprised to often find what companies were really after was someone willing to work with a previously purchased tool or framework, placate internal users, and perhaps do some scripting on the side. Perfectly fine work, but in no way matching the job description. People who've been filling these positions now begin to think of themselves as programmers (even if this type of job is all they have had). Then we, when hiring for something approximating actual dev work, are surprised to find that all they have done is lightweight admin of some tool set and some scripting. A giant red flag for me at this point is to apply to a job, offer to provide code samples, and have ZERO interest from the hiring group in seeing those samples. Seriously? But, then I realize, they aren't REALLY looking for a programmer - they are looking for more of the role I've described above. We could look deeper under the covers at reasons for this weirdness, but it's probably too depressing in general.

pw0ncakes 16y ago
Question: in hiring, what would you read for in a code sample? I ask this because, in my experience, the most destructive breed of lousy programmer is not the sort who can't program but the "rock star" who writes code fast that seems acceptable on the local scale, but has no modularity or organization at a more global level. This is the sort who can hammer out a 4000-line project over a weekend, but if you have him on something major, he won't even understand his own code if it's older than 2 months (and no one else will be able to understand it, either). You can't really catch this kind of programmer in a code sample, unless you know what to look for (and I think I'm among the majority of people who don't).
- tom_b 16y ago
  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.

by tom_b 16y ago

pw0ncakes 16y ago

Question: in hiring, what would you read for in a code sample? I ask this because, in my experience, the most destructive breed of lousy programmer is not the sort who can't program but the "rock star" who writes code fast that seems acceptable on the local scale, but has no modularity or organization at a more global level. This is the sort who can hammer out a 4000-line project over a weekend, but if you have him on something major, he won't even understand his own code if it's older than 2 months (and no one else will be able to understand it, either). You can't really catch this kind of programmer in a code sample, unless you know what to look for (and I think I'm among the majority of people who don't).

tom_b 16y ago
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.