The Swyx Mixtape

swyx: I can just get going with my prepared slides. It's going to take me like half an hour ish and then we can do half an hour of questions. Does that sound good? And then, yeah, just like, feel free to pause me if there's any technical difficulties or anything.

[00:00:13]This is something that I never thought I would. Write about or specializing. It essentially was an R com of my blogging and like people really responding to some of this stuff that I've written for them.

[00:00:25]And it's essentially like the meta code stuff around code. Yeah. You've learned as you go along, that nobody teaches you. Like w when you tend to think about coding careers, like your career as a software developer as just about code, when really like it's maybe 25% about code. And there's a lot of other stuff around that.

[00:00:44] So this is what I ended up doing in between jobs. Like I wrote essentially like a list of essays that became a book. And that's the whole idea. And I was invited to it. To do a talk with you guys about it. So I'm going to share what I have right now. And I'd love to go into further detail because there's just too much to go into it with you in 30 minutes.

[00:01:00]So I'm, Swyx I also go by Shawn. I used to use to have a career in finance change careers in 2017, did a boot camp instead of like a proper season.  When did you to Sigma? Netlify and now I just recently joined AWS. And we already talked about the other stuff. One of the, I guess, one of my other roles, if you're into front end development at all is that I may react R slash react or Jess subreddit moderator.

[00:01:24] And I think we're about to hit 200,000 subscribers tomorrow. So that's pretty exciting as well. So. What, this is what this attempt is. I just want to situate them this among the other advice that the other books that you've heard about as seen a lot of books are very sort of pointed point in time solutions, essentially like their target, like learn to code or.

[00:01:43] Crack the coding interview or like, solve the algorithm design or like, do you do a great resume or, write about clean. And so these are like just very point in time solutions, but they don't really help you with the transition steps. And so what I essentially tried to do with this book was essentially layout things which Principles, which are basically like always on default decisions, strategies, which are like, which helped to help you decide.

[00:02:09] And based on one-off big uncertain irreversible decisions and in tactics, which are things that you use frequently throughout your career. So that's the way that we're gonna break it. And and yeah, so, so basically like there's four parts to what we so how do I, how I break it down.

[00:02:23] And the first is the career guide. And one of my obsessions is the OSI layer. I think if you're doing a lot of tech interviewing, I think that's one of the first models that used to be. Come across from essentially like the network layer, I'll be out to applications.

[00:02:36] And I don't remember what the other five layers, but I was always thinking like, what if there's an OSI layer for humans as well? So instead of just protocols and and data, we can also talk about how humans form a chain of value from machines all the way to end users. So we have here the entire universe of coding careers going from, I guess, people who work the closest with hardware.

[00:02:57]Operating system devs or embedded or IOT devs all the way up to people who don't actually code technically traditionally, if you think about that, they're they might be considered no-code low-code they might micro settings, which have some sort of conditional logic, whatever.

[00:03:12] Yeah. These are, that's the mental framework. Most of us developers are actually, we're going to live around here between applications for the front end and services for the backend. If you are, if you aspire to be more of a, like an infrastructure cloud person, you might work in the lower layer on the product and the sort of platform level.

[00:03:27]And that's how I split things. You may have a different split. It's good to have a mental model because the way that you interview or a plan your career for each of these levels is very different from each other. So I think that's an also interesting mental model to have when you approach these things.

[00:03:41]Next this is more about the job jobs searching thing. Quite frankly, if since all of you are in the MLH fellowship I don't think this applies to you at all because you're going to sail through your job hunting task. But I think I recommend this book was from  where he talks about like the mathematics of job hunting and it's essentially the same.

[00:04:00] As the birthday problem where you don't actually need 365 people in the room to have a good chance of two people having the same birthday you actually need. Cause because the probabilities compound same reason, same reasoning for applications. And because you only need a one job offer out of all the applications that you send out.

[00:04:18] So that's kind of job hunting advice. Well, I know it's very simple numbers matter. Right. The other thing I think to think about when it comes to, when it comes to job hunting, especially for new grads and people who are just like, getting their first experiences without a network is that you can choose a wide range of strategies between narrow and I guess, wide.

[00:04:35] Some people go as far as, as high as 200 to 300. And for me that I prefer to do nine prefer to do a more narrow search. And it's really up to you the kind of, search strategy that you choose. But just be aware of that. Obviously, if you spread yourself out very thin, then you're not going to do a very high quality application on each one.

[00:04:52]Whereas the narrow application, you may not actually explore the full space of possibility that might be a best fit for you. So there's downsides to both in upsets. I think the most important thing to do during the job search is basically to have continued discipline and motivation.

[00:05:06] So do so one way to do it really well is to do sort of social pressure, like to have a small group of friends and do stand ups with them and say what you did, what do you plan to do? And then just like consistently meet up until you, y'all get jobs. The other thing I think that people neglect to talk about.

