What makes a certain level of developer?

developer_levels.md

Entry

• Passion
  • Wants to learn
  • Eager to learn
• Aptitude
  • Can learn a new language with little help
• Understands basics to a Language
  • Language comprehension
  • Understanding of programming languages and compilers
  • Knows language syntax
  • Competent in at least one language - able to complete a story
  • Able to follow instructions without hand holding
  • Conversant on basic software organization, algorithms, and data structures
  • Can create an array
  • Can create a string
  • Can write working code
  • Understands language constructs
• Can navigate tools
  • Good problem solving
  • Basic IDE understanding
  • No need for tool specific knowledge

Mid/Jr

• Work independently
  • Codes what is asked of them
  • Able to lead a story to completion when pairing
  • Competent in more than 1 language
  • Shipped a project
  • Able to follow along with a stronger developer
• Professionalism
• Can write a test
• Beginnings of design
  • UML for white board discussions
  • OO Design Patterns
  • Fundamental understanding of principles of software design
  • Understanding of design/architecture change impacts
  • Drives local design
  • Understands code idioms
  • Understands SOLID design principles
• Problem Solvinng
  • Thinks through complex problems
  • Can work and solve problems with minimal direction
• Pair Leadership
  • Mid-level pair leaders
• Continued Self Education
  • Keeps up on Tech
  • Familiar with several frameworks and technologies and can explain strengths and weaknesses
  • Reads and follows external resources in the community
  • Open to new methodologies

Senior

• Understands cost/benefit
  • Can professionally push back on bad requirements and offer alternatives
• Tech Leadership
  • Get a basic understanding of new technology as needed
• Mentoring
  • Helps teach design and syntax to new developers
• Drives change
• Abstract Problem Solving
• Testing
  • Can write tests with no guidance
  • Understands different testing approaches
• Breadth of project types
• Design/Architecture
  • Can recognize trade offs in design
  • Helps discover what to build
  • Understands proper pattern use
  • Understands SOLID, YAGNI, Demeter, etc.
  • Helps others discover architecture
  • Drive choices to minimize futre pain in change
  • Can view the system as a whole and know where lines can be separated
• Leadership
  • Able to lead an entire software project life cycle
• Complete Systems
  • Can write complex systems alone

Looks good. Although, I thought that there was some debate as to whether a mid needed to have shipped a product/project.

Agreed w/ above comment along with removal of UML from Mid/Jr level

I remember the product/project issue like Adam. Perhaps at mid level this or open github project would be a bonus, but not a requirement. On the other hand, if "Shipped a project" simply means having been on a team that shipped a product, then that makes more sense for mid level. Just MHO.

Depending on how this is used ... my points may be moot but I think there can be a significant difference between Junior and Mid that isn't reflected in the above breakdown.

Considered as transitions, I think folks will generally transition from Entry to Junior the fastest ... 6 mos to a year? The transition from Junior to Mid will take a little longer ... maybe around 1 to 2 years? The transition from Mid to Senior is a sticky one ... one need never leave their "Mid" status. Assuming an aggressive Mid ... maybe the transition would average 2-3 years? These numbers are shots in the dark and obviously subjective. No one actually falls directly into these numbers. I'm simply trying to depict the general trend.

As such, Junior levels feels like they have relatively short transition -- while I think someone could get stuck for a long time as a Mid. A Junior feels like they've gotten over the entry level hump - they have shown more than just desire or eagerness and they've started to pan out. A mid feels like someone that understands the general approach but needs guidance and pairing to reinforce their notions and perspective. A mid generally understands what they are doing, the big direction ... but still needs validation with their actual work. A junior sort of defaults or transitions automatically to a mid over time ... but I think a mid has to go an extra step, almost explicitly, to become a senior. Seniors don't get by simply by pairing or working in the wings.

An entry shows potential. They can think logically and demonstrate the ability to learn and pick up new things. A Junior has worked with the technology and clearly understands points as they are explained. The Junior has lots of technology specific questions - lots of questions as to 'why' we do what we do. The questions might be somewhat naive or superficial ... not quite as deep or subtle as those a Mid will ask. A Junior may 'forget' to do something but can be easily reminded. On the other hand, the Mid can generally talk about what they are doing. And while a Mid may not be able to explain the nuances of their decisions, they can explain things in the large - repeating things as they've been explained to them and expanding on them where experience allows. Mids sound like they understand, Juniors are not ashamed to admit they don't, yet. Mids come up with many good ideas and pose deeper, thoughtful questions to help them form a firm foundation - understanding and applying patterns and idioms that are essential to their work. They are pulling things together, forming opinions and starting to form a general picture. A senior has generally been through these phases and can start giving back to the team. The senior has the ability to push information down whereas the other three roles are generally asking up.

An Entry couldn't generally finish a non-trivial project - at least, not in a architecturally significant way. A Junior could finish a project with a lot of constant hand-holding but might be hard-pressed to repeat it without more hand-holding. A Mid could finish the project alone with a few questions scattered here and there to reaffirm they are working in the correct direction. A Senior could finish the project and explain why they did what they did -- and reason as to why their decisions were appropriate.

Again, the categories are somewhat arbitrary and can be as broad as makes sense to the interviewing team.