#163 Learn fewer skills but go deeper - the Caleb Curry interview
01:30:49 Share

I believe you will get the most return on your time by going deeper on a fewer set of skills and technologies.

and then spending a certain percentage of your time in the exploratory discovery of new things. Welcome back to the Free Code Camp podcast, your source for raw, unedited interviews with developers. This week, we're talking with Caleb Curry. He's a software engineer and prolific computer science educator, and he recently started mentoring dozens of developers on

and helping them with their skills and their careers. We'll talk with Caleb about his experience getting laid off as a developer and how he went about landing a new developer job. Support for this podcast comes from a grant from Wix Studios.

Wix Studio provides developers tools to rapidly build websites with everything out of the box, then extend, replace, and break boundaries with code. Learn more at wixstudio.com. Support also comes from the 11,348 kind folks who support Free Code Camp through a monthly donation. Join these folks and help our mission by going to freecodecamp.org slash donate.

For this week's musical intro, with yours truly on the drums, guitar, bass, and keys, we're going back to 1981 with the Arcade Smash Galaga's end theme. ♪♪♪

Caleb Curry, welcome to the show. Happy to be here.

Yeah, man. We have been longtime admirers of yours. And of course, all the way back since, what is it, 2018, you published this database design course that set the world on fire like a lot of people from utility in that course. How much has changed in database design since that course was published?

It's a great question. I mean, honestly, with that material, I would say it's all still valid with relational databases. So I still think it's one of my best videos I've made. Awesome. Well, we're going to drop that in the video description if anybody wants to check that out. If they have eight hours to learn database design, why not learn it from the best? But you and I, we've kept in touch, and I've enjoyed following your adventures over time. And...

I understand that a while back you got laid off from your software engineer job. Yeah, yeah. I'd love to talk about that and talk a bit about some strategies to finding roles. So for full background, it was a developer relations role, which had some software development components to it, but also a lot of communication with customers and people wanting to integrate with the software. So

Uh, that's something where I did that for a number of months and then I was told that, Hey, being laid off, which is something many people encounter and have to go through. So I wanted to talk a little bit about, you know, strategies to make that better. Just learning from what I went through. Uh, I would just assume that it's part of the career, right? So, um,

Not to take it personally, it doesn't necessarily mean there's a problem with your skill or the value you're providing. Sometimes companies just lay people off. So for me, it was a situation where I think it was bad timing for me. I just had a baby, so I was still on parental leave. So it was quite stressful when it happened. And I also...

just wasn't, you know, as prepared as I could be with the finances. And, you know, I didn't know how long it would be. Fortunately, uh, companies will usually give you some kind of severance to buy you some time, but ideally you can, um, be prepared both financially and just with your skills so that if you have to go interview, you're ready to go. So, um,

I personally have taken an approach to finding roles that really focuses on networking and the connections you have with people. Yeah. As opposed to just like cold applications to jobs. And most of my work has been in really small startups. That...

for me has given me the ability to, I guess, uh, bring unique skills or value that can be seen a lot easier for a small startup compared to going to like one of the big tech companies. Yes.

But I think either way, there's skills that will be valuable for both. But I think the approach can definitely be different. Yeah. And so your approach was not to go, okay, well, I'm laid off. I've got some severance. I've got a new baby. I need to go get a new job. And your approach in that moment was not, okay, let's start grinding leak code and applying for FANG jobs.

Yeah, I didn't really go that route. If I was to go try to get a role at a big tech company, there would definitely be a stronger focus on leet code and system design and some of these typical interview categories that you'll have to go through.

These can definitely still be a thing for really small startups, but I think if you find a company that's really niche or really focused on a certain thing, they're going to care a lot more about applied skills and your ability to provide immediate value on whatever they're working on. So the company I was laid off from was doing stuff with zero-knowledge cryptography, which is a really niche thing that

most people don't even know about unless they're in that world. So I had skills that were very valuable to companies that do that thing. So that was really my, uh, my approach. It was like, I'm going to find some really specific companies looking for skills, uh, in, in this area. So I have a, a, an advantage over other people that are applying to

And really, I think you had the specialization. Sorry, I didn't mean to interrupt you. You have the specialization. So why not apply that specialization and press your advantage? It's kind of it sounds like that's how you were thinking.

Yeah, yeah, that was really my approach. And then as for actually finding interviews and companies, that was all through LinkedIn, networking with people, recruiters. I didn't really apply to like a bunch of companies on their websites. Like I did some, but I've really found that the networking and having a strong strategy for that really goes a long way.

I don't know the exact numbers on this, but I would say that the majority of roles are probably filled through some form of networking or connections, even though, you know, those are probably harder to come by. So basically, sorry, like the they're harder to find sometimes because, you know, they might not be posted on on a Web site. But if you if you know the right people or you communicate well, then you can find those opportunities there.

and have an advantage i would say yeah well can you walk us through like okay the experience first of all the more detail you can give because a lot of people listening to this maybe they have been laid off but some people haven't and most people probably at some point in their life will be laid off from some company or another along their journey um can you talk about like what the the experience was like and what the what the process was like

For people who haven't been through it, I understand it's not the most pleasant thing to recollect, but it would be probably really helpful for people listening. Yeah. So I would say there might be warning signs in the company. So if you're getting some signals that, hey, maybe there are layoffs coming, you're getting these signals that there could be something wrong, then...

start preparing, basically upskilling, saving up some money, so forth. For me, it wasn't a huge surprise because as I mentioned, it was in ZK, also within crypto. And at the time there was like a bunch of stuff going on with crypto that made it a little more scary for people. So I guess it wasn't really a surprise to me when I was laid off. And basically I just got an invite with...

a person or two that, you know, I've never done a meeting with. So I'm like, okay, obviously, like before I even had the meeting, I was like, obviously this is like, you're getting laid off. So it really wasn't a huge surprise for me. And I think that's the ideal scenario versus being surprised. That's why I'm telling people to assume it may happen at some point, even if

If you don't have any strong reason to believe you'll be laid off, it still could happen. And the best way to prepare for that is just to have some financial runway and to stay sharp on your skills. Don't be lazy and just get through the days of work not being ready for any new opportunities.

So I think that's probably the first thing. Yeah. Okay. So just to reiterate, having a runway. So you think of a plane taking off, it needs a certain amount of runway. Otherwise it can't reach the velocity needs to actually have lift, pick it up and take it into the air. Uh, so the other thing, just keeping skills sharp. Uh, so those are the two main takeaways, uh,

how would you go about if you were working, let's say hypothetically you were working, maybe you're like five years younger than you are now and you're working as a dev and some tech company and you do have like a pretty, you know, posh lifestyle. Like they're, they're,

you know, having occasional free meals and happy hours and stuff. And you've got like a nice desk and maybe you're even working remotely or something like that. And the complacency can creep in and you can think like, ah, this is great. Like I just have to do my job and keep my head down. Uh, like what would you say to a person who's in that position right now? Um, who thinks that like they just keep doing their job. And if, if this job disappears, there'll just be another one waiting for them. Like what advice would you give them?

Yeah, I think first realizing that there's not always another job waiting for you and having a little bit of fear. You know, I'm not asking you to go through life full of anxiety and fear, but just realizing that the scenario you're in right now might not be the same situation you're in in six months. Personally, I'm...

generally hungry for growth and skill development and opportunities. So even if I was in a role where I didn't think, Hey, there's going to be a layoff, I'm still striving to advance in my career and get those skills because I know that's what's best for me. So I think that kind of comes down to the individual to some degree, like not everybody always wants to advance and, and, and,

do extra work and like that's that's fine like we can talk about that too uh but for for what I would believe uh the most successful idea would be like get the uh skills regardless of whether you're gonna be laid off or not because it's going to help your career yeah