[00:05:21] That's the long longitudinal process, but what about during the day? That's what I call times. That's how you organize your time doing doing your job search. I won't go too far into details just because I also don't expect you to face much of a trouble with this. In terms of like portfolio pieces and like proving yourself.

[00:05:38]This is  from Google. He's a very experienced hiring manager and I think what he says here is very true. So you can see who's going to quote verbatim. You can impress most hiring managers with only three contributions. Just like one class with a single JS followed, but just like show your best work, something complete where you show like all the other stuff, like tests, like architecture, docs, whatever.

[00:06:00] And it's something with a story where you can actually stand out with the, of your personality or like something interesting that, that sets you apart from from just a raw technical. Yeah. And I have more stuff in this with regards to the hiring funnel. Let me know if you're interested in all this.

[00:06:14] I'm just going to skip past this because that's not the focus of this presentation. But oh, I'm going to highlight this on mine as well. Twitter is. Surprisingly central it may not be for for your cohort right now. But as far as I'm concerned in all the developers circles, I see Twitter is very central.

[00:06:29] And if you can pitch yourself into 180 characters you get to you, you get to be spread by a lot of these other developers who are looking to elevate you as well. So that's very helpful for the jobs. Okay. So, more interviewing resources. You don't need this, you don't need this. We also, we, I also studied a bunch of junior to senior dev stuff and that's that's a whole chapter, which I can get into.

[00:06:49]Again, like I don't, I'm not gonna spend too much time here, but we can go into doing Q and a, if that's something that's of interest to you. I think the goal for you in particular is that you're getting a lot of explicit knowledge, in your courses. And that's stuff that people have written down like books Talks like stuff that people know that they know, and they've taken the time to share with you, but there's especially now on doing your fellowship and in your projects and later on in your jobs, like you're going to be picking up a lot of the tests and knowledge, the stuff that you only learn on the job because you have to live through it to, to expert to experience it.

[00:07:19] And that's actually the majority of like, software engineers value added, right. The stuff that's not in the book. And so. Anytime that you're, you have the ability to to expand the possibility boundary of that space between explicit and tacit knowledge. That's a really good thing to actually start writing down, whether it's for people who, are com or coming into cohort after you or just like your past self that's always very helpful.

[00:07:41] And that's what I'm trying to do with this whole project is which is just to relay things that I've learned as a. I guess now senior software engineer. So that's that, that brings us to the principles strategies, and tactics section. Sorry, I'm rushing too much, to be honest, I should probably pace it a little bit.

[00:07:56]Okay. So, why principles? I strongly recommend checking out this book by Ray Dalio. He runs his entire hedge fund based on principles and this idea that you should, it's okay to make mistakes, but it's not okay to meet them repeatedly. Every time you like learn something fundamental about how the world works, how you work, how you prefer to work with the world.

[00:08:14]You should write it down and you should stack rank them so that whenever they come into conflicts, you have some way to resolve conflicts or you, you have some idea that these are two principles that are at odds and you need to find some other unifying principle to, to deal with all that.

[00:08:28] So for me the one the one principal that I'm most known for is to learn in public is it's this idea that most developers are trained from the beginning to, to learn in private that everything that you retain you're tested on it. You keep it to yourself. And you're the way that you get ahead in life is that you do it, you do that better than the people around you.

[00:08:49] And it's a very zero sum view of things. And I think that if you open your mind up to a more growth mindset, where you can share what you learn and you learn you yourself, learn faster as a result of that, because people get the chance to correct. You got to. The chance to be wrong in public.

[00:09:03]And and you build your network at the same time. So that's a very short summary of what has become like a movement as far as developers are concerned. And you can check the essay out at six, that IO slash lap. But that's the core idea that I think, especially for us students you're going to start to transition.

[00:09:20] And when you transitioned from the. The sort of zero sum world of college too. To the more positive some world of I guess real world collaboration. You'll see that they're there. W the kind of games that we play it's in real life, or it's very different from from the sort of academic competitions that they might be used to.

[00:09:38]

[00:09:38] It certainly was a a huge learning for me. And the other thing, I guess, that I, that would. Share with you is, I used to be in finance. And we so I worked in investment banking and hedge funds and the intellectual property that we had that I worked on that was on the, like the best work of my life.

[00:09:54]I. I like, I laid it all out at the hedge fund. And when I walked away from finance that stayed with them like that was property of the fund and never with me. And I'll never see it again. When I interviewed with other. I couldn't take that with me to interview with.

[00:10:09] So like, it was just, it just made it really hard to transfer experience and that makes it really hard for you to scale. Whereas I think in tech it's, we're fundamentally more open, like, we are allowed, we're encouraged to share our learnings in blogs and conferences and even our failures as well.

