Episode 3: Jake from AlgoDaily

Fri, 02 Oct 2020 23:30:02 +0200

Jake, founder of algodaily.com explains how to break into tech and land that developer job

Episode 3: Jake from AlgoDaily
--:--
--:--

Show Notes

Links

AlgoDaily website

Notes

  • Consider sys admin/solution engineer roles as a way to break into development if you do not have a traditional software engineering background. A lot of these roles also look for non-technical skills.
  • Early on, about 50% of Jake's learning was on-the-job, and 50% was studying off hours.
  • Jake reckons maybe 20% of students prefer a whole mix of learning methods, whereas most people will stick with one format (e.g. video, diagrams, or text).

On Breaking into Software Engineering

  • First it's very important to identify your motivation and act accordingly:

If you're in it for the money, you should take a different path to someone trying to start a SaaS business vs. if you're trying to just be a general software engineer

  • If you're trying to break into the FAANG companies, you have to master algorithms and data structures. [Jake] would even go so far as to say don't focus on personal projects if that is your goal.

  • On the other hand, if your goal is to be a general software engineer, then work on projects.

  • Regular practice is very important for learning (especially algorithms), so try and create accountability - AlgoDaily does this through an automated daily email.

  • Encourages those looking to break into software engineering to do more projects. Building complex projects has taught Jake more in a compressed time-span than any job.


Transcript

[00:00:00] Hello and welcome to the course maker podcast. Today, I'm delighted to introduce Jake from AlgoDaily. Jake is the founder of AlgoDaily, and I love your slogan. Forget the LeetCode grind. So it's a full guided interview course with over 150 hours of high quality coding interview prep material. So Jake, welcome to the show. Thank you so much. I'm very happy to be here. So to begin with Jake, can you tell us a bit about your background? Absolutely. So I've been a software engineer for coming on eight years now. I've been in the software industry for eight years. I did L I started off my career doing a mix of software engineering, mostly web development, and a little bit of project management eventually realized I did not like the project management part and went full in into development.

[00:01:00] I've worked at. Quite a number of startups. I, I have a tendency to jump around startups startup to start up and throw in a mix of one or two large companies in there. But I've gotten a taste of pretty much every aspect of software engineering from the, as I mentioned, the project management side to the development side, but also I've been able to luckily try out some, you know, team lead stuff, as well as work on both the low level. You know, coding aspect as well as art, as well as make architectural decisions. And it's been a blast so far background wise, I'm from New York. I was born in China. I actually grew up in New York. Yeah. That's that's where, that's where I'm coming from. Great. Yeah, I can, I can definitely relate. Having also started out doing some more project management consultancies sort of stuff for myself. Was there, was there one particular moment where you thought again, I'm really going to go more down the development path, a turning point, if you will. Yeah, it was,

[00:02:00] it was, I don't think there was a specific point. It was more, it was more, the law lost the feeling of not having any control over final outcome of a certain project. As a project manager, you kind of have to be able to influence without direct control. And it's a very, very difficult thing to do and requires the. Participation and cooperation of, of a lot of people who might not be as cooperative as you would hope. And I found that pretty challenging, at least for my personality type. And so I don't think it was any direct moment, but it was a year long thing, your long dive, soul searching aspect of it. And, that eventually led to that conclusion. And what was the transition like for you getting more into development? Yeah, that's a great question. I actually had a pretty unique transition and this is something I actually recommend to students who are

[00:03:00] looking to break into software engineering from more of a nontechnical role. So my first development job was. Was actually a more of an integrations engineering kind of a role. So I was doing, I was mostly writing code, but for the purposes of integrations and configuration. So I didn't start off like writing, you know, web apps or anything like that. I actually wrote tools that would help facilitate. The transfer of data between between two different applications. My official title was solutions engineer, but that gave me a really great introduction into the software development life cycle and working on a software team. And I recommend, I recommend this to people trying to break into software engineering because. You, it's not a pure quote unquote engineering role, but it's an easier transition in a lot of these roles look for nontechnical skills as well. So that, that definitely helped coming from a more of a project management background. That's a really

[00:04:00] interesting entry into the field. yeah. Okay. So you're, you're writing these tools working as a solution engineer, and then eventually you've, you've made your way. into a variety of other sorts of technical roles. When did you switch away from more of the solution engineer stuff? It was pretty much within year one. I think solutions engineering gave me a taste of full, I want to say full software and false full software engineering development. It's kind of hard to describe these transitions because it was, it was a very, it was a pretty gradual transition. I basically became more and more technical over time. And before you know, it, you know, I was able to just apply to software engineering roles. And were you mostly learning on the job or did you do a lot of study outside work as well? There were, it was a mix of both. I actually got, I actually got my masters in computer science

[00:05:00] while, while I was making that transition, which definitely helped a lot. And I would say about 50% was off, you know, Off hours, studying or taking classes and then 50% learning on the job. Interesting. Yeah, I I'm sort of, you can probably tell, but I'm, I'm warming up to, I was talking about algo daily, cause I think some of the, the tools and techniques and all the different ways that people learn through that tool, a very, very interesting. So do you want to start to introduce how, how you came to come up with the idea and what was the initial spark. Yeah, absolutely. So, like I said, I started off in a nontechnical role and eventually moved into a technical role through a series of job hops, as well as getting a education outside of work. But my frustration with the technical interview process was discovered a very, very early on or writer came about very, very early on. I

