Based on “Organizational issues” — sore spots of IT? I think it would be fair to say that system administrators need to determine if a place is worth working at. There is a similar well known test by Joel for programmers.
What are the 12 questions system administrators should ask at an interview in order to help them decide if it's a good place to work at?
Following Joel's rules:
- Questions should be platform and technology agnostic
- Questions should elicit a simple response such as yes or no
EDIT: Please post one question at a time so we can see what users are voting for.
Do you use an incident/ticket tracking system?
Do you perform system backups, and do test restores regularly?
This affects your ability to perform in a very direct way. It also affects your ability to take an uninterrupted vacation...
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".
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).
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.
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...
This should be any other answer other than (a) "I don't know", or (b) "we don't update".
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.
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...
This is another question that should be answered with anything other than "we don't" and "we don't have backup media".
The follow-up to the above question. If you're not testing on a regular basis, you're just inviting trouble.
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.
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).
Related Questions:
https://serverfault.com/questions/44638/how-often-does-tech-refresh-happen
Do you have a disaster recovery plan and does this include IT?
Follow-ups from the great comments: If so, does it include the entire organisation and not just IT? Does it include personnel and do you test it regularly?
Related Questions:
Disaster recovery plan development best practicies or resources?
Is the current environment documented?
Are both the policies and procedures documented and consistent?
Do internal accounting practices assess a value to the services IT provides to other departments, or is IT simply accounted as a cost center?
(This is very nearly the same question as Stick's "Is IT a priority in your organisation or is it a necessary evil?", but phrased so as to possibly elicit an honest answer instead of the blatantly telegraphed correct lie.)
One thing that I consider a must-have is a testing machine that has identical hardware specifications as the live server.
"How closely do your testing environments match Production?"
I find it very interesting that many of the answers are worded "Do you have this?" or "are you doing this on a regular basis?" If I am going to be hired as a new sysadmin, I would expect to be able to implement these things if they were not already existing. Disaster Recovery and monitoring logs are not something that would make or break an interview. If they weren't doing these things, they will be after I was hired.
My main concern, as I mentioned earlier would be support from above. If I say we need to replace servers, I would like the benefit of the doubt. Or if I implement an annoying security policy, I don't want partners granting immunity to people who complain so they can look like nice caring bosses.
The system administrator is in a strange place in the hierarchy of corporate structure. Sometimes they are taking direction and setting their priorities based on the needs of the most entry-level personnel, and sometimes they are dictating policy to management. We are at the very bottom and the very top of the chain simultaneiously.
I am willing to play the part of the scapegoat and peon by being at the bottom, as long as management yields to my advice in those scenarios where I am at the top.
Do all new system/software/application purchases go through IT and does IT have the power to reject and suggest another system, perhaps one that is already in use at another department?
Are you willing to spend money for proper monitoring/logging tools?
-or, from the original Joel Test question:
Do you use the best tools money can buy?
Related Questions:
Server health monitoring software