The Transition From Junior to Senior – Filling the Workforce Gap

*This is part of an ongoing series from Rezilion titled Enlightened Engineering: Reflections From Rezilion’s Tech Team

By: Gabriel Vexslender, DevOps Tech Lead, Rezilion

“Israel’s tech industry suffers from a chronic employee shortage” – Calcalist Tech

“Hi-tech workforce growing, but lacks skilled employees” – The Times of Israel

“Israeli hi-tech industry faces shortage of 18,500 employees – study” – The Jerusalem Post

The number of senior software engineers is insufficient to meet market needs. Many of them change their place of work every one and half years in the global market along with every three years in Israel (on average).

But wait, there are a lot of Juniors (university graduates), what can be done to turn them into Seniors?

In this post I’ll focus on answering this question from my own experience of how I became a Senior DevOps Engineer in two and a half years.

From Junior to Senior Talent: Ask The Right Questions

Be On the Same Page

No single Junior can grow and develop without difficulty. It’s impossible to understand why serverless is so awesome, without ever encountering the frustration of managing servers. It’s impossible to understand why containers are so revolutionary, without experiencing the “it worked on my machine” production situation on a Friday evening.

In our childhood, we had no fear. If we jumped off the swing and broke our leg it was painful, but we learned not to do it again. Of course there are also the things that our parents taught us, like not to put our fingers in the electrical outlets, and we didn’t need to do it to believe them – just like how we don’t need to press “delete cluster” to understand that it will cause problems in production. When a junior developer gets an answer like “we don’t use MongoDB, it’s very slow”, they won’t fully understand why.

As part of my training at Rezilion, I got a chance to work with our old environments which had the old tech stack.

I understood what the old deployment process was and how we monitored their resources. I saw the open bugs and the debugging process. These kinds of experiences are what led me to understand what we must avoid in our new stack.

I think eventually, it was “feeling the pain” that got me to where I am now. It has always led me to try to understand what the solution was to the problem, and empowered me to get through it and find a better solution myself.

Be Aware of What Lies Ahead

At the beginning of our journey we don’t know anything – after some time we think that we know it all. But as time moves on we come to find out that we know nothing! How is that possible?

That’s what I think the gap is between a Junior who thinks they know it all when they’ve finished their programming course. Then they arrive in the industry and realize that there is a lot more than knowing how to write the best sorting algorithm.

The Junior still doesn’t know what they don’t know. They can code a full website from scratch, but what about scaling? What about disaster recovery? How to secure the customer information, and so on.

During brainstorming sessions, the Junior should open up their own issues/cards and ask the Team Leader to review them, while asking questions like, “How do you handle scaling?”

Gain Knowledge

As the leader of a team or a group, you often don’t have the time to sit and teach your new employees, or you don’t have the time to prepare all the necessary learning materials. What can you do about it?

One approach is to take a real bug that you have and throw the Junior into the deep end, letting them try to solve the problem. The challenges they’ll face are that it can take a long time or the solution just isn’t good enough. But in my opinion, when the solution you provided as a Junior isn’t doesn’t solve the problem, it gives you a better understand of what you should do instead.

If you don’t have sandbox environments, I recommend you create some for your new employees to take advantage of. This allows them to understand the architecture, the resources, along with the various features and how some of them are built.

Additionally, put a bug in that environment and pretend it’s real. Then, give the Junior the opportunity to look for the bug by themself and figure out how to fix it.

Self Confidence

There are two scenarios that I most often see.

The first is when the Junior has too much confidence. The other is when they don’t have enough of it.

The risks with the first one are always believing they’re right, arguing with others, making false claims, and so on.

You may think from this that you’d prefer the Junior with no confidence at all, but then you’d go back to the “you don’t know what you don’t know” situation, and the developer will be afraid to propose new ideas. Each time they get an issue to work on, they’ll freeze because they feel like they aren’t smart enough.

I know because I’ve experienced it first hand.

The way I gained self-confidence was through group work. What I mean by this, is that I worked with senior developers from other teams (other specialties) on the same issue. I was the “senior” in my area of specialization within that group and my summary and next steps went through architecture review by the team leader or senior member of my team.

Make sure you provide group work opportunities for your Junior employees and encourage them to offer their opinion.

Encourage a Wide Perspective

From day one, I think the junior developer should passively participate in the brainstorming/grooming discussions so they’ll understand all aspects of the issue and not only the title. Aspects like scaling, security, ease of use, business requirements, etc.

In my team, the brainstorming/grooming process is to define the big issue and open up the floor to questions. Then, schedule a team meeting with all the relevant personnel from the company to discuss those questions, summarize the session, and write down the next steps.

After a few of these grooming sessions, I learned how to ask the right questions, and was able to provide answers based on what I’d learned. Eventually, I became the focal point in some areas of expertise.

Another point is that Rezilion has bi-weekly R&D meetings, during which each team talks about their features. This gives the junior a clear picture of what the company does, and how the issues they work on are related to the bigger picture.

Loyalty to the Organization

Rezilion is committed to promoting learning and development. Even this blog is a learning initiative!

When Rezilion decided to create a DevOps team, I wanted to be a part of it. So, I was “thrown in the deep end” (which is funny because I don’t know how to swim). They trusted me and believed in my success.

In addition to that, everyone at Rezilion gets 2 hours of self-learning each week. We can access online courses for free or schedule meetings with other employees to learn from one another.

I think that’s the main reason why I’m so proud to be part of Rezilion. I’m always looking forward to the next challenge within the company.

Providing such opportunities to your Junior employees will help build loyalty towards your organization. That loyalty will help retain them, even when they have acquired Senior-level knowledge and experience.

I hope I’ve been able to provide you with a few pointers on how you can grow Junior employees at your company.