So I do know a few people who just like insist, like I'm, I'm an IC, an individual contributor. I have zero interest in ever managing people. I just want to go as far as I can as an IC. And I don't want to, uh, like I actively am happy in my current role and I don't desire to ascend a corporate ladder somewhere. Um, have you met people like that? Like how would you describe yourself in terms of that spectrum of like,

must reach the very top spot in the company versus like totally content where you are. Yeah. I think, uh, that probably varies over time, right? Like it changes based on the stage of life I'm in. Like when I had my baby, I wasn't really nearly as eager to grow my career. Like I wanted to spend more time at home. And then there are periods in my life where I,

i'm hungry for more and i want to put in that additional effort one thing that i think could help with this is understanding that in software software development you can go really far in your career without having to manage people i think some people want to manage people some people don't want anything to do with that

You can be an independent contributor and you can become a senior engineer, staff engineer, distinguished engineer. So there's a lot of roles beyond just, you know, an entry level developer that doesn't require you to, or roles that don't require you to manage people.

That being said, obviously responsibilities still go up as you advance in your career. So I do think there are scenarios where you just say, hey, I am content with the level I'm at. And you don't have this extreme desire to improve.

get a promotion because every promotion you, you make, you might get more money, but it also has a cost, right? There's a cost to that promotion to yourself personally. Uh, there's more time invested, uh,

More responsibility. And that takes a lot from other things in your life. So I think it's fine to say at some point, I'm good with where I'm at. I would just encourage people not to do that too early. If you're a junior dev or an entry-level dev, probably not ideal. You should be at a senior level. And you could at that point say...

Yeah, I'm good. I don't need to be like a staff engineer. Yeah. I'm just good with this level here. Like there's tons of people that will work in a solid tech company for, you know, 10 years without going to those higher levels just because they're not interested. Yeah.

I know that you have a young one now. You're a dad. And you're juggling a lot of other responsibilities. You've been mentoring dozens of developers, just kind of like one-to-one personal relationships with them, kind of coaching them and helping them. You've also been creating a lot of courses and these amazing short explainer videos on YouTube where you stand there right in front of the blackboard and you do it old school. You do it the way people do it.

People may remember like the professors doing it if they went to university. Right. And, and in this day and age with so much disruption and stuff, there's something very comforting seeing a guy and his blackboard and like answering questions and just, just talking like it just warms my heart. And I love your videos. I learned a lot from them. Yeah. Appreciate that a lot. Yeah. I love the chalkboard style as well. And there's times I've stepped away from that style, but I always seem to come back to it. It just seems to be like,

core to the way I want to teach as I think it allows you to kind of ignore some of the specifics about like correct syntax and all these things and you can just learn the concepts and understand what you're doing. Then you can go apply that to code and it just makes the experience a whole lot better. Yeah. Yeah.

Yeah, it sounds like it. So what I wanted to talk to you a little bit about is like how you structure your day. Like, so, uh, you know, after you were laid off, you went and you worked at a different company for a while and you ultimately decided like, even though that was going well, that you wanted to go back to just working for yourself. And that's an option you have, right? That, that is a privilege that a lot of people listening to this haven't built their reputation, uh, to the extent that you have and don't have like, you know,

a YouTube channel that thousands of people watch every day to learn about math programming, computer science, and things like that. But you've been doing that. You've been doing the mentoring. You've created an online course. I wanted to figure out how you structure your day and how you get so much done because a lot of people, once the structure disappears of having a boss telling them what to do and having deadlines and all that, they're productivity craters, and that doesn't seem to have been the case with you.

Yeah, this is a skill and I think it's something that takes practice. Fortunately, I think I've gotten quite good at it, but one way that makes me feel good about this and to be able to do it long-term is to not be super strict and like beat myself up about little things. Like if I sleep in a little bit later or whatever, like I don't actually have a very super strict schedule right now. That being said,

Over time, I'm very productive and the amount of stuff I can accomplish out of my own self-will, I guess, is quite high. Like, I don't need somebody to tell me what hours to work or things like that. But yeah, this is a skill and I think it's...

It's even something you should strengthen if you're working a typical software engineering role or some role, because I think having the skills of self-discipline are important and basically being your own manager to some degree. A lot of companies...

adopt this style of work where basically everybody is their own manager and they decide when they should work, have more of an asynchronous work style. And many people do not do well in that work environment because it's not typical for

But I think it's very valuable to be able to work in that environment, especially now with a lot more companies being remote and a lot of startups being completely remote where there's not even an office to go to if you wanted to. So that has been the case for me. Like the majority of the roles I've had have all been remote jobs.

I live in Ohio, didn't really have the interest in moving to San Francisco or something. Like at one point I moved to Austin, Texas for a year. Like that was fun. I did an in-person role there. But majority of the time my roles have been remote and I've had to strengthen that skill even within the job. So then going into entrepreneurship and doing my own thing,

I've already built those skills and that has helped me to continue. Like I don't need a boss telling me what to do and when to do it. So let me think I might've lost. Oh, go ahead. How would you go about getting to that level that you're at right now? Like can you trace decisions you made or kind of habits you adopted along the way over the past, you know, 10 years or so? I know you started like programming and uploading programming videos very young. Uh, and so you've kind of like your entire adulthood,

has been the computer science guy on YouTube. But I mean, it's stunning to me how much you've accomplished. And you said you're 29, I think? Yeah. Like you're not even in your 30s yet. But what were some of the decisions that you made along the way? Were there any inflection points where you're like, ah, I really got to start doing X, Y, Z? Or, oh, that burned me. Like I need to start doing this instead of this. Were there any kind of like epiphany moments that you encountered along the way?

Yeah, that's a great question. I think that I'll answer the question, but I want to mention that I think in general, I consider myself a slow learner because I will make the same mistakes when it comes to my work and how to be effective and things like this. And one of the problems I've had is

going all in with some idea and then burning out and then quitting and kind of like taking a break and getting back into it and not being very steady. Uh, that is something that, you know, I've generally struggled with. And I think people who are in general, very motivated can have that problem because, uh, motivation spikes. And then once the motivation kind of dies down, you don't have like the, uh,

the willpower or like the determination to stick with what you originally committed to. So I'm guessing that many people watching this have this same problem. And for me, I have improved that problem by intentionally reducing

Yeah.

And this, you know, you've heard these comparisons all the time, right? Like it's better to work out once per day for 30 minutes, an hour than to do like seven hours on Saturday. Right. Same idea with some principles with software development, like starting out, I would really go all in with something and then not stick with it long-term. Now my approach is how long can I spread this out and how much can I do in

per day to stick with it and be effective long term. That has helped me substantially to not feel that sense of burnout and also to have consistent progress over time. So I've taught people a lot that you should find something that's going to help you get better and do that for an hour a day.

The hour is just, you know, a number you can choose whatever amount of time that works best for you and your schedule. And this really does depend on where you are in your life. So when I was job searching, I had that very focused mindset, right? So I was studying way more than an hour per day on these topics that I thought could most likely get me a role.

However, I would still spend time on more like general things that just make me a better developer. So I'll talk about a couple of ideas of things you could do for this hour a day, as well as kind of some optimizations to help do this with work and other life responsibilities.

But some great examples would be data structures and algorithms, leak code. We've talked about that. Yeah, like doing just a problem a day, for example, over time versus doing like 10 problems a day for like a couple weeks and then doing your interviews. You want to get better at that skill because it's going to help you long term and improve.

Crash coursing, it doesn't always translate to retaining information, I've found. So spreading that out one hour per day. Or maybe that's system design. Or maybe it's not even a technical skill. Maybe it's an activity such as networking. This is something that...

people know is important, but it's kind of like, oh, how do you really network? Well, if you build a networking strategy, which I help people with then, and we can talk about that if you want. Yeah. I'd be able to hear that. Do that for an hour a day. See where that gets you.

Maybe that's practicing behavioral interviews. I'm talking a lot about stuff that helps people get jobs because we're kind of talking about being laid off and finding new roles. But it doesn't have to be job prep stuff. It could just be like advanced topics that you are not currently comfortable with that, you know, you should know. You just don't know. You know, maybe that's just

