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 who had all the answers. As the interviewee, my short and direct answers did not help me get the job either. In order to get a job, I had to do a little more then just knowing what a Singleton was.

Is it going to be on the test?

The recruiter bombards you with information and links to study before the interview. Their goal is to get you hired so they can get those sweet commissions. For candidates, it's like being that student who keeps asking: "is this going to be in the mid-term?" That student is not planning to learn anything, just pass the test.

In school, I had a different goal. I was there to learn. When learning, I needed to know the Why? Why does the programming language work this way? Why is this sorting algorithm faster? Why is this important at all?

Interviews are just like those final tests we take at school. You need the good grade to get accepted. Yes, no one uses bubble sort on a daily basis, but together with linked lists, these concepts are always brought up during the interview, and you need to have answers. 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 judge you for more than just correct answers. Anyone who reads the job requirement and talks to a recruiter can find the right answers before hitting the interrogatory room. But that's a poor way to determine your worth.

Getting an interview

You have to be incredibly lucky just to get an interview these days. For every position advertised, 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 chances if the envelope 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 baby 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 single 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

A standard CV format is fine, but 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. Your 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 in working 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 are you 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 than 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 of 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 on a lot of subjects 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 than 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 than programming, is writing. [...]

There are no perfect answers. Just discussion. Most questions can be answered with a quick online search. Your answer needs 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 a direct answer.

For example, the one time I worked with a 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 many 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 than 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 job 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 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 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 a 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 ourselves. 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.

---