CodePath EES2024 Opening Session - Leveling Up as a Software Engineer

Welcome, welcome back to day number two. And technically this is take number two. I don’t know if y’all noticed, but we did have a little bit of technical difficulties.

I wanted to give a big shout outs to all the engineers in the background taking care of this and especially the production team. We really do appreciate you. I’m going to cover a few things, but before I talk about that, I want to talk a little bit about yesterday, day number one.

If you missed day number one, first of all, where were you at? I don’t know what the excuse could be because it was totally fire and your boy had a great session. And not only my session, but all of the sessions prior have been pre-recorded and you can go watch them on this Airme platform.

So, y’all ready for day number two? Because we got a great discussion, a panel discussion actually by one of our co-founders here at CodePath. But before we get started, let me give y’all a few, you know, rules around some of the things you need to focus on during the session.

More specifically, reminders. Please utilize the chat to conversate and share your thoughts during the session. Please keep your messages and topics relevant to the session at hand.

And note that the presenters and speakers can see your chat. Our team will be on the sideline helping answer any questions live. So definitely tune back in to your questions because somebody from our team might actually respond to it.

And also following the session, we’re going to ask you to complete a brief feedback survey. Your feedback is very important. And if you didn’t know, yeah, I came back for two years in a row because the feedback was fire.

So definitely make sure you let us know what we’re doing well and what we can improve. Now, now that we’re done with the wrap-up or the reminders, I’m really excited to kick off today’s conversation and our opening session with a great panel discussion featuring CodePath’s very own CTO and co-founder Nathan Ecuinazi, who will be joined by former CodePath instructor and new and now senior software engineer Diana Hajes, as well as two CodePath alam now working in the tech industry. That’s Kabir Dylan and Jessica Lynn.

Welcome to the session. And now let’s turn it over to our guest panelists and engage in discussion on leveling up on software engineer Nathan, Diana, Kabir, and Jessica. Welcome and I hope you all enjoy.

Hey everyone, it’s great to be here with you all again for the second year of EES. Me and my co-panelists today, we’re just going to focus on what we all think of as the most important things for you to know as emerging software engineers. So I really want to focus on practical tips, skills, thoughts, experiences, you know, stories from our past and and our different journeys that we’ve been on.

And so first I wanted to start by just introducing each of us so you can get an idea of who you’ll be interacting with and and hearing from today. So first off is myself. As Bobby mentioned, I’m one of the co-founders of CodePath.

It’s amazing to be here with you. It’s been an incredible journey. I actually started CodePath way back in 2013 and then became a nonprofit in 2017.

Prior to that, my story matches a lot of other students I imagine within CodePath. I grew up in a low-inccome community. I didn’t know anyone in tech.

I actually got connected into tech by a random person I met on the internet in the early days of the internet. I started my first company kind of by luck at around 14 or 15 and I actually was able to launch box products in the early Apple stores. This completely changed my idea of who I was, my identity.

It changed the course of my life and I actually had been working in startups essentially ever since then. I was able to enter college, one of the first students in my high school to ever attend college for CS. I went to University of California Irvine.

I actually worked in startups all the way through my own college experience to pay for school. Actually worked with the one of the people who ended up becoming the co-founder of Honey if you’re familiar with that company which was acquired by PayPal. And also during that time I got really deep into open source.

I built projects installed by tens of millions of people and places and downloads and it’s been quite a wild journey for myself. All that time I was also working as a software engineer building web, mobile and cyber security applications amongst a variety of other things including even desktop software. So it’s great to be here with you.

I’m going to pass it over to my co-panelist Jessica and then you’ll hear from each of us to kick things off. Hi everyone, my name is Jessica. I’m really excited to be here today.

CodePath was a big part of my tech journey so I’m really grateful to it. A little bit about me, I’m also from an immigrant household. I was a firstgen college graduate.

I went to UCSD and majored in computer science. I found CodePath kind of randomly in college. I didn’t really know what it was, but I decided to sign up for the class and it ended up being a really big part of my college experience and my entry to tech.

And so now I’m part of the CodePath Mentor Network. A little bit about my job background. I did some internships at the UCSD basement, which is the startup incubator.

I also worked at Philips Medical Devices and I interned at Roblox. Another big part of my journey is that I was affected by the COVID internship cancellations in 2020 pretty late into the recruiting season. As most of you know, April is very late.

But I applied to like 200 jobs in the span of like a month and the CodePath mentor network was a big part of that. And that’s how I actually ended up at Roblox. After my internship at Roblox, I received an offer to come back full-time as both a software engineer and also a product manager.

And I chose engineering. Now I work as a full stack engineer at Roblox. I think I’m going to pass it over to Diana.

Yeah. Hi everyone. I’m Da.

I’ve also had a long journey with CodePath. I took my first Android course with them in 2017 and that was when CodePath basically required you to be a full-time software engineer. So you guys are really lucky as college students to get the training that I got while being a professional engineer.

After that I basically came back a few times to teach. I’m just really connected with the community and yeah I’m the first person in my family to graduate college. I come from a single mother household.

I knew nothing about computers or tech growing up. My grandpa happened to just buy me my first computer for getting all the A’s in the fifth grade. And I was hooked.

I was a neck beard basement dweller before it was cool. So after that, I went to fancy boarding school and scholarship. Got to take my first computer science class in college.

