How To Know If A Coding Bootcamp Is Right For You

Don Hansen: 0:13

Welcome back to another podcast episode where we help aspiring developers get jobs. And junior developers grow with me today. I brought on Dan from launch academy and we're gonna be going over a few topics that, um, he actually brought up that I think are gonna be really interesting.

Dan Pickett: 0:28

So a lot of

Don Hansen: 0:30

people are really confused on, you know, if they are even meant to or wanna become a developer, we're gonna be diving into that. Um, as well as, you know, some people consider coding boot camp, an option, but they don't quite know whether they should seriously consider it, whether it's for them. So if you are questioning whether you should become a developer or you wanna attend a coding boot camp, we are gonna dive into these topics and hopefully provide you some advice. And if we have time and this is what I'm gonna be pretty excited to go through. The mistakes that aspiring developers make that might, um, how do I wanna say this, um, hurt their chances of higher ability? So we're gonna provide some advice for aspiring developers on all three topics, but like normal let's go ahead and dive into our intros. Um, Dan, would you like to introduce

Dan Pickett: 1:18

yourself, everybody happy to be here? Thanks for having me done. Yeah, absolutely.

Don Hansen: 1:23

Um, you know, sometimes one thing I wanna say, and, you know, for my audience, um, sometimes staff will reach out to me and from coding boot camps and you know, what they wanna talk about. It's kind of clear, you know, most of it's gonna be a sales pitch. And the difference with you. And I, I wanna tell everyone listening, um, this outline is fantastic. I really do think that you're kind of just trying to

Dan Pickett: 1:49

give a lot of advice

Don Hansen: 1:51

for developers that are a little confused along their paths. So, I mean, quite frankly, that's the reason I brought Jan, I'm excited to dive into these, uh, topics, so let's jump right into it. Um, so you had brought up the idea of, um, you know, deciding if you want to become a developer, um, and you had brought up different talking points for that. So my question to you is how do you even

Dan Pickett: 2:15

decide something like that? Yeah, well, you know, I, I think that there's, uh, such a sort of desire in the market and, and if you go to sort of like code academy and other sites, The message in the, in the, in, even coming from the government, uh, the federal government is everyone should learn how to code. Uh, and you know, I, I just don't prescribe to that perspective. Uh, coding is not for everyone. And I think it's really important when you're specifically, uh, considering a career change to really identify if it's something, uh, that you want to do first and foremost. And then, uh, I think we can talk through a few of the things that developers do on a daily basis that may shine a light on whether this is for you or not. um, so, you know, I think that that, that whole philosophy of, um, coding being for everyone, I, I don't necessarily agree with because, um, there are aspects of software engineering that may be a turnoff to some folks, for example, how do you manage uncertainty? Right. Uh, as an engineer, one of the things we always like to tell our students, and, uh, I like to tell, uh, other folks, uh, that are thinking about becoming a software engineer is. Um, nine times outta 10, when I dive into a specific problem, I don't yet know the answer or the way in which I'm gonna resolve that situation. Right. Um, and for folks that maybe are in, and, and this is sort of very hand waving, maybe in the accounting professions, uh, the financial and actuarial per professions, um, where like it's very concrete and very, very well known go going into a particular project. Software engineering is way more open ended than that. So I would first ask, how do you really manage that uncertainty? How do you deal with not immediately knowing the answer when you're presented with a challenge?

Don Hansen: 4:11

Yeah. That that is tricky. How do you, how do you determine whether. You are someone that handles uncertainty? Well,

Dan Pickett: 4:23

well, so maybe, uh, there was a time at work where they maybe had to change your roll up. Right. And, uh, your roles and responsibilities changed, or your manager changed, um, or the team that you were working with changed. Right. Um, how did you respond to that? Was that like extremely stressful in, uh, anxiety inducing for you? Um, was that, uh, something that really made you uncomfortable going into work on a day to day basis? Right. So we always encourage folks to look at their prior work history and maybe even some of their academic history. Where somebody kind of changed the game on you right. Or changed things up on you. How did you respond to that? How did you adapt? Uh, and, um, how did that make you feel? Right. I think that that's a, that's a big aspect of it as well is you could have done extremely well working through that challenge. Um, but like how uncomfortable were you? Were you losing sleep at night? Were you, um, dreading going to work in the morning? Right? Um, if that level of uncertainty, uh, is going to throw you off your game, that much. It may be, uh, worthy of pausing, uh, in thinking about whether software engineering is for you. Okay.

Don Hansen: 5:37

I think that makes a lot of sense. Um, okay. Yeah. Keep diving

Dan Pickett: 5:41

in. I like these. Yeah. Uh, the other thing that I think is a natural part of software engineering. Um, I always like to say that our number one resource is our time, right? So the cost of computing is going down, right. Especially as, um, uh, services like Amazon web services, GCP, Google cloud, um, and Microsoft Azure are coming into their heyday. Computing power is cheap, right? Network is cheap. What is expensive to, uh, today's businesses is software developer time. Uh, and so what comes with that often, uh, depending on how, uh, intense the culture is in, in the organization that you go to work for time pressure is a real thing. Right? So, um, deadlines, uh, uh, and you know, so you're, you're, you're balancing this uncertainty with time pressure. And how do you sort of marry those two things? And, and how do you respond to not knowing all the answers, but also knowing that there's like a finite date that you need to deliver something by. Right. Um, and for a lot of folks, if you have that deadline pressure, coupled with not knowing all the answers, that can be incredibly stressful too. So another area I'd recommend to explore. You know, how, how do you deal with time pressure? How do you deal with, um, management pressure that comes in and says, Hey, we really need to have this feature out by, uh, such and such a date. Usually it coincides with a holiday or something like that. Some kind of silly contrived date, but it's time pressure, nonetheless. Right? Uh, you have to be able to grapple with that as an engineer. Yeah, that's

Don Hansen: 7:15

that's I struggled with, um, for a while. And it's, um, I think like a lot of aspiring developers are probably worried about, I know this time pressure exists. I've heard about it with software engineering and what if I do get hired, there's going to be due dates and, you know, especially with aspiring developers that don't feel like. Can contribute something worth value. A lot of people that do get hired and still like have loads of imposter syndrome. Um, I know a lot of aspiring developers are worried about that. Uh, me personally, I think you do get comfortable with that over time. Um, and especially if you had

