“Not Senior Enough?” Here’s Why: 9 Brutal Realities of the 2026 SWE Job Market

We've mentored over 75 JavaScript engineers in the last six months, helping them get senior level offers in what's probably the most competitive tech job market in the last 20 years. When Bogdan and I analyzed the hundreds of coaching calls and recordings we've done, we found the same nine questions popping up again and again. And today we're going to answer them one by one. Question number one. I pass all interview rounds, but still get rejected for not being senior enough. Why? What does senior engineer even means in 2026, Bogdan?

So the number one thing is you want to have strong software fundamentals. So nowadays AI is getting most of our code. That's fair enough. But when it comes to hiring, they still expect you to be able to write and read code really fast. And for that you need basically good old software fundamentals. You need to master JavaScript. You need to be very good at TypeScript. You need to understand no P. You need to understand solid principles.

And then depending on your specialization, you know, if you're in the front and we go into how the browser renders HTML and what is a critical rendering pad and performance in depth and going into react. And if you're in the back end, you know, you go into databases, persistence, you know, no no SQL, ORM, MVC, rest, graphQL, TIPC and so on and so forth. So it doesn't really matter that AI is doing the coding, you are responsible for the quality of the software.

You are responsible for the quality of the decisions AI is actually making and committing, and that's why they hire you. So you need to be very good at software fundamentals to deliver more with AI. And Bogdan, I would go as far as saying that this is probably the biggest gap we see specifically with people that started coding in 2021, 2022 when Chat GPT came around, where they they've done a lot of coding with AI.

Right, maybe 80% of the code they write, it's AI and people who have a senior engineer in their title, they can write a four loop from scratch or they they TypeScript and plain JavaScript. It's pretty weak. Again, software fundamental it's a huge bucket, we cannot dive deep into all of it. So folks, if you want Bog Knight to make a video specifically on software fundamentals, then let us knowing the comments. Okay, number two, it's system design and architecture. And the reason for this is because again, we are coding with AI. And so a lot of the grunt work of building a feature kind of disappeared. And now it's all about integrating a lot of code. Things are moving a lot faster. And so the decisions that used to have an impact in six months, now they have an impact in three months. You got to be much faster at predicting things. And the second one, it's if you're a good architect or if you're good at system design, both in the front and in the back and, you'll build systems that are very easy to extend. The whole mantra of software engineering for the last 30 years was, let's decouple our systems and let's make a system very easy to extend, to add a new feature with the least amount of code changes. Which means token efficiency, it means context engineering, because it's much easier to work on a model with a model, even with a dumber model, with a cheaper model, with a local model, it's very easy to work on a good code base. So if you're a great engineer, if you're a great software engineer or great front engineer, you will use less tokens. That's actually the criteria. And so we see AI getting more expensive. People are building, you know, big balls of mud, as we call them in software around them. And if you're good at system design, you'll still be able to to stand out and deliver with AI in 2026. Number three, it's, of course, AI coding. And this goes way beyond cloud code and just installing a skill. You want to understand how does AI changes your workflow and be able to integrate it without overdoing it. We've see a lot of stories of companies right now, like companies like Starbucks or even bigger software companies where they see a lot of failures with AI, where AI just kind of raise the cost and now they code base. There's not a lot of value being delivered. So you got to be very careful. You don't you don't just want to be a cloud code fanboy and go in and throw all your skills at people and be like, oh, that's that's AI skills. Those are those are not skills. Okay, skills are not skills. The the cloud code skills that you see on the internet are just fancy prompts. And a great engineer knows the model in depth.

He understands how cloud code works, and understands in which measures they use the LLM, which part is deterministic, which part is non-deterministic, and they are able to even design features with AI embedded. So back in 2022, software mental system design would do the job, but now you want to add a knowledge of AI, a knowledge of foundational models plus coding agents to your skill set to really stand out.

If not, you'll look like someone that was not really in the market for a last time or is not really aware of what's happening. And this was the case with a software engineers I was talking a few days ago, that she got this question in, hey, how does your, how do you work with AI? How does your AI workflow looks like? And like any dev, she was, she was kind of just saying, hey, yeah, I use cloud code and I always check the output. I don't really trust it.

Of course, she was interviewing with a startup. That was crazy about AI. And that was one of the mistakes because she said the whole interview went perfect. And I thought I answered this AI question well, but in the end they didn't pick me, they rejected me. And and the reason is there's two kind of, let's say two sets of companies right now. The ones that are crazy about AI, right? Then it's usually startups and everything.