finally understanding what a closure is in JavaScript, or maybe that's understanding asynchronous programming. Maybe that's no SQL databases instead of just always using relational databases. I think if you're watching this, you probably know what that thing is that you feel you should know, but you don't know. And that's what you could spend that hour a day on to get better at. And fortunately, often it's the case that you can squeeze in that hour or two hours or whatever it might be

In the morning or even during work hours, many companies support people studying and getting better. So I've talked to many people where their company will actually encourage them to dedicate an hour to learning some skills. So you might as well do something that's going to help you long term in your skill development and in your career. So that's one tip for a kind of effectively doing that, like put it in your calendar and make sure you stick with it.

Yeah. So figuring out what it is that you know you should get better at, but you're just kind of like not sure how to go about getting better at it. Like you mentioned networking is this extremely ambiguous thing, and it's also like kind of an awkward thing. Like, hey –

I'm Quincy. How are you? You know, it's like, you can just imagine being at some LinkedIn event, uh, or, or some sort of local meetup and you've got like, you know, you're, hi, my name is Quincy, like slapped on your chest and you're like going around and maybe you're even wearing one of those awkward dress shirts. Uh,

instead of just like a normal t-shirt or something like that. And you have to like talk to people and make genuine-ish connections with them, but everybody knows they're kind of doing this dance like, oh, okay. And then you get to the awkward part of the conversation. Do you know anybody who's hiring? Are you all hiring? Yes.

Yeah. And I've seen some, like, I've just observed like being at these types of events and seeing some extremely awkward exchanges between people. And what I always think when I see those is like, thank goodness that person's getting that out of the way because they need to get through that. They need to get better at making these natural connections with people. Otherwise their career is going to be forever hampered. And so like, I'm like on the sidelines cheering them on. I mean, I, it may be awkward for me to be like,

Hey, by the way, I noticed that you had kind of an awkward conversation there, but things will get better. Keep it up. I don't necessarily say stuff like that, but that's what I think when I see someone who's having like a kind of an awkward, uh, you know, like JavaScript night. Um, you know, and, and the employers are all hanging out there. Maybe the, the hosting venue, they've got somebody who goes up there and says, anybody who wants a job, come and talk to me. Uh, that makes it a lot easier by the way, if, if there are people that are proactively saying that sort of stuff. Uh,

So just to recap, finding something that you know you need to do and doing it an hour a day and just being consistent about it, putting it on your calendar. A lot of people I've met advocate not having a to-do list but just putting things directly on their calendar because having a to-do list is just like, yeah, I should do this sometime. And there's like a getting things done methodology and stuff. There's like a book about it and like some software and stuff. And I tried that when I was first getting into software development. And a lot of it is,

there's like a someday maybe list. And that's thinking you might eventually get around to like, I would really like to learn Arch Linux someday, maybe. And then you put it on that list. But if you really want to do something, put it on your calendar, right? Like I am studying, you know, data structures for 30 minutes and I'll do it right after breakfast. So I'm still fresh. And like, I've just had my coffee or something like that. Right. Like however you want to structure it. But is, are those the types of approaches you use? Do you have any recurring approaches?

kind of like things that you're working on one hour a day or some chunk of the day? Yeah, yeah. So those are all great questions and I think you...

You really explained it well, kind of going back first to the networking is it can be awkward. So practice makes perfect. It also makes permanent. So you want to improve so that you're not just repeating the same mistakes over and over again. The same thing with the skill development. The reality is some of the scary topics that people avoid, once you actually start learning them,

and you're focusing, which means turning off your phone and turning off distractions, you actually start to understand them. And then you're like, oh, maybe this wasn't as bad as I thought it was. Why did I avoid learning about this for seven years? I don't exactly know. So yeah, like for the example with you mentioned like DSA for 30 minutes a day. Yeah, data searches and algorithms.

Yes. Yeah. Thank you for that. I would say that's going to put you in a high top percentile of people who do data structures and algorithms. In fact, I think I know a friend of mine who did this 30 minutes a day average consistent DSA practice for 100 days on on leet code. And he got a badge of 100 day leet code badge for

And it said awarded to the top 4.2% of leak coders. So you're telling me, Hey, I can be in the top 5% in only 30 minutes a day. That's kind of crazy. Yeah. It's like, it doesn't take that much. Yeah. Yeah. And I think a lot of people like I, uh, I can draw parallels to other fields that are not just software development. Like for example, I'll frequently, uh, meet somebody who's learning music and, and,

they'll just be like remembering like what fret they need to play on the guitar. Like, Oh, that's on fret seven on the D string or something like that. Or on the third string, they won't even, they just, the notes themselves are intimidating and that aspect. But at some point you do need to learn the notes, right? At some point when you're learning Chinese, for example, I've met so many people that are learning like Chinese and Japanese, which are languages that involve, you know, Chinese characters. And a lot of people will be like, Oh, I just,

I've just accepted that I'm never going to learn those and I'm just going to focus on, you know, the oral Japanese and oral Chinese in terms of like

Using like romanization schemes instead of actually using the Chinese characters. And I don't have a nice thing to say about like, it's going to be so easy. I spent the last 24 years like learning Chinese characters basically, maybe, maybe slightly longer than that. And I still feel like I'm like, wait on here. But like my skills would be just so rudimentary if I just not embraced Chinese

learning those because it's a huge part of like memorizing and it's a huge part of how native Chinese speakers learn Chinese is they actually have to learn the Chinese characters the same with Japanese speakers and like you would never go to like a musical conservatory and find somebody that was trying to you know wrote memorize which note was on which or which fret they needed to play they would just have this framework you know these 12 different you know notes the the the gosh what is it called

Even... Temperament. Yeah, like even tone temperament. I can't remember the exact term, but like all the sharps and flats and everything like that. And with...

Data structures and algorithms, it is daunting. And a lot of people are like, oh, I'm just going to learn how to do the cool projects or let me redesign my portfolio for the nth time as a way of kind of practicing while also slightly procrastinating, learning the harder stuff, like having to learn how time complexity and space complexity work.

and, you know, solving these harder, like, Project Euler problems or LeetCode problems or Rosetta Code problems. Free Code Camp, by the way, we are huge believers in, like, just doing a little bit every day. We're about to launch, like, a daily coding challenge. This is the first...

Notice that this is an early heads up for you all that are tuning into the podcast. You get the straight dope right from the drop, right from the jump, whatever the slang is. So yeah, we're going to have that. And I'm very excited about that because anything, even if it's just like 20, 30 minutes a day,

you build that muscle. Uh, you, as you said, practice makes permanent. Um, and just, just getting those reps. So, yeah. Cause I think like even going back to, to music, I mean, I, I do been doing a little bit of piano and stuff, you know, you can learn a song, looking it up on YouTube, following like the videos where the keys like fall down and hit the, I don't even know what the word for that is, but, um,

That's going to take a lot of time if you're a beginner. You might be able to pick up a couple songs and that's great. Same idea with coding. You can pick up Python, write a couple scripts, maybe automate a few things and have fun with that. I encourage people to do that. If you really want to get a thorough knowledge, slowing down and actually learning the frameworks and the approaches and the fundamentals is going to save you time in the long run. Everything you learn that

can be utilized in other problems is going to save you time. So with the music, picking up a scale and understanding why the keys in the song are being played, well, it might fit according to some scale. Same with programming, understanding

how the code is working which is a big thing with ai now people copying pasting code have no idea what is even happening overflowing steroids yeah yeah and if if you're just trying to you know throw something together and you can get it working great but if you're actually trying to learn the skill of software development then that's not really the ideal it's really just um it's delaying

The time you need to invest to learn the fundamentals. So slow down and learn those to then be faster in the long run. I remember back in college solving problems that, you know, I would spend hours on and like, I have no idea what I was doing, which I could solve much faster now because in general I have more skills. Yeah. You struggled through them and you kind of built your baseline understanding of those things and then you can just apply it. It's kind of like,

