why Senior Developers are still getting hired right now

to study software developer interviewing right now and you are going through five, six, even seven interview stages just to get rejected at the end of the process. This might be the reason you failed to stand out. After helping over 300 engineers master the technical interview, fast track to senior, and land offers in one of the most competitive software development job markets ever. Borden and I detected five mistakes developers who failed to stand out make, and five ways to fix them.

And today, we're going to share them with you. Let's start with number one, implementation focus versus pattern thinking. Bugden, what does this refers to? So basically, somebody that it's a senior or somebody that will stand out in a technical interview, they will first focus on the pattern or the best practice rather than the code. So, imagine as an example, we're talking about state management in the front end.

Somebody very focused on the implementation focus will they'll talk about like React context, or maybe they mention something about prop drilling or they say, oh, we were using Redux. Um, whereas somebody that's thinking about patterns will talk about state management as as a pattern, so we'll say, hey, there's different strategies to um handle state in an application. Then they will go into a client side application because again, state it's something you have in any kind of application.

And then they will talk about, okay, we have component state, we have different levels of granularity, we have global state, or we might have a specific state machine library. Like React context, pardon, like um Redux or Zustand. So they can balance this and they won't go straight to the code because they know the code can change, the libraries can change, even the domain can change. Because again, you can have state in the back end, too.

But what's important, it's understanding the pattern. Behind it, because if not, you're just another coder who write to writes a bit of react, but doesn't really understand what's going on there, how react and to be written and how can it can be done better. And this is why you don't stand out, you're talking about what everybody talks about. So, if you want to stand out, focus on the pattern first, develop this pattern first kind of thinking.

Then, follow up with the implementation, you need both. Okay, let's move on with number two, surface knowledge versus technical deep dive. And, I think this is very much connected to the first point that we mentioned, this pattern first thinking. But, uh, we see, yeah, the opposite, coaching developers every day, we see the opposite happening, right? People get into the patterns, get into the best practices, but they cannot go very deep.

They end up having this kind of superficial knowledge where they can talk about things. But, when you ask them to dive deep in terms of, how have you done this, they go blank. Yeah, sure, so I guess the best way to explain this with, it's again with an example. Um, somebody with a surface knowledge, let's say the example of web performance in the front end, right? Again, another front end example.

Somebody with surface knowledge will tell you, uh, well, the application is slow, so we optimize the images or we change the fonts, or maybe they even tell you that they run like a lighthouse analysis. You know, they will take it from there, but that will result as a very shallow experience or they won't really know how that's connect. Whereas someone that has technical expertise and can can deep dive in a topic, they will tell you.

Well, you know, when you look at web performance, this is this is what's happening when a page gets interpreted, right? This is a critical rendering pad, another pattern. But then they can go deeper and tell you, hey, based on the, you know, the page will be slow because maybe you have too much CSS, or maybe you didn't extract critical CSS, or maybe you're not using the right format for the images, you're using PNGs where you should be using WebP.

And they would understand why WebP is better, they understand that the WebP image has a better quality to compression ratio because of the algorithms using it rather than a PNG and that it was specifically developed for the web. And so, that will come across as an expert because they know things in depth and they can articulate it. They will not just tell you, yeah, like optimize the images, which is very shallow.

And people, when they hire a developer day by expert, they're willing to pay a lot more because they don't want to take the risk. And so, what happens to a lot of people it's usually because they cannot go deeper into the things they say. They cannot really articulate and really take, hey, this is how it works. This is why, this is getting to the core of the issue. The reason for it is not usually their fault, it's just at work.

You get hanged into so many meetings and it's so easy to procrastinate and five years later you find yourself in the same position. So you've got to be obsessed with getting to the core of things, getting deep into everything you're working on. And I would say this is not only for technical interviews in the context of an interview, but if you have your eyes put on a senior level position or a principal level position, you have no choice, but to go deep, to develop that technical depth.