I had a roundabout journey. I went to Stanford and in my freshman year computer science classes, people were starting startups that were getting funded. So I’m like maybe I am not as good as at this stuff as I thought I was.

I graduated and then went back to school for a second bachelor’s in computer science. From then CodePath Android course I was hired out of the pool of students to to start at Netflix on Netflix’s UI team. From there I went to Instacart, spent four years there from like the pretty beginnings.

All the way through to the IPO. After that I worked at Square on Cash App and now I am back at Netflix working on live streaming and ads. And yeah, that number is outdated.

We have a billion installs. I just checked the Play Store. Yeah, so a billion people will see all my bugs.

I also run a local AI hack day in Asheville, North Carolina, which I am calling in from Tennessee right now because I was affected by the storm there that kind of destroyed our city. So I am so grateful and thankful to be here today with you all. So off to Kabir.

Hi everyone, my name is Kabir. Yeah, this session was actually one of my favorite ones at EES last year and I’m excited to be a panelist this year. A little bit about me.

I grew up in the Bay Area, also from an immigrant household. I’m also a first generation college grad from Cal State Eastbay with my bachelor’s in computer science. But ironically, I started off my bachelor’s as a computer engineering major.

Halfway through, I realized there was just going to be a lot of physics in the rest of my degree and I like my programming classes more. As for like how I got in touch with CodePath, the big question was when I switched over to CS was what do I want to do with my degree? What do I want to do after I graduate?

Luckily CodePath was offering an Android course that semester at my university and I really liked it. I actually got to be a panelist for CodePad’s national demo day back in 2021. I worked together with a couple of my peers on a fitness tracker Android application and then code paths actually the reason I got my internship to at at Medline and I continued on I wanted to try out iOS so I was a tech fellow for the iOS course the following year and then I’ve also been a tech fellow for technical interview prep.

Yeah I’ve really loved iOS and that’s how I I got exposed to it through CodePath. I’ve published an app to the app store and I’ve also worked for a few startups working in plots and then also consulting with open city. Awesome.

So yeah, I mean as you all can tell each of us have taken fairly different paths and experienced very different things. So I was really excited to be able to do this panel with you all in order to share sort of from each of our different perspectives. So what we’re going to do is for each of us we wanted to kind of just think about we thought back to ourselves what would be some of the most practical useful things to share with you all and of course please do post in the chat questions thoughts comments your own insights as well I love hearing from from everyone else’s experiences but what we want to do is just kind of go through we’re going to round robin and start out before questions by just sharing a little bit of each of our perspectives on on software engineering from the path that we chose and and one thing to think about for all of you is, you know, your own pathways, right?

I mean, like I mentioned, for me, I was all about the startup world and getting into startups from an early age and following that rabbit hole. But there’s so many different paths, right? And I hope you can kind of get a sense of of of each of the different routes you can go and and the trade-offs in addition to some of the other advice we share.

So, I’m going to kick it back over to you all for maybe just to write into chat. If you have one thing I’d love to understand is many of you have probably worked with seasoned engineers in one form or another we’d love for you to you know drop any responses this question which is you know for people you’ve worked with that you admired could be anybody that you’ve worked with in any capacity you know what stood out to you about people that made you think oh this person you know really kind of surprised me or or you know was was obviously very experienced what did you notice about them and their behavior that stood out to you. So, I think that would just be something we would be fascinating for everybody to be able to look through.

And as we get into it, I’ll give you all a second to write and and think in a chat. I’m going to move it over to the next slide here. And I wanted to kick off by letting Jessica and Kabir both share their thoughts about you know, what it looks like to grow as an engineer, especially in the early stages.

Yeah, great question. Yeah to kind of start off I think a great place to start is mastering the fundamentals when it comes to computer science. So whether that’s data structures and algorithms if it’s anything domain related so whether that’s mobile machine learning backend or whatnot u making sure you’re really focusing on the core of your CS fundamentals.

Personally I love to build Legos. So think of mastering your fundamentals as you know Lego blocks. You want to really build out a proper foundation for as you’re growing as an engineer.

Basically these building blocks, allow you to better solve problems. Think of them kind of like, a toolbox, per se. Example of this was, when I was working on building out, a favorites list for movies.

And, yeah, just working on it, it was think it just it was very clear to me like, hey, this is a great, place to use a set versus an array. And yeah, just really thinking about those building blocks and kind of moving on to growing and doing so. Thinking about those, building blocks.

A huge way to grow as an engineer is to do that by doing and learning. Think about it, you know, the first time if anyone’s like, ridden a bike. You’re only going to get better at software engineering by doing it a lot more.

So, using those Lego u building blocks and the best way to do it, it also helps with imposter syndrome. The more you do it, the more confident you are going to be in your software engineering skills and feeling like you you you know what you’re doing. And that just comes through, you know, practice and trying.

A lot of times you are also going to fail and that’s totally okay. Failure is definitely an opportunity to learn and take those opportunities to you know recognize you know areas where maybe you can grow a little bit more and learn a bit more and use that to continue building you know those Lego bricks as you’re building building and growing as an as as a software engineer. And then that kind of brings us to seeking feedback and mentorship.

A huge part of my growth, and I’m sure a lot of people can agree, was through receiving feedback and also through mentorship. It’s really a fasttrack way to grow. So getting feedback on a project, getting feedback on something you’ve worked on.

Mentors and people giving you feedback are able to ident, you know, one, if you did something really well, and also two, where you could do a better job of that. Example for me was when I was working on building out, this configuration view. And my manager mentioned like, hey, like you can do this a lot better.