When you're first starting coding and you go to Project Willer, of course, one of my favorite ones, the website that I used for a lot of my early Python practice, just solving challenges. And even getting a few of those can be so hard. But as you get better, as you get the reps, as you kind of establish like this

this eye for different patterns that tend to emerge or, Oh, I can see where a nested loop would be the answer here. And you, once you start to learn those things and categorize those things, it's like you, instead of having to like create something from like Adam by Adam, assemble it, you, you just have like a mold and you just ready made, you know, press one out. Um, and I think that it does speed things up dramatically. And so it's absolutely worth it. And, um, yeah, like,

I have met people that have gotten very far without going back and learning the fundamentals. And undoubtedly people who are listening to this are going to find somebody in their lives who is, is,

doing like freelance software consulting with just talking with GPT and quote unquote vibe coding where they basically kind of like tell, yeah, I should do something like this. And, and their prompt will be like good, but it won't necessarily be sufficiently precise. And the next thing you know, their, their site has like some sort of vulnerability that they didn't anticipate. Or at some point, like the context window just can't hold all the code they've written and they just don't know how to maintain and extend what they've written. And it just, the whole rigmarole is,

grinds to a halt and they're in no position to be able to fix, to comprehend and fix what they have pieced together over time. Is it like you have talked a lot about AI and I want to get your reaction to what I just said and also your thoughts on using AI as a developer. Yeah, I use it. I think it's, it's something you should probably use, but it depends on what you're trying to accomplish, right? Because,

If I'm trying to learn something, I think AI can help give you suggestions, tips, direction. But I very rarely will use AI just for solutions when I'm trying to learn something. So an example might be, hey, I want to understand AWS.

Yeah, you can go on AWS's website. You can always go direct. Or you can use an AI tool and ask about, like, hey, what are the most important services I should know and why? And what order should I learn them in? Could you also compare these to the Google Cloud Platform equivalent or the Azure equivalent? Learning the landscape and exploring is where I really think AI shines. I also think it will do you wonders for things like

Hey, I have this code in Python. I understand it, but I need to write something in C sharp. Can you explain how to translate it versus, you know, having to learn a language necessarily from scratch? So I think it's really great for translating. And in that situation, you can learn a lot faster because instead of seeing every new project or new language or new thing,

some new thing you have to do. It's really just a diff from something you already know. So you just have to think of like what you know and then how things are different, which helps you learn things a lot faster. So that's how I would utilize AI. If you're a beginner and you're learning, I would not use, at least right now, like that's my opinion as of today, ask me tomorrow, but I wouldn't use Copilot or any of these tools that will

basically help you write solutions live while you're coding. It's just going to allow you to not learn those things yourself. And I just, I'm not to the point where I think that's a good idea.

So when you're actually building software, yeah, maybe those tools can help you come up with solutions faster. Yeah. Because at that point, you already understand what they're doing and you can fix issues. Yeah. I mean, it's kind of like using Google Translate when you don't know a language versus using Google Translate when you do have at least a cursory grasp of the language. You're using that not to just communicate really quickly and yeet a response over to somebody via email in their native language, but you're actually...

using it to better understand this piece of native text that you've discovered on the internet somewhere. And like, okay, like, uh, what does this word mean? Okay. This is an interesting usage structure. So you're actually, yeah, it's helping you get what you want. Um, you know, the AI may be creating, you know, a function that actually does make sense and it is, uh, good enough for, to suit the purpose, but you'll actually be able to evaluate it and potentially learn from it in the, along with producing that artifact. Uh,

So I love the idea. And what you said, you've got a very moderate approach to this. You do use it. But at the same time, you discourage people from using it early on. And that's something I've heard many experienced developers say is that the worst thing you can do, maybe not the worst thing, but one of the worst things you can do to a new developer is like, hey, here's this new tool, Cursor or Copilot or...

like drop them in and just say like, all right, just type what you want and it'll come with code. Okay. Now does this go look good? Like, I don't know, I guess. And they just are slapping stuff in and building the Jenga tower. Right. Yeah. Um, so I, I definitely, that resonates with me. One thing that you did say that I think extends more than AI tools. And I do look at AI tools as a tool. I don't think it's the be all end all, you know, like,

Game changer. Almost everybody I talk to uses AI tools as a developer and maybe gets 20% to 30% more productivity as a result of these tools. And I see you nodding your head. For those listening to the audio edition, you would agree with that sentiment? Yeah.

Yeah, I do believe so. And similar with that percentage there, I think the information the AI gives you, it should be 20 to 30% maybe beyond what you currently are capable of or know yourself. So you might get some good tips and tricks, but you're not getting like something you have absolutely no idea what the response means or how it works.

So that's how I use it. It's like, hey, I know this, but I need a little bit of help. Can you help me push beyond where I currently am? Yeah. And one of the things, like in terms of tools, you just published your awesome back-end development roadmap type video a few weeks ago. And I really enjoyed watching that and learning kind of how you view things.

back in development, the ecosystem of tools and everything. And one thing you say in there, I'm going to try to get the quote exactly right. You say, learn one tool from each category of tools. Yeah. Wow, that's some really good wisdom. Who'd you say said that? Caleb Curry in 2025. Yeah.

Yeah, whenever someone says they're going to quote me, I get a little nervous because I've said some wild things on some of my videos. But yeah, I think this is a good one. 200, 300 hours of podcast audio where I probably said lots of silly things that are... I try not to introduce misinformation into the world. And I try to sufficiently like coat everything in like, hey, I'm not an expert in this field and sufficiently preface it. But yeah, yeah.

Talk about why it is that you feel that way and why you think that's a viable learning strategy for people who are getting into software development. Like you talk about it in terms of backend development, but would you argue it's more general? So if you're like learning DevOps or if you're learning game development or something like that, like one tool in each category is actionable advice. Yeah, I think it's, it's pretty solid. So I can kind of explain the reasoning for that idea and what that, what that actually means. Um,

So I think a big problem is that, first off, I'll get to that answer. I just want to explain real quick that learning new things is a little uncomfortable, right? Like you don't know something. You have to like put effort into figuring out what's going on. And I think people are afraid of that feeling. Like if they don't understand it, that means, you know, it's out of scope, right?

their abilities or it's like out of their current abilities. But I think that that's natural to the learning processes. There's something that you just got to kind of stare at and digest to fully grasp. And the reason I wanted to mention that approach is that you should put effort into learning new things that are outside of what you currently know and getting like a broader understanding of what

but you also want a deeper understanding of technology. Either way, you're learning, but then you have to choose, you know, what do I focus my learning efforts on? Because that feeling of learning takes effort and it takes energy. And I would say it's capped for most people. You can only learn at a certain rate. And the more you try to learn, the more painful it becomes. Yeah.

However, like in like, for example, in one sitting, like if you study for 12 hours, I would guess that the efficiency of your learning goes down. However, you learn some of those. Yeah, exactly. Yeah. Like the learning per hour rate or like your learnings per hour goes down. However, learning those skills can help make learning other things faster. So in a way you gain time as well.

So all that to say, I believe you will get the most return on your time by going deeper on a fewer set of skills and technologies and then spending a certain percentage of your time in the exploratory discovery of new things.

So that roadmap is very discovery focused. It's, hey, here's some different technologies, how they fit together, what you might want to be aware of. It is not a here's everything you should learn in detail list. The purpose of the roadmap, not the roadmap, but the mind map. It's basically a bunch of different technologies connected and categorized. The purpose of that is to get an understanding of the landscape.

not to give you a step-by-step of everything you need to spend a lot of time learning. That should be maybe 20, 30% of your learning efforts is kind of going broad, wide. And I would say that 20, 30% varies on where you are in your career and like what your goals are, but that's just a general number to kind of frame my idea here.