[00:10:25] We also share our outages and our retrospectives on of our failures.  If we don't take advantage of the fundamentally more open nature of tech, then we're missing out on. What's so great about this industry. So, I do tend to encourage people a lot to to be more public about what.

[00:10:40]It's really good for compounding your skills and knowledge and network. So include a bunch more principles and again, we don't have, we don't have a lot of time to go into all of them. The other thing I think I do tend to encourage people on is to open source your knowledge. So basically it's this idea that open source code has, open source coding.

[00:10:57]Didn't use to be the norm. It's this revolution now that, most things that we use is now by default open source. And I think that's something that's happened very successfully with code, but we haven't done that a lot with knowledge like the sort of architectural and principles.

[00:11:12] And. Are there less computer savvy skills, but there's this sort of more meta skills around our knowledge. One of the ways in which I exemplify this is my, my work with react and TypeScript. So I essentially run the community react and typeScript docs. And that was mainly because.

[00:11:29]Reacts. Wasn't doing good job of documenting its interaction with TypeScript. TypeScript was not doing a good job of documenting reacts. So I came in and did the intersection. And I think what that experience taught me was that was that, that, that became a community and a repo of knowledge.

[00:11:45] And that was more That compounded way better than a set of individual blog posts, because that has like a individual like decay in terms of the value. So it just like, you'd rather choose to have this one asset that you just compound in value over time, rather than this this blog where you just have little bit little bits and impulses of value as you put up blog posts.

[00:12:06] And I think. That comparison between open source knowledge that you have some sort of like, obviously the most successful examples, Wikipedia that one spot where everyone just funnels in and contributes knowledge and builds up the best example, best single example. One thing is actually more valuable than a series of one-off events.

[00:12:25] So I think, I've taken too many words to explain that, but I think that's the rough gist of it. So  that's Principles. 

[00:12:30] Principles are things that you should always default to in absence of anything else. But a lot of the times you also have to think about the strategy of like, you're learning your career and your technology.

[00:12:41]And those are the ways in which I want to encourage people to think more strategically instead of following whatever preset plans that you see other people that you do. Like you need to take more ownership of your career, right? And so, in terms of learning strategy I talked a little bit about this concept of learning gears, how you should behave differently based on the type of things that you're trying to learn.

[00:13:01]When you, the way that you learn when you don't know, what you don't know is very different. That's your Explorer gear is very different from the way that you learn when you know things that others don't know. That's your teaching gear, your connector gear. Even that's even more different from the way that you behave when you find something that is super important, that you're obsessed by.

[00:13:18]And no one else was working on it. So you're diving deep into something that nobody else does and that's valuable. So that's like your it's also, I always think about it as your builder gear. These are all just like different ways of different modes of learning, but it gives you permission to behave differently.

[00:13:34] So, it's like a short hand as far as people who do this are concerned to, to convey like The kind of outputs and commitment level that they should be that they should be adopting. So for example, Explorer, like nobody really expects that much from explorers. Explorers are just putting out in those to themselves.

[00:13:49] Whereas miners are putting out infrastructure R and D communities and they build the build up things to last years and on the auto years in careers, which is pretty. I guess like a fundamental insight for people who are, who have dabbled in all of these things and they viewed them all.

[00:14:03] It's the same thing. They're not they're they really differ based on the kind of gear that you're into. The other thing I think in terms of like, people's specializing a lot of people. Debating this idea of specialist versus generalist and everyone basically converges on this idea of a T-shaped model employee.

[00:14:19]This is from the valve handbook. So if you see this a lot, that's where it actually comes from the makers of half-life. And I tend to not be very inspired by this, basically, because it's not useful. Like everyone is some form of T-shaped employee. So. We're all, especially as in some ways in journalists and others.

[00:14:34] And I think the more insightful thing is where to be on technologies. So I don't have a slate here for that. But essentially we can get into that if you're interested in my thoughts on that career strategy did you know that a lot of companies actually publish their career ladders in public?

[00:14:49] So what if you just went through and studied every career ladder out there and that's exactly what I did. So here's the. The spreadsheet. I might also just share it with you cause I'm not publishing into this just yet. So, you're actually the first to see this. Cause I figured why not? I'll just share it with you.

[00:15:07]What have we just went through and. Every career ladder of every company. And we tried to see what was the similarities among the different levels. And you can see, you can start to plan out a roadmap for yourself in terms of your personal development. So that's essentially what we did over here in this research project.

[00:15:22] And that's what I wrote up in, in the chapter on career ladders, but it's, you can see how, like, it's hard to put in any concrete terms whatsoever some uniforms. General theory or career of coding careers. Except when people actually specifically lay out their ladders.

[00:15:40]And you can do something like this where you can just normalize them across all the different companies. So it's an interesting, it's an interesting exercise and it definitely gives you a map of what your career could look like. Over a super long-term like we're talking. 10 20 years. And so this is, these are not the kind of conversations that you normally have, but I think it's worth having.

