[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron. And today, we’re talking about technical interviews with Farhana Mustafa, Software Engineer at Intuit.

[00:00:19] FM: I just felt myself getting hot and very emotional and I just told the interviewer like, “Hey, I can’t do this anymore. I would like to stop.”

[00:00:29] SY: Farhana talks about the importance of having a support system of other learners when getting your computer science degree, her process for applying for jobs, and what she learned from failing technical interviews after this.

[MUSIC BREAK]

[AD]

[00:00:51] Hey codenewbies, are you ready to take your skillset to the next level? Maybe you want to learn SQL or interested in building a new app. Sometimes taking that next step can be intimidating, but we have good news for you. Cockroach university is a free online learning platform that teaches you the core concepts behind SQL databases and how to build a sample application there's quizzes, tutorials, and prizes along the way.

Get started for free today@cockroachlabs.com slash COVID. Twilio quest is a desktop role-playing game for Mac, windows, and Linux. To teach you real world developer skills. Take up the tools of software development. Become an operator. Save the cloud, download and play Twilio quest for free at twilio.com/score.

Career karma helps code newbies with free career coaching and a community of peers and mentors. To help you learn to code and find a high paying job in tech in less than a year. Download the clear karma app and get started in live audio rooms, hosted by bootcamp grads who landed coveted jobs in tech like Netflix, Tesla, Twitter, and YouTube.

Be one of the over 300,000 people they've helped get started. Visit careerkarma.com/

[AD ENDS]

[00:01:50] SY: Thanks so much for being here.

[00:01:52] FM: Thanks for having me.

[00:01:53] SY: So Farhana, you pretty recently wrote a really, really great DEV piece called, “What I learned from failing my technical interviews.” And I think the idea of technical interviews is just really scary for those of us who are new to coding. So I’m really excited to dig into all of this. But before we do that, please tell me about your coding journey. How’d you get into this?

[00:02:14] FM: So my first programming experience started in 12th grade where my school offered AP Computer Science. I was fortunate enough to actually attend a school that offered AP Computer Science courses or any AP courses at all. A lot of high schools back then didn’t offer these courses. So the class structure was a little strange. Ninety percent of your grade was attendance. So naturally students just didn’t care, didn’t show up and played games on the computer. So there were a handful of students, including myself, that focused on passing the exam. And I was so infatuated with computer science that I declared it as my major when I accepted my university offer. And basically the exam was coming slowly and I spent all of my lunch studying, and I even spent my time after school to study, ask questions to my teacher, and I took the exam and I had to wait like a month to get my grade back. So the grade structure was one being the lowest, five being the highest, if you pass. And I got my grade and I saw a big, fat one on the test results.

[00:03:32] SY: Oh, no!

[00:03:36] FM: So I was devastated and I was just thinking like, “How am I going to major in this? I didn’t know what to do.” So fast forward to college, very tough four years of my undergrad life, but I made it through. I continued to stick with computer science and graduated with my bachelor’s degree and got my first career at Kaiser Permanente, where I participated in a rotational program, basically for two and a half years, I changed teams and projects working on different technologies. And after that, I joined Intuit to become a software engineer working on iOS development.

[00:04:18] SY: Nice! So tell me more about how failing that exam affected your college career. Did it make you apprehensive that it impacted in some way?

[00:04:31] FM: I was definitely scared to go into it and I had some doubts to continue with the major. I had to basically retake that course in college. It was like an intro to Java course. And I think like the second time around, it helped, like I already had some experience in it. I also met an amazing group of people that were in the same major and were struggling just like me and we just stuck it together. We always like met up in different classes or study rooms on campus and just work together on our projects and brainstorm together. And that was a great support system that I had that helped me stick with the major and graduate in the end.

[00:05:19] SY: So what was it about coding that you liked so much? You said even before you took that AP class, you were really excited about coding and you really wanted to do it. What got you so interested at the beginning?

[00:05:30] FM: I heard a rumor that computer science was like math, and I absolutely loved math. So that definitely made it more appealing to me. And back in like the dial up days, I just couldn’t stay away from my computer, even when like my mother would scream at me, like, “Get off the internet. I have to use the phone.” So the combination with math helped me pursue this as a career path.

[00:05:57] SY: So what was it like getting your CS degree?

[00:05:59] FM: Oh my goodness! It was so tough. I think I wouldn’t do it again. I think it was a lot of self-study. The professors would speak about one thing, but then the test we’re testing out something totally different.

[00:06:20] SY: That’s frustrating.

[00:06:21] FM: Yeah. I was like, “What?” Yeah. The support system that I found definitely helped a lot. If I didn’t have a support system, I think I would have changed majors.

[00:06:33] SY: Tell me a little bit about what some of those courses were like, especially for those of us who have not taken computer science in college. I’m curious to hear, what was it like? Was it a lecture with slides or are they coding in front of you? What did it look like?

[00:06:48] FM: I would say like the core classes, core meaning like expected things, like data structures, algorithms, operating systems, computer architecture, those were tough. And that composed of the teacher with slides and then sometimes they will pull up some code examples within the slides. And then there were a lot of homework assignments just bombarded at the students mixed in with a lot of quizzes and exams just immediately. So time management was definitely something that each student had to conquer as well as computer science. And then there were tech electives for your last two years where you got to choose specific courses that you wanted to take. The structures and algorithms were mandatory, but not computer graphics or iOS development. And those are two courses that I was really interested in taking. So I have to take those. Other students were able to take cybersecurity, social media mining, basically like taking the Twitter API and like doing things with it, with a Python.

[00:08:06] SY: So tell me more about the support system you mentioned. And support is such a huge part of learning, anything that’s difficult. It’s the reason why we started CodeNewbie is to help support people. So what did your support system look like?

[00:08:19] FM: It was a small group of other New York City kids that I’ve ever met before that all have taken computer science. Each one of them was a person of color. And I felt that that helped us connect more, I guess. We’re more familiar with our backgrounds and our journey into computer science and we basically helped each other with tough coding problems or homework or assignments. We explained each concept of data structures that one person wouldn’t get, but the other person understood more. So we would go to the whiteboard and draw it out, explain to each other what was happening. We even shared our technical interviewing experience with each other. So when we interviewed with companies, especially when it was about time to get a full-time job, we told each other what these companies asked us and what coding questions should we get. If we didn’t understand the coding question during the interview, we all did it together and shared our thought process about it. It was a very great support system.

[00:09:33] SY: So tell me more about the first job you landed. What kind of work did you do?

[00:09:38] FM: I moved across the country to California with no relocation at all. I just needed some type of experience. And I was placed in a cohort of other new grads. Basically I found a new community of technologists where we all had the same question in life, I guess, where we didn’t know what to do in tech, but we wanted to be in tech. So that was the purpose of the rotational program is to rotate and be on different teams and find what we like. So the first one I did was about cloud computing. And I didn’t touch much about cloud, but I helped them make a user interface, a website in Angular. And that was scary at first to me because I didn’t want to code. I think it was probably PTSD from undergrad, honestly, but I was given guidance from the senior engineers on how to make this website in Angular. And I ended up really liking it. Then the next rotation I did was more of a proof of concept, meaning like take an idea and make it come to life with code, but it doesn’t reach the public. So this was basically chatbots using Google Dialogflow where I made a chatbot that contained medical information or the Google Assistant and Amazon Alexa. And I also worked on virtual reality development.

[00:11:14] SY: Wow!

[00:11:15] FM: Yeah. That was also a proof of concept work where I got to research and develop use cases to use virtual reality in the health space. And I spoke to a lot of doctors and some patients where I got their feedback on how would they use or what would they expect from VR to help them with their medical needs. And my last rotation was with iOS development that won my heart in the end. I got to make a video conferencing application that was for internal use where basically doctors within the company network can video chat each other on a secure network, as well as send video links to their patients and their families.

[00:12:06] SY: So you are now at Intuit working as a software engineer. Looking back on your experience all the way from 12th grade through going to college and studying computer science officially in school was all that worth it, considering how difficult it was and how hard it was? Was it kind of worth it to go through that process to be where you are today? Did you feel like you needed it?

[00:12:31] FM: Yeah, I definitely say it was worth it. I’m happy to be where I am right now. I feel that I’ve grown a lot. And just like the blog posts that I’ve written about what I learned from failing, I feel that I can continue doing that, continue documenting everything that I learned and experienced for others to learn from as well. And I’m excited to keep on growing and learning honestly. And I feel if I become too comfortable in my career, I might not be satisfied with it. So the constant growth that I felt and the constant difficulties from tech makes me a better engineer in the end.

[MUSIC BREAK]

[AD]

[00:13:37] Explore the mysteries of the Python temple, the OSS Elfa pant and the flame of opensource all. While learning the tools, uh, software development with Twilio quest become an operator. Save the cloud, download and play Twilio quest for free at twilio.com/quest. Career karma helps code newbies with free career coaching and a community of peers and mentors.

To help you learn to code and find a high paying job. In less than a year, download the clear karma app and get started in live audio rooms, hosted by bootcamp grads who landed coveted jobs in tech like Netflix, Tesla, Twitter, and YouTube. Be one of the over 300,000 people they've helped get started.

Visit careerkarma.com.

[AD ENDS]

[00:14:06] SY: So now let’s get into applying to jobs and technical interviews. Tell me about the process of applying for jobs. How many did you end up applying to before you’re able to land on your first one?

[00:14:18] FM: Yeah. So I had a Google Sheet where I recorded all the company names along with their positions, locations as well, and the app link where I just constantly filled it out, and that ended up being over 200 during my senior year of college.

[00:14:34] SY: Wow!

[00:14:37] FM: And I also recorded down like who actually got back to me, who rejected me, who gave me an opportunity for a phone screen, and that was definitely maybe around 20. So that was a learning experience where I realized, “Okay, stop sending all your applications to like a black hole.” So I felt that a majority of my interviews were through a recruiter or through a conference. I ended up taking about 15 coding interviews since I graduated. And all of those were through a recruiter, either from LinkedIn or through a conference.

[00:15:20] SY: What do you make of that?

[00:15:22] FM: I mean, honestly, it feels like no one’s checking the websites that people apply to and send their resume in. I wish that this was more known, I guess, like everyone just says, “Apply on the website.” And you do, but then you get nothing in return or not even like a follow-up email, like, “Hey! You’re not right for this role,” or anything like that. So it’s from that experience that helps me realize if I want a new role, I would need to ask someone in my network that I know is at that company or is doing something similar that I’m looking for or just go on LinkedIn, reach out to some recruiter and even take all the messages I get from recruiters that ask for a phone call to tell me about their opportunities that they have.

[00:16:13] SY: So now I want to talk about the subject of your DEV piece, Technical Interviews. Tell me what a technical interview is?

[00:16:20] FM: A technical interview is basically a multi-step process where each interview could vary. One could have five rounds of coding interviews or a different company, like let’s say a startup, can give you a take-home challenge where you build something with their specified requirements in a tech stack. So if you’re going for a web role and you want to focus on React as your framework, usually your take-home challenge could be, “Make this website consuming this API in React with this specific design.” So for companies like a FAANG company, FAANG being an acronym for Facebook, Amazon, Apple, Netflix, and Google, you will get asked tough coding questions where you’re expected to use a data structure to solve the problem that they give you and then you were expected to explain through your code your thought process and how can you make your code better. Meaning, how do you use less memory or how do you make it faster?

[00:17:35] SY: So tell me more about some examples of things that you had to do for the technical portion of the interview.

[00:17:42] FM: So during an interview, I had to first ask clarifying questions to the interviewer to make sure I understood the problem, and they’ll make any assumptions. If you do try to assume something, first, ask your interviewer and they usually give you the okay to assume or they tell you a specified detail like the maximum amount of your inputs or minimum amount. I also try to tend to think through the edge cases. If I’m asked to write a function with an input of a number, I try to think if I’m given an input that’s not a number like an empty string or a Boolean. I tend to write that in comments so I don’t forget my edge cases. And then I think out loud, everything that is going through my head, because if you’re silent and typing away, it’s very awkward for your interviewer because they don’t know what you’re doing. So if I’m given some examples of what is correct input and what would be the correct output, I would work with those first where I would try to solve the coding problem to get that exact output with the input. If I do get stuck on a part, I do say that out loud. I tell the interviewer what issue I am running into and I think of a possible solution or multiple possible solutions that I could take. And if they don’t say anything, I do ask, “Hey, what do you think about this approach?” And really depends on your interviewer. Some interviewers could be having a bad day or they could be having a great day. Really depends. Majority of the time, they will give their input as well where they think you are taking the right approach. But if you’re not, they could hint on what is a better way to solve the problem.

[00:19:46] SY: So you apply to 200 places and you interviewed at a bunch of them. What were the differences between the kinds of technical interviews you go on when you’re comparing big companies with smaller companies and anything in between?

[00:20:00] FM: Yeah. So the big companies definitely have a more reputable interview process, I guess, where you would find a lot of example questions online on maybe Glassdoor or LeetCode where people who have interviewed at these big tech companies like Amazon and Google, they shared their experiences. And it would be a question where you’re expected to use a data structure, and you don’t know which data structure at first. It could be a graph. It could be a dictionary, a linked list. If you want a tech job in a big tech company, you should have brushed on your skills for every single data structure because you don’t know which one could be asked about. I’ve also done front-end interviews with companies that asked me specific front-end questions, like, “What is Ajax?” And the difference between padding and margin when you work with CSS. I’ve also done interviews with some companies that wanted me to do a take-home project. And that I felt was a bit better, one was from Deloitte, where they were looking for an iOS developer and they gave me a take-home challenge that was make an iOS application to display data from this Google Books API.

[00:21:35] SY: So one of the big complaints about technical interviews is that so often they don’t reflect the actual job that you’re doing. They’re talking about, as you mentioned, data structures and kind of get in the weeds of things that you don’t actually need to know for the job. Was that your experience or did you feel like the interviews you had reflected the job you ended up doing?

[00:21:57] FM: I have not experienced a linked list in my everyday job. I also haven’t really worked with much data structures, honestly, in my front-end roles. I just parse through an API that’s basically a JSON or I always use an array to store some variables locally and parse through that as well. I don’t know. Maybe one day I’ll use a graph at work.

[00:22:24] SY: So was it hard for you, those technical interviews?

[00:22:27] FM: Definitely. At first, yes. When I first started doing it, I didn’t know what I was doing. I would get so nervous trying to solve this problem in front of another person or even multiple people. And sometimes my mind would just go blank about the problem and it was frustrating and a little bit embarrassing, but it was something that I needed to conquer and I needed to keep practicing where I could become more experienced at interviewing to get the role that I deserve.

[00:23:03] SY: So why do you think technical interviews are so difficult really for anyone, but particularly for early career developers?

[00:23:11] FM: I want to say it’s because of the lack of experience. The tech interview process, I believe, has improved a bit over the years. I heard that companies like Google used to be a brain-teaser, like how many golf balls can fit into an airplane, and that’s not practical at all. So I think with more feedback from the interviewees is helping these companies a bit more on honing their process. But I think it’s going to start off hard before it gets easier for anyone interviewing for anything.

[00:23:52] SY: That’s very true. Yeah, I think it’s not just a tech thing. I think that in any job, those first interviews are pretty tough, but hopefully it gets easier. Coming up next, Farhana talks about what different companies’ technical interviews were like, and what she learned from those experiences after this.

[MUSIC BREAK]

[AD]

[00:24:30] Hey codenewbies. Did you know that all apps need databases? Take a look at your phone and see what apps you have. Instagram door dash, Venmo, Lyft. They all use databases, databases make up the software layer that power our apps and most databases you sequel for writing and querying data. So once you master coding, you're going to want to start to consider the tools you need to create your app, including the data.

The expert, the couple flaps, the company behind the leading database solution. Cockroach DB offer free courses for all skill levels taught by in-house experts. You'll learn about SQL databases and building applications with quizzes, tutorials, and prizes along the way. Visit  dot com slash  to take your coding skills to the next level and get one step closer to becoming a software developer.

[AD ENDS]

[00:25:23] SY: So in your article, you listed some of the companies and what you learned from failing their technical interviews. So I’d love to just kind of go through a couple of them. So the first one was IBM and you were applying for a front-end developer role. Tell me more about how that went.

[00:25:37] FM: That was basically a coding challenge sent to me through some program that they had, let’s say, HackerRank. I didn’t speak to anyone human. It was like an automated challenge sent to me. There were some coding problems that I had to finish and then click submit. The question that I remember was very similar to FizzBuzz. And what FizzBuzz is, it’s a popular question that’s online where you are told to print the word “fizz”. You’re given an input as a number and you’re supposed to print out from zero to the number you’re given, print out the number if it’s not divisible by three. If it is divisible by three, print out “fizz”. If a number is divisible by five, print out “buzz”. If it’s divisible by both three and five, that you’re going to print out the word “FizzBuzz.” So I think I didn’t understand the problem when I was doing the coding challenge and I had no one to ask the question to because it was just a website with this challenge. So I tried my best at solving it and I knew I didn’t get anything right. Because when you click test your code, it runs through all of the potential test cases, and I didn’t get any of them right. But I needed to go to my next class. So I just clicked submit and went on with my day.

[00:27:17] SY: And what about Google? You interviewed for the engineering residency program. Tell us about that.

[00:27:22] FM: Yeah. So that one, I received a text screen, basically a phone call from the recruiter who asked me about myself, what I was doing in school. Then we scheduled the first round interview that was composed of two coding questions from two different interviewers. And they called me on my phone and sent me a Google Doc where they were able to see what I was typing. For the first one, I received a question that was like parsing through a string to do something with it. I apologize. I don’t remember much about that. And immediately I dove into trying to solve the question and that was my first mistake. I didn’t understand the question. How can I solve it if I didn’t understand it? Then I realized, “Wait, what happens if I have this string as my input? What would be the output?” And I didn’t understand what the output would be. And the interviewer tried to explain like, “No, if this is your input, then the output would be this.” And then I just dove in again. And then I got confused when I realized there was a different input that I didn’t know what the output would be. So I kept pausing, I guess, and asking for the interviewer to clarify. And I just felt myself getting hot and very emotional and I just told her interviewer, like, “Hey, I can’t do this anymore. I would like to stop.” And the interviewer just sounded very sympathetic. He tried one more time to explain how to get this output from this input. And I just said, “No, it’s okay. I would like to stop.”

[00:29:09] SY: Wow!

[00:29:09] FM: And he hung up and I just felt so defeated and just couldn’t code. Yeah. And then I had the second interviewer calling me. I turned off my phone because I didn’t want to deal with it. I do feel guilty to this day about it and I do feel that I have grown.

[00:29:30] SY: Tell me more about how you handled that feeling of defeat. What did you do about it?

[00:29:34] FM: I definitely took a break from applying. I let myself grieve. So I just took some time to spend time with loved ones. I did whatever it was that I enjoyed that wasn’t coding or tech related. And I basically went to my friends. They were very nice about it. They told me it was all right. You’re going to get the next one. So I didn’t let it get to me basically. I let myself rest for a bit and then I bounced back.

[00:30:10] SY: So next, you talked about Microsoft and interviewing for a software development engineer there. Tell us about that one.

[00:30:17] FM: Yeah. So I did Microsoft twice. That was through the Grace Hopper Conference. I was contacted through a recruiter who found my resume on the GHC resume database. And the first one, I did a first round interview and this was in-person and I was not told to code on a computer, but I was told to code on a piece of paper with the interviewer sitting in directly in front of me. And I was given a tree question. I think it was about how to insert a value into a binary search tree. And I did not know what a binary search tree was. I didn’t study as much as I should have before that interview. I just assumed he would give me a simple string question or simple array question. So that threw me off. So I was sitting there stuck and he tried to explain what a tree was to me. And yeah, I did not pass that first interview. So I think they have a cool down period where you can’t interview again after maybe a year. So the next year I was contacted again through this conference to interview and I passed a first round interview and that made me really happy. I practiced more during that year. I went on leetcode.com, practiced heavily on that website just to get myself more acquainted with programming questions and data structures. And I got to the second interview, which was their finance review at the time. It consisted of two back-to-back interviews with two different people. The first one, he asked me about my resume and my projects, and I was very confident in that part. I was able to talk about my past projects and my past experiences with the role that I had at the time. And he threw a curve ball at me with a system design question. And that was basically design how an error is shown on your website. And I was stumped because I didn’t expect system design for early career.

[00:32:51] SY: Yeah. That’s a pretty big question.

[00:32:54] FM: So I was like, “You have this interface and you make some API call to something and something else happens.” I just didn’t know how to answer it, but I tried. I kept trying to BS my way through this system design question, and I guess I just sounded like a fumbling mess because I didn’t have a concrete answer. And when it was time to ask him questions, I asked him immediately because I wanted immediate feedback instead of waiting, what was something that stood out to him that I can improve on? And he told me that I should have said, “I don’t know,” when he gave me that system design question, and I definitely took that advice and applied it to my future interviews and even like in my current work workplace where if someone asks me a question, I do say, “I don’t know, but I could find out.”

[00:33:49] SY: Right.

[00:33:49] FM: Or, “I could figure it out.”

[00:33:51] SY: And the last one, Facebook. Tell me about that one, full stack engineer was the role. Tell me what that experience was like.

[00:34:00] FM: Yeah. So that was during the lovely year of 2020. I was applying to multiple companies for a new role and finally got something back from some company. And I did the phone screen with Facebook and after that was the first coding interview where I was on a call with the engineer and they sent me a CoderPad link where they were able to see what I was typing. And that one, there was a table written in the comments. And the question was to write a function, to calculate your tax rate with your salary and a tax bracket as your inputs. And in the comments, there was a table. And one column had the tax percentages like 10%, 15% and other columns had salary ranges. So from $0 to $10,000 and then $10,000 to maybe $20,000, et cetera. That first trip me up where he didn’t give me the data structure at all. It was just like a table written in the comments. And I asked my clarifying questions, like, “Can I use a dictionary as my input for the tax percentages and salary?” And he gave me the okay to do that. And then I talked about my edge cases, like default to 10% tax rate, if you’re making less than $10,000. And I asked what was a maximum salary that I could work with. And he told me infinity, I believe. It could be any number. I could be given any percentages for any salaries. So that also tripped me up a bit. So I decided to only work with the example he’d given me, just like a work on that to make a working solution. And I started coding in I believe I was using JavaScript at the time. I started writing the function and then I realized I was doing the math wrong because I made the solution, but it wasn’t given the correct output. And I realized that I didn’t understand taxes.

[00:36:19] SY: Oh!

[00:36:19] FM: So he has to stop and explain taxes to me. And then the first round interview was only supposed to be for 45 minutes and we ended up taking the whole time talking about taxes and I did have a solution, but it wasn’t the correct solution.

[00:36:39] SY: So if we think about all those interviews together, what were some of the biggest tips and next steps, action items that you walked away with?

[00:36:49] FM: I definitely learned how to approach, how to talk my way through a coding problem, where you first clarify that you understand the problem, then you ask your clarifying questions and try to get any assumptions out of the way and make sure you understand every single detail given to you and how to utilize it. Then I learned if they don’t give me an example, I would ask for one, like, let’s say, if I’m given this specific number, would the output be like this? And then they could confirm with me that I’m on the right track. I’ve also learned to get comfortable with the programming language that I was using. I switched from Java to JavaScript and then now I’m using Swift. So I had to learn to be very comfortable with using that language where I know the syntax and the built-in functions of it that could help me during an interview. I made sure to always say everything out loud, any single doubt I had or multiple approaches that I had in my head to communicate what was going through my head. And if I had any more doubts, I would ask for some help from the interviewer because they are there to help you and understand how you’re thinking and they hopefully shouldn’t be not engaged, I guess, like they should be able to give you a hint or two if you’re stuck.

[00:38:28] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Farhana, are you ready to fill in the blanks?

[00:38:35] FM: Yes. I am.

[00:38:36] SY: Number one, worst advice I’ve ever received is?

[00:38:39] FM: That I should switch my major if I didn’t understand the material. So a bit of context for that one, it was my freshman year of college and I was taking a course that was focused on Haskell, a functional programming language. And I was having trouble understanding a homework problem that I had to do. So I went to the TA’s office hours, a TA being a teaching assistant, and I asked for help on this homework problem. And the TA was explaining to me, but I guess I didn’t understand the homework problems still. And then he told me that if I can’t understand the stuff, then I shouldn’t be in computers.

[00:39:24] SY: Ooh! That’s tough.

[00:39:25] FM: That was definitely disheartening to hear from a person whose job is to assist the teaching of the professor, but I’m happy to say I did not take his advice.

[00:39:38] SY: Wow! Well, good for you. Good for you. Number two, best advice I’ve ever received is?

[00:39:45] FM: To utilize the 20-minute rule, which is to spend no more than 20 minutes blocked on a problem. After 20 minutes, reach out for help. And I learned this from a book called The Standout Career by Randall Kanna. And this was a game changer for me because I have this bad habit of keeping to myself and not reaching out to people for help. So learning this technique and slowly incorporating it into my daily work helped me get what I needed to be done and not be stuck as long.

[00:40:21] SY: Number three, my first coding project was about?

[00:40:25] FM: My portfolio website. So this one I was especially proud of because I didn’t need to do this project for a grade or for a class. I did it for me. So I used HTML and CSS to showcase my school projects and my GitHub links and my LinkedIn and I hosted it through GitHub Pages.

[00:40:50] SY: Wow! Very cool! Number four, one thing I wish I knew what I first started to code is?

[00:40:57] FM: That my mistakes and objections do not define me as an engineer.

[00:41:02] SY: Oh, big one. Big one, for sure. Yeah.

[00:41:05] FM: Yeah. During my undergrad, I was convinced I would never use my degree after college. I didn’t understand the material as fast as the other students. And I was constantly rejected from internships and scholarships, even full-time jobs. So what does define you as an engineer is your willingness to learn constantly.

[00:41:31] SY: Beautiful! Well, thank you again so much Farhana for joining us.

[00:41:34] FM: Yeah. Thank you so much.

[00:41:42] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.