The Scrimba Podcast

Meet Kevin Tanzyl! Originally from New Zealand, Kevin moved to Japan to become an English teacher. But after a while, he felt like he hit a plateau. Kevin then tried coding, and after a sting in the infamous tutorial hell, he discovered Scrimba. While learning to code, he made a React app for English teachers, which is still used in Japanese schools! This game-changing portfolio project for Kevin caught the eye of employers and recruiters alike.

Within a couple of months, Kevin got his first developer job, but several months later, he realized that it wasn't a good fit after all. In this episode, you'll find out all about Kevin's career change, learning path, and hurdles along the way. You'll learn how to pick your portfolio projects and why you should focus on basic programming principles while maintaining a technology-agnostic approach. Kevin also shares his approach to dealing with stubborn bugs, why "no pain, no gain" applies to coding, and how learning to code compares to learning a new language. Plus, how's the work culture in Japan different from the Western one?

🔗 Connect with Kevin
⏰ Timestamps
  • "Software development involves a lot of math, so I avoided that" (01:13)
  • How Kevin started teaching English in Japan (02:51)
  • Why Kevin wanted a career change from teaching: the tech world doesn't stop! (03:51)
  • How did learning programming compare to learning languages? (04:56)
  • Why Kevin struggled to learn to code - and how he solved that (05:43)
  • Do you need to go to university to become a software developer? (07:25)
  • What are the differences between a software developer and a web developer? (08:06)
  • Community break with Jan the Producer (09:37)
  • Kevin learned on Udemy, freeCodeCamp, and,  ultimately, Scrimba (12:17)
  • Tutorial hell (14:02)
  • The path of least resistance is not the right one for coding (14:57)
  • How to fix very stubborn bugs (15:53)
  • How Kevin made his number one portfolio app (16:44)
  • Picking a portfolio app: ask your friends and family and solve a real problem they have! (18:56)
  • Killing three birds with one stone (I mean, feeding three birds with one scone!) (21:05)
  • How Kevin landed his first dev job... and didn't like it (23:20)
  • How Kevin landed his second dev job (24:24)
  • "They just wanted to see the willingness to learn" (26:05)
  • Quick-fire questions! (26:43)
  • Did Kevin have a tech interview? (28:13)
  • Your portfolio helps an interviewer help you (28:50)
  • "What are the things you think are lacking?" (30:01)
  • The working culture in Japan (33:13)
🧰 Resources Mentioned
⭐️ Leave a Review

If you enjoyed this episode, please leave a 5-star review here and tell us 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 that he can thank you personally for tuning in 🙏 Or tell Jan he's butchered your name here.

Creators & Guests

Host
Alex Booker
Host of The Scrimba Podcast
Producer
Jan Gregory Arsenovic
Producer of the Scrimba Podcast

What is The Scrimba Podcast?

Learn from inspiring developers about how they found meaningful and fulfilling work that that also pays them well. On The Scrimba Podcast, you'll hear motivational advice and job-hunting strategies from developers who've been exactly where you are now. We talk to developers about their challenges, learnings, and switching industries in the hopes of inspiring YOU. This is the podcast that provides the inspiration, tools, and roadmaps to move from where you are to work that matters to you and uniquely fits your strengths and talents.

Kevin Tanzyl (00:00):
The really good question to ask is, "Judging from my skills and all the projects that I made, what are things that you think are lacking?" And the answer they gave me took me by surprise because he asked, "Well, don't we all have things that we lack in our skills?" It's like, "Wow, that's something I don't hear every day."

MUSIC (00:19):
Scrimba.

Alex Booker (00:19):
That was Kevin Tanzyl, a Scrimba student who was recently hired as a front-end developer in Japan. Kevin moved to Japan from New Zealand to work as an English teacher originally before learning to code. While learning to code, he built a flashcard app that became the talk of the school. As teachers came to rely on React code Kevin wrote to educate their students. This was a game-changing portfolio project for Kevin that earned him regard with employers. Within a couple of months from creating the project, he got his first job, but it wasn't quite what he was expecting.

(00:55):
I'm your host, Alex Booker, and you're listening to the Scrimba Podcast, a weekly show where I interview recently hired developers like Kevin, as well as seasoned industry experts, to help you learn to code and land your dream role in tech.

(01:10):
Let's get into it.

