Published on
·
Time to read
8 minute read

YoE, Titles, and Levels Oh My!

Blog post image
Authors

tl;dr - I didn't put any job titles on my resume in my last job search. This post explains why.

This year I went through a process I hadn't touched in almost 5 years: the job search.

As I found myself back on the market thanks to the successful sale of Optyx, it was fun to see just how much the world of software engineering had changed, and a lot less fun to see just how much hadn't. Hot new frameworks may have come and gone, but one thing that has remained constant is the prevalence of arbitrary titles, levels, and gatekeeping on college degree (or time in role) in job descriptions. There's much to critique in the modern software engineer interview process, but in this specific post, I'll breakdown my perspective on leveling in software engineering, what I believe companies should be doing in recruitment, and the adjustments I made in my latest job search to play a small part in leveling the playing field.

My Background

First, a quick background check. Why do I feel I am qualified to opine on this topic at all? Well mainly because my career arc is a bit of a mixture of the non-traditional and the esteemed software development paths.

On the one hand, I was a self-taught developer working in the industry for a number of years without a college degree. Raised in a single parent household with my mom earning minimum wage, money wasn't exactly free flowing. The drive to earn and passion for the field is what led me to start coding professionally at such a young age, getting my first check from a client at fourteen. I've been the "intern" leading a technical team or guiding the work of "senior" engineers more than once.

On the other hand, I was also fortunate enough to receive a full-ride, need-based scholarship to attend Wharton, where I went on, after a transfer or two, to earn a Computer Science degree from Penn. A half dozen companies and a "Senior Staff" title later, a straight white male US citizen with an Ivy League degree and the 2nd-highest title on most IC ladders is hardly an underdog in any category.

This atypical blend of experiences has firmly granted me that MWM bravado to critique the industry and challenge the traditional gatekeeping criteria. Afterall, I have nothing to materially gain and a decent amount to lose by devaluing my "status."

With the pleasantries and humble brags out of the way, on to the substance!

Problems with Titles in Recruiting

Biased

Software engineering titles can often perpetuate bias and undermine the principles of a merit-based system. In a meritocracy, ideas and contributions should be evaluated based on their quality, regardless of who they come from. However, in reality, the same interview answers presented by an individual whose last role was "Junior Engineer" are often received very differently than when presented by a "Principal Engineer." This bias based on titles not only undermines individual performance for a specific role, but it also broadly stifles diversity. If a field is historically white-male dominated (which tech is) and existing titles are valued in a marketplace of ideas (which interviews effectively are), it becomes even harder for other populations to make their mark and have their voices heard. This perpetuates a cycle of underrepresentation and unequal opportunities.

Inconsistent

If titles were biased but predictably so, perhaps we might have been able to come up with a workaround by now. Alas, this is not the case. The wild inconsistency between companies in their use of titles only exacerbates the problem. For example, a Principal Engineer at Company A might barely qualify for Senior Engineer at Company B. This inconsistency creates confusion for recruiters often unfamiliar with technical jargon regarding specific achievements, undermines trust in the evaluation process, and makes it even harder for candidates to understand their value and career progression within the industry.

Irreflective

Most importantly though, titles are ultimately just poor substitutes for what I believe matters most in candidate evaluation. That's not a "Senior" prefix or a number of years of experience, but rather what they have accomplished, how difficult it was to achieve (technical complexity, organizational challenges, financial constraints, personal sacrifices, etc), and their consistency in demonstrating that they can do it again.

Having been often on the recruitment side, I have seen engineers who have been in the industry for decades but have rarely strayed from a very narrow comfort zone of knowledge, and on the other hand, I have known "new grads" who have already founded and sold multiple companies with management and leadership experience wise beyond their years. Experience and tenure are not always indicative of an individual's ability or potential, and it's critical to focus on their actual contributions during the interview process.

My Alternate Path

Credit Where Credit Is Due

Don't get me wrong, despite their limitations and drawbacks, titles in the software engineering industry can absolutely be valuable for a host of non-recruitment reasons.

Titles can indicate the type of work an individual is performing. For the same reasons it is helpful to differentiate sales from finance, titles can provide the basic framework for understanding the different responsibilities of different roles within a company. Staff engineer roles, for instance, may involve much less coding and more writing or leadership, making the distinction between a typical software engineer and a staff engineer a critical one.

Additionally, titles can be valuable within a company for providing recognition of high performers. Notice the distinction here between a promotion to a new job function and the use of a title for recognition. Promotions to a new job function or ladder should not be used to reward high performers. There's a major difference between "that person is a great senior engineer" and "that person should be a staff engineer".

Titles also serve as an explicit assignment of responsibility, which is especially important in larger teams, can help individuals understand their own career arc, and provide a preview of what future career growth might look like.

I'm not here to say titles are all bad, just that I find their use in recruitment deeply flawed.

Job-Seeking Strategy

In my recent job search, I targeted cross-team, individual contributor roles with a broad scope that most companies typically title as "Staff Engineer" or "Principal Engineer" depending on their organizational maturity. I needed a break from management for a while after Optyx and was excited to get back to just focusing on the engineering. To position myself as a great candidate for these roles in accordance with my philosophy, I took a unique approach to my resume and professional branding. Instead of listing out specific job titles, I decided to simplify my career history and simply refer to myself as an "Engineer" in every software engineering job I've had, regardless of "Senior" or "Principal" prefix. This allowed me to emphasize my technical expertise and focus on the achievements, complexity, and consistency of my career instead of being defined by a specific title.

I crafted my resume, and more importantly the narrative with which I present myself in each interview, to highlight the key projects I've worked on, the impact I made in each one, and the challenges I faced along the way. My public GitHub portfolio of my work doesn't hurt either to showcase my technical abilities and provide concrete examples of my expertise or contributions.

By focusing on my achievements and skills, I was able to showcase my value as an Engineer, regardless of specific job titles. This approach helped me to stand out in a wild job market and secure the role I desired without sacrificing any of my philosophical principles.

Results

During my interviews, I made a conscious effort to focus on specific accomplishments rather than titles. For example, I highlighted my experiences at Optyx through the lens of very specific technical challenges or tradeoffs made, and my experience in the open source community at Google with the navigation of specific platform and partnernship decisions.

I believe that this approach helped me convert ambiguous achievements and eyebrow-raising claims into concrete examples of what I can bring to the table for the organization.

For my next role, I chose a post-IPO tech company in the real estate industry working as a full-stack uber tech lead for an organization of around 120 engineers. If titles still matter to you after reading this manifesto 😉, it's a "Senior Staff" role, but, even though the title may be impressive, I still intend to list my title as "Engineer" on my resume the next time I'm on the market again. I believe that focusing on accomplishments rather than titles is a more productive way to begin a discussion with potential future employers, but who knows, maybe the robotic resume filters will catch up to me eventually, and I'll be forced to reveal my experience through frustratingly ambiguous titles once again.