How to check seniority of programmer? I find this "Junior/Senior Developer" title wrong and misleading because there's no real measurement unit for this. We are all Software Developers with less or more hands-on experience. We should not try to create a hierarchy for Software Developers, there's no point and it can harm the main focus point: a great-software development team.
However, in our world there are differentiating factors between a.k.a "a senior programmer" and other programmers varies from company to company but the general rules can be broken down into a few categories: broad work experience, job quality level, and salary. Senior programmers solve problems. In general, they spend much more time on defining the problem and building cognitive models before jumping into coding. They understand programming is one of the means to solve a problem, and it's not the only one, in fact, in most of times, other methods are much more efficient. The junior developer may say "I have no idea why it crashes, I am stuck." A senior cannot have that luxury.
When I hear “Senior Developer” - 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.
Who is "Junior Developer" 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.
A senior developer must always be able to come up with a Plan B, a Plan C, etc. Someone has to deliver the bad news to the customer, and you can't just tell a customer "Gosh, I dunno. Seniors have positive and negative empathy. People who possess positive empathy don’t get jealous, they get excited when something good happens to someone else. Negative empathy is the ability to comfort others when they’re down.
Senior developers are humble. People who are genuinely enjoyable to be around are humble, not arrogant. They don’t wave awards in people’s faces. They don’t name drop for the sake of sounding important. They don’t toot their own horns. They don’t have an aura of I-am-the-coolest-person-in-the-world. Of course, it’s healthy to be confident and sustain a high self-esteem. But there’s a fine line between confidence and arrogance. And the difference is humility.
Senior engineers own non-trivial projects (feature or component scope), resolve ambiguous requirements with other stake holders, design implementations, make schedules, build projects plus test code, and as planned deliver quality solutions to QA unlikely to bounce back.
Progressing beyond senior engineer scale increases, scope requires leading other engineers (usually coach and guide, sometimes sell, occasionally coerce), planning should be strategic (what moves the business forward not just delivering a feature), and contributions are multiplicative.
Multiplicative contributions are in areas like process, architecture, and coaching. Taking a team from dozens of release candidates and slowing release cycles due to adhoc methods to code ready to ship via test-driven development has huge impact on the business.
Here is Amazon approach to select and promote senior developers:
Needless to say, a junior developer will require more iterations on code reviews, make slower progress, software releases can be eventful (not in a good way - that is, bugs and other issues), and they might miss out on important aspects of testing and monitoring. Therefore, a senior developer can be trusted to deliver a more critical piece of software.
A senior developer is able to distill complex problems through the application of design patterns. He/she is able to adapt design patterns to fit the needs at hand through thoughtful analysis of the problem space. As a result, he can be trusted with architectural problems involving many systems, not just coding problems.
Dealing with Ambiguity
A junior developer is usually trusted with a task. A senior developer is trusted with a problem. To solve this problem, the senior developer's responsibility is to distill the tenets (priorities) from the problem, determine what is in and out of scope, and make tradeoffs in debating the merits and drawbacks of several options, while also taking into account development costs and operational maintenance. Therefore, a senior developer can be trusted to take on problems without a defined approach.
A junior developer tends to underestimate the amount of effort needed to get a product released - this is largely a combination of lack of experience, domain knowledge, and insufficient upwards communication of progress. A senior developer has more of all these, so management is rarely - if ever surprised due to missed dates. Therefore, a senior developer can be trusted to deliver large projects independently, serving as a project manager of sorts.
A junior developer has trouble working with others who disagree with him/her. Sometimes the developer stops disagreeing and "goes with the flow", other times the developer is obstinate and comes off as arrogant. A senior developer is seasoned in the art of influence, and uses tact as well as data to ensure progress is made among all parties. As such, a senior developer can be trusted with cross-team projects that involve many engineers and managers.
In the same vein, a junior developer tends to develop solutions for a fixed problem. Whereas, a senior developer tends to think in terms of other teams or systems that have similar problems, and build architectural systems that might be shareable across the company. Therefore, a senior developer can be trusted to raise the software bar across multiple teams.
A junior developer considers what is the best technical solution to a problem. A senior developer, on the other hand, thinks about the needs of the business, and can be trusted to generate ideas and software that provide quantifiable business value. For instance, he may suggest a project to help you save money, resources, reduce error, and so on. He is able to justify business value using data and convince others to join him.
A junior developer thinks in terms of the project he/she is working on currently. A senior developer is thinking about the challenges the team will face in 6 months to 1 year and is already working with management to solve those problems now. In this vein, a senior developer is a partner to management.
What else Senior Programmers do?
They are genuinely interested in EVERYONE. Remember how likable people are humble? Well, they’re also not pretentious. That means they don’t hold a chip on their shoulder when dealing with someone who is “under” them. They are genuinely interested in what EVERYONE has to say. They want to hear their story.
They reciprocate praise (and can take blame). When a likable person is praised for their work, they typically have a response like this: Thank you so much! However, I’d like to emphasize that this was a team effort. I played only one small role in hitting this goal. Jen, Sam, Mike, and Kelsey…you were all crucial to making this happen. And we wouldn’t have done it without you. In other words, they give credit where credit is due. When they’re recognized for a success, they shift the praise toward everyone else. They give praise and empower people without expecting anything in return. Conversely, when shit hits the fan, they aren’t afraid to take the blame.
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 engineers take end-to-end ownership for development and quality of products and services that delight customers and add strategic value for Microsoft. They evaluate requirements, estimate costs, design, and implement products and services. They define and implement the quality criteria for their products and services, using measurements and insights to understand and validate the quality of experience for customers. They manage and improve the engineering process, manage risks, dependencies and compromises, and integrate software into broader ecosystems and/or products.
Microsoft wants to have the following things from you if you are really looking to be a senior engineer:
1) Develops high-quality code to meet technical requirements, such as scale, global delivery, and implementation across distributed systems, monitoring, serviceability, testability, debugging and maintenance. Builds the associated tests to validate the code both at the unit level and end-to end-level. Develops infrastructure that meets the expected return on investment (ROI). Uses technical software development skills to identify problems and to advocate for improvements to the product or service design. Leverages his or her experience with multiple product or service releases to allow only that which satisfies and delights the customer into the product or service.
2) Creates and validates efficient (low-latency, high-throughput), stable, secure, maintainable, scalable, performant, well-tested, and reusable code that enables customer and business goals for the product or service. Builds the correct tests and tools to validate that the code meets quality goals of the product or service. Analyzes data and presents conclusions in a manner that enables self and peers where appropriate to understand and solve problems. Ensures that quality is maintained throughout the entire life of the product or service. Defines quality metrics, best practices, and coding patterns, and provides deep expertise on the coding strategy. Chooses the appropriate internal or external technologies, incorporates research, creates designs that are reused across the team, and is an excellent judge of practices that work well.
3) Takes end-to-end ownership for development and quality of products and services that delight customers and add strategic value for Microsoft. Software Engineers evaluate requirements, estimate costs, design, and implement products and services. They define and implement the quality criteria for their products and services, using measurements and insights to understand and validate the quality of experience for customers. They manage and improve the engineering process, manage risks, dependencies and compromises, and integrate software into broader ecosystems and/or products.
4) Builds the right team. Acts constructively to increase the efficiency, impact, and morale of the team, as a whole. Works proactively across team, product or service, or platform boundaries to share information and technology, and ensure that peer team goals are aligned. Promotes a positive environment across the organization by modeling behavior that promotes good morale. Finds opportunities for collaboration across groups in the division, ensures that cross-team commitments are set, and achieves scale in his or her work efforts by enabling the work of others.
5) Has a sense of personal accountability for the quality and completeness of the entire product or service and resulting user experience. Maintains a sense of pride and craftsmanship that yields output with aesthetic, as well as technical value in the product that we ship. Resolves issues outside his or her area of responsibility and opens discussions with peers and takes action when needed to ensure the success of the product.
According to Adam Grant, the youngest-tenured and highest-rated professor at Wharton School of Business, there are three types of people: The Taker is an egoist. They tend to get more than they give. They believe the world is a competitive, dog-eat-dog world. As a result, they put their needs before everyone else. This strategy works for short-term gain … but it’s nearly impossible to sustain. The Matcher is someone who seeks balance between giving and taking. They seek fairness and equality. If they put too much into a relationship, without getting anything in return, they’ll eventually give up. They believe in even exchanges and trading favors. The Giver is altruistic. It’s a rare breed of human who doesn’t look for anything in return. Whereas Takers are focused on receiving all of time and Matchers are focused on receiving at least some of the time. Givers don’t even think about it. As senior programmer is someone who is experienced enough to have solved many programming challenges. When a problem shows up, a senior programmer will likely have a history of solving that problem vs. a regular or junior programmer who may get worried or afraid about this new problem. "When should you call yourself a senior developer?" - When I started to mentor junior developers.