Having done a few horrible technical reviews lately, I figured I should post a little info to help prospective interviewees out. So here are some of my pet peeves that I run across during interviews (or on resumes) that will immediately get you removed from consideration.
Listing Skills or Technologies You Don’t Know
Seems obvious, but clearly it is not. If you list a technology on your resume (especially the harder ones or ones not strictly in your specialty), I’m going to ask about it. For instance, if you list all the technologies in a project you were on, but all you did was update ASP.Net pages and someone else did the WCF/SQL Server/whatever it is, you shouldn’t list it. Technology acronyms may get the recruiter’s attention, but I am going to ask you about it, and if you don’t know it, I’m going to assume your resume is a batch of lies. I don’t have the time to figure out what you do know so I’m just going to eliminate you.
And since we’re discussing technologies on resumes, stop applying bold to the technologies and phrases in a seemingly random manner all over your resume (STOP IT!!). While you may think it’s helping people skim through your resume, it actually harms the people reading it. So my impression of you is that you don’t understand users, and probably make poor choices when trying to build a system that interacts with people, because you can’t format a document intended for people to read.
Listing Clients as Employers
Your clients did not hire you as an employee, but a contractor. Those are very different scenarios. If you work for a contract house and worked on a project at Proctor & Gamble, P&G is not your employer. I have personally seen contractors list Microsoft as an employer because they worked on a project led by Microsoft Consulting Services. You were not an employee of Microsoft, you were a sub-contractor. You did not go through the extensive hiring process at Microsoft and pass. Someone at MS hired your company to provide developers, and not specifically to hire you. That’s not the same thing at all.
Brush up on Basics
If you are a developer whose main skill set is Java or .Net, you should know OOP basics. How about the four pillars of OOP? I am amazed that interviewees with 10+ years of experience can’t answer this question. If you know C#/Java/whatever, you should be able to tell me what the language keywords mean and their effect. I expect you to be able to write code in the interview. I don’t think you should be able to write up a connector for WIF, but some basic coding without the benefit of Uncle Google is a prerequisite.
Opinions
I am consistently shocked by the number of developers who won’t express an opinion, on even the simplest of questions, like what do you like better about C# compared to language X?. I don’t want team members who won’t tell me what they think or even tell me if I’m wrong. I’m pretty sure if you can’t express your opinion in an interview you can’t work on my team.
Look up your Interviewer
Again, seems pretty basic, but it doesn’t happen. I know the recruiter gave you my name. In almost 10 years of interviews, only two people actually looked me up ahead of time. If you are reading this before I interview you, congratulations, you are on the right track, but I’m pretty sure you are the minority. This is an easy way to demonstrate some initiative.
Listen
Again, I can’t believe I have to write about this, but listening to the interviewer is kind of important. I can tell when you aren’t listening to what I say, and if you can’t listen to me in the interview, why would I think you would listen to your team once hired?
Ask Questions
If your only question is what is the project this interview is for, I’ll just assume you are just another contractor looking for a gig and not looking for a career at my company. Again, I don’t want you. If you don’t know anything about my company going in, I’m going to assume you are lazy in your work as well.
Learn About Tech Interviews
Do yourself a favor, learn about tech interviewing:
What Great .NET Developers Ought To Know