And to those companies, you want to go deep. Like Bogdan said, you want to talk about agential, you want to talk about skills, you want to talk about foundational models, etc. And and then there's the enterprises, which some of them have very strict limits on whether you can use AI or not. And to these companies, you got to tell them, hey, yeah, that that answer would be more fit, hey, I use cloud code and I use cursor or whatever, but I always check the output.

So depending on which company you're interviewing with, also you you have to tailor your answer related to AI coding. Exactly. If you're going for a startup, then the latest fad, it's loop engineering, you know, we had prompt engineering, it went to context engineering, then into harness engineering. And now it's called loop engineering. So they're basically attaching the word engineering to to something.

So you want to go full mode blast zone. But if it's a corporate, if they're revenue dependent on actual software and production, you'll see that they are a lot more conservative and that's when you want to put the focus on your judgment of the AI output. Okay, Bogdan, next question, how do I signal seniority in technical and non-technical interviews? Because we do work with a bunch of developers who have good fundamentals, who have their N20 experience, and who know a lot more than the average about AI, but they still are unable to signal that in the context of a technical and non-technical interview. Sure. So, when it comes to seniority, the magic word, it's depth. The difference between a junior and a senior will always be the depth of the answer. And if you don't have a lack of depth, you will come across as passive. So they ask you a question and you just answer the question. Whereas a senior would be able to predict, based on the question they ask you, what is the number 345, things they will also worry about. So going back to these three pillars, which are software fundamentals, systems, design, architecture and AI coding, whenever you get a question around those, you want to go deeper, right? You want to gradually kind of go deeper in your answer and go from, you know, if they ask you about, let's let's put something like super fancy, like micro front ends. Like a junior would be like, well, you know, this kind of architecture, I mean, this is an architecture question, so. It's going to be a top, but they'll be like, oh, you know, it's a better architecture, it allows you to scale. But then a senior would be able to tell you, you know, how does a micro front end architecture will affect the way in which you write CSS, or in which you do testing, or in which you do, you know, caching. So they're able to go from this fuzzy fuzzy thing, like high level concept, all the way down to how do I write code because of this, and what are the implications of that? And what's that going to mean for our product and so on and so forth. And when they do this and it's really important, it's you want to mention what we call it the best practices, actually, if I'm talking about testing, I'll talk about test coverage or code coverage, I'll talk about the testing pyramid, I'll talk about the A pattern, and you want to mention, you know, any kind of mental models, like kind of senior mental models as you go. So that kind of signals, hey, I have a criteria for making this kind of decision. It's a bit of a scientific mindset when I do things. I'm not just, you know, folcloring my way around the code code base. Just doing what I heard or they know it works.

boy or girl or whatever of a specific framework, but I actually bring critical judgment, an engineering judgment to the decisions we make. And Bogdan then this comes down to like technical depth. If you want to signal senior in technical and non- technical interviews like technical depth. But what I want to talk about now it's the way you answer those interviews, right? Cuz what we've seen it's whenever you get two identical JavaScript engineers, close to senior, strong mid level, close to senior, they go to interviews.

roughly the same knowledge and one gets rejected and one one gets an offer. And the difference comes down to how they answer. And I know from my own experience that's one of the things that seniors do it's one never assume, right? Always question and never take questions for the face value. Right? So they try to dig in, they try to understand, hey, what is really about, not just default. To even if they know a certain question, like they're being asked something about micro front ends, you probably did them before seniors have this habit of actually taking a step back and digging in.

What would you say about that? Well, you you definitely want to dig in, but you want to know your stuff. Because if you just go to your interview and a lot of people like they this advice of line of ask the five wise, if they ask you a web performance question and you start asking the wise, they'll move on to the next question. Like it means you don't you you're going to ask the why with like context attached to it that you give as a senior.

So if you're telling me, you know, well, we want to switch to micro front is architecture, what would you advise? And I'm like, okay, but what made you switch? Then I'm not really answering your question. An interview is, you know, this whole happens very fast, it's 30 to 45 minutes, a bit of small talk and a couple of questions and then you're out. So you definitely want to inject around the why around asking clarifying context, the best practices to show them that you're leading them somewhere.

