I stumbled onto an interesting Twitter conversation the other day, and I’ve been looking forward to continuing my thoughts in a broader form here on my blog.

The conversation in question revolved around the use of titles for developers, and what those titles actually denote or communicate about the person who holds a specific title. The meaning behind dev titles was especially unclear when it comes to the role of a “junior” developer.

When I see a job posting with the word “junior” in them, I don’t always know what that says about the company’s expectations - but I know what it means to me, and I hope that the company’s meaning comes close.

To me, “junior” indicates a level of responsibility, rather than a level of skill or experience. As a junior developer, I want to have code reviews and possibly pair programming throughout the week, to help strengthen my coding knowledge and best practices. And “best practices” refers not only to my coding methods, but also to the workflows and processes that differ from one company to another.

As a code school graduate and current dev intern, I know that there are many things I don’t yet know. But when considering my classification as an employee, should my experience in development be the only experience considered? In addition to my 9 months of dev work, I have years of client-facing experience with high communication and problem-solving skills, and I was a teacher for three years. Don’t these skills and experiences add value to my role as a developer? Being able to communicate clearly with clients, or share knowledge with colleagues would seem to be valuable assets to bring to a tech company.

And with the ever-changing nature of technology and development work, tying the definition of junior specifically to dev experience can get kind of shaky. For instance, let’s say that a JavaScript developer fresh out of bootcamp gets hired at a .NET agency, looking to branch out into other technologies. In terms of overall years of dev experience, that bootcamp graduate could be considered a junior. But when that .NET company starts working on their first JavaScript project, that same bootcamp graduate is the resident expert.

I’ve talked about what the junior title means to me, and why it can be a tenuous thing to define. What does it really mean to tech companies? It’s one thing to read about tech stacks in a job posting - but how does the title of “junior” set a company’s expectations of work, and how do they communicate those expectations?

The subject of job titles has been a recent topic of conversation here at Metal Toad, especially in relation to career paths. As a developer (junior, staff, or senior), what really are the expectations for developers at each level? And if these expectations aren’t set transparently and clearly, how does a junior dev set goals to complete for becoming a staff developer?

We asked, and our Director of Development answered! Matthew and our dev team leads worked together to create a career matrix for junior, staff, and senior developers. The matrix includes expectations for all areas of life as a Toad: teamwork habits, programming, methodologies, and vision & passion. And while I might like to see some of the items expanded on with more specific criteria for success, most of the descriptions are written with enough detail that I can set and meet goals for advancement, and understand the expectations of my responsibilities.

For instance, let’s look at “Pairing and Code Reviews” for junior, staff, and senior. The career matrix sets the expectations for each developer level. Junior devs are expected to participate in code reviews and pairing; staff devs are expected to initiate pairing and code reviews, and to offer substantive feedback that contributes to their peers’ growth; senior devs are expected to lead code reviews and communicate best practices, enforce review coverage as stories are closed, and take lead in following up with a bug ticket when peer review uncovers a significant issue.

For programming, the career matrix addresses coding, software design, QA & testing, debugging, environment configuration, DevOps, and security. I can easily understand a junior developer’s responsibilities for each of these areas, and see where a junior dev would need to improve their skills and strengths in order to advance. The matrix that Metal Toad created takes away the murkiness and frustration of standard job titles without standardized expectations, and replaces it with clearly defined responsibilities and expectations that allow developers here to set goals for improvement.

Has your tech company created or communicated definitions for its developer roles? Share your dev title definitions, or what you’d want to see!

This blog post was inspired by a conversation on Twitter with Nathan Ladd, Iheanyi Ekechukwu, and Yehuda Katz.