The Scrimba Podcast

Hussien Khayoon (00:00):
The first bootcamp person I saw, and I think she's a staff developer at GitHub now. She had an English major at University of Toronto, she did our bootcamp, and she was phenomenal, and that's when I first saw like, Wow, it doesn't matter. She was doing English and then she switched to programming. She's better than me.

Alex Booker (00:13):
Hello and welcome to the Scrimba Podcast. On this weekly show, I speak with successful developers about their advice on learning to code and how you can get your first junior developer job. I'm Alex, and today I'm joined by Hussien Khayoon, who is going to be your coding career mentor for the next 30 minutes or so.

(00:35):
Hussien has more than a decade of experience writing software. He's been a hiring manager and now a staff engineer at Shopify. Hussien is also a bootcamp mentor, helping students feel confident and giving them the advice to get their first coding job. When I say Hussien will be your coding career mentor today, I mean that unfortunately Hussien can't meet with everyone one-on-one, but he can join us here on the Scrimba Podcast where I've tried my best to ask questions that I think will help you.

(01:04):
I had a great time speaking to Hussien and I know you're going to love this episode. We were both so passionate about helping new developers like yourself, and I was really impressed by Hussien's thoughtful advice. Being a developer for a decade, he had some fantastic stories to tell. For example, the one time he started to interview at Facebook, and we'll get into about a little bit. All that to come and more on the Scrimba Podcast. Let's get into it.

Hussien Khayoon (01:29):
When I was in high school, I was kind of that kid that wanted to get high marks to get into university. I worked really hard. I was very good at math and physics kind of stuff, the sciences. So I got into engineering naturally from there. I went into electrical engineering. I just thought like, okay, it was whatever. Somebody I knew that I respected was doing it and they were doing well in their life, and I thought, hey, I'll do this. In my first year, there was a programming fundamentals course, and this was in the University of Toronto in Canada here. And this program, I didn't know, when they say a university program is the best, it just means it's hard for no reason. That's what I realized as well. Essentially, in that course, I was doing well in physics and math and stuff like that, but this course just stumped me. I didn't know the first thing about programming, I had never programmed anything in my life. And people were saying things like, hey, recursion this, four loops that, and I had no clue what was going on.

(02:23):
And the university, the way it works is you have so many courses and things are moving so fast, and if you just miss a week or two of catching up, you're going to be left behind. So that's exactly how I felt. I really struggled. And everything was on a terminal. These days a lot of times people will teach you JavaScript, a little HTML, CSS, and you kind of see things on a screen. This was very much terminal based, like C++, and there was pointers and all this stuff and I had no clue what was going on. So safe to say I struggled a lot. It was my worst mark that semester and [inaudible 00:02:52] getting a lot of help and I barely scraped by. And that, to me, it was like, okay, programming, I'm not good at this. I'm going to just do well on the other ones and hopefully balance things out. So that was my approach.

(03:02):
From there, in my second year when I had to take two more programming courses, I kind of had a shift of mentality based on books and stuff I was reading at the time and I thought, okay, there's no such thing as being bad at something, just you have to learn it properly. I spent all my life learning math and physics in school, but I just haven't learned this yet. So with that approach, I really buckled down and started learning this and got fairly good at it and by second year it was my highest mark, programming. It just kind of clicked. And I wasn't good yet, but I was better.

Alex Booker (03:30):
What kind of motivated you to get better at coding? Because you were kind of counseling on doing well on the other subjects. It didn't seem at the time you had a natural aptitude for it.

Hussien Khayoon (03:40):
I think that I was at the time reading a bunch of books and listening to stuff. And a lot of stuff, to be frank, was like Tony Robbins kind of material that was kind of like, you're not kind of born bad at something, you kind of learn to be good at it. And I kind of thought, oh, what if I learn how to play guitar, I would suck at it, but then if I just practiced a lot, I would get better. And got immersed in that kind of mentality and I thought, okay, this is just something I have to work on. And that was exactly it. I just had to spend more time learning it, and then eventually it paid off. And what's nice about programming is that a math problem, a physics problem, is kind of like you solve, it stumps you, and eventually look at the solutions. But programming, there's that euphoria when the program actually works and it does what you tell it to do. And that was the ultimate satisfaction. When you see the green check marks or just running the way it says, it passes all the test cases, and you're like, yes, I'm doing this.

Alex Booker (04:31):
That's so interesting to hear from you because I don't have much experience with things like maths and scientific problems. I just kind of assumed it would be a similar feeling, just that cracking a meaty problem. But now what I'm learning from you is that programming's quite unique in that way.

Hussien Khayoon (04:45):
Yeah. At least it felt to me. It's just because you don't have that unique experience of hands to keyboard, not knowing what's going on. And when you're a beginner, we get these problems every week and we go into this computer lab and it's serious, and you're like, I don't know if this is going to take me an hour or if this is going to take me 30 hours to solve. And you're kind of just working with your friends and you're kind of like, oh, but can't plagiarize. How much do I take from them? And everybody's trying to be cryptic to each other so that we don't get in trouble when you're talking to each other. Oh, try this, try that. And at the same time, the language itself is standing in your way. Again, C++ and pointers, you got to understand how that kind of works and you get segmentation faults and you're like, what is happening?

