This is pure awesomeness. I've rejected people for all of those reasons but haven't ever put them together so succinctly.
The one that can really swing my vote one way or another is the lack of passion. To be clear you are probably passionate about something, and I don't mean "getting paid to work here." For example when I was with Google (and even earlier at Sun) I interviewed candidates who were passionate about wanting to work at the company but were not passionate about any thing in particular the company was doing. Their passion was 'to be employed by <company X>' and I would ask them "Ok, so lets say we hire you and you've achieved your goal, now what are you hoping to achieve?" only to get crickets. That is always hard to get past.
Thanks for reading. I've received many of these responses lately on some job candidates and thought there was some value in compiling them for engineers that may be interviewing. I could certainly see where candidates might get hung up on working for a particular employer without necessarily being as passionate for their role there. I don't see that too often as I tend to recruit for smaller software firms, but I'm not at all surprised that you would see that at Google, Sun, Apple, etc.
Interesting part about the "fanboy" complex, where programmers insist on working with specific technologies.
Unfortunately, some segments of the recruiting industry do encourage this behavior. Once a programming language or framework is established, it can be difficult to get a job without direct experience. There's a short, narrow window of opportunity when a technology first appears where nobody has much experience and people can learn on the job, and that's the magic moment to gain experience. Queue the stampede. For instance, when EJB hit, a lot of Java devs thought that if they didn't gain experience with this new technology quickly, they'd be shut out. And I did start to see job postings that specifically required EJB experience, not just general java experience.
I get the feeling that the industry has moved away somewhat from this type of skills matching, but hacker news can give you a distorted view on how things work. Lack of experience with a specific technology is less likely to hurt you here than with a consulting/body shop attempting to put square pegs in square holes. But even this article recommends that you gain deep experience in a technology and avoid becoming a "jack of all trades" (while at the same time advising against being a fanboy for a specific technology). This isn't necessarily inconsistent - there is a meaningful difference between being a fanboy to the exclusion of all else and being an expert with depth in a particular technology, but it can be a tight line to walk.
Well said, and I could claim some guilt in years past about jumping on the next big thing and encouraging my network to learn what seemed to be on the horizon. I still keep track of trends and will mention them to candidates, but I now try to tell engineers (particularly younger ones) that they should try to experience several languages and tools to become better at the overall craft. Deep engineering experience seems to be acquired by seeing variety.
I think the fanboy comment would be attributed to someone today walking into an interview and saying they 'only want to work in (specific language)', which would be a turnoff to most companies. Having passion for a technology is good and engineers will always have preferences, but being willing to help out where you can will have greater value.
You're right. But good developers won't want to work for employers that engage in that kind of skills matching anyway (unless they're desperate and have no other options). A broken recruiting process is usually a sign of deeper organizational dysfunctions.
What a great read. I've recently run the gauntlet on interviewing and I'm acutely aware of all of these. I only have one issue which is about the section on "Candidate showed a lack of passion".
I'm completely passionate about development. I do freelance work, I build stuff outside of my 9-5 job, I go to conferences and meet-ups locally. But I know developers who are much better JavaScript and Ruby guys than me. They have more experience, but don't do nearly the same amount of stuff outside of work that I do. Does that "lack of passion" about the industry and their profession make them a less worthy candidate than myself?
Yeah, I was uncomfortable with that too. There are two sets of people I know: Folks of the kind that you mentioned who are incredibly good programmers but who have other interests outside life. In fact one of the smartest coworkers I knew spent half his time at work and the other half time in a band and he was extremely productive. Another group are the people who have a personality which doesn't exude visible signals for passion: They probably never hang out at meetup groups or conferences, but they quietly hack away in their own time without tweeting about it or whatever. From a macro perspective they are "passionate" for sure but are susceptible to false negatives especially in the highly noisy interview setup.
A lot has been written about passion lately, and even another recent blog post of mine is relevant (http://jobtipsforgeeks.com/2012/04/17/how-employers-measure-...). I don't think passion has to be demonstrated by 'only' doing coding 24 hours a day, or going to meetups every day. I know very good technologists who don't attend meetups or hackathons, but you can tell in how they talk about technology that they have passion. It's hard to quantify, but I think for the most part good companies tend to get it right more often than not.
Good question. I think in time, those who love what they do will generally catch up 'skills-wise' to those that do what they do only for dollars. Being a worthy candidate with less skills is a possibility - perhaps you will work harder or longer than they will, which could make you more productive. I would say that many companies may hire someone like you over someone with a bit more experience and less passion, as the long term investment is potentially better. If it were a 6 week contract, I'll take the other guy - for a salaried perm job, you may be a better choice.
Another one to add is personality. Generally at the end of the interview there are two questions I have to answer:
1) Can the candidate do the job?
2) Can I work 8-10 hours a day, 5 days a week, under stressful situations with this person?
I've had candidates just rip apart their past co-workers and previous companies. Sure you might have some gripes with how things were done at your previous company, but make sure you don't end up portraying yourself as someone that is difficult to get along with.
Not sure where this one fits in (passion? commitment?) but having a candidate mention that they "don't do overtime... ever" half-way through an interview when nothing has been mentioned about over-time is a serious turn-off.
Sure - people have families and not everyone is geared up for 18-hour work days - but sometimes the sky is falling and companies need an employee that isn't going to disappear out the door at 5:01 PM when the place is burning with a "well that's me for today! good luck guys!"
If a candidate says they are 'never' willing to work overtime, they are probably in the wrong business. I can't say I've ever had someone tell me never. Most engineers understand that there are going to be at least some support or production situations that need to be addressed beyond standard biz hours. I wouldn't say that is passion or commitment - having some expectation of at least occasional overtime is probably just a minimum requirement.
There is a good chance the candidate has been burned in the past by too many instances of 'the sky is falling' or 'I need this tomorrow for no good reason' types of overtime and isn't willing to be taken advantage again.
I haven't really ever been required to work overtime but I've always emailed my boss before I left for the day to ask if there was anything else he needed before I took off for the day. I don't want to work overtime, or like it, but will if something needs to be done. I don't like the culture where everyone sits at there desk for an extra 15 minutes because they are afraid to be the first one to leave.
Overtime should be reserved for emergencies, not for demonstrating passion or commitment.
Just to clarify, if someone stayed late to fix something on Tuesday and then clocked off early on Wednesday in lieu, would that count as overtime in your definition?
I would venture a guess that someone like that has worked at a place where overtime wasn't 'required' explicitly, but was required implicitly (think the gag with the 'flare' at Chotchkie's in Office Space). Sometimes people have an extreme response to being in an extreme situation.
Overtime is fine, as long as it is paid. At least, this is how I've tended to operate. The ones for whom I feel are the ones stuck in salaried positions where unpaid overtime is the way of things, and is even expected. I never complain when offered overtime, because I see it as an opportunity if I'm getting paid to do it.
I would rather it was a logo. Currently, it comes off as kind of precious. It was actually quite distracting. I came to your blog to read an article, and found myself presented with this bit of text, which I initially mistook for the beginning of the article.
An overly large sense of entitlement and lack of passion are the two biggest red flags for me. Someone with a great attitude but lack of skills can be trained; someone with a bad attitude can't be fixed (at least not by the hiring organization).
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.
Great article but I have to wonder.. is it actually relevant today? With the huge demand for engineers and the utter lack of even somewhat qualified engineers, I wonder if people actually are still having a tough time landing a job?
Whenever I hear/read these comments, my first thought is always that the speaker/poster is from The Valley, and assumes that every place is like The Valley (or that everyone with technical skills wants -- or can -- move to The Valley). In other words, "The Valley" isn't the answer to life, the universe and everything.
[Also, there can't be that high of a demand for engineers, because I've been denied jobs for the most trivial of reasons. I was denied a job once for not being able to answer a Python trivia question about something that took me 5 minutes to learn from the Python documentation.]
There are always people in the tech industry who find it overly hard to get a new job. At least in the SF Bay Area it seems like there are always some 'well known problem children' who, perhaps in spite of their qualifications, remain stubbornly unemployed.
There is also the question of where you work, saying that anyone can get hired is fine, but if you're only offer is working in the local office of an offshore company with dictatorial management from abroad, that's not necessarily a fun choice.
I read this as a nice treatise on things that you may not realize are pretty influential in the hiring decision but aren't related to your technical skills per se.
The engineers that do have decent tech skills and don't fall into some of the categories listed in the article aren't having too difficult a time finding work. Some companies can't afford to be too choosy and will hire people with these traits. Most of my clients tend to be smaller shops, where the cost of a bad hire is much greater, so they will be more selective and protective of their culture and environment.
The one that can really swing my vote one way or another is the lack of passion. To be clear you are probably passionate about something, and I don't mean "getting paid to work here." For example when I was with Google (and even earlier at Sun) I interviewed candidates who were passionate about wanting to work at the company but were not passionate about any thing in particular the company was doing. Their passion was 'to be employed by <company X>' and I would ask them "Ok, so lets say we hire you and you've achieved your goal, now what are you hoping to achieve?" only to get crickets. That is always hard to get past.