What I’ve Learned from Doing IT Interviews


WARNING: My humor tank is running low today.  This one is a semi-quasi-serious post with sub-humor ramifications and subtle uses of pontificatory inflection.  cough cough…

Like many (most) of you, for years, I’ve been the one sweating through an interview.  I’ve had bad interview experiences, and good ones; maybe even a great one, once or twice.

On the bad list was one with a well-known hardware vendor, where I was introduced to three “tech reviewers” on the call who regularly speak at pretty much EVERY IT conference on Earth, and have written enough books for me to climb a stack and change a light bulb.  I was in over my head, but thankfully, they appreciated my humility and sense of humor (had an interesting follow-on conversation at the end as well, but I’ll leave that for another time).

On the good list was the most-recent interview I had (my current job) where the interviewer took the time to share some fantastic technical advise which helped me on the project I was working on with my previous employer.  More than an interview, it was like a mini-training session.  Needless to say, he liked my mental problem-solving process enough to offer me this job.  Very, very much appreciated.

But this post is really about the flip-side of the interview process; what I’ve learned from interviewing others for various types of positions.  At a former place I was the administrative “lead” of a team of six (6) incredibly skilled people.  Part of my role was to interview new hires for a very uncommon set of skills to fit into that project.

At my current employer, I’ve been interviewing like mad to help a customer fill staffing needs for another set of uncommon skills. Not that the individual skills are necessarily uncommon, but the mix of skills in a single person seems to be uncommon.  I have to say, it’s been both enjoyable, and educational for me.

I hope that this experience helps me with future interviews when I go looking for a new job (or a promotion).

I’ve tried to apply the “good” experiences from my interviewee past as much as possible.  For example, not just grilling candidates to make them sweat, but help them along the way, in a give-and-take discussion.  Not a lecture.  And not a cross-examination.  It’s been eye-opening for me, to say the least.  So here’s what I’ve learned:

1 – Keep it Simple

When asked to respond with a “what would you do if…” scenario, start with the most basic step.  A classic example question is “You have a web server, that relies on a separate SQL host, to support a web application.  After working fine for a while, it now shows an error that it can no longer connect to the SQL host.  What would your first step be?

Bad answers: “I’d check the SQL logs”.  “I’d confirm the SQL security permissions”, “I’d verify that the SQL services were running on the SQL host”, “I’d Telnet to the SQL host”

Better answers: “I’d try to ping the SQL host from the web server”

2 – Know the Basic Basics of your Platform

If the role involves system administration (aka “sysadmin”) duties, you should be familiar with at least the names of features, components, and commands.  You don’t necessarily have to know every syntactical nuance of them, just what they are, and what they’re used for.  For example, “what command would you use to register a DLL?” or “What command would you use to change the startup type of a service?”

If the interviewer doesn’t focus on scripting aspects, then ask if they want to know the command or what PowerShell cmdlet.  Then take it from there.  If they ask about the command, just give them the command.  You don’t need to describe the various ramifications of using the command, or how it would be better/easier/cooler to do it with PowerShell.  If they ask about PowerShell methods, answer with the appropriate cmdlet or just describe the script code at a 100,000 foot level.  That said, if the interviewer is focused on your PowerShell acumen, dive deeper, but ask if that’s what they want to hear first.

3 – Don’t be Afraid to say “I Don’t Know”

If the interview question leaves you stumped, don’t hem and haw, and don’t make up something.  Just say “I don’t know“, but, and I mean BUT…. follow that with some next-step direction.  For example, “I don’t know, but I would research that by going to ___ and searching for ____

4 – Ask Questions

A lot of the time, the interviewer is also looking for indications of how the candidate interacts with a situation, such as an interview.  They want to know if you’re inclined to question and discover each situation, rather than just react to it.  Sometimes, the interviewer will ask you “Do you have any questions?“, and sometimes they won’t.  Regardless, it’s often good to ask at least one or two questions, even if it’s just “what’s the next step?

5 – Get a Critique if Possible