And it just really improved the way I was able to build that quicker and I did that, you know, multiple times after building that. Also speaking about a mentor, like where to find one. I know that question comes up.

CodePaths does have a mentorship platform. I I did want to mention that. It’s been super helpful for me.

I know it’s been helpful for other people. And I’ll hand it over to Jessica to talk about some of her advice and tips. Yeah, thanks Kavir.

So I think something really important as especially interns and new grads starting out into your career is to take the agency to take charge of your own growth and proactive planning. I think as early career engineers we think that our our growth is dependent on our manager and or our mentor. But in reality every job will have a different structure and you can’t control that but what you can control is how you approach your own growth.

So for example at Roblox when I was interning I had an interest in product management. I was hired as an engineering intern but I just asked like can I do some product management work on the side. And that path actually well one it made me realize I didn’t want to do product management but I did get a return offer to come back both as a product engineer or an engineering full-time engineer.

So I think that’s super important especially when you’re interning to explore take charge of your own growth and plan for it. The next thing that I think is kind of neglected as early career engineers is project management skills. As engineers, I think we get so caught up in showing our technical prowess that we tend to neglect all the other parts of a project that makes it successful.

So, as someone who’s now mentored interns, something that’s really stood out for me is not only someone who can complete a project, but someone who can effectively plan for it, update stakeholders, document their research, and overall just communicate throughout the entire process. Kind of to piggyback off of that too is effective research and presentation skills. There’s actually a lot of presentation that goes into being an engineer.

For most internships you’ll have an intern presentation, but even more than that, you’ll always have technical spec reviews, design doc reviews. So, being able to learn and develop technical communication skills to broad audiences early on can really help you stand out in the future. And finally, the last thing that I think is helpful in leveling up as an engineer is understanding the why behind your projects.

So understanding how your project maps to team goals or company goals and if you don’t know, just ask. And doing this can really help you find sort of problems that you didn’t know were there and offer solutions to problems that maybe your team didn’t even know existed. Awesome.

Thanks so much, Jessica Kavir. I’d love to now hand it over to Diana to kind of share from her perspective and and I’ll I’ll pass it over to her to to kind of kick things off. Yeah.

So, just to frame this a little bit, a manager, my first manager at Netflix, said during our 360 feedback meeting that I had an efficiency bias. He didn’t consider it a good thing, a bad thing, just a neutral thing. I take it to mean I’m good at finding shortcuts and getting things done.

And this is a collection of my shortcuts to loving up leveling up from junior to senior. Okay, first thing master writing technical design docs. If you haven’t gotten your first internship or your first job at college, one thing you’ll notice when you do is that the seniors, the you know staff engineers, the senior staffs, they are writing these technical design docs that get circulated for feedback.

And if you do that and start doing that and write these coherent technical design docs and ask for feedback regularly, you will soon establish yourself as one of the thought leaders on the team. Number two, identify and propose solutions to bottlenecks. So, you know, here’s an example from Cash App.

So, one of the things that I noticed while I was there is we didn’t have very good ways of detecting where things go wrong on the client. We were relying on server side data dog metrics or, you know, analytics metrics to figure out what things went wrong. So, I took it upon myself to just write a proposal of how we could hook into this new data dog product called real user monitoring to help people find bugs quicker.

I was just it was a onewoman show. I kind of got permission from my manager because like I had finished most of my work to do it. And when I did it, people started jumping on board.

It’s like, "Oh, I’ve had this problem. You know, can I work with you on getting this in?" leadership started you know taking note of that and actually gave me budget to the tune of seven figures to run a pilot of this on the Android platform. So that is a really good way to get impact that is outside your team outside your org of you know identifying the problem writing something up and then circulating it and see if it’s actually a problem.

Three is regularly solicit feedback. A lot of people are shy about feedback. You want that you want the criticism upfront and early.

Especially when you first start a new job, you don’t want to be making the same mistakes over and over. You know, to be to be honest, I definitely have a mental model of a lot of my co-workers of the people who are improving just like, you know, hockey stick growth in their skills and trajectory and then people who are kind of at the same level as the years go by and you don’t want to be that person who’s plateauing. And the way to get there is to ask, you know, hey, does anybody, you know, have any does this look good to people?

I’m just sharing this out. Share it out in the public channels, see who bites. And develop that muscle of taking feedback, incorporating it, and thanking people afterwards so they don’t feel bad about giving you harsh criticism that they know is true.

Four, conducting effective meetings. This is one of my pet peeves. I have transitioned, you know, from, you know, junior to senior to senior tech lead.

And often times meetings have no agenda. The important people we have to ask questions to aren’t even in the room. And the way I solve that is just having a template.

So first of all, you know, always have an agenda. Second of all, open questions. Just like if something is on your mind about the project that doesn’t fit into the agenda, there’s a space for this.

And three, I always take notes when leading meetings and assign at mention the person who is owning this task or action item so we can all hold them accountable as a team. I also send that out before the meeting starts. So, people will typically add their things to the dock so we have clarity on what we’re actually trying to get through in the meeting and who really needs to be there.

Because I don’t know about you all, the rest of the panel, but I’ve definitely been in meetings where I’m like, "Okay, I got this invite. I don’t know why I’m here. I didn’t say anything during this entire hour, but I guess you got something out of it." You don’t want to have those meetings.