What that means is 80% of your time should be going in depth on a smaller set of technologies or skills so that you are going to new challenges and things that might stretch your mind more. When you do that,

Those are the skills I believe transfer over to other things much easier. So for example, if I become an expert at the Postgres database, I understand all the commands, very good chance I could pick up MySQL or SQL Server, very little effort because of that depth.

So if I went that route, learning Postgres in great depth compared to splitting my time three ways across MySQL, SQL Server, and Postgres, I think I'm going to get much farther with the first approach of just focusing on going deep with one. So that kind of goes back to what a lot of people ask, like, hey, which languages should I focus on? Which frameworks should I focus on?

And then they kind of just jump around and they're spending their focus currency a little bit on everything. And they're not really getting depth on anything, which basically makes them a generalist to the extreme degree where they can't actually do anything with their skills. They can only talk about the things at a high level. So I'm not trying to go off the rails here, but I just think like,

Understanding that mindset of like going deep and then doing some exploration is very important for most people to get the most out of their study time. So when I say learn one thing from each category, really what that means is like first learn one database, one language, one framework, one cloud provider,

One primary operating system plus Linux. Yeah, we're just learning about the primary operating system. Yeah, there we go. It's going to give you headaches, but it does get the two for one. And then that's going to set you up to have a good depth that you can transfer over to new frameworks very easily. Yeah.

Does that answer your question pretty well?

Shout out to Notes. And that ends the... Sponsor of this segment is Taking Notes. So what I...

When I was getting into coding, of course, everybody has probably heard my coding journey ad nauseum. If you haven't, Google learn to code book and you can read where I do blow by blow how I learned to code and got developer jobs and ultimately started free code camp and all that stuff. And it's all designed to be actionable advice for you and not just like, hey, this worked great for me. It's all like kind of caveated. But I definitely found myself in the generalist to an extreme degree because I was like,

learning some very basic programming stuff and automating stuff in my school and feeling really smart and special and stuff like that until I realized like, well, I'm just using like very specialized tools that are very good at getting things done. Not unlike somebody who might feel like they're, uh, you know, super powerful wizard just because they're using a copilot to like generate a lot of their code or they're grabbing some boilerplate off GitHub and they're making slight modifications to it and it's doing what they need to do. Um, and,

I will tell you, I went around for a while. I'd go to events and stuff like that, and my reach really exceeded my grasp in terms of understanding a lot of the concepts. And I find myself caught in conversations where people presumed much more skill and in-depth knowledge than I actually had. And it was super-duper embarrassing when somebody's like, oh, okay, so you're into Python too. Have you checked out this library for XYZ? And I'm like, I don't even know what XYZ is. Because...

A lot of times the illusion of knowledge can crowd out the actual incentive to go gather knowledge. And I often like to remind people that like the illusion of knowledge is the greatest impediment to learning. And people who think that they already understand something have no incentive to go out and, you know, actually test their hypotheses and like,

break down their presumptions and things like that. So don't be afraid if you find yourself in that situation or if you identify like, oh my goodness, he's right. He's talking about me. Kel's talking about me. I'm a generalist to the extreme degree. I've been watching all these YouTube, like I'm subscribed to like a backend channel, a DevOps channel. I've just been watching every video that drops on the Free Code Camp YouTube channel and like jumping all over the place. But I'm

Don't worry. Don't worry. There's nothing wrong with having that broad understanding, but you do need to go deep, right? Like the, the, the,

Managers will always talk about T-shaped individuals that have this broad understanding but that are deep in one vertical, whether that's some sort of engineering topic or some sort of domain expertise like they're a statistician or something like that. Those people are very valuable. But what is not super valuable is the person who just has the deep knowledge but doesn't have any of the additional grasp of the surrounding fields. Yeah, that's a good point too. Can't make good associative decisions.

can't make connections, can't figure out like how things relate to one another because they don't have that kind of scaffolding. They don't have that framework for grokking those, those concepts. Uh, and then, yeah. So, so I just wanted to point out that like, if you find yourself in that situation, I found myself in that same situation. It's nothing to be ashamed of, but it is something to remedy. Yeah.

and take action on it and don't be content to merely be the, the know it all from cheers. The, the mailman who comes in and seems to know a little bit about everything, but like when pressed further, can't really go beyond the surface depth of anything and lacks kind of like a functional understanding, like kind of the physics of software and like how things actually traditionally fit together and what the actual rules are governing like different things. Uh,

You'll get there with deliberate practice that Caleb is advocating for. So, sorry, I just had to go off. Like, like I've never talked about that before. And I think you, you, you articulate in such an elegant, eloquent way, generalist to an extreme degree. And I just wanted to say that, like confess that I was such a person and anybody who's listening to this, it's never too, too late to like take corrective action.

Uh, just don't let your, don't find yourself in that rut and don't accept like, Oh yeah, that's just who I am. Maybe I should be a, a product manager because I understand how these things in theory fit together. No, you should actually learn how to code the best PMs know how to code, right? The best, uh, anybody really knows how to code. Like if you look at Silicon Valley, like,

almost all the CEOs are not salespeople or something like that. They're software engineers who can actually dig into the product and understand why decisions are being made the way they are in the product design and the, you know, the infrastructure and like architecture, all those things, right? And they can have conversations where they can go from different layers of abstraction and, and converse fluently with other people in the organization who are doing more technical work. So, um,

I think that's all really good. Yeah. Yeah. Don't really just accept like, oh, okay. I'm a generalist. It's cool. I'm a generalist. No, it's not cool. You need to don't plateau there is what I'm saying. Yeah. I just started working with somebody who has a background in like chief operations or like basically in operations. And they realized that they have always missed their full potential because they never started working.

from the basics of code. Like now that's what we're doing. We're filling in all the gaps. Like, Hey, let's crash course what you'd get in a CS degree. Let's talk about building apps beginning to end. And now once that's done, like her knowledge is going to be extremely valuable because she has both of those skills, right? Like she knows the tech at a high level now and has a really broad understanding and she

how it's helpful for companies and how it makes money and how it's produced. But pairing that with the actual ability to build it yourself, I would say that's a recipe for high value. Yeah. I mean, basically, I also low founder has that skill set. They have like some sort of managerial mindset or like value of like sales or some other kind of like dimension accounting within an organization so they can understand the money and how that funds work.

You being able to sit down and drink coffee and write code all day or drink tea, in my case, or drink water if you just don't drink caffeine at all, which, shout out to you, if you're completely clear of those psychoactive substances, I'm afraid to give them up anytime. Props. I digress.

Yeah. I think as you're a beginner, uh, it, there's definitely some value in just spending time doing that discovery. Like just go broad for a little bit and understand what's out there so you can confidently communicate in a casual environment, but that's just like a step one. Then you need to choose some things to go, go deep with. Uh,

And yeah, you also mentioned with the thing I didn't even really say or consider is like you can go the opposite extreme where you just only go depth and you are basically uninformed about anything outside of that specialty, which I'd say can also be dangerous because you don't know how things interact. Say you're like a

You're a master at distributed systems. You're all back end. And then someone's talking to you about web development and you're like, what's an HTML? Like, I don't remember that. So, yeah, a little bit of both is great. I think people tend to only do the broad because it's less painful. Yeah.

It's less painful because the evaluation criteria are farther away. Like I think Paul Graham, the founder of Y Combinator, has talked about this. And one of the things he said is like a lot of people think they're much better drivers than they actually are because when you're driving, it's extremely rare that even a bad driver gets in an accident.

It doesn't happen every day. So the feedback loop is so loose and it's easy for somebody to say, well, yeah, of course I got in an accident because I had her play a door. Of course I got in an accident because there was road work and I got confused or something like that, ignoring the fact that they could have –

in theory, been more prepared for that scenario and avoided an accident. Or maybe they just habitually speed and tailgate people. Very common here in Texas. I guess you lived in Austin. You know, like the giant truck bearing down on you is like a daily experience here in Texas. But yeah, like...

