Technical Resumes and Interviews

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.

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 MCS. 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 Microsoft 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.

Ask Questions

If your only question is what is the project this interview is for, I’ll just assume you are a 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.

Read These

Do yourself a favor, read about tech interviewing:

• What Great .NET Developers Ought To Know
• On Interviewing Programmers
• The Guerrilla Guide to Interviewing