At the end of the interview, unless you feel certain you nailed it, like this, I always recommend asking the interviewer for some feedback how how you did.  Ask if there were any areas you could have responded better.  Don’t worry about getting granular details, just general responses can be very helpful.  Whether it’s technical, personal, or otherwise, anything is pure GOLD when it comes to this.

It’s a rare chance to get some tips that will help you on future interviews.  This is particularly true when you feel pretty sure that the employer isn’t going to make you an offer.  That doesn’t mean you are a failure, it just means you didn’t provide indication for the position they’re looking to fill.

IT Security Methods by Industry

After years (okay, decades,… okay, okay, centuries…..  damn it… alright! alright already, eons… are you happy now?  yes.  I’m THAT freaking old.  I still remember coal-fired computers and horse-drawn airplanes and shit.  My birthday cake is a slice of tree trunk of matching rings, but the table can’t hold the weight anymore.  sheesh!)

What was I saying?  …. (eyes wandering left and right…. … . . .          …  .         …. . .      .   .  )

oh yeah!  I’ve amassed a data set that accurately summarizes the predominant security practices or strategic “methods” leveraged by each major US industry. I warn you: this is highly scientific information.  It may require additional consumption of various questionable substances just to remain conscious while trying to read it all. Here goes.



Method: Place sufficient restrictions on the adoption of new technologies, so as to (A) mitigate unknown vulnerabilities and exploits, (B) insure that those with knowledge of older, proven exploits have died from old age, and (C) keep certain aging consultants employed (because they’re married into your family).  And besides, what’s wrong with COBOL?


Method:  Never leave important IT decisions up to any one person, ever.  In fact, the more people involved, the greater insurance that the decision will eventually be reliable, maybe.  Larger companies focus on perfecting multi-role hyper-proliferated subterfuge logic branching and coalescing processes.  In layman’s terms: they foster greater variety among responses to decision inquiries.  Many have invested heavily in processes which depend entirely on custom hand-stitched, stone-carved, natural leather encased software, usually written by someone who left or died long ago.

Defense Manufacturing

Method: Implement dozens of stop-gap procedures to insure every motion of IT is slowed to the lowest possible, almost un-measurable, velocity.  Think of a Japanese rock garden, only slower.  Where the sand is executive processes and the stones are IT staff, now simply add quick-set cement to the sand mix and sprinkle some water on it.  This insures that even the bad stuff will take forever to make headway, and by that time, the entire system will have been eventually decommissioned.  Forget penetration attempts, even social engineering-based, because they’re often project-oriented, not departmental, so most people have no clue what that next cube is working on.  In fact, they probably don’t use the same network, computers or operating systems.


Method: Relegate “IT” to whomever answers the Craig’s List ad for an “IT Expert”.  Critical skills include: printer management, thumb drives, recovering lost files and emails, and using Excel databases” (that’s not a typo).  Must also have experience with Macs and Windows XP, particularly with kids games.

If they have any in-house “IT” capacity at all, it’s often enough shock to send a consultant into cardiac arrest.  Due to possible legal implications, it’s best to never change passwords for critical user accounts and never, I mean NEVER, delete anything.  Keep everything forever, or as long as you can afford somewhere to store it.


Method:  Agents need to be flexible and mobile.  Everything is done on laptops.  Everything remains on laptops.  No time for that silly, trendy, cloud stuff.  No backups, no cloud sync, but OMFG do NOT let anything happen to that precious data on those roaming laptops!  Thumb drives are forgotten like Matt Damon in Interstellar, waiting for someone to give them a hug, only to have their face shield cracked open and their chip tossed away.  Shit.  Did I give away the plot?

Advertising / Marketing

Method: Hire someone quick, and get back to the conference before the food runs out.


If it’s airlines, use railroad standards.  If railroads, use airlines standards.  Either way, the older the technology the better.  It’s like a cast-iron frying pan, after years of seasoning, or a vintage wine.



Method: Deny all requests for pay increases for five (5) years, reduce promotions from once every five (5) years to once every ten (10) years, discontinue any training programs, and for God’s sake: deny all requests for stupid things like newer software and hardware  It worked in 1995, so it should still work!  Hire a consultant to blame internal staff for every deficiency, terminate and reassign to avoid audit trails and blame the contractor afterwards.

