What defines your seniority?
Photo by pascal_habermann on Unsplash
We live in a world of labels, where we have to categorize ourselves without any standards, which makes this more difficult than ever. Plus, the concept that defines that can vary depending on companies and people.
Despite the position or the path you take, there will always be uncertainties about levels. It is just something that mainly companies use to categorize the expertise of a developer so that they can define pay bands. Some prefer to have numbers or other custom names, or there are even cases where they define their framework.
But what in particular defines whether you are a Senior developer or not? In my humble opinion is not ALL about technical knowledge. As in, you can study JavaScript on your own, read every book, do tons of courses, and do JavaScript projects, but that will not make you a Senior Developer, even less for team-based positions.
Don’t get me wrong, design/architectural patterns; how the different parts of the development ecosystem work, and the fundamentals of the main programming languages ARE important, and we can go into the details about what are the most and the nice to have as a dev, but that is not where I would like to focus on this particular article.
For the last few years, in Argentina, The Netherlands, and now Spain, I have been doing interviews from both sides of the table, as an interviewee and an interviewer, which helped me to understand a lot more about what other areas should I put the focus when looking for experienced profiles or new opportunities for me.
And based on that I concluded that the more I do interviews the less I focus on technical topics.
But then, where should we put the focus instead? Before I start with the description of the subjects I would like to clarify that this is my personal opinion, and that doesn't mean that this should be the one and the only way to do this, and please DO NOT USE this as a checkbox list.
First clarification, I don’t like to use labels such as junior-mid-senior so I will use “experienced developers” instead.
Empathy
Lately, this has become a trending topic, as the new skills to have in the new modern world, please noo! This skill was always important but it was recently re-discovered during the pandemic. A difficult time when we all faced a worldwide problem and were forced to adjust our systems and be more empathic because this situation affected all of us in many different ways. So, in summary, the ability to reflect and consider things from another person's shoes will bring you more joy than you think. And, in different situations, this can be the key skill to unblock things or even prevent friction.
Autonomy
An experienced dev should know how to work solo and within teams, where they can act as leaders, and motivate and encourage others to perform in a different and potentially better way. Something that in the long run will make others generate a positive impact in the company or the position they are working for. Two things that can be important to discuss under this point are how people manage their time and how people prioritize their work because you just can not make everybody happy. In other words, stakeholder management and alternatives to avoid being a people pleaser.
Foresee problems
Ways to prevent errors in the future by following different processes or techniques is one of the questions I sometimes ask. There are no good or bad answers here, I always learn about how people avoid getting to a point where they think - I should have noticed this at an earlier stage.
Opinions and Transparency
I have worked in different types of companies and domains, where politics and negotiations were crucial for the development of the products we have built. That includes all the reorganizations that I have been through from waterfall to agile. So by sharing my experience and learnings, I can help to prevent making the same mistakes I have already seen and experienced. An experienced dev should not feel afraid to share previous experiences, and opinions, ask questions, and also importantly accept other people's opinions. On a side note but also worth sharing, we shouldn’t be afraid to share vulnerabilities or areas that we think we can improve.
Challenge and Push-backs
There are times, when well-founded pushbacks need to be made, especially during negotiations about priorities with the different stakeholders. And, respectfully, don’t be afraid to challenge other people's solutions.
Motivation and Proactivity
This doesn’t mean that you have to work harder until late hours but smartly and healthily of prevention and planning. The ability to unblock your pairs, make them believe in themselves, and make them able to achieve their goals in the short and long run.
Coaching
As soon as you become more experienced, you start developing coaching and teaching skills. And within team-based jobs, this can be a must-skill to have. Promote other devs to take responsibility, and knowledge transfer sessions to less experienced devs to unblock them to perform smoothly.
Delegation
This will open the box to take upon new responsibilities. Gain the trust of the team, and also trust the team is the main driver of delegation. Will make the team perform better, allow the team to learn, and move out of their comfort zone.
Creativity and thinking outside of the box
Thinking outside of the box, and encouraging creative solutions will unblock you from different external dependencies in difficult times. Apart from the fact and main reason that we all deserve the same opportunities, this is why diversity in a team can be super important!
Lead and host meetings
When dealing with heated conversations and negotiations I would expect the experienced dev to lead the situation and host meetings accordingly to tackle things; and convert limitations, dependencies, and problems into solutions as pragmatic as possible. Always led by a clear way of communicating.
Distinguish arrogance from confidence
This is something that I always try to observe while talking to potential candidates, but it is not always easy to notice. Especially when dealing with technical discussion is good to see how the other person reacts to something that is not certainly correct, and how they try to convince others to follow their way without feeling like they are imposing rather than explaining an idea.
Advocate
A bit related to the previous point, but from a management perspective. This refers to the confusion between leaders who impose with the ones who lead the team to better places. Not necessarily linked to leaders, team success never depends on only one person. Thus advocating for your colleagues increases self-confidence and their feeling of belonging and contribution to the team.
Self Reflection
The ability to reflect on everything we do gives the feeling of continuous improvement. Looking back on how things were done and how we could have taken a different approach to get a better result. Even in times when the feedback is good by being self-critical, we can prove to ourselves that there is always room for improvement.
Negotiation
Being able to follow up a negotiation without being biased by just a feeling or your preference should be key to always having a curious and objective mindset.
Final disclaimer
Apart from things that make you a better dev, others won't. And it is something that I see quite often out there. And it's TIME.
Don't be fooled by the people who consider themselves experienced or senior devs just because they have worked in the field for X years. Time was never and will never be a way to measure how good you are as a dev, even less as a professional.
As always, I am looking for opinions, so in case you have any comments or feedback, please share!!
Written by Manu
I am a product-driven JavaScript developer, passionate about sharing experiences in the IT world, from a human-centric perspective.