Kevin Tanzyl (01:13):
I never really thought of becoming a programmer. My dad used to be a computer technician, so I would naturally be interested in computers and technology just from him rubbing it off on me. But I never really thought of programming because it wasn't in my interest in the beginning. I did consider it when I was going to uni, but then I realized that, "Oh, I'm not actually not that great in math," and I saw that software development involves a lot of math, so I avoided that.

(01:41):
But then throughout my uni life and then just working in New Zealand and after coming to Japan as an English teacher, I decided that I wanted to try something new. At first, I actually found a Udemy course on iOS app development and I was like, "Oh, that might be pretty exciting," because I do like phones, I do like apps, and I could maybe just give it a go and try making one. I could not go past the first five videos, and I just couldn't understand the logic. It was just too much for me.

Alex Booker (02:11):
Oh, really?

Kevin Tanzyl (02:12):
Yeah, I put that off. And then after a year later, I stumbled across HTML and CSS, and I was like, "Okay, that looks pretty cool and it looks pretty fun, designing stuff and putting colors on things and just seeing things pop into your website straight away." So I decided to give that a go, and I started with a Udemy course from Colt Steele, and then I started supplementing it with freeCodeCamp as well.

Alex Booker (02:40):
You mentioned briefly that you were teaching English and then you came to Japan to teach English. Can you elaborate a bit more on your origin story there? What were the things you were doing before learning to code?

Kevin Tanzyl (02:51):
Oh, right, yeah. So before I came to Japan, I came on this program called the JET Program. Essentially, it allows you to be like an assistant English teacher helping the Japanese English teachers here teaching in the public schools, and then I was teaching at three different elementary schools. It was just fun making different English games and helping planning out English lessons for the kids.

Alex Booker (03:16):
This was a career for you, you thought?

Kevin Tanzyl (03:18):
Yeah, yeah. Originally, I thought maybe I could become a teacher because I did quite like teaching. I did teach a few of my friends, like one-on-one tutoring Japanese. So I thought, "Yeah, why not give it a go?"

Alex Booker (03:34):
Okay. So you were teaching children in Japan English, but you also had taught yourself Japanese and were teaching some of your friends how to speak and read Japanese. That's amazing.

Kevin Tanzyl (03:42):
Yeah, yeah. Thank you. Yeah, so I pretty much learned Japanese since I was in middle school, and yeah, I thought I could just use all of that together and see what it's like becoming an English teacher here.

Alex Booker (03:51):
What changed? What drew you to programming as a career as opposed to going deeper down the teaching route? It sounded like you were pretty successful at it.

Kevin Tanzyl (03:59):
So I think I was feeling like I was hitting a plateau with teaching because I didn't feel like I could go further. And then I saw programming becoming quite a attractive field to get into because there's so much studying and so much learning and there's no stopping in that field, so you just keep going and learning new things and that's what I really like, just always liking being updated with all the latest and greatest and all the new tech that's out there.

Alex Booker (04:27):
That's such a great point really, because while a language like English or Japanese can go very, very deep, everything that has been studied or written about is kind of a closed book, right? Nobody's innovating necessarily in spoken language. But when it comes to the world of software and programming languages, well, it's hard to imagine plateauing when things move so quickly.

Kevin Tanzyl (04:49):
Yeah, the tech world doesn't stop, just like with AI and stuff coming up, it's just like there's so many exciting things to learn.

Alex Booker (04:56):
How did learning programming languages compare to linguistics?

Kevin Tanzyl (05:00):
Syntax-wise, it's kind of the same when you learn a new language. Japanese, Spanish, English, first, you just need to learn how to use the grammar, use the words, when to use them, and the cultural context. It's the same with programming languages. I think it was like with JavaScript and Ruby and stuff, you just need to know what these functions are, what these methods are, what these array prototypes are, and then you just need to know where and how to use it.

(05:26):
I think the only difference is that it can go deeper with the logic, right? It can get pretty complex.

Alex Booker (05:32):
That's a great word. It is the logic as well as the grammar or syntax of the programming language. And you mentioned before that it was maybe a lack of confidence in maths that deterred you from programming. How did you find the logical aspect of languages like JavaScript? Did it come quite naturally to you?

Kevin Tanzyl (05:48):
No, it was pretty bad. I struggled making a really simple calculator app and it took a long time for me to try to overcome that. I was very comfortable with HTML and CSS and just very basic simple logic, but the moment when it comes to making more complex things, that's where I stumbled a lot and I had to really try my best to find different resources and try to learn from other people how to solve problems and how to solve computer logic problems.