Dan Pickett: 7:54

an

Don Hansen: 7:54

old job in your industry that had tons of time pressure, it's something that could kind of, um, get you to, um, get a little bit more comfortable with that. But for those that, um, do have tons of here, what do I wanna ask for those that are afraid of that, that feel like they're kind of afraid of that pressure? What would be like the one piece of advice you would recommend for people going into their first position to be able to deal.

Dan Pickett: 8:25

What a great question. So, in my opinion, like you said, over time, you get a experience with this. And historically as software engineers, software developers, we're terrible at estimating how long it's going to take us to do something, right. Like we're just, we're just so bad at it. Right. Um, and, and so, uh, most savvy software engineering groups and businesses, um, know that there's definitely uncertainty and that schedules are likely to slip and a good, um, mentoring development organization is gonna encourage you to add a little bit, uh, of extra time to account for uncertainty. And I think your job when you're just starting out as a software engineer, is to play that game and flex that muscle and exercise that muscle as early as possible. Right. So, uh, whether you're in a bootcamp or you're studying on your own. Actually sitting down at the, at the keyboard and saying, okay, I think it's gonna take me 90 minutes to get through this challenge and actually go through the exercise of like, trying to outline your approach to the solution. Um, not necessarily coding it all out and then measure, uh, up against how you did against what you estimated. It's never too early to start that process and start exercising that muscle. Cause that is just so critically important when you get into the real world is to be able to kind of get within the realm of, you know, in order of magnitude of how long something's gonna take. So the better you get at sort of being able to analyze a problem, break it down into small steps and then say, okay, within, you know, a four to eight hour range, this is how long I think it's gonna take. That's a very essential skill for today's software developer.

Don Hansen: 10:12

Yeah. That's really good advice for aspiring developers that want get a little bit more accustomed to that. You do you feel like. last question with this one. Do you feel like you can practice that as you are learning how to code? Is that a skill that you can build up before you actually get a full-time position?

Dan Pickett: 10:31

Yeah, it's a great question. You know, a lot of the challenges and exercises, especially in the early days of, uh, learning to program are a very contrived and B like kind of in short duration, you know, something like 10 to 12 lines of code. So it might be a little premature to start there, but once the challenges and the exercises get a little more meaty, uh, I do think that there's the possibility of, um, providing yourself with a little bit more concrete of time bounds. So one of the things that we do as software engineers is. We kind of supply a best case estimate in a worst case estimate. So even going through that process of saying at the, at if nothing gets in my way, I, this will take me 20 minutes. If I run into some snags, I think at most it's gonna take me 90 minutes. Even determining those bounds, your men and max time values is, is a worthy exercise. So I would do that, um, as early as possible. But the other thing is, is while you're learning to code, there are other areas of life where you can kind of exercise this as well. Um, I, I love to work out my yard, right? So, uh, I, now I'm terrible at estimating how long something's gonna take in my yard, ironically, but I do kind of try to say, okay, I think that, you know, it's gonna take me 90 minutes to rake these leaves. And maybe you practice that decomposition and you say, The front, yard's gonna take me 40 minutes, the side, yard's gonna take me 30 minutes. The backyard will take me the balance of that time 20 minutes or so. Right. Um, but again, like if you can translate what you're doing as a software engineer into something that is a little bit more complex of a project that doesn't necessarily require a coding, that's still a very worthwhile skill to cultivate.

Don Hansen: 12:15

Okay. Yeah. It's really good advice. I like that. All right. I know you had a couple other points. I'm

Dan Pickett: 12:20

excited to hear him. Yeah. So, you know, I think the, uh, the other thing around, uh, deciding if you want to become a developer, I just really wanna drive the home the point, please, please, please. Don't make a career change exclusively for the money. Um, yes, you can have a very lucrative in rewarding career and software development, but don't just chase the salary. I have a, I have a cliche that I like to share all the time of, uh, life is too short to hate your job. Right. We spend so much of our life working. Um, and, uh, you know, even if, uh, the career vacation that you've chosen, uh isn't as financially rewarding, but you enjoy it. You know, I, I think you should really look at, okay, how do I maximize my earning potential in the field that I'm in? Um, how do I, uh, uh, compliment that or supplement that income with something else, right. Um, don't just go to software engineering because you heard software developers make a ton of money. Um, the reality is most discerning hiring managers can assess that out pretty quickly, right? If you're, if you're chasing the salaries and certainly from an admissions perspective, Uh, discerning boot camps at boot camps and boot camp admissions. Folks can really tell that as well. We wanna see insatiable curiosity. We wanna see a desire to be a craftsman and a professional software developer, right. Um, and in an energy and an enthusiasm for solving problems. Um, and if that doesn't show, um, either when you're in the learning or when you're more importantly looking for the job, a discerning hiring manager is gonna see that pretty easily.

Don Hansen: 14:02

I like that. Um, I, I like that you emphasized, you know, if you're doing something you love, but it's not paying well, figure out how to up your earnings basically. Um, and that you, you can give advice, like whatever industry that you're in. I mean, I make extra money from consulting right now and, and helping other software engineers. Like I figured out ways to make additional income on top of being a software engineer, but I could have done that. I was an aquatics director a while back and I could have, um, I could have taught private lessons. I could have trained instructors. I could have trained lifeguards and different people. Like I could have made extra money on the side. And I actually had those opportunities. I was just overworked. So I didn't do it, but you know, that's, that's interesting. Cause I like that idea because whatever profession you're in, you have this like something really valuable. It's your expertise. It's your knowledge that you can now teach people on the side. You can make extra income. So, you know, a lot of people, well, a good chunk of people do try to switch to software engineering for the money and. You know, give them that extra solution. You don't, you don't have to switch for that money. I like that though.

Dan Pickett: 15:10

Okay. Yeah. And it doesn't, it doesn't have to be like an immediate cutoff too. Right. You could, um, develop the skills over time and find a way to have it compliment your, your already, uh, establish credibility in another field. Right. For example, uh, you said aquatics instructor, right? Aquatic,

