What defines your seniority?
We live in the 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, other custom names, or there are even cases where they define their own framework.
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 must 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 help me to understand a lot more in what other areas should I put the focus when looking for experienced profiles or new opportunities for me.
And based on that I came to the conclusion 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 will like to clarify that this is my personal opinion, and that doesn't mean that this should be the one and 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.
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 where 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.
An experienced dev should know how to work solo and within teams, where they can act as leaders, 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, stakeholders management and alternatives to avoid being a people pleaser.
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 in 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 including all the reorganizations that I 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, opinions, ask questions, and also important accept other people's opinions.
On a side note but also worth it sharing, we shouldn’t be afraid to share vulnerabilities or areas that we think we can improve.
Challenge and Push-backs
There are times, where well-founded pushbacks need to be made, especially during negotiation about priorities with the different stakeholders. And, in a respectful way, 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 in a smart and healthy way 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.
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 responsibilities, knowledge transfer sessions to less experienced devs in order to unblock them to performance smoothly.
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, give the team the opportunity to learn and move out of their comfort zone.
Creativity and think outside of the box
Thinking outside of the box, encourage 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; converts 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 to follow their way without feeling like they are imposing rather than explaining an idea.
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 really 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.
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 in order to get a better result. Even in times where the feedback is good by being self-critical, we can prove to ourselves that there is always room for improvement.
Being able to follow up a negotiation without being bias for just a feeling or your own preference should be key to always have a curious and objective mindset.
Clearly, apart from things that make you a better dev, there are others that 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 who 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!!