If you're just asking why for the sake of asking why, it's just they they're just going to get tired and be like, oh, but you're not the really answer. Ok, I'm going to move on to the next question. And by the way, folks, if you're wondering what senior engineer actually means, the best way to find out is actually to find your gaps to senior. This is why I created this free tankle assessment, you'll see the link in the comments.

Just get in your email a full report of what your gaps are and what would be the best way to fix them. Question number three, I'm a front end engineer, but it looks like AI it's eliminating the front end. Most job postings I see are full stack, do front end engineers have a future at all or should I just learn full stack? So it's definitely a justified filling when you look at the number of job postings that it feels like there's there's a lot less full front, pure front end positions. And what's been happening for the front end in the last four years, pretty much since 2023, it's it kind of was pushed to the extremes of what front end used to be. So if this would be front end dev, in the middle we have kind of writing components in and doing your design to code kind of stuff. You know, that was a lot of the grunt work of building a UI was taking that design and now putting it into code and a lot of that, it's now done with AI. So that kind of work disappeared. You can verify the output, make sure that the components are of high quality, maybe restructure things, but then AI kind of implements very quickly. So what's left is basically the two extremes, which is number one, you either move towards becoming more full stack like the person asked, which is can be a legitimate change depending on the market you're in. It's all depending on the job market you're targeting and then you either move to becoming like the you know, the top 1% front end in your local market because then you'd work in specific front end problems that not even AI can get done well, like you're building the design system of a company or you're building the micro front end architecture, or you're building, you know, specific you know, things like animations and stuff that, yes, you can do that with AI, but it's kind of look sloppy, you still need someone to really fine tune it. It's so either go into full stack or become a very specialized front end engineers, the kind of people who actually define design systems, right, who set the whole front end infrastructure of the company that AI can scale. Because AI can scale whatever you design in a way, right? Exactly.

And so if you are in a bigger market, if you are in a New York, San Francisco, Chicago, then yes, you can afford to specialize because there's a lot of companies that are very big and they need a specialized position. However, if you're in a smaller market, if you're in Florida or, you know, down south, there's there's not so many big software companies and they want you to be the person that does a bit pretty much a bit of everything.

And the same it's in Europe where, you know, in a smaller market, in a smaller city, you always want to be a bit more full stack. Question number four, what is the correct AI assisted workflow for a full stack engineer in 2026? Uh so a lot of people I see they just use cloud code or they install a bunch of skills and they think that's it or they they they they carefully craft their agents in the file, whatever that means.

But the reality is those coding agents are incorporating a lot of that. You as an engineer, you want to go much deeper than just a reusable prompt, which is basically a skill. And this is a thing where and and all these companies, they kind of manufacture this whole language. But if you dive deeper as you should as an engineer, you'll realize there's not much to it. But I would give you kind of the heads up, this we could make a full video about this.

But the number one thing it's, I would say, use a coding agent. I see a lot of people are still just kind of using chat mode and using auto suggestions, but you definitely need to switch towards the agentic part where you have a task, you work with it through the agent, then once you have a plan, you're going to actually executing. The most popular one is cloud code. I've been using that one. I use open code with open source modules.

It's also pretty good. I know copilot has an agent mode. Cursor has an agent mode. There's pie, the open source agent. But keep in mind that whenever you use a coding agent external to the to the company, they usually charge more. Codium is also pretty good these days. So number one, pick a coding agent. Number two, you want to somehow scale your and and be crazy about your code quality. And there's there's a couple of tools that came out, but you always want to be using TypeScript, you always want to have tests, you always want to have enter.

test, you want to use as many deterministic measures to check the quality of your code. There's also some static code analysis tools that are very good, they're very fast and you can work with this too. So basically, you know, you give it back and forward to the coding agents and they use each other. I would keep skills minimal. And then do make sure that you do have the minimum amount necessary of MCP servers to connect to your ticketing system, driga or linear, have very good integrations. You want to bring that in and then I usually I also use MCP servers that connect to Google Drive if I need to upload files and so on. Of course, you all work in different companies and so on, they might use different stacks. But you want to know what an MCP server is, how to build one, how to deploy one. And finally, depending on how much access you have or if your company is building with AI, I would definitely check out, you know, things like hugging face, try to either run a self-hosted model and plug it in with Oyama or even local AI. So you get to know how about how to use these things in beyond, you know, the anthropic facade or the open AI, you realize it's just a large language model with software on it, like harness, and then you can use this to separately, you can buy them very cheaply, you can have them self-hosted for for your company, and then you can lead a bit your company with with those tools. One thing, I know you bring up a lot when we talk about AI associated workflow, not around AI specifically, but more around the code base you're working with and one thing you mention a lot, it's programming against interfaces. Yeah, so of course that that goes into kind of the software architecture aspect of it, which is those models they go really fast, so the only way for you to kind of keep things order is by making sure you really modularize what you're doing. And this will kind of limit the blast radius of an error if we have clean modules in the code base rather than, you know, the big chunk of mud, let's say, you know, like the your your standard output from cloud code, it's something like that that looks very nice on the on the outside, but then you look at it and it's kind of rotten.

