Sink or Swim? Team Lead and "Junior" SREs Debate... Verena T, David P, Melody E, Patrick S & Petr R

This panel discussion focuses on the experiences of junior and senior engineers during the onboarding process and how companies can better support new hires, particularly in technical roles like Site Reliability Engineering (SRE). The speakers, including a mix of juniors and seniors, share insights into the 'sink or swim' and 'trial by fire' approaches to onboarding. They discuss the importance of both technical skills and soft skills, emphasizing cultural fit and communication within teams. The panelists recount personal stories illustrating challenges faced during their early days, such as the steep learning curve associated with tools like Kubernetes and Terraform. They underscore the need for mentorship, psychological safety, and an environment conducive to learning and growth for junior engineers.

Today we have a wonderful panel discussion for you or maybe rather a debate seniors versus juniors. No, just kidding. And we want to talk a bit about sink or swim and trial by fire onboarding. I am Verena. I'm your moderator today. I'm actually an HR manager turned a lot of different things but ending up in the cloud working now mainly with Kubernetes but also a lot when

it comes to communication with clients, um collaboration within teams and client teams. Um and I will guide you through this today's session. And I brought as you can see surprise some guests. We have actually a set of two different let's say panel pairs like each time a senior and a junior or former junior. So let's start maybe meeting and introducing panel team one. So hello. My name

is David and I am the senior on this part. You know, we got an idea to discuss how do we like act towards the junior members in our company when I got a question from Melody like how what is your like policy around juniors in your company and I said, "Yeah, it's quite easy. We don't hire them." So to kick off maybe with some like hot take

on this. This was how it all started and when we got into like further conversation we quite understood that we basically have a several problems that we maybe experience in a very similar fashion in a similar manner over the years over like multiple employers no matter if this was in the Czech Republic or in Germany or maybe some other places and that's how we got here. So

we would like to basically share what we have learned. Now I have my ex-junior I would say here over here. Hello. My name is Peter Rice. I'm the ex-junior. And uh I work in Sluno uh in a small robotic robotics team. And my job there is probably everything, but also DevOps, backend development, and QA testing. Thank you so much. It's not your slide yet, but it's coming

now because we have a second um set of um panelists. So, here we go. Now it's your turn. Hello, I'm Patrick and I'm a former aerospace engineer and at day I'm working as a team lead at Cloudflight here and at night I'm co-founder of Adaptik. And when I'm hiring, I'm actually really looking for a high culture fit and also high talent. And Melody was actually the first

junior we have hired in our team and today we are going to share the experiences we made over the last 2 and we will have a lot of interesting stories regarding this. Yeah, um I'm Melody and I am a the junior SRE and I still am. Um but I am also the community lead of um where I'm not a junior anymore, I would say. Um and I

did my apprenticeship 2 years ago, so I finished 2 years ago at SAP. And um I also co-founded an internet exchange. I'm not sure if anyone here knows, it's a different community, but um internet exchange when I was around 20 years old, I'm 24 now. And yeah, I'm really happy to be here today. I hope we can share some insights that you haven't heard of before and

yes, let's start. Wonderful, thank you so much. So, we have two introductions. Um so, that's set, uh but before really, really starting, uh there's maybe one last thing. You you heard um two two, let's say, different phrases uh on our first slide, sink or swim and trial by fire. And I think these can mean a lot of different things to different people. So, maybe let's just have

a quick summary. I'm the one giving it for now to have a common understanding of what we as a group mean here. So, sink or swim would basically be let's say I would guess the typical situation in a company. So, you have a junior coming in and you give some tasks and the person is just trying to work on them but like trial and error but it's

let's say a safe space. It's a dev environment. It's an own project. It's a pet project whatsoever. But you have something where the person can just try and then ideally not sink, right? But it has does not have so much impact. Trial by fire, let's call it the extreme way of sink or swim, right? So, we're not talking about a very nice and shiny and easy a

secured safe space environment but like the real talk, okay? So, that's basically maybe just as a common ground for all of us, right? And I think especially today we talk a lot about the trial by fire like the the real one but not only. Let's see. And now we can start. And I think first things first, we thought we just give you some quick glimpse or let's