Five, mentorship. I think Kabir mentioned mentorship. It’s a tricky subject because I for one have participated in formal mentorship programs.

You know, Instacart had one. You know, I honestly didn’t get a lot of value out of those, right? I checked in on maybe once every couple months with my mentor.

They were just very outside of the sphere of what I was doing day-to-day. You want to strengthen bonds with people who you work well with, who know your work style, who you have overlap with on projects and just be like, hey, you know, here’s example of one thing. I wanted to do more server work.

I wanted to do more backend work. I was doing full stack web for my side projects, but I wasn’t touching the server, you know, because my day-to-day was Android. And I asked a person on my team who was a cool guy, who was a smart guy and he just did backend, you know, hey, you know, hey John, would you mentor me in server?

I just want to know more and get like more visibility on how our endto-end systems work. He was like, sure, that is a great way to grow your skill set. And then you take control over being with the person that you learn the most from and have a good relationship with versus just being assigned, you know, a random person as part of a formal mentorship program who you don’t jive with.

Six is recognizing strengths and teammates. Some teammates may be excellent communicators. You know, you might want to have that person like review your design doc.

Some people are just like deep into the weeds of the Android framework. You know, if you’re, you know, touching something that might break the whole app infrastructure, go to them. Like develop a model of who’s good at what, so you know who to go to.

You know, don’t just go to your friend because you know, you chill with them at the lunch table, right? You want to get the most out of your relationships with your teammates and that’s the way to do it. Also positively influence engineering culture.

We all have the teammate who is the brilliant jerk, right? They’re nobody likes working with them, but you know, they’re not expendable. They do great work, you know, so people just force themselves to do it.

But that’s not the one kind of team we want to build. The way at least I approach it is to open the floor to people and just welcome them. It’s like, okay, you know, hey, thanks for, you know, I appreciate if you, you know, take a look at this or review my PR.

Like, I saw that you did this awesome work and I just wanted to learn more from you, right? Just be vulnerable in what you know, what you don’t know. And thank people, appreciate them, and do it publicly so others will do that, too.

You know, I’ve been on teams that are very like closed-lipped and, you know, just kind of their eyes are glazing over, the cameras are off. But giving them kudos in the meeting, you know, you know, brightens their day and engages them more. And you want to work on teams like that.

Because I don’t know, I’ve been on those other teams and it’s kind of sad. Okay, slide two. I’m going to speedrun because I know this is getting a little long.

Okay. So, LLMs, generative AI, and I think Nathan has a few slides on that, is a hot topic. A lot of people think that, especially entry-level engineers, you won’t learn if you’re copying and pasting code.

There is a way to use LLMs in an effective way, and that is don’t copy and paste the code. Ask why. You know, why am I doing this?

Like, be the annoying 5-year-old asking why down the rabbit hole. Why this? Why that?

Because you know the LLM is not going to judge you for not knowing things. So dig deeply when you and then copy and paste the code if it works right but you want to know the why. Ask questions publicly.

I kind of got at that because somebody else might have that question and also it builds the culture of asking questions, curiosity, inquisitiveness, being vulnerable and then it also is a check on your own mistakes. Because I’ve definitely made the mistakes earlier on in my career of like, okay, let me just Google this, Stack Overflow this. I don’t want people to think I’m dumb and then it ends up in a bug that I’m fixing over the weekend.

Pull threads if something doesn’t make sense. Especially with communicators who are not great communicators. A lot of this is over Slack.

I work remotely. I’ve been working remotely for five years. And just ask follow-up questions like, "What do you mean?" you know, people might get upset, but if you poke at them enough, they’ll realize they’re not being clear and it saves you from making mistakes.

Set aside time for learning. I know this is a hard one, because like especially in big tech, like the work is very demanding, but it’s important to not have to not plateau. So, one thing I like to do is just like, hey, side projects.

Like, let’s learn web app development. Like, I learned Remix, you know, over the weekend. I built like a a food truck website like a couple weekends ago.

Where’s the truck.com? It’s only Asheville specific, and I don’t know if many of those food trucks exist anymore, sadly. But, you know, it’s a way of stretching your muscle and not getting locked into a particular technology or way of thinking.

Also five, track how you spend your time. I have a Slack channel called DAna Office where I post what I’m working on every single day. You know, I don’t know if anybody’s looking at it.

I don’t know if anybody’s paying attention, but it makes it clear to me, oh, hey, I spent two days on the same bug. I should probably ask somebody for help. This is not productive at this point.

And it really like for me, I was like kind of unproductive when I started out. In Android and I didn’t know that because like nobody was giving me this feedback as still they until they started tracking PRs and commits and everything. I held myself accountable by doing this and I ended up as one of the top committers in our repo on Android.

Three months after I got back to Netflix, I was the top committer and it really makes you like hold yourself to your own standard. It’s not all about being the top committer, but it’s about just like being productive, moving forward, pushing yourself a little bit, and growing. Overcommunicate and give context.

I talk a lot, as you could probably tell. It’s important sometimes to just like air out all of your plans as just an official check. Like, hey, I’m thinking about doing this.

What do you guys think? Hey, this person over there who knows more than I do, like is this line of thinking right? Is there anything else I have to worry about?

Because when you’re engineering large systems, it’s all about these edge cases or this, you know, context that you don’t have. And then the last one is prioritize relationships. I think that’s a lot of, you know, where people slip and I slip, too.