to kind of move towards this, which is modularization, you know, these modules they have their own interfaces, they tag to each other. And it's extremely easy to find bugs. It's harder to make mistakes, you use less tokens. So that's the number one principle. And then there's there's a lot more about data design, but probably this deserves, would deserve an in depth video on it. Question number five, do I still need to grind lead code?

or has AI made algorithm interviews irrelevant? I I would say the short answer is yes and the long answer would be yes, more than ever. Because the only way to nowadays figure out if someone really has a deep understanding of software is by making them code live and solve a problem. Now, you don't need to type the problem, you could do it on a on a whiteboard. But they will ask to see, okay, do you actually understand what a stack, what a Q is, what JavaScript does, what's a promise?

If you're going to the JavaScript world, you know, how node GS actually works and and how React does certain things. They'll really want to see that you know things in depth. And with AI, you know, everybody can kind of build a decent take home task. But production software is not your take home task. You know, production software is choices that you make today that will affect you six months from now.

And even if AI can accelerate certain things, it made other things a lot harder. So it's harder to slow down, it's harder to think about things. And if you look at software companies like financials, you know, you look at stripe or healthcare, they are the first ones to say, you know, we're going to put a hand break on AI. You can use it, but you're not going to write all your code with AI because we see all kind of weird bugs appearing.

And it's because people are just not even looking at the code. So not only you'll have to grind lead code, but you your typical JavaScript problems like debound will become lead code, writing a component. Will become the new lead code because you don't do that on a daily basis anymore, but it will be in the interview. So the dynamic of, oh, I'm getting this algorithm in an interview and it's something that I don't do every day, but I need to know it to get the job.

This is a very funny question cuz everybody online, everybody here on YouTube says, yeah I can do the coding and we see a lot of people saying, I need to learn system design, I need to learn system design. And then they they binge watch a bunch of system design videos, they go into interviews with Fang level companies and they get asked and they fail interviews because they have gaps in the fundamentals. They get questions about closure or building things with vanilla JavaScript. So it's a very confusing topic, Bogdan. What would you say? How much should they go full on to system design mode? Or should they stick to the fundamentals and just know a bit of both system design? I think the biggest problem people do is to assume that system design is different from programming. And I know it sounds very different. But for the most part, you know, you start with your simple program here, like a simple function. And then as you move up, you know, and you distribute it, and then you have several applications talking together and you have different protocols, and you end up with like a big system, right? And so let's say like a scalable system, whatever, like a big, big system. And so what you want to do is to be able to go from zero to 100 by yourself. So you got to imagine you are the CTO. You are the lead front end. And of course, a lot of people are going online and they're looking at system design and people start talking about database sharding and load balances, and they feel like that's not related to what they did in the front end. And that's true. Because in the front end system design, it's more about understanding money with interfaces, things like a design system, what kind of CSS architecture you need? How you're going to do caching? What kind of caching and validation policy you're going to use for different assets? What is critical CSS? What are micro front ends? We have a lot of videos on the channel about exactly that. But it should be a continuation of your front end skills. If you feel like there's too much disconnect, you're probably studying the wrong thing. If you're starting, you know, geospatil databases, because that's what Uber system design video is talk about. And you are interviewing with your average software company, you'll have a big problem. You go in and you run out of things to say, because you're starting, you're focusing on the wrong thing. And people say they come to me and they're like, yeah, but I'm still

learning when this when you've done like front end for five years when you see this geo spatial or I don't know database shining or whatever shiny stuff you're like, oh wow, I'm learning stuff, it feels productive. But then it's you wasting five, six, seven weeks, right? Maybe they're unemployed and they're still doing that. They're getting into the courses about fancy stuff and they don't realize how important time is.

