Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#240 - Navigating the Front-End Landscape: A Senior Developer's Perspective on AI Tools, Front End interviews and What Makes You "Senior"
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
Yasemin, a senior front-end developer with a decade of experience, shares insights on career progression in front-end development and how the transition from junior to senior is more about mindset than technical skills.
She discusses her journey from being task-focused to product-minded while offering practical advice for developers at all stages.
• The junior-to-senior transition
• Front-end interviews
• Deep JavaScript fundamentals and whether they're worth learning
Check out Yasemin's podcast "Commit to Growth" and look for her articles on Medium where she shares more technical insights and career advice.
Shameless Plugs
🧠 (NEW) Parsity's The Inner Circle Program - a highly customized roadmap to take you from 0 to hired. For career changers who want to pivot into software.
💼 Zubin's LinkedIn (ex-lawyer, former Google, Brian-look-a-like)
👂🏻Easier Said Than Done Podcast
Already a developer? Check out 👉 Not Another Course
Serious about joining Parsity? Schedule a call with me ☎️
Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network and more. I'm Brian, your host. Today I'm speaking with Yasemin, a senior front-end developer with nearly a decade of experience. She also hosts a podcast called Commit to Growth, where I recently was a guest. She has excellent topics that are technical about career strategies. I'm really excited to have you on today and speak about a few of my favorite topics, like front-end interview prep, going from junior to senior and what it's like being a front-end developer in 2025. Welcome to the show.
Speaker 2:Thank you so much. Thanks for having me, by the way, I'm really excited to be here.
Speaker 1:Me too. I don't speak to enough front-end developers in general and I love the fact one that you have a podcast. That's really technical. You talk about things like core web, vitals, scaling, code bases A lot of things that front-end developers I feel like is missing from the dialogue online People in general and me too a little bit I started off in front-end developers I feel like is missing from the dialogue online People in general, and me too a little bit.
Speaker 1:I started off in front-end and I'm still mostly front-end, but I feel like nowadays, like everything is full stack, full stack, full stack. No one talks about front-end development and I'm happy to have you on there, especially as an experienced senior person, to get your take on some things, because I know that a lot of people want to get into front end. They're either nervous about it or the changing landscape. Front end is tough and you and I have been doing this for about the same amount of time and we've both seen how much it's changed. I'm curious, because this is a question I get from a lot of people how do you go from junior to senior Was?
Speaker 2:there a point in your career where you're like, okay, I'm no longer junior, like when was that magical moment that you say I'm not a junior anymore? Yeah, it's a good question. I think when I was a junior developer, I was very focused on code itself. As I said earlier, I was all the time worried that I was falling behind and catching up and completing tutorial-based projects. I don't even remember how many times I completed this to-do app in different languages. I was also very much focused on features and not thinking about the bigger picture why we are doing it and who is going to use it, what we are doing actually. Here I was given tasks. I believe I also attributed to the fact that I was working as a contractor. I'm not sure if you have experience, uh, working as a contractor, but a little bit yeah yeah, working as a contractor is way different than working as an employee.
Speaker 2:because Because if you are a contractor, you are at least this is my experience. I believe it might vary again, but from my experience when I was working as a contractor, I was given a specific task, technical task and I was focused on that one. I wasn't involved in product decision. I was in those meetings, to be honest, but I was just using uh or treating grooming sessions like extra time to cook.
Speaker 2:Oh, yeah, I, I know what you mean, yep yeah, and instead of the opportunity to engage in discussions about the product. But I think this is the moment that I felt like when I grew up into a more senior role, I started realizing how important it is to actually be part of the product conversation and questioning it and taking initiative, not relying on people or not waiting for a task to be handed to me, instead and asking around and telling them. Well, this is something that I noticed. I think we can improve it. So let's do it together. And I'm not sure if you have such things, but in Preply we have this chart. I really like that one and it shows every level P7, P6, P8. Let's say, you are a P7 engineer and want to become a.
Speaker 2:P8 engineer and there are certain things that you can follow, for example, engaging in a product decision and coming up with ideas, or taking on initiative, company-wise initiative, such things. So it's nice again like there is a lot of ways to achieve these goals, but it's just an outline that you can follow. I think that was one thing that I noticed, that I am no longer a junior developer, but I will say that it's not because my coding improved drastically. I started to write tens of thousands of lines.
Speaker 2:It's not about that, but my mindset changed. Mostly related to product.
Speaker 1:That's super solid insight right there. Because, yeah, I think a lot of people think that they're going to. That was my problem. I thought I'm just going to get so good at writing JavaScript, I'm going to learn all these weird intricacies and I'm going to read all these books and I'm going to know all these weird little pieces of JavaScript and I thought that would make me senior. But you're right, it's not. It's not about just getting infinitely better at code. It's about having the product mindset, being able to contribute to the product direction. It's kind of like, at a certain point, if you're senior, you're kind of the person they look to in the room to have an opinion on something, or if there's a bug that happened. They kind of look to you like you've probably seen something like this before. So I think there's a mix of experience and an ownership in that product mindset. If you were mentoring somebody like a junior developer that said, hey, you know, can you mentor me and I want to become a senior, what would you tell them to focus on besides technical skills?
Speaker 2:I would recommend recommend focusing on. I believe, soft skills or behavioral skills, such as improving communication and mentoring is very important Not being afraid of taking on initiative, and one more thing that I also started doing when I grew into more senior role is that building strong problem-solving skills it goes beyond framework, a library or language you are using, but focusing on problem-solving skills in both technical and non-technical.
Speaker 2:It's very crucial, and writing code that's maintainable is also very, I think, important thing to consider, and thinking about the next developer who is going to read it. Because back when I was a junior, I was very proud of the code that I wrote when I used a lot of complicated uh things such as, I don't know, inheritance, polymorphism when I wrote such code, or using even generators like uh, why generators? Right, if there is a simpler way to do it and just go for it, I think it is fine and no need to use generator. But back then I was like, okay, I needed to prove that I know how to write.
Speaker 2:Now I do value simpler code so that people, especially next developer, will not struggle as much.
Speaker 1:That's a good one. It's so funny you said generators because I remember when I like learned them, I was like looking for ways to introduce them into the code base. I'm like, how can I use a generator here, Cause I really wanted to do it. Or I find something cool Like um, I forget, uh, the pipeline operator or something. It's like a experimental feature and I was like, oh, how can I use this?
Speaker 1:But you're right, it's like you need to use the tool for the job, but also think about, like, at the end of the day, this is other humans reading this, Like. These are teammates on our team and these are humans, not robots, that need to be able to extend the code, understand what it says and debug it quickly and easily and not have to call on you every time something breaks because they don't understand your beautifully written code. That is super funny that we did some of the same things there, but it's fun, right? You learn something and you want to show it off. You're like, oh yeah, I want to show off this cool new thing I learned. Or like, make my code more elegant and all these kind of things. You talked a lot about some technical hard skills also. How important. Do you think it is now like with AI, with frameworks, to be really good at JavaScript as a front-end developer?
Speaker 2:I think it's a lot simpler, I would say, because you can now pull an open-source project and ask an AI and walk you through the whole project and this way you can get yourself familiar with that within a matter of hours. But back when I was a junior, ai wasn't a thing that I was reading a book, literally a book. I remember myself yeah all the time.
Speaker 2:Right now, I still, uh, try to read the book, but not in a way that like I don't have a book anymore, like how to write a code, c-sharp code, like I don't have. Yeah yep um, but I guess it's uh a lot easier, uh, when you think of it this way okay, okay, yeah, I, yeah, I talked to you.
Speaker 1:I'm sure you know kyle simpson, right? The guy that wrote the you don't know javascript series. I actually asked him this question. I was like hey, what do you think about like learning javascript now? And he's like I don't know. He's like maybe you don't need to be that good at javascript anymore. I was kind of shocked when he said that he's like so the reality is he's like you need to, you need to definitely have like some fundamentals down. Like you need to know like some basics of javascript. How deep do you need to go nowadays? He's like if you're getting paid to write react or angular or view for whoever's using view, you know you're going to need to know JavaScript for sure. But like you're not writing JavaScript for the most part, like you're just not writing that much vanilla JavaScript in a day to day basis for most jobs, which is which is kind of interesting.
Speaker 1:Speaking of JavaScript, let's move on to interviews. Speaking of JavaScript, let's move on to interviews, which is one of my favorite topics, and we always talk. If everybody wants to talk about Google and Facebook and Netflix, I'm like, well, you're not going to go interview there. Let's just be honest. Most of us are never going to interview with those companies. Those are the top 1%. I mean not even the top. They're just like they take up 1% of all software engineering roles. The other 99 99 are much different and front-end interviews even get get talked about even less people forget like front-end interviews are a thing when it comes to interview prep. For you, as a front-end developer, how do you prepare for a front-end interview?
Speaker 2:I want to quickly uh tell you you what I've gone through in terms of interviews, because I had a mix of interview experience over the years.
Speaker 2:I say it really shaped how I think about tech interviews nowadays. Right after I graduated from college, most interviews I had were very algorithm focused Because I was interviewing for banks in Turkey. So they were asking me questions like I don't know algorithm questions, lead code questions and I remember one day I was interviewing for a bank they asked me questions related to mostly in Java and algorithm. And then later I started applying for contractor roles which are remote based. Interviews were more framework specific. For example, for React Native roles I asked direct questions like what's the difference between React and React Native? And then these I'm not sure if you have ever come across such questions, especially in GitHub like top 100 questions.
Speaker 1:Oh yeah, for sure, react Native questions, and they were literally asking me such questions.
Speaker 2:I remember that HR was asking those questions technical questions in the first round, and then she was, uh, kind of taking notes and expecting the right answer, like oh yeah yeah I hated that they'd expect the exact thing and like they don't know the answer they don't know.
Speaker 2:The answer it's yeah. It's very hard to pass this level, to be honest, and also, and also, like some companies gave home assignments and schedule a follow-up call where I walk them through the project which I really like, by the way, because not only helped me create an app and or a web project, so I was able to tell them or the way how I created, created those projects. I like those uh interviews a lot, yeah, but then, uh, I would uh tell you that I had an opportunity to interview with amazon and it was for a ber location, berlin hub, but it was very, completely different than what I was expecting or what I got through for applying for a job in a contractor-based company. I had seven rounds of interviews and it was very overwhelming. I didn't get the job, by the way, and it was a great learning experience, because one thing I appreciate was how much emphasis they put on behavioral questions Up until then.
Speaker 2:I wasn't interested in that part. I was focused on technical part only, and after I had an interview with amazon, I started to think more and more about behavioral things such as conflict resolution, decision making, collaboration, and there's something smaller companies often overlook. But I really believe soft skills are just as important as technical ones, yeah.
Speaker 1:Oh my God, Especially as you get more senior, because I realized this at some point.
Speaker 1:My interviews went from like build a React component, or let's like build a class for a bank or something like that into like hey, you are a manager, how would you resolve a conflict between design and product teams and you have a deadline? I'm like, oh, I was not prepared for this question at all and I was thinking it was going to be purely technical. But you're right, I actually went through the Amazon rounds as well. And yeah, the seven round interview thing. Maybe that's not as common in Turkey or in the UK in general, but in the US I feel like all my interviews now are six rounds five, six, seven eight rounds of interviews.
Speaker 1:It's draining and I'm like why do you guys have so much time? If you're Amazon, I get it, you have enough time and money to burn. But if you're like a startup, I'm like do you really want to do seven rounds of interviews and have all your engineers doing this for multiple people? It's just not a great idea. But yeah, yeah, the behavioral piece is so, so important when it comes to, like, technical prep for maybe more like junior roles. Like what would you recommend people do? If they're like, hey, I'm getting ready for a technical interview for front end, like what, what would you tell them to go about it?
Speaker 2:I genuinely think that it is based on company, because every company's focus is different.
Speaker 2:As I said earlier, there were some companies that I interviewed with and they were mostly focused on technical things or framework based knowledge, such as if you are applying for a React Native role, then you should brush up on React Native skills. You should definitely go through the architecture, new architecture or performance issues. You should prepare some answers, for example, for the questions like what's the most technical or challenging project that you ever worked on? Such things I guess it's very crucial. But again, if you are applying for a framework role, then it's very important to go through framework and it is very less likely to be asked question lead quote uh questions for these uh jobs. But for larger companies, I'll spend more time on lead code or similar platforms and I always also go over behavioral questions.
Speaker 2:I believe nowadays, interviewers started to ask more and more questions behavioral questions even in startup companies. It's getting very popular. I believe it's very important to brush up on that. It's very important to brush up on that. But for technical again, we can use open source projects such as top 10, top 100 questions to go through that. And also I think I noticed that people started to focus on framework and forget about how to write pure JavaScript. It is also a bit important, for example, how to write an event emitter and the things that we are doing every day but not knowing how things are working.
Speaker 2:How things are working, for example, like we are using, candidates often saying that they are using MobX observable pattern but they don't know event emitter how it works. So it's just something that we need to deep dive into, the foundational things as well.
Speaker 1:Oh my God, you just like took me back to an interview where I was writing an event emitter.
Speaker 2:I'm like, oh, I forgot about that.
Speaker 1:Yeah, really good, Really good advice. Yeah, I don't skip over these fundamental things. And also just to understand the patterns and the uh, yeah, the. The patterns that you're leveraging in a code base like react or angular or whatever library you're using is, is probably based on some old pattern that is like very well documented, that you could look up and understand how it works and you might be asked to implement in vanilla JavaScript. Really, that's a really good one. Before I let you go, I want to get some hot takes from you, if that's okay.
Speaker 2:Yeah, I will say that for someone who is trying to get into tech, it might be overwhelming in the first place, but over time it's going to get easier. That's something that I can tell from my experience, and I think we should stop keeping up with new technologies, instead focusing on one thing at a time and trying to learn and be good at this one thing.
Speaker 2:And then if we are interested and we can expand our knowledge, but if you don't know one thing, one programming language, well then it's just a waste of time knowing every single frameworks out there.
Speaker 1:Yeah it's a really good one yeah, I got a couple other hot takes. I'm curious about to hear your idea about what is a, what is a front-end tool or framework you think is overrated um, uh, yeah, it's a good one.
Speaker 2:I um, I don't know I would say react and uh, because it's it's not very hard to be honest, uh, to get uh yourself familiar. It might look scary for someone who is coming from different environment, or this is something that crossed my mind right now. I bet there are more, but For sure, for sure. Yeah.
Speaker 1:Okay, okay. How do you feel about TypeScript? Do you like using TypeScript or you think it's just making it more difficult to write front-end code?
Speaker 2:I don't like it. To be honest, I was using Flow I'm not sure if you ever used it and Flow was created by, I think, react founders and it came with React. It was purely state types like prototypes, no prop types. It's also another. Oh yes.
Speaker 1:Yeah.
Speaker 2:And it was similar to that one. I might be confusing now, but I don't know. I remember flow, but I mean TypeScript. It has a lot of features comes with TypeScript, such as generics and other complicated things, but this is not something we use every single day and we use here and there if it's necessary, but I think maintaining TypeScript is a little bit hard. I don't feel it because we have a platform team dedicated to that, so it's kind of yeah, making things a lot easier for us.
Speaker 2:We don't have to deal with this developer too. Yeah.
Speaker 1:Oh man, yeah, I'm glad you said that I did not like TypeScript. I learned to like it and I'm I'm. I've used it now and it is, and when I'm working with full stack apps, I see it's pretty beneficial, like using an XJS app where you have your database connections and your API routes and your front-end code all co-located in the same project. Typescript is not a bad idea, but yeah, it slowed me down quite a lot. I'm like geez, what used to take me a day is now taking like two days sometimes to wrestle with the types. I was spending a whole day sometimes just fixing the types and I'm like this is this is the annoying piece to me too. I know we're probably in the minority here, so you know, I'm sure all the people out there like, oh, you just don't know it well enough. I'm like, okay, whatever. Last question for you If React disappeared tomorrow, what would you be using instead.
Speaker 2:To be honest, I'd like to use pure JavaScript, like I am overwhelmed with frameworks. Of course, it's not possible because we need to use a lot of things right now. Back then it wasn't as complicated as it is now. We have routers uh, I don't know themes and uh, a lot of things going on. Uh, but, uh, I think angular or not angular, okay, woo, I will say woo, okay okay, I've heard nothing but good stuff about view.
Speaker 1:I always make fun of you developers because I've just I just don't see view it's it doesn't seem as popular, but nothing's as popular as React.
Speaker 2:I've used Vue once.
Speaker 1:I liked it. I liked it a lot. I'm like this is cool. I just make fun of Vue developers because there's so few of them out there, but I need to try it out. I'm getting a little tired of React myself. I've been writing it like you probably different for a while. Thank you so much for talking to me today. I really enjoyed this conversation. And where can people find you online? We're going to have a link to your podcast, for sure, but anywhere else where people can find you and listen to your opinions or get some information about your insight into the front end.
Speaker 2:Yeah, I'm writing articles on Medium here and there, nice. Yeah, when I have free time, I'm trying to be more active on social media platforms. To be honest, it's something that I've been working on. I wouldn't say that they can find me on LinkedIn, but I don't post as often as possible. But I'll definitely start posting. You really should. I think, you have a lot of great opinions.
Speaker 1:I think you have people that actually there's too many people online that don't actually do the thing, that are talking about it a lot, and I think we need more people like you that are doing it, that have opinions, have seen some things and can help guide people with some actual advice based on what they've actually experienced. That's my opinion. I would love to see you write more, but I'll have links to all that in the show notes as well. Thanks again for being on the show. I really appreciate it.
Speaker 2:Thanks for having me. Yeah, it was nice chatting with you.
Speaker 1:That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and want to work directly with me and my team, go to parsityio, and if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.
