The Scrimba Podcast

Johannes Kettmann (00:00):
One of my students recently got a job and I saw his code. It's not the best code that I've seen in the program. There were really, really good developers in my program. This guy really nailed it. Not the best code, but really cool personality, really cool approach, and he just got a job offer.

Jan Arsenovic (00:15):
Hello and welcome to the Scrimba Podcast. On this weekly show, we interview successful developers about their advice on how to learn to code and get your first job in tech.

(00:26):
Our guest today is Johannes Kettmannn. Johannes is a full-stack JavaScript developer from Germany who also runs a platform called Profy.dev. It's a React Job Simulator program for aspiring junior React developers. Originally, Johannes studied physics before transitioning into coding, and he never had a full-time job. He has always only worked as a freelancer or contractor, even though his first experience with freelancing wasn't the greatest.

(00:57):
In this episode, you'll find out what are the differences between contracting and freelancing? What are their perks? And should you try any of them as a junior? What are the most common React mistakes that even some experienced developers still make? And what are the skills that aspiring junior developers usually don't have, but that can really make you stand out? All of this and much more coming right up here on the Scrimba Podcast.

(01:21):
And don't worry, the show is still hosted by Alex Booker, but he's on vacation, so I'm doing the intro while being ever so slightly envious, but enough about me. Here's Johannes. You're listening to the Scrimba Podcast. Let's get into it.

Johannes Kettmann (01:36):
When I was younger, I couldn't imagine to sit all day long in front of my computer screen. I always wanted to do something with a bit more action or being outside or something. But then I studied physics, and while it's a very interesting topic and I learned a lot of things about logical thinking and stuff, it's also very complicated and theoretical. So at some time, I realized that I'm more of a practical and hands-on learner. I can really go down the rabbit hole when I know what I'm learning this stuff for. But with physics, it's always not very applied in the end.

(02:09):
On top of that, I was doing experimental physics, which was nice, but I was working in a dark lab. But during my thesis, I was actually already starting to get into programming. I took one very small course in programming in university, and then during an exchange program, I also, I'm not sure what the language was called, but it was more for sound engineers so I drifted a bit apart from physics, but I realized that I'm quite good at this because of all the logical thinking that I practice in my physics studies. In the end, I figured that this could be a nice career because you're, or at least in theory, you're location-independent. In theory, you can work on the beach.

Alex Booker (02:50):
In theory, yeah.

Johannes Kettmann (02:51):
Yeah, exactly. And that felt really nice. I guess in practice, if you work on a beach and always get sand on your computer keyboard, then you won't do that anymore, but yeah.

Alex Booker (03:00):
Wait, did I hear that right? You had to work in a pitch-dark lab when you were doing physics?

Johannes Kettmann (03:05):
Yeah, I was working with lasers and doing some quantum optic stuff. I can't even remember the exact title of my thesis anymore. But yeah, it was interesting. But the lab was pitch dark and I barely saw the sunlight during the whole summer I wrote my thesis, so it wasn't really pleasant and I had to get out of there.

Alex Booker (03:24):
Yeah, the total opposite of working from a beach basically.

Johannes Kettmann (03:27):
Yeah, exactly.

Alex Booker (03:28):
But it's good that you identified that maybe the theoretical side wasn't as appealing to you as some of the practical things. I guess there were a few paths you could have taken, like maybe you try mechanical engineering or something like that, but because you picked up this coding class during school, it gave you a really clear path it sounds like, to go a bit deeper and continue to explore this thing.

(03:50):
How did you feel about learning to code over time? I know that you had this background in logical thinking and it's really interesting to know that that carries over in a way, but obviously, the practicality of it all in terms of coding languages and tech stacks and the tools you use, yeah, it must've been a whole new world to you. How did you navigate that?

Johannes Kettmann (04:08):
It was completely new. During my thesis, we used MATLAB and some Python, I guess, for controlling these machines, so this was the logical starting point for me. But in the end, I figured when you want to start a career in software, MATLAB is probably not the best thing to learn.

(04:26):
So I had a look around and at that time, a friend approached me, he had this startup idea and I said, "Why not? Let's do something together." And this was about apps, like mobile apps. So mobile apps weren't very big at that time and relatively new still. So I started learning Android because I had an Android phone and it's easier. You don't need the MacBook to code an Android app.

Alex Booker (04:51):
How did you teach yourself Android development?

Johannes Kettmann (04:54):
There weren't a lot of courses out there. If I remember correctly, at least I didn't take a lot of courses. It was maybe some Udemy or something for $19 on discount as always. I probably read a lot of tutorials and then also documentation, but I remember that I didn't know how to do things the professional way, so I didn't really know how, in production apps, how developers would send out requests. This was actually something that fell on my feet in one of my first interviews, so it was definitely difficult and I jumped tech stack a lot. As I said, I started with Python and MATLAB and then I did some C because everybody says you should know C if you're becoming a developer, but nobody uses it anymore. And then Android, iOS, and finally at some point, I decided to, with another project, to do more web development, continued with Drupal, and then at some point, I finally landed on React and really loved it.