Federal Agencies

Method: Same as municipal, but on a much larger scale.  Every four (4) years, change direction from in-sourcing to out-sourcing, and blame the opposite for any failures that remain.  If conservatives win, out-source to private contractors, where expertise and trust are premium values, after all, when has anyone ever heard of a private contractor doing something wrong in a government position?  Then blame liberals.  If liberals win, open up the job requisition flood gates and hire at will.  However, keep GS-rating pay scales at 1995 levels to avoid asking for tax increases.  This helps insure only the highest-quality employees are onboarded from their previous positions as private contractors or foreign exchange students.  Then blame conservatives for any failures.  Think of it as seasonable employment.

Medical/Dental Practices

Method: Hire the first contracting IT firm that actually shows up.  If they wear those spiffy-looking polo shirts with a slick company logo, they might be too expensive.  Ask if your cousin’s friend graduated tech school yet.  You know, the one who puked all over your sofa when he brought her to crash in your apartment while you were out of town.  That one.  If she’s not available, what about that kid that asked you about spark plugs while you were trying to inflate your car tires that day.



See if you can guess which of these most closely matches the photo above.

5 Myths of Modern IT


These are just five (5) of the most common statements/assertions/quotes I’ve overheard over the years while working in IT.  Every time I hear them, I have to take a deep breath and suppress my inner angst (to put it mildly).  This post isn’t all that funny actually, but I ran out of coffee and it’s too late for bourbon on a weeknight.  So I attached my custom-fit tin-foil hat and henceforth pontificate…

“The goal of Automation is that it frees up employees to focus on other important tasks”

Conceptually, this is plausible.  But, and this is a big BUT (and I cannot lie, all you other brothers can’t, oh never mind…), it depends on the source.  ‘Who’ initiates the push towards automation is what determines the validity of this statement the most.  If the premium placed on automation is cultivated in the ranks, this statement can be, and often is, very real.  However, when it’s initiated from the “top” (usually business, rather than technical ranks) it’s almost always (okay, 99.999999999999999999999999999999999999999999999999999999999% of the time) aimed at reducing staff and employee costs.

I’ve seen various spins and flavors of this, depending upon business culture.  The “reduction” can range from departmental shifts, to demotions, contracting-out, layoffs, and outright terminations (depending upon applicable labor laws).  Indeed, as much as I love (and earn a handsome living on) business process automation, using IT resources, I never allow myself to forget the ultimate goal: to reduce human labor demand.  The more I spend time with non-IT management, the more I see evidence to prove this assertion every day.

With that said, if your particular automation incentives are derived internally, push onward and upward.  Don’t let me talk you out of that (why would I?)

“The value of the cloud is that it enables on-prem expansion with fewer constraints”

This is a contextual statement.  Meaning, taken out of context, it is indeed a valid statement.  However, when inserted into standard sales talk (also commonly and scientifically referred to as “talking shit”) it’s often sold as being the premium value in the over-arching model.  In reality, I have seen only two (2) cases, and only heard of two (2) others, out of dozens of cases, where an infinite hybrid model was the ultimate goal of a cloud implementation project.

The majority of enterprise cloud projects are aimed at reducing on-prem datacenters, often to the point of complete elimination.  There’s nothing inherently wrong with that; it makes good business sense.  But selling it under a false pretense is just wrong.  Indeed, of the last five (5) cloud migration projects I’ve been involved with, the customer stated something akin to “I want to get rid of our datacenters” or “I want all data centers gone“.  The latter quote came from a Fortune 100 company CIO, with a lot of datacenters and employees.

“Who needs sleep?”

Don’t fall victim to this utter bullshit.  If you believe you only need a “reboot” as often as your servers do, you’re putting your own life at a lower value than common hardware.  If you’re a “night owl”, that’s fine, but only as long as you adjust your wake-up time to suit.  Always ask yourself where this inclination to never sleep starts.  Is it coming from management?  From your peers?  From personal habit?  If it’s coming from management, move on to a better workplace.  If it’s coming from your peers, you need to expand your network.  If it’s coming from personal habit, fix it.

