Hi everyone! After a period of writing hiatus, I’m back and trying to get back into the swing of things. I would like to stress that the experiences shared here are based on my academic and professional experiences. Therefore, it is important to remember that what is described here may only represent a fraction of reality and should not be interpreted as a definitive formula for any particular process, procedure or service.

I am currently very excited about this new chapter in my career. I have learned a lot and want to share some of this journey with the community. I hope the information presented here will be of great value to readers.

People are the focus – The importance of soft skills

When I took part in my first selection process a few years ago, I still remember the almost boring steps I went through: interview with HR, practical test, interview with the technical lead and finally interview with the manager. During my career as a developer, I attended several interviews with different models. Back then, I always felt uncomfortable during interviews with HR people. I didn’t quite understand why and thought: “If I can do what is required in the technical test, I already show enough competence for the job.”

When I took on my role as Head of Engineering, one of my tasks was to prepare a technical test together with HR (yes, the same people who I didn’t understand why I was taking part in the selection process) and define the interview format for two candidates starting in the backend area. I thought I already knew what a beginner developer should deliver in the backend area and what would be considered a differentiator in the test. What I didn’t expect, however, was that despite the importance of code, there were other requirements that arose beyond project delivery: How do you evaluate candidates in terms of communication? What interest do they have in the role? And how can the context they present influence their suitability for the proposed role? These and other questions turned out to be as relevant as the code presented by both candidates, something I hadn’t previously considered in my early years as a developer.

I remember sitting at the boardroom table to make the final decision and being a little surprised at how little was discussed about each candidate’s technical skills. This was partly because these were entry-level candidates, so it was to be expected that their technical skills would not be as strong, and this was not the main focus of the discussion.

But even for more demanding roles, especially senior level positions, it is important to consider skills such as communication, documentation, adaptability, proactivity and other often mentioned skills. These soft skills are fundamental and, alongside technical skills, can be crucial to success in the role. That’s actually my next point.

The boundary between junior and senior (no, not middle level).

I know there is a lot of debate about the meaning and classification of terms related to experience levels like “senior”. Some say that “senior is defined by years of experience”, others claim that “in some companies, you get senior experience after one year”. There are also those who say that “there is no clear distinction between junior and senior” or that “seniors only do code reviews and approve PRs”. Some of these statements are funny, others contain a grain of truth. The fact is that the term “senior” is very diverse and it is not my job to define a universal standard, but I can give some pointers to understand this classification in a more individual way.

Being a senior does not only mean technical knowledge, although this is undoubtedly very important. A real senior, or at least a good senior, is someone who is able to solve complex problems both in terms of code and system architecture. Maintaining code quality, following good development practices and knowledge of project management are crucial aspects.

The main difference is that a senior must be able to do all of this autonomously and, more importantly, collaborate with teams from different levels and areas to deliver the best project possible. Moreover, a true senior (or at least the best ones) not only leads and leads the team, but also develops and prepares other developers for new positions and responsibilities.

My first experience as a project manager

When I took on my first project, my boss knew that I had never managed any other project before. I was just involved in development and working on some things that would make development easier in terms of communication with management. The first question he asked me was: “How many people and what type of personnel will be sufficient to complete the project?” I didn’t know the answer right away, it was a very complex question. Since the project was only in the design phase, we had no idea about the stack, how much time we would need to complete each task and other metrics that were of interest to the people from above. I conducted a comprehensive study of several project management methodologies to be able to deliver the next day: Pert, Planning Poker. We jointly chose the method that was most suitable and the challenge began. It was clear to each team member what the best development platform is, which stack is best to use, how the system architecture will work, we studied other solutions on the market, monitored the level of each developer, Meeting, meeting and more meetings with management.

When I least noticed it, I found myself becoming more and more distant from the code. My role now was to suggest improvements and fix some critical bugs so that the project could work, or at least provide a solid foundation for developers to start. The rest of the work involved communicating with developers, assigning tasks, monitoring metrics, and essentially keeping one eye on Asana (to estimate project delivery time) and another on Meet to make sure my microphone wasn’t on and nothing unwanted “accidentally” slipped through.

Conclusion and a look into the past – the master with affection

I started my career as a development intern and interestingly – and you might find this a little contradictory – I had no concrete experience (at least not formally recorded in my work reference) that would classify me as a junior, full-time or senior developer. Much of my experience was gained through personal projects and research in college. It was a gradual process until I realized that my skills had evolved since those early days.

But yes, I have worked extensively as a developer at different levels and have had the opportunity to meet different types of experienced professionals throughout my career:

1. The very competent and effective but uncommunicative manager who solved problems without explaining his approach.
2. The senior has excellent communication and teaching skills, but is often overloaded with urgent tasks and has no time to teach.
3. The senior who was passionate about over-engineering and centralizing technology, but met deadlines and delivered what he promised.

The most important thing is that all of these professionals, despite their legitimate shortcomings (although it is possible, it is very difficult to balance the requirements), had something valuable to impart. These experiences shaped my career and gave me a clear view of what works and what doesn’t in systems development.