RAPID Scale

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:

  1. Being comfortable with English enough to navigate online (e.g. StackOverflow, AI-generated code)
  2. Having written about 500+ lines of non-trivial code as part of a project
  3. Having at least 50+ non-trivial commits within a project on GitHub or similar hubs
  4. Having seen and resolved 500+ errors and warnings
  5. 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).