Don Hansen: 15:31

aquatics director, so, oh, okay. Um, different positions.

Dan Pickett: 15:35

Yeah. Um, so you could have learned how to build a website for folks that, uh, offer those kinds of services. Right. And kind of made building blocks towards becoming a software developer while not having to do the hard cutoff. Right. Um, and we always really try to encourage folks to harness and leverage their preexisting experience. And how do you combine that with software development to make for something like super exciting, right. Especially if you loved your vocation before you decided to switch your career, how can you combine that experience with what gets you excited and out of bed in the morning? Yeah, I like that.

Don Hansen: 16:13

Yeah. That's good advice. I like it.

Dan Pickett: 16:17

You know, so I, you know, I think that the executive summary kind of TLDR on this one is, is take up coding. If you like solving problems and you have this kind of insatiable curiosity and you like to tinker and kind of break things down and analyze things. Um, that's really, uh, I think the essential skill, um, and the, the items that I think you should kind of have some pause and, and some, some thoughts over is. That idea of uncertainty. And again, like you, you totally nailed it. That imposter syndrome of feeling like I'm not a good enough software engineer. We, we deal with that. I've been coding for 20 years. I deal with that every day. Right. Um, how do you deal with that? Can you cope with that? Can you establish healthy, uh, ways to combat that internal monologue? Right. Um, those are the things that you really need to look at before you even start to write lines of code.

Don Hansen: 17:55

Pastor syndrome is a tough one. It really is. Um, And it it's, it's so tricky because it stems from, in my opinion, it stems from a lot of different, um, a lot of different habits that have been brought from other, um, industries as well. But, you know, um, you had mentioned this idea of you need to be like insatiably curious, uh, and you had mentioned some qualities that you should look for in software engineering when people are kind of like learning how to code, how do they, how do they overcome that imposter syndrome and start identifying traits in themselves that would indicate that they might really like this profession. I know you

Dan Pickett: 18:38

talked on it a bit, but if you could expand on that. Yeah, great question. I, I think the number one thing is find some other folks to commiserate with as, as terrible as that sounds right. Like I think, uh, particularly as adult learners, right? We have this expectation that we're just gonna immediately get it, you know, and everything's gonna just, I'm gonna, the, the, the it's gonna go right for my brain into the computer and it's, everything's gonna work flawlessly. Right. Um, and we see that in other adult learning pursuits, learning new languages, um, learning new technologies that are gonna, uh, help us, uh, in the work that we do already. Right. Um, there's this desire in this expectation that. It's just gonna be instant. Right. Um, and I think having other folks alongside you, having a community, like the audience that you're building, um, is so, so vitally important because it's kind of a sanity check and being like, oh, wild loops are kind of tough. Are you having trouble with that? Oh yeah. Yeah. Actually like I, I crashed my computer the other day in an infinite loop, you know, just having that, um, ability to normalize it and normalize that perspective is, is very important. And then I think the other thing is, um, to have models, right? Uh, folks that look like you and, um, have the backgrounds that you have, um, to look at and, and look up to and say, Hey, if they could do it, I can do it. Um, and thankfully that situation is getting a lot better in software engineering nowadays. Um, particularly as a result of, um, a lot of like the workforce development and, um, diversity things that are happening in the industry. , these are all super, super positive, uh, in allowing folks to kind of, um, be able to identify with practicing professionals, which I think is, is a really important aspect of, uh, diminishing imposter syndrome. I

Don Hansen: 20:32

like that. Yeah. Kind of just getting into the weeds of things, understanding, and I think. As individuals, at least for me, like, I'm really critical of myself. And I'm like, how couldn't you learn something like that? Why can't you remember something like that? But when you do talk to other aspiring developers, they're like, they're thinking the exact same thoughts. They're struggling on the exact same things. Um, and it, you know, it, it's also great to kind of just have role models to like when you have that vision and you see that person of who you can be eventually like, um, especially like I highly recommend get mentors, get people that you can look up to, um, that resonate with you. Um, yeah, I. I agree with a lot of that. So, you know, a lot of developers, um, I always encourage people to aim for the self-taught path. I always encourage them to, especially just to get exposure, see if they like it, especially before they dump money into any, you know, uh, high cost programs. So, um, but you know, coding camps tend to speed that up. Um, but there are a lot of, I mean, my whole channel's based on catching a lot of coding, boot camps that kind of advertise things they don't necessarily deliver on. Um, but there are some good coding boot camps as well. And so a lot of people are considering coding boot camps. It speeds up the process. It gives you structure, um, gives you people to work with. I mean, there are a lot of advantages that come with it, but how do you decide if a coding bootcamp is right for you? If that's the path

Dan Pickett: 22:02

for. Yeah. Wonderful question. And, and you nailed it, right? It's about acceleration. I, I really don't want to be a bootcamp founder that comes on and says, you can't do it by yourself. It's impossible. Right? Like that's not the case. Right. Um, the reason I became a web developer is because I wanna make information freely available and, and out there for the world. Right. Um, you can go it alone and you can be successful. Uh, you know, I think the question that you need to ask yourself, How quickly do you wanna move? Um, and what support structures do you have in place to make sure that you're learning the right things at the right time? Right. Um, so I think that those are the things that, uh, boot camps really allow you, um, to gain efficiencies in is, uh, a, it concentrates a lot of learning in a short duration, um, and B uh, it connects you with sort of the right sequence and the right chronology of, uh, what technologies to learn first, second, or third, or what techniques to learn first, second or third. Right. Um, so I, you know, to go back to your, your previous point of having a mentor, I just think that that is so critically important for independent learners. Um, if you do decide to go the independent route, it's so, so important to find somebody that's working in the industry to help guide you. Right to help show you the way, uh, and identify what skills you need to learn for a second or third. Right. Um, and that is also very important when you're on the job hunt, right? Having that mentor that can, um, introduce you to associates and people that they've networked with as practicing professionals is really important to getting your foot in the door, right. Effectively boot camps just provide you with a mechanism to, um, bottle all that up. Right. And, and invest for that, uh, and buy that bottle and realize that outcome. Right. So, um, it's either a question of, you know, do you want to extend out the timeline, uh, and. Um, exercise some of your resourcefulness in terms of networking and reaching out to people and finding somebody, uh, that resonates with you as a practicing software engineer in making sure that they have the time and the bandwidth to support you in your own journey. Right. Um, if you are able to do all of those things, you can safely go it alone, but a bootcamp is kind of a, a proven path. Um, now a proven path and it wasn't, it wasn't so, so long ago, but, um, for having immediate access to mentorship, having immediate connections with hiring managers that want to give you your first shot, right. It's just a, um, we have a lot of gamers, uh, that are, that come into our, it's a cheat code, right? It's just like a, a quick way to get into the field and inject yourself into the industry.

