It is quite common to measure professional seniority in bare years, which is understandable due to its simplicity, but also unfortunately incomplete because real expertise mostly very poorly correlates with the number of years nominally spent in the industry (unless defined that way).
Measuring seniority by years is like measuring driving skills not by the actual miles driven on a variety of terrain and environments, but simply by the number of years you've had the driving license — which is exactly why pilots are licensed in actual flight hours.
RAPID Scale differentiates seniority levels by actual software engineering practice in several key categories. By this scale, seniority is granular and one can be senior if (s)he is senior in at least one area. The more areas one is senior in, the more seniority can be ascribed and matched with a corresponding corporate title. For example, one corporation may decide to give the title of Senior I if the person has seniority in at least one of these areas, while another corporation can have it given if at least two are met.
Low-level problems (algorithms, libraries, APIs, etc.)
Junior Finds solutions in time 3x
Mid Finds solutions in time 2x
Senior Finds solutions in time x
Architectural
Junior Has written a solution with at least 1K+ lines of code from scratch
Mid Has written a solution with at least 5K+ lines of code from scratch
Senior Has written a solution with at least 10K+ lines of code from scratch
Navigating code of comparable solutions
Junior Can navigate 10K+ lines of code successfully & on their own after time x
Mid Can navigate 50K+ lines of code successfully & on their own after time x
Senior Can navigate 100K+ lines of code successfully & on their own after time x
Navigating errors & warnings
Junior Has resolved 1000+, mostly by googling & asking the AI
Mid Has resolved 3000+, recognizes and fixes many by just reading what it says
Senior Has resolved 5000+, recognizes and fixes most instantly by glancing through
Navigating StackOverflow
Junior Recognizes a solution to the problem at hand in the answers
Mid Able to compare competing solutions and choose the best one
Senior Has a firm grasp on which solutions are authoritative, old, new or best
Using AI-generated code
Junior Able to integrate suggestions into an existing solution
Mid Recognizes if the suggestion is better than what (s)he would have done
Senior Recognizes limitations behind an obviously imperfect suggestion when sees one
Rules & Best Practices
Junior Knows where to look up and applies successfully
Mid Knows where to look up and applies them effortlessly
Senior Knows when to bend or break them and when to create new ones
Development Productivity Tools
Junior Uses a few of them
Mid Uses all that's available for the project
Senior Has written at least one for own use
Documentation (including code itself)
Junior Can often get carried away reading when actually has read enough
Mid Recognizes when, where & how much to read to implement the task at hand well
Senior Recognizes when & how documentation can be improved to save others significant time
Emerging Technologies & Trends
Junior Has been following for several months
Mid Has been following for several years
Senior Quickly recognizes which are particularly noteworthy
Command Line Proficiency
Junior Can use and navigate scripts
Mid Has written a few 100+ line scripts
Senior Has written dozens of 100+ line scripts in more than one language
Interns
A word about interns in software roles.
The one simple reason companies are often hesitant to hire software engineering interns is that they usually have a prior impression that interns take more time asking senior engineers for help than solving problems. Now, when this happens in environments that are strictly specific to the company and their product, it's obviously completely normal and expected.
But the problem is that much more frequently this happens for things that the intern could have very easily learned on their own, especially in this day and age of limitless online resources — and that's when and why companies get conscious and cautious on this issue.
Also, it doesn't help that what's usually listed in job descriptions and asked during technical interviews doesn't at all reflect the needs of an actual daily work (hence the many memes about this), which forces candidates to memorize things like design patterns and sorting algorithms along with their complexities, even master hundreds of LeetCode question, but end up having absolutely no clue on how to google to resolve an error, spending an entire day to center a div, and having real panic attacks on even the most trivial merge conflicts.
I strongly believe that it's really not that hard to have a different approach.
For example, there are certain, clearly measurable markers that are much more indicative of whether someone will mostly take up senior time justifiably. These include the following:
- Being comfortable with English enough to navigate online (e.g. StackOverflow, AI-generated code)
- Having written about 500+ lines of non-trivial code as part of a project
- Having at least 50+ non-trivial commits within a project on GitHub or similar hubs
- Having seen and resolved 500+ errors and warnings
- Having seen and resolved 10+ merge conflicts
I have never seen points 2-5 explicitly mentioned in job descriptions for interns. Yet these are the bare minimum skills with experiences of a real world, which simply assure that the intern will spend more time adding value — even if only by learning and navigating mostly on their own — than taking up valuable time from more senior engineers by asking for their help for things that, again, are very easily learnable on your own these days.
For fairness, though, I'll have to say that there are quite often other problems, unrelated to the experience of the interns themselves, that lead to companies being hesitant to hire interns. For example:
- Codebases are too complicated and not designed to be modular and junior-friendly
- Work isn't being chopped up into senior / juniors chunks well enough
The irony is that when things are done right, for the fastest progress on a project, interns and juniors are absolutely necessary in all engineering fields, not least in software, because any complicated work, when approached well and divided properly, will always reveal simple component problems that are wasteful for seniors to work on (like repetitive adding of test IDs to all elements for test automation), but are very instructive for juniors (because they have never done that in the sophisticated environments of large codebases).