If you are going deeper and you're actually learning like a skill where like a compiler is telling you every 30 seconds, like, Hey, that didn't work, you know, like try again. It very quickly humbles you. And yeah, I think that that's something you don't get when you're just like,

watching a listening to podcasts, which again, I love listening to podcasts and I listen to them all the time, but there's no feedback. Great. Like loop. Like, it's not like you take a quiz at the end of it. Although you could in theory use like an LLM and put this podcast in there and say, Hey, quiz me about this podcast. And, and that's something that a GPT four Oh, for example, we'll do. Um, I, you can grab the transcript so you can introduce these feedback loops, but when you're actually learning a hard technical skill, it's like math. Why is math so scary for so many people? Um,

Because there's only one right answer usually. And if you don't arrive at that, you arrived at a wrong answer. And so you just have to keep thrashing and banging your head until you actually arrive at the correct answer. And even then, you may not fully understand how you arrived at that answer and why it was correct. And yeah, like that daunts people who are used to like learning like,

political science or, um, you know, art history or, or things that like don't have those kind of like, you're not actually feeding your thoughts into a machine and having them evaluated. Yeah.

Uh, you're, you're maybe your professor is like saying, yeah, I see that you're using this type of reasoning here and I was, but it's, it's squishy, it's soft and there is no squishy and soft when you're dealing with, uh, you know, dealing with JavaScript compiler and getting these error messages and stuff like that. Very frustrating. And I can see why so many people put off going deep on more technical topics.

Yeah, you actually mentioned a couple things I wanted to add a few comments about. So with the general learning, if you're wanting to have a good understanding of everything that's out there, like what it is, where it fits in, that's where things like roadmaps, mind maps, things you mentioned about I've created, those are extremely helpful. So I would really recommend looking at some of those. But another great way to

to get better at that general understanding is through passive learning, through things like podcasts. So I'm glad you mentioned, like, you know, listening to this podcast isn't going to get you depth, but it does get you the breadth you need for a good understanding. And that's one of my favorite ways to learn what's out there or what I don't know.

So podcasts, listening to YouTubers who kind of, you know, talk about some of like the latest tech or trends. And for me, I really love like long form stuff, you know, something I can just throw on for an hour and, and just hear perspectives and also like be exposed to maybe a few words or technologies I haven't really learned much about. And you can get a really good general understanding with almost no, no,

mental strain, if that makes sense.

Yeah, I mean the conversation is intended to guide you. And if the interviewer is doing a good job, like I hope I'm doing, you're kind of anticipating potential blind spots for the listener and trying to smooth that out so that they have a smooth learning experience and they don't walk away completely confused about what you were talking about, right? Totally. Defining acronyms and trying to relate things to things that people are likely to have had first-hand experience with, stuff like that.

Yeah, podcasts. And I'll just, again, like I listen to a ton of podcasts. I probably listen to, I don't know, like 10, 15, 20 hours a week. Granted, I listen on double speed, which if...

You know, like this podcast is not edited. I want the raw extemporaneousness. I want us occasionally interrupting one another because that's what happens in a real-life conversation. I've been on podcasts where they take my interview and they just chop it up, and, like, the second I finish saying something, I'm saying something else, and there's no space to breathe. But you can kind of, like, take a raw podcast like this, and if the insights per second aren't high enough for you, just kick it up to 1.5 speed or 2x. Yeah, I mean, I do, like...

3x speed. If you're on 2, you need to pick it up. Come on. Yeah, yeah. Well, hopefully, because we're not doing these jump cuts every three or four seconds, I mean, my goodness, I watch some channels on YouTube where they're doing video essays and it's literally like, okay, I got half a sentence right. Now we're going to jump and do the next clause of this sentence. Yeah.

And there's something to be said. Like when I'm sorry, I'm going to be old man and cloud yelling at cloud. Like when I do the guitar parts and the drums and the bass and the keys, like those are all one take. I don't composite. I don't do any sort of magic on the computer to like fix, fix my crappy music. Like I actually just, I think there's an organic process there that I respect. And if you go see somebody live, uh,

They're doing way harder mode than what I'm doing because I can take multiple takes at least and find a good take. Right. And it's, it's kind of the same thing with like, if you go to a conference and watch a conference talk, that person may have rehearsed and everything like that, but they're doing it live without a net up there in front of a whole bunch of people. And it takes a lot of audacity and, um,

Yeah, there's just something about the actual performance of it that I love. And you could take somebody who knows literally nothing about programming and you could make them into a very popular programming YouTuber by just having like a team of subject domain experts who are like writing scripts for them and putting them in front of the camera and telling them exactly what to do and having like a masterful editor who like inserts all the memes and stuff like that. And like I swear that sort of stuff comes up in my YouTube feed all the time.

And then I see Caleb Curry talking to his blackboard, like walking me through all these things. Like it's 1985 or something like that. I mean, it's awesome. I love it.

Yeah, teaching, like, AI on a chalkboard. No, I appreciate it. And I get comments about that all the time. Like, some people are like, what in the world? And then other people are like, you're teaching, like, these new technologies on, like, a chalkboard. This is so weird, but I like it. And I think slowing down is what helps people kind of grasp the material. It's not very hard.

Yeah, I don't think so either. And that's why I'll also do like hands-on applied videos. I kind of like jump back and forth because I think there's a place for both. It's really like the way I've done a lot of series is like I'll focus on the theory and the ideas and the understanding and then go apply it, which makes it a lot easier to understand what you're coding. Yeah.

And there's so much deliberation and thought that goes into like thinking about like the journey you're going to take the learner and learner empathy. And you have all that. And so that is just one thing I'll shout out. Like not all programming teachers are made equal. There are a lot of people that are excellent programmers but don't really put that much thought into pedagogy. They don't necessarily put that much thought into how they're going to actually design things.

a course or even like a short video to maximize like insights per minute or learning like, and ensure like the smoothest possible difficulty curve. Cause there's always a difficulty curve and, and,

There are people out there who are just looking to impress you and dazzle you. You'll see these virtuoso guitarists like just playing extremely fast. You don't even comprehend what's going on. And you're just like, wow, I could never do that. And that is like the polar opposite of what most teachers are trying to do. What they're trying to do is show, you know, you can do this and we're going to start slow, but we're going to work up toward these much more sophisticated code bases that we're going to be building and maintaining and things like that. So, um,

Anyway, I will stop complimenting you so vociferously and just gushing. But I wish more people were doing it the way you're doing it. And I hope some people listening to this will get inspired and they'll consider creating – like just getting in front of the chalkboard or whiteboard or even just doing a screen share and talking about what they're learning, how they're learning it. Because there's not enough of that.

Yeah, I really appreciate the compliments and comments because like I intentionally structure my material that way on purpose, right? It's not just me. Maybe when I started, I just threw the camera on and was like, yeah, let's just do it. But now I really think through like, hey, what's like the best logical way to introduce these concepts one variable at a time so that you can always isolate things you don't understand and learn them. Yeah.

So yeah, a one hour video might take a week of prep and recording and all of that. So there's a lot that goes into it, but I think that's why I find a lot of value in the material I produce and other people in theory do as well, maybe.

Yeah, well, I think the proof is in the pudding. The proof of the pudding is in the eating. There are a lot of people that are watching your videos and commenting about how they've learned a tremendous amount from you. I saw somebody was like working at NVIDIA as a software engineer who was like, yes, hurry. He got me where I am today. And I mean, that's got to make you feel really proud that like the very top of engineering, like where people are like literally designing semiconductors and stuff like that and doing these different processes and stuff like that's got to feel good.

Yeah, that was, that was a great one. I love getting messages from people and like, I'm sure there are many people out there that have that same kind of story who haven't said anything. But for those of you who do definitely appreciate the, the mention. Yeah.