Don Hansen: 25:00

So, um, how do you. So you had mentioned some ideas of why coding boot camps might be a good fit for you, like acceleration, like mentorship, like this, uh, progressive structured learning. And it's all kind of just laid out for you, um, who wouldn't this

Dan Pickett: 25:20

before? Great question. Yeah. I, you know, I think the biggest thing for me that we look, uh, at, in the admissions process, um, is how do you deal with overwhelm and how do you deal with uncertainty? Right. Uh, but overwhelm, I think is on top of like the critical traits for a software developer, the folks that are, uh, good fits and ideal fits for, uh, accelerated learning programs is they are okay with that sense of being overwhelmed, uh, and kind. Drinking from a fire hose of knowledge, right? Um, the programs are designed to be unsustainable by design, right? It's an 18 week immersive experience. You know, most programs are gonna require 50 or more hours per week for you to get the most value out of the program. Um, and it's gonna be overwhelming and there's gonna be emotional moments and frustrating moments along that way. Um, so, you know, if you're considering a bootcamp, but, um, maybe often felt overwhelmed in your academic career or often feel overwhelmed at work. Right. Um, that would be, uh, something to think about is okay. An accelerated learning program, uh, a bootcamp is going to, um, really, really dial that up to a 10. Right. Um, how would that make me feel? How, what am I, what strategies am I gonna employ? Um, when I feel that that sense of overwhelm, right? So, so that's one area to visit. The other unfortunate thing is, is can you manage it financially? Right. Um, I I'll be the first to say my program is not cheap. Bootcamp programs are not cheap. The average bootcamp is somewhere around $14,500. Right. Um, can you, uh, take that financial, uh, hit? Right. A lot of folks are not in that position. Uh, so you have to really plan, uh, for financially. Um, and we just recommend, you know, its so important that um, you have your finances in order and you're not stressed out about that. Because the academics in learning and trying to acquire your first job is gonna be stressful enough as it is. So you really have to be in a good financial position, uh, to make this move. Right. And what a lot of people don't consider or think about is, yeah, the tuition is one thing, but it's also, you can't work while you're on the on-campus portion or the immersive aspect of the program. Right. Um, so you have to account for that loss of income as well. Usually most programs it's like eight to 12 weeks that literally you cannot work. You, you cannot work while you're going through this. Right. So. Um, you, you need to make sure that you account for that as part of your overall financial plan as well.

Don Hansen: 28:14

Yeah. Um, you know, I'm glad you really emphasized that. And even when you graduate, um, you still are looking for a job, you know, usually for several months, can you afford all of your bills during that? And some, you know, a lot of ISA contracts will limit you from even getting a job at all. It'll trigger it as well. So if you feel like, oh, I'm just gonna go back to work. Um, well maybe you, you might have a, you know, a 600, $700 bill every month on top of that. It's um, but yeah, I've really. Generally think a lot of people that get frustrated with the coding bootcamp experience, they are overwhelmed sometimes. Like they just don't handle being overwhelmed with, uh, very well, but that financial pressure is such a huge weight. And I don't actually think most well, most people that feel overwhelmed, they prepare well for it because I mean, coding bootcamp, like you said, it's, it's meant to be, um, incredibly intense and something you probably can't keep up long term. It's, it's a condensed, um, intensive learning. And to have that financial pressure of like, how am I even gonna afford rent once graduates, I need to get a job within a month. I need to get that job or else I'm screwed. Like that's. That's a lot of

Dan Pickett: 29:34

pressure. Right, right. And can you imagine you put your life on hold you're in week five of a, of, you know, a 10 or 12 week immersive experience you're not doing well and the rent check's gonna be due a week after you graduate. Right. That the immense pressure that, that will put on you. Um, and, and so what we wanna make sure is, um, when folks make the investment and, and want to make the switch with us, we wanna make sure that they've got good financial footing. Right. I, I just can't because we don't want that to be a distraction for the learning. Um, it's just so vitally important.

Don Hansen: 30:10

Yeah. I agree. Um, how, I guess this is my own curiosity. How do you go about figuring out if someone doesn't handle being overwhelmed very well, because sometimes like, for me, for an example, like I still get nervous in interviews. I remember applying for Twitch. Twitch was my dream job. And, um, I blanked, I didn't know a thing about react, even though I worked with it every day. I didn't know a thing about react in that interview. Um, and I, I definitely got nervous in that interview, but generally as a software engineer and just learning as a software engineer, I had much more confidence. So for people that are kind of just nervous in. Interviews, you might do like a technical screening or something like that. How do you distinguish between just being a little nervous and just not handling overwhelm

Dan Pickett: 31:01

