Technical Interviews

In my career I've done numerous in-person interviews, phone screens, technical evaluations, skill tests etc both from the employer and employee side and it amazes me the number of people who seem to bomb job interviews.  Normally, a person decides if they want to hire you within the first few minutes of an interview.  So you literally have only a couple of minutes to sell yourself to a potential employer.

Here are some common mistakes I've seen in interview and how to avoid them:

1. Being too general.  If an interviewer asks you about your experience the likely answer is to give a high level overview (C#, ASP.NET, SQL) which doesn't tell the much.  Likely since you're being interviewed they already know this information.  Instead, talk about what do you with the technologies you use.

I've heard countless interviews where the interviewee will describe their experience by merely listing out keywords: "C#, SQL, ASP.NET, Web Service, SQL, Oracle..."

A better example, "I primarily build ASP.NET sites using C# and ASMX web service.  On my sites I use the AJAX toolkit to communicate to the server to get combo box values and dynamically load content based on user selections.  I also use JavaScript for client-side validation of user input."

You might also throw in any applicable controls you've used that employer might be looking for.  Example (continuing from the fist example): "In my most recent project at ABC I've been using the RAD controls for data grids that display accounting information that the user can edit which is 2-way data bound to my Entity Framework business objects."

2. Overstating your qualifications.  Generally, questions like "What is your experience with x?" is a setup question.  If you answer "Yes" then you'll probably get 3-4 more follow-up questions.  Be honest about your experience with a technology and what you have done with it.  If you don't have any experience then a good answer is "No but I'd like to learn more about it and work with it."  Additionally, try and take a positive spin if possible and talk about a similar technology or approach you've used in the past.  Example: "I don't have experience with Biz Talk but I have used Windows Workflow before to create processes and tie business processes together."

3. Being an interview killer.  Killing an interview is where you say something (or several things) that will automatically disqualify you to an employer.  Listening is key to getting a job.  Listen to what the interviewers say.  If they have a different lingo for something; use their lingo.  For example if they call XML returned from a web service a "payload" then call it a payload when you talk about it instead of an "XML string" if that's your word for it.  This tells them you are listening and helps show that you can fit in and adapt to the team.

Additionally, don't contradict the position you are interviewing for.  For example, many times I will tell someone the position is a UI or back-end job and they'll later state their preference is the opposite (or something different) of what we're looking for.  If the job is not one you want; don't interview for it.

Last, don't be absolute about how you do things.  For example, "I would never hard code SQL into my application."  This can make for tense moments and give a bad impression if this is a habit or approach your potential employer is taking.  You might say instead, "Normally, I don't hard code SQL into my application I keep it in the stored procedure but there are circumstances I would do things differently."

In review, always talk about what you've don with the technology (not what technologies you know), be honest about your qualifications and turn negative into positives by talking about similar technologies or approaches taken in the past, and don't kill the interview; listen, use their terms, and don't be absolute.