(05:26):
And at the time, you don't know the essentials when they teach you something, right? When I teach somebody to prepare for an interview, I say do small wins. Literally write a function name and say console dot log. Hello. Get that small win and then build on that. But what we would do is I'd try to write this entire program and press run and then it'd be a hundred lines and then who knows where the problem is. That unique feeling of having something on a screen and typing it in, I don't think you can match it with physics or math. Maybe out of lab, and I never enjoyed those labs and they're very expensive kind of labs where you have a very short amount of time, whereas on a computer, as long as you want to spend on that computer.

Alex Booker (06:02):
I can't believe that writing a hundred lines of code before pressing run. But at the same time, I can totally imagine myself doing it before learning this mentality of just focusing on small wins, incrementally building up the program, and then if you have a problem at least you can solve it where it happened. And it sends out a coding was something you've kind of enjoyed, right? You've gone on to work as a senior and then a staff developer, but your first exposure to it just wasn't that great. Do you think that the teachers failed you in that respect a little bit? Because clearly you were built for programming. Not that you were born a programmer by any means, but clearly it was something that connected with your intrinsic motivation around problem solving.

Hussien Khayoon (06:39):
The problem is the professors teaching this are very, very, very, very smart people. We can't touch them, the stuff that they know. They're geniuses in their field, especially at that university. Maybe there's this disconnect between teaching people things and them understanding it because they're just used to all these students coming in every year and they understand that just some people are going to get left behind. But learning how to learn in programming specifically, and learning how to learn is hard enough, but learning how to learn in programming is maybe something they can talk about or focus on because what I think is happening is if you don't have that mentality shift, a lot of people I knew just focus exclusively on electrical engineering or just quit out of the program and said, yeah, this programming stuff is killing me. I can't do this. I don't want to do this.

(07:19):
So they end up going in a different career path because they're kind of scared. And I don't blame them, because as a kid it's terrifying. You mask all of it in just university, you're cool, this, whatever, but secretly you're terrified those whole four years about what's going to happen after those four years. And the professors, maybe there's a disconnect there, but the university in itself, the system, is all about, hey, let's churn through as many people as we can and whoever makes it, makes it, whoever doesn't, doesn't. And you just either sink or swim. That's, I think, the university mentality, whereas I see it in Canada, in America they call them community colleges, in Canada we call them a college, which is a two year kind of program and maybe you don't get a degree. I looked at material there and I loved it way more. And I thought, hey, a lot of this makes sense and is very concentrated, and maybe I would come out a better developer from that two year program. But at the time, I guess, when I graduated 2013, still that stigma was being removed about having to have a degree in computer science or engineering. Things are changing a lot now, thankfully, but at that time that could have limited you. At the end, I don't think the professors, I don't want to blame them entirely, but the whole system itself is not geared towards helping a beginner.

Alex Booker (08:20):
You mentioned Tony Robbins. This is a kind of motivational speaker that sometimes people think is a bit too much, but I think one of the core points there is that you're not born of a fixed mindset. You can always grow, you can always learn, you're not born talented, hard work creates experience which then creates knowledge and utility and allows you to get jobs and change your position in life and all these things. I think the fact that so many people listen to motivational speakers and get so much value from it shows how so many of us think we have a fixed mindset or that our past defines what we'll do in the future. But equally, if you haven't been very successful academically before or maybe you try to subject coding and it didn't work for you, it's easy to assume that, oh, this just isn't for me.

(08:59):
But really what you need to do is find a way to relate to the material differently or find a sort of methodology or an avenue for learning such as a community college or a bootcamp that's going to work for you. But I think you probably agree with saying this is quite difficult to navigate at times because I feel like people get caught up in the prestige of it, even in society today, going to a community college or doing a bootcamp maybe. It is seen as a little bit less than going to school and getting a degree. And there's still this whole debate almost, we know we don't need computer science degrees to get jobs as developers, but there's still so many people who might say, well, you should get a degree anyway because that's something they can't take away from you. It will open up doors for you and all these things. How do you look at that?

Hussien Khayoon (09:42):
I think there was some validity to it at the time because obviously bootcamps weren't as popular. And now you hear a lot of people doing bootcamps and community college programs and getting somewhere. But before maybe that was kind of a thing where you see the job postings and it says you need a degree and they would be insistent on that no matter how much you knew. Now that things are changing, it's a lot better and we can all see as a programmer, your experience and what you build matters the most. Especially we're talking about web development. And let's be clear, there's all kinds of software development. That's cool things I learned in school, you could be coding operating systems, chips with digital, using [inaudible 00:10:19] log VHDL, graphics programming, embedded systems. There's a lot of programming out there. It's very, very hard.

(10:25):
But thankfully web development is the most popular one. To be honest, I think it's the least complex one in my opinion, in terms of complexity itself and being very smart. And that's what I love about with web development, you don't have to have that fundamentals of computer science in so long to be able to build stuff. That's kind of, in my opinion, what makes web development so cool is that you can focus completely on the front end and be a front end master. And maybe over time you develop those very core computer science skills. But the way computers are these days, don't think you need to be very close to the wire. You don't need to know what a register is and all this kind of assembly code kind of stuff. But in some areas you do. But thankfully the most popular thing I think that has jobs is web development and you don't need to know it.

