DEV Community

Manuel Obregozo
Manuel Obregozo

Posted on • Originally published at manuelobregozo.com on

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.

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, 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 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. 
Enter fullscreen mode Exit fullscreen mode

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.

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 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.

Autonomy

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.

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 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 thought 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.

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 responsibilities, knowledge transfer sessions to less experienced devs in order to unblock them to performance 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, 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.

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.

As always, I am looking for opinions, so in case you have any comments or feedback, please share!!

Top comments (0)