Alex Booker (05:52):
Oh, and yeah, I know that you make a lot of content around React today that people can and should check out.

(05:58):
I'm spoiled for choice about what direction to take the interview in. I suppose what I want to know most of all, is this startup that you worked at or you were approached to work on where you built the Android app, is that the same as your current company Profy or is that a different story altogether?

Johannes Kettmann (06:13):
That's a very old story. In the end, I developed for almost one year I guess I worked on this project, and because of my lack of experience, we didn't get anywhere. At the same time, my business partner, he also didn't get anywhere because he didn't have experience. So basically, this was just some project that entertained us for a long time and we had big dreams. But I guess the typical thing as a first-time founder is that you just build and build and build and never ship, so this was basically my first startup project.

Alex Booker (06:45):
Did you get paid to build that app or was it more of an equity-type situation?

Johannes Kettmann (06:49):
It was more equity. I got paid a very little amount, which didn't even cover costs I guess, but I was a student back then, so my expenses were very low.

Alex Booker (06:58):
I read actually that you went on to do some freelance work around Android app development. I think you worked on an Android app based on an existing iOS app?

Johannes Kettmann (07:07):
Yeah, exactly. This was around the same time, I guess, when this first startup came to an end. I was out of money obviously, and my business partner had a friend who also wanted to build a startup and he supposedly had some money. He already had an iOS app for his startup idea, and then he asked me if I would be able to translate this to Android. I said, "Yeah, sure, why not?"

Alex Booker (07:29):
Nice. Sounds like a good opportunity.

Johannes Kettmann (07:31):
Yeah, for sure. He offered to pay some money. For me, it was big money back then, I guess like $10,000 or something for a lot of work in the end, but didn't turn out that great actually. So I built this application and after a few months, actually, like two months or so, it already became clear that there are some differences in opinion, I would say, and eventually it turned out that this guy never really intended to pay us. That is at least my assumption because he never paid us and the only thing that I got out of this was experience and a laptop, I guess. So for a six month of work, not the best.

Alex Booker (08:10):
What? He never paid you in the end after all that work?

Johannes Kettmann (08:12):
Yeah. I was obviously looking forward to this money because I was really broke at that time and when it didn't come in, that was really bad news for me.

Alex Booker (08:22):
I mean, that sucks basically. I'm so sorry you had that experience. I think that's such an unfortunate situation to find yourself in, and despite that, I really appreciate your perspective, which is that okay, you got a laptop, but more than that, you got the experience. What was the kind of key takeaway from that experience, would you say?

Johannes Kettmann (08:41):
As a freelancer, I find it very risky, and especially we didn't have a proper contract or anything in place. We were young and naive. This was a friend of a friend, so yeah, why not do this job? But in the end, I wouldn't do it again this way. I would have a proper contract. I would estimate the effort and bill accordingly and probably also get paid some amount of money upfront then at different intervals, again, a payment because at that point we just had this one payment at the end. When it became clear that it wouldn't go through, then yeah, we basically had nothing.

Alex Booker (09:16):
I really appreciate you telling us this story because even then your journey into tech wasn't exactly smooth sailing. You clearly had a bit of a hurdle here with this particular experience, and yet you're thriving today. I think it's so great to hear stories from people who they themselves have taken a slightly winding path to get where they're going.

(09:34):
Maybe you can kind of continue the story from there. How did you find your feet? Did you go on to do more contracting or did you get a full-time position? If it was me, I wouldn't be surprised if you never freelanced again after that experience. It might've put a bad taste in your mouth or something. You might've preferred to go over secure routes of getting an employment contract, for example.

Johannes Kettmann (09:54):
Yeah, that makes sense. But somehow I guess I tasted the freedom of doing this first startup project and then this freelance gig. It's really nice because you can work as many hours or as little hours as you like as long as you keep the deadlines, and once the job is over and you earned your money, hopefully then you can take a break. That was always something that I wanted to have.

(10:18):
And this first freelance job, it didn't turn out well financially at first, but there was also a happy end somehow because this iOS app that I was supposed to translate to Android, this was developed by an agency, and this agency was still communicating with this guy I was working for. I guess he also ripped them off, so I wasn't the only one. What a relief.

Alex Booker (10:40):
What?

Johannes Kettmann (10:40):
They heard that I have good android skills through him and they had a contract for another actually bigger Android app, so they asked me if I want to do it, and I said yes. Time time, a proper hourly rate and stuff like this. This was the starting point.

Alex Booker (10:57):
You definitely got a contract that time, I'm sure.

Johannes Kettmann (10:59):
Yeah, yeah, for sure. And most importantly, this was an hourly rate, so at the beginning of your career, it's really hard to estimate the effort of things like this, like building an app. That seems very easy at the beginning, but then in the details, it can take very long. So hourly rate, that was really nice. So I was just working, building this thing, and then sending them my bills, so that was really cool.

Alex Booker (11:20):
And you've been contracting ever since, I think.