I was walking through the gym, just a local YMCA, and some guy from Google was like, Quincy Larson, you got me a job at Google. And I was just like, oh man, that's so awesome. That's amazing. Yeah, that's a wonderful feeling. I wanted to circle back to one of the things we were mentioning about the passive learning and podcasts. I think this naturally gives you the ability to communicate about things.

Uh, and in a better way. So I really do think it's valuable for screening interviews and just communication interviews, talking about how you can help companies and like the actual work. So with, with me going back to what we were talking about at the beginning with like zero knowledge cryptography, um,

I basically listened to a, the zero knowledge podcast, I believe is what it's called, you know, multiple, uh, multiple episodes per day. And I was basically like, Hey, I'm just going to absorb as much information for that. Like the really broad understanding before going deep on any one specific topic. So then I could communicate about anything ZK zero knowledge, uh,

in an intelligent way. Yeah. Like it's not going to hold if we go deep, like you've mentioned, like, you know, I might be in a conversation and someone's asking me to explain how, you know, a zero knowledge circuit works beginning to end. And I'm like, I don't know, but I can tell you a little bit about some of the different competing products and different vocabulary and so forth, but that's all still really valuable. And I think, uh,

People also tend to neglect that ability when it comes to interviewing because not only do you want to be able to build software, you want to be able to

prove that what you're going to build to a potential employer is valuable and that you can write software that solves problems that are needed to be solved in the industry. And a lot of that is at the communication layer and not just at the coding layer. So if you go in and you completely, you just do really, really great with some technical assessment doesn't necessarily mean you're going to get a role or that you're the best fit. Um,

Some people have said like, hey, it's all about what you can code. I don't necessarily think that's true. I think it's also what you can communicate. So don't neglect that portion of it either. And I think one of the best ways to get better at that is to start communicating with other people. So finding some communities and listening to podcasts, more higher level stuff, conferences and those kinds of things.

So I wanted to mention that. And then we also use the term squishy, kind of like this more lightweight stuff that's not like in the weeds. For in the weeds learning, do something that's a little uncomfortable. Like just say, hey, I'm going to focus on this for this period of time.

Maybe that is DSA or something like we've talked about, but it could just be, you know, finally figuring out Docker and Kubernetes or whatever you want it to be. Something you want to get better at. For me, while I don't do this regularly and I still don't enjoy it, when I wanted to get better at a deeper level, something I always avoided was reading white papers because yawn. I mean, come on, they're so boring. But...

forcing yourself to do something like that can challenge you to have a deeper understanding. So I started with the Bitcoin white paper, which kind of laid the foundation for a lot of cryptocurrencies. And I was working in Web3 and, you know, I just read it first time. I kind of got some of it, you know, read it again, started to like piece things together. And I just like reread it until I could comprehend most of what it was saying.

And obviously I'll do any extra research or whatever, but just that repetition, it helps with remembering stuff and making those connections. Then doing something similar with database systems. So go read the Dynamo white paper or the Google Big Table paper, whatever it is in your niche. There's probably some really boring document that people know of that kind of sets the foundation for a lot of learning.

And that's something that if you force yourself to start to digest, you'll really deepen your knowledge, I would say. So that's one idea. It doesn't have to be a white paper, but maybe it's some specific documentation or some spec or some guide that people adhere to. Yeah, so definitely balancing the communication, the more squishy kind of stuff, like you mentioned, and then also the depth.

We did briefly talk a little bit about networking and you wanted to get into that, but we didn't really cover it. We kind of jumped through a bunch of different topics. High level advice for networking. Like let's say hypothetically you, you moved to a different country. You moved to Germany.

And, well, let's say you move to the UK because then at least you don't have the language. I was going to say, first I have to learn German. Yeah, there are big cultural challenges. Like people underestimate the cultural differences between the US and the UK, for example. Like more companies, more joint ventures. This was true in like the 90s. I don't know if it's still true. But the country where the most joint venture type companies

between companies fail is like the US and the UK because what happens is people just presume the culture is the same even though it's actually quite different. If you watch Peppa Pig with your kids and stuff like that, you start to understand, oh, this is like really different from like...

U.S. culture, let's say hypothetically that those cultural differences were also normalized. So this is like a complete, like, fabricated, contrived exercise. But let's say hypothetically you drop into a different country and you don't know anybody, right?

Or maybe we could just put you in Toledo or something like that. Yeah. Okay. So let's go to Toledo where the culture and language are the same. And they're also Midwesterners. I'm a Southwestern technically, but I think between you and me, I would presume there's not a lot of cultural differences, but we could see whether our joint ventures fail like the American and British do. But let's say you're going into that and you know nobody, what's

And maybe you've got like three months of runway, but you do have the skills. You do have like what you've invested time and energy. You've got like a shape. You've got like a specialization in relational database design or something like that, right? Obviously, that is true because you created probably the canonical eight-hour video course on that that's on YouTube right now. So let's say that you've got that expertise, but you know nobody. Right.

How do you go about getting started building your network? What would you do to maximize it with three months runway? Yeah, that's actually a really good question and exercise. So I will talk about what I would do and I'll show, I'll pretty much just tell you what I did do to get a senior software engineering role in like less than three months. So basically you say we're in a new location and,

but I have the same skills. So this is important because there's different approaches to job searching, right? You can go broad, like, Hey, I'm going to spam, just apply to every single role on planet earth. See what happens. That strategy actually can work. Yeah. But there's also very targeted approach as well, where it's like, this is the type of company I'm looking for. This is the type of tech I'm working, looking for that approach can work too.

I would say, for me, I would do probably... I would narrow my focus a bit. So I would want to have some specifics of what I'm looking for. Because it's kind of like...

there needs to be a good match between you and the company where if you're just super broad and you're just applying to anything, there's a good chance for many of those. You don't have some specialization or some unique thing that sets you apart from the hundreds of other people that are doing the same exact thing as you. So that's really like a numbers game there. You just have to get enough out there to get somebody to convince, to, to convince somebody to give you some time to interview. Uh,

I would say the more bulk broad approach is something we can definitely talk about, but I'm going to, for this exercise, go more on the narrow approach, which to narrow, I would first look at the skills because all of the skills in the world isn't necessarily good, right? So with skills, I would focus on a couple that I'd be interested in working in.

So for me, I was like, hey, I know for a fact I want to work on the Rust programming language, want to focus on backend engineering or full stack, not really interested in mobile development, not really interested in design, not interested in even certain little things. Like I didn't want to use Azure or GCP. Like I specifically wanted to use AWS or something I was familiar with because I

every role you apply to if you get an interview then you have to prepare and and so forth so i was like i'm gonna go pretty focused on the tech and at this point i was pretty new to rust like i didn't have a working yeah skill set with it but you know same idea i just diffed it from what i already knew compared it uh i already knew c++ to some degree and already knew python javascript whatever so i just learned about like some of the differences with you know um

everything Rust has to offer, which we'll get into some other day. Just for some context, why Rust? Rust is like the main language used in Web3 development. And of course, Rust is also used for

Anything that has to be high performance, like it's being used in the Linux kernel. A lot of people, their favorite programming language is Rust. So it is a very actively developed and maintained community. And FreeCodeCamp has some courses on Rust as well that are free. Oh, nice. That you can go through, including some interactive courses too. Yeah. Sorry, I just wanted to give people context into why Rust is so important.

Yeah, that's some great context. So for me, I saw that opening the most opportunities for me because I knew I could either stay in the Web3 environment

zero knowledge space, or I could get into that high performance, low level stuff, potentially like in a working on a database engine or something like that. But also Rust because you could build general API. So if I wanted to do the equivalent of ExpressJS using Rust, I totally could do that. So for me, it was like, hey, this is going to unlock the most opportunities for me.

And I just saw it as something that if I had that skill, I could utilize it to find a remote role doing something I was interested in. And the software I'd be building would likely be either new software, relatively new, or rewriting old software in Rust, which is something that interested me as I didn't want to join some project and have like 20 year old code I had to like