(11:07):
So I think that mentality shift in people seeing what bootcamps are producing. The first bootcamp person I saw, and I think she's a staff developer at GitHub now, she had an English major, which at University of Toronto she did a bootcamp and she was phenomenal. And that's when I first saw, wow, it doesn't matter. She was doing English and then she switched to programming, she's better than me. You know what I mean? That was my first exposure. That was around 2015 where I saw, okay, bootcamps are series of business. Things are changing, thankfully. I know some big companies that are saying bootcamp grads welcome specifically, which I love

Alex Booker (11:38):
Hussien, and I will be right back. But first Jan, we have a favor to ask, don't we?

Jan Arsenovic (11:44):
That's right. The best way to support a podcast you like is to share it with someone. And if you share our podcast with someone, we will be really, really, really grateful. If you're enjoying this episode and getting value from it, why not share it with someone who might also get value from it? Be it on Discord, on Twitter, on Facebook, if anybody's still using it, or on LinkedIn, or maybe even in person. If you give us social proof, we will give you a new episode every week. One week we're interviewing an industry expert like Hussien, and another, a recently hired junior developer, so you get to learn from both sides. There's a new show every Tuesday evening and we haven't skipped a week for more than a year and a half. Whoa. So subscribe to the Scrimba podcast wherever you get your podcasts to make sure not to miss it. And now, back to the interview.

Alex Booker (12:40):
We talk about development, we talk about programming, and within the context of a lot of content online development, Twitter, podcasts, YouTube, oftentimes we are talking about web development, at least in this space. But development is so broad and there are so many different types of disciplines within programming. And actually you're absolutely right. Most companies, they need web developers to add features to their websites or apps and generate more profit, basically. It's a business at the end of the day. And there are of course other disciplines that are a bit more low level or inherently more complex or that would benefit from a computer science degree. But your point is absolutely spot on. We have to distinguish between these different types of disciplines because the advice is completely different depending on where you're focusing.

Hussien Khayoon (13:20):
A hundred percent. And the cool thing about learning them in university is you know about these and it's cool, but did I need to know about them? I don't know. There's still kind of that mentality of, I guess, people call it gatekeeping or whatever. I made a Twitter post. It was kind of just like I thought it would be funny, maybe provocative, I don't know. Years I've been a software developer, 10. Working as a software developer. Times that I've used big notation, zero. And I meant that in the context of work, but I kept this general, and obviously when you keep things like general and short on Twitter, people make assumptions. Which is funny and whatever. Whatever happens, happens. And man, some people were very upset and some people were like, you don't know what you're talking about. You are this. How do you not use big notation? Use big notation without thinking about it. And my point was kind of like maybe you use things but you don't need to know about them. The biggest example I give is database indexing. And just quickly about that, if you index queries...

Alex Booker (14:10):
Maybe define indexing for listeners who are a bit newer to coding.

Hussien Khayoon (14:13):
Of course, of course. With database indexing, when you're looking through things in a database, if you have millions of rows, maybe if you want to find something in particular and it's at the millionth row, maybe it's not a good idea to go through every single one of these rows until you reach the millionth one. Maybe there's an easier way you could do it. To give a good analogy that I've seen, if the thing you're looking for is on page 600 of a book, the easiest way to find it is to look at the index of the book and see, oh, this is what I'm looking for. It's at page 600. As opposed to going through every page and finding it. That's what database indexing is essentially. There's different ways of indexing something and some things will be 0 of 1, I think. And some things will be, I think, it's end log in depending on the query and some things will be 0 event. And don't quote me on this, but those are kind of situations where there is big notation being used.

(14:58):
But when I use it at work, I just say index as query, and it kind of just happens. So at the end of the day, you didn't need to know it. It's there behind the scenes. It's nice to know. And that's what I was kind of getting at. But some people were very upset. And I was surprised and it was interesting. Some people were like, how could you be a developer and not use big notation? You must be just a front end developer. You know what I mean? They're trying to cheapen what you do. And I found that very interesting and I thought a lot of people agreed, a lot of people didn't, so there is that kind of elitism in there because if you are, say for example, you're working at very big companies where they ask those and it's a requirement to get in, you're going to maybe justify yourself and say, mo, no, it is actually necessary, but I don't think it is. So those are just, I guess, maybe going a bit of a rant here, but that was a very peculiar case of maybe it's not about degrees per se, but it's about elitism and information.

Alex Booker (15:48):
I think there's two points that I want to touch on. The first is about Twitter and how it can easily be taken out of context in 280 characters. And the second thing is how I think for many developers it becomes part of their identity and they think they're doing a service by upholding the rigor of programmers and ensuring people use the correct terminology. No. Just get them with your life. Solve problems and do the thing, because what you're doing is actually gatekeeping and it's not helpful.

(16:14):
And I also wanted to touch, Hussien, on your point, because I think this is incredibly astute. Oftentimes you're using these fundamental ideas that might stem in computer science you might learn specifically during a computer science degree, you just don't necessarily know the words for the thing you're doing. But now that you've got some experience and some situational examples of where you might have solved different problems and used these underlying concepts, I'm sure you could learn the words for them very easily. And it reminds me a little bit of spoken language, and we'll just use English as an example. So if you grow up in a country where you speak English, you end up speaking very, very good English, reading perfect English, but you haven't got a clue about the semantics of the language or how the rules work necessarily. You just know it all based on experience, intuition, and all these things. And I think in a lot of cases with programming, it's kind of similar. That's kind of what you're saying I think.