Because in a market like this one, again, it's one of the worst markets we've markets we've seen in the last 20 years, you cannot just mess around for a bunch of weeks or take a sabbatical and then come back. Because there's probably another software engineer out there who's doing the homework and is going to overtake you. So don't treat your learning like I'm just learning stuff, especially if you're in the job hunt.

Exactly. And so you want to look at the possible versus the probable. And yes, it's possible they ask you about the load balancing in front and interview, but that's not probable. And you want to train for things that have statistical significance. So you don't just like learn anything. I I mean, knowing about byte conversion would help you, you know, knowing about how the, you know, the hard disk kind of encodes encodes data or knowing about how transistors and conductors work under the hood. Yeah, that's great. It's great.

But are they going to pop up in your average front engineering engineering interview? Probably not. So you you really want to be pragmatic here. It's like saying, you know, you're learning Chinese to go visit New York because there's definitely uh a Chinese town in New York. Yeah, sure, but you're probably I would work on my English, right? So you you want to keep it keep things real. Question number seven, at my last company, I had a senior title, but in the market, I feel like a junior.

Why and how can I fix it? And so probably the most common scenario is that you spent a while at your company. And so if this is the tech stack, right, of your company, you kind of develop skills that make you very good in the context of your company. So these are our skills, right? Also, you take that to the market, but in the market, you're interviewing with different companies and they are kind of all over the place.

They all have different text stacks, they ask you weird questions. questions, maybe it's something that you haven't, you know, you haven't necessarily touched on. And the number one golden rule of interviews is that people interview on their tech stack and what they know, not on what's relevant for the job. So then you feel like you're not senior at all for those companies because in their eyes you're not. And this is why you need to focus on kind of the what we call massy dimensions. You're going to focus on the common denominator and really learn skills that then you can transfer. And then you look at each company tech stack and you'll realize that the tech stack it's only an implementation of a more generic mental model. Even frameworks are just an accumulation of different principles. If you know those principles, you go into a company, you know, you're a react developer and they tell you they use Svelt. Well, you could still use 95% of your knowledge. Because your knowledge is not react specific. It's, you know, web browser engineering, HTML, CSS and you project that then into Svelt. And so, if this is how you feel like, I would really make a bit of an assessment, you can use our assessment and see what is the biggest gap. Because definitely you've probably over fitted your knowledge to your current company. And you know the domain, but it's hard for you to extrapolate that because your knowledge is built about specific things, not about senior mental models. So, leaving aside titles, you have senior level skills that are not transferable to the market. And by the way, folks, if you want Bogden I to personally coach you and mentor you to the senior level, then check out the link in the comments. We have a free training where it's going to show you exactly how to get to senior in 2026, but also how Bogden I can help you get there to a clear road map, personalized mentorship, feedback and a huge community. Question number eight, I optimized my resume with AI, but recruiters still don't call me back. What's the issue? Well, this is very common today. People will feed feed their resume to the AI, it will write a bunch of keywords. There's usually two issues when it comes to resume. So number one would be it doesn't pass the ATS check, so it doesn't rank at the top. So, from the 300 applications that recruiters get,

they'll usually only look at the top of 100, and the ATS will kind of rank that. For the most part, most ATSs use semantic matching, and they also try to look at your track record and your job title. So, you want to use more or less the same job title. Don't change your resume for a job, just make it if you're a senior front, make a senior front end engineer resume. If you're in the market where they call you an engineer, add engineer to the title, if it's a developer, then do that.

So, that's number one. It's got to be ATS efficient. So, you got to get yourself into those first 800. Now, this has a lot of nuances. I'm not going to go in depth. AI kind of, you know, it's kind of possible of putting all the keywords in there. But then the second problem is that there's the the actual HR that will look at the resume and this is where most people fail. And the reason is they write their resume with AI and it's a wall of non-specific text that looks exactly like any other resume and doesn't say anything about yourself.

They'll be like, I love building usable interfaces and scalable systems. That's that's that's a description. You know, and a great engineer will be like, you know, I have seven years of experience building this system for, you know, 300,000 business users in the finance sector in the US, for example, or in Canada. Or the application I built was serving these two markets, this is a stack we use, this is how many transactions we have per day.