Awesome on to number three, console log versus professional debugging skills. I think this is quite self-explanatory. But uh, what does you you've been interviewing developers yourself. You've been interviewing yourselves, what is the advantage of actually learning professional debugging skills? And what are those professional debugging skills versus just, you know, console logging the hell out of your of your code?

So, again, it comes down to efficiency, right? Someone that's using console log, uh they will basically go through the whole code. Add console logs and the other thing is console log works well in the front end. But when you go to the back end, there's so many layers and middleware that you go through to actually figure out a complex bug and if you go with console log, I can promise you're going to spend 10 times more time than if you set the debugger up.

So what happens is people get these bad habits because everybody's doing it, especially in the in the front end we use console log a lot and then what they see is that the senior person in the team can actually figure out the bug they've been staring with for three days in a couple hours or even worse in half an hour. Or even worse because they know what questions to ask in 5 minutes, you know, oh yeah, you got to look at that.

Um, and so the most predictable way to figure out bugs and again, software systems are very deterministic, what you put in, you get out, there's no mystery. And so juniors, like they go, they console log, it's kind of very tedious. You need to clean it up whereas a senior would go in and be like, okay, let me run through the code with a debugger. Is the front end or the back end? Okay, is there any network layer problem?

Then I go in with the network tools. And if not, you know, they use like the backend uh debugging tools. If it's a database area, then know, they can actually query the database manually with a database explorer. And because they have all these tools, they literally see through the code with a crystal clear. They know what the issue is, they know what how the system should behave at this layer and why it's not behaving like that.

And so they can immediately, like a surgeon, immediately go there and change what's what's missing. And people see that and they think, wow, it's because of the years of experience or whatever. But the reality is, we know people that have 10 years of experience that cannot do that. So it has nothing to do with the years of experience, it's about your knowledge of the tooling. And you really want to be very good at looking at software like uh with some some, how would I say this? It's like uh an X-ray machine in a way.

That's what good debugging is. It's really showing you the inner work and so for a civilian, it looks like they click on something and and they get a result. But for someone that knows this, they can see through it, they can see the the the bones and the tissue. And everything that makes up. And you know, it's like blood analysis, you all of a sudden you know what's missing because you'd be this diagnosis.

So get good at debugging, get good at seeing through the software as it is, the deterministic system where you have, you know, function calls and data, and that's pretty much it. It will make you 10 times faster at debugging and, you know, fixing problems. Uh for the people watching us, could you mention just uh the main tools that you recommend to a um front a JavaScript engineer that's watching us and wants to get better at debugging?

Um sure. So if you're working on the web, starting at a very client-side kind of things, you want to know how to run the debugger in the browser. So go to the source tab, add break points in the browser, and also make sure that you know what source maps are. Because usually when we bundle our code, we'll use developer to debug that where you're going to debug some some mumbo jumbo uglified code. That doesn't make any sense. You need source maps.

