How Frontend Engineers Can Survive the Next 2 Years of AI

I've been talking to dozens of front-end engineers, and they are all worried. AI models are getting better and better every day. They are kind of chipping away the work that a front-end engineer used to do. The question that's on every front-end engineer's mind right now, it's what can I learn to survive and to stay relevant and valuable? Yeah, so step one is to basically use AI to replace yourself. And you'll use this to basically buy your time back. Now, a lot of front-end engineers use AI by basically having a coding agent that helps you out with features, but you need to go way beyond that. You want to basically disrupt yourself, and you want to really test how much of your day-to-day job can you automate with AI? So, that means you automate also the verification layer. You add as many quality measures as you can to your

code. You use agents to even specify out tickets, to reproduce bug issues, to test tickets. You have end-to-end tests that cover the whole application. And my personal challenge to each one of you is to see how many tickets can you release to production without breaking it and maintaining high quality? And the side benefit of this is that you'll see the reality beyond AI coding right now, because I promise you things will start to break. So, that will give you back a bit of confidence, which is you still need a developer to do all the supervision. Now, if your even model is successful, you will have a lot of time

on your hands because a lot of the issues or common bugs would be solved by AI. You just kind of review the PR, merge it, and the quality might not be 100% what you used to deliver, but it's good enough for you to focus on other things. So, number one is use AI as much as you can. Don't be afraid of it. Actually, lean into it and use it to free up a lot of your time. And now, use your time intelligently to build the skills that will make you valuable in the future, right? And that, I guess, bring us to step number two. And so, step number two, if you're a front-end engineer and you want to stay relevant in the age of AI, is to learn the full stack. So, basically become more broad. Now, a lot of people are very confused when tell them this and they're like, "Well, what should I focus on?" And then very easy mental model is to look at your backlog if you're working at a company and try to pick up tickets. And

all of the sudden, you'll find yourself running into full-stack work. And so, you really want to focus on what we call end-to-end. You want to be able to deliver value in production. So, that means not only learning a bit of back-end and APIs and databases, but also learning CI/CD, learning about the cloud, getting all those credentials going, getting access to the observability and monitoring platform so you can solve bugs yourself and be able to go end-to-end. You're basically now working alone, like you'd be the CTO, you work with the product manager. And if you're employed, I would try to really get this possibility at work as soon as possible because it's a lot easier to defend full-stack experience when you have concrete examples of you doing it at work. >> Now, Bogdan, what if I am unemployed and I've been working, I don't know, 5, 10 years as a front-end engineer and now I

want to go to the market, but I want to go to the market as a full-stack engineer. What should I focus on and will I be able to even compete with other full-stack engineers in the in the market? >> Well, to answer your last question first, can you compete with a senior full-stack engineer? No, and you don't have to because you'll go for front-end heavy jobs. In the full-stack spectrum, there's usually a lot of jobs that are sold as full-stack because they want someone that can touch the back-end, but what they need and what the interview will be about it's a lot of front-end. It's literally a 70% distribution where

70% are front-end skills and around 30% is full-stack. What companies don't want is someone that cannot ship their own work. That needs the senior help to go in and integrate their changes. Now, most of your changes will be around the front-end. >> If I'm unemployed, how can I make that transition? >> Now, if you're unemployed right now as a front-end engineer, most of experience is front-end and you want to go to the market as a full-stack, what you want to do is to connect the dots in the back. So, what I would advise everyone to do is to try and create a replica of the back-end APIs they were consuming. And so, whenever you talk about those back-end APIs, it'll always be in the domain space of your last company. So, it's the closest thing to production experience. If you go in the interview and you say you're doing some side projects with GraphQL, you'll almost

instantly be disqualified because they'll tag you as a junior because only juniors do side projects and only juniors have portfolios. But, if you talk about the full stack in your company, if you talk about the CI/CD pipeline as it was configured in your company with confidence, it'll sound like you're doing full stack work. So, what you want to do is to see how much can you remember from your last job and create like a local copy of the systems you're working on and focus a lot on the back-end because you as a front-end you have the front-end stories, you have the front-end experience, but now you want to build the rest of the black box called back-end that you're just consuming. Another very important

question by Ronit is how long will it take me to become a proper full stack engineer and this is particularly important if you're unemployed because you don't have a lot of time at hand. You want to make that transition as well as possible, go to the market and get a new position. Yeah, so basically in that case I'd follow two different paths. A immediate path, which is going to the market as a front-end and applying to the front-end positions that you have because there's a lot in interviewing like getting screening calls, behavioral interviews that you can practice in the front-end niche. It's going to be smaller, you'll get less interviews, but

it's still very valuable experience. So, I would create that front-end resume that's competitive. Check out our channel, we have a video on resumes and how to optimize them. Even in a bad market, with just a front-end resume, you should be getting two or three interviews a week. If you're getting less than that, uh you're going to have big problems and going to full stack is not going to solve them. You got to solve the resume problem. The second path I would do is to start moving a lot of your experience towards a full stack and here I would start by building that full stack resume. So, branching out from this front-end resume, which should be a front-end, and adding some full stack skills, mostly around the

front-end. So, I would basically add uh some API skills, talk a bit about APIs, databases, but don't go >> You'll get completely lost. It has to be close, like use the law of proximity, as close as possible to what you're doing in your last job, and mostly around the data layer. >> And Bogdan, in our experience, usually this transformation from front end to full stack takes about 3 to 6 months, given that you follow a proper road map, and you have some kind of accountability and feedback. And my advice is either talk to someone who's already a full stack engineer, and they can guide you, or if you want to work with someone like us, we have a specific mentorship program. You can check the links below, where we help you do exactly that, transition from a front end engineer to a WhiteSands AI native senior full stack