[00:15:59] Right. So, that's what you think about when you think sort to think strategically then the last bit of strategy, I also want to want people to think about the business of software, like the business of tech, how money is made from your tech. Yeah. And that directly affects the way the companies you choose to work at the projects you choose to work at within a company, the technologies that you choose to bet on the technologies you use day to day, these are all effected by tech strategy decisions.

[00:16:24]So we talk a little bit about the difference between horizontal versus vertical industry. It's like all industries start vertical and then the horizontal lines as they specialize. And then we talk about business models as well, like agencies, advertising subscriptions. Basically a lot of things start vertical and then they split out.

[00:16:39] So here's the famous chart of how Craigslist is being split out into all these different small startups and all of them are worth like billions, each. We also talk about mega trends like gaming. So, one of, one of the things that, I mean, you guys are probably more aware too, because you're in that demographic.

[00:16:55] Whereas I guess people in my generation and older you not be that aware of is. The sheer explosion in terms of the gaming industry is unmatched compared to all the other media industries. And there are strong reasons for that, and I can go into, and I can even go into why. But it's, if you view all these industries as the same, like working for Spotify is the same thing as working for a 10 cent or what's the other gaming company that I'm blanking on right now.

[00:17:20]Whatever  th these industries are performing differently and I think it's it behooves you to bet strategic strategically based on the industry. If you care about these things in terms of your own career the other thing I think to be aware of. This sort of tech adoption curves.

[00:17:35] So we talk a little bit about crossing the chasm, like th those classics. But also the fact that technology adoption is accelerating. Like it took us this long to adopt a telephone. But now we are, we're adopting technology at a much faster rate in terms of your population percentages.

[00:17:49] So these are all very interesting ideas that people really talk about when it comes to. And I'm not going to talk about this Wardley mapping. Okay. And then last part is tactics. I think people are always interested in like small things that they can do to improve. So I collect for example this list of of nice design tips developers always interested in design tips.

[00:18:08] I'm not the best at design myself, but I think if I can. Spend like five minutes to like, bump up the look of my thing that increases the people who who, who will try my stuff out. And their enjoyment of my products then that will be that's actually a very high ROI activity to do.

[00:18:23]There's also this idea of like, there's also sort of workplace tactics that you can employ. So for example, when you're When, like you're, we're often told that knowledge is power, but sometimes we can actually turn ignorance into power as well. And that's a lot of what I call lab shading, like, just call calling attention to your biggest weakness so that no one else can and then making that into a strength because of your position your positional advantage.

[00:18:45] For example, if you're very junior or you're very senior, you're allowed to not know things. And I think that fundamental assumption helped me a lot in my first job.  And then writing's like brings a huge skill for just compounding your learning in your knowledge and your reach.

[00:18:57]Part of the reason I'm speaking to you today at all is because I wrote I've wrote, I've written a bunch of stuff. And I think the way that people view writing is they don't take it very seriously. Right. It is, if you intend to be a knowledge worker at all, you need to store your knowledge and you need to scale your knowledge.

[00:19:13] And a lot of that takes place through writing because it's the most scalable medium compared to everything else. So that's that's what we, that's what we have in terms of like writing strategy. I can go into more detail about this as well, but I don't want to bombard you with too much.

[00:19:25]And then I think the last piece that I always touch on that strikes a quarter of a lot of developers is that they need to market themselves. And it's very much, I think people are aware of the idea that if you build it, they may not come like a lot of developers have this idea that.

[00:19:38] Okay. When I, whenever I do any project to do any startup I'm just going to do a bunch of code first. And then at the end, I'm going to poke out a full code of my hole and just say, all right, it's done. And then you get crickets. Cause no, cause nobody knows what you work on and you haven't spent any time on the marketing.

[00:19:54] It's the same thing with regards to your own coding skills. If you just become the best coder that you can possibly be, but you'd never spend any time on marketing yourself. No one is no, one's going to know how awesome you are. So you shouldn't use, you do owe it to yourself a little bit to to market yourself in public and network.

[00:20:09]So that's and that's that I also, I, I end the book with the Coda for sustainable careers. So I think a lot of there's a lot of, I guess, developers struggle with burnout in our industry. And we need to have a way to pick up all these loose ends and into tied in together into something that, that unifies the full stack of what we are from, our our personal selves to all, to the, to other people's image of us.

[00:20:31]I think, imagine, and the way I pitched this is that we need to have an operation, the system that runs all these principles, strategies, and tactics. So these are all like applications of what we are, but even if we had the answer to everything the reason that we don't actually benefit as much as others from them is because we don't have a system to implement them, to make them to meet that as effective as possible.

