The career ladder. Everyone wants to climb it. I did write before that for young George, and many other developers, the career of a developer looked like this:

  • Junior
  • Mid level
  • Senior
  • Manager
  • VP of Engineering
  • CTO
  • Elon Musk.

After talking with a lot of people this progression sounds like what most employees and organisations have in mind. People go through reviews talking about achieving that elusive middle ground of senior developer. What happens once you do? And more importantly, how do you do it?

Becoming a senior developer

Let’s be honest. Ideally you want a list of bullet points that you can go through and check them against you. A quick answer. But like everything in life there is no quick answer here. There is no one list of things that works for all people or all companies.

There is though one thing that defines a senior vs a junior. Confidence in tackling a diverse amount of issues and problems. Being more comfortable with the unknown unkwowns. How do you get there? With patience and curiosity.

Patience is required in order to gather lots of experiences. You need to go through a diverse amount of scenarios within your role. Ideally I would say in a diverse amount of organisations or within one organisation but different departments. The reason being that the different business problems you will be solving will force you to use different technologies and tackle different problems. And you will make mistakes, you will feel useless and ignorant. It’s a right of passage. Know thought that we’ve all been through the same. It’s fine.

Curiosity is required in order to make a note and learn all those things you won’t know. Don’t brush off anything. Don’t say “I’m a backend developer, I don’t need to know about the front end”. Learn about it, even in the form of theoretical knowledge. Don’t expect your manager to give you a task. Do a tutorial, do a side project, write code in a playground. Get your hands dirty and understand the basics. It will make you stronger.

More importantly, focus on the fundamentals. Knowing JavaScript is more important that knowing all the frameworks. Knowing Java is better than knowing all the frameworks. Knowing design patterns is better that accepting a way of solving a problem as gospel. Know basic algorithms but don’t sweat too much about it, unless you aim to work for a FAANG in which case leetcode your way there.

Finally the biggest skill you need to work on is your soft skills. Learn how to tame your ego, how to not be emotional in the face of criticism, how to not take things personally. These are the things that kept me, and a lot of excellent engineers I know, back. You need to be anti-fragile. You need to use all the bad things that will come in your way as opportunities to learn, grow, become more resilient and therefore more successful. Take it as a given, shit will happen. Embrace it, use it, make it a treasure.

What do I do as a senior developer?

This section is equally important for employers and employees. This is setting the expectations in a way. What does a senior developer do? What should you do to be successful in your role?

I wish there was one answer. The reality, again, is that different organisations require different things. I do believe though that the core is the same everywhere. The general theme of a senior developer is that you should be a “shit umbrella” for your team, especially the more junior people.

Being a “shit umbrella” to me means doing the tasks that a lot of the times are thankless, the tasks that aren’t high profile. The tasks that a more junior team member either will fail to keep being motivated to do them or simply won’t know how to achieve them.

Why, I hear you ask. Because the biggest asset you have is the ability to see the bigger picture. The bigger picture here is that helping your team grow professionally and in confidence will make your work easier down the line. Levelling up people will lead to a more resilient team, a happier management, a prouder you. Know that while those tasks you do seem thankless, are not being unnoticed. I am not talking about management. You won’t get a golden star for spending 3 days in a yaml file, improving the speed of the CI by 22%. I am talking for those colleagues of yours that years down the line will remember you for being a team player. Trust me when I say that this network building is invaluable.

Another important thing is mentoring. A good senior developer is one that can mentor people, work with them and show them their way of thinking. Mentoring isn’t about fixing peoples problem. Teach a person to fish, don’t give them a fish. My preferred tools are pair programming and active listening. Pair programming to give hands on guidance and active listening to understand the aspirations and the way of thinking of a person. There is a lot more in mentoring but the gist of it is being there when your colleague needs you. Make yourself available. Check in.

Hiring a senior developer

I have done my fair share of hiring and I know how difficult it is. The recruiters are doing the tough job of combing through a lot of CVs, organising interviews, coordinating with team members. Your developers are taking time off coding. Round after round you are investing money in that process. Same goes for the interviewee. They have to keep making decisions. Decisions that wear you out. Should I reject this company? Does it fit with my principles? Do they pay me enough to provide for myself and my family? Are they inclusive? All that questioning is wearing you out. As a result a difficult process becomes almost unnatural.

How do you make it better for everybody? Don’t lose time testing basics. Don’t focus much on the basic principles of a language. Don’t ask how Object Oriented programming works, what is polymorphism or what is hoisting. The developer likely knows all that. Spend at most 5 minutes to temperature check that. Don’t give take home tasks, you are losing all those people with families and busy lives. Instead do one good online round of coding. Offer the candidate the option to use an existing online coding environment or their own laptop and pair. Don’t waste time there though. Make sure that they can start coding immediately. Focus the coding round on what you really care for, don’t leave it broad. For example if you are hiring a front end developer and you care about React focus there, don’t ask them to write HTML and CSS. Likewise, if you want a Java developer don’t ask them to write yaml files, or xml configuration.

Having a design interview is more important than the coding interview in my opinion. The best design interviews I had were ones that asked me to provide a diagram of an existing system I worked on and talk about that. I like the fact that makes me feel at ease, they test my ability to do diagrams, that I understand how a system works and then they can dive deeper on more specific aspects of the system design. Don’t copy “Grokking the design interview”, we have all read it by now (If you haven’t read Grokking the design interview, do it. It’s spectacular).

Pair a senior developer with both a junior and a senior developer in an interview. Don’t leave only one or the other. The junior might misunderstand realism for cynicism and the senior might ignore lack of ability to explain concepts and their way of thinking. An additional benefit from a candidates perspective is that they get to interact with different levels of experience in your company and they get a better feel for the culture.

Acknowledge that most senior developers are not amazing with algorithms and certain computer science core concepts from a theory perspective. The reality is that the type of problems you solve as a senior are more mundane but really value adding to the team. I’m not saying don’t test them, but I would say that you should set your expectations correctly.

Last, but not least, don’t approach any professional, let alone a senior developer, with a job spec, fancy words, the promise of competitive salary without saying how much you are paying. If your salary is competitive then you won’t have a problem saying what it is. They know what they worth, you know your budget. By not saying it we are losing time.

What to expect once you hire a senior developer

A sentence that I’ve been hearing through my entire career and I dislike it is “we want someone to hit the road running”. They will run alright, but if you want them to run towards the right direction and not distract the team you need to onboard them and support them. No matter how senior or junior they are. You should expect some onboarding time.

A senior developer most likely will come to you with questions and suggestions. Those things will probably be learnings from old experiences. Experiences that can be either good (successes) or bad (learning from failures). It is important to address all those suggestions. Let them know if they are suggestions towards the right direction or not. If they are towards the right direction ask them to write them down and share them with the team for discussion. If they are not, let them know why. It will promote learning for them and offer an opportunity for adjustment.

Another reality to be expected is that any person, let alone a senior, will require adjustment time before performing to the peak of their abilities. A big reason behind it is the fact that they need to leave behind well-formed habits from their old job. It shouldn’t take long but they will need time.

Finally you should expect for them to add value to the team once they are settled in. They will have their strengths and their weaknesses. You should identify both and support them on their weakness and enable them on their strengths. Build a team around a couple of senior developers and if you choose right you should see magic happening.

Epilogue

I hope it is clear by now that a senior is not a unicorn that farts rainbows. A senior is a person that made more mistakes than a junior and learned from them. That’s what you should be assessing. The learning. A senior won’t do the job of 2 juniors. A senior needs support too. A senior will ground a team when needed and propel them when the opportunity arises. Set your expectations right, support them and your team should get the benefit.