Like, you know, I’ve left jobs with, you know, hey, like I’m not even friends with you on LinkedIn, like, you know, and then grown to having text relationships with my co-workers still to this day, right? You know, complaining about like whatever manager or hey, you know, I need this job referral. Can you give me the inside info?

You know, you want to be the type of person who others want to work with, others like working with. And sometimes it’s not all about just like being right. It’s about being accommodating, you know, being a good teammate, like being a good shoulder to lean on, all of that.

And the relationship is key because if people don’t like you, they’re not going to help you grow. Okay, next slide. Awesome.

Well, I want to leave plenty of time for questions, of course, so I’ll try to you know, keep some of my thoughts brief and then we’ll we’ll spend some of the time diving into what you all are most interested in. But I loved all the advice so far. I think Jessica, Kabir, Diana hit some really really important points in the in the brass tax of of what what to kind of watch out for or to lean into.

I wanted to start my section briefly by kind of pulling up a level and I just want to be like really honest about I mean I’ve worked with I’ve been doing businesses software engineering launching companies for 20 years and I wanted to be really honest about what I see as the core muscles that either allow someone to be exceptional or actually cause people to struggle. And I want you all to think about each of these core muscles as you understand your relationship to that today. But I also want you to think about ways that you can develop these muscles over time.

All of these things are things that we can develop. We can become exceptional at each and every of these things. Yes, some people will start intuitively like you might find certain ones here that you’re intuitively good at and there might be others that you know, oh boy, this is actually a big challenge for me.

So the first step is just understanding these core muscles and then the next step is understanding which ones you can’t work on all of them all the time. So finding ones you feel like you’re really good at and becoming even better, like just becoming truly exceptional. And the other one is maybe be honest about what are the ones that you struggle with the most and then really like being very practical about how to fix that.

Whether that’s, you know, anything from, you know, literally like meditation, supplements, writing down a process for the for it on paper and literally like practicing the muscle in writing, talking to chat GPT or Claude, and literally like talking to it about I’m trying to get better at this. Here’s what I’m thinking. So, I wanted to kind of just introduce these muscles because I think they’re incredibly important.

I’m not just talking about for software engineering. I’m talking about for pretty much anything you want to do in the world as it relates to creation, right? So, the first one of course is what I like think of as like each of these as sort of parts of the Doctor Strange power from Marvel where you can like look into your crystal ball, right?

But it’s different types. The first one is very focused directly on that which is it’s a fundamental muscle that some people have incredibly strongly developed and some people don’t. And I’ve seen this, to be completely honest with you, be the number one thing that causes people problems as they’re developing in their career.

It’s a failure of them, their ability to model pathways into the future. And when I say model, what I’m talking about is fundamentally in your head or on paper projecting futures, right? I ship this feature.

Why are people not going to like it? I am going to write into this PR some feedback. What might upset somebody that I’m when I when I post it?

You know, I’m building this feature and I’m and I’m building it into the app. How could that feature go wrong? Where can it fail?

Why is it going to be embarrassing when I push to production and there’s a huge mistake? So, it’s this it’s this fundamental ability that can be honed, that can be developed to you’re actively in your own head or in writing actually attempting to model future realities. You’re either modeling the behavior of people.

How is a user going to respond to this? Why are they going to like it or not like it? It’s modeling your own team.

It’s modeling time, which kind of gets to number four. It’s all these different forms of modeling. And most of us can intuitively model certain things.

Okay. Other things we model very poorly. It’s critical to start to understand and be really honest about trying to set up a guess for the future.

And then when you’re wildly wrong, which you often are, don’t just be like, "Oh, well, I’m wrong." Think about like, "Why was I wrong? Is it because I didn’t understand the user well enough? Is it because I didn’t understand my own team well enough?

Is it because I didn’t understand my own weaknesses well enough? Is it because I didn’t understand the risks of the of the feature or the project well enough? What is it that was causing your model of the future to be wrong?" The more you can go into that loop and develop a strong ability to model the future of reality, that is literally, I would say, more important than any other underlying skill that will lead you to be able to start companies, be an engineering leader, architect projects, create open source, you know, launch marketing, whatever you end up doing in your life.

That’s number one. The second one, which I I want people to really get serious with, and and most of you here probably already have this ability to a degree, but it’s the ability to get into the flow state. The float state is not just some woowoo thing that people talk about.

It’s actually a brainwave shift that is actually changing scientifically in your head when you’re in that mode that I’m sure all of you have experienced where time starts to fly by. It’s this really unique experience. If you haven’t experienced it, you know, it’s really hard to describe, but for everyone that has, you know exactly what I’m talking about.

It’s like you you you like you get into it and you’re just like in the zone and stuff is happening and it’s almost flowing from you almost like beyond your just like conscious cognitive cognition and then you look up at the clock and like four hours have gone by. Your ability to get into flow state, your ability to recognize what puts you into flow state versus what does not put you into flow state. And then your ability to get better at focusing your own attention within that flow state is literally the the second most important thing you can do in the world, especially as a software engineer, but really for anything.

And if you’re finding it really hard to get into flow state, then you want to ask yourself, are there other things I’ve done that I can remember that I have gotten into flow state? And that allows you to understand over time where you need to specialize or double down, where you need to avoid. So it’s not only extremely valuable in terms of getting things done, it’s extremely valuable in terms of understanding where you want your own career and your own life to go.