So understand when do we emit source maps? How are they managed? Um once you know that, go back to the network tab in the browser and understand what your HTTP. So response statuses, response codes, what are the typical ones? Like what's a 401? What's a 403? What is a 503? What does it mean? A 503? when you when you get the error um and also the headers like what what is accepting coding, what is content type? You you got to know at least 5 to 10 headers by by memory because that shows that you've been working with them a lot. It doesn't show that you memorize them, but just you know how to get them. Now moving on to the back end. You want to know the debugger tool also in the back end, if you're using TypeScript, it's just VS code. You can set up the debugger and go with different break points. And then if you're using Docker, or um you want to know how to debug inside Docker because it has an extra layer. And finally in the database layer, you really want to log out, you know, your database calls and if you want any any database call fails, you're going to be able to copy that query and run it in an isolated environment like Padmin, if you're using Postgress or you basically want to run the query manually and see why is the query failing. If you have all these layers, you're already 90% there. Of course there's some more things you could add to the language, if you have that, that's already 80% of everything you need to know. Awesome so just to summarize the browser debugging tools because that's where your code is running, the network tab also in your in your browser to make sure you understand the different requests, and then inside your IDE, if you're using VS code, you have a debugger, but most professional IDEs come with a um with a debugger. So learn how to use that, how to set the break points and all that, and later if you're moving towards uh Docker. Then learn the specifics of Docker and in terms of database, the specific tooling for databases. I remember back in my junior days when um I faced the reality that I had to get better at debugging and I just didn't want it because I felt like it's going to take a lot of time to learn these tools. They seem pretty complex and uh probably that's one of the biggest mistakes I've done, if I would have gotten better faster and I just invest a bit of time in it, the pay off would have been huge later down the road. Uh, not only in productivity, but also in standing out in the team as someone who takes their craft seriously. On to number four, number four, back statements versus knowing your numbers. And we did talk about this, surface level knowledge. I think this is very this this point is very connected with the other one, but it comes from a different angles. And what do we what do we mean when we say know your numbers in software engineering box?

Yeah, sure, so again, the best way to explain this is with an example. Imagine we're talking about testing, and we are in an interview setup and I ask you, um, do you test your code? Do you write test? Somebody giving a vague answer would say, yeah, we we do, we write unit tests. That's it. But someone that knows their numbers, we'd talk about code coverage and we'd talk about how at the moment, let's say, we have around 50% code coverage, but we're working towards getting it at 70%.

Knowing that, for example, Google, um, will not approve a pull request if it has less than 65% code coverage. So they can always reference what they do back to an industry best practice. It doesn't mean they will always apply the best practice, you don't have to, you don't have to work like Google if you're not Google, but they do know those references. Another example would be, for example, loading time, right? So somebody uh with experience would know that if you ship more than 1 megabyte of JavaScript in a single bundle, there's a big issue going on there.

Like if you're really downloading a single bundle and they know how to find this out, go to network tab and look at the number like, okay, 1 megabyte. It's way too much. The industry standard, like the Webpack warnings, trigger already at 250 kilobytes after you compress and minifight. And so because they have these references, they can give an expert insight when they're being asked a question. They don't to tell you, yeah, just make sure your bundle is not too big. What do you mean? What is it too big? What is it too slow?

What is a slow re-coil? And then they can bring that into their context. So it's not like a uh somebody that just talks about, yeah, we should code uh look code garbage of 65% because Google does it. And they say, look, industry best practice is here, this is our context, how do we combine that? And that gives this flavor of, okay, this is an expert, this is a person that has expert decision making.

They know the industry uh numbers and they can bring that into my business. And it just shows professional etiquette and it will it will make them go crazy, to make them even throw more money at the table if they found someone like that. Those people do not come along very often and that's kind of having combining that hands-on thing with the engineering mindset. Very important, as Barger said, to know your numbers and also the why behind them.

So those are not arbitrary numbers that you found on the internet or because Google says so or better session. But you know the reasoning behind those numbers and knowing your numbers will allow you to do something that's crucial to any job in the 21st century, which is making data driven decisions. As a software engineer, you have to make tons of decisions, not only technical decisions, but also user experienced focused decisions.

So knowing your numbers, knowing how to interpret data, knowing how to find the data will definitely allow you to stand out. And this is an easy one because most developers out there don't. Trust me, I talk to hundreds of developers every day and most developers can't tell you why, you know, most developers can't tell you what's their code coverage and why it's, you know, 65, why it's not 85. Okay, moving on to final point, number five, code versus systems.

Now what does it mean to focus on code versus systems or to focus on systems versus code? So most of us work on coding 80% of the time, right? We build components or API endpoints. But at any point, everything you do, you need to reflect that on top of the overall system. So a lot of people struggle when they need to look for a new job because usually there's a lot of red taping in your company. So only seniors touch the pipeline or only seniors touch the web pack configuration or the tooling or only seniors decide how we're going to organize our git branches.