So, it immediately gets their attention and it shows evidence. Now, this is again, very complex, but in general, either one of these two, it's not working. There's a lot of online tools that can kind of get you to an okay score here. Well, where people fail the most, it's here because they write long resumes that nobody will read instead of going strict to the point and being human. One point I would like to add, it's the developers I talk to, whenever they hit this wall, the resume wall, they're like, oh, I know the market is bad, so maybe I'll apply again in six months, I'll stay in this job, etc., or I won't do anything, right?

Or maybe I do side projects, which is honestly the worst thing you could be doing. But I'll say, don't default on, oh, I'm not getting results because the market is bad. it's more competitive, yeah? It's not what it used to be in 2021. But the market is bad for marketing people. You know, when it rains, it rains on everybody. Like, but there are people out there signing offers right now. So the question should be, okay, the market is not great.

What are developers that are getting offers? We have plenty of them in our mentorship. What are they doing that I'm not, right? And like Bogdan said, it usually comes down to the ATS, to the HI. And also, a lot of people in this market, they have messy resumes, meaning, you know, there's been an unstable market. There's been like layoffs and some developers, unfortunately, they get hired. In a company that tells them, hey, you're going to be with us for 5 years, and then month six, they get the company can't raise money and they get fired.

And then you have this kind of zombie resume, right? And that's a problem for the ATS. But either way, you have to identify what is the issue in your resume? Is it the contribution itself, or is it something? Is it the story that you're telling, how those the titles and the jobs fit together? It's usually working with people, we see it's always one of those and once you fix it, you'll be amazed by the results.

Yeah, so people kind of they are the conclusion of how the market is based on the experience. And we have this great engineer we're working with, and she is, you know, she has a background in computer science, she worked for very big names in the in the industry, and she people were not calling her back, or when they would, should kind of, you know, not pass the phone interview. And the reason was all about how she would frame that experience.

We made a couple of changes and now she's interviewing with companies like Microsoft and Google in the US. Question number nine, my resume works. I get recruiter calls, but I get stuck in those calls and never reach the technical interview. What's wrong? Well, in this case, it means the resume kind of works, it works enough to get you the phone interview. But there's probably some red flags. And so it kind of looks good, but he called you up to check those red flags, and then he confirmed the red flags in the call.

A typical red flag is, okay, why are you leaving your current job? Why are you looking for something new? Or why why why did you apply to work with us? And a lot of people that have this kind of questions prepared. So they go in and they tell they go take exactly what they needed to reject them. And in this case, you know, recruiters are non-confrontative, they will just tell you, oh, wow, okay, that's great. And then they never call you back, they'll tell you we moved on with somebody that was a bit a fit for the role, whatever that means. So the number one thing you want to do now is to write down the questions they're asking you and rate one to 10 which ones are you feeling the least confident about. And it's very easy to identify this. Because you usually answer to the recruiter and they look at you and they're like, okay. That means they didn't bought the answer. They'll never confront you. They'll never tell you you gave a bad answer. But if the answer goes like, okay, and then they move on to the next question, that's the end. That means that the way you answer that was not convincing enough or you mentioned something that tipped them off. So you want to take notes of that and then kind of reiterate. Usually they don't like when you have a big gap that you cannot explain, if you tell them you got laid off in your last company. They'll assume that you were at the bottom of that company, that's why they laid you off. So you've got to frame things differently. If I got laid off for my last company, I would rather say something like, you know, this was a position, I've been it for a while. There was restructuring restructuring going on, they may be a really good offer. And I take it because I also needed some time off, I've been taking, you know, I've been chilling, I've been taking a sabbatical, enjoying that and now I'm back in the market, talking to a bunch of companies. That would be an example. Morgan, what I would say, looking at the software engineers we work with, the number one reason they fail in these calls. It's again, lack of preparation, because for a lot of engineers, software engineers, they love to get their hands dirty with code and see some code, but many of them, they hate editing a resume or redoing certain parts of their resume or writing actually writing down without AI, or using AI maybe to to inspire yourself. But actually pulling out a a Google Docs document or whatever and writing down the answer to those questions, and it's a pity, because you have to understand it doesn't matter how great, how prolific you are as a software engineer, if your resume and you don't get in front of the right people.

people who actually can hire you. So investing a few hours in building the best resume you can come up with and anticipating certain interview questions will save you rejections and will save you a lot of work because again, in this market it takes a lot of applications to get an interview in the first place and you're messing it up because you didn't spend a few hours just preparing better certain questions.

Okay folks, so here are the most common nine questions we see in our calls. Thank you, Bogdan, and we will see you folks in the next one.