Johannes Kettmann (11:23):
Yeah, exactly. I never left this path of being freelancer or contractor, so at that time, I was more on the freelancing route. I always distinguish these two things. On the one hand, freelancing, which is more project-based, where we have our approach for one project and you estimate how much effort it is and then give a one-time payment or the complete fee, but you're completely free when you work and how fast you work, if you work faster, then you have more per hour basically. And the contracting thing, the difference there is that I'm mostly embedded in teams, so I work more like an employee. I have my working hours more or less. I'm still flexible there, but I work inside a team and I'm really integrated in the processes. I work on an existing code base. So basically just the same thing as an employee, but with more freedom and better payment, at least here in Europe. I guess in the US it's a bit different.

(12:17):
At some point, I figured that there were recruiting agencies, so my first job was with this development agency, but then there are big recruiting agencies that work with big clients. I'm not sure. In Germany, you have Mercedes or banks, companies that wouldn't employ a freelancer because it's peanuts. So they work together with big recruiting agencies and I got on the list of some of those. It was still pretty tough to get invited to interviews because I had little experience, but I had two startup projects at this time and this Android app, so I had some production experience basically, although I was always working alone, but that made it easier, and so I got invited to a few interviews and from there on, kind of slowly improved I guess.

Jan Arsenovic (13:06):
Coming up, be on the lookout for these React mistakes.

Johannes Kettmann (13:09):
This small change reduced the complexity of the code a lot.

Jan Arsenovic (13:14):
Johannes and Alex will be right back, and if you stick around until the end of this episode, you'll also get a discount code for Johannes's React Jobs Simulator. But first, I want to take a look at the socials in your posts about the podcast.

(13:28):
Abiel Ortega shared our last week's episode with Mohamed, and wrote, "Just finished listening to another Scrimba Podcast. Really love the show. Each time I feel like I'll never make it in tech, people like Mohamed inspire me to keep going and not give up." That's really great to hear. That is precisely the reason why we're doing this show.

(13:47):
The Coding Montana tweeted, "I haven't been listening to podcasts, so I decided to try out the Scrimba Podcast. Honestly, I loved it and I would really recommend it to everyone."

(13:56):
And Anthony Nanfito made a post on LinkedIn saying, "Today I'm very happy to announce that I completed Scrimba's Front-End Developer Career path. It was a lot of hard work with many late nights and early mornings. I'm very grateful for Per, all the course instructors, the behind-the-scenes people, the Scrimba Podcast, and the Scrimba community on Discord. Without your collective support, I don't think I could have maintained the motivation to keep going. So thank you, thank you, thank you."

(14:23):
Anthony, awesome. Congrats. By the way, Anthony had a really good Twitter thread about what should we call Twitter now? And I wanted to read it on the show, and when I pressed record, suddenly I couldn't access it anymore. So Anthony, if you're listening to this, please reach out. That was a really fun thread. I really want to read it on the show. Thank you, and once again, congrats.

(14:46):
And if you're enjoying the show and want to support us and make sure we get to do more of them, the best thing you can do is post about it on social media. Word of mouth is the single best way to help a podcast that you like, and plus, you might get a shout-out on the show.

(15:03):
And now we're back to the interview with Johannes.

Alex Booker (15:09):
Do you think that contracting is a good way to get your first job in tech? Say someone's listening, they've been learning front-end development, for example, and they're at the point where they feel ready to apply for jobs. Is going down the contracting route something you can do from the beginning? Is there a approach there? Maybe start with freelancing, start with some projects, build up a portfolio, and maybe use that to get your foot in the door when it comes to these contracting opportunities,

Johannes Kettmann (15:36):
Contracting, I wouldn't really recommend it for entry-level developers. It can be very tough. You join a team and you're expected to ramp up quickly. You don't have weeks or a month to become productive, but it's like, at least from my perspective, it's expected that you ramp up in a few days and commit your first code in that timeframe.

Alex Booker (15:56):
Right. They want you to hit the ground running almost immediately it sounds like.

Johannes Kettmann (16:00):
Exactly. You're expensive, but you also have... Most contractors bring a lot of experience. So yeah, as entry level, I guess it will also be hard to just convince people to actually hire you as a contractor.

(16:12):
Freelancing on the other side, I guess that might be easier because there are lots of people who are looking to build a project and find some cheap labor basically. So I think there are opportunities for freelancing, but I would be careful to still have the tech that you are focusing on in mind. Let's say you want to become a web developer, but work with React. You might find freelancing opportunities for WordPress or Drupal or something like this, but I wouldn't really recommend to go after this because it might make some money, but if your real goal is to become a React developer for example, then you might go into a dead end here.

(16:49):
I know people who have a lot of experience with WordPress and Drupal for example, but they kind of have a hard time to convince employers that they are also capable of doing React. It's just different worlds from my perspective. The one is more a static website building, the other one is real software development.

Alex Booker (17:06):
By the way, what contributed to your decision to maybe put Android to one side and pursue React instead? It's easier to stake out the same technology than learn a new one. And besides, to your own point earlier, if you switch around too much, that can be a bad thing as well. So what kind of made you want to change to React?