[00:20:51]So I actually ended up with a low call to action to take care of, the small things like the like, well, small, but huge health. Yeah. You're your own personal scheduler. You're your internal model innovation and drive. These are all important things that I think are. Essential.

[00:21:05] And I've given a separate talk on that. It's called the operating system of you. And I think, we should all think about how we deal with unlimited applications, but limited resources. And that's essentially what operators is operating systems do. And we could start, we could take our learnings from how, we, I think we've developed with science, how how operating systems do that.

[00:21:23] And we could take that learning and apply it on how we govern our own lives. And I think that's a very interesting analogy that we can explore as well. I've been talking nonstop for half an hour. But that's the idea, that's the book, right? If you want to go check it out, there's four free chapters on there.

[00:21:37]That give you more of a sense. But I'm not here to sell the book. I'm here to have a real chat with you on whatever topic you want. My time is yours and yeah I'm happy to take it.

[00:21:46] Q&A 

[00:21:46] If you've worked with junior developers, what's the biggest mistake you see them making and how would you go about solving it if you were in their shoes?

[00:21:54] Yeah. So biggest mistake I think is pretending, is feeling like you have to pretend, more than you do. It just kinda, it was just the idea of lamp shading, which is the sense of you're a junior developer, you want to show that you have value and you are competent.

[00:22:13] So when people ask you to do stuff, or w if people ask you that, whether you understand stuff you say that you do that actually like people will take care of your word and they'll trust that, you know what you're talking about. And if you, if it turns out that you don't, or you, it turns out that you're missing knowledge in some way, There's two things that happen.

[00:22:30] Like one is you you miss out on a teaching opportunity. Like people teaching you things that you already know, like that's actually not the worst thing in the world. But it's probably true that they'll teach you something that you don't know, or they presented to you in a new light.

[00:22:45] I think that's a very valuable sort of. Experience to have. And then the other thing is that you lose trust. If you start to present yourself as more competent than you, then you are I think it's better to be, to lampshade your vulnerability and say like, I have some awareness of this, but it's only theoretical.

[00:23:01] I haven't really worked with it in production. And like, can you walk me through this, the stuff that I should know. And just being humble enough to admit that, like that, you're. You don't know, everything is a very good learning strategy in general, but especially for junior engineers, because do you knowing that like you're not at risk.

[00:23:18]And I think people feel very vulnerable, especially when they start out, but that is when you're the most invulnerable because it's their job to take that responsibility on. So, make the most of it. Cause you don't get much of a shot afterwards, I don't get much of a shot for that these days.

[00:23:33]Prevents you a tree. It's an amazing analogy. Okay. Yeah. Totally right. Like everything that we apply and translate machine learning all the way down to operating systems. These are general rules that we've systematized and we have the algorithms, we have the source code.

[00:23:47] That's amazing compared to. The fuzziness of the human world. And I think if we can take those general rules and apply to our world, I think those are just generally very interesting insights. Because those are clean systems and then we apply them down to the messy systems that we are.

[00:24:03] What should be the aim when job hunting big companies or startups?

It's up to you? So I I, I have, I actually have three categories when I talk about the job hunting section big companies, startups and agencies. Obviously, I think I do. I do agree that agencies tend to be the most challenging, but these are all, these are good starting points.

[00:24:19] I've seen people be extremely successful. All of them personally I have a preference for, because so, for me it was it was down to Google or to Sigma. When I had my first job in two sandwiches, made a better offer.  Big companies give, generally tend to have a better junior training program.

[00:24:35]And they have a brand name which makes your subsequent hires. Your subsequent job moves easier. Whereas startups and agencies don't have that cachet with them, although they may give you more generalist learning opportunities because you're more responsibility because of the downside of yes they may pay well they may have better resources, but then you might be a cog in the wheel and not do very much.

[00:24:56] Which is a risk. Okay. So if you had the knowledge you have today, back when you started, what would you have focused on getting better at first? Oh wow. I gotta think on that one. Holy crap. Getting better, I think. Hm. I think getting better at shipping projects. I'm not very good. And like I'll straight up admit that I'm not very good at shipping projects from end to end.

[00:25:19] Like I can do, I can take down a JIRA ticket and, knock out an issue. And that's like a one day to one week affair, but to work on something for like three months and be responsible for the entire stack for them. Hello world, all the way to the market marketing and taking payments and customer support.

[00:25:35]That's something that I've only done once in my life, like right now. And I learned so much during that process and I think, I wish I did a lot more of that, like shipping side projects a lot more. That's something that. I've done a little bit of in, in terms of, I think one way to level up is to clone open source apps.

[00:25:49]And mainly that's because you get a chance to compare your implementation with other people's implementation. And then also you might get the maintainers of those applications to review your work, which they have for me. And that's free learning. And I think I didn't really get that until I traded a couple of times, it's a lot of work. But I would definitely, if I had more time, I'll do that. 