very well? It's a good question. Um, you know, I, I think when I'm, when I'm interviewing developers, I'm not necessarily qualifying for that just yet. Usually I, I kind of discover and discern that as part of like the probationary period in the first couple months, you know, is kind of, um, give them some uncertain work and see how they manage it and see how they manage my expectation as an engineering manager. Um, how long things are gonna take and how they deal with, um, sort of like getting thrown into new technology and a new platform and a new team. Right. Um, definitely sort of discern that, um, uh, in the first three months when they're on the job, um, for us, uh, in, in boot camps in general, I think there's often, uh, pre-learning or prerequisite programs, uh, that require students to, um, be thoughtful about how they're managing their time, uh, require them to be intentional about planning, right? How much time they're gonna dedicate to studies and ultimately how they're gonna do with the way in which we teach. Right. Our, what we call our pedagogy, our way of teaching them, uh, new material. And, uh, we can actually very quickly kind of determine who's gonna do really well, uh, in the immersive, in intensive portion of the course, and who's gonna need a little extra assistance. Um, and we obviously try to intervene as quickly as we can on the, on the early side of that, right. To help them with study skills and scheduling and things like that. Um, so for us, uh, the pre-learning program, the prerequisite, what we call ignition, um, that is an area, uh, where we are able to sort of assess how students do with overwhelm and how students do with us throwing, uh, a lot of new information at them. Um, so, so I think the answer's a little bit different. Uh, if I'm looking at it from the, from the lens of a, of a bootcamp founder versus an engineering manager, You know, I, I think that the unfortunate reality in, in what is, everyone's so afraid to talk about, the way that we qualify engineers is, is so terrible. Like I mentioned, we're bad at estimating. We're awful at evaluating engineers. Like the, the way in which we interview is so horrendous, especially for folks that, um, are suffering from that imposter syndrome. I, I just, I, I really think as an industry, we need to look at that in the way in which we evaluate engineers and, and seriously, seriously refactor it. Um, the whiteboarding challenges, the algorithm challenges, um, all that stuff. It's not what we do on a day to day basis. Right. So why are we qualifying people in this way? Um, so, you know, I, from my vantage point, if I really want to qualify how somebody does, uh, in uncertain situations, I'm gonna put them in an uncertain situation and I'm gonna actually let them have, uh, a keyboard and Google and research and do all the things that software engineers do. Um, so that I can truly evaluate what they're gonna be like as a software engineer. Um, so our favorite way to do that is just to pair with them, right. Just pair, uh, and work on an interesting problem together and see how they do. Yeah. I, um,

Don Hansen: 35:00

I like that you had still mentioned. you want to put the interviewee in an uncertain situation. You still wanna determine how they handled that situation, but also, um, give them the tools to be able to succeed in that situation. Look things up if they forget. Um, I like that. I think you're gonna get a lot of, uh, uh, brownie points for the people watching for that one. Uh, okay. So I'm kind of curious just to dive into this. Um, so we talked about like, first of all, what, like, how do you determine if you are kind of meant to be an engineer, if it's a path for you and, um, also, you know, boot camps are an expensive route. Um, how do you determine that that's worth what it costs and if a bootcamp is gonna be right for you. So let's dive into our third topic. Um, For entry level developers for aspiring developers that are struggling to find a job, um, what are they doing to sabotage their chances of finding that job?

Dan Pickett: 36:08

Oh, man. The, it it's unfortunately a long list. Um but, you know, I think the, the, the largest thing that I see, um, is not bringing focus to your coding portfolio. Right. Um, so a lot of folks will have like tutorial repositories that are like 25 to 30% done. Right. A, a discerning hiring manager is going to look at your example, repositories. Um, we have hiring managers and this, this is a practice that I do. I will clone your repository and try to install it and get up and running. Right. Um, it's gonna indicate to me whether you are a craftsman and what the work you're putting forth. You do, you take pride in it, right. Do you, do you, do you, uh, really honor the craft. um, are, are you putting your best foot forward and representing the way in which you code? Right? It's gotta be professional. It's gotta Belin. It's gotta have some unit tests, right? There are some things that we want to see as hiring managers, um, in those repositories. And I think a lot of engineers, what they, uh, or aspiring engineers, what they, what they try to do is they, they try to cast a wide net and demonstrate a lot of breath. Right. So maybe, uh, you studied react and you saw a job application or a job bra that required angular. Oh, okay. I'm gonna go read, I'm gonna go read a tutorial on angular and do an angular. And I'll put that, uh, repo on my GitHub profile. And ironically for me, what that indicates is a total lack of focus, right? Um, Wait a minute, you, you studied react and all of a sudden you have this angular example repository that you worked through at like 25% or 30%, right? Why didn't you just intensify your efforts in react, maybe pick up Redux or demonstrate the use of a conduct, uh, context, or, um, maybe work with Apollo or some of the more advanced react libraries, right? Like why this shift to angular. So we see a lot of that. Um, and in, in both, um, uh, entry level engineers, but mid-level engineers as well of kind of just kind of having this example code base up in your repository. Really has no anchor to, it has no finish line on it. Right. And it's, it's like, okay, well, I mean, did you kind of just fork somebody else's repository just to like pull it up, right. What did you actually do meaningfully in this repository? So in my opinion, in a, in terms of a coding portfolio, less is more right. Find, you know, two or three repositories that you really wanna highlight and intensify your, your investment of time in those repos and demonstrate. Uh, what we call a T-shaped proficiency, right? So a T-shaped engineer, um, is an engineer that, um, knows a lot about, um, a small amount of, um, uh, uh, around a few things, right? Maybe, uh, I'm not the best front end engineer. I don't know a ton of CSS. I don't know a ton of react, but man, I can normalize a database and I can tune performance, tune a database. And if you need somebody that is a master in Postgres, I'm I'm your person, right? I can, I can nail that. Right. That's an example of being a T-shaped engineer. You can command your own, uh, and get by, uh, in certain disciplines. But, um, if you have a database optimization problem, I'm your professional. I can do that for you, right? Um, that gives, um, teams a lot of flexibility because you can kind of move around knowing that you always have this, this, this one sort of passion of value, uh, that, um, is gonna set you apart in the marketplace. So. Your repositories, uh, in your coding portfolio should really reflect that. Right? Um, I don't wanna see 20 repositories in disparate technologies. I wanna see, um, three really focused repositories that go into, um, a substantial amount of technical depth. Right. And I wanna see you solving interesting and challenging problems maybe with, um, GraphQL and, and maybe you had an optimization problem with GraphQL and how you were iterating through objects or paging through objects. Um, I don't wanna see 20 Cru apps. I wanna see, you know, some, some depth, uh, particularly in the area where you feel like you are the, the tall end of that T-shaped engineer. I

Don Hansen: 40:38

like, I like the T-shaped engineer concept and I would argue a lot of coding, boot