discuss a little bit about like okay, what are actually requirements one would have in an SRE. As always in the world, there is a lot of dimensions to it. As with many topics, even kind of an iceberg. So, maybe giving the word now Melody. Melody, what are your thoughts on that? Okay. So, this slide was one that I created because it was really important to me. And

I was in the lucky situation back then when I was looking for a job after my apprenticeship that I knew someone and this person knew someone and then they recommended Cloudreach as a company to me. So, it wasn't like actually applying for one position. I was just invited to an interview. I sent it off my CV and then I had the chance to get to know a

lot of team leads from different teams. And why I'm telling you that is I would have never in my life applied for an offering or like for a job where I would have seen the hard skills of an SRE. So, I would have never thought that I would be fit for this position. And I think this is an important thing. I think a lot of you know

what I'm talking about. If you don't know what I'm talking about and really good for you because it is really, really hard to look for a position after you graduate and then think, "Oh my god, there are so many hard skills. I don't know half of the tools that they're talking about and I haven't used the other half yet. I don't even know how to try them."

And despite your thought, you still got hired actually by Patrick. So, Patrick, Yeah, it's it's really, really interesting because um when we talk about the SRE role, uh from my point of view, the magic happens below the surface. Because tip of the iceberg, shiny CNCF landscape, that is something every everyone can wrap their head around and it's really easy to discuss all those tools, those technologies, but

for the SREs, it's it's a lot of important culture topics and also um soft skills that are required to become a really, really important foundation for each organization. And as I said earlier, I'm always looking for a good culture fit and also for just people who are more in the um under the surface in this case. So, and that's where where we came together. Great. Thank you

so much. David, what are you What are your thoughts on Okay, what would be requirements in your eyes? Uh well, technically what when I was looking recently for a job, uh it looked like that companies are dumping basically their tech stack, you know, to the road and saying, "Hey, you need to work in these three major cloud providers and of course, if you have some certification as

an extra, it would be nice. And of course, you need to maybe up to some point understand the Java code because we use not Java, but Scala, you know." And I really like was stumbling upon these offers. So, when I even have the experience from all of the above, unfortunately, I still like cannot wonder like how does it look for a junior to apply because still they

say maybe okay, they differentiate, there is some preference or you can have this as a strong side, something like this, but I guess that this never happens. And especially maybe without previous like positions, it looked like that typically they hired it like the definition of the job is something completely else that you will get like once you are in because the current project may require something else,

right? Yeah. I can agree with agree with it with that as you will will hear later, I have story for you how hiring to a greenfield project turned into one-man one-man operation. And so a about this topic a I want to say that the requirement for for this position is to is to be brave because a Okay, we have to have to agree with that a little

bit. Sorry, I will help up a bit. So, if you imagine that you will be thrown into a project that is kind of a new because we would like to innovate, right? We sold the idea that we will, for example, use Kubernetes in the projects and let's imagine that we will take a step back in the past 3-4 years ago. At least in the Czech Republic, it

was not, you know, an obvious choice that you would do. So, you are hired as a back-end developer, but now, maybe the tech stack has changed from the regular Tomcat servers or what you used previously, right? So, what was it? Right. I was hired as a as a programmer we developed an application. And after that, in one point, we want to present the the solution to to

our customers. So, me and my boss presented My boss said, "Okay, let's let's present. The customer will arrive. Let's let's do the presentation." So, not after the hard skills, like the programming is required, but also the soft skills as a communication and preparation for the presentation is required as well. Did you want to add something? >> One little thing. Okay. Um something that I remember from the

hiring like when Patrick hired me that really like reminded me what you just said is hard skills can be learned. And this is really important, especially for graduates because the things that CNCF landscapes, the tooling, and everything, you don't learn this in university typically or you don't learn this in an apprenticeship, no matter what. Every one of us had to learn it by themselves doing the things,

learning things that the clear way. Thank you so much. That was actually a very good sum up of okay, it's not so much only about the the hard skills, let's say, but actually well, it's a lot below the service, which is surface, which is relevant. And I think that matches actually also our panel here because I don't know if you you kind of realize, but only two