So it’s the combo of number one and number two really feed into the these other ones. I won’t go into all of them in as much detail, but in addition, your own emotional coping and management of your own stress and frustration becomes essential, right? Managing against burnout, managing against the frustration of being in the middle of a codebase and you have no idea what’s going on and you feel like you’re like completely out of your depth and you’re like and you were also made a change and now it’s completely broken and the build’s broke and it’s like these things are very stressful.

It all sorts of feelings will come through you all sorts of emotions will come through you learn thinking of that as a muscle and how to manage those emotions as they flow through you and not getting too attached to them or allowing them to paralyze you is essential. So I I won’t go through all of them because just in the interest of time, but I really want to emphasize how important these core skills are in everything else and and talk to chat GPT about these things, right? So for example, number one on my other list and I’m going to not even go through everything because I don’t want to take up the whole rest of the session, but you know, one is please please talk to generative AI.

Like seriously, like like almost like a therapist, go to it and be like, I got feedback from my team that XYZ I feel like I’m not very good at modeling the user. Here’s what I feel like I know about the user. Help me get better at this.

Or literally like don’t just ask it for code. Literally have like back and forth conversations with generative AI and use it to poke holes in your own thinking. Like ask it directly, you know?

Like like write it out, right? Like I want you to challenge me. I want you to help me understand where this code would break.

I want you to help me understand why this feedback I gave might have been taken wrong. I want you to help me understand why my time estimate might be inaccurate. And literally have a back and forth conversation where you allow chat GPT to poke holes in your thinking.

Because the cool part about this, and this has actually been studied, is that when an AI pokes holes, it’s actually less emotionally reactive than when a human does. So, it’s a really powerful way to get honest, objective feedback and also to challenge your own thinking without having it trigger as much of the emotional reaction of of what you would have sometimes when you’re interacting with people. So, please do that.

So, yes, write you know, use it to ask for stack traces and issues, use chatpt to help you think through error cases and be a defensive programmer, but also use it as a human and use it to help you develop those core skills. So that’s actually all I’m going to say from my perspective right now because I want to leave plenty of time for questions and I think we’re going to go until about 10:15 just because I know we started a little bit late. So what I’m going to do is I’m actually going to stop there in terms of my specific feedback and any other feedback I provide I’m happy to do in the context of you know questions from the from from you all so we can kind of share what you’re most interested in.

So, I’ll pass it over to Bobby. I think he’s going to help moderate the questions for the panel and then we’ll go through as many questions as we can. Well, first of all, I want to say thank you so much all three four of you all giving us some insights in terms of this specific skill.

And one of the first questions that came out was there’s a term that’s been burning very hot in our industry around imposttor syndrome. And my question or the question that’s come in is how have you all dealt with Apost syndrome as you started to develop in your career? Well, I’ll I’ll kick off and then I would love to hear from others on the panel that that kind of experienced this.

I would venture to guess almost all of us have experienced it at one form or another. I would say it’s especially heightened amongst people like exactly as myself where you feel like you’re a little bit you always at least for me I always felt a little bit like I didn’t belong in a lot of the settings when I first started out. I remember thinking, you know, like a lot of other people would talk about like friends that they had or family that worked at Google or worked at like startups and I just was coming from a totally different universe where like nobody in my family knew anything about tech.

And so I just remember from a very early age and because I’m naturally anxious and naturally like an overthinker just constantly questioning whether or not I really belonged there and whether I was even smart enough to be able to do anything, let alone lead or run or or build a company. Like I I always would sometimes start my life with negative selft talk a lot of negative selft talk tapes you know telling me why it’s never going to work you know I’m not smart enough like there’s these tapes that would play in my brain and to some degree they still play but you for me over time those negative selft talk tapes the power of them have lessened over time and I can talk a little bit more about that but I would say my guess is almost every single one of you in the audience I know for me 100% at various points in time imposter syndrome is a powerful you know part of your inner experience and you know we need to be honest about that. We need to grapple with that.

I’d love to hear from other co-panelists you know their experience with imposter syndrome and maybe any tips about you know how you’ve managed that or how it’s evolved for you as you’ve developed in your career. I love what you said about the mindset stuff that is so important and the way I’ve dealt with my own imposttor syndrome obviously you guys know not many people look like me in big tech who are individual contributors or you know tech leads but you can’t argue with code if you are contributing if you are shipping your projects if you are basically kind of isolating yourself because it is mindset right I thinking these negative things about myself, about my work. Maybe somebody said something.

You know, I’ve had these experiences. I’ve had, you know, when I was a top committer in the repo, all of a sudden people started talking about me in Slack and I came upon a few threads criticizing my commit strategy. Oh, she just does fine grain commits.

People will say that people are talking about you. If they’re talking about you in a jealous fashion, it probably means you’re doing something right. And the mindset is don’t let them waste the time.

Do the work and get it out there. And people can’t argue with that. Roger that.

I I got a next question up for Jessica and Kabir. The audience wants to know, how has CodePath helped you offer the opportunities for you to lay in the roles that you’re in now? Yeah.

So for me, like I mentioned before, CodePath was a really big part of my university experience and a big part of that was that I got to build something. My college courses didn’t really have that. We learned the fundamentals of computer science, but actually, you know, making an app, thinking about the user, getting into that business mindset was such a huge part for me landing this role.

And I really made use of the CodePath mentor network and I encourage everyone here to make use of that. A lot of us here are mentors on that. You can find a lot of informal mentors or even start formal mentorships on there.