Johannes Kettmann (17:27):
Yeah, definitely. I wouldn't recommend to switch tech stacks too often, and that was definitely a mistake that I made in my early career. I had some experience with one tech stack, but then I switched to a different language or environment or something. But at that point, I had been developing Android mobile apps for some time and me and my business partner had, again, a startup idea. This was more website-like, so I decided to go into web technologies, learned a bit of Drupal back then, but it never really convinced me.

(18:01):
And then I saw this talk, a presentation about React, and I guess this was Flux, so the beginning of Redux back then, this Flux architecture, and they explained how there was this pain point I could relate to. When you have an inbox, for example, with messages, unread messages, and you have a menu where you see the number of unread messages, and then again in the header, for example, this small notification bar also with the number of unread messages, and then it can be really complicated to keep those in sync. For example, you press on the menu and then suddenly all the unread messages are gone, but the notification at the top is still showing the old number. And with this Flux, or nowadays more Redux or Zustand or something like this, it's pretty easy to keep those in sync because you have this global state management.

(18:52):
And that was really fascinating for me because I had this pain point and I didn't know how to fix it, and this React thing back then was kind of new, and it really convinced me.

Alex Booker (19:03):
Yeah, that's a great point actually because I suppose React was appealing in its own right. Components were just functions. It's just JavaScript, or JSX, I suppose you could say. There was a modularity to it that allowed developers to incrementally adopt it in their projects, and at the same time, it had the backing of Facebook, or Meta as they're now called. There were lots of good reasons to give it a look compared to Angular or View, but it sounds like, from your experience, React was in a sense leading the way with its approach to state management, how to manage global state, how to make sure all your components and their view of state is in sync. Obviously, in a complex application, you might be fetching data from data sources that can come in at different times.

(19:46):
Every developer kind of has enough flexibility to also fail I guess when it comes to some of these things. It's not immediately obvious how to solve them. You could guess it wrong, but React introduced or at least popularized a lot of patterns and implementations of those patterns in the form of things like Redux. Maybe there wasn't that same conversation around Android in this case. Maybe it just wasn't a conversation that was happening at the time, but you saw the interesting kind of development in the React space that drew you to it.

Johannes Kettmann (20:15):
Yeah, exactly. I remember that I tried Angular for example, and before that jQuery, but jQuery is a whole different world. And Angular at that time, I guess it was Angular 1 before the big version change. It had this two-way data binding concept, and I had this in Android as well, and for me it didn't really work maybe because I wasn't experienced enough with this, but I had this problem with data being out of sync. And with React, it made so much sense that you have this one set of data, or your state, which is basically just a JavaScript object or array or something, and you render your UI based on this data, so the data is the source of truth basically. That was really convincing to me, and in my mind, made the approach to UI so much simpler.

Alex Booker (21:02):
And the rest was history, I suppose. It sounds like you've been happily using React for many years now.

Johannes Kettmann (21:08):
Yeah. I'm waiting for the next thing to convince me. There's always new tech coming up in JavaScript. TypeScript was the last thing that really convinced me and I learned it, although a bit late, but so far, all the other frameworks, I didn't have this eureka moment that I had with React like, "This is a pain point that's really worth solving." A bit of performance increase or something, it doesn't really convince me. I don't think any big team would jump to a new framework just because of a small performance increase.

Alex Booker (21:37):
Yeah. You're kind of I guess talking about Svelte, essentially.

Johannes Kettmann (21:42):
Yeah, for example.

Alex Booker (21:43):
But these libraries, they might have a few quality-of-life improvements. They might be a bit faster, but fundamentally, they don't represent a paradigm shift in the way that React did. It's not exactly worth dropping everything to pick them up when React is so established in its ecosystem and the job market.

Johannes Kettmann (22:03):
I'm pretty sure in a few years, there will be something that's really worth considering, but at the moment, I don't see that.

Alex Booker (22:09):
And now you are the person I suppose behind Profy, Profy.dev. We'll link it high in the show notes for people to check out. I can only read the heading. I'm curious to hear from you more, but the heading says, "Your first React job starts here." And as I understand it, it's kind of a React Job Simulator for aspiring junior devs. That sounds so fascinating and obviously super relevant to what we're doing at Scrimba with our career path and our courses on React. I know a lot of people listening want their first job in React, so maybe you can tell us a bit more about, yeah, genuinely very curious, what this project is all about and where it came from, where you saw the need and the gap for something like this.

Johannes Kettmann (22:48):
Yeah, thanks. I realized that the basics of JavaScript and React and a lot of other technologies are very well-covered with video courses or interactive courses, tutorials, things like this, but from my own experience, I realized that there's a huge gap between what you learn in courses and what you will encounter on the job, especially when you start working in a team and on an existing code base. Most, let's say, entry level developers who haven't had the experience in a team yet, they only worked on their own code base. After a few months, it can be really hard to understand your own code and fix it, but once you become a team and there have been dozens of developers through the lifetime of this project working on the code, you may not have even a person to ask questions to because this person has long gone.