A few years ago, I fell into the habit of working myself almost (literally) to death.  Mostly from what I call “code immersion”.  That urge to “get one more line done” and then another, and it never ends.  I was averaging 2-3 hours of sleep over the course of a year.  It finally caught up to me in a very bad way.  I’ve since taken action to prevent that from happening again.  I’ve seen way too many people die from not taking care of themselves.  Way too many.  Don’t be another statistic.

“This is cutting edge”

I have another quote (and I’m still trying to identify the true source of it), that runs counter to that: “We live in ancient times“.

Everything we do in IT, and I mean EVERYTHING, will be gone from this Earth long before most of the furniture in your house.  Long before your house is gone.  Statistically speaking, this is a valid statement.  Information Technology is a process, not an end result.  It’s a process of optimizing information access and accuracy, which evolves over time.  The tools and technologies employed to that purpose also evolve.

“The customer is always right”

If they were, then why do they need you?  And more importantly, why are they paying you to help them?  That said, the customer holds the purse strings, and the promise of future work, so don’t ever charge out of the gate with a smug demeanor.  Every new customer engagement should start off deferential.  It should then evolve and progress based on circumstances and communication.   However, anyone who works in IT and insists that the customer is “always right” is misguided or just stupid AF.

Honorable mentions (phrases that annoy the $%^&* out of me)

  • “You can’t afford NOT to!”
  • Excessive use of buzzwords like “holistically”, “literally” and “ummm”
  • “It pays for itself!”
  • “It’s the next ______, only better!”
  • “Why? Because ours is a better solution”
  • “The Cloud is a fad”


Everything you read above could, quite possibly, be entirely rubbish.  After all, I’m a nobody.  I just call it as I see it.

Top 10 Reasons Your Job Might be Automated

10. Machines don’t give a shit about your favorite sports team, movie, TV or streaming series, cars, food, drinks, types of women or men, tasteless jokes, what you did last night or over the weekend, or what programming language you think is the best.
9. Machines don’t need restroom, smoke, vape, or lunch breaks
8. Machines don’t need to get their kid from the school nurse
7. Machines don’t ask for a raise or better benefits
6. Machines don’t need to rest
5. Machines work faster than you
4. Machines can do the work of more than one of you
3. Machines are better at analytical processes than you’ll ever be
2. Machines don’t horde information about their job
1. Machines don’t sue their employer

Even funnier, is that most people are convinced that THEIR job could never be automated.  No matter what profession they’re in.  Let’s list off some of the folks who were convinced of this as well:

  • Telephone operators
  • Mail sorters
  • Grocery store clerks (in many places)
  • Surveillance aircraft pilots
  • Security guards
  • Punch card handlers
  • Carpet weavers
  • Stock market traders
  • Food and drink vendors
  • Waiters (in many places)
  • Newspaper deliverers
  • Gas station attendants (in most places)
  • Librarians (in most places)
  • Milk delivery (in most places)
  • Movie set demolition experts
  • Camera Film Developers
  • Data center rack engineers (I already hear that giant sucking sound Mr. Perot mentioned)

Travel Tips for the Non-Terrorist


Formula for Determining How Much to Pack

(Days * Underwear,Socks) + (Belt) + (Occasions * Shoes) + Occasions(ShirtTypes * Days) + BadWeather(Coat/Jacket/Pullover) + Toiletries + Entertainment + medical supplies + weather gear(optional) + flight requirements (tickets, etc.)

Factors to consider

  1. How long is the visit?
  2. Weather forecast
  3. Occasion (business, formal, social, leisure)
  4. International or domestic
  5. Required equipment / accessories (work, personal)
  6. Entertainment needs (music, movies, books, e-books, etc.)