Hussien Khayoon (17:02):
Yeah. That's so funny because I have a specific example on that. I spent a lot of my childhood moving back and forth from Canada to Syria, and it was kind of learning Arabic. My dad wanted us to learn Arabic culture and stuff like that. And I remember in school, in Syria, which is all Arabic and there'd be English class and I'd probably know more than the teacher, but the funny thing is I remember Syrian kids would be like they were constructing a sentence and they'd be like, okay, so why is it right to say it this way and not right to say it the other way? And I'd just be like, I don't know, but it just doesn't sound right. But actually a Syrian kid, I remember, they'd be like, no, well it's this rule and this rule. And I'm like, I don't even know what you're saying.

Alex Booker (17:38):
It's really interesting you mention that because I was born in England to English parents, but then when I was a baby almost, we moved to Wales where they teach you Welsh in school and I was in quite a low grade in English because I just couldn't focus and stuff like that. And meanwhile there were some Welsh kids who were in a better grade, a better set we call it in England, of English, and yet I knew that my English skills were better because I came from an English family and I spoke it all the time, but they were in the top set. And one time one of them came in and they just asked like, oh, have you a chair we borrow? Or something. And it was just the most broken English, and I remember thinking why on earth are they in set one but I'm in set three?

(18:13):
The trouble is a lot of the time with school and of many things in life, it's about sort of fitting a square peg in a round hole kind of thing. School just did not work for me for so many reasons. I know the traditional paths don't work. And I thought I was quite alone in that actually, and it was not a great feeling as a teenager thinking you're kind of stupid and stuff. But actually, as it happens, and one reason I'm so motivated to do the Scrimba podcast, is that there are so many people with non-traditional backgrounds or who maybe didn't quite fit the exact path they thought they were meant to take with enormous potential. And so I love doing this podcast because we get to bring it to the surface and talk about how to unlock that potential. But there are still situations like this in the modern coding world, and I'm thinking of job interviews in particular because we hear about companies, really fun story by the way, Hussien, just last week I spoke to a self-taught developer, they used Scrimba, and they got a job at Amazon. And to get the job at Amazon, they did a thousand leetcode challenges.

Khaidem Sandip Singha (19:07):
In order to produce positive motivation, I should say to my colleagues that I'm going to work in Amazon. I'm going to do it no matter what one day. What makes best developers, they're very consistent and they're very persistent. I have done 1000 leetcode challenges. I have to learn how to ask questions and keep on looking for answers. I had to understand what are the developers in big companies, they focus on the basics and they focus on problem solving.

Jan Arsenovic (19:35):
If you haven't heard this episode, I'm linking it in the show notes or you can look for it wherever you're listening to this right now.

Alex Booker (19:42):
And as you can imagine, during the Amazon interviews, they were asking lead codish type questions. And I actually remember, because I've been following you on a Twitter for a while, you spoke a little bit about how to get a job at Facebook, you have to almost learn their interview process specifically and the types of challenges they want, and only then can you be successful in the interview. You have to specifically practice to do it the Facebook way and then you get a job. And I get that a little bit. Maybe they have their reasons and all these things, but at the same time it does seem a bit strange, doesn't it, that you almost have to do this task which might not actually judge and measure your experience so much as your ability to just do it the way they want you to do it.

Hussien Khayoon (20:20):
Yeah, that was very interesting. I'm currently at Shopify, and before I found this job I did a lot of interviews. I did about a hundred hours of technical interviews total. So I was doing a lot. I probably spoke to 30 different companies and probably did maybe 20 first rounds and then did 11 onsites, which are five plus hours, and finally settled on a few offers and made my choice. But what was interesting was the big ones, the ones that I know asked leetcode questions, for example Facebook, I went to their panel which was kind of an introductory they have developers there who talk to you about how to prepare for the interview. And one of the phenomenal things I won't forget was each one of them had their story about how long they prepared, and it was months, weekends, nights, just preparing and studying leetcode.

(21:03):
And I'm thinking, hey, there is interview preparation. In interviews you kind of had to write code faster than you usually do, think on your feet kind of thing, and under a lot of pressure to perform. But then this was all about textbook kind of problems. And they're like, you have to do these and you have to do two of them in 40 minutes, 20 minutes each usually, and you have to come up with the optimal solution. You can't do something that works that's not the most optimal thing, and you can't run your code. You just have to write it and have to work and you can't run it and test it, this is how we do things. And this is the first tech screen. You haven't even done the main interviews yet. So I just found it, wow, what is this? And anyway, you think about it and you're like, okay, well they can do this because everybody wants to work there.

(21:42):
But at the same time, the nice thing was most companies didn't do this. Only the kind of really big ones that kind of have this kind of thing come up. And the cheat code I found out was I did an Uber interview, which I think they ask leetcode questions, but I did the front end one, and they don't. They were still hard questions but they were more suited towards your experience. If you have experience and you've built stuff, you can do them. I think Facebook has something similar, but if you're doing pure backend, you're going to have to do these. And man, I did a lot of leetcode questions and I went through the algorithms, but you can't learn that stuff. I gave myself a month and still I needed a lot more time, and I would just forget these algorithms as soon as I learned them. Breath first, search depth, first search, dynamic programming. I'm like, I don't know what this is. This is hard. This is school again. This sucks.