Ask for referrals and things like that. CodePath is a really amazing resource. So I encourage everyone to make the most of it.

Yeah, I totally agree with Jessica on everything she said. I would just add CodePath is also just really supportive with career coaching. I know that’s been a huge help in you know landing the roles that I have helping me with you know networking.

Kind of similar to what Jessica mentioned, there’s CodePath alum working at all sorts of different companies. Definitely reach out for coffee chats. And yeah, I’ve had a lot of help, you know, whether it was a referral, or just meeting people.

And I think the most important part is CodePath really gives you the skills to succeed in your job search. So whether that’s networking, handling like your resume, interviewing, I think, you know, CodePath really gives you those resources to do that. So definitely use those resources if you’re not already.

Roger that. Roger that. And thank you both so much for that insights.

The next question that came comes up is a topic that I even heard Nathan mention that he started off his career contributing to open source. There’s a lot of cohorts and students here that are intimidated by it based on you know the type of projects and potentially the code base. Would you all have any feedback on that in terms of the value around contributing to open source?

So I mean I can definitely speak to this. One I really appreciate the question first of all. I can tell you for me and my journey open source literally changed like literally changed my entire perception of what it meant to be a software engineer.

And also completely changed my life. Some of the connections and friends I made through open source ended up like literally is why I moved to San Francisco and then you know literally why I was able to get some of the opportunities that I had through my life. So for me, I would absolutely encourage folks that are interested in participating to try to get started.

And I think there’s a couple things I just want to put out there like real talk that you should just kind of go in expecting. First one is, you know, you’re ne when you go into an open source codebase of like a sizable project, you’re never going to understand the entire codebase. I I mean I can tell you like when I first started, so you know, I was working in a web I was working in web application development and I I was using this framework called Ruby on Rails, right?

And my one of my first open source contributions was I like could not for the life of me in the documentation figure out how to do this one thing that I needed to do. And so I was like this is ridiculous. I was googling I was on Stack Overflow and it ended up being like four lines of code but it’s like I swear to you it was like nowhere.

And at first I thought maybe I just missed it. So, I ended up like putting a section into one of the the docs in the one page that I was looking at and I just added a section like literally one subsection and I submitted that and then I got like a bunch of likes and a bunch of other people were like, "Oh my I was I’ve done that too. You’re right." And then you know they gave me a bunch of feedback like oh I can’t add this as it is because your your writing is not very good.

And I was like oh it like hurt right and I was like oh that sucks. And then but they gave me some feedback and I like iterated on it like three four times and like I sorry I still can’t release it as it is because you didn’t put it in these four other places and I was like my god is this this is so elaborate you know and I like went through and did that but at a certain point they’re like this looks great it’s in all the right places you’ve added it to the build like let’s ship this and that was like my it was like a dopamine hit. It’s like I’d gone through all these hurdles.

It was really frustrating. They told me why I sucked. It was like painful.

You know they weren’t very nice to me at to first to be honest but like there was something very powerful about now I’m officially committed code to like one of the most popular frameworks in web at that time and it got me hooked and so what I ended up doing was I’d be using other open source projects and I would notice again the documentation sucked honestly and so that’s how I got my foot in the door initially was radically improving the readmes or radically improving the wiki it was a great way to get started because I didn’t understand the codebase at all now over time right there came points where I started to not understand the whole codebase because almost nobody does except for maybe the actual like core contributors right but like the individual person on GitHub nobody understands the whole codebase but what what what can happen is you’re working on a feature or you’re trying something an open source project and you hit a bug or you know what I mean like there’s a feature you wish existed and then you don’t try to understand the whole codebase but what you do is you you literally just try to find like that one file or those two files that are related to that one really small thing like error or feature And then just make it very practical. Like don’t even stress yourself about adding it because that might be too much. But just ask yourself, okay, where does this live?

Like let me just spend a little bit of time spelunking through this code. Can I even find the file? Right?

And let’s say you find the file. Could I find the method that I would need to change or add? And if you can get that far, then it’s only one more step to be like, well, let me clone the project and create a branch.

I mean, again, you may tell yourself, I’m not going to push this, right? But let me just try it. And for me, that’s what I did.

And at one point I remember adding this kind of cool feature. It was this alias. It was a very simple feature.

It was an alias to make the syntax easier for this feature of one line of this framework. And I ended up putting up the PR. I got like a bunch of negative feedback.

At first they rejected it. I made some adjustments. Two weeks go by and literally it was added to the readme.

It was shipped and I now was a code contributor to that project. And so I just got hooked. And so over years you know my understanding of things deepened.

My development of what it meant to ship you know software that was open source ready like started to heighten and I was self-editing rather than needing them to edit it for me and so it’s hard to un overstate like how powerful that was for me and my journey and also how small you want to start like you’re not go you know like don’t put so many expectations on yourself right that you’re going to understand a whole project or you’re going to be able to add some huge feature start small start simple but start if you can if you’re interested And it’s not for everybody, but if you dabble in I definitely encourage you to and would love to hear anyone else maybe briefly that would that has dabbled at all in open source and then we can move to the next question. Well, I I’ll just also mention that open source is definitely something that I’ve experienced that same feeling in terms of getting feedback thinking that I’m not qualified enough, but working through the feedback and then getting that feeling, that adrenaline, that feeling of like, oh my gosh, I made a contribution that’s going to run on computers all around the world. And I definitely definitely appreciate that feedback, Nathan.