engineer. >> Yeah, so as you mentioned, usually 3 to 6 months to a sign offer as a full stack, and it's usually a senior full stack. So, don't get scared here. Like, usually the skill acquisition can be done in 6 to 10 weeks if you're determined and if you're consistent. The rest would probably be job hunting and doing a couple of interviews to see where there are gaps. But, don't worry But, remember that when it comes to the full stack market, there's a huge subset, probably around half of this market, that is very front end heavy. And this is what you're targeting. So, it's not completely a new job, it's an extension of your previous job. >> And the next question is, what are the paths for me once I move towards a full stack? People are throwing around terms like product engineer and forward deployed engineer. What's out there for front end engineers who want to go full stack?

>> So, right now, as you mentioned, it's very early to say, and there's a lot of noise in the industry. But, in general, we see a couple of branches that you could place yourself. So, if you're a front end engineer right now, and you go heavier on the design part, you learn about design system, you learn about a little bit about taste and cohesion, and not only about how to, you know, write CSS, but what kind of UX and UI makes sense for specific domain, you could go more into design engineering. And this is for the people that they really love the front end. They love making things that look good, that look sleek, and they have a taste. They like things like photography or typography. It's extremely hard for AI to create beautiful things. I know everybody sees these demos and you hit enter and you get a landing page, but those things

hardly ever sell. When you go to the industry and you need to build a product that sells, it's a lot more complex and you really need someone if you want the beautiful product. They're just building a design system that makes sense, that it's accessible, that it's performant, but at the same time looks good and they need to maintain that. So usually that will be a design engineer. And again, this would mean getting very deep in things like CSS transitions and pretty much and the new browser APIs, but even mobile patterns and so on. It's all about the kind of design side of front-end engineering. The second part would be as you moved towards the full

stack, you would have to branch out. You would either go deeper in the full stack and become a system engineer or you move towards product engineering or what they call the forward deployed engineer, which is basically just a product engineer that's an external consultant. In general, most developers like this position a lot more because you're working on a product long term, the consultant salary is usually better, uh it's more exciting and you don't switch projects so much. Uh forward deployed engineer is basically a product engineer that's external. >> What's the difference between product engineer or FD and a systems engineer?

>> Well, a systems engineer is responsible that the factory itself runs. They are responsible for the lower layers of the platform, a lot of cloud, a lot of CICD. Whereas the product engineer it's usually it's more for user of those things. They use the platform, they use the design system that the uh design engineer created, they use the CICD platform and the building blocks that the system engineer put together the lower level and they assemble them into complex features. Probably the closest to the product engineer is the traditional full stack role. >> And the systems engineer is the one that

builds the platform that the product engineer can build on top and ship features. All right. >> Exactly. So once you have a couple of product engineers and they start shipping features, system will break and someone says, "Well, maybe you should dockerize all our applications and simplify our deployment." Well, that's not the task for product engineer. The product engineer works really close to the users and really close to the product manager or even the stakeholders. So, a lot of they do is thinking about what to build also. Whereas the system engineer, it's just making sure that things don't break and that we really fulfill our SLA and our

availability. And they usually also do, you know, things like refactoring the architecture. Like, okay, let's move from microservices to event-driven. Well, somebody needs to define that. The product engineer is usually meetings with users and they're looking at web analytics or product analytics. They're not going to be deep in the logs of AWS. It's just There's too much distance. Can a single person cover those? Yes, but it's a different job. That's someone doing two different jobs, let's say. >> Or someone working at a startup. But I guess when I'm thinking about system engineer, the skills that they need are very much related to distributed systems

and very technically deep, very close to the technology. And the product engineer, and that brings us to the third step, has a lot more product knowledge and domain knowledge, right, Bogdan? >> Yeah, so the thing about domain knowledge is that as a company, it's so much more attractive to hire someone that has solved the same problem in the exact same sector for the exact same set of users, with the exact set of policy, regulation, and so on. Because the onboarding time is virtually zero. Even if someone that's a total civilian, they could learn with AI, they'll have to go through all the jumps, do all the mistakes, and it's a lot better to hire someone that worked in the industry. So, if I'm a financial company, I usually prefer to hire people that work in other for other banks or other insurance companies before. If I'm in health care, it's so much easier to hire people that worked in health care. And I feel like

engineers, we are so focused on the tech stack, but I would definitely switch it. So, normally people are like, "Oh, I'm a React developer." But now you want to look more at the sector. I'm like, "Okay, what other companies that are building software in this sector are hiring? What are they hiring for?" If you build software for the construction industry, probably you know a lot about that industry. So, it's a lot easier for you to sell yourself in an interview. >> It will always feel natural. There will be no resistance. And that's what I would also look for if you can. So, to recap for the front engineers watching us wanting to stay relevant and survive the AI age, number one, use AI to

replace yourself and to free up time, so you can actually use that time to learn the full stack. And when we talk about full stack, you can move in different directions, the product engineer directions or forward deployment engineer, if your company sends you to a client, or the system engineer direction. If you're moving towards the product engineer direction, domain knowledge is very important. Product knowledge is very important. If you want to move towards the system engineer direction, then you need to learn more technical depth, and you'll probably move towards distributed systems and system design. With that being said, folks, whether you are a front-end or full-stack engineer who wants to get hired, we have a specific program which is hired in 90 days, whose sole focus it's to get you hired. Or if you're employed and what you actually want is

to move towards the full stack and move towards senior and become AI native, we have another program which is solely focused on that. Depending on where you're at, you can just book a call with me. We're going to connect, see where you're at, see what would be the best step for you, and whether we could help you or not. So, check the links below to see how we can help you, and we will see you, folks, in the next one.