[00:26:06] Can you expand more on the differences between being a junior software engineer and finance to Sigma versus tech? Okay. So just to be clear I was in finance in in different companies when I was in two Sigma. I was a software engineer, but when I was in finance, I was a trader.

[00:26:21] I was an investment banker well trader and analyst junior software engineer in finance, reverse tech. Yeah. I don't know. I don't know how to talk about this one. So it's too general for me to give you a good answer. Like Fang itself is a massive fricking category, right? You've got Facebook on one end and you've got AWS on the other end and they have very different audiences. So Fang itself is too huge to generalize.

[00:26:43] And it's just not a great question. So, I don't spend too much time thinking about that. Since he came from finance, how do you find breaking into tech?

If you don't have contacts, do you have any advice in terms of contacting real people or companies to show yourself in the best light possible?

[00:26:54] I'm not sure. Cold calling recruitment email addresses are the best thing to do, actually that can help cold calling. Let me show you this cold email that I found from the edit the other day, cold email, cold emailing.

[00:27:06]This guy directly cold email. Oh God. This guy directly called emailed Evan Spiegel, the CEO of Snapchat. And he just made it right to the point. So I'm going to call this told email textbook cold email. So that's check that out for Colby bill. I mean, I don't have a lot of advice on that front because I got lucky.

[00:27:28] I, did a boot camp in New York and at the end of the bootcamp, they have a hiring day. And the first person I sat down with on hiring day, that was the first, that was the two, my my hiring manager to Sigma. And it turned out that I got the job with her after two months of back and forth.

[00:27:44] But We all have different stories breaking into tech. Mine was just straight out careers or career transition through a bootcamp. So we all have different stories. And I think networking is always a great way, but like as long as you can pitch yourself in some unique way, that's that makes you stand out.

[00:27:59] I think that gets you in front of the door faster than other people. We are in a very weird time right now, where there have been a lot of laid up layoffs. And so there's a lot of senior software engineer talent from places like Airbnb and Uber that will crowd out some of the more senior level positions.

[00:28:13]But I don't think you should be that wording for where you are at. And the other thing that you should always be aware of is that, the general demand for software in the past three to four months has done. In, in, in every category from e-commerce to social networking, to, to sort of office software, I don't know what you call it, but so there's a huge demand for software engineers. You're in a great time to be in software stick it out. 

[00:28:31] How easy or hard is it to change your field?

Seeing clients who is both Korea and software development in three or four years down the line, you said Jeff one field together. I don't know anything about AI. So I'm not going to comment about that.

[00:28:45] I think just as a general software engineer, you have a very flexible skillset and that's a blessing compared to other industries. Like I have friends who are lawyers and doctors and they're not as transferable as we are. So yeah. It's good. It's easy. I'd say that. Our salon, do you prefer crash courses over official documentation to quickly catch up?

[00:29:03]Yeah. So this is something I have a strong opinion on. So think about the levels of learning a very simple sort of. Tiers of learning is like three tiers, like beginner, intermediate and advanced. Okay. Beginners need the quickest way to get from, to get to hello world. Right? Like to get from zero to something productive.

[00:29:21]Advanced people only need the diffs. Right. I know what I know. I know the state of the art, just let me know. What's changed. The intermediate people are the people who actually know. To fill in all the gaps and they don't like, they may feel too confident. They may feel they may, they may just not know everything that they should know.

[00:29:37] So. You take a crash course if you're a beginner, but the, you take the official documentation or the source code if you're intermediate and I always encourage people if you want to go, if you want to really level up do like do the hard work of like read technical books from cover to cover and look out for the stuff that isn't covered that much.

[00:29:52] And people are like, not even really willing to talk about that much because it's an unresolved issue. That's where you you actually find the most opportunity for growth and Deep investigation. Yeah.

What do you think about product management and how would the graduate set of career path aim towards that?

[00:30:06] Yeah, so I actually have a chapter on, beyond a coding career. So something that maybe is not so obvious is that a lot of people actually graduated from coding to non-coding. And whether that's engineering management or product management or being a founder of being instructor or whatever.

[00:30:20]These are all these all, interesting career paths. Product management. So, I think something on the order of 60% of PMs are former software engineer. So you're actually, you actually well-served, if you are a software engineer Quite well of it and well-run companies.

[00:30:35] And I think quite poorly of product management at shitty companies mainly because I was at a startup that had PMs where the PMs would basically glorified project managers. So, part of pro product management is also project management where you're corralling software engineers to fit towards some kind of business goals.

[00:30:52]And a lot of the times, if you're not really con if you're, if your software teams are not really jelling or working well with you then you're just scheduling weekly updates, asking if if they're delivering there or not or if you're not being empowered by your upper management.

[00:31:06] Then you're just executing on someone else's vision and you're not really being CEO of the product, which is the selling point of product management. And the other thing I think it's is the problem with product management is that you're given, it's what they call it.

