- How many other people will be working along-side myself in day-to-day operations?
This affects your ability to perform in a very direct way. It also affects your ability to take an uninterrupted vacation...
- Who is the first responder to problems?
This answer will vary, but it's a good indication of how the organization can actually "organize". Large setups should have a helpdesk and ticketing system; small setups should have at least the ticketing system, along with some kind of company-paid pager for help.
"Just you" is not an acceptable answer. This is a complete lack of organization, and should be followed up with a question of "How do you track requests from users?". This must be answered with something other than "you don't".
- What is your ratio of existing systems to administrators?
This shouldn't be too high (above 50:1) or too low (below 5:1). Too high and your workload will be so severe you'll be treading water to stay afloat. Too low and you're either a one-person shop, or there are severe issues with the shop's ability to manage systems.
As always, there are exceptions to the rule; instances where 200+ systems can be imaged from a single source (think web head-ends), and instances where the business is very small (20 employees might only need 2 servers).
- What is your ratio of end-users/customers to administrators?
This is a measure of expectation. These are your "customers". When there are issues, this will be the amount of "pressure" you will be under to resolve a situation. An organization of 5000 with just 2 admins can be a very, very stressful place if your systems are having trouble.
- What is your ratio of end-users/customers to existing systems?
This is a measure of server workload. Very high ratios can be a sign of overutilization, or budgetary constraints that will tie your hands when it's time to expand. Underutilization can also be an issue when it's not called for (i.e. makes sense that HR has their own server, but a file server for only 5 "regular" users in an organization of 5,000 is a red flag); this might call for some "virtualization" to consolidate servers...
- Is there an existing process for handling updates to existing systems, such as applying vendor patches or firmware updates?
This should be any other answer other than (a) "I don't know", or (b) "we don't update".
- Say a server catches fire. In the event of a crisis or calamity, what timeframe is acceptable as downtime?
This should always be a reasonable question. If the interviewer gets bent out-of-shape at this question, then they don't understand the nature of your work, a vital clue about future prospects. If the expectation is 24/7 operation, that's fine - unless they don't have the infrastructure for it, which means you'll be babysitting machines a lot. Knowing what is and isn't acceptable helps to tip their cards to you about their true expectations.
- Speaking of fire, do you have a fire suppression system in place for your equipment, and is it of the appropriate type?
Water sprinklers are not an acceptable answer. This does happen, and you will get organizations that think stuffing a rack into a broom closet with no ventilation and a fire sprinkler overhead is a great idea. If this is downplayed, ignored, or met with hostility, get up, thank the interviewer, and don't walk, run...
- Describe your data backup process and the format of storage used.
This is another question that should be answered with anything other than "we don't" and "we don't have backup media".
- Do you test your backups on a regular basis, and how often?
The follow-up to the above question. If you're not testing on a regular basis, you're just inviting trouble.
- Is there a known budget and purchasing process for both capital outlays and minor purchases? Can you explain to me the process I would use to purchase something?
If the answer is "we (someone else) will buy it as we need it", that's a red flag. It means "we don't trust you to buy equipment when you really need it, so we'll have someone else do it instead". There should always be some kind of budget.
The process to purchase something should be easy enough to explain in less than 2 minutes. It should not involve more than 2 parties signing off (higher numbers indicate red tape), and it should have a turn-around measured in days or hours, not weeks (critical purchases will be held up if it's too long). There should always be some kind of process.
- Do you have a plan to refresh and recycle old hardware, and how often does it occur?
I have actually seen companies running on 18-year-old minicomputers that are kept alive by support contracts and lots of spare parts from a support vendor. Of course, the original hardware vendor has long since departed...
Desktop units should never be refreshed faster than 3 years, or slower than 5. In businesses with tight budgets, stretching a desktop to 5 years is sometimes an appropriate answer.
The bit on recycling is a test to see if they have a "disposable" attitude towards old hardware. It's bad in the sense that you should properly dispose of it through a known recycler, but good in a sense that you can press-gang old hardware into temprorary duty should the need arise. It will also give you a sense of the size of their "boneyard" (the pile of old hardware that is kept around).
