The dreaded technical interview. The bane of any programmer that’s not sure of themselves. I’ll admit to being nervous in every interview I’ve ever been in, even though I’ve gotten an offer nine times out of ten. (I’m very good in an interview).

I know that I typically make it worse on myself than I need to though. I get nervous over stupid stuff and flustered when I’m asked about something that I don’t feel like I know enough about. But I’ve also found that if I can focus on just a few important points, things seem to go a lot smoother.

There’s a great article on technical interviews from the interviewer’s perspective that has a lot of lessons for interviewees as well. I suggest you read it to see how a real interview should go.

Of course, no technical interview will ever go like that. All of the mistakes that he lists are exactly right and it may put you at a disadvantage if you don’t interview well. But I’ve learned a lot through all of my interviews and this is rule number one:

The interview is there for you to convince the hiring manager you can do the job.

Yes, yes. Captain obvious, I know. But many people seem to forget this fact and, even more interestingly, the person doing the interview seems to forget this fact sometimes, especially if they’re technical and want to ask all the complicated Shortest Path questions.

But here’s the secret, most of the interview doesn’t even matter, especially the technical part of it. What really matters is what I said above, you need to convince the manager that you can do the Real Job he’s looking for you to do. Here’s how:

Figure out what the Real Job is as quickly as possible.

You won’t find this in the job description or from the HR people.

Job descriptions are typically generic lists of skills (many of which you probably don’t even need) and a vague, useless description of what the job might be. It does not tell you what you’ll really be doing or, more importantly, what your manager will need you to be doing. Job descriptions should be used as a general guideline for the skills you’ll need to have (or need to acquire) in order to apply for the job.

HR has no idea what the job will entail. After you send in your resume, they will probably want a phone interview. This phone interview is only there for you to reiterate what is already on your resume and convince a person that has no idea about technology that you aren’t trying to trick them. HR’s only goal is to make sure that if they bring you in for an interview, it won’t make them look like an idiot.

So when do you figure out what the Real Job is? When you’re talking with the actual person looking to hire you. This could be the manager or the technical team lead of the group that you’re looking to join, usually both. They’re going to start asking you some generic questions that they ask everyone. At this stage, it is now your task to derail this interview from their generic questions and get them talking about their problems. These problems are the Real Job.

Figure out the Real Job and then explain how you can solve it.

They probably won’t be forth coming with this information, so ask questions. Nothing will make you look better in an interview than asking questions about the job. Why are they looking to hire now? What kind of project are they working on? Who will be the users of this project when it’s done and what are they’re problems?

Don’t think it makes you look presumptuous or nosy, it makes you look interested and knowledgeable. Always try to direct the conversation to figuring out what they need help with. The more they talk about themselves, the closer you’ll get to figuring out what they need and where you fit in.

Try to match past experience with the Real Job.

There is typically one central reason that they decided to try and hire now. Do they need another developer to put on a project to get it done sooner? Explain how you’re a quick learner and what you learned in the past quickly to get something done. Are they looking for someone to help them transition to a new tech platform? Explain how you know that platform and how you taught it to others to get them up to speed. Start answering all of their questions in the frame of what they’re current problems are. Craft your past experience in terms of solving problems just like theirs.

You’ll notice that I didn’t even talk about the actual technical aspects of a tech interview and that’s because they aren’t that important. If you don’t impress the tech heads in the interview, but you blow away the manager that has the actual power to hire you, they will probably hire you. Solving problems is important, knowing the difference between a bubble sort and a whatever sort is not (I honestly can’t think of another kind of sort off the top of my head because it’s not important!) Show them that you’re inquisitive, personable and is someone looking to solve problems, and you’ll probably be at the top of the list for the job.

Skills can be learned and details can be Googled, but gumption is rare and the people hiring know it.