(06:19):
But I think basically, the main takeaway I got from learning all that was you have to go through your code slowly and you have to, as my coworker said, you have to really just follow the data where it's going, and you also have to just really plan it out before you start coding. Write it on a piece of paper, draw a diagram, anything, so that once you have a framework there, then you can just follow it and just Google away and just find all the necessary tools and language tools that you need to solve it.

Alex Booker (06:49):
That's such a good tip right there, slowing down to speed up by thinking through the logic maybe on paper, and awesome that you could get some help from someone who could steer you with that advice. I think oftentimes when we're learning to code and we look at online platforms, it can feel a bit isolating maybe. The curriculum's there, the content's there, but sometimes it's having people around you that can make more of a difference.

(07:13):
Did you ever consider going down the bootcamp or university routes to learn to code? You mentioned that you latched onto online courses quite early on, and I'm just wondering what the story was surrounding that decision.

Kevin Tanzyl (07:25):
I did read about how people got into becoming a web developer. I know that becoming an actual software developer, you definitely need to go into uni, but after reading through Reddit and different forums, people were saying like, "Oh, you can become a web developer. You don't necessarily need a degree. A degree would help, but there are people who did get in without a degree or just through a bootcamp." So I was like, "Huh. Why not? Why not give it a try? I'll just try to take some courses and see how it goes." And so that's what pushed me to just give freeCodeCamp and The Odin Project and stuff and just give it a try, basically.

Alex Booker (08:02):
Out of curiosity, now that you've landed a role in tech and you're in the industry, how do you view the differences between a web developer and a software developer?

Kevin Tanzyl (08:10):
It really comes down to how complex the system gets. I've never really touched proper software developing, like people working with C and C++ and all those complex languages. But I would say logic, syntax, everything is very similar. It's just I think the complexity and the scale of the system makes the whole difference and how difficult it is, basically.

Alex Booker (08:33):
I think that there are some websites that are rather complex and tooling around web development that's rather complex as well. You can imagine the intricacies of a project like Google Docs, for instance, or even a developer tool like TypeScript. I do think that there can be some real complex engineering that goes into web development, but what you are describing, I suppose, is a different category, which might be more low-level programming such as working with C or C++ to implement firmware or compilers or database engines and things like that. It's just one more example of the breadth of tech, isn't it, and all the different options we have at our disposal?

Kevin Tanzyl (09:11):
Yeah, that's right. It's just like a vast world out there, and honestly, I feel like web development is a nice entry into programming. This is just my personal opinion, but I just feel like it eases you in there and then you can decide on your own. After you've properly matured in your career path, you can decide, "Hey, I want to become an AI engineer," or, "I want to design complex payment systems."

Jan Arsenovic (09:37):
Coming up, portfolio projects that make it meaningful.

Kevin Tanzyl (09:41):
You know you make all these calculator apps and movie apps and stuff, of course they're really great practice, but it's really hard to get people to use them.

Jan Arsenovic (09:50):
But first, let's take a look at our socials.

(09:53):
Hello, I'm Jan, the producer, and this is the segment of the show where I go through your LinkedIn or Twitter posts mentioning our podcast as well as your reviews from various podcasting apps and your comments and YouTube, and I give you shout-outs. Today, I'll read a Twitter thread by Kardic Mohan, I hope I'm not butchering your name, if I am, I'm sorry, please tweet at me and I'll rectify it, who has recently listened to our interview with Alex Kallaway, the creator of 100 Days of Code.

(10:25):
It says, "Wow, I was planning to start a 100 Days of Code challenge and I stumbled upon this podcast from Scrimba. Here are the key takeaways:

(10:33):
"Number one, have discipline. The first few days are the hardest.

(10:36):
"Number two, try to adjust the rules and make a plan. So make a plan of what you want to achieve in 100 days.

(10:44):
"Number three, if you want to do it in multiple rounds, it's fine. You can pick a particular technology you want to explore or a project you want to do and stick with it.

(10:54):
"Number four, even if you don't have an hour of unbroken time, make it 30 minutes, 20 minutes, whatever it takes. But in between tasks, if it doesn't take much of your brain power, try to study something adjacent and that can help a lot to get into that mindset.

(11:11):
"And number five, if you skip a day, don't think about ending the challenge or don't think you're a failure, just continue doing it."