(23:36):
So it's really something different to work on this existing code base and read, understand, bug fix, debug this code that other people wrote. And apart from that, there's even more to it. It's not only the code, but there's the projects, the repositories are huge. There's so much tooling. You start with TypeScript, but then there's ESLint, Prettier, Husky, the pre-commit hooks, and the whole GitHub CI pipelines, things you never heard of before. It's just so complex when you start and you don't have experience with that. How do you even get the code from your machine to the GitHub repository? How do you get it on the master branch then? I remember how overwhelming it was in my first years and it took really years for me to get comfortable with this.

(24:27):
And so the idea behind Profy and the React Job Simulator was that I can kind of front-load this, so the students in my course, they get access to this existing code base that I developed. It's like I really focused on a good setup and professional code quality, good tooling, like React Query, but also TypeScript and other things. Then there's testing.

Alex Booker (24:51):
Just like you would find in a real world project if you got a job.

Johannes Kettmann (24:54):
Yeah, exactly. And then on top of that, you get a few tasks. If I tell this to professional developers, they are all like, "Yeah, this is exactly how we work." Because as a professional, you don't start just changing the CSS or working on something, but you have tasks that you work on. So you take a task, you work on it, you fix it, you get it into the master branch, and then you continue with the next task, and this is usually how you would work.

Alex Booker (25:19):
Is the student kind of just working on their own copy of a repo or is there a kind of workflow here where they maybe make a pull request and they get some help merging it in or something? Because that's kind part of it sometimes, isn't it, in a real world code base, collaborating with others?

Johannes Kettmann (25:33):
At this moment, there's no real collaboration, but every student gets their own repository to work on, a React Next.js repository. Then when they work on the task, they create a new branch, they push this code to GitHub, and then they create a pull request. So this might be completely new to the listeners, but this is totally standard in professional projects. And then with this pull request, I created a GitHub bot that basically just enforces the proper workflow. So you request a review by this bot and the bot approves, so you can merge the pull request. There are plans to make this a bit cooler, like doing an AI review or something, but I'm not quite there yet.

Alex Booker (26:14):
And then you have a sort of YouTube channel that goes alongside this. In fact, one of the first videos I saw from yourself and a big reason I was excited to speak of you on the pod is that you were kind of reviewing a junior React developer's code, offering feedback to reduce the code footprint and optimize the code, basically make it more readable. Talk to me a little bit about the motivation behind that kind of video.

Johannes Kettmann (26:37):
Yeah, I really like doing code reviews. I guess a lot of developers don't like it, but I am really into that. When I look at the code that people in my program produced, there are a lot of common mistakes, and this particular one was very interesting because there was a very simple fix at the very beginning of the ideation of the code.

(26:57):
So the developer there used, I'm not even sure what it was anymore, but I guess they used an array or something and if they had used a map instead of an array, the whole code changes, and this is exactly what I showed there. So it was actually kind of a lucky coincidence that this was a really nice project or code to review and to adjust. But yeah, this small change, like migrating from this array to a map, if I remember correctly, or a set even, reduced the complexity of the code a lot and I was able to throw away so much code just because of this.

Alex Booker (27:32):
Oh, I love that map versus array or maybe even a set, data structure. Because oftentimes you can use these kind of data structures to the same effect, but then there are different data structures for a reason. That's not always something you can fully grasp and understand why there are multiple things that seem to do something similar until you experience it.

(27:52):
What are some of the other kind of common mistakes you see junior React developers make? I saw another video of yours where you produce the complexity with a single source of truth. For example, applying some, well, I suppose you could call it a pattern of some sort, a way of structuring the application and producing a sum of all the individual React features you've learned about in a more effective way.

Johannes Kettmann (28:16):
Yeah. So this single source of truth is actually a great example because this is one of the most common things I see, not only junior developers to be honest, but also very senior developers do this all the time. This means that you, for example, you have a state and some data from an API. This data from an API is, for example, a table and you render this list of table items. Then you want the user to select one of these items. And what people often do is to copy the complete table item into a state. So basically, you have now duplicated the data. You don't have a single source of truth anymore because you don't really know where this data's coming from.

(28:59):
So if you would update the data from the API, you also would need to keep the data and the state in sync. This causes a lot of problems and the very simple fix is here to just keep the ID of the data from the API inside the state. So don't copy the whole thing, the whole object, but only the ID. This works wonders already.

(29:19):
In this particular case, I saw a Twitter thread recently where a guy was really pushing for keep your state in the URL, and this is exactly what I did in the video. You don't always need to keep things in a state in React use state for example, but you can also have the current filters or the selected items or something inside the search perimeters of the URL, and this way you don't even need to touch context, redux, or state, but you have this one single source of truth. There's no duplication, especially if you need to persist things in the URL. Yeah, this is really cool.

