Every company seems to call their technical employees something different. No, I’m not talking about all the ninjas and gurus out there. I’m talking about the folks who sit in front of an IDE (or, dog forbid, vim) and write lines of code in the desperate hope that it compiles and/or runs. There seems to be no end to the honorifics bestowed upon these folks.
The reason for the differences is that your title means a lot to your career. Regardless of what duties you do, a “Senior” at the front of your last job title is going to open more doors than without it. If the technical people that you’re hiring care about what their employer calls them, then anybody trying to hire them should also care.
To help you decide on the names you use on your job postings, here’s a rundown of the various titles used and what they mean.
For the boots-on-the-ground type role, the individual contributor building software one byte at a time, the major title split is between engineers and developers. I’ve even seen some companies have it both ways with the “Development Engineer” title. For the actual roles, there may be no actual difference between what they do, but there are some perceived differences among the tech community which we also saw manifested in some regional preferences during our analysis.
A veteran engineer put it to me like this: a developer will take whatever solution you give them, and code it in the language that you’ve chosen. You give them tight tech specs and your vision will become reality. An engineer can take the business logic of the project, then design and architect the solution. They’ll ensure safety through security measures, design unit and integration tests, and iterate as the goalposts move. Obviously, this doesn’t always reflect the reality in all companies, but strong opinions exist in the community.
Speaking of strong opinions, a note about terms like “programmer” or “coder” (or, keep your voice down, “code monkey”). These aren’t always received well, even if you meant them as a compliment. I once referred to a friend of mine with a CS degree and job at a software company as a “programmer,” and he became irate. For him, “programmer” and “code monkey” are the same thing, insults that imply that all you do is write the code that other people tell you to write.
If you think there’s a divide between the IC roles, just wait until you see how wonky the leadership titles get. The divide here starts with whether the role manages people or not. Because being a leader in a tech org doesn’t always mean having direct reports.
If it does mean direct reports, then most employees will have “Manager” somewhere in their title. But, depending on the org, these could also include “Tech Leads” and “Principal Engineers” and people who have people under their wings. Either way, it’s important to offer an alternate path of growth that doesn’t include write performance reviews on underlings.
That alternate path of growth and leadership without managing people has a lot of titles that start with “Senior” and “Lead.” I saw one that started with “Bad Ass,” which could be senior or could be that you get paid in flattery. Who knows? Some companies, especially larger companies, number their roles, as in “Software Developer II,” which are usually very defined and indicate a more rigid hierarchy than you would get at a startup. Other high rungs on the IC ladder include titles like “Architect,” “Principal,” and “Technical Fellow.”
There’s another pair of related roles that have gained prominence in the age of networked applications: DevOps and site reliability engineers (SREs). DevOps came about because the folks writing code didn’t always consider the complexities around how that code behaved in production. They’d write, compile, and make sure it ran on their local machine. Once that step is clear, merge and we’re done, right? Well, no. Nothing behaves the same in production as it does in your local tests.
But as there are two roles that do this sort of thing now, what’s the actual difference between them? Google has a pretty extensive opinion on it, but these titles overlap enough that there’s no perfect division. Roughly, DevOps roles may be determining how to bridge development and operations, while SREs will be building that bridge using all the automation, CI/CD, and deployment tools they can find.
There’re a lot of other technical job titles out there that may indicate some amount of programming knowledge, but in specific contexts:
Names matter. When a technically-minded job hunter responds to postings, they’ll be selecting the ones that have the titles that they want to see on their future resumes. It’s the first thing they see of a posting, so make it count.