Alex Booker (22:26):
Yeah. Did they actually make you a better developer or did they make you a better leetcoder?

Hussien Khayoon (22:30):
Definitely they make you good at solving those kind of questions. They could make you a better developer if you kind of identify where you could use them. I think sometimes, I like the one Amazon problem, it's called a sliding window problem. It's like, well a lot of people are trying to book meetings in the same room and how do you kind of manage that? And that's a cool problem because that's actually maybe practical in that sense, although I would say you would not run into them that much. And a lot of times, there's libraries that abstract that and save you a lot of time, so you just end up using them. And some people do this stuff from scratch, it's just not most of us. There are programmers who are specifically very good at that and they will be doing this kind of low level stuff, but not most people.

Alex Booker (23:09):
I was recently researching a post on the Scrimba blog about intrinsic versus extrinsic motivation, and I kind of concluded for intrinsic motivation. It's so pure, it's so clean, it burns long enough for you to stand the test of time and become a successful developer. And intrinsic motivation, for people listening, is going to be quite simply for you just really enjoy coding, you find satisfaction in it. You like the possibility of mastering it, and you have your own internal drive and reason why you think learning code is something worthwhile. Maybe so you can work on problems you believe in. And then there are external factors which I think some people get into tech for, but they sometimes fail or they sometimes regret it because these weren't really their own internal drivers. They were things like, oh, I want a really high paying job. Not necessarily thinking it through. The fact they would have to do the job every day and hopefully enjoy it.

(23:54):
But also things like prestige. It can be quite cool to say you're a developer. It also unlocks opportunities to work at these big fan type companies. And I think when you're describing these kind of quite hardcore difficult questions, I get the vibe that on one hand they're testing your coding knowledge, but actually the reason they want you to do it their way so specifically is because they're kind of testing if you would be a good culture fit. Culture comes down to values and sharing values. They're almost like aerobics. They're just an exercise more than something pragmatic necessarily. Or you have the desire to work somewhere where everybody who's there has to prove that they are hardcore programmers and stuff. Maybe you really belong there. I'm just curious to know what you think. Do you think I'm onto something there? Do you think it's a little bit to do with testing if you would match the vibe inside the companies as well as their way of doing things? Or maybe it is just exclusively a coding challenge that they, for some reason, maybe unbeknownst to me, because I don't know what they're working on specifically, maybe it actually matters to their work.

Hussien Khayoon (24:55):
I think the conundrum with these kind of questions is the following. If you pass these questions, you are likely to be good on the job. It's not guaranteed, but it seems like people who do very well on them end up being a good fit for the job itself and can do things technically. The thing is, well, why should we look for another way where this way works? Even though we are conscious and we know there is somebody who's very good, and the biggest example is I think the creator of Home Brew had a tweet one time.

Alex Booker (25:22):
Yeah. I know that one.

Hussien Khayoon (25:23):
And they got rejected from Google because they couldn't do kind of whatever kind of question, but who doesn't use a Home Brew? I'd get that person in a second. You know that consciously it's like, okay, we're going to miss out on really great people, but whoever passes this seems to be doing well. Why not just stick to it? That's my opinion on why people particularly stay with this kind of thing. And other people are like, listen, we're not big enough to do this. We can't do this, or we think it's wrong. So either you think it's wrong or I don't think this is the best way to assess a candidate when they're on the job. Because here's interesting, as a staff developer now, here's what I realize. There are a lot of developers who come in that are brand new and they're way smarter than me. I could admit that.

(25:59):
And I tell them, you're way smarter than me. But the thing is, programming and just coding is half the job. When you're at a job, it's like coding meets business meets people. All those things have to combine. You're working on something that needs to make a profit, and people need to use it and they need to like it. And you're doing this in code. Whereas when you're learning yourself, you're just purely coding. But when you add those external factors, that's when things become complicated. Making a decision at a big company, should you have the screen like this? Well five million people, 100 million people might use this kind of thing. That's a big decision when you're going to do something like that. So how do you get alignment on that? Maybe what you're working with involves working with a different system in the same company, and now you have to talk to those people and understand their system and you have to know how to get in front of those people.

(26:45):
And maybe you have an idea yourself and you need to present that. How do you present it to people? How do you make sure work gets done on time? Maybe you're building something on the front end and there's some APIs that need to be adjusted. And if you don't adjust those APIs on time, then this feature won't ship. Who's managing all that? All these things surrounding the actual code you're writing take up sometimes more time than coding. That's the most important part that people forget about, and it's very hard to test that. And that's what experience gives you, and that's why a lot of times they have interviews about things like tell me about a system that you've built or that you're involved with that things went wrong. And then you tell them about all these scars you've built and they go like, oh, okay. This person has seen some stuff, they have this experience, and they know how things could go south, or things like that, and they can tell us about things ahead of time.

