Job Interview Tips

By Robbe D. Morris

Printer Friendly Version

Robbe Morris
Robbe & Melisa Morris
My how times have changed.  In the late 90's, all someone had to do to get a software engineering job was to claim they had experience and be able to quote acronoymns.  In return for granting a company access to our vast experience, we expected gamerooms, naptime, and afternoon milk.  Our workplaces often more closely resembled kindegarten class rather than an office.  This was one of the things I disliked the most about being an engineer during that time.  Well, that lack of focus on productivity and cost control has finally caught up with us as a group in the form of large scale layoffs.  Rather than be perceived as cost saving employees, we are viewed as one of the most expensive portions of the workforce that seldom live up to expectation.  Thus, making us prime targets for the tough decisions management has to make in order to cut costs.

This has really hit home for me at the company I work for as well as watching friends and family members loose their jobs.  On top of that, my first son (Caeden) is due to come into the world in May adding to the stress of trying to make sure I stay employed at or above my current salary in order to provide for my family.  So, I've been thinking of those who are having a rougher time than I lately.  It is one of the reasons we offer free job postings on the web site now.  I also wanted to take some time and share a few thoughts on job interviews that were shared with me a long time ago.  They have helped me obtain over 95% of the jobs I've interviewed for in the past.  I think you'll find these to be helpful to you as well.
It may sound strange but your ability to listen to the question and provide a specific answer will make or break the interview.  If you are able to really hear the questions and provide brief yet specific answers, the interviewer will find the conversation fruitful and ask more and more questions knowing they are going to get the answers they need.  You'll find that in many cases, the interviewer will ask fewer tough questions that you may not know the answer to.  Plus, you've demonstrated your communication skills rather than just claiming that you have them.  A good interviewer will spot this as a rare talent and move you towards the top of the list of candidates.
2.Avoid using the word "I" when discussing projects you've worked on.
Always try to use we instead.  It is a great way to reinforce the notion that you are a team player and willing to accept any role that management asks to you to play without actually saying it.  The interviewer will undoubtedly ask you to describe your specific contribution to a project out of curiousity because you didn't mention your role.  Simply by using we instead of I, you've not only portrayed that you are a true team player, the interviewer is now paying close attention while you describe your own achievements.
3.It is alright to say I don't know
If you are asked a question that you really don't know the answer to or aren't sure of, just say I don't know or I haven't worked in that specific area in awhile.  Good interviewers will ask you questions designed to get you to try and BS your way through the answer.  A candidate who has a tendency to bend the truth during the interview process is likely to do the same after they've been hired.  Believe me, your honesty is of far greater concern than your made up answer to some obscure question.
4.Know the interviewer
It is crucial to get a good feel for the personality, skill level, and expertise of the person or persons interviewing you in the first few minutes of the interview.  You also need to fully understand how the interviewer sees themselves in the organization.  Everyone likes to talk about themselves and their accomplishments.  At the beginning of the interview, simply ask them to elaborate on their job duties and the projects they work on.  Besides generating a rapport with the interviewer, you'll know what level of technical jargon to use when answering questions, slang or lack thereof in your conversation style to match the interviewer, and does the interviewer view you as a potential threat to their own career goals.
If the interviewer is a manager but has only a small understanding of technical jargon, take this opportunity to shine.  Before discussing complex topics, simply ask the interviewer Have you had a chance to really dig into x?.  This allows them to say they are familiar with it but don't truly understand it without making them feel inadequate.  You now know that you need to use lamens terms when describing your past work.  If you've done a good job here, you'll not only have an interviewer that fully understands your past successes, you've demonstrated that you can be a useful resource without being a threat to their competence.  A great way to prepare for this scenario is to practice trying to explain what you do with someone who really doesn't understand software.
If you are interviewing with the senior engineer on the team, it is imperative that they walk away from the interview thinking of you as a subordinate and not an equal.  This is true whether you are interviewing for the same job grade or not.  Keep in mind, this person most likely holds veto power over new hires and will likely excercise it if they feel threatened.  Besides, if you really are a stronger engineer and desire to be higher up on the ladder, you'll have plenty of time to prove it after you've been hired.  However, during the interview process, you'll want to preface your answers with phrases like: I think I can free up some of your time by doing x so you can focus on more advanced areas, I'll be looking to you to help take me to the next level when working with x, or When you look at my skills and experience, where do you think my abilities will help you the most?.  In other words, always position yourself as their subordinate and a tool to make them look good.
And, of course, don't forget the junior engineer especially if you are taking part in a group interview.  The senior engineers often dominate these discussions.  Do your best to include the junior level people in the conversation by asking them questions or even relating your answers to things the junior level folks are working on.  When you demonstrate an interest in them, you show the IT manager that you are interested in the strength and well being of the team.  Plus, the junior level engineers will begin to think of you as a partner and not just another senior engineer that will look down on them.
5.Bring examples of your work
Bring a floppy or CD disk with your source code and applications on it to the interview.  Bring 3-5 copies to hand out to interviewers.  This demonstrates confidence in your coding skills and gives them one more tool to evaluate your talents.  Senior developers will skim over your code looking to see if you write code with an organized mind.  Easy to read and follow source code speaks volumes as to how good an engineer really is.  Plus, you've now got an excuse to send emails after the interview with updated code or a new application to add to the sample based on what transpired in the interview itself.  The more you communicate with the interviewer(s), the more likely you are to get called in for the second interview.
6.Speak positively about past employers
There is nothing to be gained by airing your dirty laundry from a past employer.  IT Managers are looking for positive employees and not those who are likely to voice their concerns in a negative way that could someday change the atmosphere surrounding the team they've tried so hard to build.  It is also important that you not be perceived as a potentially dangerous employee should you ever need to be laid off or fired.
7.Always have questions of your own at the end of the interview
This shows that you have more than a passing interest in obtaining a position with the company.  Plus, there really are a few areas you should ask about.  Here are a few good examples that will shine the spotlight on organizations they may be going through tough times: When was the last time an engineer voluntarily left the company and why?  What is the average tenure of the IT staff?  What is the one thing they would change about the organization if they could to be more successful?  Did they meet or exceed their revenue goals for last year or last quarter?  Were they happy with the merit increase or bonus received last year or last quarter?  Body language more than the actual answers themselves can tell you a great deal.  Pay close attention to it.
There you have it.  I hope you've found these tips useful and you find the job you've been looking for.

Robbe has been a Microsoft MVP in C# since 2004.  He is also the co-founder of which provides .NET articles, book reviews, software reviews, and software download and purchase advice.