(11:21):
This is a great roundup and I think it can help a lot of people starting or already doing 100 Days of Code. And if you like these tips, I can definitely recommend you listen to the entire episode about 100 Days of Code and our interview with Alex Kallaway. I'll be linking to it in the show notes.

(11:42):
If you like what we're doing and if you'd like to support the show and make sure we can make even more of it, the best thing you can do is to tell somebody about it. You can do it in person, you can do it on socials, you can do it on Discord, you can leave us a comment on YouTube, or you can leave us a rating or a review in your podcast app of choice. Of course, as long as your Twitter or LinkedIn posts contain the words "Scrimba" and "podcast," we will find them and you might get a shout-out right here on the show.

(12:11):
But for now, let's go back to the interview with Kevin.

Alex Booker (12:17):
So how did you learn to code specifically and what were the challenges that you remember?

Kevin Tanzyl (12:22):
I started learning coding using Udemy, especially Colt Steele's web development course, and I used freeCodeCamp and The Odin Project. They were great at first, but it was really hard for me to understand the concepts, especially I was struggling with JavaScript a lot. So then I was looking around Reddit to see if there's any other great learning platform, and then some people were suggesting Scrimba, so I gave that a go.

(12:49):
And just trying it out, the interactive code editor, that was magical. It was great. It was just like having the tutor right there in front of you and then with the tutor there saying like, "Okay, do this exercise and try to output X and Y and blah, blah, blah." And it's like, "Okay, I can do it just straight on the computer. It's no hassle, no delay." Whereas with Udemy and stuff, it's like you have to set up your code editor and then you have to pause and replay the video and it gets very distracting, all these little pauses, whereas in Scrimba, you just go straight in and then it's easy.

Alex Booker (13:27):
What did you think of the project-driven nature of some of the modules?

Kevin Tanzyl (13:31):
I think they were great just because they reinforced the concepts really well. I know other resources, they do use projects as well, but with Scrimba, it's because it just feels closely tied in. I remember with learning the objects and stuff and the object or in the programming, just straight away making a game, a basic game from that. And then how I think Tom, Tom Chant, when he was explaining the project and then he also inserted new concepts on the way, it made it really easy to understand everything.

Alex Booker (14:02):
That makes me so happy to hear. I've been working with Scrimba for probably four or five years at this point, and it still really puts a smile on my face when I hear people have a fantastic experience with the product. I really relate to it as well because I was that person learning on traditional videos, in my case on YouTube, and I relate so much of what you're saying about that friction of pausing and playing and copying. And I sometimes found myself in what people describe as a "tutorial hell." Have you come across that term before?

Kevin Tanzyl (14:30):
I read it a lot everywhere online, and I was in that hell too.

Alex Booker (14:35):
Oh, seriously?

Kevin Tanzyl (14:35):
I didn't realize that I was going from one tutorial to another tutorial and then I was like, "Okay, maybe the teacher's teaching method doesn't vibe with me or something." But it was just me avoiding trying to do projects on my own, and that's where Scrimba in and this is like, "Oh, wow, they actually not force you, but it pushes you to start doing your own projects."

Alex Booker (14:57):
There's got to be a quote out there, something about taking the path of least resistance not being the right thing to do for coding. It's normally when you push through what's making you a little bit uncomfortable, just sitting down and learning that hard thing or really challenging yourself to build something from scratch, that's when you learn the most, I think.

(15:17):
This is the Scrimba Podcast. We of course talk about Scrimba, but I never intend to plug Scrimba or be overly biased, even though I do love the product obviously, but I love the way in which you get to push your comfort zone, but you're not totally sink or swim either. You're not looking at a blank canvas thinking, "Where do I even begin?" You are somewhat guided and you're given the white spots to fill in, and if you get stuck, there's always help. And I think it's that kind of combination of factors that have made Scrimba very productive for very many people.

Kevin Tanzyl (15:44):
I think probably the phrase you're looking for is, "No pain, no gain."

Alex Booker (15:47):
Sure. Can I ask you about that? What were some examples of pain that led to gain when learning to code?

Kevin Tanzyl (15:54):
The pain was fixing really stubborn bugs in my project. It really forces you to look at your app from a more top-down view and you're like, "Okay, I need to really understand what is happening here. Why is this data not showing?" And as I said before, you have to trace where the data's coming from and really it also just forces you to use whatever tools at your disposal. At the time, ChatGPT wasn't around, so I think I was struggling with the Quizlet app. I just didn't know how to show all the quizzes and stuff properly. And eventually, I had the help of my developer friend, but of course I don't really want to bug him every single day about my project.