(29:57):
Another thing that I see junior developers do often, which is also often caused by this duplication of data inside the state is the use of useEffect. It's also not junior developers, but also all kinds of developers actually. Nowadays, when I see a useEffect, I always think to myself, is this really a proper use for this and do I really need this? Maybe I can get rid of this. Because often, the state, you have two different state variables and one can be calculated from the other, but if you separate this in two states, then you need a useEffect to keep them in sync. And if you remove this useEffect or if you remove this duplicate state, then you can remove the useEffect as well. So this is always something that triggers me and I would really sit down for five minutes, just think, is there a different solution for this useEffect? You usually don't need it in most cases.

Alex Booker (30:48):
Yeah. Again, these are just brilliant examples because you generally, in a course, you learn the function, you learn about useEffect, its application, where it's useful, you learn the arguments, you learn how to build a feature using useEffect in this case, but then it's these kind of anti-patterns, that if you just don't know, you don't know kind of thing. And if you are building a project, it might suffer from an anti-pattern like this, but without somebody to point it out or warn you, you're not likely to learn the difference. I think when you become a junior dev, you're very lucky to get this kind of feedback via code reviews and things, but until then, or if you're doing the freelance routes, it's really cool to get YouTube videos like this and resources such as yours, Johannes, to help out. So I think it's really cool what you're doing.

(31:33):
One thing that strikes me about your experience is that you often have to interview for roles I suppose if you're contracting. Contractors typically work for, I don't know, three months to a year, something like that. Otherwise, there'd probably be a full-time employment. So I'm very curious to learn a bit more about how you approach jobs and interviews and things like that, your advice for junior developers, but what do you say we break the interview up a little bit with a round of quickfire questions?

Johannes Kettmann (31:59):
Yeah, sure. Let's do that.

Alex Booker (32:04):
What is one learning resource that has been the most impactful to you over recent years?

Johannes Kettmann (32:09):
Actually, posting my own stuff on Reddit has been the best learning resource because I get criticized so much and there are better solutions to what I do, and it has been illuminating really to share my own stuff.

Alex Booker (32:20):
Oh, yeah. That's that kind of thing, isn't it, where if you ask a developer a question, you might never hear back, but if you put a wrong answer or an answer they think is wrong out there, they'll very quickly jump in to correct you if they think they have a better perspective.

Johannes Kettmann (32:33):
Yeah. I published this blog post recently, again, like a refactoring, and then this one guy came and proposed a one-liner, really a one-liner for my complex function algorithm that I introduced there, and yeah, you could replace it with a one-line native function. That was really humiliating.

Alex Booker (32:52):
What is your favorite technology to use at the moment? I could probably guess.

Johannes Kettmann (32:56):
Yeah, so React is there at the moment. I also really love, love TypeScript. I've been into it for a few years now and it's been a game changer from my perspective.

Alex Booker (33:06):
Is there a kind of technology or maybe advanced feature that you're interested in learning?

Johannes Kettmann (33:11):
I really would love to get more into this whole AI thing, machine learning, but more on creating the models, not using them side. I'm pretty old now and I don't have much time, so I'm not sure if I would make that.

Alex Booker (33:24):
I could see that being very useful for the work you're doing at Profy.

(33:27):
Johannes, what kind of music do you go to?

Johannes Kettmann (33:30):
Oh, that's very mixed. In my earlier days, it was mostly rock or met rock or something, but nowadays, I have a lot of different music and mostly with a bit of beat, so like African Beats or something like this, sometimes hip-hop.

Alex Booker (33:44):
Do you look up to or follow anyone in the tech community that maybe we can check out and follow after the show or subscribe to on YouTube, for example?

Johannes Kettmann (33:52):
Yeah, I'm not big on social media, but I really love the stuff that Kent C. Dodds is doing, although I never tried Remix, but yeah, maybe I should.

Alex Booker (34:00):
Love Kent C. Dodds and his work. He actually joined us on the podcast a while ago now, so we can link that in the show notes for people to check out.

(34:06):
I don't think I've told this story on the podcast before, but actually, one of the ways I got my first junior developer job... Well, first of all, I was listening to a lot of podcasts because I found that when I listened to podcasts as a junior developer, sometimes I would learn about tips like you gave today, Johannes, around anti-patterns and design patterns to follow and things like that, just things you might not necessarily pick up if you're not plugged in I suppose. I also liked the career advice and I found it just made me more eloquent at talking about code. I got a sense for how coders spoke and I think that helped with interviews and things.

(34:39):
And one of the podcasts I really liked at the time was called JavaScript Air, and it was hosted by no other than Kent C. Dodds. In his first interview on that show, he interviewed Brandon Eich, known as the creator of JavaScript, and in subsequent episodes, he brought on a panel with people like Dan Abramov and the React team, just super inspiring stuff. I really loved it. And so I actually reached out to Ken and said, "Hey, I'm a new developer. I don't have any professional experience really, but I really love your show. I see you have a website for the podcast and you're working on it. Could I help at all? Is there any way I can be involved?"

