Great article, though I do some of these things and have never really had trouble securing work, some examples:
Candidate has wide technical breadth but little depth and related: not uncommon, particularly for folks that have perhaps bounced from job to job a little too much
I think this describes me, though I'm not sure how to define technical depth here. The only benefits I can see (technically) from staying at a company for more than a year or so would be greater domain knowledge and perhaps a greater understanding of the long-term implications of architectural decisions.
As for technical depth in terms of skill, IME I've found that job-hopping has dramatically increased the speed at which I've been able to gain expertise. For example, I've worked at some places where, for cultural reasons, there's no call to do fat-client javascript applications, with more of a focus on server-side technologies like stored procedures. Conversely, where the front-end stuff was more important, I got much better at organizing large javascript codebases and creating web services to interact with them. Had I worked at only one or the other, I would have lacked technical depth in the area I was missing out on.
Candidate displayed a superiority complex or sense of entitlement -
Guilty as charged! Unless I'm being hired as a consultant, I generally tend to wrap-up interviews when I realize the technical staff I'd be reporting to don't have as much technical ability as I do (for my own, entirely subjective measure of technical ability). Also, I don't work with PHP, Java or anything related to Microsoft.
I'll also disqualify companies where I feel like they have bad process, or if there's any social weirdness in the interview (I've experienced everything from off-the-cuff anti-Semitism to the interviewers shouting at each other). I don't mind a flexible work schedule, i.e. I work late on a Tuesday and then I go home early on a Wednesday, but overtime without pay is not an option.
Candidate talked more about the accomplishments of co-workers -
Programming of any significance is a team sport. Sometimes a potential hirer will ask "Do you have any experience with problem X?" and my answer is often "Yes, alongside other developers" or "Not directly, but I was involved in discussions about X when we were dealing with it at #{company_name}" or even "No, but I was talking about X with #{someone} at #{some_tech_meetup} and he said they were trying #{some_solution} which sounded like a sensible strategy. I think it's probably better than #{other_solution} because it means that #{benefit_of_first_solution}".
As long as I discussed some of the tradeoffs of various options and managed to adequately demonstrate my understanding of the technology, I think the interviewers were happy. I feel somewhat uncomfortable taking full responsibility for achievements at any company I work at, because in practice it involves mulling over ideas, discussing pros and cons and coming to a solution together.
Good points. Depth is hard to measure, but generally I find that clients will ask a question about a specific programming topic and start off basic. When the candidate gets that right, they go a little deeper with the second question and the candidate fails. It's like being able to name all the baseball teams but none of the players - that would be breadth but not depth. You might come across as a baseball fan initially, but not on further review.
RE: entitlement - I don't think what you are describing is a superiority complex as much as coming to a realization that you are more senior than the person - no complex, just a fact I'd say. Companies that have bad process should be off limits for you as well, I don't think that is entitlement but rather some basic expectations. Not being willing to work at all with PHP, Java or MS could be perceived as entitled if everyone else has to dive in on those from time to time.
Agreed with your ideas re: co-workers. The key being that you demonstrate the understanding. It's not so much about claiming responsibility as it is about being curious about your surroundings and interested in things beyond your individual contribution to the project.
> Depth is hard to measure, but generally I find that clients will ask a question about a specific programming topic and start off basic. When the candidate gets that right, they go a little deeper with the second question and the candidate fails.
My experience bears this out. In one of the best interviews I had the interviewer essentially picked items off my CV and asked me more and more about them until I was forced to say "I don't know". This was supposedly deliberate (i.e. they wanted to see a) how much knowledge I actually had and b) what I would do at the limits of it). I came away from that interview with no idea of how well I did, but I got the job!
> Not being willing to work at all with PHP, Java or MS could be perceived as entitled if everyone else has to dive in on those from time to time.
In a tougher market I might be singing a different tune, but at the moment there's just so much work out there that I think the average developer can afford to be a little picky, or entitled as it were. Not saying it's right, it's just what it is.
Candidate has wide technical breadth but little depth and related: not uncommon, particularly for folks that have perhaps bounced from job to job a little too much
I think this describes me, though I'm not sure how to define technical depth here. The only benefits I can see (technically) from staying at a company for more than a year or so would be greater domain knowledge and perhaps a greater understanding of the long-term implications of architectural decisions.
As for technical depth in terms of skill, IME I've found that job-hopping has dramatically increased the speed at which I've been able to gain expertise. For example, I've worked at some places where, for cultural reasons, there's no call to do fat-client javascript applications, with more of a focus on server-side technologies like stored procedures. Conversely, where the front-end stuff was more important, I got much better at organizing large javascript codebases and creating web services to interact with them. Had I worked at only one or the other, I would have lacked technical depth in the area I was missing out on.
Candidate displayed a superiority complex or sense of entitlement -
Guilty as charged! Unless I'm being hired as a consultant, I generally tend to wrap-up interviews when I realize the technical staff I'd be reporting to don't have as much technical ability as I do (for my own, entirely subjective measure of technical ability). Also, I don't work with PHP, Java or anything related to Microsoft.
I'll also disqualify companies where I feel like they have bad process, or if there's any social weirdness in the interview (I've experienced everything from off-the-cuff anti-Semitism to the interviewers shouting at each other). I don't mind a flexible work schedule, i.e. I work late on a Tuesday and then I go home early on a Wednesday, but overtime without pay is not an option.
Candidate talked more about the accomplishments of co-workers -
Programming of any significance is a team sport. Sometimes a potential hirer will ask "Do you have any experience with problem X?" and my answer is often "Yes, alongside other developers" or "Not directly, but I was involved in discussions about X when we were dealing with it at #{company_name}" or even "No, but I was talking about X with #{someone} at #{some_tech_meetup} and he said they were trying #{some_solution} which sounded like a sensible strategy. I think it's probably better than #{other_solution} because it means that #{benefit_of_first_solution}".
As long as I discussed some of the tradeoffs of various options and managed to adequately demonstrate my understanding of the technology, I think the interviewers were happy. I feel somewhat uncomfortable taking full responsibility for achievements at any company I work at, because in practice it involves mulling over ideas, discussing pros and cons and coming to a solution together.