3 ms·

Most companies that I've worked in or with seem to treat interviewing as a miserable bore, and most candidates as utter incompetents to be sifted through. Wheth

Most companies that I've worked in or with seem to treat interviewing as a miserable bore, and most candidates as utter incompetents to be sifted through. Whether this is accurate (I'd be ready to believe that the incompetents spend much more time on the job market, but that would concede the questionable possibility that most corporations' interview processes work) or not is open to debate. Grading papers, an objectively miserable process, has probably led a few teachers to conclude that their students are morons just due to the unpleasantness of the task. If you can get to an in-office interview, you have the shot of impressing someone enough that people are actually excited about interviewing you-- people start talking about "the candidate" being really good today-- but this doesn't happen often, and not until you've already passed enough hurdles to get in person with someone who matters. Until that happens, you're just a block of work to be dealt with.

LiveTheDream 16y ago
Most companies that I've worked in or with seem to treat interviewing as a miserable bore, and most candidates as utter incompetents Jeff Atwood and Joel on Software blogged about how an absurdly high amount of people applying for programming jobs can't actually program at all. Many candidates are utter incompetents. Filtering the wheat from the chaff is hard process for the average company, because interviewing well and performing a job well are two different tasks.
- 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.
- pw0ncakes 16y ago
  I'm sure this is true, but it doesn't justify the organizational arrogance that is often seen in the interview process. One all-day round of interviews is fine, but when people are pulled out of work for 3 or 4 days just to interview, and informally expected to interview at their own expense, that's ridiculous. Selecting good candidates is extremely difficult and most companies and people suck at it, but coming in to the process with a rotten attitude isn't going to make it any easier or better. A large percentage of "programmers" shouldn't be. They don't like programming (enough to be good at it) and many just don't have the talent. This doesn't mean one should be a dick to them. Can you fault them for aiming comically high in the job search process? It's what everyone is told to do from the cradle in this country. And the "collateral" fall-out is that this attitude often alienates people who actually are talented and who quite possibly may be future customers, partners, et cetera.

LiveTheDream 16y ago

Most companies that I've worked in or with seem to treat interviewing as a miserable bore, and most candidates as utter incompetents Jeff Atwood and Joel on Software blogged about how an absurdly high amount of people applying for programming jobs can't actually program at all. Many candidates are utter incompetents. Filtering the wheat from the chaff is hard process for the average company, because interviewing well and performing a job well are two different tasks.

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.
pw0ncakes 16y ago
I'm sure this is true, but it doesn't justify the organizational arrogance that is often seen in the interview process. One all-day round of interviews is fine, but when people are pulled out of work for 3 or 4 days just to interview, and informally expected to interview at their own expense, that's ridiculous. Selecting good candidates is extremely difficult and most companies and people suck at it, but coming in to the process with a rotten attitude isn't going to make it any easier or better. A large percentage of "programmers" shouldn't be. They don't like programming (enough to be good at it) and many just don't have the talent. This doesn't mean one should be a dick to them. Can you fault them for aiming comically high in the job search process? It's what everyone is told to do from the cradle in this country. And the "collateral" fall-out is that this attitude often alienates people who actually are talented and who quite possibly may be future customers, partners, et cetera.