[00:31:17] You're given all of the risks, all of the responsibility, but none of the authority, which means that nobody reports to you, but you have to, but you're responsible for the P and L right. And you have to wrangle by charm or begging other departments to work with you to deliver some shared goals.

[00:31:32] So there's a lot of like, I guess, political navigation that they may need to do. That's like the cynical view or you might, you might view that as like the buck stops with you in terms of like where where this sort of product or business unit goes. And you need to be able to be able to work with, senior engineers and other senior engineers marketing.

[00:31:50]Design whatever to to deliver something that users will love. So probably mentioned is like a very multi-disciplinary thing. But you're going to be well-served if you start off on the software side of things how would it graduate set of career path into ours that like study strategy, study tech strategy?

[00:32:05]The stuff that I covered very briefly in terms of business models of tech what's the horizontal versus vertical stuff like that. I can give you a lot more resources. Just email me. I'm just a type in my email over here. Cause I care a lot about strategy as well. So, just email me more questions about product management and I'll set you on the right path in terms of links and resources delivering projects early versus enforcing quality.

[00:32:24] Which one do you prefer? Does AWS have a priority among them? So I'm only two months into AWS, so I don't really have a good sense. The real trade-offs. I know what they say, but I always, I'm always mindful of the difference between what people say they do and what they actually do. What they actually do.

[00:32:40] Well, what they say they do. Is that there is a high level of quality enforcement. So, and this goes down all the way down to docs, to tests to thinking about the different edge cases. And because AWS has a million products, a lot of that is the comment torics of like, I want to ship this new feature, but how is that going to work with these other a hundred different features as well?

[00:33:00]So to me, that's high quality that you have to think of all these use cases. The other thing about high quality is that once you ship something, you have to maintain it. It always never deprecates anything. So that's the other thing that you got to think about forward compatibility as well?

[00:33:13]I prefer delivering early and often, but then iterating continuously. So I don't think that's like a strict, trade-off like either early or it's good. You can deliver early and then iterate until it's good. So, it's really up to you.

What's the best or correct way of approaching a recruiter slash employee to get a referral?

[00:33:32]Hm. So this used to be easier in the days before COVID where you could actually ask someone to to, have a coffee or take a walk with you. I in New York, it's really nice to ask people out for walks because then you're not sitting all the time. You're actually out and about and enjoying the outdoors, especially now.

[00:33:51]During COVID it's a little bit harder. Sometimes you might just need to schedule a zoom chat and in the mattress we have half an hour, like, tell me about what you do. I'll let you know your day in the life and like how the company works and all that. I actually tend to encourage people to not to get, not to be too zeroed in on this referral because they're going to offer it to you.

[00:34:10]Most like it, it doesn't cost us anything. And. And so they're the referrals, the easy part, the difficult part is really understanding what they do so that you have good answers when you go through the interview process and when you have to decide on which job to take and yeah, referrals don't cost anything, like everyone, everyone can refer pretty easily.

[00:34:28] So that's not the, that's not the issue. The issue is really understanding on a fundamental level, what they do and figuring out whether that's something that you want to work on. 

When hiring someone and looking at OSS contributions, how would you rate it from very different projects are more well-known? Friday's considered more highly, or does it depend on how technically sophisticated the project is, or it makes a different factors.

[00:34:48] Wow. Big questions. So at a very simple level, if it's a project that the company already uses, or I already. Then I'm going to read that more just because I'm more familiar with it. And it's almost like a gratefulness thing. Like thank you for working on something that I use. And I've seen this, I have a quote from Josh Goldberg at teachable who says that any, like anyone who's contributed to in a non-trivial way to a project that they use at work gets an interview from him.

[00:35:14]And yeah, it's just something that people don't explain enough. Well, first of all, it's not easy to contribute to something like a Webpack or TypeScript. But if you do it, it's not that hard. It's not easy. It's not hard. It's just not trivial. Okay. And but if you do it then that stands very well with with people when hiring OSS contributions.

[00:35:30]But at the same time, it's something that you have to surface during your cover letter or your resume, because I am not going to go through your GitHub and dig through every contribution of yours. Like you have to tell me. So just be aware of that. Like nobody has time to dig through your GitHub.

[00:35:42] No, one's paying attention to that much. Just like the other guy said  from Google Just have three. I just have a perfect thing, a good thing, like a complete thing. And then one of a story. And I think that's a good sort of spanning minimum spending. It's tree, is that a tree or whatever it means minimum spending set of of achievements.

[00:36:00]And if it's open source that they use, then that's even better. Big, like, so, I went, my first sort of big open-source contribution was react and and that it's impressive, but at the same time, it takes a long while. And actually, the reactant here is now let's say like, don't do that.

