- Listen on Apple Podcasts
- Listen on Google Podcasts
- Listen on Spotify
- Listen on Pocket Casts
- Listen on Castro
- Listen on Breaker
🎙 About the episode
Meet Jonathan Gauthier 🇨🇦! Jonathan volunteered when the company where he worked needed somebody to figure out how to turn a Figma design into a website. The rest is history.
After quitting that job, Jonathan gave himself three months to properly learn front-end development and get his first developer job. And he succeeded! In this interview, he shares how. Yes, Jonathan was pulling long hours, but there's more to it!
Jonathan talks about his way of learning and why knowing how to approach a problem is better than knowing the exact method of solving it. You'll also learn why it's good to find a mentor - and how to find one! Lastly, Jonathan shares his approach to looking for a job online and why it's important to interview your interviewer. Believe it or not, the latter can make or break your interview process!
🔗 Connect with Jonathan
- Jonathan's journey into coding by way of learning to translate designs in Figma into a website + his introduction to Scrimba (01:59)
- How Jonathan quit his job and had only three months to learn to code and get a job in front-end (04:14)
- What's manual QA, and was that a helpful background to a new developer? (05:41)
- Learn the approach, not the method (06:29)
- How Jonathan decided to switch careers(07:27)
- Why you should apply when others think you're ready (08:53)
- Jonathan's study plan (10:21)
- How can you study both properly and fast? (11:41)
- The importance of taking breaks (14:10)
- How Jonathan found a mentor and why are mentors important (15:10)
- Jonathan's approach to finding his first developer job: LinkedIn, Angel.co, and messaging recruiters directly (17:43)
- How to optimize your LinkedIn profile (19:16)
- Jonathan's interview process (21:22)
- How to interview your interviewers and why that gives you an advantage (22:15)
- What skills should a junior developer have? (24:44)
- How Jonathan got his job offer (27:13)
- Jonathan's new company + Do you have to know Agile? (28:21)
- How to ask questions as a junior (29:38)
- Closing advice: don't stress about feeling ready; remember to take breaks, and come up with personal projects! (31:18)
- On notetaking (32:12)
🧰 Resources mentioned
- Jonathan's LinkedIn profile
- The Frontend Developer Career Path
- HTML and CSS crash course with Kevin Powell
- ProgrammingBuddies() on Reddit
- No Whiteboard
⭐️ Leave a Review
If you enjoy this episode, please leave a 5-star review here and let us know who you want to see on the next podcast.
You can also Tweet Alex from Scrimba at @bookercodes and tell them what lessons you learned from the episode so they can thank you personally for tuning in 🙏
Something interesting that I did is turn interviews into me interviewing them and making them think they need me. What is your company's midterm, long-term goals? What is the vision? What is the biggest competitor? What are your current issues? How can I help in solving them? What is the best part of working at your company?
Hello, and welcome to the Scrimba Podcast. On this weekly show, I speak with successful devs about their advice on learning to code and getting your first junior dev job. My name is Alex and today, I'm joined by the absolutely determined and now successful Jonathan. He's a Scrimba student who just got their first junior developer job. And before that, Jonathan worked as a QA tester.
Some of us, okay, have the luxury of time. We can learn to code at our own pace, and that is a beautiful thing. But sometimes, there are bills to pay and straddling a career change while keeping a roof over your head can be extremely stressful. It takes a lot of discipline and a great well-executed plan to be successful.
I'm actually describing Jonathan's position and attitude exactly. With just a three-month runway between his QA job and his dream of becoming a developer, Jonathan learned some additional coding skills, honed his abilities and pushed through that final mile to get to a hireable level and be successful. I'm really happy Jonathan took some of the advice we share at Scrimba about how to learn effectively, how to optimize your LinkedIn profile and the benefits of mentorship.
In this episode, Jonathan talks in detail about how he applied some of the lessons that made him successful. But also, he will talk about how he found a mentor and just how integral that mentor was to his success in such a short period of time. Not just because they answered questions right, but because they believed in him and gave him that little push. You are listening to the Scrimba Podcast. Let's get into it.
I worked in a tech company for about three years as a QA engineer where I did mostly manual QA. And towards the end of that job, during the last maybe six months, we were a really small team of four people, and we needed an extra engineer to reproduce Figma designs that our designer did. And so, they asked me if I could figure out, let's say in a week, how to reproduce a Figma design with the code. And I had absolutely no idea what I was doing and I said yes, anyway. I said I would need help, but I said yes. They provided me with an environment to code on. That was on Amazon Cloud9. They said, "You need to add your code in this specific file and you need to add your CSS in that other specific file." And they set me a Scrimba course.
Yeah, because that was a company in YC, Y Combinator, and they heard of Scrimba and Y Combinator as well, and they suggested that to me. And they said, "There's this HTML and CSS course for free that is four hours that was made by Kevin Powell." And they said, "This should be good enough for you to reproduce our designs." That's where I was initially introduced to Scrimba and to coding at the same time.
And so, I took that course and I managed to reproduce the design in a week. That was a lot of work, but I did it and since then, I never looked back. I started learning a little bit, piece by piece, how to code from there.
That's sick. Was it a complicated website? Did you have to make it responsive and stuff?
That is an incredible start to your development journey because you were thrown right into the mix. I suppose a lot of new developers, they start off with the idea of a, okay, I want to be a web developer and then, you play around with a lot of kind of contrived examples before you finally get a chance to contribute to something that's in production. Do you think that was a useful first experience for you?
I think it was because I learned to learn in a rush and since I had no idea I was exposed to something I didn't know I would like and I developed kind of like a love relationship, if that makes sense, with code because at the end of the day, I had to learn it and I had to enjoy it in order to get my work done. And I worked really hard to learn so fast. So I would say, yeah, it was a good thing because when I quit that job in early January this year, I decided to take some time. I had three months of leeway to learn full front end course and I decided to take it. And I gave myself three months to learn and find a new job.
That is a very intense timeline. Just quickly on the topic of QA, that stands for quality assurance, right? And you said you do manual QA specifically. I guess the way it works is the teams provide you with their app and you kind of go through it and press all the buttons, give it erroneous inputs and try and make sure everything works like it used to before the updates. And if there are any sort of bugs and stuff, you report back to the development team to fix it.
Yeah, exactly. So how it worked is basically, depending on new features we released, I created a test scenario and then all the test cases related to that test scenario, set all the preconditions, the test steps, so like what I need to do for a login, enter my username, my password, press the button. And then, what happens if there's nothing entered in the username or the password and then, stuff like that, right?
Which is really interesting because as a developer, a lot of thinking like a programmer is thinking through exceptional scenarios. So when a new developer codes their first login, they probably don't even think about input validation or how maybe a special character could break the process. But presumably, these were things that were quite front of mind for you from the beginning. Was there parts of the QA experience that helped you when you started to learn to code?
Yeah. Actually, there was a lot of that experience of QA that helped me during my learning phase. I gave myself a lot of pressure to be able to learn that in that short amount of time. And sometimes, I would think like I'll never be able to do that because I kept forgetting some specific methods or, oh, is it a dot-include or is it a string or things like that.
What I learned eventually during my journey is that what's really important is to know how to approach a problem and not the method specifically. What I mean by that is that let's say I have a model, I have to make a model, how I would approach the problem is I know I have to, let's say, have a state that will turn to true or false. And when I click a button, it opens the model and then, there's more information displayed in there. I might not remember that it's a state or something, but as long as I have a systematic approach to how I'm going to solve the problem, after that, I can use like, let's say, Stack Overflow or go back in my notes and figure out exactly how I do it.
That makes complete sense. By the way, was it the case that you hadn't really imagined being a coder until that opportunity came about to turn the Figma sites into a website? What was your kind of motivation to learn to code?
I didn't know anything about coding. So I thought it was really scary to learn about coding because I thought it was a lot of maths and a lot of like you have to go to school for four years, and it's really complicated and there's algorithms and stuff. That definitely threw me off a little bit.
When I left that other job, I started looking for QA jobs initially. And I figured out that there was a lot of automating in QA that I didn't know about and it was directly related to code. And I figured at first, well, I'll learn how to code and maybe, it will help my QA career. And during the process, it turns out that I really enjoyed coding, especially front end, and I decided just to go with it.
That's sick, actually. I have heard over the years, how more and more companies have either adopted automated quality assurance where they create scripts and things to move the mouse and interact with the application, but also a lot of teams in an attempt to save costs basically, they adopt Agile practices and things like task-driven developments and integration tests and things like that. It's really interesting that when you started to look at other QA jobs, you noticed the pattern, but you just kind of fell in love with web development, it sounds like.
I thought at first it would be impossible for me to learn in two months. I gave myself three months, but two months and then applying, I knew it would take about a month. I never felt ready for applying for jobs even when I started applying. Even when I got a job, I didn't feel ready, to be honest with you. I reached out a lot to communities and I made friends on Scrimba community and other community like Reddit and stuff. And I made a friend who had 15 years of experience and I would show him my work. And he said like, "You're absolutely ready," and I had a hard time believing it, but I went for it and I just started applying.
That's mad, how someone else's belief in your work is the thing that gave you the confidence and motivation to start applying, but lest we forget, you did approach things in a very, I guess, disciplined manner. Imagine you're back at the beginning of that journey. You have two, maybe three months to learn to code and get a job. Take us to that point. What was your plan?
Initially, what I did was I knew I had three months to tackle the issue of not having a job. I had three months to find something and after three months, I had to go back to finding a manual QA jobs. Otherwise, I couldn't pay my bills. And so, what happened is I went on Scrimba, find a Scrimba front end career path and I saw that there was, at the time, 14 modules. And I told myself, 14 modules, if I can do at least one a week, I could possibly make it.
Oh, my, that's so intense, by the way.
I decided to have that plan where every week, I need to complete at least one and turns out that there was some that were 15 to 20 minutes, just like learning Git and the introduction. And so, those, I were able to fit two, sometimes two and a half in a week.
When you wrote in the Scrimba Discord a little bit about your developer job, which we're going to get well into soon, one bit of advice you shared is to do every extra task that are given during the course. Even if you think you understood something, you should go in and add your own little feature or something.
Yeah. I think it's important to do all the exercise you're given and especially add even some yourself in the sense that it will also help you think about real world use cases when you create your own exercises. Since if you really understand the problem, you'll be able to create new problem effectively and then, just approach them and solve them yourself, right? So you create problem, that means you understand how to approach it since you created it, right?
You were going through the career path for a pretty rapid pace. We don't actually, at Scrimba, attach a timeline to it because everybody's a little bit different, but I would say the average is at least a few months if you were to just do all the challenges and not even go over them again. But in your case, you made a lot of progress, at least, in just a couple of months, doing all the challenges and sometimes practicing the scrims a second or a third time. How did you combine those two things, doing it properly and doing it fast?
To be fair. I spent about eight hours a day minimum every day, including weekends. I knew it was going to be a lot of work. And sometimes, I would tell myself like, "I won't make it. I don't know what to do now." And at the end of the day, I just told myself, "What's the worst that can happen? Am I going to die? No, obviously not. Am I going to fail? Well, maybe, but I'll just try again tomorrow." So there was a lot of focus on getting the job done and that was it, really.
Coming up on the Scrimba Podcast, how Jonathan [tacticfully 00:12:40] turned the interviews around so he was interviewing them.
I got something like 70% in my coding test and they still went on with the second interview. And I think the first interview is real important for the entire process.
Pardon the interruption, but I wanted to please ask that if you're enjoying this interview with Jonathan and the Scrimba Podcast in general, that you do as a favor by sharing this episode with your friends, be that on social media like Twitter or in your Discord community perhaps. Maybe you have a programming partner who comes to mind who could benefit from the advice on this Podcast as well. Word of mouth like this is so helpful for a newer Podcast like the Scrimba Podcast because it helps us reach new listeners. A big thank you for that in advance. Also, if you haven't already, it would be great if you left the Scrimba Podcast a favorable review on either Apple Podcasts or Spotify.
Next week, I'm speaking with a CSS and junior developer career expert named Josh Comeau. He has worked at some companies you definitely recognize like Gatsby, DigitalOcean, [Unsplash 00:13:37], Khan Academy, et cetera.
A few years ago, while I was still working full time doing typical software development work, I started working part-time for a local coding bootcamp. Every cohort, I'd be assigned two or three students to work with that had recently graduated as a sort of career coach. And I noticed that the standard template that people use for their portfolio sites really doesn't do the job that it's intended to do. On Twitter, I decided to offer portfolio reviews. So I said like, "Hey, if you have a portfolio site, drop the link, I'll take a look," and 500 people responded to that. And so, because I found I was giving the same advice over and over and over again, I thought, Why don't I put this in a book?
That is next week on the Scrimba Podcast. So please, make sure to subscribe as not to miss it. Back to the interview with Jonathan.
Is it fair to say you just dedicated all your time to learning to code? And if it burned you out and it made you really tired, so be it. This was the risk you were willing to take.
Yeah. We've all been there.
What was really important as well is I had to really be involved in communities, in coding communities like Scrimba. And what I really wanted is to find a mentor that I wouldn't be shy to ask any kind of questions and not make a fool of myself because sometimes, I'm unsure of my questions and I want to make sure it's clear and it makes sense, but sometimes, it just doesn't come out the way you want, right? So you want someone to be able to understand your questions, help you out every time you need it.
How did you go about finding a mentor and convincing them that you are a good person for them to invest their time in helping?
I've been really involved in a lot of places. I talked to about 50 different mid to senior engineers until I really found that person that helped me out. I used Reddit a lot, communities like Web Development, Programming Buddies, and also Scrimba community where I used it a lot, ask a lot of questions. And when I found someone who would constantly help me, I DMed them and asked for more help, maybe get in a call, get to know each other, and eventually, ask for more help, and I kept contact with them.
Do you think you would've found success as quickly as you did, if not for the mentor you found?
Not at all, actually. Having a mentor helped me so much, not only for improving really fast because when I was stuck for too long, I would ask questions and get the answer. And also, it really helped with the self-esteem because like I said, I never felt ready for a job, but since I had people who were more senior than me, who did that job for years, telling me that I was ready, it really gave me the little boost to being confident.
Finding a mentor sometimes feels a bit one sided because you're hoping to learn a lot from them and you think, oh, what do I have to offer? But I think mentors often find it really rewarding to sort of help and see you be successful. And if that's their kind of subliminal, I guess, objective, they probably want to see progress from you and see you follow their advice and getting closer to success. And I bet that just motivates them to help you more and find success.
Yeah, it really did. And I figured that out a bit late. Due to my success in finding a job so fast, I had friends that saw that and wanted to do the same thing and they started coding, and I was super happy to help them because I learned that it helped me even to teach them basic things. And it helped me understand things that I didn't understand when I was first learning, right? So I think helping others really does improve your learning curve.
So you've been coding frantically for a couple of months, learning on Scrimba, getting better every single day. That second month passed, I'm sure, and it was time to start applying for jobs. What was your approach, Jonathan?
So initially, Scrimba gave a lot of advice on how to apply for jobs. And also, I think LinkedIn is an amazing resource. There's also other platforms like No Whiteboard, Twitter communities. Also, something I figured out is reaching out to recruiters directly on LinkedIn. So when you see a job, let's say, I don't know, Scrimba is recruiting and you go inside all the employees and find the recruiters and just message them directly, "Hey, I'm looking for a job. I'm really interested in the company. Could you tell me more about your current problems and how I could help in achieving them?" and stuff like that. And so, I think having a connection with recruiters really help.
I did apply at first to a lot of jobs just using the Easy Apply on LinkedIn and turns out that I didn't get a lot of answers. And so, I tried to figure out other ways since when you have little to no experience, it's really hard to get considered for the roles, right? Even the smallest jobs will have something like asking for two years of experience or three years. And you're like, "It's just a junior job. What am I doing here?" But then when you message recruiters, you realize that in essence, even if there's a year or two of required experience, turns out that if you do the job, they'll give you a shot anyway, right?
I started using also angel.co, which is a recruitment platform for startups.
That's a good one.
I also did all the skills test that you have on LinkedIn and also on angel.co to improve my profile. And it turns out that I got my job by being contacted on LinkedIn by a recruiter due to my profile, which was quite surprising, honestly.
That's mad. So you think maybe optimizing your profile a bit, adding the skill tags, having a good picture and all those other hygienic things, and I guess you were sending out a pulse into the world, right? Whether you were deliberate about it or not, you were applying to jobs, you were on the platform every day, you were just active. And then a recruiter messaged you. What did they say?
They said that my profile looked like a perfect fit and that they wanted to tell me more about their position. I didn't expect that. At first, that was the first person who contacted me. The job I currently have, that was the first person who contacted me directly on LinkedIn. And it was also the first person to give me a real interview. Surprisingly, that's the job I got, so I got really lucky.
I'm just checking out your LinkedIn, by the way, and it's a really nice example. I want to let people listening know that we'll link your LinkedIn in the show notes for them to learn from. I can see that it's clean and minimal, and you've done a really great job sort of stressing your skills and your values. How did you sort of decide what to write in the about section?
When I finished the Scrimba course, there's that last module called Getting Hired where they guide you through making a good profile, making a good resume and kind of some of the questions you might get asked during the interviews. And that really helped a lot in approaching my LinkedIn profile. I even have that banner that Scrimba provided.
Yeah, I noticed that.
And so, I think that's a big part of my success on LinkedIn. Honestly, the tips from Scrimba really helped, adding the correct experiences, adding licenses and the correct skills I needed. And also, I had no idea what to write in my about section until they gave me examples in like how to not say like, "Oh, that's what I did," And rather say, "That's what I did and that's what came out of it," right? The result is really what people want to see.
Emphasizing the impact. At this point, you'd got a message from a recruiter. What was the interview process like from there?
The first interview I got is the job that I got. The first person who messaged me gave me an interview. But right after that time, while I was in the interview process, I got five to six to seven replies from recruiters I contacted-
... directly on LinkedIn and even on angel.co, I got replies. And I think especially while on angel.co, I think it was due to me doing their front end test, which gives you like you get to do the test and you're in the top 20% or top 10% and stuff like that. And I got top 20%, thanks to Scrimba, I guess. So basically, I got message from five to seven recruiters. I don't remember exactly. And I did all those job interviews and I got two offers and I accepted one, which was the first interview I ever got.
Give people listening an idea about what to expect.
I felt like the questions were honestly quite easy to answer. Something interesting that I did is mainly turn interviews into me interviewing them and making them think they need me. I would answer their first few questions. And then, I would jump right into my questions, asking things like what is your company's midterm, longterm goals? What is the vision? What is the biggest competitor? What are your current issues? How can I help in solving them? What is the best part of working at your company? And things like am I going to work with a team or on specific features? And really feel like I'm already involved with their company?
Yeah, definitely. What impact do you think that had on the success of the interviews?
I think it went great. All the first interviews I got, I managed to get to the next step, which most of the time was an engineering test, a timed coding test that was taken at home. And then, the third interview was talking about my test and getting to know more about me, right? And every time I would say, "Here's what I did and here's my approach," and then, find an example on their website or their product and be like, "Well, you know that thing you have on your website, I would do it that way as well." Or I would take an example of their website and then kind of explain how I would do it. So they already, they understand that I looked at their thing, I'm interested in their company and I want to know more, and already feel like I'm in their code doing things.
Yeah. That's really underrated. People want to work with skillful contributors. You need to have good coding skills obviously, but they also want to work with people who care and you've got no greater incentive to care about and research the company when you're in the interview stages, right? You really want them to invest in you. And so, if what they see during the interview doesn't inspire them, that can be a problem, right?
Yeah. And something that I can't stress enough is that I never felt ready for applying for a job, but what's really important is that when you do your coding test, even if you are not a hundred percent correct, I think if you nailed your first interview and they already felt like you were part of the company, you have more chance at succeeding. I got something like 70% in my coding test at my current job and they still went on with the second interview and they just talked about why I failed during the test, right, what didn't make sense that I did and how I could approach the problem differently. So I think the first interview is real important for the entire process.
What level of technical skills do you need to get a job as a junior developer?
So basically, I don't know if you heard about something called pseudocode or you probably did, you describe the problem itself before starting to code it. And I think that's the main part that you need to get right during your interview. So basically, get all the fundamentals, obviously, HTML, CSS. I didn't even understand Grid correctly and I wasn't really familiar with async functions and promises, and I just went with it anyway and just made sure I understand the fundamentals correctly. And so, when they asked questions and when they saw that there was some part that I wasn't sure about, they just reiterated the questions and asked me to explain my approach.
A lot of new developers read interview prep posts or watch interview question videos on YouTube, and it'll be questions like how does the Context API work? What are hooks in React or what arguments does this function take? But your experience was that they maybe wanted you to have a fundamental understanding and that had to be demonstrable, but most of the interview was focused on your ability to think logically and think like a programmer, consider edge cases and control flow and how you would approach problems. And you basically expressed those things using pseudocode or words rather than the specifics of the code, which you can always look up in MDN or double check at another time.
Exactly. And what's surprising is at my current job, the tech stack was also including things like TypeScript, things like GraphQL, things like Jest and React testing libraries. And I literally told them, "I don't know those. I didn't learn those, but I can definitely figure out on the job." And they said, "Yeah, you can figure it out as long as you know the fundamentals and understand how to approach problems." You don't need to know everything because you're a junior after all, right? You won't know all of it.
Tell us about the day you got the job offer?
During my last interview, we went over the problems that I did in the code. And like I said, they asked me a few questions about the questions I didn't get. I kind of explained how I was thinking of the problem, how I'm approaching it. And it felt like it was good and they even said like, "Okay, that's the right approach. Maybe this method could have been a different method, but at the end of the day, you have the right mindset. You understand the problem correctly." And then, at the end of the interview, they said, "We'll contact you back if we're interested in hiring you. It often takes a week." We hung up the call and they sent me an email five minute after that with an offer.
No way. Seriously?
Yes, five minutes after that. I even asked them, "What made you take this decision so quick?" They said, "You got the right thinking. We like that you have a little bit of management experience." I was good with managing projects and I was good with explaining myself, which is a really important thing. When you get stuck in something, you can't hesitate to ask questions and you need to be clear about what the question is, right? And that's what they pointed out.
Congratulations, man. That must have been such an incredible feeling. What is the job exactly like? What are the company? And what team are you working on? What sort of products and things, and what tech stack and stuff are you using?
I work basically in a tech/healthcare company.
It's called Equinoxe.
Yeah. It's a local company doing product for essentially the government to offer better services in healthcare. The tech stack is React. I don't know much about backend, but I think it's .NET Core they're using or .NET, and we're using GraphQL, which I had no idea about. We're also using TypeScript, which I had no idea about, but they're always here to help me. My day to day consists in basically taking the cards like if there's new bugs, there's scars that appear on... We're using Jira, so there's scars that appear on there. I just take the cards, start working on the problem at the hand. And we're doing sprints with the Agile methodology, which by the way, I didn't know much about, except for a 10-minute explanation in the Scrimba course, but I just started on the go.
I guess a lot of new developers hear about Agile and stuff and wonder if you need to know it. You really don't. It's not something you have to sort of learn to get a job as I think you've proved, Jonathan. Well, damn. That's just amazing. I mean congrats again. Are you learning a lot? Do you feel like it's the right place for you?
Yeah. Honestly, it's been moving super fast. I had the impostor syndrome at first because everything happened so fast. And like I said, I never felt ready even when I got a job, but then I would talk about the issues I had with my mentor. Let's say I get stuck on something at my job, I just ask my mentor, "Is it fine if I ask some questions?" And it gave me the self-esteem to know which question I should ask. And in reality, I can ask whatever question I want. It's normal because I'm a junior, I'm just learning and they know that. So at the end of the day, it's really not a big deal. Just ask your questions, you'll figure it out.
It's not great if you give up at the first sign of trouble, obviously, but if you spend 10, 15 minutes on it and you're still stuck, you're not doing anybody any favors by just being stuck all by yourself. It would be much better if you ask for help. If you demonstrate that you were working on the problem and you can show you're working, there's no limit to the amount of questions you can ask practically.
I think a good point, too, is you kind of ask your question how you would approach a question on Stack Overflow where you need to explain the problem and also explain what you tried to do so people have a better understanding and they know you at least tried something and then, they are better equipped to answer you. So it's really important to be explicit when you ask a question. And I think that's a little bit why they hired me there because they know juniors are going to ask questions and you need to prove it during your interview that you're good at expressing yourself and you won't hesitate to ask questions and learn from the senior engineers.
We're almost out of time, unfortunately, but I was hoping just to close up by asking you if you had any sort of closing advice to new developers learning to code and aspiring to get their first web developer job?
Don't stress about not feeling ready. Just make sure you're consistent in your learning. If you can just learn for 30 minute in a day at least, just so you keep your head in the code. If you get stuck for too long, don't hesitate to take some breaks. And I guess something I didn't mention is during my learning, I also added personal projects on top of Scrimba courses, just to make sure I had the right understanding of how things worked. So I gave myself some personal projects like making a calculator, a grocery shopping app and things like that when I wasn't sure I was getting things right. What's really important is when you don't have guides or anything telling you how to do it, that's where you learn the most. So make sure to do all the exercises and even add some of your own.
I remember now that you have a Discord server where you keep your notes and I noticed in there, there's a few people hanging out.
Yeah. And you'll find probably familiar faces of people from Scrimba who were willing to help me. And I made connections on Scrimba Community Discord that I eventually added to my notes. And so, they can also take notes and add things that I didn't think of. I think it's important to take notes because when you go back to your example in your notes, you already lived through the context of that specific problem or method you took note from. So, you don't have to go through the context again. You already lived that problem before so you'll instantly remember when you see the code, right?
This reminds me of a quote from a recent episode of the Scrimba Podcast by Scrimba teacher, Guil Hernandez. He said...
Be a librarian, not an encyclopedia.
Don't try and be an encyclopedia and know everything. Be a library and look things up instead. And the only way to make that better is to add context around it, which I think you've achieved with that server. Jonathan, thank you so much for spending your time and joining us on the Scrimba Podcast today. It's been a pleasure.
Well, my pleasure. Thanks for having me.
That was Jonathan, a successful Scrimba student who was recently hired as a junior developer. Thank you for listening. If you've made it this far, you might want to subscribe. For more helpful and uplifting episodes, we've recently hired juniors like Jonathan and industry experts like Josh next week. You can also tweet at me your host, my name is Alex Booker, and share what lessons you learned from the episode so I can thank you personally for tuning in either with a reply or a retweet or something like that. My Twitter handle is in the show notes. This episode was produced by Jan Arsenovic. See you next week.