When talking about interviews, most programmers are interested in the technical interview. And why not? It’s what we know. We think that if we can solve a problem on a whiteboard, we should get the job. Meritocracy for the win!

But at most companies, it really doesn’t work like that. The management in charge of the programmers will always have the last say in whether you’re hired or not. What they want to know is, “Can this person do this job?” and more specifically, “Can this person solve the problem that we’re hiring for in the first place”. Every piece of what you go through in an interview is geared towards determining that, including the tech interview with the existing programmers.

Remember every job posting was posted because there is an immediate problem that needs fixed and that problem will never be included in the job posting. The job posting will say how fun a place the company is to work for and what kind of skills they want you to have and that you should be “hard-working” and “ready to work at a fast paced environment”. But you need to remember that there is a problem that has popped up that caused this job listing to be posted now and not last month.

If you can figure out this problem and position yourself as the solution, everything else becomes a lot easier.

So, if you can prove directly to the hiring manager that you can solve this problem, that can sometimes short circuits any objections that they may have in other areas. The following has landed me many jobs after only one interview, including having one manager follow me down to the lobby after the interview and tell me, “You’ve got the job. We just need to follow procedure and finish the rest of the interviews. Please, don’t take another job until then.”

It’s a good feeling. :)

Key Phrases to Use

“Tell me more about that.”

In most of my successful interviews, I’ve talked less than the person that’s interviewing me. Always be looking to ask questions to 1) show that you’re interested in what they’re doing and 2) to get them excited about getting their problems fixed. While they’re talking about their problems (and they have some, that’s why they’re hiring right now), you’re looking for places to say the things I’ve listed below. If you can present yourself as the answer to their pain, you’ll have a huge advantage.

During this questioning, you should be looking to say the following phrases:

“Yeah, I’ve done that.”

At every opportunity that you can, you want to say these words. You should always keep in mind the things you’ve done in the past and be ready to apply those experiences to the conversation at hand.

“Create a Laravel web application? Yeah, I’ve done that with company ABC and they’re using now as their main platform.”

“Fix up a Ruby on Rails application? Yeah, I’ve done that and made some extra tweaks to improve it’s performance from 300 millisecond response times to 50 millisecond response times.”

And it doesn’t even have to be exactly the same work, but if it requires the same solution, use it.

“Search for all locations near a given zip code? Yeah, I’ve done that by using an SQL function to calculate distances between two addresses.”

The point here is letting someone know that you not only can do what they’re hiring for, but you’ve already done what they’re hiring you for and that you can bring that experience with you on the job. Managers love it when they know you’ll start adding value right from the minute they start paying you, so make it absolutely clear to them that that will happen if they pick you.

“Yeah, I’ve done something like that.”

This is level two. If you can’t say “I’ve done that” at least try to say this.

“You build web applications using Java and Spring? Yeah, I’ve built Java web apps, but I’ve mainly used Struts in the past. I know that Spring is a more modern take on MVC in enterprise Java and I’ve been looking into it.”

See all that gobbledygook at the end? That’s research. Even if you haven’t done it directly, you need to be able to talk intelligently about it to relate the skill they’re looking for to the skill you already know.

Look at the list of skills in the job description. Take any that you don’t know and look them up online. Do they kind of relate to things that you already know? Remember that and use the above technique in your interview. Heck, with all the tutorials out there about everything, learn it before the interview so that you can talk intelligently about it. Mention what you love about it, how it handles dependency injection for you, how it’s templating language is so much clearer than regular JSP, whatever. You might be scared that you’ll come off sounding like a newb, but you’ll sound like an interested newb who isn’t afraid to learn and that’s really what people are looking for.

Most interviewers know that they aren’t going to get lucky enough to have someone come in and perfectly match everything listed in their job posting, so showing that you’re willing to learn and have related experience (and attempt to pick it up before the interview even starts) will make you stand out in their eyes.

“Yeah, I could learn that like I learned this.”

I’m going to admit that this is the weakest avenue to go down, but it’s a good fail-safe when you’re surprised with something that you didn’t know about before hand.

“Have you ever worked with [obscure technology]?”

“No, I haven’t. Could you talk a little about it?” (Always get them talking.)

“Blah, blah, blah.”

“That sounds really interesting. I’d love to learn more about it. I was able to pick up XYZ pretty quickly and this doesn’t sound too hard to learn either.”

Basically, the idea here is to show that you know how to learn and can apply that to this job too.

Takeaways:

• A job is only posted because the company has a problem.
• Your job in the interview is to identify that problem and show that you are the solution.
• In a job interview, your interviewers should be talking more than you.
• Illustrate that you can fix the problem they have or are someone who can learn to fix the problem they have.