Alex Booker (16:37):
I feel that.

Kevin Tanzyl (16:38):
But anyways, yeah, the projects really get you into thinking like a programmer and more logically.

Alex Booker (16:44):
I actually noticed on your website, your portfolio, the Quizzical app is featured, as well as a couple of what look genuinely unique and fascinating apps. For example, one that draws my attention is your English flashcards app. Can you talk a little bit more about that?

Kevin Tanzyl (16:58):
That was actually one of my star apps that attracted some recruiters. Basically, while I was teaching with my Japanese English teacher, he usually makes all these English flashcards by hand. And at the time, our class had about 25 students. So what he would do is he would print about 100 cards with commonly used English words that we taught them throughout the year, and he would hand-print them and hand-cut them every time. And I'm like, "You know what? I think I learned enough React and learned enough JavaScript to design an app for that." And I told him, "Why don't I just try and make an app for that?" And he's like, "Okay, why not?"

(17:40):
So I started doing that project. I had quite a bit of downtime between classes, so I was pretty much programming on my school PC during that time. I think it took me two to three months to get a working app going. I did get some feedback from my teacher and then I made some changes. He told me, "Okay, yeah, we'll give it a go once the term is coming to a close and I just need the students to go over the English cards." And I heard from my friend, she said that, "Oh, he's using your app in the open schools." All these teachers would come and then he'll tell the kids to use the tablets and open up my app and I was like, "Oh my God, I feel so happy he's using it."

Alex Booker (18:19):
That's amazing.

Kevin Tanzyl (18:20):
Yeah.

Alex Booker (18:20):
How did it feel to see someone benefiting from the code that you wrote?

Kevin Tanzyl (18:24):
It felt fulfilling to see your project actually being used and people using it. It's like you make all these calculator apps and movie apps and stuff, it's like of course they're really great practice and stuff, but it's really hard to get people to use them. And second thing, it's also really difficult to come up with a nice unique idea. And that was such a great timing and opportunity to use my skills there because I feel like the problem with projects is coming up with the idea of the projects, right?

Alex Booker (18:54):
That's hard. It's really hard.

Kevin Tanzyl (18:55):
Yeah. And that's why I think another great tip I would give is just ask around, ask your friends, family, listen to what kind of problems they have and what kind of things they need and just offer them, "Hey, look, I can make this app for you if you're okay with that. You don't have to pay me," and stuff like that.

Alex Booker (19:13):
I've been thinking about that recently. I want to do more coding and I do a fair bit, but it's always to learn something or I don't know, it feels a bit contrived. Right now, for example, I'm building a kind of advanced chat application and I'm just curious about real-time code and it's interesting enough to me, but I can see it becoming more complex and then I get a chance to experience and work with a more complex code base as well. But realistically, I don't think anyone's ever going to use this chat application over a Slack or a WhatsApp or something. And at times, it kills my motivation. So I'm trying to look out for some projects that I would actually benefit from in the short term.

(19:51):
The only thing that comes to mind, and I totally understand why people do, is work on my portfolio because then I'm learning something I guess while I style out and code up the portfolio. And it will be genuinely useful as I get to tell more people about my skills and stuff and share a little bit and what I'm about. But then the portfolio is like, I don't know, it could look really nice, it could have some cute functionality. For example, I wanted to hook up my following count on Twitter to a label on the website, stuff like that, little bits of interactivity, but it's never going to be super integral. It's never going to be super valuable to anybody else but me.

(20:27):
And so I'm trying to figure out or try and keep a more open mind to problems I can solve with code because I'm remembering as I listen to you, and I think it's very useful for everyone listening as well, when you solve real problems with code, that's very motivating. You're much more likely to finish the project in the first place knowing that it's going to bring value to someone. It's totally unique, of course, as opposed to something based on a template or a tutorial. And I get the sneaky feeling that once you deliver something like that, you might be more likely to keep working on it as well because you see evidence that other people will actually benefit from the improvements and updates that you make.

Kevin Tanzyl (21:03):
It's kind of killing three birds in one stone, right?

Alex Booker (21:04):
Three birds with one stone! I can't wait to hear this.