Thank you so much for that. And I hope it inspires our audience to to really pursue that. I do have another another question lined up and this is actually for DA is one of the things that I know as a senior engineer and been in the industry for a while is that you’re interviewing and evaluating candidates and one of the questions that come in is how can candidates stand out amongst the mass of individuals that are looking to pursue computer science and more specifically like what what is the thing that you notice that be like oh my gosh yeah we want to hire this person and bring them on and how can they stand out in the interview process?

Okay. A lot of people might disagree with me. I came from Cash App.

I met Netflix. I know Netflix is a big and sexy name, but Cash App’s Android team was absolutely stellar in a way that I had never experienced on any other engineering team before. And I think one of the keys is their prioritization of communication and collaboration.

So during the interviews, they’re pair programming interviews typically, and that’s typically the way I like to run my interviews that I’m doing is are you going to listen to me when I give you feedback of, hey, let’s not focus so much on that, right? Let’s do this thing instead. Are you going to listen to when I hint you or go along and stick to your own like architecture where it’s like clearly doesn’t go not going to work?

We’ve asked this question, you know, hundreds of times. This is the, you know, two out of five answer that you’re going or are you going to listen to me and adapt? Right?

That’s what I’m looking for is that adaptability and communication and really listening because I don’t want to work with a teammate who’s not going to take feedback and who’s just going to like code a bunch of messy stuff that I have to interact with and maintain and, you know, it’s a red flag. You can do all the leak code you want. And I’ve seen people, it’s really funny because, here’s an anecdote from Instacart.

Actually, there was this one guy who kind of blew the interview out of the water. He finished in record time. You know, we were 30 minutes the way through and he, you know, had already exceeded like our staff level, you know, bar.

And me and my pair interviewer, we’re like, we’re done here. You know, you did great. This is awesome.

Yeah. Like do you have any questions for us? Kind of like going into the cell and he insisted on completing asking this next API that we wanted to build and completing it, you know, and my co-iner as like talked to each other and I was like, "Yeah, he’s technically great, but he just didn’t listen, you know.

We just sat there watching him code this thing and we obviously know how awesome he is and I just really really don’t understand why that’s not the type of person I want to work with. Obviously you have to be technically good but make sure to listen and pair well. Ah some some powerful feedback there and thank you so much for that.

We we’re up to our last question here and actually it’s for all panelists and we’ll go in the order of Jessica, Kabir, Diana and then Nathan at the end. But Jessica, could you give your top advice to those that are attending pursuing software engineering as a career to close us out? Yeah, I think the best advice coming from me would be if you think you’re not qualified for a position, if you think you’re not good enough for a project, just apply.

Just do it anyways. Everyone experiences imposter syndrome. And take comfort knowing that everyone, even those who you think wouldn’t experience imposter syndrome does.

Yeah, my advice would be definitely keep a like a win sheet. This is something Kelsey mentioned to me. Whether it’s something as small as like this is something I did on a project.

List your wins. It really helps with the imposttor syndrome and, you know, just something to look back when those negative self-t talk comes up. You know, look at that.

The other piece I wanted to mention was make sure you’re prioritizing you know, self-care. So whether that’s you know taking time to you know take a walk but make sure you know you are prioritizing self-care. It is a marathon not a sprint.

I think mine is always be learning al and do what you need to do to fix your mindset. Yeah. Yeah.

And I guess I’ll just wrap up by once again jumping on the hype train and saying I would I’d do all of those things and I would also get really good at practicing conversational development with generative AI. Like go to the AI and like tell it your goals. Tell it what you want to do.

I want to contribute to open source. I want to reduce the negative selft talk, you know, and and and so focus on your goals. Be reflective.

Be self-aware. And do it in a way where you’re you’re working with other people as well as like working with AI to achieve your own goals. It’s an incredible time to be alive.

I can tell you from you know and and also I guess the last thing I’ll leave people with is it is frustrating in a lot of ways trying to crack into the tech industry. Like I just want to I want to emphasize that I understand you know how many students I’ve talked to that you know literally they apply to 50 jobs and they hear back from like one or zero right like this is a thing you know it’s cyclical I I just want to let everybody know like you know it it is challenging it is difficult and I you know at various times for different reasons but it’s also a really exciting time to get in as well and so you know I just really want to kind of leave people with the message of hope which is one use all the CodePath resources and materials available to you. We’ve developed this specifically to help people crack in based on how difficult we know it is.

But the other piece is going back to my core skills, you know, that emotion management becomes really important because it’s really easy to give up. And I I you know, I just really want to impart to people like you do belong here. You deserve this path if you want it.

You are smart enough. Like use those affirmations and and you know, take that with you forward as you’re as you’re going on your journey. Roger that.

Now, let let’s all give them a round of applause. And I need y’all to show your love inside of the chat, letting them know how much we appreciate each and every one of them. So, thank you so much, Jessica, Kabir, Diana, and also Nathan.

We really do appreciate your time and insights. This is right here for me is behind the scenes so that y’all can really understand how to level up in this industry. Now, in terms of next step, I want you to all first of all, go show some more appreciation.

And if you didn’t press that button or the like the heart, send them send them. But also head back to the main stage so that you can see what next session you can log into. Again, thank you all so much for attending our opening session in day number two.

It’s your boy Bobby D. Have a great rest of your day. We’ll be chatting soon.