Interview red flags for the IT consultant

Sometimes the new IT consulting gig you're walking into is a mess. These early warning signs might set off your inner Geiger counter.

For a number of years, I've practiced IT as a consultant rather than an employee, meaning I pop in and out of various companies for six to 18 months at a time. There's always a conversation up front during which the task is spelled out to me, and we see if it's a good fit.

The thing is, there's a quality spectrum to deal with: Some projects are exciting and progressive, some are necessary drudgery, and a scary few are nuclear meltdowns, requiring a sacrificial technician to wander into the hot mists. One way to detect potential meltdowns is to pick up on the early warning signs and then ask the right questions from the start.

Interview questions that are red flags

"Do you have experience with application support?"

There isn't anything farther removed from the typical IT consultant's range of interest than application support. Most of the time it doesn't come up -- it's much more likely to surface as a necessary evil in an interview for a staff augment gig.

But when a project is crashing and burning and consultants are being rapidly hired, that usually means a system in production has gone haywire and no one knows how to fix it. The project will involve rebuilding the app as well as propping it up in production in the meantime, or, at the very least, reverse-engineering the existing mess to the point that you can teach someone else how to prop it up. Do you really want a piece of that?

"Would you be comfortable working with products that are no longer supported?"

If a production app is wigging out, oftentimes it's because the legacy app is built out of parts and pieces that no one in-house has on their shelf -- the technology is so outdated that the current crop of developers are all newer than the legacy app platform. This also explains why a consultant is brought in to fix it. Most consultants have been around awhile and have hands-on experience with obsolete technologies. I was in this situation in the past year, dealing with an Adobe PDF generation system that was deployed during the Clinton administration.

If this kind of thing doesn't float your boat (it floats mine!), steer clear of it, because there's usually no surviving documentation and no one to call.

Follow-up questions you should ask

If your alarms are starting to go off, you can take some initiative to pin down exactly how messy the situation is, and this can help guide your decision about wading in.

"How many releases out of date is the platform you'll be working on?"

The rule of thumb is No More Than 2. If you're a Microsoft junkie (as I now am), two releases puts you back 4-5 years, which is an eternity in IT time. And while the typical application life cycle used to be friendly with that time span, it's less so today. If I'm sitting in an interview in 2014 and the SQL Server back end of the app to be rebuilt is SQL 2005, I'm in trouble.

There are several reasons why: If it went that long without an upgrade, it's probably been neglected through-and-through, not just on the back end; if it's a multi-tiered app, its layers are likely way out of sync, and it's probably unscalable. And the documentation (if it exists) is not likely to be very good.

"How many folks in-house have expertise in the legacy system?"

If the answer is none, you know why they called you. If the answer is one, two, or a few, your next question has nothing to do with the IT side: "Is there a business-side expert who knows the app, its users, and where it needs to be today?" If the answer to that last one is yes, then all is not lost.