3 Handy VB.NET File Functions You Can UseLink Round-Up for 9/27/07

An Undercover Guide to Programmer Job Interviews

September 25th, 2007

A job interview is a lot like a blind dateSeveral of my recent articles have dealt with interviewing programmers. This time around I’m going to sit on the other side of the conference room table. I was given some of these interview tips from professional recruiters plus I’ve added some of my own observations drawn from my own experiences.

It is common these days for one to have upwards of 6 to 8 separate interviews with people of all different levels and positions. If you flub one part of the interview, then you may not get the job. Let’s look at dealing with these different levels/positions.

Dealing with Human Resources

These people are usually the gatekeepers of the company. Some act as your friendly tour guide to the company while others can be a bureaucratic nightmare to deal with.

The first type is easy enough to deal with, just be courteous and polite. Ask a few general questions that reveal your interest in the company. Don’t delve too deeply into benefits (for example, don’t ask “How are your substance abuse benefits?”) but ask reasonable questions about them. After all, you don’t want to be surprised by a lousy benefits package after you’ve accepted the position.

The bureaucratic type is the personification of Dilbert’s Catbert, a person who seems to take delight in tormenting interviewees and employees alike. They’ll have tons of legal paperwork for you to fill out, psych tests, and so forth. They’ll insist that you fill out a 5-10 page application by hand even though you have a perfectly good resume. They’ll talk about personnel plans like the vitality curve and other things that make employees miserable and at each other’s throats. Generally this person is on a power trip and this is usually a good indicator of a messed up company. Do you really want or need to work for this company? If so, grin and bear it. Otherwise, bow out gracefully and head for safety.

Of course there is a lot of room in between these two but the HR person will usually give you your best initial feel for the culture of a company.

Dealing with Non-Technical Persons

If you do interview with a non-technical person they’re probably going to be someone who you will be working with or for, either directly or indirectly, on the project that’s being staffed. Avoid getting deep into technical details but try to draw high level parallels between what you’ve done in the past and what they want done. For example, they’re wanting to build a document manager for insurance claims and you’ve done a similar project with auto loans. Let them know in confident, but not cocky, terms that you can help them due to your previous experience.

People in these positions are also good indicators of company culture outside of IT. Watch for warning signs of a dysfunctional organization or, hopefully, indicators that people really do like working there.

Dealing with Executives/Owners

When you interview with a member of executive management or, in smaller companies, one of the owners, it’s best to deal with abstracts when it comes to technology and dollars and cents issues when it comes to business. They’re going to be paying a lot of money for your time so you want to make sure you look like a good investment for the long term. Stick with topics like how your work has improved efficiency or increased ROI at your previous employers.

Mild flattery can help here too. Show them that you’ve researched their company by saying something like, “I noticed that you’ve been in business since 1996.” or “I read that you won the Human Fund’s Costanza award last year.” Just don’t lay it on too thick, they’ll see through it more than likely. Also, be careful about stumbling into something that might better be left unsaid. A faux pas at this level might kill your chances.

As for company culture, they usually aren’t the best indicator of it. They usually imagine that their employees are all happy campers and often don’t see cultural problems developing until it’s too late.

Dealing with IT Managers

Sadly, many of these people moved into management from programming, or another technical field like network administration, and, for their efforts, have become little more than bureaucratic paper pushers. They will generally be fans of processes, metrics and other busy work. The worst ones will be micro-managers and choleric jerks. Others will be nice but obviously lacking technically. Others, the good ones, will have technical savvy. You can generally get the feel for the situation quickly by seeing what kind of questions they ask and how they answer your questions.

If you’re being interviewed by Bill Lumbergh, you know it’s time to retreat unless you’re desperate for work. If you must stay in the battle, mention your love of metrics, well documented processes and your willingness to work on weekends.

The nice but non-tech guy/gal can usually be bedazzled by throwing out hot buzzwords like AJAX, Agile and Scrum, or just about anything else you can gather from the front pages of DZone, ZDNet or other popular tech sites as long as it seems to fit in with what they want to do. Don’t overplay your hand though because even if they aren’t up on things, somebody on their staff probably is and you may be called on it at some point.

The technically savvy manager, in most cases, will be your best or worse interview. It will be the best if you know your stuff and present yourself well, but the worst if you try to BS your way through. For the best results, treat them like you would a senior, knowledgeable, peer. If you impress them you’re more than halfway there.

Dealing with Other Programmers

These guys/gals should know both the technology and their problem domain. You may have a technical edge on them but don’t be a show-off about it. That’s a good way to get black balled. Listen attentively to what they say about their problem domain and, if given the opportunity, ask about a few details to show your interest. If you try to scam them with buzz words you’re very likely to fail and, if you do manage to dazzle them with BS, it probably isn’t the right place for you to be working anyway.

Remember that mess of an application or web site they share a few details about may be somebody’s pride and joy. Therefore, don’t talk about any design flaws you may notice without being invited to comment directly on them. Treat it just like you would treat a parent who just proudly presented you with a picture of their ugly baby. Likewise, if you’re awestruck by the perfection of their development methods you may want to find somewhere else to work if you know your skills aren’t up to the challenge.

Show them that you have a sense of humor but don’t go overboard into creepy, annoying or goofy territory. You want to be someone they wouldn’t mind hanging out with at lunch or after work. Smile and be friendly, even if it hurts.

If the programmers you interview with are obviously lacking in skill, this could be a warning sign. You may be handed the responsibility of improving things which can be a daunting task. If they hint at morale problems or other troubles, this should be a big red flag to you. Ask them to provide a few details about the work environment so that you can get a feel for what you may be getting into.

Ultimately, these people will usually be your best source for information about the inner workings of the company and will have a lot of control over the hiring decision their manager makes.

Well, this article went on for a little longer than I expected. I’ll have to follow it up later. Let me know if you thought these hints were helpful or not. Feel free to throw in your own hints and tricks and if you disagree with what I said. I always welcome your opinions and perspectives, even if they’re different from mine.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Personal Development

Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (No Ratings Yet)
Loading ... Loading ...

1 Comment Add your own

Leave a Comment


Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed

Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles


Most Recent Articles


 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities