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.