And what happens is then you go out and people at senior level, they expect you to have an opinion and that they expect you to know, they expect you to know, they expect you to know the pipeline. They expect you to know what microservices are, they expect you to know how to, you know, how to make decisions by yourself. That's actually a senior. They don't need help. They can reflect, they can make their own choices correct, they can work and deliver.

And so you need to always bring it back to systems thinking and you need to always ask yourself, okay, I'm working on the front end, what's the back end, what's the API? Okay, what databases are they use? We're using Mongo, um, okay. That's a no SQL database, why are we not using a relational one? Even if you're working on a front end, you always want to reflect your choices based on the whole system.

That's what we call system thinking. And you understand that even if right now for the last two years I've been working on this component, if I need to work on the other one, I know how these parts relate. They can talk about architecture, they can talk deployment. If not, you're just a component developer or endpoint developer, and that's available paid, very poor added value position. You won't be able to show a lot in interviews.

You'll feel very weak and there's so many black boxes around, you don't really understand. And that's okay, we all start out that way, but you really need to start working your way out of it. And it's really important that you need to do it. Your company will not give you the responsibility most times, if you don't already know how to do it because they don't want to take the risk, because you'll make mistakes.

They will pay for it. And so you need to be proactive and try to go out to take more and more responsibility and and expand your view. Don't just be like a component developer or like a, you know, backend API developer. So folks, it's about getting into the big picture as well, not only the code, even if most of your time you see only the code. Not what happens after now. What, when we talk about systems, right?

What's what would be an immediate step? What would be, you know, two, three things that a developer could look into by themselves in order to take that step and to become a more systems-oriented person? And develop this big picture view. What what are we uh what are we talking about? So if you're working right now in a company, try and you're working only on the front end. Try to also run the back end.

Just pull the code, pull the repo, run the commands, they are in the readme. Um if you don't understand it, ask for help. But just try to run it, try to see, okay, can I run the API? And can I change endpoints and can I you know, fetch those endpoints from the front end? Just a very like a hello world. As as long as you go out of like just the front end, you it'll already change your view. Try to run the pipeline, try to see how they define the pipeline, what are the different stages?

How does it break? Can you roll back by yourself a a failed deployment? You don't need to be a DevOps experts to do all those things. You just need to to be onboarded on that system. And if you run into blockers and you're at your job, um try to figure out if someone can help you. Okay, It will help you build it's an excuse to to reach to out to people outside of your team. And if you have to put one or two extra hours or this is your learning time, that's okay.

Trust me, it will pay back a lot. A lot of the people are just in the in the in the development headway, they get tickets and they get to solve those very fast, and four years later, they can only get mid-level jobs, because they only know, you know, about to talk about the tickets they they solved in a sprint. If you're interviewing, so let's say you're not having a job right now, you're interviewing, take one of those drawing software, I use still draw for the most part, map out your current, your your the architecture in your last position.

How did it look like? Even the parts you don't know. And then map out the CACD process. If you don't know it, you just try to map it out hypothetically, but have an opinion about it. Then just go in there and talk about the tickets you solve in a spring. Nobody cares. They didn't they can't even understand them because that's very specific to your company. So you need to pull yourself out and head to see, you know, the architecture, the CACD process, both if you're working right now or if you're going to be in the awesome.

So, map out your deployment process and map out the architecture and get your hands dirty, get out, get out of your ID, get out of your react, get out of your view, and go out there and get your hands dirty with other pieces of the system and don't expect your company to do it for you. Well, folks, this has been for today knowing this five things will definitely help you stand out in technical interviews, and not only that, but also develop a senior level engineering mindset, which will get you one step closer to the next level.

Now, mindset alone, it's not enough to pass a technical interview, so make sure you also check out this playlist where we go a lot deeper in tons of very common interview questions. And this next video, as for Bogden and I, Bogden, thank you so much. We will see you in the next one.