(35:13):
I sent that as a cold DM on Twitter. I'd never spoken to Kent before. He's even more famous now than he was at the time, but he was already quite prolific I feel like, so I didn't too much expect to hear back, but being such a kind and generous person I feel like, he responded quite quickly, jumped on I guess a Skype call or something at the time. This was a few years ago now, and gave me some pointers about how I could get started. He was like, I forget the specifics, but he gave me something small. He was like, "Yeah, there's a GitHub issue here. Maybe you can try at it and if you need help, let me know." It went well, and Kent merged my PR, and in time, I contributed more and more to the website. It was React actually, but it was a statically generated website. Kent was using React on the server side to introduce reusable components and things. It was ultimately producing static HTML though.

(36:00):
So I guess in a sense, that was my React Job Simulator, Johannes, because there was also another lad working on the project with me, someone named Connor, if I recall. At one point, we got to this position where we had a pull request with 90 commits in it, and I think for the first time we both realized... Well, I think we were more like, "Crap, how do we deal with this merge conflict?" The kind of what real world experience you don't necessarily get when you're just building your own projects.

(36:27):
So yeah, that was just the connection I made there. Definitely check out Kent. I just remembered that was kind of a job simulator for me. Maybe it's a good testimony for what you are doing because if it's half as useful as that experience was for myself, then it's definitely something worth pursuing.

Johannes Kettmann (36:42):
Yeah, but that sounds like you did a really smart move there because first, you made contact with a very important influence in the React environment, plus you gain some collaboration experience and open source experience, so this is all something that you can show on a resume.

Alex Booker (36:58):
Absolutely. Yeah, there's definitely something here and I'm really happy that you are sort of making it accessible via Profy. Really cool.

(37:05):
We kind of segued out the quickfire questions there, but just to put a bow on it, that's the end of the quickfire questions. We don't have much time. We've spoken about so many interesting things already, but I would be remiss if we didn't use the last few minutes really to talk about your advice on how to get work and impress during interviews. How do you think junior developers can stand out during the job application and interview process?

Johannes Kettmann (37:32):
There are a few things that come to my mind, and first is get experience with GitHub and a common GitHub workflow. This is something that most junior developers don't know, and I had this a couple of times in interviews where we asked the developer, "Can you explain or do you have experience with Git?" And it was basically, "No, I don't have." If you can say, "Yeah, I know how to work with branches, PRs, reviews, stuff like this," it's really a plus and makes you look so much more professional.

(38:03):
In fact, I have a free course for one of these GitHub workflows. Check out my website and you can find that. It's also something that many students of mine actually told me that this was really helpful in interviews.

(38:14):
Then the other thing is to get comfortable with testing. There are two or three big players in testing in the React world. One is React Testing Library. Again, Kent C. Dodds is the creator. So this one is really once you join a team and you will probably write tests, most of the tests you'll write with React Testing Library. Then there's Cypress for end-to-end tests. I really recommend looking at Cypress because nowadays, the API is very similar to React Testing Library, but they have a really nice UI. You can basically see the test executing inside the browser and click everywhere and just see what the test is doing. So this is a nice entry point I think. And finally, there's Playwright, which is also end-to-end tests, so similar to Cypress and increasingly popular now.

(39:04):
But I would highly recommend checking out Cypress and then going once you're a bit comfortable with writing tests, checking out React Testing Library because those tools will really have impact. And again, almost no junior developer knows how to test.

Alex Booker (39:19):
Exactly. Definitely something that can help you stand out.

(39:22):
I know that you are a big fan of TypeScript. Would you recommend a junior developer learn that? Is it the right thing to prioritize over some of the other things we've spoken about, do you think?

Johannes Kettmann (39:35):
Yeah, that's a good question because TypeScript is also so much more common nowadays. I guess you will rarely find a React project without TypeScript.

(39:43):
I have to say when I started development, I think it was a bit easier because we only had React, JavaScript, and then a bit of testing, but today, there are so many tools like TypeScript on top of React, so I would definitely also look into that if you have the capacity, for sure. This also lets you stand out from other junior developers, but I also know that there's so much stuff to learn already and I wouldn't hold onto learning because this is also procrastination, right? If you just continue learning until you feel comfortable, you will never feel comfortable. So at some point, build one or two projects and then just go out and apply for jobs or start applying and continue studying at the same time because you never know.

(40:26):
Another thing that is really important during interviews is your personality. One of my students recently got a job and I saw his code. It's not the best code that I've seen in the program. There were really, really good developers in my program, but they cannot find a job for some reason, and this guy, he really nailed it. Not the best code, but really cool personality, really cool approach, and he just got a job offer like this. They actually thought he's a mid-level developer I guess, but then found out that he's more of a junior later on.

Alex Booker (40:55):
Can you tell us a bit more about this?

Johannes Kettmann (40:57):
You had already good experience, but I guess his approach was really good. I'm not exactly sure how he came into contact with a recruiter on LinkedIn, and then he prepared so much for the interviews, like he scripted stuff.

Alex Booker (41:09):
Oh, I like that.