Kevin Tanzyl (21:09):
Basically the first is like you're applying your skills and all that you've learned throughout your courses and stuff. And number two, you're helping the community and you're helping just your friends and family members with a real problem. And the third bird would be, again, it helps you with getting new experience with the whole programming coding process because whatever you go through with your personal projects and all the problems and the struggles that you go through it, it's times 10 when you go into the actual job.

Alex Booker (21:38):
I don't want to make this into four birds, that's going to feel like just too violent maybe, but I guess the other aspect, and this would be a great segue maybe into your experience getting into the industry is this is something that should really help you, I think, get noticed and give you something to talk through during your interview process.

(21:55):
What was your experience like? Did these projects you built for your portfolio help you get a job in a meaningful way?

Kevin Tanzyl (22:01):
Oh, yeah, absolutely because I try to apply for all the entry-level jobs. Unfortunately, all the jobs on LinkedIn, they're catered towards developers with at least three-plus years experience. I know the general advice online is saying, "Just give it a go. Just try it. Someone might give you a chance." And I did give it an honest go, and unfortunately, I didn't get any success with that, so I had to resort to trying for more entry-level listings here. But unfortunately, they're all mostly any Japanese speakers. I studied really hard with Japanese, so at least I got the communication done. It's just that my programming skills were not up there yet.

(22:43):
My first interview and my first company, the lead developer did ask for my GitHub. He just asked me to just show my projects and have a brief talk about it. And then my second job, it was a little bit interesting because I got into the interview and then I just told them about myself a little bit and they're like, "Okay. Well, show us what you got." And I was like, "Uh, is showing my GitHub okay?" And they're like, "Yeah." I was like, "Okay." And then so I screen shared and showed my projects. I showcased the English flashcard app and my other projects, and then they asked questions about it and then, "What did you do and why did you choose this?" And they asked me a few technical questions, "Do you know Flexbox?"

Alex Booker (23:20):
I saw in your LinkedIn profile that you got hired for the first time as a developer about 10 months ago at a company called Marvel, and that was a contract for six months before you went on to work full-time at a company called Bee2B as a developer. I was just wondering if you could take us through what was the story there in terms of getting that first role and then why did you change after six months?

Kevin Tanzyl (23:42):
My first job with Marvel, I thought I signed on as a front-end developer, and I was sure of it because they were asking for my projects and my GitHub. But then the first few months coming in, they assigned me to do really basic IT-related assignments, which had no relation to web development at all. And I thought maybe this is just the start and they're just trying to ease me into it. But after five, six months, I didn't see any signs at all of them actually putting me on any projects at all. They haven't even set me up for GitHub or anything. I was like, "Okay, I don't really want to just wait for them to assign me to a project," so I decided to start job hunting, and then that's when I found my current job.

Alex Booker (24:29):
This is the company where they asked you to show them what you've got and you shared your screen, is that right?

Kevin Tanzyl (24:30):
Yes. They work with React and Vue, but I think their main project is Vue. So when I came in and I was like, "Oh, I don't really know Vue, but I'm sure the concepts of a framework will carry across from React to Vue." Because I understood all the basic concepts with state and everything and how it renders and using templates and stuff. It's just that Vue is done differently, but that actually didn't deter me. I wasn't like, "Oh, no. Vue. I was learning React the whole time." It was nice. It was fun too, like, "Oh, I get to learn a new framework." And I got to say, I actually enjoy Vue more than React now.

Alex Booker (25:15):
That's a great attitude to have though, not being too fixed on a particular technology.

(25:19):
Just a couple of logistical questions, I suppose. Where did you find this job and how long did it take you to find it?

Kevin Tanzyl (25:26):
So this job I found through a website called Wantedly, and it's mostly a lot of smaller startups to medium-sized companies posting jobs there.

Alex Booker (25:37):
Is it specific to Japan or is it international?

Kevin Tanzyl (25:40):
Yeah, I think it's specific to just Japan. Unfortunately, it might not help being in America or something.

Alex Booker (25:45):
But there's equivalents, like Wellfound. It's great for Europe and America as well. It's still really interesting to know.

Kevin Tanzyl (25:51):
So yeah, I found my job through there and it took me about three weeks.

Alex Booker (25:56):
That was a great turnaround. What is it that you thought they wanted to see from a candidate that they got from you during the interview process that made you successful?

Kevin Tanzyl (26:05):
I think they just wanted to see the willingness to learn. They were very aware I'm still a very beginner, but I guess because I knew the basic concepts and they saw that I was really into programming, and I guess they saw that with the basic skills, that they thought that they could probably polish it and grow it within the company. That's what I feel that that's the reason why they hired me.