(27:30):
So essentially what I'm trying to say is you can be the greatest leetcoder of all time, but when software as a business with people using it comes to the forefront, and that is what development is at the end of the day, in my opinion, those skills can help you but they won't get you to the finish line. And that's when people who do bootcamps I see start to really shine. Because they're like, oh, I've worked with customer service before. I know how to talk to customers. I know how to manage stakeholders. I know how to do all this stuff. And that's when they really like, okay, this actually came in handy and it wasn't just about my technical skills. And that's when all the smart kids in computer science get left behind.

Alex Booker (28:03):
That's fascinating. So I guess there's two parts to that. There's career changers who maybe had a customer facing role before, they might not have much technical knowhow yet, but they've dealt with customers a lot. They've had to appreciate business goals and things like that, and they kind of know how things get done in the real world. But I guess a bootcamp itself is a highly collaborative experience, and coming in the gate you'll have some experience about how to collaborate on software, and maybe if it's a really good bootcamp, you might even work with a stakeholder or something. And that's the kind of experience that can help you shine compared to say a really technically brilliant but maybe not so socially tactical, I guess, computer science graduates.

Hussien Khayoon (28:40):
Exactly. And yeah, bootcamps, I don't think it's a perfect way of learning. I think one interesting thing I've seen is people who do compsci, I didn't know this, people did this, but they've finished a degree and they just don't have the confidence to apply for jobs, and they just take a bootcamp on top and spend all this money. And what was interesting is after all that, you end up having a great combination of skills, but honestly I don't recommend it because it's just so time consuming. And in fact I would try to tell those people, why are you doing a bootcamp? Just start applying for jobs. Trust me. And they're like, no, I'm not confident yet. I need to build projects. I'm like, okay, well, it's up to you but I just don't think you need to do it. Whereas a bootcamp can teach you a lot of those things, especially ones that are in person and you're building projects together and things like that.

(29:18):
And you'll get exposure. And you're working with people who are working in the industry, which is a huge thing. At Springboard for example, I meet with every student 30 minutes a week. And it's not just sometimes when I look at their code and we talk about what's going on, I give them a lot of examples of how things can be used at a company like writing test cases. Why you should write test cases when they build things in HTML. How people can interact with them. Accessibility. Things like that that are important when you start working but you don't know yet. And as a mentor, I try to make those connections between what you're working on and how it might be used. And I think bootcamps are very helpful for that. Traditional learning might not be as helpful. Although there are universities. Of course some of them are catching up and offering these kind of courses.

Alex Booker (30:00):
But your idea though of those sessions with the bootcamp students is you're kind of giving them confidence. You're like, hey, this thing you're doing, that could actually be used in a production code base more or less today.

Hussien Khayoon (30:08):
Yeah, exactly. Sometimes you'll get using something so long and you don't think about how a beginner might interpret it or know about it. So you tell them about, for example, using Git. Your life is going to be GitHub at companies. That's going to be a big part of your life. Committing things, merge conflicts, things like that. It's not just about saving your code and looking at the history. It's a whole kind of an ecosystem that you work within it. And when you're first learning, you're just learning Git, you're like, what is all this just to save my code? What is this old ancient system? But it's the backbone of all modern companies.

(30:40):
And not everybody uses Git obviously, but GitHub is very popular, and reviewing your polar request and your code and how everything's there, the history, they don't know, for example, I'll tell them like, hey, you look at a new code base, right now I'm working on something and I'll look at a new code base and I'll see somebody wrote this three years ago. Well I can look at their changes, I can look at their history, maybe that gives me access to tickets. I can look at context. And I can sometimes, those people, if they still work at the company, I can reach out to them. So those are things that Git can do, but when you're starting out, you don't make that connection. You don't understand that whole picture yet. And that's what I try to get them to.

Alex Booker (31:13):
If they think Git is old fashioned or something, they should try taking SVN or Mercurial or something for spend. That'll show them. Just to unwrap things a little bit, because we spoke about quite a few different topics and then I think we'll take things into another gear in just a second, but I think you're totally correct, by the way, this was a few minutes ago, but your sort of observation why companies do these quite intense imperfect coding challenges and the reason there's because they can afford to. They are sort of teasing some of the best compensation packages in the industry. And obviously then as a new developer you can look at that and make that your reference point and feel kind of crummy because you're not really there yet. But at the same time, the Facebook and... Well, sorry. Meta and Amazon and all these type of [inaudible 00:31:55] companies, they don't really represent the industry. They're just kind of in our peripheral because they're big and impressive.

(32:01):
And when people work there, we tend to recognize that. But there are thousands and thousands and thousands of companies and teams hiring developers. And for every sort of layer, if you keep peeling the budget back from the top budget to the next top budget and you get down to more typical budgets for engineering managers and teams have for developers, they actually are faced of a problem. They're like, we need developers but we can't afford to pay a huge amount of money. We're going to have to get creative and we're going to have to find some developers who might otherwise miss. And that's where perhaps they open the doors to these more accessible coding challenges, or maybe investing in the junior that doesn't yet have experience but shows a lot of potential. I'm not going to break it down in a huge amount of detail, but it's really inspiring, I think, to know that there are companies like that. And as a new developer, you have a lot more prospects than you might realize if you're only aligning yourself by some of the most popular and big companies.

