How to Handle Interviews - Turnoffs

I thought I'd finish my series on [[How to Handle Interviews|how I like to conduct interviews]] but covering some items that I feel are turnoffs.  I wouldn't instantly disqualify you as a candidate, but I really don't like to hear or see these things.  I'm not going to cover obviously things like take a shower, look groomed, don't pick your nose, etc.  These are obvious and don't need rehashing:

  • Focusing on "duties" vs "accomplishments"?  I want to hear about times you stepped outside of your area of expertise.  If you were the DBA then I just assume you handled backup and reindexing duties, you don't need to dwell on it.  But when did you go over and above the call of duty?  What was it?  Why?  
  • Mentioning how you were the "Senior" member on your team or you have "Senior level Oracle skills."  "Senior" is a meaningless term.  Were you the senior man because you had seniority, or because you were the "go to guy"?  A "Sr Engineer" at my company wouldn't even be a "Jr Intern Programmer" at Google, unfortunately (nor would I).  
  • Mentioning how you have 10 years of experience with blah blah blah.  Who cares, "years experience" is also meaningless.  Do you have 10 years of experience with Windows just resetting passwords, or doing progressively more difficult tasks like cluster management?  One of my favorite sayings is, "Do you have 10 years of experience or one year of experience repeated 10 times?"  I know people with one month of SQL Server experience that can code better TSQL than folks with 20 years of experience, simply because they are working with much more complex code than the 20 year guy has ever seen.  
  • Telling me how you know 43 different programming languages.  If you are going to do that, make sure you can tell me a few reasons why I might consider one of these over another for a given problem.  Or tell me why you want to know this many languages.  If you want to know all of these languages so you can have a deep and broad understanding of different programming paradigms then that shows amazing maturity.  
  • Focusing on the quantity/quality of your education/training/certifications.  Just because you have dual masters doesn't make you smarter than the rest of us with only a bachelor's degree.  Just because you have 12 certifications from Microsoft doesn't mean you know how to implement their technology in my environment, it really just means you are a good test taker.  Feel free to mention these things, they are important accomplishments, but don't assume the interviewer will immediately fawn over you.  Instead, tell me why you have this much education and why you think it is a benefit.   In my opinion, the sole purpose of an education is to help you to spot people's bullshit easier later in life.  See this video for an example:

You get extra points on an interview if you can mention these things:

  • Understanding the full software lifecycle.  If you can mention how a solution reduced support costs I'll love you for ever.  So many architects and developers think their job is done when the software is released.  
  • Mention "-ilities" and how one of your proposed solutions took -ilities into consideration.  
  • Somehow work in that you understand what requirements are (they are NOT something that you CREATE, rather they are something that you DISCOVER through analysis and then DOCUMENT.  
  • I like to see a wide range of development and business environments.  Some people think you are worth less as a developer if you never worked on a 100 person development team.  

Hiring Process Items I Disagree With

  • I don't like giving proficiency tests to candidates.  I think they tend to focus on minutiae ("if you compile this code what error will you see?" ... who cares?  It's a stupid block of code I would never write that way!) that isn't important.  I would rather have a conversation with a candidate and understand how he thinks, projects he has worked on, teams he has interacted with, etc.  The mechanics of programming can be learned easily on-the-job, if necessary.  
  • Hiring managers who focus on tool-based knowledge when advertising an opening.  They want to list every software package that the candidate may have to use.  If my company uses ClearCase for version control I really don't need to list that on the ad.  I would *never* choose one candidate over another based solely on whether she has experience with my version control product.  The "concept" of version control is what is important.  The tool-based knowledge is not.  Similarly, a lot of ads will mention required experience with SSIS, yet I wouldn't want to disqualify any candidates who have broad ETL experience, but with DataStage or Warehouse Builder and not SSIS.  Granted, if the primary skill is Oracle administration, a SQL Server DBA wouldn't be a good choice.  I'm merely referring to the software used on the periphery.  
  • Ads that mention "Sr Level Experience in Java.  Sr Level Experience in SQL Server, Sr Level Experience in C++" etc.  Again, this is tool-based knowledge and as mentioned above, the "Senior Level" qualifier is meaningless.  If I see this ad I know the company uses C++, Java, and SQL Server, and they think they need a guy who has been this for years.  I would rather see something like "Knowledge of C++, Java, and SQL in a high transaction online environment using SOA".  Less words, far more meaning.  

You must look for signs that he understands the development process. Does he understand the role of configuration management, or even what it really is? Does he understand the role of quality assurance, and why the QA group should be independent of and not report either directly or indirectly to the program manager? Does he understand what baselines are, and why you have to maintain all of them simultaneously? Does he understand what requirements are (i.e., they’re not something that you create, they are something that you discover through analysis and then document)? How many different kinds of development environments has he worked in? How many different business environments?
Lastly, is he fast? This characteristic hasn’t been mentioned before, and it’s difficult to gage without subjecting the applicant to a proficiency test (which probably won’t work very well anyway and is demeaning to applicants with any experience – you don’t want to start a new experience with an insult). You can, however, estimate this to some extent by asking him about the size of his previous jobs, how much he did personally, and how long it took him to do it.
Also, nothing slows a programmer down more than having an inadequate understanding of what he’s doing and why he’s doing it. If he has all the other essentials, then he at least has the potential to be fast.
The least important characteristic to look for, except in rare and extreme cases when you need it done yesterday, is familiarity with a particular programming language or a particular set of tools. Good programmers can learn these things virtually overnight.