I recently saw a short piece by Deborah Walker about "stupid interviews". I'm sure most of you have had them, those interviews where for some reason the interviewer isn't prepared. Their server crashed, they just got back from vacation, some project is late, etc. They haven't thought about what to ask and aren't really sure how to interview you as a DBA or developer.

Hopefully you're the first interview and there really is some good excuse. If you are in the middle or end of a long list of interviewees, the this might not be the company that you want to work for, but be careful about how you find that information out.

It's a Dud, Now What

The short piece I read talked about being prepared to ask two questions: What are the greatest challenges in filling this position and what are the most important qualifications the company is looking for? The advice is to slip these in at the end and then be prepared to follow them up by giving examples of how you fit that mold. Personally as someone that's hired people before, that looks like what it is, last minute tailoring. But that doesn't mean the advice is not good advice.

I've walked in on any number of these interviews and here's my advice. First a small disclaimer, this is really for someone that has experience in the position they are applying for. It's not necessarily for a beginner.

Take charge of the interview. If the person interviewing you isn't prepared, doesn't have a list of questions, no test on T-SQL, etc., then help them out. Chances are that they're overworked or always unprepared and will be when you sit side by side with them. This is your chance to show them you can take care of yourself as well as help them a little.

If I hear about some excuse, I usually probe and ask a question about it. What happened? Server crash? Give an answer from your past in how you dealt with a similar situation. If they're just buried, "Is it always this busy?" or "Are you hiring to ease the workload?" are questions I've asked to get a feel for the company. From there you can give your own responses or suggestions to show the interviewer how you fit in.

It's important to note that I'm not looking to suck up or make this a perfect fit. That's easily spotted and won't help your images in most cases. I give honest answers that are relevant feedback based on the information that I'm learning. Not having any relevant experience is also a valid answer and if you've never had a RAID card crash when that's the current scenario, tell them that. Show them you're interested in learning. And more importantly, you're interested in helping if you can. It's an interview, but if you could help someone, that scores big points.

Another thing you might use to take charge if things slow down is ask about your co-workers or team of people. I've asked to meet them in almost every interview because I think that being a part of a team is important. If you think working in a dark room is important (and I've had friends that do), ask to see the area. Lead the interview along lines that help you to learn more about the company as you stress your strong points.

Remember the interview is a two way street. You want to be sure that this is a place you want to work as much as they want you.

Preparation

That brings us to the pre-interview. Regardless of whether the interviewer is prepared, you should be. You have no excuse at all for going to an interview not knowing something about the company much less yourself.

Preparing for the company is the easy part. Check out the website, Google people's names or their products, try to learn something about their business or industry so that you can be somewhat informed about what the company is all about. It's easy for corporate developers to think that the business doesn't matter and they can just code, but that's not the most effective way to be productive. The best developers in any position are those that understand the domain and the boundaries as well as the rules of what they're trying to develop. If you can't handle complex math and statistics, mortgage risk programming probably isn't something you'll do well at. The same thing applies if you don't understand how products are actually moved across the country; you probably won't be highly effective at supply chain prediction. I've spent 15-20 minutes on every company since I left college and it's yet to fail me in an interview. It also prevents 15 minutes of wasted time having someone give me the company history.

The hard part is preparing yourself. All those sites out there that talk about the basic questions you should be able to answer are good practice Monster has a random question generator you can use, but there are plenty of books and sites that are similar. My advice is to practice talking out loud. Your spouse might think you're a little strange, but it helps you to speak clearly and smoothly. Remember, you'll be nervous during the interview, so every bit of practice helps.

Use a watch or stopwatch to be sure that you don't ramble on and on. A minute of talking is a long time.

Be honest with yourself. By this I mean pick the hard questions about your failures, your problems, etc. and work on developing good, honest answers. If you yelled at your boss and walked out on a job, you might want to present that a little differently, but if someone asks if you quit your job, be honest. You never know when they'll find out and it could cost you a great job you love AFTER you've gotten it. You want to be sure that when someone asks about your failures, you can talk to them. We've all had them and trying to present a perfect past doesn't ring true. After all, you ARE looking for a new job for some reason.

Answering those questions for yourself, will also help you to take stock of where you stand, what you're confident in, and what you're not. If you need to take charge of an interview, then you know where to steer things. It will also help you not to have long pauses trying to think of something to say or answer some questions. As an interviewer I hate 30 second pauses while someone thinks. If I ask about your best or worst job, I expect a quick answer.

Lastly, take stock of your technical skills. Know what you do well and what you don't and have some examples ready. Nothing impresses in a technical interview like some real code that you are proud of and solves an interesting (and hopefully business related) problem.

Conclusion

I've written about being on the other side of the fence (Who Do You Hire?) as a hiring manager. However, I'm sure most people reading this are the guys trying to get hired, so between the two articles, hopefully I'm giving you some hints on how to get the job that you want and that's right for you.

Applying for and getting a job is always a sensitive subject with advice across the board from many different people. If you've got your own advice, or want to debate any of the points I've made, drop a note using the "your opinion" button below.

©dkranch.net 2004

Return to Steve Jones' home