[00:06:00] remember the first time. I found out I had to do a coding interview. I was very disappointed with how complex the materials to help people prepare were. I remember, you know, if you're a developer, you know, that the goal two recommendation for technical interviews is, is a book called cracking the coding interview. It's a, it's a pretty much a legendary book at this point. I, as someone who was new was a new programmer. And new into software engineering. I just found it very, very, very intimidating if you're coming from a nontechnical background, especially whether it's a, whether it's a bootcamp or whether it's a hybrid role. Like I was it's, it's just very, very difficult get into the more computer science aspects of things. And so I just read that book and I was just. Incredibly incredibly stunned that people would sit down and read an 800 page or however long. It is maybe

[00:07:00] 700 page computer science book, front to back. I just couldn't believe anyone could do it. And so I started looking for other resources that could help. Could help me. I'm pretty personally, I'm a visual learner. I have to see diagrams and I have to see, I have to see things emotion. And so I found that Lee code, which was interactive and help, but the explanations were in too great. And so I tried to find, I tried to create something for myself that would serve as a reference in the future. And that's how I came up with the idea for Albert Bailey. It makes a lot of sense. Certainly. Yeah. Cracking the coding interview is definitely a doorstopper. Yeah. Have you read it Chris? Or have you, but parts of it, like you say, is it is the GoTo. Yeah. So, I mean, let's dig into more about the. Collection of different sort of media and tools that are there in Alberta daily. Cause I was having a browse and you've got sort of a

[00:08:00] whole mix of interactive materials where you can actually write code in the browser combined with videos and more long form text examples as well as sort of cheat sheets. There's a whole variety of different tools in there. So how did you go about deciding what to put in. The, the angle that I came from was, quality over quantity. I, if you look at the other technical interview, prep sites and materials, there's, there's hundreds, sometimes thousands of questions. My belief has always been that it's better to study a small subset of all the possible questions out there, perhaps the most common ones and really go deep in them. And so, like you mentioned, algal daily has. Several learning angles for each problem. So when you, when you come on Algoa and you arrive at a problem, you can visualize it both via diagrams. We have

[00:09:00] numerous illustrations on the site to help you. You know, actually see what's happening or what's expected of a solution. You can also step through the code. We have a little visual visualize button that lets you actually step through and see what's happening at every break point. You mentioned the text explanations for people who just like to read through and, you know, understand what's happening. And of course the actual editor itself where you can try out code. I think personally, that I've always thought of. The way algal Daly's been built as the way I wanted to learn. I like to just try everything I need to, I need to see it. I need to play with it. I need to, I need to retain it. and the only, the only way I found was, was by trying it, trying to solve it through multiple different ways and seeing it through a few different methods. Yeah. It makes a lot of sense. And do you have any sense from, from your

[00:10:00] students of. If there's one particular way that they prefer, or do you really think it's about the mix? Yeah. I've from what I've from the testimonials that I've heard, there are people who prefer one style over the other. I would say, I would say a small percentage. Maybe, maybe 20% are like me. They like, they like to go. They like to have every aspect available or every angle of study available, but. Most people, if they're video, people will just watch the videos. If they're diagrams, people will just look through a diagrams and read the texts. and if they're, they'll just, play with the code, it's interesting. It's the I've always found learning styles is fascinating. The fact that you and I could have the same materials given to us and derive completely different results and outcomes from it. It's really interesting. Yeah. A hundred percent. Okay.

[00:11:00] I'd like to. Ask more generally, like let's, let's put ourselves in the shoes of a student who's perhaps somebody who is making a transition into software engineering or a technical field. What advice would you give to them about how to go about making that transition effectively? Cause like you say, it can be very intimidating. There's an awful lot of material. And obviously with alga Dalio, you're helping them to approach that. But what, what would you say to somebody in that position? Hmm. So is the question, what are they, what are their goals? Let's say it's somebody who's in a position similar to you where those years ago, you know, you're working as a project manager in some non technical field, and you're, you're trying to switch over more into software engineering is actually a transition I've made myself as well. So this is familiar. How, w where do you begin? How do you tackle that challenge? It's quite, it's quite a big question because it really depends

[00:12:00] on the individual and the circumstance. I think, I think the one thing. You have to do is of course there there's so many different ways to break into the field. Now, if I could do it all over again, I would, I think that I would encourage myself to do more projects, to, to create, to create some projects of my own. I, so algal daily.com is built from scratch, using rails and react. And I have probably learned more from. The building of that in, in a, in a compressed time span than I have in any job to go back to your question. I guess I would say the first thing is to find your motivation and make sure you're taking the actions required for that specific motivation. And by that, I mean, if you're in it for the money, you should take a different path than if you're trying to start a SAS business. Versus if you're trying to just be. Just be a general