Dan Pickett: 40:43

camps that I see

Don Hansen: 40:46

teaching multiple stacks. I think they tout, like, we're trying to teach you how to be a T-shaped engineer and you, we are gonna show, uh, depth in your projects, but often like the timeline will limit them. And they're just learning, you know, multiple stacks they're learning. I've had coding boot camps, that'll teach multiple frameworks just to give you exposure. And it's like, then when I talk to these graduates, they don't really know much of react or angular. And it's like, this is kind of a yellow flag. So now they have to spend this extra time to dive into it, really understand it. Um, that's a real problem. And I think a lot of educational platforms try to. Um, spread people too thin. I almost think there are some programs that teach developers, like, just learn as much as you can just learn a second language, a third language it'll get easier, which is true. But like often the way it's structured there, there's no depth in knowledge taught with some of these programs. It's always been a concern of mine.

Dan Pickett: 41:42

Yeah. It it's pretty baffling to me. Uh, if you look at some of the syllabi out there, right. Of like, oh, we teach you me and then we teach you angular, and then we teach you Redux. And it's like, How do you really achieve a, a level of depth in any of those disciplines in an 18 week program? Right, right. Um, yeah, it is. It's, it's pretty fascinating and, and kudos to them if they're able to, to do it. You know, I, I think our perspective is, um, my job as, uh, somebody training early engineers is to give you enough understanding of these technologies and a discreet list of technologies. Right? Give you enough to determine where you want your, your tall part of the T to be. Right. Um, so for us, um, you know, we can pretty quickly, uh, represent, okay. Front end seems to be your bag, right? Like CSS, uh, HTML. You've got sort of a good design sense. Why don't we make, why don't we invest in that area in postgrad, right. And really spend some time in this area. Cuz you seem passionate about it. You seem like you have great skills in that area. Other folks that might be, I don't want to touch CSS with a 10 foot pole, right? Like, uh, and they're focus on back end in, um, database optimization and object oriented analysis and design. Right. Um, and, and what my, my hope is coming out of a program like ours or, uh, a period of intense study, if you're doing individually is you at least have an understanding of where your interest is, right. And where your passion is and where maybe some of that natural, innate talent is. Right. Um, and to have enough exposure to all these different technologies, um, and frameworks and in aspects of software development to be, um, what we call consciously and competent. Right. Which is, I know that I don't know everything there is to know about. Databases and performance tuning. Um, but, uh, it's an exciting area of study for me and an, an exciting area where I'd like to grow professionally. If I, if I can have our grads kind of come out of the program with that sort of perspective, and it is an informed and consciously incompetent perspective that that's, that's a plus for me. I, I think that that's a, a really great, uh, thing to be able to come out of an accelerated program with is at least an understanding of how you wanna slant your proficiency in the industry.

Don Hansen: 44:04

I like that. I really like that. I think that's great advice. What else. I wanna hear more from you.

Dan Pickett: 44:11

Ah, yeah. So, you know, going back to the repos, like the basic stuff, right. Uh, do you have a readme, do you have instructions on how to get installed and up and running? Right. Um, do you have CI set up GitHub actions is free for most, for most folks, right. Um, you know, like you wanna see that craftsmanship and that, that desire to, uh, achieve software quality. Right. Do you have a linter set up? Are you linting your code and, um, is CI reporting on issues, uh, when that comes up, like these are sort of like the, um, uh, the price of admission, so to speak, right? Like if you wanna get past the gateway, uh, and get the interview, these are the boxes that you want to kind of check off. Um, and again, if you're doing less repos with more intensity, this should be relatively easy to do. Right. So, so don't shoot yourself in the foot by not having those bare essentials. Right. Super, super important. The other thing in those repositories that I wanna see is how are you handling your edge cases? Right. Um, so for example, let's say you're, you wrote an app that interacts with Yelp API, um, tends to be a popular one in the example, apps. I don't know why, but, um, you know, or the Google maps, API or something like that. Right. How does your app perform when those services are unavailable? If I turn my wifi on, uh, if I turn my wifi. And I pull up your app locally. Does it still work? Right. Um, and how does it manage, uh, outages and services that are down, right. A lot of folks forget to handle those edge cases. Um, how are how's your schema set up? Right. Like if I delete, uh, a child record, uh, no, if I delete a parent record, uh, does, does like the destroy dependencies, does that kind of match up, do you end up with database corruptions? Right. So, um, I think what discerns a junior engineer from a mid-level is really handling for those edge cases and those performance, uh, in those, um, uh, sort of, uh, integration points, right. In thinking intelligently about how to handle for those exceptions in those edge cases. So, um, that's sort of a little bit of a deeper dive, but that's important as well. Um, so, you know, I think that's, that's really it on the repository side, but, um, I really just wanna emphasize good hiring managers are looking at your GitHub profile, right? They're they're looking at your code, they're pulling up, uh, your example, uh, code bases. They're looking for technical death, super, super important stuff. And unfortunately that is just like the bare minimum. That's where you need to start. Right. Um, and that's what will get you the phone screens? I think, um, a lot of bootcamp grads, uh, and, uh, self studiers, think that it's all about the tech, right? Um, once you have those repositories in place, you have to have that conversation, right. And you need to be able to indicate, um, who you are as a professional. Right. And I, I think, uh, when oftentimes, uh, an aspiring engineer. Ha checks off those repository boxes. They haven't really thought out. Um, what are some professional stories that I can draw from that indicate how I deal with an uncertain or tough time at work? Right. What are some, uh, prior experiences where, um, maybe I received some harsh, uh, in constructive criticism. How did I respond to that? And how did I turn things around? Or how did I improve things? Right. Um, these are things that are gonna come up in your interviews, uh, as part of assessing whether, uh, a team wants to work with you ultimately. Uh, so don't discount, uh, the importance of being able to have those conversations in being able to tell that story, right. Um, You have the code, that story, the, the, the, the way to get your foot in the door and then the anecdotes and the stories and your likability is what's gonna ultimately get you into the final rounds of interview. Right. Um, and being able to talk about the craft and talk about some of the challenges that you've run into thus far as a software engineer is so vitally important. So, um, you know, I think. in popular culture and industry, and this is changing for, for the better, um, there's this perspective that, um, you can kind of like lock yourself in a closet and be this amazing engineer, and everybody will wanna hire you just on technical prowess alone. Totally not the case. Right? Totally not the case. Most engineers, uh, and engineering managers wanna, uh, work with people that they like and people that will communicate, um, work well with a team, uh, and indicate areas where they're weak. Right? So garner those days of like that, um, that rebel coder that would, you know, lock themselves away in isolation and come, come out with this amazing product, like hiring managers just don't have any tolerance for that. Nowadays you have to be able to, um, work with people and communicate well.