digest or learn some new language or something like that. So that was my approach for choosing what to focus on. And then I just became that. So I dropped anything saying like aspiring Rust developer or learning Rust or whatever. I just was like, hey, I'm a Rust engineer, updated my profile, LinkedIn. And on the topic of LinkedIn, you don't have to use LinkedIn, but

For me, I needed, you need a centralized location for all of your contacts, basically. So if you're in sales and marketing, this is basically like your CRM for networking. And you start to think of this as like a marketing and sales thing. Like I have to market myself and I have to sell myself into a role. So even on conferences, I don't have my phone with me, but like

My homepage was a QR code for people to connect with me on Telegram or LinkedIn or like whatever. So anybody I could, anybody I met, my goal was to get them to that centralized location. Then I build a strategy out from there. So wipe the LinkedIn, update it with all like the new skills limited to just a couple that I think were like going to give me the most value. Then I started creating.

building in Rust and like updating what I was doing. Like I just like, Hey, I'm just going to build like a CLI. I'm going to build like some cryptography stuff. Yeah. And I started posting about that on LinkedIn, like nothing too crazy. I would just be like, Hey, today I learned about like the clap package and like showed an example, nothing magnificent. You know, I wasn't doing anything that

Anybody watching this could probably figure out just regular stuff. Then I joined a bunch of LinkedIn groups, Rust, software engineering, like whatever. And with connections, you could basically do reach out like, hey, I'm going to reach out to this many people per day, you know, 10, 15 people per day.

And that can really help. And for that, you could target recruiters or you could target hiring managers or you could target people who could give you referrals to companies. If it's a bigger company, that would probably be how I would adjust this. If you were going for like more like Fang or like some big tech, instead of targeting recruiters, target people you can build relationships with to get referrals. But I was targeting small anyways. Like I wanted to be like doing basically the end to end.

So you said you wanted to work on small teams because you'd be able to work on a product and instead of just being in some department focused on some microcosm of the code base. Like, for example, I've talked to people at large companies that like their entire job, they have like a person whose entire job is just to manage like the CloudFlare.yaml file. That's their entire job is to like move around in that yaml file. And like that doesn't sound like you're going to build like a broad skill set if you're just doing that all the time.

Yeah, I wanted pretty small because I wanted to do either full stack, like deploying everything, like also the DevOps and operations and stuff, or the same but just the back end portion. So like a medium sized team. So that was my goal. So I joined these groups, connected with people. Someone reached out to me.

who saw me join that group, probably saw my profile, saw I was doing rough stuff, started a conversation. I just hopped on a, like an intro call, which is what I would say is the goal of these conversations is just to like get on a call and just communicate what you're working on, what your goals are going with confidence. Like,

Just an ungodly amount of confidence. Yeah, give them a face. Put a face to the name. Like, I remember people whom I've had a 30-minute call with. Like, I don't generally forget when I've allocated 30 minutes of my waking life to talking to somebody. Like, I don't just, oh, who's that person? I have no recollection of that whatsoever. No. And I think most people do, especially if their job is recruitment or being a hiring manager and finding talent and stuff like that. And you just dramatically increase...

Kind of like your perceived weight in their search for candidates. Like, oh, yeah, this person I talked to. And it might be completely subconscious, but they're going to be much more likely to want to talk to you after they've – or to further perceive you after you've gotten the ball rolling with that. I hope that's not like a complete digression from what you're saying. No, I think this is 100% true, right? Yeah.

In a world where we're going more towards automation and AI and automatic screening of resumes, we want to intentionally find a person and get face-to-face, even if that's online. So even if I was in Toledo or Germany or UK or wherever, we're

My approach has always been online. I've always worked remotely. I've always done online. In-person events are definitely valid. I've done plenty of those. But for me, my goal was to get that person connected with me online. So that was my central location. But the in-person events can be extremely valuable. Like where I live, there's really no events like locally. There's one that was going on for a short period of time and it was like almost an hour away.

I went once and I connected with a guy there. We were both like learning and we're still friends to this day. And it's been like, you know, eight years or something. Uh, and I, we ended up going to the same university and I was like, dude, I just saw you at that like event. And like, we're still friends today. So those deep connections are really good. You should definitely have like those deep connections. Um,

But yeah, just to kind of wrap up this idea for sake of time, basically, I started this conversation with this person. And then with the intro call, I came in with high level of confidence because I believed that any problem I was given, I would either know how to solve it or be resourceful enough to solve it through conversation.

research or the help of others. In other words, asking around, searching through forums, asking on Discord, Slack, whatever it might be to solve whatever problem.

Could there be a problem I don't know how to solve? Like, yeah, there might be something I don't know how to solve. But believing that I could solve it is step one. And I think that confidence alone is what convinced him to be like, yeah, let's go. And we just, you know, after a week or two of communicating back and forth, like I started a role there.

and did everything from beginning to end, full stack with Rust and React and a lot of really interesting, challenging stuff. It was not in cryptos and defense contracting, so dealing with Air Force and some stuff like that, but completely new domain. But I was confident enough with the technical skills that he was like, "Yeah, I can teach you the domain knowledge."

I'm confident you can build the software. So domain knowledge helps. So I told him up front, I was like, to be honest, I don't know anything about anything regarding this, but I can definitely build you an app. So that's my story. I just want to quote something you said that I think is really profound. A genuine desire to learn outweighs most skills. Yes, I would say that's true.

If you put in consistent effort and you want to get better, I think in the long run you're going to be better than many people.

100%. Well, let me just quickly recap what you said there because I think it is profoundly important. You essentially decided what you wanted to do, step one. Step two, update all your socials, especially your LinkedIn, which is just an invaluable resource. People don't count LinkedIn out. It is a real tool. I think you said you also use a tool like Blind. Yeah, I use those for scoping out different roles and seeing what they're looking for mainly. Yeah.

And then, of course, you did talk with recruiters as well. And you seem to be somebody who encourages people to make use of the expertise of recruiters and their networks. Yes. Yeah. So essentially, you're like, okay, I'm the Rust guy. I am going to – I'm a Rust engineer. I'm going to learn what I need to learn to be able to back up that label that I've applied to myself. Yeah, I believe that's the fastest –

Sorry, I didn't mean to interrupt you there, but I believe that's the fastest way to learn is put yourself in the position where you are what you want to become. I've spoke with someone who recently started working with in my mentoring where they were given an opportunity to go to a senior role within their company. However, they didn't feel they had the experience to do that.

My initial like immediate thought, like obviously prep, learn the skills, get better. My immediate thought is like if you are in a situation in your life where you can devote the time, the time and you can you can learn those things, take it because the only way you're going to get the experience is by doing that.

100%. Caleb, it's been amazing having you on the Free Code Camp podcast. I hope everybody will check out the link to Caleb's course on database design that is in the show notes. And I'll have some other links from Caleb in there.

I hope this advice has been helpful for you and your own skill development and your, your job search and just planning things out. I mean, Caleb, you're obviously somebody who plans a lot, thinks a lot. Uh, you are not somebody like a leaf flitting on the wind, you know, like Forrest Gump or whatever. I think it was like a feather in the movie, but like you are somebody who, who kind of like,

does what you can to control, to like assert control in a world where we have little control agency. Yeah. Congratulations again on not the back after the layoff. And thank you for continuing to just very transparently share your insights, your experience for the benefit of everyone else out there who's going through similar things and who's,

gearing up to go through similar things because a lot of people want to be where you are when they're 28, assuming they're not even 28. And I didn't even start learning to code until I was 31, but I'd be very happy if I was where you were when I was like 35, if I started at 31. So just like making out a roadmap, as you said, getting the giant view of the mountain range before you decide which mountain you want to parachute onto and start climbing. Yeah, you've got so many insights here, and I hope everybody tuning in, these have been helpful.

Yeah, this has been great. Thank you, Quincy, for your time. And I'm happy to be here. And maybe we'll do this again sometime soon. Most definitely. And to everybody tuning in, until next week, happy coding.