Alex Booker (26:28):
How do you prepare for the interview process?

Kevin Tanzyl (26:31):
I guess on top of just polishing my GitHub and just making everything look clean, I just looked up a bit basic interview tips and any good methods of tackling some of the difficult questions.

Alex Booker (26:43):
All right, well, Kevin, I'm looking forward to learn more, but first, how about we do a round of quick-fire questions to break up the interview?

Kevin Tanzyl (26:51):
Okay, let's do it.

Alex Booker (26:53):
Okay. The first question is what is one learning resource that has been the most impactful on your journey learning to code?

Kevin Tanzyl (27:00):
I would say Scrimba.

Alex Booker (27:01):
What is your favorite technology to use at the moment?

Kevin Tanzyl (27:04):
Right now, it's Vue.

Alex Booker (27:05):
What about a technology you would like to learn next?

Kevin Tanzyl (27:08):
I would definitely want to learn Ruby next.

Alex Booker (27:10):
What kind of music do you code to, by the way, Kevin?

Kevin Tanzyl (27:13):
I used to listen to lo-fi, but then recently I've started listening to classical, which is pretty nice.

Alex Booker (27:20):
Is there any kind of Japanese music that you listen to while coding that helps you lock in and get in the zone?

Kevin Tanzyl (27:25):
I noticed I'd listen to J-Pop, but I think I mostly just use classical nowadays.

Alex Booker (27:30):
Nice. I like that kind of music with no lyrics, whether it's lo-fi or classical, but helps you, helps you lock in.

(27:36):
Do you look up to or follow anyone in the tech community that we could maybe follow or check out after the show?

Kevin Tanzyl (27:41):
I think this is everyone's favorite, but Bob Ziroll.

Alex Booker (27:44):
Yes.

Kevin Tanzyl (27:45):
I do really like his React courses. Yeah, he's so great at explaining them. Another one I think that's not really mentioned is Fireship on YouTube.

Alex Booker (27:55):
Oh, I love that channel.

Kevin Tanzyl (27:57):
The very meme-y videos he makes and as well as the 100 seconds and stuff, it's totally a great learning resource.

Alex Booker (28:04):
Kevin, thank you so much for doing the quick-fire with me. Let's go back to the interview.

Kevin Tanzyl (28:07):
Okay.

Alex Booker (28:08):
I guess with this company, they mostly wanted to see your code when they asked you to show them what you've got, right? Did you have to do a sort of technical assessment as well as part of the interview process?

Kevin Tanzyl (28:18):
There's no LeetCode-style quizzes or Whiteboard quizzes. They just asked me technical questions like, "What do you do when you deal with a conflict as you merge your branches," and things like that and, "Do you know Flexbox and when to use Grid," and then, "do you know Bootstrap," and then, "what is state or something in React?" It's very, very basic coding questions.

Alex Booker (28:39):
That sounds to me like they felt great about the code and the projects you demonstrated. They just wanted to, I guess, verify that you could speak about everything coherently in line with the projects you'd been working on. It's such a good reason to have projects and the portfolio because in my opinion, that's one of the best ways to interview because you're not under the same pressure necessarily, and perhaps you get to reflect what is your real-world coding abilities, not just your interview coding abilities, but of course you can only be extended the options to interview in that way if you have significant projects to bring to the interview table.

(29:13):
So apart from helping you stand out with interesting projects, I think it is great to have them available so that interviewers can assess them and maybe even tailor their questions to things you've done because I don't think an interviewer is ever trying to really catch you out or trip you up with surprise questions or something. They would like you to be successful ideally by asking fair questions in line with your experience. Some of those questions might push your boundaries a little bit to find where the upper limits of your knowledge is, and frankly, some questions, the interviewer doesn't necessarily expect you to know. They want to see how you'll handle it if you don't know.

(29:49):
But again, just giving a blueprint of where you're at through sharing code for your projects, that's a great way to help the interviewer help you, I think, and a great testament for building a portfolio apart from getting noticed.

Kevin Tanzyl (30:00):
No, absolutely. Those are all really great points you made there.

