I don't think the title has lost its meaning entirely, but it is entirely relative to the company size. A "Senior" at a 10-person startup is often just the person who has been there the longest and knows where the bodies are buried. Put that same person at a FAANG company, and they might map to a mid-level IC4. Instead of looking at the title on the business card, I look at their systemic impact. Are they fixing bugs, or are they fixing the engineering culture that allowed those bugs to happen?

There is a massive difference between 10 years of experience and 1 year of experience repeated 10 times. That is why some veterans still call themselves mid-level—they have the humility to see how deep the rabbit hole goes. True seniority is defined by how much you multiply the output of the people around you. If you are a coding wizard but a bottleneck for your team because you don't mentor or document, you aren't a senior engineer; you are just a highly productive individual contributor.

The title has definitely been diluted by HR departments using it as a retention lever, but the industry standard still exists implicitly. I differentiate seniority by how a developer handles ambiguity. A junior needs a fully spec’d out ticket. A mid-level needs a well-defined feature goal. A senior can take a vague business problem ("our checkout flow is dropping users") and translate that into a technical roadmap, coordinate the team, and deliver the solution. That level of product empathy can't be rushed in 2 years.

To me, being senior has very little to do with syntax or years on a resume, and everything to do with ownership and risk mitigation. A true senior engineer isn't just someone who writes clean code; they are the person who can look at a product requirement, foresee the architectural bottlenecks six months down the road, and steer the team away from them.