In my current company I'm a senior developer. I recently interviewed for a senior dev position at another place and the feedback I got was terrible. Personally I think the interview didn't cover enough areas at all, but that's just me trying to rationalize a quite shocking result.
Either way, it's led to me questioning what the most commonly accepted standard for senior devs is, as I know that it can vary quite widely.
For me personally (6YOE, non FAANG, mostly web work, .NET if it matters) my standards are:
Can take any general software development task and just do it, using the full suite of features and syntax available in the framework being used
Writes quality, readable, efficient code with few basic mistakes
Knows the wider impact of their work, either through innate understanding or from repeat experience of standard development tasks
Knowledge of databases and how to manage and interact with the data via queries and stored procedures
Has a good understanding of the most important software architecture principles, common design patterns, etc
Can contribute to discussions on any new task or feature and play a part in agreeing on any final decisions
Understands and experienced with project management concepts like agile, scrum etc
Ability to mentor or guide junior members
Ability to perform code reviews
Knowledge of CI/CD and unit testing (though in my company that's left specifically to DevOps/ QA teams)
To be honest this is more like a list of "the level I'm currently at" (and incidentally is all the things my recent interview experience did not cover). Personally I think it might be considered mid/upper-mid level by some standards, which is fine by me because I know it can vary from place to place, but my latest interview feedback left me feeling like I was only a junior in their eyes. Strange because I'm surrounded by juniors at work and it's clear to me that I've advanced way way beyond that. But now I'm just ranting.
So let's see what standards you guys have for senior devs, according to your own / your company's way of thinking.
Thanks.
skills - When should you call yourself a senior developer? - Software Engineering Stack Exchange
What is your expectation of a senior dev?
What does it require to become “Senior Software Engineer”?
"Exceeding Expectations" as a Senior Software Eng and beyond
Videos
Before I dive into this I want to say something I consider very important:
- It is extremely normal to have doubt about your "performance" when you're starting a new position, especially when you're thrust into a senior-level role where your "peers" are people who have years of experience/expertise with the company.
With that being said... stop being so hard on yourself. I know it isn't that easy, but no matter how experienced you are or what point you're at in your career it takes time to ramp up when you start with a new company. That's especially true when it comes to software development because of the massive differences there can be from company to company or even team to team when it comes to environment, standards, languages, etc.
The important thing (IMO) is that you keep a positive attitude, demonstrate that you're working hard, and do your best to influence the things you can based on your experience. For example, another posted mentioned things like contributing to coding standards, mentoring junior programmers, security, etc. Those are things that are universal and don't require expertise with a process/application to be involved in and provide input.
I would also say that if the company doesn't have documented development standards that could be a good place for you to take initiative and document them. See if you can sit down with your peers and the solution architect and document their standards (don't hesitate to make suggestions). Not only will it help you familiarize yourself with their environment/expectations, but it will provide a benefit to any future new/junior developers who come on board when they start to ramp up.
Besides that: just keep at it. Try to understand the process and the requirements and then dig into the functional side of the code. Over time you'll gain the experience you need and you'll find you aren't asking as many questions until the day comes when you realize that people are coming to you for answers.
As a final note: communication is important. I wouldn't go to your supervisor/s and express that you're feeling insecure about your performance, but it is completely ok to ask for feedback and make sure they know that you care about being a valuable member of the team and that you are constantly striving to improve yourself.
The best way to find out if you are fulfilling the expectations of your role is to ask your manager.
Arrange some time for a one on one with them, let them know in advance that you'd like feedback about how you're settling into the role (so that they don't get put on the spot, and have time to think about relevant feedback before talking to you), and then listen to what they have to say.
Note that I said "how you're settling in" instead of something like "is there anything I'm doing wrong". I deliberately chose neutral language. Your manager quite possibly thinks you're great, don't set a negative tone when you don't need to.
You can call yourself a Senior when:
- You can handle the entire software development life cycle, end to end
- You lead others, or others look to you for guidance.
- You can self manage your projects
Software development is a curious creature unlike other fields.
Sometimes, a fresh punk out of college can run circles around veterans who have 20+ years of "experience". Programming is a bizarre world where code is king.
Some achieve the above in 2 years or less, others take 10 years.
When I hear “Senior Developer” I think of someone who has mastered programming. I think of a person who can design, code and test a system. They can talk to system architecture or component design. They understand and use design patterns. This person can anticipate the performance bottlenecks, but knows not to pre-optimize. This person will leverage asynchronous programming, queuing, caching, logging, security and persistence when appropriate. When asked they can give a detail explanation of their choice and the pros and cons. In most cases they have mastered object oriented programming and design, this not an absolute other languages such as Javascript, F#, Scheme are powerful and are not object oriented. They are adept in risk management and most important of all they can communicate the before mentioned to their peers.
What is mastery? There is a generally accepted idea, that to master ANY one skill it takes 10,000 hours of repetition for the human body and mind to grasp and internalize a skill. This is written to at length in Malcolm GladWell’s book Outliers. When the original author talked about mastering a field, he was refering to reach the top of a highly competitive field would take 10,000 hours.
Some examples of in Malcolm GladWell’s Outliers are:
Mozart his first concerto at the young age of 21. Which at first seems young, but he has been writing music since he was 11 years old.
The Beatles were initially shunned. They were told they did not have the mustard and should consider a different line of work. They spend 3 years in Germany playing about 1200 times at different venues, each time being 5 to 8 hours in length. They re-emerged as the Beatles we know and love today.
And lastly, Bill Gates at age 20 dropped out of Harvard to found Microsoft. To some this might seem foolish, but considered at 20 he had spent nearly half of his young life programming. In 1975, only maybe 50 people in the world had the experience he did. His experience gave him the foresight to see the future in Microsoft.
Peter Norvig also discusses the 10,000 hours rule in his essay “Teach Yourself Programming in Ten Years”.
In the book Mastery by George Leonard, great detail is given on how to master a skill. One must practice the skill over and over and over again. The more the repetition, the more you become aware of the differences in each repetition. Only with this insight can you become better.
The software industry’s titles (Junior, Mid-Level and Seniors) are misleading and inconsistent from organization to organization. I’ve worked with companies, who defined a Senior Developer as someone with 5 years or more of experience. There is no mention to the quality of the experience, just that they sat in front of a computer for 5 years. In working with these folks, many of them had not yet grasp object oriented programming -- yet they were considered Senior Developers.
There must be a better more objective way to measure the skill set of a software engineer. John Haugeland posted a computer programmer’s skills matrix. It’s an objective way to measure a programmer’s skill level, which otherwise is left to gut feeling.
When looking at software engineers I see 4 tiers of skills: Luminary, Senior, Mid-Level and Junior.
Luminary (10+ years) is one who has mastered a skill and has set about improving their respective discipline. Some examples include: Ted Neward, Uncle Bob Martin, Donald Knuth, Oren Eini, Peter Norvig, Linus Torvalds. Luminaries change based on your skill-set.
Senior (7 to 10+ years, Level 3) is one who has spent the last 10,000 hours programing in a specific genre. There is a strong understanding of design patterns, They leverage asynchronous programming, queuing, caching, logging, security and persistence when appropriate.
It’s very possible that a Senior will never reach Luminary. Luminaries are often found speaking and writing. They are actively trying to impact their discipline.
Mid-Level (4 to 6 years, Level 2) is one who understands day to day programming. They work independently and create robust solutions. However they have yet to experience creating or maintaining large or complex systems. In general Mid-Level developers are great with component level development.
Junior (1 to 3 years, Level 1) is one who understands the basics of programming. They either have a degree in software engineering or computer science or they are self taught. Their code is continually reviewed. Guidance is given in regards to algorithms, maintainability and structure.