Johannes Kettmann (41:10):
Asked what questions will they ask me? How should I answer this question? They sent him questions upfront and he asked my Discord group, "How can I best answer this?" And I told him, "Here, if you want to look professional, do this, do this." He did that. He also got feedback from other people. I guess he also had a mentor at that time, but this whole approach was not like, "Oh, I just shoot out applications like crazy and then hope to get interviewed," but he was on top of it and that was the difference that I saw to other people.

Alex Booker (41:41):
Very cool. There's definitely something there I think. You can go very broad and shallow I suppose, but when you do see an opportunity where you think there's a great alignment, as in you would really like to work there and on the product and with the team, and you also feel like your experience could be a really good match as well, it's nice to know that there are tools in your belt that you can use to go a bit deeper into the opportunity.

(42:05):
One thing you mentioned, which I really like, is being proactive during the interview phase and asking what's coming up next and how to best prepare and things like that. Just communicating well to maximize your opportunity of being successful, even though basically none of that stuff has anything to do with React at that point, right, it's more of a soft skill?

Johannes Kettmann (42:21):
Yeah, exactly. But soft skills are so important because in the end, this is actually a good exercise. Imagine that you are sitting there being an interviewer and you interview yourself and then what would you like to see? Obviously, the tech skills need to be there. You cannot hire somebody who has no clue, but in the end, you want to have somebody you want to be friends with, or not necessarily deep friends but-

Alex Booker (42:44):
Friendly.

Johannes Kettmann (42:45):
Have a drink after work, have a coffee or lunch because this is essential to collaboration in a team. I would say tech skills is maybe 50%, but the other 50% is personality and convincing people that you are actually willing to do the work and are capable of learning and improving because no junior developer's on a good level at the beginning, but they all need to improve, so this is something you need to convince people of.

Alex Booker (43:09):
I think it's like a human nature thing to some extent as well. Liking someone means you trust them and if you trust them, you might extend them an offer, if that makes sense. I'm not saying you have to be like George Clooney charismatic. It's not really the point. It's obviously a full picture, including your technical skills and experience. You will be working very closely with these people over a long period of time potentially, of course you want to get along on some level. And I think when you're a new developer and you're really kind of hustling for an opportunity, this is something that's totally in your control and sometimes it's like a low-hanging fruit.

(43:44):
If you've been learning to code for a year and then hopefully you're not procrastinating, that was a good tip as well, not to procrastinate too much because you can definitely end up in a infinite cycle of learning instead of doing the actual hard thing, which is putting yourself out there to get a job. That's a very good point. But say you do pop your head out one day and you start applying for these opportunities, after a year or two of learning to code, you're not going to become a dramatically better coder overnight or over a week or over two months. It's like anything; the longer you've been doing it, the slower the improvement is. That's just the way it goes. But if you haven't really thought about your interview scales or how to position yourself as a professional, oftentimes there's a lot of wins to be had here. You can really change the game quite quickly if you optimize and think about these things.

Johannes Kettmann (44:28):
An encouraging word to all the listeners out there who are just trying to find their first job. I still fail at a lot of interviews. My interview skills are really not good, and what I'm good at is, in interviews at least, my social skills, so this really saves me often. I get technical questions, even hoisting, and sometimes I just freeze because I'm excited or I don't know. I am not good with these technical questions.

Alex Booker (44:53):
Yeah, pop quizzes.

Johannes Kettmann (44:54):
Yeah, exactly. In my last job interview for the job that I'm currently doing, I really failed at a few technical questions, but somehow they still took me because I was likable in the interview, I guess. So it's not the end of the world if you fail a few technical questions. It's like you can still have a good personality and be picked for the job.

Alex Booker (45:13):
How long have you been freelancing for now?

Johannes Kettmann (45:15):
Must be about 10 years.

Alex Booker (45:17):
Yeah. It's really encouraging to know that even someone with a decade of experience doesn't necessarily nail every opportunity. It's very nice that you can be that transparent and honest because I think sometimes as a junior looking at GitHub and Twitter and social media and all these things, people only really highlight their successes. They don't necessarily highlight the stumbling blocks, so I appreciate you doing that, and I think that's a really genuine and nice note to end the interview on.

(45:43):
So Johannes, thank you so much for joining me on the Scrimba Podcast. It's been a pleasure.

Johannes Kettmann (45:48):
Yeah. Thanks again for the opportunity. It was a really nice chat.

Jan Arsenovic (45:52):
That was the Scrimba Podcast, Episode 129. If you're interested in Johannes's React Jobs Simulator, you can check it out at profy.dev. That's P-R-O-F-Y dot-dev, and if you want to sign up for it, we have a discount code for you. You can sign up for the cohort wait list and use the coupon code Scrimba during checkout for 10% off when the cohort launches. The next cohort starts in a couple of days.

(46:19):
If you made it this far, please also subscribe to our podcast. We are a weekly show and you can find us wherever you get your podcasts. The show is hosted by Alex Booker. You can find his Twitter handle in the show notes. I've been Jan, the producer, and we'll be back with you next Tuesday.