Junior-Level: Takes a long time to get simple things done, struggles with elementary things, needs plenty of supervision, needs plenty of feedback, feels insecure about touching other people's code, keen to learn. When something goes wrong, the user using the app will usually get the blame for using the app incorrectly or "caching" will be blamed for the problem even though no caching is present, often makes n00b mistakes that will potentially take the system down in production.
Mid-Level: Self-starter and can work without supervision, elementary things no longer a problem, but struggles with more advance stuff, still keen to learn, but are less influenceable due to set ideas during Junior phase, when something goes wrong, explanations will range from spot-on to caching is the problem even when no caching is present, will go into heated debates about how things should be done even though they don't have the experience to back it up, strives to be a senior developer.
Senior-Level: Gets stuff done, tells you how it should be done due to plenty of experience, understands the bigger scheme of things and how all the system components fit together, when something goes wrong, they usually don't make assumptions and rather look at the logs to get an exact explanation for what's going wrong, will drive change when change is needed.
Architect-Level: Works directly with business to understand requirements and design the system accordingly, wants to teach how it should be done, when stuff goes wrong, the Architect has probably already fixed it before you could even figure out what was going wrong, probably does a lot less coding than the seniors and mid-level developers due to overseeing that they do things correctly, fixes code / writes code that is very complex to follow / understand which the mid-level developers will never change and the senior developers will maybe make small changes here and there since they don't understand the full scope of what they are changing. Architects can range from patient likeable people to people that will jump down your throat if you screw up.
CTO-level usually don't write any code, the best CTOs I've worked with are ex-architects who completely went to the business side. They work with the CEO to understand the direction the company is going towards in order to drive the technical business requirements after which they work very closely with the architect to put the complex parts in place so that everyone else can jump in and work on the platform.
Bad qualities in each of these groups includes, "not-my-problem" mentality, lack of enthusiasm, not willing to learn, entitlement issues, being possessive about code and not allowing other to work / change code you've written. Not taking the initiative to make things happen I consider a bad quality, but is more or less understandable when you're a junior who doesn't understand the system yet.
Good qualities in each of these groups includes team-spirit where the end-goal is placed before personal choices, issues, etc. Willingness to learn from others or to teach others. Clear communication with everyone else is definitely a good quality, documenting code properly and writing unit tests where needed and not leaving it for somebody else to do. Being a self-starter instead of waiting to be told what to do.