(Attention lawyers and previous employers: the following information does not specifically identify a particular entity.
You have nothing to worry about unless you think this represents you or your company and you know there is some truth to it.)
As I have worked with a few different kinds of managers/supervisors throughout the years, I have encountered one or two that had various red flags that I ignored but should have paid attention to. Here, I share some of these red flags with you in the hopes that you do not end up getting screwed. Not saying I got screwed (well, much), but you may! 
Red Flag # 1 – People tell you to watch out for her/him.
That should be obvious, but sometimes your first impression (which was good, in my case) clouds your better judgement. Pay attention to what other people are saying about this person. Even if you treat it as rumor, keep it in the back of your mind.
Red Flag # 2 – She/he has a long history of dismissing or demoting employees with excuses of “no confidence.”
When this manager joined us, it was because of a merger with another company. My current manager was demoted in short order because of “no confidence.” Note that he had been with the original company from the start and had been supervising/managing developers (quite successfully, I might add), up to that point. Other people in the company (the new one in the merger) often mentioned her/his tendency to do this.
(As an aside, I strongly believe that one of the things that would greatly benefit the business world in general is a process for employees to call for no confidence in their manager/supervisor. Once managers/supervisors realize that they can be called to task for the otherwise unknown shit they pull on their subordinates, things may change for the better. Companies need to realize that most of the real work is done by those that have not yet reached their level of incompetence. It is time to move out the ones that are not just incompetent, but possibly abusive and reduce the productivity of their subordinates.)
Red Flag # 3 – She/he exhibits bipolar behavior.
Not in the clinical sense, but you notice that she/he can run hot and cold at the drop of a hat. Be more caution if this flipping between states is a result of perceiving you as a threat. For example, she/he once asked if I wanted to be a manager “because I was good at it,” referring to how I worked with developers. But when I put on my yearly review form that I wanted to become a lead/manager of the team, I was informed that she/he did not think that I would be good at it. WTF?
Red Flag # 4 – She/he takes credit for things that she/he has nothing (or very little) to do with. These types may exaggerate their involvement in the conception and implementation of (novel) solutions, or have their name placed on things that were conceived and implemented long before they were even around.
Red Flag # 5 – She/he is personal friends with one or more people in upper management. By “personal friends,” I do not mean taking the occasional plane ride together, I mean things like frequently getting together on weekends, crashing at each other’s place, etc. In some (less professional) companies, this can end up being Carte Blanche to do just about anything. People in this position can become assholes to their subordinates, just because they can, and they have in the past without being called on it. As as you may find out, the human resources department is sometimes just upper management’s bitches, so people like this are never correctly identified by their pattern of behavior and removed from the company.
Red Flag # 6 – She/he will undermine your authority over, or the respect you receive from, other developers.
One specific case I can recall is with a problem one of our plug-ins had with another plug-in from another group. Both worked fine separately, but when loaded into the same application, the other plug-in would sometimes not cleanup its interface correctly and would leave a window on screen that was broken, and would raise exceptions whenever it was touched.
Now, we had access to that other plug-in’s source code, so I wanted to load it up in the debugger to see what was causing the crash. My manager at the time effectively berated me for this idea, that it was not the way to do things, and saying that “in her/his time,” we never blamed stuff on other developers. (I never said it was the other group’s fault, I just wanted to get more details on what was happening.) And then she/he had me make (random) changes to our code to see if we could get the exception to go away.
After a couple of days(!) if no results, she/he then stated in an open conference call “I guess we will have to find someone that thinks outside the box, then,” with other members of my development team present.
Well, I hope that helps… someone…