out of five here actually have a background in IT, but we all work in infrastructure and in IT nowadays, right? Uh so that brings me to the next question question, which would basically be, okay, what would be then the minimum requirements? And given Patrick, you said before that okay, culture fit is uh very important. What is your thought on Yeah, in this case, the Tetris game is

a very good example of how approach this hiring um Our team back then consisted of I don't know, I think eight seniors and technically we were quite strong. Culture was good, but I felt that a team lead that there was something missing. as we are SREs, we provide technologies yeah, especially other users like developers or service managers in our And there was always a problem on the

user side, so thought we. But I I was really looking for someone who um who can actually bring a skill to our chapter, to our team that unlocks this hidden potential that we have already in our technology, but was somehow hidden because we really didn't have the strong communication skills, but also empathy for the user. So um and that's something where Melody did a lot of good

work and she can definitely share some stories Thank you so much. So it took ages for me to realize that when like I arrived that I don't have to write like a whole module on the first day, and I don't have to I don't know, write a whole helm chart on the first day. And um until I realized that, I felt really bad in the team because

I thought I'm not adding like any value to the team. But um then they started using me for quality assurance, which was a great first step for me. So we tested all the super old documentation to set up our observability stacks, to set up our land like landing zone with our terraform modules and everything and it was really beneficial to hear my feedback. That's what the other

people say. Just Just trust me on that. Um so, yes, and what also really helped me to grasp the role, to be honest, I never even knew what a site reliability engineer was before I started. It was really like hard to understand and this book, I hope Who of you knows this book? Like the site reliability engineering book by Google. Really good. >> Some. For everyone else

who doesn't know it and is interested, it's really really good. I can totally recommend. Um that was part of my journey for the first 6 months and it helped me immensely to understand what my role is and a lot of it is communication with other teams and even if they sometimes are hard to handle, they aren't as stupid and if they don't understand, it is mostly the

fault of the platform engineering teams or of the SRE teams. I'm sorry, that's a hard take, but it is the way it is. Thank you, Melody. David Peters, your take on that. Well, for us, if you would like to click that bricks into the Tetris and we would like to score more typically for us, it's very hard to think of the environment that will like gradually progress

because at least from my experience, by the way, I have heard a perfect story about like getting the ticket from customer on the first day and trying to solve it. colleague currently who is like 11 years in the company said something like, "Hey, you know, we are having some QA duties to help the developers." and I believe that like everyone should have the QA duty on day

one. You know, I can tell that even in this company, I was not able to get the credentials probably on day one even I tried. So, the people who are there for longer, they have a lot of bias already because they know how things work, how what's happening there, but if you are from especially on the new projects and there is some push from the management, "Hey,

we need to innovate. But at the same time, they will not provide you with the resources, with the stronger team behind you, but they will say, "Hey, you as a junior will bring the innovation." How do you think that it might end? Okay. Uh if I should bring uh the innovations, uh I need uh reliable people around me because uh and especially the the mentor which is

uh communicative and uh gives a good feedback. Uh I was happy that I was uh had a good in in my company because I don't know everything. uh they they always uh support me because they learn learn uh in parallel with me uh about the new things. So, if I if I uh also it is about being being friendly and not uh just working on my stuff

and lock myself in home or in a separate uh room and not uh to talk about the the projects we are work working on. So, yeah. That's that's and yeah, that's that's it. Great, thank you. Actually, we dived a bit already into Okay, what are typical things happening? Uh what was the environment I was starting? So, that's actually a good point for the next slide. Surprise. Uh

where we have a little bit like Okay, what is actually an environment making everything possible? So, Patrick, I know you like this slide a lot. Uh so, maybe you will Yeah, sure. So, the environment really needs to be engineered for success. And with the environment, I don't mean a technical environment like in the best show. Uh I mean really the environment a junior or honestly everyone who

starts newly um just yeah, is around. what you see here is the pyre pyramid of needs adapted to yeah, like an onboarding process of a And honestly, we didn't get this one right from day one, especially myself because I have assumed like the baseline is just there and we took a lot of talks, meetings, blood, sweat, tears, everything to really get this done. for my I think

my biggest mistake here have started with the recognition and trust from day one because I knew that from our seniors, if I have like the single single most important recommendation build on psychological safety first. And that is unique to everyone. And Melo, felt for you when it changed? There was a turning point or something? Yeah, for maybe at first it was really hard. I was crying I

