Rocking Your Job Interview
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on March 21, 2012 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
One of the things about the PHP field is that developers are highly sought after, and good developers are prized. While anyone can slap “PHP Developer” on their resume, most companies have gotten good at weeding out the pretenders from the real deal. This means that for a highly qualified developer, interviewing should be an easy step towards receiving an offer.
Of course, the interview process is not always about the person, their qualifications, or their skills. Sometimes it’s about personality, team fit, or corporate culture. Those interviewing you may not be the people you work with daily or even semi-regularly. They may be HR people, vice presidents, leaders of product management teams, sales people, or others. As a highly qualified developer, it’s important to understand the audience.
Know your technical details thoroughly.
This might be seen as “going without saying” but the number of people who walk into a technical interview totally unprepared for a technical question is amazing. Usually in five minutes I can tell whether or not someone is prepared or even qualified just based on one or two simple technical questions. Paul Jones has written on this, saying that some developers talk about frameworks when they should be talking about PHP code, and elaborates in the comments that some developers can’t even escape SQL queries without their framework helpers. Don’t be this person. Know your technical material inside and out. Be able to show code samples and write sample functions with ease. Know the languages you claim on your resume.
If you’re a PHP developer in need of a refresher of the basics, Laura Thomson and Luke Welling have a great book on this topic (disclosure: Laura Thomson is my immediate supervisor at Mozilla).
Know the role of the person interviewing you.
The single most important thing you can learn about a person is what role they have in the company. Talking to a Vice President of Marketing is very different from talking to the team lead you’ll be working under. Technical answers are required in the latter but probably frowned upon by the former. More and more companies are expanding their interview process to include numerous individuals who may or may not have anything to do with your direct role, evaluating you in terms of “culture fit”. These cross-department interviews mean you’re meeting with people that think quite differently than you do, and it’s important to be able to relate to them.
Be able to turn technical answers into non-technical answers, and vice versa.
A corollary to the previous statement, in any interview it’s critically important to be able to take a technical answer and make it more simple for ease of understanding. This is also a critical job skill, especially in companies that might have developers help marketers write releases or documentation. Being able to distill technical information into simpler explanations is a skill that will serve any developer well.
On the flip side, when technical answers are necessary, developers must be able to start simply and expand as required. A lead developer is going to want a much more technical explanation than a sales representative, but may be looking to see that you have basic knowledge of a technical area, or may want to investigate your advanced knowledge of a given subject. Being able to scale your technical discussions, along with reading the wants and needs of the interviewer, will allow for targeting an answer to their specific level of interest.
Learn how to be personable.
I’ve often thought that if I can get an interview to laugh, I’m 50% of the way there. This isn’t because of any secret manipulation technique I have; it’s simply the reality that we like to like those similar to us. Laughter bridges the gap of difference and makes people seem more like us, because we’ve shared something – in this case, humor.
The problem for most developers is we’re great with code, but not with people. This works alright when being interviewed by other developers (who are interested in technical topics) but doesn’t work so well when the interviewer is a non-developer. An excellent way to develop some of these skills is to become familiar with that famous book, How To Win Friends and Influence People by Dale Carnegie.
Ask thought-provoking questions.
Speaking of How To Win Friends and Influence People, Dale Carnegie tells a story about a young man who asks an older man a thought provoking question. The older man in turn talks and talks, leaving no room for the younger man to say anything. At the end of the time, the older man exclaims to a colleague how brilliant the younger man is, even though the younger man said nothing beyond his question.
Asking thought provoking questions, and allowing the person giving the interview to do much of the talking, is a sure way to leave a good impression (since you can’t say anything that would otherrwise damage your image). But the question must be thought provoking, appropriate and relevant – this is the key. And you have to care about the answer – it may even be an opportunity for you to interview the company.
There aren’t any sure-fire ways for getting a job, but there are ways to improve the chances of being hired or called in for further rounds of interviews. Being liked, being competent, and reading one’s audience are as close to sure-fire as one can get without having someone on the inside.
Learning design patterns doesn't have to suck.
Design patterns open a whole new world of possibilities. So why are you avoiding them? This brand new book will help you finally understand these wonderful programming techiques!Learn design patterns TODAY »