Hussien Khayoon (32:52):
Yeah. And I can speak for Shopify and how the interview process is at Shopify, and for a developer, like a senior developer, we do pair programming, and this is all you find on their website, you do pair programming. We don't ask leetcode type questions. And your solution isn't the only thing we look at. We look at so many things surrounding you and would I like to work with this person? Also we do something called a technical deep dive which is explaining a previous project. So those are really cool ways that go around just asking pure can they solve this really, really hard problem. And at the same time, we have our internships, which is a way to get into full-time work. A lot of interns start off and they become full-time. And that's another way of getting in. And those, I've seen bootcamp grads come through that. You know what I mean?

(33:37):
And there's no gatekeeping there, and they end up moving up the ranks and things like that. So I think a lot of big companies are changing the way they do things, and I think in all the interviews I did, I think Shopify was very much it felt like I was doing things that I would do at work. On the interview, it was a faster pace, and that's the kind of problem again with interviews is that it's under pressure with somebody. And that just takes some practice. And what I tell people to do is don't let that be your first one. If you really want that job, don't let that be your first one that you do is the one that you want. Maybe do some other ones about companies maybe you would work there, maybe you would not be so disheartened if you didn't get the job, and that way get the ball rolling and learn how to work under pressure a little bit and get into the interview mindset.

Alex Booker (34:19):
That's such a top tip, honestly. Because if you are maybe feeling nervous about applying for jobs and interviewing, well now you have no stakes at all. Your only goal is to fail the interview so that you can learn what went wrong and what to do better, because you don't want to be learning all these things during the interview for the job that you really, really want.

Hussien Khayoon (34:38):
There are a lot of tips like that, and for example, I tell people talk, small wins, all this stuff, but nothing beats at the end of the day, you don't rise to the occasion, you sink to the level of your training. So no matter how good you think you are at solving these problems, some people are great leetcoders, but put another person they never met before and put the pressure of the interview and the time, and you see them crash. And that's normal because you're not used to that. You're not doing that day to day. I'm not opening my laptop when I start work and they're like, okay, timed question, somebody I don't know, go. It's not like that. Unfortunately, that's just how the interviews are, because it's really hard to interview a developer and figuring out the right kind of interview. Because you can do a take home.

(35:15):
But for example, I don't do take homes. They just take too long. I'd rather just sit through the pressure of five hours and know yes or no than to have to do a take home for ends up taking me 10 hours to get it perfect and then they could just be like, yeah, not really. I'm like, why? Why didn't it work? They'd be like, I can't tell you. Sorry. Bye. That's a lot of times what ends up happening with take homes in my opinion, so I just don't do take homes as a rule for me.

Alex Booker (35:37):
You want that face to face interaction because once you're there, they're going to tell you some feedback.

Hussien Khayoon (35:42):
And you know what, it saves me a lot of time. So in the time I did a take home, maybe I could do two onsite interviews, which are virtual these days.

Alex Booker (35:49):
I'm really enjoying this conversation because, I think like me, you think a lot about how to help new developers, but the way in which our day to day is different is that Scrimba is completely course based and a lot of our learning and communication happens asynchronously, but you get to work directly one on one with students at the bootcamp. And that leads me to have a question that I often wondered about, which is for all the advice that we've just spoken about, apply before you're ready, try and get your foot in the door so you can get feedback so that you can fail and then apply those learnings to the next, this is great advice, but what I've kind of realized is that this advice is only one part of the equation. The other part is emotional. It's actually having the confidence to do it and fighting your inner voice that might say intrusive thoughts like, oh, well if I apply to the job I don't want and I don't even get that one, but how am I going to get the job I really want?

(36:42):
And it's all about mindset and practice and confidence, and I think being inspired. Since you're talking to students one on one who might be struggling with this same thing, what are some of the things that you've seen that works with them that helps them get out of their own head and just move in the general direction of their goal, even though it might not be perfect, even though it might be difficult at first? What are some of the things? I'm just imagining, maybe there have been students who really struggled with this, but eventually they cracked it, and I just wonder what advice you might have shared with them or what patterns you could have identified that we can learn from.

Hussien Khayoon (37:12):
Sometimes they just need somebody who's gotten there to tell them that. I think that's a big first step. For example, at Springboard, there's two big capstone projects that you got to do, showcase projects. And I tell them, after you're done the first one, you can apply for jobs. And they'd be like, no, I have to finish the course. Then I tell them another thing. A lot of people have finished this course and still haven't found jobs. Think about that for a second. And some people have done it halfway and found jobs. But they need to hear that from me in order to kind of believe it and to start believing that this is possible. Yesterday I had a person I met with on that platform ADP list, which is great for just a free platform for meeting people in the industry, highly recommend it, ADP list.

(37:48):
And I met with a guy and it was kind of like he showed me a project that he was working on, and it was obviously not done yet, but I told him this is good enough to apply for jobs. And he's like, how? And I was like, okay, even though you haven't made everything work a hundred percent, there's enough here. There's like a login system, you can register as a user, you can do a search, you can add new records of a person. That's enough for me to see that you can do the fundamentals of this job. And one big thing that they don't realize is people think I need to get to the job on day one, I need to be producing at a high level. If you're a junior, that's not what we're expecting. I want to see potential. I could see that you can get there and you have the seeds for that.