think at least once a week. I was immediately going to sleep because I was so exhausted and I promised myself to be honest on stage because I know there will be people in the crowd who kind of relate, maybe not crying. I am a crybaby sometimes, but you you will you will know what I'm talking about. And in this case, there was a turning point. I had

several different seniors working with me, but I found one who's actually here today in the second row, Joe. And he supported me a lot. We did a lot of pair programming and he was honest to me. He didn't know everything himself. So, we had sessions where we had to figure out stuff together. And it also helped me a lot to see the value I was contributing when

I was working on good first issue tickets. Sometimes I found bugs that even the seniors couldn't find. And it took a while, but I I was building a little bit of trust and I got good feedback and also good recommendations how to get better, how to yeah, just continue to grow. And no one was mean to me, which I didn't knew before. My older companies were not

so nice to me. That's why I had like a lot of baggage from the past, which Patrick handled amazingly. Every time I felt bad, he took the time to talk to me, which not everyone can do, to be honest, and it's really like a nice thing to have. And now we are like on a really good basis, I think, for for my psychological safety in the team.

I feel really good there. Thank you. Uh for the pyramid, I would definitely like to highlight that they're like technologies and all the exercises since the basement there, right? So, this is definitely that you can learn, improve, have a manual for with multiple steps. This is the easy part. We were touching on the psychological safety. So, uh how long would you feel that it takes for a

junior to gain the trust for from the mentor perspective or like for the company perspective. So, I am really trying, for example, to install new server, something in the network might break because I may mess it up, right? Uh like does it take a week or maybe a month in some company before I get some feedback? Also, what is our experience uh with better uh the home

officing, especially during the COVID era, didn't help much for like to push this trust forward in multiple directions, I would say. So, if you are maybe a bit shy, if you would like maybe to prefer to work on your own and not ask your mentor, like four questions uh every hour, some people are a bit stranded then and they struggle, right? Yeah, right. But uh it's it

comes with the with the attitude of the answering, I would say. Because uh in in my case with David I ask him or just saying him something that I want to work 50 or 50% of all of all of the things that I will tell him or ask him are nonsense from from my point of view. And he always is calling and he says, "Okay, let's back

to the to the start. Let's start thinking about it from different way. And what you said is not totally but we could adjust it to to work to make it work. So, the communication with with the mentor in a good attitude important, also. Thank you so much. So, we heard a little crying {slash} being frustrated and so on and so on. And so far you didn't hear

so much about trial by fire like in real life, right? And that's exactly what we want to do now. We have some fun not so fun. No, let's see. We have some stories. Peter, maybe do you want start? >> Um Okay, so uh my background a little bit. I am a studied robotics engineer. I studied mechanical engineering. And I was hired to a company that implements the

robots. after find a few few months, I I found out that I have to learn how to program not the robots, but also the the control system. So uh okay, I said, "Okay, let's let's try programming." So, I programmed and developed the software. And after that, they said, "Okay, we have to deploy it." But, uh it was in in time that we migrated migrated to Kubernetes. So,

I have to learn what what the Dockerfile is and and what a pipeline is. And why is the pipeline failing? okay, what is the pipeline and what stages does it does it have to have? And accumulated those informations and in point of time the senior or the lead DevOps engineer left, which was David. And left uh and and some my team was left without the DevOps engineer.

So, he handed over some knowledge, but uh it was only for maintaining the uh the the application infrastructure. And uh after a year or uh half a year the customer came and uh said, "Okay, we needs to we want your application. Let's deploy it to to our to our servers." I was, "Okay, I have only this knowledge this knowledge this this knowledge." this was uh the time

that I was like on the the Docker on on the picture. So, in a quite a short of short of the time I have to learn uh a lot of things like uh the observability, logging, and uh the infrastructure itself. yeah. We have to be a bit careful because of the time >> I will >> But, your view on exactly that story, please. That would be awesome.

All right. So, I would like just to explain that even though as a mentor you're trying to shield people from getting too much like cognitive overload and you do your best. Still, unfortunately, you know, it falls down from the top. So, this is what has happened and I think that for the companies it's super easy, you know, because it's already in the ownership of your team. So,