Example: 5-day business trip (technical, not executive)

  • For the flight / direct to hotel after landing:
    • Long-sleeve t-shirt over short-sleeve (layers for hot/cold)
    • Jeans or sweat pants
    • Tennis shoes which slip on/off easily, or flip-flops
    • Ball cap (not the one that says “F-U TSA”)
  • For the backpack:
    • Laptop, charger, cords
    • Phone charger and spare charger pack
    • USB thumbdrives
    • Light jacket (maybe)
    • Snacks, Medicines, Gum
  • For the suitcase
    • Dress pants (business casual)
    • Polo shirts (business casual, un-stained)
    • Underwear, t-shirts, socks
    • Dress shoes
    • Swim trunks
    • Toiletries (toothbrush, deodorant, shaver, etc.)

Other Aspects

  • Print boarding passes
    • I used to use the phone apps for boarding, but I’ve had issues at the point of scanning when the app locked up, or phone went to sleep, etc.   Angry people in line behind me.  And I see it happen to others quite often.
    • I still use the apps for check-in, assignment changes, and gate status, but for boarding I print the pass and it always works.
  • In-flight:
    • Aisle seat if possible
      • I like window seats on flights over interesting terrain
      • Otherwise, I like to be able to get up without waking up the snoring slob beside me
    • Passenger next to me = friendly:
      • Conversation
    • Passenger next to me = not friendly:
      • Short flight = Podcasts
      • Longer flight = Movies, books, podcasts
    • Alaskan Airlines = talk with flight attendants (they’re usually cool)
      • After 11pm = free wine (if they still do that)
  •  Layovers
    • Short (less than 1 hr) = direct to next gate. Don’t fk around
    • Medium (2-3 hrs) = eat, drink, charge phone and ear buds, phone calls, emails, etc.
    • Longer (4 to 12 hrs) = bar, restaurant, comfy place to lay out, charge phone, phone calls, emails, people-watch, read, watch movies, etc. (I picked up people watching skills when I worked in NYC years ago – makes for great stories, blog posts, tweets, etc.)
  • Hotel
    • Check in – drop stuff – go for a walk
    • Find the workout room / pool / Jacuzzi / bar
    • Lay out clothes for next morning (I can shave/shower/dress in 20 mins if I don’t goof around the night before)

BONUS!  Going Through Security (Tips)

  • Don’t make jokes using words like “explode”, “kill”, “shoot”, “stab”, “grenade”, “bomb” or “booby trap”. If you have Turret’s Syndrome and can’t avoid these words, stuff your mouth with cotton balls or an entire pack of bubble gum before going into the airport.
  • Regardless of what one TSA person says (or doesn’t say) take your belt off (long story) or wear pants with an elastic waistband (no belt needed)
  • Don’t ask if you need to put your penis in a bin to put through the scanner.  Even if you have one.
  • Remember: TSA people do not have a sense of humor.  It’s a job requirement.
  • Shoes that you can slip on and off without using your hands = very nice.
  • When they ask “what’s in the bottle?” don’t laugh and say “C4!”
  • While the TSA person stares at your photo ID and back at your face, try to not make a Clint Eastwood face, unless you can’t help it.
  • You can save $4 by bringing a clean, empty (dry) plastic bottle in your carry-on, and fill it with water once you’re done with the security process.

General Observations (Dave’s Travel Rules)

  1. The number of available charging stations or electrical outlets in a given airport is directly and inversely proportional to how low your battery is.
  2. SeaTac (SEA), Charlotte (CLT), Atlanta (ATL) and Los Angeles (LAX) best spots for charging are at the most remote wings of the terminal.  Kind of like most conference buildings.
  3. If the pilot says “it might get a little bumpy” and you’re NOT crossing over a mountain range, it’s probably going to be “a little bumpy”
  4. If the pilot says “it might get a little bumpy” and you ARE crossing a mountain range, like the Rocky Mountains, it’s going to be very bumpy.  This is particularly true if you’re flying into Denver (DEN) from the west.
  5. Evaluate your departure time and landing time, total flight time, and sleep schedule (before and after a time zone shift) and plan on sleeping during flights as needed.
  6. Avoid caffeine and alcohol during flights, unless you’re really angry, in which case, consume all you can.
  7. The people seated on an exit row are not going to help you escape when the plane goes down.  They’ll be the first out.
  8. There really aren’t any oxygen masks.
  9. There really isn’t a pilot.  It’s a blow-up doll and a recording.
  10. The air nozzles over each seat are fed from air in the restroom.