[00:36:16]Go contribute to the smaller open source project. They actually need help rather than piling in on the big one that everyone wants to help in on. And yeah. So it's up to you what strategy you want to pursue, but definitely open sources is a good and hiring approach method.

[00:36:29]Provence shoe, w would you deliver a feature with hacky implementation or delay in order to do quality? You? I just said that like, Make it work, then make it right. Then make it fast. Right. In that order cutout. We'll cut again.

What's the benefit of a random employee spending the time on you for referral or talk about their job? I feel like it's one sided for the student.

[00:36:47]  Like I'm yeah. I'm a random employee and I'm spending more time with you. I'm paying it forward. I hope that, you will do this for people, in, in future. Because I care about. New people coming into our industry. I care about people having healthy approaches to the career.

[00:37:04]There's a lot of hustle in in our career that causes burnout. There's a lot of bad advice out there. So I'm trying to do my bit, so I dunno, it's just more like, sometimes you want to have a nice conversation with people who are eager about. Sometimes you meet, you may feel a little bit like too in the weeds with people who have so much context every day, and sometimes he might just have like a nice one-off conversation with someone.

[00:37:28]Who's super interested in everything you say and that's very flattering. So, yeah, it's not too hard to make that justification. Yeah, I think that's it for questions. Is there any additional questions we still have about five or six? Perfect. There we go. Some are coming in. I know.

[00:37:44]It's super interesting. I mean, feel free to like, I don't know. I'm mute and ask this yourself. Cause I'm reading both sides.

How do you ask developers for conversations about their job or guidance?

Just straight, email. Email's good. Like if you know them, if you like know them by like a friend of a friend, then yeah.

[00:38:02] Do that. But if not just call email or Twitter, like you like be prepared to get ignored. I'm not saying you won't get ignored, but like it, that is the best way. Yeah. And also like, be able to pitch yourself like refer to that cold email person, but then also there's  that, that person so like be able to pitch yourself in a very short form, right?

[00:38:22] Like what you want and like who you are, what you want and how they can help you. Right. And like the more specific you're asked the better it is for people to help you. So let me try to pass this along to you, Vinny and share a tip.  Stand alone. I mean, one second. I'm going to, I'm going to pass you this so you can pitch yourself so pitch yourself as you go.

[00:38:45] Okay. Cartek how do I approach about the referral at the end of the conversation though? 

Like, Hey, we talked and stuff and I'll give job  It most just mentioned the word referral some somewhere in your conversation and they'll pick up on that. If they don't want to refer you, then they won't offer.

[00:39:01]And you can take that hint and just, that conversation probably didn't go that well. Otherwise like, yeah, like, like again, it's. Sometimes. So it's so yeah. So first of all, just like, make sure you mentioned referral at somewhere in the conversation and they'll pick up on that, that you're also trying to get a referral.

[00:39:18] Well, like again, like. The sole purpose of the conversation, right? You genuinely want to learn and you genuinely want to have feel for future conversations, like one other really good thing to get out. Like, even if you do not get a referral one other really good question that you can ask at the end of a conversation like that is who else should I talk to and have them refer you to their other friends or.

[00:39:39]People who are a better fit to talk to you to talk to your interests and mining the social graph rather than just getting that system referral because that's that's, that's one referral, but like having more people actually speak up for you that's also very valuable.

[00:39:52] do you prepare for data structure and algorithms for job interviews? Is there a fun way for that? 

I don't know if there's a fun way you can game-ify it, with with points and stuff. I was. Friend slash beta tester of algo expert.io before they were famous. And that has like a nice completion system, which is nice.

[00:40:10]So long story short, I did, I spent two to three hours a day on that. And I'll be honest. Like I only used it at my Google interviews, every other interview, every other job that I interviewed at didn't really use. Traditional algos and data structures. They, the sort of technical interviews, but it wasn't like, right.

[00:40:29]Men heap or something, like it wasn't that sort of classical textbook algorithm stuff. It was just more applied on to specific problems. So fun way for that. Not really just know that you are actually going to have some points in your career where you actually use this knowledge.

[00:40:44] It's not just for interviews and that day will come and you will be thankful for that. You studied this stuff. And to me, that makes it fun. Nice pizza. What do you think about referrals? What does that mean? Nice pizza. Yeah, sure. Okay. Yeah. Mentioning referrals. Got it. Yeah. Cool. Yeah that's I think that's that for my answers look like I, I'm not, I don't know if I have the best answers, but feel free to have that conversation with me.

[00:41:06] Like, email me, I'm happy to answer. I may not answer right away. And I tend to try to answer it in public. My answer with, you can be shared with other people who have the same question. But I strongly believe that, I think we need to have more conversations like this from people who've, are a few years into our process to people just starting out.

[00:41:23]So that's why I'm here. Thanks, Leah. Bye. Thanks for having me. Nice day.