Data Driven Approach to Software Engineering - Interview With John Vandivier

So this is this is perfect. Now people I can I'm going to cut this into shorts and post only this for the rest of eternity and say look you need soft skills. That is your differentiator. You need to do this. How might a PhD in economics help you out as a software engineer? Well probably in some ways that you're not expecting. Hi my name is Nick Cantino and I'm a principal software engineering manager at Microsoft. In this video I was joined by John Vander of latterly.io who is a PhD in economics. John has put together an approach for skilling up as a software engineer that is entirely evidence and databased. There's a lot of really interesting overlap for how John likes to approach skilling up software engineers and how I like to educate and share my experience for engineers as well. It was great that John could support his claims with data and research as well. So, if you're an aspiring software engineer looking to scale up as a software engineer, this video is going to be awesome for you. A quick reminder to subscribe to the channel and check out that pin comment for my courses on dome train. All right, sit back, enjoy. I'll see you next time. Right. So, it was originally my Tik Tok. Uh, my name is John Vander, senior software engineer, about 10 years of experience. I also have a PhD in economics, >> which >> because my sister said it was cool. And she she showed me some funny videos and said, "You're so old. Why don't you have a Tik Tok yet? Don't you want to be cool?" And I thought, "Well, yes, of course." Uh, and so I played a bit of guitar and I just did sort of random things until I was just giving a hot take related to something to do with tech. I don't remember what it was, but you remember a few years ago there was just a wave of like trend in the states of people wanting to get into tech. And I guess I hit it at the right time and it and it u resonated with a bunch of people and I thought whoa let me stick to this topic because it's actually performing for me and I went from a couple hundred followers to tens of thousands of followers because I found a niche where I was providing value. People cared. Um and on TikTok when you get to a thousand viewers you're able to live stream and >> that's what I'm pushing for. Yeah. Yeah, I hope you get it. I'll do what I can to help you. That was a big >> Thank you. >> That was a big milestone for me when I was able to cross that. >> Um, then I was able to get a lot more viewers because I I'm able to effectively communicate programming when I'm streaming, I think, better than in these short form videos, >> which is awesome, right? Because like, and that's actually some of the feedback I get on some of my content. So for a lot of my like if people watch my content and it's short form, it is almost never an original short form piece. And full transparency, it takes too much time for me to dedicate to that versus focusing on my main type of content. So I've had feedback where people have said, "Hey, like why didn't you post the whole thing?" And I'm like, "Well, it's a short and if you want the whole thing, here's the link to the YouTube video kind of thing." But it's really cool that you're able to kind of lean into the streaming and like you said a little bit before the fact that your you know your your jam is really that you stream this stuff and that's kind of like where you're creating all of your original value. I think that's super cool and a whole unique skill set because I feel like a lot of people coding and streaming that's like that's not easy. It's like people doing a software demo and it's like nothing ever works in a demo and here you are writing the code and you know to a live audience. >> It is a skill. It's a skill that I've acquired and I'm not exactly sure how I acquired it and I don't fully appreciate it myself. Interviewing.io just today I think released a blog article where they studied the skill sets of top engineers and where they work. So interviewing.io IO you may know is a job uh search preparation platform. So you can book a interview with a real fang engineer and they'll run you through a full loop and they'll give you transparent feedback which is nice. >> One of those things that's kind of missing if you do the actual loop you might not get decent feedback, right? Um so you pay interviewing.io. Anyway, in any case they have a really nice blog where they're constantly releasing analyses of their own interviews. Ah, >> and one of the things that they found which was surprising to me, here's something that's not surprising. Okay, Dropbox engineers excel at coding routes, right? So, your classic big tech uh engineers are going to succeed at the coding routes. One thing I was surprised by is that the number two best communicators were Capital One engineers. Um, and I formerly worked at Capital One and communication was really important there. There's all sorts of regulatory and compliance reasons where we need to be crystal clear about what we're saying. >> Very interesting. So do you find like say capital one it's almost like it's almost built into the culture then like it's just a huge emphasis like from a technical standpoint and like you were saying kind of a you know you know restrictions but then it's kind of built into the culture as a result of that then. >> That's right. And I think that's why I say that I don't fully appreciate when I obtained it because when I obtained it, I was just talking, right? >> Sure. >> Um, and Capital One is not regarded as big tech. I not in my circles anyway. It's not considered tier one or fang or even fang adjacent. So if you anyway, if you look at the interviewing.io analyses, they're not excelling at the coding rounds, but at communication, they're like better than Google. It's like baffling. >> Very interesting. That's that's really cool. And thank you for sharing the data points. Like I think I was saying a little bit earlier, right? The I think it's awesome like in I said in my head I've kind of figured, you know, this type of data must exist somewhere. But the fact that you're out there kind of being like, hey, like I'm interested in this obviously with what you're doing and being able to do things that areformational uh sorry like information or stats based is just awesome. So I really appreciate that. It's one of those things where like I definitely don't carve out time to do it, but it's fascinating to me. So that's that's super cool. >> Me too. I have this background in economics, so I'm constantly wearing the hat. So my approach to how can I add value in my mental model, it's based on my background in economics and research. And I need to provide research and then provide value that way. I'm sure this is a mental model which is wrong in some ways. I'm sure I could be funnier or more entertaining and provide value that way. And I frankly I just don't know how to do it. So I end up falling back to to research and that brings us to the the laterally curriculum. So I'm always being asked how do I break into tech and my answer was I would curate the best resources I could find. I would refer people to these documents. Don't repeat yourself. You referred enough times you write it down and make a document out of it. We're going to scale ourselves with documentation. >> And uh I think you mentioned earlier something about not having original shorts. I don't have really original uh like code either, right? So I'm like going to Stack Overflow and and pulling research from from places that I can. So it's a curation approach and it turns out that there is data on these things. Um some of it's original, but much of it's taken from elsewhere. One of the interesting tidbits that's original with me is the prestige rule for coding boot camps. So I found a rule where if you go to coursereport.com there's a reviews aggregator for coding boot camps and you can segment the boot camps by the count of reviews and the average rating. And so if you go with a boot camp over 4.25 on average with more than 400 reviews. Uh I wrote a paper and you can find this on SSRN where that generates a statistically significant employer perception effect and that will accelerate your hireability if you go high prestige >> boot camps. It's interesting but it's not that surprising because we know in university >> right >> high prestige universities have better placement rates >> and uh Nick I know you work at Microsoft and I think you can attest to some certifications are better than others. Employers care a lot about the best ones and not so much about the average one. >> Yeah. What I >> what I generally say for like when this comes up because people will ask they'll say like you know is it possible to get employed if I don't have postsecary or don't have this or don't have that. And what I generally say is like is it 100% needed or required? The answer is no because people can do it without it. But then I say, think about the volume of applicants, right? If you have the exact same skill set as 10 other people, but those 10 other people happen to have either more certifications, even though your skill set's the same, they have different, you know, maybe more prestigious school because you did you didn't even go to school or something. Even if your skill set's the same, all of a sudden, especially on paper, it just starts to look like there is potentially more value in the other candidates. Does it mean that that's necessarily true? Absolutely not. But, you know, when there's a lot of volume and people are going by what's being fed into the system for applicants, like it's it's really hard to tell people you don't need to do anything. You can just go apply. It's kind of like you should try to think about your competition. And this is just a brief interruption to remind you that I do have courses available on dome train focused on C. So whether you're interested in getting started in C, looking for a little bit more of an intermediate course focused on object-oriented programming and some async programming, or you're just looking to update your refactoring skills and see some examples that we can walk through together, you can go ahead and check them out by visiting the links in the description and the comment below. Thanks. And back to the video. >> Absolutely. Absolutely. And I think you touched on at least three key areas. So, I'll address these briefly and then we can circle back and go through them methodically because we're sort of talking to talking to them as the topics arise and that's appropriate. But when it comes to learning in an optimal fashion, you're going to want to do these steps in a certain order. >> That makes sense. >> One of the things that you mentioned was volume. And when it comes to the job search in the current economy in particular, the biggest problem that I see is an absence of application volume on the part of people who want to lay in their first or next programming role. And so I have um I have a rule of thumb that I encourage 80 plus applications per week. And you could go for 100. We have the heristic the rule of 100. And there's some reasons for that. One is that if I want to AB test changes in my resume, I need a bunch of data points to even detect a signal. Um, in practice, in practice, I actually don't think you need to exceed 100. Uh, I think you can get away with 80. Um, and if you are a currently employed senior, you're going to want to bring that number down and be more selective. But if you are non senior, if you're precenior, or if you're at the senior level like I am, but you're not currently employed, you can ramp that up to to 80 or even 100. Um, and there are reasons that this is really useful. That alone is not going to help. You're going to want to do social networking, too. And we can get into some of the social networking tips if you want to. But this is one of the major keys of eight keys that I'd like to get into, Nick. One of them is experiment on your job search. >> Right. Okay. >> So, there's a bunch of data about what works and a lot of the data is good and some of the data is contradictory. How could it be >> that some things work for Nick and they don't work for John? Uh, well, I looked at your I looked at your LinkedIn. It looks like you're on the West Coast. That's right. >> Believe it or not, conditions in Washington are different than conditions near Washington DC where I am. >> Um, and so how do you tell what's what for you in particular at the individual level? Just AB test your own resume, AB test your own talking points or your own behavioral interview answers. >> And that's going to be extremely valuable um for for individuals that are in the job search currently. And a quick question on that because I guess depending on who's watching and listening, right, the the number 80 depending on your experience that might sound like you might say, "Oh, like I do 80 a day and some people might say 80 like I I've sent out five and I feel overwhelmed." So when we talk about this number 80, is this 80 unique companies or is it potentially you know different roles at the same company? Say for example you want to apply to Microsoft. You might send uh an application to 10 different roles at Microsoft that are you know of interest to you or you know what are your thoughts on that? >> Absolutely. Um this will vary by company but if you ask a technical recruiter most recruiters will advise you not to apply to more than two uh two roles at their company because it becomes a burden on the on the recruiting system. >> And so I follow a rule of three and actually there's a 3x3. Um, so the we're we're talking about experimenting in the role of 3x3. So we're working backwards from the job search, but really we probably want to come back and talk about learning to code first. >> Sure. Yeah. Yeah. >> So the the the 3x3 is there are three job families that you're going to want to network with. So you go apply and you should be networking with at least one and ideally all three. That's of course the hiring manager related to the role, a technical recruiter at the company and a fellow developer. Um, and you there's plenty of things that you can say and it shouldn't be a game. This should be very authentic. If I were reaching out at Microsoft about a particular role, I might want to know, hey, what programming language are you using? >> You know, right, I've used Python, JavaScript, TypeScript. Are you using that on this project or do you know about a different team that's hiring that's going to use those? So you can also ask for resumeé reviews, portfolio reviews, and you also want to try to provide value to them. So if someone's going to review your resume, they're doing you a favor, right? So yeah, >> uh maybe the lowest effort thing to do is say thank you. And it's amazing how many people won't even say thank you. Um and how far a simple thank you can go, like a sincere one. >> So these are the three job families. Uh, and then also I would limit to less three or less. I I typically go one or two, but you can go up to three if you really want to. Maybe you're one of these people on the bubble like a Python developer who really does have an interest in both engineering and data analysis. Okay, fine. Fine. Go ahead. Uh, but I would limit it to three roles at a particular company. You should have a point of contact for every role. Not for every company, for every role because you might be applying to different teams, right? And then uh the third thing to do, so the first thing is the job families. The second is three and then the third is how often do you follow up? So um Nick, if you wanted to apply to Upstart and you say, "Hey, John, can you refer me?" And I go, "Of course." Like you're great. Let me refer you. And then you don't hear back tomorrow, >> probably I don't want you to bug me tomorrow. Right. >> Makes sense. >> Um so I I advocate for waiting really a week, follow up a week. Um, and then I get the question, hey, I applied on on on Thursday. Does does the next Tuesday count as waiting a week because we crossed the weekend? At least >> at least do three business days. Just give it a week. I understand that we get in a rush and if you're not employed, you you might want to shrink the week. >> Um, so you you can shrink it down to three business days as long as that's the next week. But give it a week and then three strikes and you're out. If you follow up with them and they don't reply, you can follow up a second time. But if you follow up a second time and they haven't got back to you the third time, just move on. You don't want to waste your time. Your time is too valuable. And let me put my economist hat back on. The opportunity cost of spinning your wheels on one job, it's a bad idea. If you look at the at the best programmers, and here I don't mean genuinely good programmers. I mean those who are good at coding rounds and passing the technical interview. >> Sure. >> Which I'm sure you know is very different than the job. And it's I know that this is one of the one of the topics that we'll get into at some point, but yes, I I I've produced content on this because I like to let people know like there are different skill sets involved in this kind of stuff. We would love if it was the exact same, but unfortunately it's not really how it works. >> That's right. I would love for it to be the same. And I think there may be some positive indications that they're converging over time, but it's going to be a while. For the time being, they are almost entirely distinct skill sets. And I think that's the right mental model is you should try to become a good programmer and then you should intentionally practice the job search skills independent of being a good programmer. >> Absolutely. Yep. >> You should not get hooked on one dream company. >> There we go. >> You should not get hooked on even one dream company because even the best programmers have a full loop pass rate of just over 50%. >> Wow. >> Um >> yeah. Um, and there are plenty of programmers at Google and at Facebook who will tell you to your face, if I were interviewed right now, I would flunk. Um, it takes time to get prepared to get prepared properly. If you can set your heart on a fang company, I think that's fine, but you have you're probably not going to get the job this time around. So, be prepared to go somewhere else for now and be prepared to pursue that over a number of years. So, typical cool down periods will be six to 18 months. If you do a really really good job, ask your recruiter. They might tell you, you know, you don't have a cool down because you were on the border, so feel free to apply again. That's kind of rare, but it happens. Ask your recruiter. But if you go with the statistics and if you say, well, my full loop pass rate is about 50%. Then that means if they're independent trials, the second time passing either would be 75. Or another way to look at that is there is a significant chance that you're still not getting that job after three loops in their cool down. Right. >> Yeah. >> So, I think that's perfectly fine and in some ways even admirable for you to stick with this goal of a fang company over a number of years, but what are you doing in the meantime? And there is a wrong answer to this. And the wrong answer is in the meantime, I'm unemployed, >> right? Yep. That makes a lot of sense. And I think, you know, just to to add on to that, I I agree that having like I think it's great if people have goals where they want to end up. And it's not for me or anyone to say it's a good or bad goal. If that's what people want to do in their career in their life, like that's great. Like, you know, set your sights on something. But the the reality is that our careers are not like it's not like a two-year career or a three-year career. our careers are I mean if we're if we're planning on staying employed like they're for a large majority of the rest of our lives. So if you don't get it right away it doesn't mean like you're a failure. It doesn't mean like it's never going to happen but you need to be doing something unless for some reason you happen to have tons of extra resources and you don't have to work and you can just code on your own until you know the next time you want to apply. I'm assuming that's probably not the case for almost everyone. So yeah, I think moving ahead and then going sure like that is my goal. I want to revisit it and trying again. I think that makes a lot of sense. >> Great. So maybe we should go back to how do we actually learn to code. >> Yeah, I think that would be awesome. >> So my starting point here I think as I mentioned is the research on hirability. I basically work backwards from what do employers want? And if we work backwards from what do employers want, there's different ways to analyze this, but I'm trying to take a risk averse approach that works for most people. >> Fair. >> Other people will give you advice targeted specifically to landing the best roles. And by best, they mean highest compensation. That's not what I'm trying to do. I think that's a separate conversation. And I think it's a good one to have as a second stage. >> As I said, >> make sense. >> As I said earlier, in the meantime, let's not be unemployed. Right. >> So, the first thing that I like to do is help people get uh either a tier 2 or a tier three job. And what do I mean by this? You know, people have used these terms in various ways. When I say a tier one company, I'm thinking of fang or fang adjacent companies. And when I say a fang adjacent company, I'm referring to the compensation structure in the interview pattern and then also the skill matrices and other things like that. But most relevantly, how do they run their interviews, >> right? >> With a tier 2 company, the compensation will be significantly less, but you will still know these companies. their household names. Um, Capital One is a tier 2 company. I think I mentioned them earlier. Your chain stores, your Walmart, the stores that the the companies that you know, they may be national or international, but they're not competitive with a Google or a Meta Salary. And then a tier three company. By a tier three company, I simply mean a company that isn't well known. They're not a household name. This could be a local um web development agency in your county or something like that. >> Sure. And so I uh the vast m majority of jobs by quantity exist in those tier two and tier three categories. It also so happens that those tier two and tier three categories are on average easier to obtain and don't require leak code. They don't require jumping through these really difficult hoops and these hoops that are constructed with the intention of being difficult because they're a filtering mechanism for the company. So I essentially advocate that people try to get competency here and hey some people will get competency here so quick that they can have the fan conversation within a month and maybe maybe it doesn't make sense for them to land a job and leave in a month. So they just compress the job search and they effectively do two hops right out of their college degree. Power to them. And actually that's an important differentiator is whether you went to college or not. But basically the approach here is what do these tier 2 and tier three companies want? And the big answer is they want websites. >> The big answer is they want websites. >> And what kind of websites do they want? Well, all kinds of them. Uh I think maybe last I checked WordPress was still the most popular provider. >> Um >> wow, that's I'm uh I don't know if I'm I guess I'm surprised by that, but now that I'm saying that out loud, I'm like, am I surprised? Like maybe I shouldn't be. Yeah, >> it will depend how you cut up the numbers. So if you look at the numbers of websites themselves, I think it's still WordPress. But if you look at um maybe like stores like you know those are not mostly WordPress. >> So website versus revenue generating official corporate website, you can cut that up different ways. >> Um and so if you ask yourself the question, well what skill set what skill set should I learn to make a website? uh there's a very there's a common denominator here which is HTML, CSS and JavaScript and then you can broaden significantly and and very significantly improve your job search performance by going full stack and learning the back end as well. And so that's my mental model and that's the reason that laterally takes this evidence-based approach of suggesting starting with full stack uh and then sort of going wherever you want from there. There are some specializations we can talk about, you know, mobile and and things like this. I see specialization as a second stage after getting that core of of full stack. >> That makes that makes a lot of sense. And one thing that kind of comes to mind is like especially when we talk about these tiers of companies. I think the way that you laid that out makes a lot of sense. Your approach for saying like what do most of these companies look for? Yeah, websites again makes sense. So the the languages and the tech stacks that you start to look at totally like you're kind of kind of matching up like if I'm going to start investing my time what's going to give me the best chance of success for matching up with the majority of companies and one thing that I think and I don't have stats on this this is an anecdote but if I had to guess at like companies say like I'm at Microsoft for example I work in the office 365 part almost nothing I see has to do with front-end development and I don't know you you're smiling and nodding so you might actually have some stats on this and I don't want to put you on the spot to dig it up or something like that but is there a big discrepancy when you start to go from what you're classifying as tier 2 and tier three to tier one in terms of those skill sets cuz again anecdotally for me it's like everything is backend like I'm working on a team that's doing routing for trillions of requests per day there's no CSS and JavaScript like it's not anywhere near where we're Not saying that's bad or anything. It's just it's very different. So, do you see a pattern with those types of skill sets and languages? >> Absolutely. I love this observation and I'm laughing because at Upstart I lead the Python guild >> and so I've done zero HTML and CSS myself in the corporate world for years. I still do this with side projects, but I'm a full-time back-end developer in the corporate world as well. And the answer is yes. The mix of job family between tier one and tier two is significantly different. And in particular, it's different in the direction that back-end developers are disproportionately highly employed in tier one. >> Okay. Interesting. That's like again anecdote for me, but I'm like you probably have some information on this. So that's that's pretty cool. Awesome. >> Yeah. And there's a bit of a puzzle here. Um but we've given away the answer but I'll spell out the puzzle anyway which is >> um if the full stack developer is able to do backend front end and even integrate between them and then a really cool full stack developer will have some SQL skills and can even do some fun things with data. Um why would you pay more for a back-end developer instead of a full stack developer who can do everything? Um, and in tier two and in tier three, we see a bunch of these like full stack developers or more relatively more front-end developers, although not absolutely more on a per company basis. Absolutely more across the market, but not absolutely more on a per company basis. The answer is specialization. The answer is specialization. Um, so when you acrew enough capital, you can pay for specialized roles. those specialized uh individual contributors have higher productivity along the margin of their specialization and so one back-end developer by themsel doesn't really help a company but if you're at the point where you can afford teams it becomes a brilliant choice. >> Interesting. Yeah. So like the the the composition of teams when you're able to scale up higher you can do more creative things. Um I've and I've seen a little bit of that too. Um, again like where I'm at right now, it makes it only makes sense to have like we're all backend but to give you an example like uh some of the stuff that we're building like Microsoft is tons of C code as one might expect but some of the stuff we're doing is uh extremely performance critical. So there's some stuff being built in Rust and like okay like would it you know does it make sense to go say we need to hire experts in Rust like yeah like if we can afford to do that have that composition mix into the team there's still you know back-end developers but you know different skill set with rust coming into the picture and that kind of thing. So yeah, I think that that's that's a good point that you can afford these optimizations within teams >> and you can afford them because of the scale precisely because of the scale. So it's not coincidental that tier one is where these things occur. In a tier one company, when I have tens of thousands of headcount and billions in revenue, if I can have a 1% advantage over my competitor, I can significantly impact the market. >> Right? If I if my product is 1% faster, I might take 10% market share, which would be millions or billions of dollars. Um, so it's a very different it's a fundamentally different game from a business perspective compared to tier 2 and tier three. >> Yeah, that's really interesting. I I love the the data being brought into it because a lot of the time when these discussions happen I don't like I think I've had similar themes of conversations but it's almost like yeah this is kind of what feels right based on experience or my you know observed uh time in industry but like here's data like this is cool. >> Yeah. So, we learned full stack. Um, and then to your point, if you get down the road in your career, it makes a lot of sense to strengthen up on the back end and then maybe go all in on back end. And in fact, that's my story. Um, but let's say that we're visiting that time where I want to learn full stack. Well, how do I do it? >> Right? >> So, one of the keys here is that I want to say there are prerequisites to coding. Sometimes I'm asked, can anyone learn to code? And I want to say yes, but the answer is no. I have two young children. They're wonderful. One of them is three. Um, she cannot read and write. She cannot code. So, there are there are prerequisites to coding including literacy and numerousy. Um, anyone who is familiar with the concept of a variable calculation will probably need to know algebra because 1 + x = 3. X is essentially a variable. When I'm solving for a variable, this is an arithmetic operation. So when I say literacy and numeracy, I don't just mean your your arithmetic tables like we're talking up to the level of algebra. Um most of us don't need to know geometry except some of those funny uh graphics people. Yeah. Um once you have basic literacy and numeracy, I want to harp on the value of search. And so this is me putting back on my PhD hat and it's my past bias and I'll own it. But I believe all other skills are downstream of search. And when I say search, you can also you can group search and research together and talking about both things. And just ask your your your your friends who may know about about programming, where did they go to to learn to program. Some might say school, but many will say if you ask them about a concrete problem, they will say Stack Overflow, >> right? >> Or they might say CSS.com or they might say Mozilla or they might give you a concrete reference. So they have built a mental list of curated resources and these are basically search techniques. The ability to Google keyword search, the ability to have a known and trusted list of uh information providers referring to official documentation here in 2024 using generative AI in lie of Google search. So being able to prompt engineer and there are some additional ones. Guess and check with a bit of debugging and troubleshooting, knowing how to log, knowing how to place a breakpoint. You can view this as a as a search technique. So guess and check is a search or research if that makes a if that makes more sense to you. If you say well guess and check isn't search, but it's a research technique, >> right? >> Um and so there I've listed five uh in the laterally checklist. Search is like the second thing we do. There's a video. There's actually like eight of these. Another one is phone a friend. If you ever saw Who Wants to be a Millionaire, >> right? Yeah. >> Um you can phone a friend. Um and there's a way to do these, right? There's a proper way to phone a friend. >> So, you won't want to be the junior who's nagging on the senior without doing any of your own homework. You're going to want to >> absolutely >> you're going to want to do techniques like uh try to do some of these other search techniques on your own. apply time boxing, escalate and prioritize when and if pri when and if appropriate. Um, so there are these eight techniques. They're not co-equal. It's poss I will see many students will get stuck and they'll say, "Well, there's eight search techniques. Which one do I do? I don't know which to do." And they'll just sort of sit there and they'll be stuck. Do a random draw is better than doing nothing. >> Do nothing. Yep. >> But you can do better than a random draw. You can actually rank these. And so phone a friend would not be the first one to do by way of example >> which which is interesting the phone a friend part I if I had to guess based on some of my experience with really junior developers it's either okay some now that we're remote I feel like a lot of people don't want to phone a friend first of all but when it was in office and I don't know if this is exactly related I think it is a little bit but what I used to observe is that people would lean on phoning a friend very often. And the challenge with that, it's kind of on two sides, is one, you phone a friend, you get the answer. You didn't actually have any of the struggle or like genuinely the learning process. Like we need to have a bit of friction and discomfort and try and fail things to be able to learn. And it sucks because I think we all just want like the give me the knowledge thing. I don't want to I don't want any of the pain. Just like make it happen. But you kind of get fed answers and it kind of kind of stifles your learning a bit. And the other side is that other engineers who say are more senior, they're used they end up falling into this pattern of oh I'll just give this person the answer so they they go away and I can go back to being productive and then it just becomes a vicious cycle and this person's now doing two jobs and the more junior person's not learning. >> I agree. uh for those who are familiar with growth mindset will know that uh failure is learning and pain is growth and that we need some of this discomfort and you can actually view you can actually come to learn it as a good thing. I think there's an analogy to testing here where as a junior I was terrified to see a failing test and as a senior I I'm terrified if I never saw a failing test. I need to see it fail. I need to see it and then I want to see it fixed. >> And I would use an analogy to exercise as well. I think this is pretty common is you get sore and then your muscles grow. Um at university there will be plenty of people who disagree with me because it turns out that the way that you learn concepts is very different than the way you grow a muscle. Fine, they are technically right. But I think for the lay person, this is actually a very useful mental model. >> Yeah, >> I agree with that. Even if the mechanism is not the same, I think it's a good reference point to say like, hey, like you know that if you're going and working out and like you are feeling like you know fatigued and sore the next day, odds are you're probably making pro progress. It's just going to take some time, right? So I think that's fair enough. Yeah, >> the taking the time point is key as well. Um, so whenever I take on a personal uh student, which I don't do very often, I I do apply a few tests and so I know that applying tests for admission to programs is controversial. Um, but there's reasons we do it. Companies have a formal interview because we need to filter. One of the very few tests that I apply is for grit. For grit. the Angela Duckworth's personality assessment for grit, which is the perseverance towards long-term goals. >> Okay? And >> this is a remarkable differentiator. If you're asking yourself, should I become a programmer? Ask yourself whether you wanted to be a programmer last month. And if you see that the answer is toggling between yes and no, maybe don't do it. At least not right now. Or a better way to say that is if you see that the answer is toggling between yes and no, we can predict that your performance will be lower. >> It's going to be lower. >> Interesting. Uh if you have said I do do I want to be a programmer? I've been thinking about this for a year. You should try it right now. You should like just just go try it. Um because the ability to hold on to that long-term goal is one of the best predictors of your success like right up there. I think better than intelligence. If not, it's right up there with it. >> Yeah, I like that a lot. And something you said earlier about like can anyone be a programmer barring like uh I think some very minimum requirements like in terms of being able to to read and you know physically write code or even speak it to a computer like I often say like I think most people can learn to program can but does that mean that they will enjoy being a software engineer and I think those are very very very different answers and not only enjoy like will you excel at it because you might say yep I can write code I can make a script or a program, do something. I'm like, okay, that's cool. And like, yeah, you succeeded at programming, but like, do you like problem solving? Are you good at problem solving? Do you have a mindset that you're talking about being resourceful and things like that? Like, if you don't enjoy doing those types of things and like that's not aligned with skill sets you want to improve, you probably just will not enjoy software engineering. It's not just about like did I put the code on the screen and does it run? like there's so much other stuff that gets added in and yeah, I think people can build the skills but if they enjoy it long term very different. >> I agree. So I think my pessimistic answer to can everyone learn to pro program the pessimistic answer is no. There's some bare minimum requirements. The optimistic answer and I think these are both true. I don't think there's a contradiction if you can understand the nuance. The optimistic answer is that the majority of people that want to can. And so if you want if you want to, you probably can. >> Yep. I I think that's a very fair way to put that. Like yeah, like if you didn't want to, you you actually might have this technically have the skills to be able to do it, but if you don't want to, you're not going to put in the time, you're not going to put in the effort, and then as a result, you'll never even know if you can. Like it just won't happen. There's a third related topic which is some people think that they don't want to but if they properly understood programming they would want to. >> Yeah. >> So I think here is in the popular culture now we get into the problem of cultural stereotypes >> and I think the cultural stereotypes on pro programming have been really negative and they've resulted in a lack of diversity in the industry and we need diversity for the purpose of innovation. >> Absolutely. >> What's more important to tech than innovation? uh and we know that uh diverse teams and organizations are more innovative. So how can we drive that diversity? That's a question that people have been asking for the past 10 years and we're getting some answers. By the way, coding boot camps are an extremely good answer to that. >> Coding boot camp gender diversity at graduate is about 5050. >> Wow. That's >> that's very impressive. when this used to come up, not for coding boot camps, but I can remember even being uh in hiring rounds and stuff at the previous company I was at. And this idea of like, yeah, we want to be able to have say more women or different, you know, more diversity in our hiring. It was like the challenge was you put out the the job pages and stuff and then we'd even have a recruiting events. The reality is no matter what we try to do, if the pool of people that we're trying to target is disproportionately more like white males, like it's really hard to say like you literally have to start saying these people might be very skilled and we just need to ignore them to go focus on a different group. And that's not to say that there aren't skilled people in the other groups, but like uh statistically, if one group of people has a higher representation, there's probably going to be more people in that group. So, it's really cool to hear that boot camps are starting to change that up. I don't know. Do you know about colleges and universities if like that trend of that is changing as well or is that still like very much kind of locked in like mostly dudes? we might be getting marginal benefits and in fact I think we are because of things like scholarships and things like that but those are marginal benefits in the traditional computer science 4-year programs they're still uh overwhelmingly white and male >> interesting >> and there there is some actual reason to think that there is real cultural problems in some of those programs um that that even like endow poor mental models and things like that that lead to performance performance problems later on. And I think one of the ways that you can see this in the traditional pipeline we might call it, which might take you from a CS degree to tier one with the whiteboard interviews, very traditional approach. Uh this concept of competitive programming >> and you can see that competitive programmers are not above average engineers actually. So there's this misleading coralate basically. And so that's one of those places where an overemphasis on competition can actually be harmful to team dynamics. And so that's just one example where some of the traditional approach is harmful. But I actually don't like to speak against the traditional approach. I think if we can get the new practices right, then the market will crowd out. You know, the old things will just become obsolete over time. And there's some really really cool things going on with hybrid learning and uh and basically coding boot camps. they're getting a lot of things right. What I would what I would advise employers to do is increase their source quantity from boot camps relative to to colleges. >> Um >> interesting >> on on average and that's not against you know that's not against all colleges. There are particular colleges that have like uh programs that support diversity. So you know take take this and apply it with nuance to your organization. But I think on average, if we can have more boot camp graduates hired, we'll have more diverse teams. I think that's really uncontroversial. >> That's uh that's very interesting. And again, like you're saying, you're you if you're selecting from al alternative different altering your sources of you know, people coming in, then you can actually shift like yeah the the volume of those individuals. That's that's really cool. I know. Sorry, we've been jumping around a lot because this is all super fascinating to me. So, thank you. I want to see if we go back because I'm I'm looking at your list of the of the eight items here. I know we kind of talked about the beginning like the structuring your curriculum and uh we talked a little bit about literacy, numeracy and search. So that's good. We talked a bit about front end to full stack. Um and you did also talk about uh this is kind of earlier might have been out of order but we talked about this concept of the boot camps themselves if you're interested in those going to like a 4.2 too and having like over 400 reviews that actually differentiates you uh like statistically. I think that's fascinating. One thing we haven't talked about that's kind of right after that though is like a portfolio. So when I look at this list, I think this is really cool because I think something that comes up a lot especially when I'm trying to help new software developers is like I think if you want to learn to be a software engineer, be better at building things, you need to build things. you like reading stuff is great, watching videos is great, you want to pay for courses and other stuff, great. But if you're not building stuff, in my opinion, almost none of that other stuff matters unless you're doing that. So, I wanted to kind of hear about you're saying three to five projects like what's the and there's got to be data to back this up. So, I'm really curious to hear like how you kind of came up with this approach. >> Absolutely. And your your intuition, Nick, is spot on and the research is with you that every other learning modality is second best to project-based learning. Actually doing the thing, learning by doing is the most effective transfer into actually learning. Um, I also advocate for learning in public because there are social networking knock-on effects that will benefit you at job search time. And part of learning and building in public means starting your GitHub portfolio from day one. I don't care if you commit a readme change. Get it in day one because it demarcates the start of your experience. You can point at your portfolio. You can point at those famous green squares and say, "I've been coding for a year even if you haven't been paid." So the portfolio is incredibly critical for not just employer calibration of quality because frankly employers don't pay that much attention to the lines of code. Uh if you get an employer that is interested enough not just to view the topline but to click into your HTML file and read it that is already an extremely interested employer. And so even if they find some nitpicks which they probably will because even the best of us don't have perfect code in our repositories. >> Yep. when they when they report some nitpicks to you, tell them thank you for looking. >> Don't be concerned that they looked. It's a it's an extremely green flag that they looked. But even if they don't dive into the HTML file, if they looked at the green squares below at all, you're accumulating experience. Okay. So, what projects do we build? We look at those coding boot camps. We know that the universities and the boot camps are giving employers what they want. How do we know that? because that's exactly where they're hiring from today. So, let's just ask the question, if we look at the best boot camps, what is their curriculum? What are they teaching? What are they building? The answer is they're building Next.js portfolios. They're building React. And why do they do this? Because it's what employers want. Uh there's that there's that uh famous line um electrolytes. It's what plants crave. I don't know if you've heard the idiom. >> I've not heard that. Okay. >> Okay. Okay. Um but but it's like um React is what employers want today at tier two and tier three. Basically, that's the answer. And we know this by investigating the curriculum of boot camps, in particular the boot camps with the highest placement rates. And we also know that simply by scanning job posts. If you go to indeed.com, there's a there's research on Latterly to pull the eight best job boards for you. So check out the Latterly blog and you can even download the spreadsheet which gives the line item reasons. So those job boards are selected for time efficiency as a job search candidate. Basically enabling things like an easy apply >> without sacrificing your application to interview conversion rate. So the places where you're getting jobs and you're actually getting placed if you look at these places the job postings in the web development domain. So restricting it to web development domain for reasons we already talked about. In that domain there are three leading frameworks. They're Angular, React and Vue. And among those three, uh, React is the big winner. If you learn React, you can go ahead and apply at the entry level for Vue and Angular roles as well because the employer mindset is if you've learned a framework, you can learn another one. >> Sure. Yep. >> So, there are actually more than a job more than a dozen job titles that you can apply for once you master this skill set. um ranging from UI developer, front-end developer, fullstack developer, React JavaScript developer and so on. And basically the way you do this is you do this iteratively. So you don't want to dive directly into React. This is an antiattern and many many candidates have been re rejected because they learned React before they learned JavaScript for example. >> Sure. >> And so you want to learn the fundamentals. When we talk about fundamentals, yes, data structures are an important sort of fundamental, but before you learn an abstract data structure, I recommend learning a concrete data structure. And so the stage in which I introduced abstract data structures and leak coding and things like that is when you're moving on to language number two. And if I realize that a a dictionary in Python is like an object in JavaScript, how so is it different? I abstract up to a thing called a hashmap. And this is like the perfect time to introduce data structures. But before we introduce the abstract, let's learn the concreta and let's build something specific. Okay, so we're going to build something specific with React. What should I build? Maybe let's build something you already know. That way I can hold the business domain constant. I can increase your speed of learning because it's something you already know. >> I love that. Yeah, that's that's so good. And I find that when people because sometimes I'll say, "Hey, like you got to build things to get better." And they go, "Well, what do I build?" And I'm like, "Okay, well, I realize the problem is people are like, "How do I build the next Facebook? Like I can't I can't come up with the next, you know, trillion dollar startup idea." And I'm like, "That's not what we're doing here." Like the goal is you got to learn. And the only way that you're going to do that is by building things. So the fact that you can start to isolate a variable. So for example, pick like anything any software like say any website in this case, right, that you've used just pick something that you you can hold constant and then the rest like you just focus on part of that. That's Yeah, I love that. >> And I can get more specific. So laterally in particular recommends that you build a blog. >> There you go. Yeah. >> So circling back to the most popular sort of website is the WordPress blog. So let's build a blog. Not only have you already seen a blog, but when you interview with an employer and they ask you to explain your project, they will immediately know what you mean. Now, how do we address the fact that when they push back, they will push back and they will say this is a boring, common, boilerplate sort of project. >> Sure, >> we push back in two ways. The first way is we say this isn't cookie cutter. It's personalized to me. >> And that needs to be true. So, in the Latterly curriculum, when you create your blog, you're doing things like theming it according to your personal favorite color and you're doing things like putting real blog articles that are true questions and discoveries that you had in your learning journey. So, you are personalizing your blog. So, it's personalized. It's not cookie cutter. Um, and the other thing is that you will make a blog and then you will make a capstone which is not a blog. And so, you will have a portfolio of at least two projects. We can see that will push back on that. Now, if I have these two projects, I have a portfolio. Now, I can make a portfolio site. >> But the other thing is I didn't want to jump in directly into React, did I? So, I wanted to have a vanilla blog and then a and then a and then a full stack next.js blog. So, this is why we recommend in the range of three to five projects. Um, you want to do vanilla and then you want to do full stack next.js. You might want to do an intermediary step where you don't need to worry about learning SQL yet. So there's an option to do a full stack local storage blog which has mocked authentication. Uh and then the portfolio is also optional and then the capstone is not optional. So you're going to have three required and two optional. So three to five. >> That's awesome. I wanted to add in that and I maybe I'll I'll see your take on this but my philosophy when it comes to projects again is like I think that they're learning opportunities and if someone were to hand me a resume and they had a a handful of different projects on them what what I'm not doing personally is going how impressive like from like a monetary perspective is this project and to be quite honest if someone was like I didn't finish that like I actually don't care I just want to be able to have that as a kickoff point to be like, well, this seems cool. It seems like you were interested in something. Tell me what you learned. Like, why did you pick some things? Like, where did you get stuck? Why did you get stuck? What did you try? Like, I just want to talk about that because to me that is software engineering. So, the fact that something wasn't like completely finished or perfect. I'm like, when's the last time I wrote software in the last 20 plus years that was complete and perfect? The answer is never. So, get it working. Get And if even if you're like, I got part of it working. Say it was a full stack thing and you're like, I really couldn't get the the front end the way I wanted or maybe the database has some quirks. Like, cool. Like, let's talk about it. I don't care if it's not perfect. Personally, that's my kind of take on it. >> I'm 100% with you. I think you're highlighting three things that are pretty important. One is in programming, we have a common idiom, which is get it working and then make it work better, >> right? So, um, anytime you get something working and then you make it work better, if you're able to describe how it was better, you have created a star method entry on your resume and you have a metric that you can add to your resume. You make the resume pop. You can give a behavioral answer. >> I love that. >> So, make it work and make it work better. This is something that um is really important, especially as a senior. At the junior level, I actually agree with you. It's less important to have quantitative metrics on your resume as a junior. If you can just show that I have projects, um, that will make you stand out from the crowd. If you can show that you built something and then you made it 20% faster, you're in the top 5% of junior developers. Like junior developers just don't do that, >> right? Um, the second thing that I think you're you're highlighting or maybe yeah, maybe this is the third I guess depending on how you slice up the bullet points is the importance of connecting with a developer at social networking time. >> If I'm going through the traditional resume process where an ATS will scan it, it will get prioritized by keyword density and then a technical recruiter will review the top slices. The technical recruiter might click on your GitHub link and go, "Okay, it exists and they have stuff there. great. They don't have the generally with some exceptions and there are some surprisingly technical recruiters but they're rare um in general they don't have the ability to distinguish what qu what counts as engineering quality >> and so >> and so for them they will think it is important that the project works in their mind if they click the link and if the site says 404 that's a red flag where if something shows up even if they don't know how it's implemented well clearly it it works. Right. >> So, what you're speaking to is the importance of social networking with a developer who can actually override the recruiter. Because news flash, if you have a conversation between three people and they're trying to decide on whether to prioritize your resume, one is a hiring manager, one is the top engineer on that hiring manager's team, and the other is the technical recruiter. The least important voice in the room is the technical recruiter. >> That's a that's fair, right? because they're primarily doing the sourcing and kind of that initial funnel and the they're leaning on the others for like basically scoring or you know grading how how others are doing. So yeah, that makes a lot of sense >> and there's a cheat code here. I agree that makes a lot of sense and there's a cheat code here. The cheat code is if you can network with that engineer which sometimes people will underrate in the interview process. They think well networking with the hiring manager and the recruiter is what's going to get me that interview right? Networking with a senior engineer is a cheat code because if you can get them to look at your portfolio, they're going to tell you something is wrong with it. They are a senior engineer and you and even if you're a senior engineer, senior to senior, they're still telling me something is wrong with it. >> And here's where the cheat code happens. You say thank you and fix it. >> Now your resume is the top resume in consideration for that team because you've shown that you're coachable. you've shown that you are like appreciative and the social capital there is extremely valuable. >> Well, okay. And I this might lead to I think I got time for one more thing on your list because I think we touched on a couple of the end ones, seven and eight in the beginning, but number six is really like right on this point I think. So, coding round and then behavioral prep. So, what you had just mentioned was something about being coachable. And the last thing that I kind of want to dive into a little bit here is like talked about building technical skills, how you're going to be looking at your projects when it comes to interviewing and well software engineering in general. This is one thing that I think does translate very well between the two is like software skills and I sometimes don't like saying soft skills. I'm trying to just call them human skills now because I think these are things that we just should be doing as humans and one of them say is communication, right? Like I'm curious when we go through a list like this and we're trying to prioritize, you know, how we can land jobs, how we can make sure we're doing good as software engineers. How do you layer in what might be considered more soft skills? I heard you say coachability, right? Like that's a really awesome one. Where does that kind of fit in here? It's precisely showing coachability and showing soft skills which makes you such a high quality candidate and a differentiated candidate. In the scenario we just went through in the research on postsecary uh alternative credentials and employers attitudes on those credentials. The single biggest variation skill gap is in soft skills between traditionally educated and alternatively educated individuals. So, there's this hot debate, who's the better coder, the coding boot camp grad or the CS grad? And people talk about this all the time. The truth is is that they're both quite good. And they're both terrible with soft skills. So, if you can demonstrate that you have soft skill in addition to either a degree or being a boot camp grad, if you can also show that you have soft skills, you have rocketed up your perceived value in the eyes of the employer to the top of the stack. >> Okay. And this is perfect because I need I want to pause because I've been saying this and I don't have data and I know you're the data guy. So this is this is perfect. Now people I can I'm going to cut this into shorts and post only this for the rest of eternity and say look you need soft skills. That is your differentiator. You need to do this. >> That's right. And you can look up I believe it's in the journal of economics letters if I'm remembering that right. Uh the paper is something like um attitude preliminary attitudinal trends. Oh, I'll have to get you the proper can I can I take two seconds and look at it? >> Yeah. Yeah, for sure. >> So, it's the journal of applied economics letters, preliminary attitudinal trends and alternative post-secary learning is where you can go to see the measuring of the skill gap. That is the difference between boot camp grads and traditionally educated in the eyes of employers. What are those gaps? There's a reason that computer science programs include team projects. Um, it feeds these behavioral interview answers. If you're able to say, well, I haven't done any professional work, but I worked on this team. We overcame this obstacle. We delivered this goal. >> And so, I've I've been an advocate for building in public and learning in public. Another I'm also an advocate for social learning. So, we talked about project-based learning. There's also the concept of social learning and social emotional learning. If you can build in these components, you will learn better. It will form stronger connections in your mind. You will actually learn the material better and it will also pre it will also prepare you for a behavioral interview where if you have a hackathon team, you can you can speak about that as a junior. Um, and so I think these are are perfectly good behavioral answers at the at the junior level. >> That's awesome. Yeah, and like I said, thank you for sharing that part because as you know, I am a software engineer at heart, but I've been an engineering manager for I don't know like 12 or so years now. And I don't sometimes I feel like I'm saying this out loud and people are like, "Oh, like whatever. Like that's just I don't know like you're an engineering manager. I have a different perspective on it and you don't relate to software engineers." But I'm like man like no like as a software engineer working with other software engineers communication teamwork collaboration all that stuff made a world of difference. And when I'm managing people and hiring people like these are things the like a lot of the technical skills I'm like man if someone's got the right attitude they want to learn they're demonstrating all these other things I'm like I'm happy to teach them like I will invest my own personal time because I can see that they're like they're motivated to do it. So a lot of these other things I think make a huge difference. That's That's awesome. >> Well, thanks for having me on here. It's been great to talk to you. Hope we can do anything. >> Yeah. Yeah. I I really appreciate the time. So, John, I know you were kind of saying Tik Tok is your your number one spot. Where else can people find you at? >> Well, GitHub. Uh github.comvande. Um and then that will give you a link to my other social from there. >> The other major platform that I stream on constantly would be YouTube. Cool. >> So, Tim talk will be great for my shorter form material, but if you want to see any of the live coding streams, whether it's open source development or or doing some of these algorithm problems, that's saved on YouTube. And there's a bunch of YouTube playlists with uh saved older episodes as well. >> Perfect. Well, John, thank you so much. I would love to have more conversations in the future and find other ways to collaborate. This is totally cool. Um, I love all the data and I think that's something for me that I'm probably missing in a lot of the things that I'm trying to educate on. So, just wanted to say thanks again because this was awesome. >> Good to see you.