SCCM, AD and Dumbest Statements so far Today


It’s only Monday, yet the insanity has already begun piling up as of noon today (ET).

(them) “We don’t want to use PXE, because it might end up reimaging all our computers without our control.”

(them) “Our AD keeps locking up.”

(them) “We need packaging support.” (me) “What kind of packaging support?” (them) “I don’t know.  Whatever packaging SCCM requires.”

(them) “SCCM cannot tell you who the user of the device is.”

On call number 5 already, different customers, different engineers, planners, etc.  Waiting for the next awesome statement.  Only 5 more calls to go.

Application Packaging: One more time

Combo meal edition: Double cheese pontification, crybaby sauce, and a side order of rant fries.


  1. Do NOT repackage unless you absolutely HAVE TO.
  2. If you actually do have a need to repackage, try to produce an MSI package.  And if you crank out an MSI, please fill out all of the properties.
  3. Read this: http://www.itninja.com/blog/view/application-packaging-best-prac-tices
  4. Read this too: https://msdn.microsoft.com/en-us/library/windows/desktop/bb204770(v=vs.85).aspx
  5. If you don’t know how to do it: SEARCH, ASK, READ, LISTEN
  6. Don’t knee jerk. Ask yourself what the BEST solution is for EVERY request.
  7. BE CONSISTENT with EVERYTHING: methods, tools, documentation, naming, version numbering, storage locations, all of it.  Being consistent does not mean change is bad, but analyze the change and when you decide to do it, make it stick.
  8. If you don’t have time to do it the right way, don’t even bother. Grab your keys and head out right now.  I’ll explain it to your boss.
  9. If the installer package you produce requires the target users to have local administrator rights, or that the client firewall be entirely disabled: you have FAILED miserably.  Go back and start over, or cover yourself in lunch meat and visit an alligator ranch.
  10. If the product absolutely cannot work without users having full admin rights, or the firewall turned off, or it cannot install silently by any means, contact the vendor for help.  If the vendor won’t help, find another product.  If you can’t find another product, make one.  If you can’t make one, hire someone who can.

And that’s not all… (pull-starting the rant engine now)

If you’re thinking “I can’t afford to hire a programmer to make this thing“, maybe you need to do the math to be sure.  While the full-on 1990’s approach to large-scale in-house development groups isn’t as common in 2017, there can easily be a comfortable balance when the need exists.

  • How much time do you spend making adjustments for half-baked, crappy-installer products over a year? That includes “tinkering” and “messing around” on your own time, as well as phone calls, emails, to the vendor and colleagues, user groups, trying to get help.
  • How many people are involved in making those adjustments?
  • How much do they cost per hour to make those adjustments?
  • What other tasks are those people NOT working on, while they’re busy making those adjustments?
  • Is your business important enough to put a little more effort behind getting your applications done the right way?  If not: then why not?
  • Why are YOU doing the work that the vendor should have been doing?
  • Why are YOU still paying that lazy vendor for unfinished products?

Think of this another way…

  • What if you had dinner at a particular restaurant every week, and every time they brought you a partially-prepared meal, such as half-boiled pasta and uncooked meat?  And then they told you that if you wanted it fully cooked, to get your own pan, water, and stove and finish cooking it all yourself.  But don’t expect a discount on the price either.
  • Would you still keep going back to eat there?
  • That’s only a $20-$30 meal (on average, at most)
  • So, why would you do this with products that charge you thousands of dollars?

Maybe you hate your employer, which isn’t uncommon these days.  But if you like your job and/or your employer, and you put up with inept software packaging by vendors, ask yourself, why?  At least try contacting the vendor(s) to see what they can do.

Of the several dozen I’ve reached out to, about 50% were helpful in making their product install silently, and with less effort.  About 40% dragged their feet and did nothing.  10% were either unresponsive or complete arrogant bastards that should be lowered into a turbo-charged woodchipper, feet-first.  But otherwise, those aren’t terrible odds for getting help.

I feel better already! 🙂