Don Hansen: 49:35

Yeah,

Dan Pickett: 49:36

that's, that's all really good advice.

Don Hansen: 49:38

Um, and I think. man, soft skills can take so long to build up too. Um, I mean, it's something you really have to start working on as soon as soon as you get in that office, as soon as you're kind of aware of certain habits that you do that, um, might not be super constructive. I, I, I really like the emphasis on soft skills and I mean, you're, you're right. Like how you interact with the interviewer is going to resemble also how you're gonna interact with the team. And, um, you know, no team is gonna be perfect. I've worked with software engineers that have frustrated me, I've frustrated other software engineers. And how do we overcome that and kind of accomplish that, uh, meaningful goal that we're. All striving for it's, but it is a hard thing to build up. And sometimes, um, sometimes experience is really, what's gonna accelerate the growth in those soft skills and just taking a step back and like trying to learn from it. Even, especially if the emotions, uh, there just taking a step back breathing and seeing what you can learn from something like that. But, you know, I'm, I like that you emphasize that because that's something you can work on in your current profession as you're transferring over, um, try to recognize those

Dan Pickett: 50:51

habits. Um, you know,

Don Hansen: 50:52

one coworker that just, you always clash. Well, how do you clash? Why is that? Um, some personalities do clash, but it, it, I do feel like you can start working on those soft. Early, and I think you should as early as possible. Um, but I, I mean, like all of what you've given is it's really good advice and I'm eyeing, uh, something that you wrote, uh, not studying algorithms and algorithm complexity. Can you expand on that?

Dan Pickett: 51:21

Yeah, totally. So, um, for better or worse, and we talked about sort of how miserably broken the, the job interview process is in software development. The reality is that a lot of hiring managers are gonna, uh, have you go on a whiteboard, uh, implement a, uh, coding challenge and then talk about the algorithmic trade offs and performance trade offs of your solution. Um, so if you come from a traditional computer science background, I'm talking about, um, big O notation, um, uh, big theta, like, and being able to analyze, um, how an algorithm, uh, performs over time and how it consumes resource. Right. Um, like I said, we don't, we don't regularly think about these things as software engineers, um, in today's modern programming, like I said, computational resources are, um, are, are much cheaper nowadays. Right. And we have a lot more memory available to us. We have a lot more CPU available to us now. Um, Is it important for you as an engineer to eventually establish a strong understanding of best case, worst case performance, right? Average case performance, a hundred percent. Will you be immediately called to do that type of stuff as a junior engineer? Probably not. Right, but for better or worse, that is a way in which you are going to be evaluated as a junior engineer. You may not use it in your first or second job, but it's, what's gonna get you your first or second job. So it is something that needs to be practiced. It is a skill that needs to be cultivated. And in, in truth, it will make you a better software engineer. So it's worth doing right. Um, But we find, uh, a lot of resistance, uh, to learning this stuff because, uh, you haven't yet established enough, um, hours. You haven't done enough reps yet to really understand, um, what these trade offs mean. Right. What's the difference between a linear, uh, a linear performing function versus a log rhythmically performing function. Right. Um, and what makes those trade offs different? Um, it take, it took me many years of, uh, doing computer science in, in working to really develop, uh, an appreciation for that kind of analysis. Right. So it's, it's one of those things where, um, you have to learn it because you have to, but you don't really understand how to assimilate that knowledge yet. Right. Um, It's like anything else, it just takes practice and it takes intention. Um, so how do you go about doing that? Well, um, there are, uh, some well known, uh, challenges out there. Um, lead code, hacker rank, right? There are a lot of these sites that have pop popped up and honestly, uh, hurt the industry by continuing to proliferate these practices. Right. Um, but like, it's a thing it's, it's part of our industry. You can't educate a market, you have to embrace the market. Right. And say all. If you can't beat, 'em join 'em I know that this is like the thing I have to do. I'm gonna, I'm gonna spend some time in this area. Um, so one of our favorite resources is cracking the coding interview. Uh, there's been a few new additions, uh, over time that kind of provide you with broad exposure, uh, to this idea. Um, and there are platforms like, um, hacker rank and lead code that give you a good, uh, sort of, um, ability to assimilate some of that knowledge and, and expertise. But I would start with the book, um, and do some of the, the work there. And then, uh, go to lead code or hacker rank. I see many, uh, aspiring engineers in week three or week four on hacker rank or lead code. Like put that aside, wait, wait, and developing an appreciation for the code. And just being able to write something meaningful. The you'll you'll spend plenty of time over there in time. Right. Um, but to start to start, you know, that that book cracking the coding interview is a really great place. And then you can start to do some practice sets and really start to, um, exercise your brain, uh, using the tools like lead code and hacker rank. I like

Don Hansen: 55:34

that, you know, I. I feel like for me, it was really hard to learn it because I wasn't using it. And I remember going through my coding bootcamp and we started off with it very early. And I do think the way that my coding bootcamp did it, um, it, it did give me a better chance at at least understanding fundamental data structures and where they're gonna be used depending on the situation. Um, but I, I still feel like I didn't have this context. Like I didn't deal with any big data in any of the applications. Like I, like you said, You know, our computers have, um, really fast, uh, I mean, have a lot of computing power and a lot of memory compared to what we used to have. It's like software engineers that are building these really simple websites and trying to become software engineers. They have no context of like where any of this is useful. And so I would be interested in seeing a website pop up. Um, I actually only read long time ago, uh, a small portion of cracking the coding interview, but I would be interested in seeing a website pop up where it gives you real examples of features that you're gonna be building out with data sets that you might have to deal with and how to optimize, how you're gonna read or manipulate that data. Um, for me, I need examples like that. Um, and I'm really bad at data structures and algorithms, but do you