we will just assign the CI/CD pipelines also to the developers, right? Because they can manage. The deployment, well, you are on a specific also this is yours. And no, it was really so funny to see one person like managing, carrying physical robots, working with the controllers that needed to be physically like plugged in, working on the software, and also working on the Kubernetes side. And I didn't

even mention that you also was in pre-sales, right? So, like like this. Sorry. Melody, I will keep my story short because I know what we will miss if I don't. So, that's why I one funny story. I was developing on a Terraform module. I didn't know what Terraform was. I didn't know what a module was. And I had to build We had a module for a virtual

machine with a Azure provider and I had to build a special one for an MSSQL thing that also needed a virtual machine as a baseline. And I was working on it and it was so hard and it was so really really hard for me to get into this topic because there was so much code there already and we had a really high like we have one colleague,

Roman, he's really really good in this topic. So, he has a really high standard when it comes to this kind of code. Yeah, um and I did develop it and I somehow survived the code reviews which had like over 40 comments and each round. It was like he's the best person when you want to code review really well done then you ask him. And um yeah, then

then I was not there because I was on vacation, my first vacation I think and he published it without me. Um which was a bit sad. I I know he did it because we really needed it to be published, but it was a bit sad because I really wanted to be there in the contributors. And one story at a customer was just thrown in alone. At a

new customer, brown field, really long project, really really expensive one as well. And I had to be in a workshop for 4 hours explaining our whole observability stack that I barely knew at this time, but it was really good because I was the only one who could actually understand the customer's perspective because they don't understand any of the technical things. So, I was only focusing on the

benefits. I was focusing on what the customer gains for our product. I was still able to ask like answer all the questions and I had my team like in the background who were like there for me. So, I mean in the end happy end, but there were downsides, right? Or there are downsides, right? Let's face it. So, what are your thoughts on that? Quick, Really quick. This

graphic, really look at it. If you start off not everyone knows everything, you know? And I thought that by myself, but I realized that many seniors also don't know everything and you can still support with your own strength. And that's like my takeaway. Imposter syndrome is normal in this industry. Please take care of yourself. Please take care of your teammates as well and never forget that. If

I may ask a question to the audience like who thinks that he has an imposter syndrome? Because I can definitely like raise my hand and I definitely have this one. So, if you just look around, you're definitely like not alone and definitely you sometimes, of course, very unfrequently can say I don't know. Yeah. Something to add, Patrick? Yes. So, to all the seniors out there, please push

your ego aside and just admit that you don't know stuff. And then take a junior and figure out together. This helps everyone. That's really great one. Thank you so Peter. Okay. Yeah. Yeah. Definitely agree with with Patrick. Uh hiring juniors, it will uh the the benefits will come later. make them make them brave. Uh in- involve them in the in the work and let let's let them

time to to improve them themselves. Wonderful. I mean, we we could talk ages about that. We could talk hours. We unfortunately are not allowed. Um but just before quitting the session and saying thank you, what would be last famous words, uh ideally a sentence, uh Max, uh you would put out to the audience so they can even find you somewhere around in the area, might maybe challenge

you or exchange thoughts on? We just go by the row. So, Patrick. Right. So, to all the team leads out there, please check out the pyramid of needs and nail this one on day one and then you have the environment that could be successful. Please hire junior engineers. You really AI won't really replace us totally 100%. And who thinks that, please talk to me because I will

challenge you and fight you on that. And um we will have an issue again every 5 years that we don't have enough people experience in these technologies and we have to keep them running. Okay, hire juniors because they they are the future. I would even say that if you don't hire them, like every other colleague of yours uh next year might have better the name Claude Codax

or something like this. So, just be aware. That was wonderful. Thank you so much. Also, thank you so much to all of you joining us today. Uh thank you to um the whole community, the program committee inviting and accepting our panel. I mean, thank you to the whole world. It was wonderful with all of you. Um, please feel more than free to reach out. Um, ping our

colleagues, our panelists. You have all the contact details there. Um, fun fact, you can also ping me if you want to. Um, my contact details are not there, but I'm still Verena. So, just feel free. Um, and thank you so much for this wonderful session. Thank you so much.