(30:04):
I think one thing I want to add, I don't know if this will work in an English interview or in other countries, but the really good questions to ask is, "Judging from my skills and all the projects that I made, what are things that you think are lacking?" That was the question I asked, and the answer they gave me took me by surprise because he asked like, "Well, don't we all have things that we lack in our skills?" It's like, "Wow, that's something I don't hear every day," because I was expecting, "maybe your code needs to be cleaner," or, "maybe your project is not complicated enough," or, "maybe you need to learn how to do this." No, their answer was just like, "Yeah, we all lack something. We're not perfect developers, we're still learning every day." So I was like, "Yeah, wow. That's great."

Alex Booker (30:49):
That's really nice of them to share and probably a big green flag that they have these realistic expectations.

(30:55):
Can I share a different perspective on asking about gaps in your experience? I used to subscribe to the exact same view as you, but I learned over time, I think, that if the interviewer has concerns about your skill set, rather than calling them out directly, they're probably going to ask you questions, like technical questions or questions about your practical skills and experiences, that would give them confidence that that gap is not a concern to help them move forward with the hiring decision. That's their role in this, to ask you hard questions, and by hard I don't mean difficult. I mean tangible questions about your experience as it relates to the role.

(31:34):
And so I think when you ask point-blank if there are any gaps or concerns and things, I sometimes wonder what it accomplishes because they probably already have some in mind as they go through the process. I think what people, when they ask that question, they're often looking for some immediate feedback that they can hopefully address. So if the interviewer says, "Well, I've got this concern," then it's a good opportunity maybe to come in and explain why they don't need to worry about that. But it's never quite, in my opinion, as strong as addressing those concerns from the get-go by interviewing really strongly in a competitive interview.

(32:06):
That's my take, and then obviously during the stage of the interview, towards the end, you might then ask for feedback as to how to improve. I think that's really sincere and really productive.

Kevin Tanzyl (32:16):
I see. Yeah, no, that's actually a really good, interesting take because when I was looking around how to ask good questions in the interview, that question came up because the reasoning was that it shows that you are humble and it shows you are willing to learn and you're willing to take feedback from others and try to improve yourself. I'm guessing that's probably a cultural context, but I could be wrong though.

Alex Booker (32:40):
I think what you're saying is valid though, and if I'm honest, maybe I presented my view as quite definitive, but there is no science about this. It very much I think depends on the individuals and the kind of relationship and interaction you have with them, so it could be the right thing to do in the right situation. I really appreciate you sharing your perspective on that, Kevin.

Kevin Tanzyl (32:58):
No, that's great. Thank you for your opinion and perspective too. It's nothing set in stone. It's just like use whatever is necessary, I guess, for the situation.

Alex Booker (33:06):
Do you know what I've noticed about us, Kevin, is that we're both very polite? And I've also heard in Japan, the working culture is very formal and polite. Does that track in the real world?

Kevin Tanzyl (33:20):
Yeah. Formality is a very big thing here, which is why in the Japanese language, you have three levels of formality. I don't want to get into the nitty-gritty of that, but first impressions is the most important and how you convey yourself to clients is pretty much how the customer perceives your company. So it's a little bit different to, I'm not too sure about the UK or America, but in New Zealand, it's like you can also be formal, but at the same time, you can also be very friendly. But Japan is a bit different in case you have to be also a little bit rigid and strict with other clients, especially if it's bigger clients.

Alex Booker (34:00):
What is the working culture in Japan like compared to other parts of the world?

Kevin Tanzyl (34:05):
People work a lot. Overtime is very common, and it's odd to, not odd, but very rare to see companies that doesn't really prioritize overtime. With my company, the only time when you have to do overtime is when you have to release a product and you have to just try and get everything out before the due date, but usually people go home on time. But in general, if you work in other fields and other companies, normally you are expected to do overtime. So it's a case-by-case basis, but it is more common here compared to the Western countries.

Alex Booker (34:39):
Thank you for the insight into what it's like working in Japan. It's always really interesting to hear a take from another culture and country. And Kevin, thank you so much for taking the time to join me today as well. It's been a real pleasure learning more about your story and your advice on learning to code and how to break into tech.

Kevin Tanzyl (34:54):
Thank you. Thank you so much for having me here.

Jan Arsenovic (34:56):
That was the Scrimba Podcast, Episode 162. If you made it this far, please subscribe. You can find the show wherever you listen to podcasts, and there's a new one every week.

(35:08):
In the meantime, check out the show notes for resources, timestamps, and ways to connect with Kevin. The show is hosted by Alex Booker and produced by me. I'm Jan Arsenovic. Keep coding and we'll see you in the next one.