[00:13:00] software engineering software engineer. And the reason is this, if you're trying to break into Facebook, Google, Amazon, you know, the usual Fang cast a fan, you know, the shops it's pretty much, you have to know master algorithms and data structures and go as far as to say. Maybe don't spend as much time on personal projects and focus more on algorithms and data structures, because that's really what will get you get your foot in the door for those specific companies. Now, if it's to be a general software engineer, I would say, you know, work on projects, find something, find an application to build and just. You know, go crazy on it and just find tutorials and learn as much as you can there. And then if it's to build something for you yourself, I would say, you know, question, if you eat question, if you even want to be yourself even want to be a software engineer, I've noticed, especially, like on sites like indie hackers,

[00:14:00] uh there's people who say, who asks, you know, do I need to learn a code in order to launch a software business? And I. I don't think, I don't think you do at all. I think at this point, if you're, if you're looking to start a software business and not be a software engineer, there's so many, no code and low code tools that are available, you know, sites like teachable. sites, like what is, what's the website? What's the website builder that's really popular now. No, you're thinking of like a Squarespace or Wix those ones. Yeah, exactly. Exactly. So I guess I would say the most boring thing is to find your motivation and, and take the path. That's required of, of that specific motivation, if that answers your question, Chris. Yeah, no, I think that's a very comprehensive answer. And I like how you began thinking with motivation, to draw it back to the algo daily. One thing that I noticed you have in there is this a daily

[00:15:00] email, that makes up part of the course and I, yeah, I find these sorts of. it's almost like a little touch of accountability or at least habit building. Right. That seems to be, to be so important, like consistency. Is that something that you consciously decided to add? Yes, definitely. I heard, I know. I personally had a very hard time practicing Lee code every single day. The guilt of missing an email actually gets a lot of people active in their and their studies. I think, I think it's, especially, I think in the course of preparing for interviews, especially technical interviews where, you know, you're going to get grilled. It's the impending anxiety of the interview. Causes a lot of people to procrastinate. It's, it's something that I found very difficult for those for listeners or viewers who might not know

[00:16:00] technical editor reviews are extremely grueling. I don't know. I don't know if you've been there, but, standing in front of a whiteboard and you had those. Yeah. You have this person who who's just judging your every move and everything you say. It's quite, it's quite excruciating. And. A lot of people know that they need to do some, some form of daily study to prepare for these interviews. But it's real. It's really, really hard when you're, when you're, when the thought of that, you know, link is lingering. And I can see, I can understand why people would procrastinate as a result. So the daily email is like you said, like an accountability tool. And you get, and it's also, it also simplifies the study process because you get one interview question, right? You open up the email, you solve it and then you're done for today. Yeah, it helps. It also helps with breaking up the curricul which is quite large at this point, there's over 200 total on the site at

[00:17:00] this point and, hours and hours of videos and visualizations. so it gives you a nice small sliver. Of the course to do on a daily basis. And it makes sure that you're aware of what you need to do and it gives you, it does give you a little bit of guilt if you miss that email, or if you miss that day's actions, but you can always pick it back up the next day. Yeah. I mean, I really liked that. I think more causes. Should think about that kind of little hook to keep people engaged and to make things more bite-size. so I think that, yeah, that's a really cool feature that, that jumped out at me. Are there any other parts of algo daily that may be a little unusual compared to the, the, the current resources that are out there? Yeah. The one thing we have that no other course has is the ability to step, to step through solutions and see what's happening at every break point.

[00:18:00] It's very similar to putting a break point in code and then stepping through it, using a debugger. And the reason people love this feature is because, algorithms are. Very conceptually hard. There's a lot that you have to hold in your head as you solve these kinds of problems and being able to see what's going on, see the state of the problem, if you will, at every line and then step through and see how that changed. It really helps with developing that intuition that you need when you're actually being interviewed. It helps to kind of give you. The practice of thinking like a machine. And oftentimes in interviews, interviewers will ask you to do, to conduct a dry run of the code. And this does a really good job of helping you prepare for that. It's a very, beloved feature of algo Bailey. Yeah, well, I mean, I really think it's a re a great blend of

[00:19:00] different resources that you've put into this product. So, I mean, kudos for, putting that altogether, especially all custom from the sound. Yeah. I appreciate the kind words. Thank you. Yeah. What's what's next for algo daily. What are the plants? Yeah, so more videos. For for about two years, for about two years, it was mostly the visualizations, the texts and the illustrations, but people, people really, really enjoy watching videos. I'm not sure if it's because, you, you kind of get the sense that somebody is explaining something to you. So there's. The feel of, of perhaps being tutored. but people really like videos. And so I have a small team and myself that's working on ensuring that all the problems on the site have a video component to it. And so that's, that's in the works. Nice. Well, thanks ever so much for coming on. Jake has been really

[00:20:00] interesting hearing about you and your product. Where can people go to find out more about you and alga daily? Yeah, absolutely. I'll go daily.com would be the best place to reach the course to reach myself. Yeah. And I appreciate you for having me. Thank you. Thanks Jake. Bye for now.

View all podcasts