How to excel at your Interview

Working as a programmer, I've had the chance to interview quite a few people. The best candidates where never the ones that knew the answers. As the interviewee, my direct and short answers did not help me get the job either. My experience tells me that in order to get a job, you have to do a little more then know what a Singleton is.

Is is going to be on the test?

The recruiter, whose primary job is to get you hired, bombards you with information and links to study before the interview. The scenario is not so different then the student who asks "is this going to be on the mid-term?" and hopes to get only the material that will be on the test. I had a different goal when I was going to school, so I always wondered if this kid was only going to learn what is coming on the test and nothing else.

Interviews are not that different. They are like your final and you need good grades to get accepted; at least that's what you are lead to believe. No one uses bubble sort on a daily basis, but this and linked lists are the most popular programming interview questions. Naturally, we read all about algorithms before the interview and recite them in the waiting room.

You may ace an interview with a 52ms average response time and still not get a call back. Why is that? You got the right answers but not the job? Well that's because, unlike in school, the interviewer will look for more than correct answers. Anyone who reads the job requirement and talked to the recruiter can find the right answers before hitting the interrogatory room; it does not determine your worth in anyway.

Getting an interview

Getting an interview is attributed to luck nowadays. For every position, there are enough candidates to fill the company over. Don't forget you are not only competing with the unemployed, but also the employed looking for better opportunities. If you send your resume by mail, you will have more chance if the envelop is neon green then a plain color.

The HR department will not go through every single letter they receive, anything that differentiate you from the herd will get you more luck. Put babies pictures on it if you have to, but be prepared to see your letter land in the junk mail pile.

If you write a generic cover letter that you plan to send to a million companies, don't be surprised if you don't get a response. If the format of your resume can distinguish it among a thousand, then the content is the meat that will keep your reader interested.

Don't apply for too many jobs. I don't think there's ever a reason to apply for more than three or four jobs at a time. Resuméspam, or any sign that you're applying for 100 jobs, just makes you look desperate which makes you look unqualified. — Joel Spolsky

I genuinely accept the standard curriculum vitae format, but in addition it should also reflect the line of work you are applying for. If your graphic designer resume can be mistaken for a warehouse associate resume, then you need to get back to the drawing board. Just like a UI professional resume should have a great UI.

A resume is not meant to be read by robots. It needs to be personal. If you are interested to work for a company, the least you can do is show interest. Check their website, check their work, check if you agree with them.

An interview is not like a test in high school. Not only you are being interviewed, but you are also interviewing the company. You will be spending the best part of your day working there, you might as well make sure you know what you are getting into before you start.

Don't be afraid to email people other then jobs@website.com. The worst they can do is ignore you. But we won't let that happen now would we? On the about us page, most websites have a list of the most influential people in the company. If they are on this page they probably did something important, and Google is your friend for finding out more. Don't just send them a generic message. Take time to craft it.

Write a nice message introducing yourself and why you want to work for said company. List the things you like about them and what you think you can do for them. Show your work. Mention that your resume is available upon request. Subject lines are hard to come up with, so leave it for last so you have plenty of room to think.

The more effort you put on your letter the more chances you have on getting a response.

Interview questions

Interviewer - Do you participate in online communities?
Candidate - Yes
Candidate - (silence) Interviewer - Do you use stackoverflow?
Candidate - Yes
Interviewer - How involved would you say you are?
Candidate - a lot

Direct and short answers are not your friends in an interview. Questions like these are meant to stimulate discussion. You can touch a lot of subject just by talking about your involvement in online communities. If I was asked the same question today, my answer will probably be a little longer:

Interviewer - Do you participate in online communities?
Me - Yes, I am mostly active on stackoverflow. In fact, the first time I used it to ask a question, I ended up deleting it because I figured it out before I even finished writing it. I provided my user profile on my resume by the way. If you notice, I have a lot more answers then questions. That is because I found that writing your question helps you understand the problem better and the solution naturally follows. I only post them if I feel the community can benefit from them. I would say, what I learned most from stackoverflow other then programming, is writing. [...]

There is no perfect answer. There is discussion. Most questions can be answered with a quick online search. Your answer need to be different, because there is a flock of candidates that will probably have the same answers as you.

If you are unfortunate enough to have to answer a linked list question might as well prepare for it. Read about it first to refresh your memory, then try to find the places where you implemented it in real life. Giving a little story is much more interesting then giving the a direct answer.

For example, the one time I worked with linked list was when I was trying to create a little game in C++. I used a state stack engine and I first started with an array to store the states. But then I had a problem because I could only get a set number of states. I didn't want to set my array to a constant size, what if I needed to stack more states? So I used a linked list to allow me to add as much states as I want.

With this story, I am letting the interviewer know that I developed a small game. Games come with their own challenges and are much more interesting to discuss then linked lists. We end up talking about pointers, singletons, and other things in their natural setting instead of theories.

A lot of jobs require you to be familiar with a particular framework. Let's say the jobs requires you to be familiar with Angularjs. You can try to learn as much as you can before the interview but that won't cut it. It takes time to really understand the framework. On top of that there are too many JavaScript frameworks, chances are you will not be familiar with the one for the job. I agree with trying to learn from tutorials, but the most important thing you need to know is what problem they solve.

It's much easier to talk about a subject when you know what it is used for. If you are experienced with JavaScript, it's only a matter of time before you familiarize yourself with any angular, jquery, backbone, or even threejs. The same goes for any language and its frameworks.

"How many golf balls can you fit in a school bus?" Do not prepare for this question. There is no a right or wrong answer, it is designed to evaluate your problem solving skills. You were probably asked this question or heard of it before. I think this question and the like are useless, although they sound reasonable in theory, the main reason they are asked is because the interviewer wanted to have an even number of questions, or thought it was fun.

How many pirates are there in the Caribbean?

The best way to improve your problem solving skills is by working on side projects. Something no one has asked you to do. It could be contributing to open source, your personal project, or just helping others. In each, you will find a set of challenges you would not have encountered when you are told what to do. I will insist on helping others because it is shockingly difficult to explain something that seems obvious to you to someone else.

Summary

• Your resume needs to reflect your line of work. A game developer and a web developer should not share the same resumé.
• Research the company you are planning to apply for. Know them in and out before making a decision to apply.
• Email the key people in the company. You can also send a separate email with resume to the email listed in the job description.
• Your resume is the selling point, take time to craft it for the specific job.
• Don't answer yes, no, or polymorphism! Each question is an opportunity for discussion.
• Ask questions too, you are interviewing the company. (they may not pass the test)
• Don't try to learn everything about every technology in existence, learn about what problem they each solve.
• You can't fake your problem solving skills. The only way to practice is to work on your own projects.

---

If there is one thing programmers hate, it's marketing. We don't hate it because we think it's useless. We hate it because we are scared of it. We are afraid of selling marketing our self. However everyone you ask will give you advice about interviewing. Well I hate to tell you this but sending your resume is marketing. You are selling your product, which may be your programming skills.

Having a good advertising campaign is one thing. Delivering on your promises is another. Your campaign is getting someone to want to read your resume. Your promise is showing that you are not only the best candidate for the job, but you have a unique voice. Let's polish that voice.

---