Dan Pickett: 56:58

feel like there, um,

Don Hansen: 57:01

there's a way to kind of integrate that, like give aspiring software, software engineers, that context. To be able to realize why these algorithms are important.

Dan Pickett: 57:14

Yeah. And I, I think that that's inherently the challenge, right. Is in order to develop an appreciation and an understanding of why these things are so important, you have to have a, a fairly intermediate level of understanding of code. Right. And how code works. Um, once you've achieved that context, then I, I do believe that a site like you're mentioning, in fact it is just like, man, that's inspiring. We should totally do that. um, is, uh, you know, having a site of like common problems that we see, um, with junior engineers, maybe not considering algorithmic complexity or use of resources and things like that. Um, so you know, the, the, the few things that just come immediately to mind, um, Is loading your entire table in memory. Um, so we see that a lot, uh, where basically you run like one big honk and select statement that's constrained or whatever. And obviously, uh, when you have a small toy database, uh, you know, with less than a hundred records, it's not gonna be an issue. But if you execute that, um, in a production environment with millions of records, you're gonna quickly run on memory. So that's one thing that, um, a lot of hiring managers will qualify for. Um, the other thing is look out for those nested loops, right? So if you have, uh, two wild loops or two, four loops, there's a good chance that you have, um, exponential, uh, uh, complexity. Right. Um, and, uh, you, you want to see if you can break out of a nested loop situation. Um, and then, you know, the other piece that I would think about is, you know, if you, if you need to consume large data sets, how can you, uh, page it or buffer it? Right. So rather than taking all of it in all at once, can you take a segment of it? Work with it and then write it to disk and then load new stuff into memory. Right. So it's stuff like that, that, um, you know, I think we could put on a website like that and kind of give you ideas and patterns of why this stuff ultimately matters. Because I think that's the hardest part for the adult learner when they're learning this stuff is they just can't connect it to how is this gonna make me a better coder. Right. Um, and I think if there are ways, uh, educators like, like myself and, and others in the industry, if we could kind of connect those dots, I think it, I think it would really help people out. I like that one goofy recommendation. And, um, I recommend this to, uh, everybody studying. There's actually an awesome Netflix series that explores algorithms. Um, it's like algorithms, the, the, uh, the solutions that shape our world or something like that. And it's really good. It talks about, um, some of the more complex algorithms that we have to deal with as software engineers. So, um, one of the coolest problems is the traveling salesman problem. Um, and they have a whole sort of, um, series about how they use bees to, uh, create, um, like a what's called a, a heuristic, uh, for, uh, solving the natural, uh, the traveling salesman problem. And then, you know, another, another one is, um, uh, path optimization for Amazon robots or warehouse robots. And they have a study of that too. And it's a really entertaining documentary. It's not, it's not boring and it's, I think less than an hour, but it's a great way to kind of get an idea and appreciation for, you know, some of these goofy things that are in cracking the code interview or might be in your bootcamp curriculum or in your self-study curriculum. You know, I, I find that this video really helps a lot of students and aspiring developers connect those dot.

Don Hansen: 1:00:54

I'm just, I'm just consolidating everything that you just said. A lot of really good exam. I think you do a great job of coming up with examples that are, um, tangible, practical and understandable. Um, and I'm actually gonna check out this movie because a big, like you said, um, data structures and algorithms, the testing of it for early engineers. I don't think it accurately represents the skill of what they can do, but it is. It's a necessary evil, right. And so, you know, it, it's kind of on, um, hiring managers in, um, educational platforms to teach how they can be fun, to give them resources, to capture their attention and get them engaged and actually interested in it. Because if you're interested in it something as a software engineer, like you're going to pursue it. You're gonna be curious about it at least enough to look into it. And if, if you can get aspiring developers to get interested in this like obscure thing that everyone says, like shouldn't be in the interviews. Yeah. It shouldn't be, but it can also be fun. It can also help you grow as a software engineer and think about your code and your solutions in a slightly different way. So I'm actually gonna check out this movie and if it's a good one, I'm gonna recommend it. So that was good. But we are over time. So, um, Dan, I really appreciate all this advice. I caught myself kind of just like, um, I know as a podcast, I'm like supposed to come up with a response sometimes afterwards, but I'm just like listening and then I'm thinking, I'm like, oh, I should respond. But like you, you have a lot of good advice and it, it shows that you have a lot of experience in the industry and it shows that you wanna help people. So I think this is gonna be a pretty valuable episode, but,

Dan Pickett: 1:02:34

um, at our outro

Don Hansen: 1:02:36

phase. So Dan, um, if people wanted to reach out to you in anything else that you have to shout out, um, what would you like to

Dan Pickett: 1:02:43

share? Well first I wanna share my email. So, uh, if anybody has any questions in follow up or wants to learn more, you can always reach me at, uh, Dan launch academy.com. Um, what I always say is, um, I really like helping people, uh, learn and discover the craft. And if it means, um, that you want to go alone and independently study. Great. If you want to, are you thinking about attending a boot camp? Great. But what I want you to do is if you're even considering it or think about it and you don't have advice, you don't have perspective. Drop me an email and I will do my best to help you. Um, um, I still, uh, read all, all the emails that I get and, um, it's one of the things that I really actually enjoy doing. So, uh, that's first and foremost, um, we are, uh, in the process of enrolling a cohort, uh, that starts in December. Uh, you can always learn more about, uh, our program and everything that's involved there@launchacademy.com and, uh, please be sure to sign up, uh, for the email list. We're gonna be announcing a pre-learning program, uh, where we teach the fundamentals of software. So if you're just starting out, uh, in your learn to code journey, we'd love to have you be part of that group. Okay.

Don Hansen: 1:03:55

I love it. Well, Dan, thank you so much for. Coming on and, and sharing useful advice for us. I appreciate it.

Dan Pickett: 1:04:03

I had a great time. Thanks for having me.