Welcome to Bytes In Balance, the podcast where we navigate the wild world of software engineering together. I'm Dan and this is Demian. We have been juggling code, themes and sanity for over 35 years combined. From junior depths to principal engineers, we have worn every hat in the industry. In this podcast we're sharing our journey, lessons learned and mentoring tricks to help you find your own balance.
It's not just about the tech, we dive into people, psychology, communication and all the messy bits in between. Think of it as group therapy for the digital age. We bent, swap word stories and share what we think is solid advice. Sometimes we've been bringing guests to shake things up. This podcast is our way of tackling the stress, burnout and growth pains that come with the job. It's as much a balancing act for us as it is for you. Grab a seat and let's navigate this madness together.
You'll find some interesting links in the episode description if you want to learn more about us or the topics we discuss. Alright, let's get started. I've really enjoyed the last few conversations we've had. It's been really cool diving into different aspects of software development and careers and things like that. One of the things that I was really interested to talk to you about is mentoring.
Both of us used to be at Amazon together, quit, maybe we were a little burned out looking for something different and both of us kind of fell into this mentorship coaching kind of side gigs. I thought it would be fun to do a whole episode. Let's dive into both how we got into this, what we get out of it and how we enjoy it and how we think about it. I'd also love to compare notes with you and see how you approach certain situations and topics within your coaching practice.
What do you think about that? I love it. I agree it has been great to have those conversations about software engineering, about growing, etc. I think this is a great topic. We have entered into the mentorship world. To some extent I suspect we have also been mentors for a long time in our own jobs and etc. I think it's a great topic. Where do we start?
Why don't each of us tell a little bit about our story, maybe, how we got into this and then I'm interested in how your first few mentoring clients went. I guess a little bit about me finished the latest part of my career as a principal SDE at Amazon. We were together in a division of AWS. I enjoyed the mentoring aspect of my job a lot.
I had fun memories of coaching people both in their own careers but also to solve really hard problems and just get people excited about certain things and really what I enjoyed. My favorite teams were always the smaller ones where I could get to know people really well and really take a long-term view of my own career and everyone else around me.
When I quit I was definitely burned out on supporting the product team that I was working with and mentoring didn't jump out at me as a possible career path right away. I did think about interview coaching just because I had a specific niche within that. I was a bar-raiser at Amazon. I had done tons of interviews and I felt like I could easily parlay that into a viable side gig but I never got around to figuring out all the pieces.
I was like, okay, I got to have a website, I got to figure out my policies and I got to advertise, I got to go to LinkedIn and start hustling. That was the part that always held me up. Let's see, I think what happened is you and I were meeting periodically and you referred me to Mentor Cruise. I think maybe there were a few different sites also that you were trying out. Mentor Cruise was the one that I finally put up a profile.
I just stayed up late one night and typed out a whole bio and stuff and put it up, not really expecting much to happen. Within a few weeks I think I had one or two people reaching out and it took maybe a few more inquiries and working with people and stuff but finally I got a client that had just gotten laid off, was looking to get another job and I felt like, okay, cool, I can help this person. That's how I got into it and I didn't expect it to be a full-time thing.
It's not a full-time thing for me right now but I am doing it a lot more than I thought I would. I thought it would just be this little side thing that I would do here and there and I really enjoyed it more than I thought I would. I'll stop there. I'm curious about your own journey too. I'm curious for you how did you get into it and when did it switch from being like, oh, this is maybe something I'll try out to something you seriously were considering pursuing.
Mentoring has been an important part of my life in general, right? I started to companies in Venezuela. It's more companies, five people, you know, six people and you have to do everything. You have to sweep the floors, you have to do the business presentations, you have to code, you have to hire and you have to mentor and help people and so on and so forth. So then I was a university professor and I loved that job. There's a lot of mentoring in that job.
You basically have this group of 20, 25 students at a time, seven semester of engineering. They are trying to learn software engineering. That was the course that I, one of the courses that I thought. You basically are trying to help them to navigate that world. And it was interesting because I think it was young enough to be able to connect with these kids, right? And I was not too old to have a big generational gap.
And it was, it happened kind of in the perfect moment from that perspective, no. So I connected with a lot of these students and we built strong relationships and so on and so forth. And then I ended in Amazon and I always joke that when I started realizing that as a senior engineer and as a principal engineer you actually do a lot of mentorship, right? Or do you try to find these incredibly talented people, right?
That are sometimes trying to find direction and growing and you try to point them into the right direction. One that comes to my mind and SD2, incredibly talented SD2, and he was resisting to take the step to SD3, no. And ultimately, he had everything he needed. He didn't believe it. He had everything he needed to be there. He just didn't believe it. And given that push and say, hey, you can do it. You just need to speak out more, you know, and be who you are. You are an amazing engineer.
And seeing this as the transition into the role, it blows your mind. It's amazing. So I always joke in Amazon that I hiddenly kept doing some of the work that I used to do at the university. You know, this is students, but now with the engineer, that's probably one of the parts of the job that I enjoy the most. So similar to you, you know, a little bit of burnout, etc. Trying to figure out what to do.
And I stepped into these website that I mentioned and tested a couple of them, eventually settled with mentor crews and with another website that is more non-profit mentorships, which I like and I have enjoyed, but I also have a hard time conciliating with them for profit mentorships. It's an interesting situation there. And same as you. One day, at night, they said, okay, I'm going to write a profile. And being a perfectionist, they say, I was like, okay, it's good enough.
It's two a.m. in the morning and tired. I'm just going to click, but submit. And there was the profile and I don't know, like four or five weeks later, I ended having two mentees and we established a relationship like four months, five months, something like that. And even after the recurrent monthly mentoring stopped and they didn't need it anymore. They have scaled one off, meetings and stuff like that to deal with some specific aspects. And I enjoyed it a lot.
Same as you, trying to figure it out policies, not doing much marketing. It's definitely not my thing, something I need to learn. That was where I was still working at Amazon, so that was a site, experiment or job. Eventually, similar to you, I quit and I decided, okay, what do I do? We can maybe scale this a little bit more. And I have enjoyed it. I enjoy it a lot. In some cases, it's challenging. In some cases, it's fun.
Do you develop good relationship with new people with mentees, which is also a very fulfilling? It is far from being a full-time gig. Yeah, it would be difficult to make it a full-time job. Yeah, but because we're very fulfilling in that sense. Yeah, I went through a couple of phases of looking at it because I guess I didn't realize you were still working full-time. Would you first started it? So for me, it was a little different. I had quit and I was trying to become a freelancer.
And I had, I think at that point, I had a freelance gig that I was working maybe like 20 hours a week on. I looked at this coaching thing, like another little thing to squeeze in here and there, but I would keep it, you know, five hours a week. I was trying only a handful of clients. I think I only had one or two, maybe three at a time. And it was fine. And then two things happened, like maybe six months later.
My contract gig kind of dried up and I didn't have anything else lined up and I wasn't doing a whole lot of effort to go out and hustle for another one. And then I don't know if there was another wave of layoffs or whatever in the general industry, but suddenly there was, you know, I got a lot more inquiries and I basically made this decision to try a lot more clients at a time, more than like the two or three that I was doing. And let me actually work and see, can I actually scale this?
Because the effort that I was putting at that point wouldn't have really scaled if I had
10 clients at a time or whatever. I had to get a lot better at taking notes and deciding after I meet with someone, okay, one of the next steps, sending out a follow up, things like that, but doing it in such a way that didn't take me an hour for each client or something, which when I first started, I was definitely spending a lot of time planning out what we would do in each session, taking notes, figuring out what the next steps were later.
I still do all those things, but I've managed to condense them all or figure out how to do them all efficiently. Yeah, I agree with you is definitely a learning curve like everything. I do defining all those things and getting better organized at the following up, keeping track and things like that is definitely a skill. I've been going through the same process. What do you think about diving a little deeper into some areas of our coaching practices?
I can think of it one area I'm curious to ask you. I hope this isn't putting you too much on the spot, but since you were a university professor, some of my clients have computer science degrees and have a good solid computer science fundamentals and we're maybe working on other things.
I have other clients who may be solid programmers, maybe they already work as software engineers or maybe they're trying to break into the field, but for whatever reason, they don't have the computer science background. We're working on practicing for interviews, practicing coding problems. Sometimes I'm struggling to figure out what is the best way to teach someone these algorithmic concepts, data structures, things like that.
Specifically, we were talking about graphs and topological sort, reachability analysis, things like that. I'm throwing out all these words like topological sort and reachability analysis that don't make any sense until we dive really deep on them and explain them. I always struggle with teaching these bare bones concepts without walking them through all of computer science 101, which takes a long time. You know what I mean?
How do you approach these kinds of clients who need computer science help, but obviously in an abbreviated concise way, an mentoring format? All the mentees that I have had until now had some type of background in computer science or software engineer and so on and so forth. But I think the question applies in general, because you will find that a lot of people that, despite of having a background in computer science and these things, they still have gaps. Right?
In some of these things, you have seen in college 20 plus something years ago. It's easy, it's relatively easy for us. We've been in the industry for long and care about it and we just grab a book if there is some gap and we can quickly address it. But some people have been building UX for the last eight years or so and they don't remember where a graph exactly is and how exactly it works.
And if you add the factor that people tends to think on this stuff as academic things that are never really going to be useful, right? And they just get out of college and forget a lot of that and just start working and coding and writing JavaScript code or whatever. It's easy to forget those things. My strategy is of teaching these things. It's explained this concept as simple as possible.
I just use walked people through examples like you have a house and imagine that you want to navigate from the office to the kitchen. And then, how do you do that? What if you put a note on each of the rooms of the house? Write and what if each door that you have in the house actually it's an edge, right?
So you have vertex, you have edges that are the doors and then you have the floor plant of a house and then you have notes on each room, you have edges and you can see actually the map and you can see the graph on top of that map and then you can use that graph to actually navigate. And I have a YouTube video by the way in Spanish where I use this example exactly to teach the graph, most people have played fish, present shooters or some type of video game, right? And guess what?
This is how some video games actually use to navigate characters on both the maps, but finding and stuff like that. So I try to use very well grounded, realistic, real life, let's say examples that I can even walk people through instead of just a very theoretical abstract approach to each, which is what a lot of college actually tends to do. Yeah, definitely. And there aren't a lot of good online resources about that.
My first strategy was, here's some coding problems that are around this area and go search up these concepts. And I'd give them some topics. And what I'd find is when you Google that, all the pages are very academic, very dry. They maybe have diagrams, but they're very disconnected from like real code or real examples. They're honestly just bad. And the problem is it would take me a lot of effort and work to create something better.
I don't mean to disall these things that people have put time into, but it hasn't worked. Well, as you know, I'm working on a YouTube channel precisely to explain some of these things in Spanish, right? It's still not in English, but it's in Spanish. And I find the same problem. Okay, I want to talk about, I don't know, density graph or some other specific concept, right? And then you Google the concept and most often than not, you're going to end in Wikipedia, for example.
And it's very valuable material. It's exhausting though. It's very extremely exhausting. And I can't use that to explain somebody that is facing that concept for the first time. Yes, yes. I need something intuitive, simple to actually explain that. And that has been a challenge with a YouTube videos in that sense, because I'm trying to craft that. I'm trying to explain those concepts very well-grounded, very simple.
And then once the concept is intuitive and they get it, you can dive deep into all the details and mathematical details if required, right? In some cases it's not required. Yeah, I find specifically around graphs, I don't want to dive too deep on this, but like, I find that a lot of the material like on Wikipedia, for instance, is very mathematical.
And you know, you're looking at the runtime or memory complexity of something and it depends on V and E and I have a lot of candidates thinking they need to do that kind of stuff in an interview and then their real world programming. And like real world graphs, they aren't like the graphs they show in Wikipedia examples. Real world graphs are like networks of friends or files on a file system or things like that. I resonate really highly with what you said about giving specific examples.
I love graph problems that are visual. I always used to love the paint bucket tool, what is it called? The flood video question, but it's like the paint bucket tool and MS paint. You click on a pixel and then it fills with color, outwards. And it's very visual. You can see exactly which pixels are getting filled in. You can iteratively explore it. You can show the difference between BFS and DFS. You need to explain things so they may sense to people. They mean something to people.
So if you're trying to explain graph to me and whatever you're trying, the example you're using, it just doesn't mean anything to me. I will not relate with it. It's very hard to relate with it. But if you do something like, hey, the paint bucket fill algorithm or something like that or the mind sweeper, even just say you're writing a video game and you have a mail. And you have to find your path through the maze. That means something to people.
And I spend a lot of time as a professor building some of these examples. And I do have examples of graph where I have a sprite of a dinosaur that it's actually walking and you can click in different places of a map. And the dinosaur will actually walk and we walk over the nodes. You can have a bit map and you can change the bit map and those were the walls. So these things build the graph, etc. But the point is that, hey, it's a game, it can click and it's calculating a pattern.
And I have this dinosaur that it's actually walking and people just connect with that. And once they connect with that, they feel way more motivated to keep research and keep learning, keep finding and so on and so forth. So I think that's important. Yeah, it's really great when you can figure out with one of your clients what works for them because different strategies work for different people. And I've tried a lot of things that have fallen very flat with certain clients.
But once you find something that clicks, it's really rewarding. One of the most rewarding things about being a university professor was these being in classroom, except that I'm working with the students and seeing that aha moment on the students. No, it's like that was worth it. No, definitely. Yeah. I remember my own aha moment where I was finally understood how computers thought. You know what I mean?
Like it was some hardware class and we're learning about flip flops and my professor sketches out essentially what is a very basic CPU architecture. And I feel like that film moment where the perspective changes and I just like holy shit, you know, yeah, totally. And it's also very full-filling for you as a mentor in my opinion.
I had a university professor who was my peer and became my mentor to some extent, not formally, but and he would say the person that learns the more in a classroom is the one that is holding the the marker or the chalk, you know what I mean, right? So basically the person that is explaining and that is teaching something is normally the one that learns the most. Yeah, but you don't learn right there in the classroom.
What you do is you learn at 2 a.m. the night before while you're up pouring over the lesson and figuring out just a no, right? Because what I have found is that one thing is to know something because you read it in a book and you organize the material, right? Or maybe you went to a lesson or a classroom and you somebody tried to teach that to you.
But another is being in this classroom trying to explain this thing or talking with somebody or one-on-one mentorship relationship and trying to explain this. And then realizing that the way you're explaining it, it's just not working. Yes. You need to figure it out another way to explain it. And then you start scrambling concepts in your head. And then you have this aha moment.
No. But you have to remember, I had the luxury when I started teaching to have been in the industry for like eight years at that point. And I remember getting there and teaching software engineering. Like I had already done these things in real life, no? But when you start teaching them and then you start thinking about what you did four years ago, what you did two years ago in the industry.
You have this aha moment and we just started understanding much better why you did things this way or why did this did not work, right? Hey, I was not doing things right here. And it should have done things this other way. Yeah, yeah, yeah. So there is also the aspect of teaching that is not only about preparing the class or whatever but it's like scrambling concepts to explain them in a different way. Produces also those aha moments in yourself.
Yeah. I wanted to ask you something different too. I think some of the stuff we've been talking about works really well for a client that you've been working with for a long time. And you get to work with them for a long period of time, get to learn how they learn and how to motivate them. But sometimes we have clients that we only work with for a really short amount of time, maybe only a single session. I'm curious, how do you think about that?
How do you try to deliver some value to them, give them something useful in like a short period of time? I actually had one of those this week. The first thing is that make sure they have well organized what they, what are their goals, what they want to learn or what they want to talk about. And a good idea for that and to not waste time is to make sure that they prepare before the meeting. Yeah, I always message with people beforehand. I'm sure the same thing for you.
Yes. What I do is that I do ask people to put together a write up. Some people do sit on their own when they create a calendar invite. They just post some message sometimes is long, sometimes is medium length. Basically telling me, hey, this is a situation facing. And these are the questions that I have or these are the things I don't know. So that gives me an initial edge into what they need. And normally this happens a couple of days before the meeting, right?
So that allows me to think about this for a couple of days in background. It's not I do an active research or whatever, just I think about that. And on the other hand, when they actually have to write these things, when you write things, you think through them and you organize your thoughts better. So I know that they are organized. And when the meeting comes, to me is basically listening.
It's like I do a lot of effort listening their story and what's the story and asking probably questions like what happened here or in some cases, hey, what is the organization structure of your company or your team? And what I'm trying to do normally the first half an hour, if this is a one hour meeting, for example, is get to know their problem, get to know them, build in my head a map or a context of what's going on.
And then normally the remaining half an hour or so is I just move towards talking more and trying to help them. So sometimes they have concrete questions, so they ask these concrete questions and I try to answer my perspectives and so on and so forth. Sometimes they need advice of how to behave or how to act in a specific scenario or context. So I tell them like, okay, I think about this and about that other aspect and try to give them some ideas.
You could try to do this or you could try to do this or a thing or you could try to do this or these two work together well or these two don't work well together. They ultimately need to figure it out what it's the best course of action, right? I can't tell them like this is what you should be doing or anything like that, but I can keep them a bunch of possibilities and help them narrow it down.
So sometimes I just keep them perspective from the other side, people that it's having trouble with their managers, for example, what people that's having problems with their senior engineers or technical leads and what I can do is tell them, okay, what you need to see is that this is how your technical leaders, senior engineer or managers probably thinking and these are the problems they're reality, what they are facing. And this is why probably they are behaving or acting this way.
And that sometimes helps a lot because people don't necessarily understand the motivations or the incentives of the other side and when they do, they can empathize and they can align much better and solve the problem sometimes. So it's mostly listening, trying to build myself solid context of what's going on and then providing advice in that format that I told you. Yeah, you mentioned a couple things that I do as well and that work really well.
When you're talking about listening well, but also asking these questions and specifically you mentioned asking about their organizational structure. And I thought that was really interesting because that's something that I found to be super useful. It's one of the first things I ask, I tell me about your team, who do you report to, who do you work with on a day-to-day basis and how does your team make decisions, how you plan software work.
And just talking through though, that might take 15 minutes to walk through, you know, how that works. But one of the things that I found is that that immediately helps me see how they operate. We can talk about any like big flaws or anti-patterns that I notice. But sometimes it's not that obvious, it's helpful just for them to hear me give some perspective on what they're doing because I've obviously seen lots of different types of software teams and how they operate and stuff.
And I'll be like, yeah, most of that sounds pretty normal. But here, this part where your entire team has to gather around an emergency release every night at 7pm, that part sounds weird. Let's talk about that. And there are so many different teams out there that have no idea, well, all of us are winging it in reality. But lots of teams really are following practices that don't work well.
And lots of people don't have the experience or the knowledge you have seen that or to know if that works well or not. And if I'm thinking about what is the most useful thing that I can do in a short amount of time to help someone out, it's diving into how their team works, how they work on their team and helping them compare that to other approaches in the industry. The other thing that you mentioned, helping them to understand the motivations of others, super powerful.
I mean, honestly, I was just talking about that recently with a few clients because we are practicing behavioral interviewing and we're practicing talking about examples where you had a disagreement with someone else, right? And those are super tricky to navigate. Obviously, the real situation that you had in real life was tricky, but talking about that in an interview is also super tricky.
And one of the red flags that I as an interviewer remember, when I'm interviewing people and I tell, say, hey, tell me about a time you disagreed with your manager or tell me about a time you disagreed with one of your other peers. If you tell a story where everyone around me was an idiot and I swooped in and saved the day, it's like, no, I don't believe you for a second. And when I tell my clients what you really need to do is make sure you show that you understood the motivations of others.
Yeah, maybe you still fundamentally disagreed with your manager, but you have to give the most charitable interpretation of what their view was. You know, it can't just be that everyone else around you was stupid and you were right. You know, it has to be a lot more complex than that. And you have to really dive in even if you'd still disagreed, even if you still didn't like the person fundamentally, you have to be able to explain why they thought, you know, what they thought.
And you have to show that you still cared about the same overall business goals. You were still on board, you weren't just being stubborn for the sake of it, right? No, and even suppose that you could argue that people in that team was not doing things at their best. Yeah, or was not approaching the solutions the right way and you know for a fact that there is a better one and you jump in there and you did save the day, right? Like, I'm, you know, getting into that possibility.
Yeah, that happens. Still treating your team as a stupid, it's a professional. Right? Because people is doing their best and sometimes people is winging it. We all, as you say, are winging it, right? It's like influencing people the proper way, right? And to do that, you need to approach, with respect to the situation. And even then, I'm pretty sure that team was doing things well that you need to acknowledge. That maybe they were different to what you were thinking, but you need to acknowledge.
And even then, you probably learned something from this whole thing, right? So it's not that everything was, you were perfect when you jump into that. You have to learn something. It's unlikely that you did not. Showing some humility goes a long way. Yes. You know what I'm thinking right now of is one of the most useful books I ever read, which was written in like the 1920s. You know, how to make friends and influence people or how to win friends and influence people, Dale Carnegie.
I don't know if I'm getting the exact title right, but it's so funny. You read it and it's mostly written in this kind of old, tiny, depressiony language. Essentially, the whole premise is just like, be nice to people and be charitable and, you know, exactly what you're saying. Look for some amount of humility and all this kind of stuff. Very basic stuff, but it goes a long way. I think in time, and I don't know if this happens to you, right?
I remember reading something 15 years ago or something like that, that it's very impactful. It was so impactful that I put it in my slides on my software engineering course. Right? And it was something like to be a software engineer, to be a good software engineer, you have to hate software. Right? And it was very interesting because basically, it was like, you need to know how hard is to get this thing right. And you have to know how big of a liability, every line of code you write else.
Yeah. And I have to think of being in this industry long enough and not earning one way or another of this humility, right? Because it's going to hit your head really hard software. It's going to bite back over and over and over and over. And there will be this moment in which I don't say ever, never. And I'm not a superstition person, but I don't say, oh, this is easy. Right? It's like ostrich. I still find myself saying it. And yeah, hitting yourself over.
Yeah. But ultimately, I think, big egocard or red flags in this industry, right? Because whoever has been here long enough knows that this is going to bite back one way or another. No matter how good you are, you're going to have to iterate and it's going to bite you back. We have been talking a lot about our roles as mentors. What do you think about our roles as mentees? So what have been your experiences as a mentee? Either explicit or implicitly.
And what mentors have you have that have been, you know, very important in your life and in your career? Yeah, that's a good question. Honestly, I will say I've probably been a very bad mentee. I mean, I've very rarely had an official mentor. Someone I was reached out explicitly for the purpose of mentoring. That's definitely a hurdle that I can understand people having trouble getting over. Like, just putting into words, even only to yourself, what do I need? What am I trying to get out of it?
I have a lot of sympathy because I myself have struggled with that there. But I can think of a lot of people over the years who I've looked up to. And I think the thing that they have in common is they really, they got me excited and passionate about something. They made me connect these abstract concepts. Like we were talking just a bit ago about how do you connect these abstract computer science concepts to something real and reality?
And the people that I think of as mentors were the people who were able to do this. I had a professor in college who was known as a very hard-ass, seaplus-plus professor. And you took his class and you either got an A or you got an F. And only like 20% of the class passed. And there's now a LinkedIn group. I don't want to give his name, but it's his name, survivors. Sounds like an amazing professor. I'm thinking it's sound terrible. He was a very nice guy, very supportive.
But just really instilled in you a little bit of fear, but awe in the power of raw memory management and stuff like that. Got you excited about building complex things. I looked back on that. He got me into my professional career. But I looked back on that and the way he ran his classes was very similar to the way he ran his startup, his software shop that he ultimately hired me into.
His whole company had a culture around coding things the right way and thinking about the design up front and writing. I think he had a degree in like creative writing or something. And when he taught us about Indianness, for instance, he of course taught us the whole backstory about Gulliver's Travels and the big Indian, the little Indians. And so he had all these like literary references sprinkled throughout his lessons. That it's just this kind of thing.
He was a very interesting guy to work with. Later on at Amazon, there was another, I think he was a principal engineer when I was an SDE one, I was brand new. And it was someone who got me really excited and interested about developing distributed systems. It was the first time I was working on stuff at a slightly higher scale than university projects. And you have to go through this learning from like, oh, my application is running on this server.
And this server is a delicate thing that we need to baby and treat very nicely to, oh no, we're deploying this software on a fleet of, you know, 600 machines, 10,000 machines, whatever. And you treat them like cattle. There's that famous blog post, cattle not pets. He kind of helped coach all of us on the team into thinking of distributed systems in that way and thinking about the guarantees that your database or your synchronization primitives gave you and how to make sense of that.
Because the crazy things happen when you deploy software across a wide, you know, wide fleet of varying hardware types and quality, crazy things happen. And having these rules put in place are these ways to think about large scale systems that simplify things in your mind. Super important. And he was someone that made that extreme accessible, you know, and neither of these cases were someone who I reached out to and said, hey, would you be my mentor?
But I still look back on them and look fondly on designed sessions that I sat in on them. They really just made the room come alive and made everyone feel like, yeah, this is cool. We're building something. We're solving hard problems. And this is hard, but we can do this, you know, that kind of supportive environment. Anyway, I'm curious from your perspective, like what are some of the mentors that kind of resonate with you or stuck with you over the years?
That professor, the dimension, I have my own examples of that. I remember having this professor in a control systems course, lots of mathematics and stuff like that. It was a hard course. It was a ridiculously hard course. And this guy had a very dark sense of humor coming to the class the day before the exam when looking at the fear of the people and saying, smells like dead here. Right. Like that type of humor.
And he thought hard life lessons, you know, not only the things that actually are technical or mathematical or whatever, right? And one of the things that comes to my mind and that has been very important for me is like focus on the concepts. If you know the concepts, you can develop the rest. And that has been a leading principle for me to write. When I approach to a system or to something like that, I want to understand the concepts. What are the key concepts here?
And from there, I can start building around. And I remember two semesters after I did that course or whatever I was working in the faculty building and we randomly passed by one of his classes, right? He was trying to explain something to his students and he was like, okay, you come here. Like he brought us inside of the thing. How do you solve this thing? Like out of the blue.
And even after we approved his class or whatever, you know, sometimes people in college just be approved that class and then forget whatever. Not the thing. And he actually pushes us to start from the concepts, rebuilding the thing and solving the problem. And it was like, my blowing, right? It's like, oh, we do remember this. And it's actually useful. So that's an example comparable to your professor. I had a boss when I was a freelancer and he started this guy from Germany.
I have a profound respect for Germans and their work culture. You know, they sit down at 9 a.m. in the morning. They work two hours straight, like machines. They get up, have a coffee, have a conversation, you know. And then 15 minutes later, yes, 15, 20 minutes later, almost on the clock, they sit down and they just work again. And a lot of lessons and ownership from him, right? This guy cares about me, but cares about the product, right? Same in Amazon.
I think my first manager in Amazon was amazing. Amazon culture tends to be a little bit rough, particularly back then. But it's something that I appreciate. Straight forward, things that need to be said, they get saved and so on and so forth. And I remember relaying a lot on him, okay, this is the scale, this is the bar, right? And looking up to him about those things, operations and learning a lot.
I had a pee in Amazon when I was previous to my process of promotion or whatever, also connected with him. It was a formal mentor back then and trying to help me understand the world of peace and that point in how things, you know, I was thinking maybe we're wrong, but things were okay, right? And what, how should I reframe my role to some extent better to be a pee? And I remember asking this person about impostor syndrome, because impostor syndrome is something that I don't know you, but I...
Every week have a lot of things to do with it. Just some extent, yes. Yeah, right? And just realizing that thing eventually, you know, but I remember asking him, and this is said, you know, 20 years at Amazon pee. So you can imagine a little bit and I asked him like, how do... I suffer a lot of impostor syndrome, I tell him like, and I don't know how to deal with it, right?
It's like, and he says like, well, I mean, if you ever figured it out how to deal with your impostor syndrome or how to go to strategy, please comment down maybe, Victor, to help with mine. It was funny. But before you said that, I was sitting there thinking like, oh, maybe he has the solution. No, no, no, but ultimately, I remember that being the aha moment in which, you know, it's like, okay, if this guy, you know, 20 years at Amazon, to see what he has done, and it's like mind-blowing.
Still deals with impostor syndrome, right? Just that little bit of validation actually is helpful. I mean, I think my clients also get some help just by me saying, yeah, everybody deals with this, I give specific examples in my own career where I dealt with it and still do. And he's like, what about your first manager at Amazon that reminds me, my first manager at Amazon, the same thing, he really stuck with me.
The thing that he taught me that I remember the most was he talks to me about Amazon, the company, the culture. This was way better. This was been like 2009, 2010. But he goes, everyone thinks Amazon is a technology company. It's really not. He goes, it's a fulfillment company. It's a logistics company. Everything else around it is just ancillary. And people will argue with me in other cases where that's not true for sure.
But I think that explains a lot of Amazon's culture and business practices. Yeah, not totally. I mean, you could think, and Amazon not as a software company. It's software pointed towards a business. I think there's two heavily-oriented to be said. Software is secondary. Yeah, for sure. Business is the primary thing. I think another way to look at Amazon is it's essentially just a big hedge fund. And the things that the hedge fund invests in are software teams.
Yeah. Yeah. It's a good way to say it. So anyhow, I think you mentioned something very important. It's people to look up to. And I think that's very important. It's like a mentor. Even if it is somebody that is not directly mentoring you or talking to you or something like that. But it's an example of, yeah, you look at how they behave in a meeting and you say, you think to yourself, wow, I wish I could do that. You look at, maybe you look at their day-to-day job, their whole day-to-day job.
Like my manager, I didn't want to be a manager. But I still looked at how he worked in meetings and I thought, wow, he really got stuff done. And we ended that meeting with clear expectations and everyone knows what to do. There's no ambiguity. He sure got that other team to give up a lot of negotiations or whatever. But same thing for other people, I'd look at them and think, that's where I want to be in five years and ten years, whatever.
And that's why role models, I think, are extremely important. I think a lot of promotions happen and we have this conversation with Mendizio, probably have no from SD2 to SD3 or SD3 to principle. Is it not that the technical aspects are not important? Right. But that's when you start realizing that, actually, not the most important. They're not enough. They're not enough. They're necessary, but they're not sufficient. Right. Exactly.
You want to have role models that the whole team looks at them and thinks like, oh, I want to be like that person. Right. And then you can think about the direct mentorship, if you think about it. But do you think about this ad hoc or indirect mentorship so that you can find in your job itself, versus mentoring that you can find externally? Yeah. That's an interesting point because obviously both of us have just seen both sides of that. We did informal mentoring or we had informal mentors.
The difference is mainly whether they're from your own company or whether you seek it out externally. Back when I was an informal mentor, I think one of the first things we talked about was, if I'm working with a new client, I immediately need to go explore their org structure and how they work and where their team sits and where their team sits organizationally. If I'm at a company and someone reaches out to me internally for mentorship, I don't have to do that.
I immediately know where their team sits and I have a huge advantage. So I guess my advice to clients is often, if you can find a mentor internally, in some ways, that will be better. They will have a lot more context on the projects you're working on. They'll have a more context on the people. They'll understand the motivations of the people and the teams and all of that. They'll do that much better than someone externally will.
One of the things that I'm able to do better now is I'm able to be more objective and honest with people. When I was mentoring people at Amazon, I would not necessarily caution them to leave the company. I definitely did tell people that at certain times. But most of the time, I was mentoring them to like, especially if they were within my own organization. I was interested in their own development, but I was also interested in maybe the development of some product, some other team.
I would say, hey, this project looks like a good fit for you and I would try to match that up, find things where there was mutual benefit. But I'm also looking out for the interests of the product, of the business, of the team, all of that. Now that I'm independent, the downside is someone else is paying me for this help, but the upside is I can be a lot more objective. The only thing I'm concerned about is the growth in the development of my client.
What they care about and their motivations, I'd say one of the biggest differences. What do you think? I totally agree with you. Being an external mentor gives you a fresh, more objective perspective. If you are already on a team and you are mentoring somebody, you are biased by the culture of the team, the culture of the company. Sometimes it's hard to see those things when you are in there. But when you are outside, you can see things that may look normal that they really shouldn't be there.
I imagine this company, this example that you say is the company that is fighting releases every day at 7 pm, they have a fire drill and something like that. But for the culture, they may think it's normal. But an external party is easy for you to look at that and say that shouldn't be there. That should not be happening. That external perspective also helps.
To some extent is what you have when you just join a team and some managers, wise managers tend to like to take advantage of those things when you just join a team. They know the first three months, you have the fresh perspective, you have not seen this before and you will be able to say a bunch of things that you will not be able to say six months later because you are already embedded into the team. And I totally agree that I mentor inside the org.
Not much better how to navigate the politics, for example, of the organization for a promotion in that case than an external party. Or not much better how to navigate the organization than you. Yeah, I help people with their promotions now. I help people write their promo docs in some cases. But when I was at Amazon, I had the document ready to go. I would just be like, hey, pull up a chair. Let's fill this out together. I can't quite be that plugged into the real process now.
Hey, so something I'm wondering about. Both of us are doing this mentoring, we are working with a variety of different types of clients. I wonder if you can just talk a little bit about the different types of activities you do with your clients because I'm sure with different goals, you spend time focusing on different things.
And I'm curious, what do you find yourself doing in the sessions like when you're meeting with people and also what kinds of sort of homework or maybe outside activities do you have your clients working on? Yeah, there are several activities and things that I am doing with mentees. Sometimes it starts one way and then ends going into another direction and comes back to the where we started. And I leave this very open to the mentees, right? It's like, okay, what do you want to do?
I think this is a blind spot that you have, but what do you want to, how do you want to grow? I like to call this therapy for engineers. It's not a therapy session, of course. But it's basically, hey, let's have a conversation about how are things going? What are you doing? How are things going in your team? Is there anything boogieing you right now?
Any interaction in your team that doesn't feel okay or that you have a question about this or how, and mentees are just like, okay, how can I do better here? How can I do a better job in retrospectives, for example? Or I want to speak out more or I want to be more visible? Or I have this architectural problem? We both have ideas we discuss about the problems, the organization, the things, give them some tips to grow, to do things different, experiments to try.
And some homework there is, for example, sometimes I find out engineers that they are not having one-on-ones with their managers. So some homework is like, hey, one-on-ones are important, so you should be trying to figure it out how to have one-on-ones and drive this and talk to your manager. That's a piece of homework there. There is a piece of advice that the mentee likes, right about how to deal with retrospectives or something like that or stand-ups.
And then they go on, they try this for a couple of weeks and then we talk again and that. Other trying to fill gaps in knowledge. Most of this is oriented towards, a lot of it, this is oriented towards interviewing. So they want to prepare for the algorithms, you know, encoding interviewer for the system, the same interview. So I have these lists where I ask, hey, from these concepts, what are you familiar with, what are you not familiar with, what you know for sure by heart.
And that's a piece of homework. And we start from there trying to see, okay, maybe we spend some time learning this. I don't teach during the mentee sessions, basically. So I try to say, you should learn a little bit about this, go figure it out and then maybe the next session, I give you a problem as a homework, you go and solve that problem and then you come back and we discuss and we talk about your solution and so on and so forth.
And this applies for systems design, coding, etc. Some people, it's focused a lot in the interviews, some people just want to grow. And it's about, I want to learn more about algorithms because I'm not interviewing right now with one day I may and I have a gap and I want to grow there or systems design, right. Sometimes I do mock interviews to help people understand where they are.
In the tutorial interview, you have this amazing document that you have shared with me that I think works really great. People help people preparing for behavioral interviews and we have those type of conversations and mock interviews.
Had an example like a week ago, I had this engineer, you know, answering his behavioral interview, I was doing a mock interview, rambling around a lot and I stopped him on the tracks, keep him like two, three minutes of feedback and say, okay, let's start off and it was amazing. What about you? Similar to you, I think about career coaching and interview coaching differently. With career coaching, it's honestly similar to what you describe as therapy for engineers.
I really like that term actually. My wife jokes that I'm a software therapist. There's a little bit of a truth to it in the sense that there's a lot of value that you can get by just talking through someone's current job. So first there's a lot of basic things that you can get out of diving into the organizational structure, the team processes, things like that, just to point out maybe inconsistencies or flaws or whatever.
But then going one level deeper into, you know, my clients' motivations and what do they think about it and how do they feel and what kinds of things do they enjoy when they had a design review, how did that go, did they feel supportive or did they feel like they were being attacked and why was that and we can dive into that. We get a lot out of that kind of stuff.
A lot of people have realizations about maybe how they need to better relate to their team or their managers or they just realize maybe they need to get a better job or something like that. But it's still it's a fruitful exercise. And then when I'm thinking about interview coaching, of course there's things like coding and system design and I do the same things. We talk about what areas a client wants to focus on. I send them some resources to study, some homework to do.
But I think also there's no substitute for doing mock interview style solving a problem in front of somebody trying to do a system design exercise in front of someone talking through it and then giving them feedback on it. I think those are super valuable. So I definitely do those with clients. I try not to overdo it. There's this meme about grinding leak code. People imagine that you have to do thousands of problems and just grind it every day. I don't find that's the case.
I think just one or two mock interviews immediately helps you understand how to do that better. Not saying more doesn't help but really only a tiny bit of mock interview practice. And I see immediate improvement. Like you mentioned I do focus a lot on behavioral interview prep. I do that for a couple of reasons. One, I was a bar user at Amazon. I think I'm good at that.
Also I think I'm good at hearing people's behavioral stories, their star anecdotes and then coaching them through how to tell it better, what to focus on, what not to focus on. And obviously that helps people with interviews, that helps people with their initial recruiter screen, which is often the first step in an interview but also helps them with later on technical rounds. And one of the things that I've noticed is that also helps give people confidence.
You understand like, oh wait, the things that I've done are actually impressive and here's why. That's obviously a huge confidence boost in interviews. Yeah, that works. It is amazing. What I try to tell people that one thing is the mock interview. One thing is the interview and there's a strategy for an interview. It's a different game. And another thing is what you want to learn of systems, the sign, what are your gaps? What do you want to learn about algorithms, what are your gaps?
I'm focused on those two things separately. Focus on learning your gaps, right? That's your... Okay, folks. So we've been talking about mentoring and this has been a really interesting conversation. I've enjoyed talking about how we got into this, how we started thinking about this from the beginning, how we committed to making this a serious side gig and some of the strategies that we've definitely gotten a lot out of this. Yeah, thank you then for the conversation. It has been amazing.
And thank you for the listeners for listening to us and it will be until the next episode. And that's it for this episode of Bites in Balance. We hope you enjoyed our deep dive into the world of software engineering. Thanks for tuning in. We would love to hear your thoughts, so don't hesitate to reach out. Connect with us and link it in to continue the conversation or simply follow our updates. You'll find the links in the episode description.
We aim to release at least one episode a month, but with our busy lives it might vary. Subscribe to stay updated and you might catch some surprise episodes when we're feeling extra chatty. If you are enjoying the show, please write, review and share it with your friends and colleagues. It really helps us reach more people in the community. To learn more about the podcast, check out our website, the link is in the episode description.
And if you're looking for more personalized guidance, we're available for mentoring through mentor crews. And there's a link for that too. That's all for now. Until next time, keep coding, stay sane and remember. Even when it feels like a total shit show, you got this. Thanks again for listening and we'll catch you on the next episode.