If you are interviewing for a software job, or a job in a software organization, Joel Spolsky has a short list of questions that he calls "The Joel Test" that you should ask. They are yes/no questions so that can be asked quickly as part of the interview process. Here they are:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

For a full description of why each question matters, check out the link to his site. Now, if you are interviewing for an actual software position, you can obviously skip question 11, you'll know if you've been asked to write code or not. But to me, this is one of the most important questions out there. It still amazes me that people hire coders without making them write code. I always make interviewees write code. It's startling the number of people that can give good book answers to standard interview questions, but when it comes time for the rubber to meet the road and to write some code, they are completely useless.

The one other question I'd add to this list is:

Do you check references?

Amazing as it may sound, lots of places don't. If you are hiring a developer and you don't check references, and you don't have them write code, you are taking a person based on their answers to a series of trivial questions. The results will vary widely, which means the people you'll be working with will vary widely too. Yeah, there'll be some good ones, but there'll be plenty of stinkers too, and those are the ones that will keep your organization for being really good... bad coders drag down the entire team.