(38:24):
You have the attitude and you have the right amount of skills. It's not just the attitude and things like that which are important. Also, I want to see you know some of the fundamentals, but a senior developer, no, on day one, I expect certain things that I don't expect from a junior developer. So don't worry. We're going to teach you. It's about getting you to that potential. And that's why a lot of times we hire somebody who's a beginner. And a lot of people don't realize that and they think, well, I'm just not ready because I don't know this, this and this and this. I haven't figured out promises in JavaScript. I'm like, you know how long it took me to figure out promises in JavaScript and how much companies I've probably paid me in salary until I figured them out and they just kind of clicked? And now I love promises and I love explaining them, but it took me a while. So it's okay. Those are the kind of things that I think people that I found struggle with.

Alex Booker (39:09):
Why is it that companies are okay hiring people who aren't perfect yet?

Hussien Khayoon (39:13):
For example, I worked at a couple of startups, and they just couldn't afford to hire somebody at that level. And other companies, when we've had budget, we've hired only senior developers. That has its own problems. Senior developers, a lot of them are divas, and it is very hard to please and they're very hard to manage sometimes. Not in that they're bad, but it's just if somebody's so smart, what's the next level for them? As a manager. I was a manager. How do you get them to reach that? Sometimes you can't. But with juniors, the path is clearer. And sometimes juniors make senior developers better because they push them, they ask them questions. You know what I mean? And you get less clashing. Sometimes senior developers in a room, you can't get anything done because they have such different opinions rooted in a lot of stuff that they just can't agree upon and they build animosity.

(39:55):
Where a junior developer was like, yeah, you want me to make a button? I'll do it. You want me to do this? I'll do it. That's what a junior developer can bring, and seeing them grow is the best thing ever. When you see a junior developer or intern kind of question you on stuff and figure out, when they'd be like, Hussien, what you said there was wrong because of this, I'll be like, yes. You're getting there. And that's the first step. And some of them think they figured out everything, and that's also kind of a funny thing. Sometimes you think you know everything after a year, which is interesting because I know there will be a downfall, but I let them experience that. And I'll be like, okay, you know everything, let's see. Go ahead and do it this way. And then they'll see and they'll be like, oh, crap, Hussien was right. And that's what my experience would bring, for example.

Alex Booker (40:34):
Senior developers have their own problems. I love that so much. It's so easy to assume that seniors would be better, but what you're describing is like an ecosystem where you need big fish, you need little fish, you need kale, you need to have everything in equilibrium, everything needs to be balanced. And junior developers, you're right, they bring so much energy to a team and they remind senior developers how far they've come. And when a senior developer teaches a junior developer, they're challenged to explain their own understanding and maybe that leads to them learning something new. Because when you teach, you learn twice and that kind of thing. Junior developers are awesome, man, and they're so valuable. And I guess, okay, in this dream world scenario, you might have a team of incredibly experienced developers, all kind of senior and beyond, who collaborate beautifully.

(41:18):
But let's be honest, every team has a hiring manager or some kind of leader at the helm. And yes, I'm sure they would love that too, but one, they probably can't afford it. And two, based on all kinds of restrictions like geography and all the rest of it, they're just not going to be able to make that happen. It's not about compromising to end up with something less good, it's about finding the value in other things and getting creative with how you structure the team. And I think as a junior developer, if you can showcase your technical ability, yes, but also all the things Hussien said about your communication skills and the way you get in the door and carry yourself and the collaborativeness you bring to the table, I think you have every chance of success. So, Hussien, that's all we really have time for today, but thank you so much for joining me on the podcast. Is there anything else you'd like to share in closing about advice for juniors or anything you're working on?

Hussien Khayoon (42:03):
The hardest thing as a junior developer is going to be getting that first job. But just know this one thing. There's three phases that you got to go through. The first phase is the learning phase, and that's going to be very hard. The second phase, which is just as hard, is getting that first job. And the third phase is keeping that job. So all different phases and all different things that you have to learn, but they all build on each other. So just keep in mind that those are the three things I think the phases that you just have to go through. And once you reach a year in your first job, things will dramatically change for you and your life will change. So just keep at it, and I think you could do a lot better. In terms of me, I'm on Twitter, you can find me there. And I started a YouTube channel a while back. I'm working on a couple of courses. But if you want to just know more about me and kind of my thought process, that's kind of like where you can find me. And happy to be on this podcast, Alex. Thanks so much. And yeah, this was really fun.

Jan Arsenovic (42:54):
That was Hussien Khayoon. Make sure to check out the show notes for all the ways you can connect with him and also a lot of good resources. For example, he has a course, but he also has a free report with four tips to get your first coding job faster. Again, we're linking all of this in the show notes. If you've reached this point in the podcast, you can also subscribe. We have a new show every Tuesday evening. And if you're feeling extra supportive today, we would also really appreciate if you left us a review on Spotify or Apple Podcasts or wherever you're listening to this. If there's an option to leave a rating, please do so. It really helps. We are pretty much a two person team and we love being able to bring you a new insightful and uplifting episode every week. So thank you for your support. The podcast is hosted by Alex Booker out of London. You can find his Twitter handle in the show notes, and I'm your mildly nomadic producer Jan, currently recording this in Belgrade, Serbia. Where are you listening from? Mention this on Twitter and let us know. And don't forget to write what have you learned from the podcast. Until then, we will see you next week.