AI Coding Interview Questions for Software Engineers

Today we answer the top 10 AI coding interview questions for 2026, this is for frontend, backend and fullstack engineers. Bogdan, are you ready? Yeah, let's go. Question number one. Bogdan, could you walk me through your AI assisted development workflow? Sure, so before AI, my workflow looks pretty much like the traditional agile workflow where you have refinement, and then you do a bit of planning, and you kind of commit, and then you disappear for like two weeks, implement, you write some unit tests, but then kind of at the end of the sprint, you write some end-to-end tests.

If you do test-driven development, usually people would put the test at the beginning, but let's be honest, that was more of a, you know, meet than reality in most teams that you ever work on, people will test at the end, and then there's a code review and finally, you go to deployment. So that would be the traditional software lifecycle before AI, with AI, the implementation phase shrinks. So basically, the implementation it's a lot faster once you decided what to build, so there's a lot more refinement of planning that goes on.

I usually do this with a coding agent, I usually, for the most part, use cloud code, but I've been using Kimi lately, so I'd go in and ask it, okay, you know, this is what I want to build. Give me two or three versions, I would ask about trade-offs in terms of performance and state, and once there's a ref plan, then we'd go into the implementation part. The implementation stage shrinks, I guess there's other phases that get longer.

I can think of the code review phase, like how how does AI coding changes other parts of the development lifecycle? Yeah, so because the implementation phase it's much smaller and everybody in the team it's going faster, a lot of the effort it's focusing here onto the testing part, review and deploy. And the thing with the testing is you got to be careful because tests with AI are in most cases a false positive, you might get a case where you have 100% coverage and all the tests pass and the application is still broken.

Because the tests are usually written against whatever context the coding agent has. as and agents optimize they they over optimize locally. So, if you tell it just write test to make, you know, to cover the component, they will write test to cover the component 100%, it does not necessarily mean that those tests make logical sense. So, when it comes to review, that also becomes a lot bigger because pull requests are bigger.

So you can use an automated agent, you can have cloud code even reviewing the pull request, but I use a tool called Code Rabbit, there's a lot of them. Uh again, you can use any any tool you want, ideally it has an MCP and you get some comments on that pull request and then you feed this back to cloud code and you make it evaluate the suggestions and see does it make sense to implement any of those or not.

And that's when you start reviewing. So that's how you can save up time, let's say with in the review phase, which becomes a lot bigger because pull requests are a lot bigger and so on. You mentioned cloud code. Now, I'm interested to to know what are besides cloud code, what are some of your favorite tools and feel free to talk about open source tools, anything that you used on your daily workflow as a senior engineer.

So, I think it's the cloud code is probably the market leader. It's not, in our opinion, the very best tool and it's very flaky. I got so many times where you get a memory leak, just today, I got a memory leak where I had to shut down my whole machine. So, it's kind of flaky. I feel like the build it really fast, you can see that it was Vibe coded. It's not reliable at all, but it is connected to Arpus and it gives you the best performance.

So, I use cloud code, I also use open code and I use Kimmy, which I kind of love. So, the Kimmy model is not as as good as Arpus, but the interface and the user experience is a lot better, it's pretty stable. You just got to be careful because sometimes Kimmy would go in and and commit things without telling you and even commit on the master branch. So you got to make sure that before you introduce any of those, you you kind of close your master branch for example, so it doesn't go ahead and makes deployments without telling you.

Because sometimes it will just go ahead and be like, oh yeah, sure. straight to production. So that's what I was in terms of coding agents. These are all TUIs, terminal user interfaces, which are in general a very poor way to interact with code. I know people are pumping them up and AI companies are like, oh, this is the best user experience. It is not like writing text and getting text back is probably the worst way to understand your code base. But the reason why probably on topic did it is because it's much simpler to build a terminal user interface, which as I said, is very poorly built, the one in Cloud Code. But it's still simpler than building like cursor, for example. Building a full IDE. But I use this in this phase, in the implementation phase, in the planning phase. You can use a coding agent. When I go into review mode, then I'm fully working with cursor or in my case, I use Z this days, which is kind of an AI powered IDE. Because I need to see the code and I usually use the the ID to refactor. Do you also use any AI powered tool for code reviews? Yeah, so as I mentioned, code rabbit, this goes straight into my pull requests that are open and it's connected to your coding agent. And then it'll kind of, you know, it'll raise some issues, then you can choose if you want to fix them or not. It's it's kind of need picking and it's not 100% accurate, but it helps you if Cloud Code miss edge case or there's like unnecessary again, if there's anything obvious, it'll catch it early. And then you can push that back to cloud code, review it yourself and then push it again. So that's what I use. So whenever I code review, uh I would start with number one, review the test first, and then number two, I would do static analysis. So just making sure that there's a tool called follow that will, for example, check for code duplication, function length. and you know, module that that code. There's a lot of dead code in in AI coding and I would check if the code quality is being regressed. with the pull request, they they have an overall code quality metric and you can check if with this, you know, with this commit you are merging with this pool request you're trying to merge. Are you decreasing the the overall? Code quality, they also check for a side

cyclomatic complexity and you can do like an overall analysis and then go function by function. And they do have an MCP, so you can feed that back to your cloud code, but you do need to manually review this because this tools again, module models optimize over optimize locally. So you tell them, okay, reduce cyclomatic complexity and then maybe they they do it, but they break the function itself. So it's very hard for them to have like competing competing goals.

They'll just go in and and single on the one thing you tell them. And then we have also dynamic kind of dynamic quality, right? Which is basically running tests. So here I would look at the end to end first, make sure they pass. And then unit tests and unit tests are mostly what I give you first. If I see that the unit tests are kind of okay, I see that there's no fake positive or empty tests, which can happen, then I'd go into actually kind of code review uh and have a have a hery there to go to go faster.

Because you cannot possibly review every single thing. This brings me to my next question, which is we know AI generates a lot of code very fast. Right? So, especially when we talk about production code bases where we need to keep a stable version of the artifact of the code base. Right? What kind of intermediate data structures, processes, or tools you use to make sure you get stable, consistent output from AI coding?

Yeah, sure. So, it very much depends on the domain, is different from the back end to the front end. But in general, uh I think my mindset has changed from reviewing components, right, to reviewing the way we build components. So, I care more about the factory of code in the beginning, then the code itself. So, I usually usually you want to inspect components, you want to inspect functions to see is there any way that you know, is there anything that the agent gets repeatedly wrong?

And then adding kind of rules or different systems to make sure it doesn't repeat that. So, when it comes to code review, for example, in the front end, going back to your intermediary question, the first thing I'll look uh at it's the state, and then I'll look at the component. instruction. And it makes sure you know how to find this in your framework of choice, I use React for most of my stuff, and they have the extension, I go in, I look at the component structure and I look at the state.

I will also look at the blast radius of uh a change. So that means if in this feature where I'm making a change to like anything that's global state, I will pay attention attention to that specifically. Because state it's really where most of the problems will come from. And if I know what choices the model made with state, then I can predict the the component structure. And then I would finally, so in the front end I would look at that, and then I'll probably run like a performance analysis, depending on the component it can be onload or on user action.

I kind of looking for the core web vitals. Because that will tell me if it made any mistakes with rerenderings, or if if the model didn't, you know, like the code, the components is creating are they are they well cached and so on. And then finally, I will do like an, you know, component by component analysis, for the most part, I look at the logic in the component. That's that's basically the state transitions.

Because that's where the the juicy part is. I I usually look at the HTML markdown and the CSS style. And what I'm looking for there is, is there any quality drift, like in general, but is there any architecture drift? Architecture drift basically means that you had an architecture that you decided at the beginning of the project. But then because models optimize locally, sometimes you tell a model build this component, and then they start taking shortcuts, for example, a good example and a very common example is you're using tailwind.

And so when you have tailwind, you have this atomic classes, right? So you use text, excel, right, to create like, let's say text excess, that would correspond to, I don't know, like 12 pixels, right? But then the model kind of forgets that is like, no, whatever, you you ask it to reproduce a layout and it will just add text, right, text, and then like 12 pixels, high coded, right? And there's a big difference between these two, because this right here, globally, it will be a minimal change.

Like with one line of code, we can update the whole code base. Whereas this, you know, you need to go to the whole code base and figure it out. And this is just an example, but there's so many of those code smells. Because again, models, like especially the latest ones, you know, Opus 4.7, they were overfitted to make things look good. But they do that at the price of composability, usability. So a lot of people are comparing models with junior engineers, I I don't think they act as junior engineers.

Sometimes they do things worse because they over optimize for that one goal you gave them. So this is one code smell. And then in the back end, we have other intermediate data structures. But for the most part, in the back end, you want to program against APIs. So the first thing I would look for, it's number one, you know, if we're using REST API, okay, what are the endpoints? What are the different methods we have?

Number two, I will look for modularization, which models are pretty bad at, so you end up having big files, they declare functions inside functions. And I'll go one by one, extract those functions into logic and then write unit tests on them. And then I will look at the database schema. If there's any changes in the database schema, you want to review those. If if the model is writing migrations, you want to review those.

Because it's pretty bad, unless you direct it, it's pretty bad at building like a scalable database, and it's usually creating like very bloated database structures. And then of course, you're using usually most of the times an ORM. With the ORM, you translate like if you have a bloated ORM declaration, that will result in very complex SQL queries, and then you get latency. So everything that has as I mentioned, like a huge blast radius, like it's very much critical, and in that case, you know, in the in the front end case, it's usually state.

In the back end is the database schema. Those things I definitely review by hand and sometimes I even write them by hand. And finally, uh, I use sequence diagrams, which you can instruct the model to write those and so you just tell the model, okay, give me the sequence diagram for this endpoint. This is that in in the swim lane and it kind of condenses, you know, thousands of of files into a single diagram where you can identify immediately if something is wrong. You can check, you know, retry mechanism, you check your sequence diagram against your rest API declaration. So, what happens is you have a sandwich structure. Basically, you know the API schema and you know the US API, and you more or less know with the sequence diagrams, what happens in between those two. So any mistake that the model will do at this point will be very much localized here. And so, if it starts making mistakes, number one, you're your application will be fine. And number two, that's when you go into code style and you try to make the model write kind of better code, you instruct it to modularize better. But again, because those those things are very stable and you try to have the least amount of changes in here, then your PRs are much smaller and you don't introduce more bugs than than you add. If you don't do this, and I've been also trying to vibe code where I wouldn't pay attention to these things. It got to this point where every time I would extend or fix a bug, the model will end up breaking something else. On to the next question. But you did mention a bunch of AI code smells. Like what are the most dangerous AI code smells you found when using an AI coding agent like for example, cloud code? So, again, code events are very domain dependent. But in general, there's a lot of architectural drift and and quality drift. The the the number one most common is it's really bad at modularization. So, modularization is missing. So you get in in the front end, it would write 15 components in a single file and it will be just fine with that until you go in and you start thinking about it. Number two would be over generalization. So what happens is people are like, okay, can you write clean code or can you make it more reusable? And they don't really like go in and understand why is the code not reusable? And what the model does in this case, it's to add abstractions too early. Okay?

programming that before you get the guy, you must get wet. And basically what this says is, you know, you don't need to apply, do not repeat yourself. If you're just using the same logic once or twice. You need to wait until there's a lot of repeated logic. But if you tell the model, hey, write clean the code, it will just go on and abstract things way too early. So, for example, let's imagine this is a very common mistake it does.

I have a form and it has five fields, right? So what the model would do, if you tell it to write like reusable logic or testable, it will go ahead and create an array where it has like those fields, it takes them away and do a dot map and then render those fields. But the problem with this is that in most component frameworks, this is dynamic, it's very high to cache, it will break your JSX caching and internally it messes up with the React fiber, for example, in React.

So you end up getting a a way worse performance from your from your application, but also it's just harder to debug. And so for five fields, you don't need the generic way to render the fields. Unless you're getting those fields from the, you know, from the database or something that dynamic, you don't know them, you're better off just writing JSX6. It's just a lot better, it's easier to read, it's easier to cache.

And so that's one example, okay? In the back end, the most common example I saw, it's code duplication. And then it kind of messes around with function scope. So you'd have it would if it needs some utility in a in a in a rest end point, it will then create a function just for that rest end point. It wouldn't put that in like in a shared library where it is very much reusable. So modularization over generalization, a lot of code duplication, and then we have like false positive testing.

So basically here it will write test, just for the sake of writing test or you have empty tests, or you have tests that doesn't make any sense, just to fill up like the test coverage. Gordon, let's say you are handed a piece of AI written code, and let's think about usually these pieces or these PRs that were written by AI are pretty big and may they encompass several files. So do you have a mental checklist when reviewing AI code, and how does that mental checklist looks like? Yeah, so as I mentioned at the beginning, when it comes to code review, in the front end I'll go for the state and then component structure I'll check if there's any major changes, major in the terms of impact. So I will change again anything about global state. And is there any if there's any architectural drift? I'll look for example at what are our conventions about CSS? Are we using atomic CSS, or are we using component CSS and then make sure that the model follows that because sometimes they over optimize locally and they'll go away and you end up with three strategies for CSS in your code base, which doesn't really make any sense just because models don't really think, they just have a goal and they they're optimized and they finished. And then somebody else, maybe it's on a feature branch and they do something completely different. It makes total sense in their in their local environment, in their local context that it has, but then it doesn't really follow follow the the architecture constraints. And I know people are like, well, just use a skill or add more stuff to your cloud.md file and they try to do that. But in the end, when you go into a bigger context window, the model just starts hallucinating. It's hallucinating here and there. So it's always much better if you're in touch with your code base. So that's number one for the code review. Then I will give you the test first, review the test cases, and then go on to the state, logic and so on. And in the back end pretty much the same, I'll look at the rest API first, are there any changes in the API, are there any changes in the database schema? Those ones I will check manually. And if those things are are okay, I just skim through the rest of the code and I'm not looking for like I don't analyze the code like line by line. I'm looking for code styles. For example, I'm looking is it using really immutability or is it just declaring local state and changing that state? It tends to do that a lot where you have a lot of you know, let variable and then they modify that variable in place, or is there too much abstraction or you know, is it is it is there any duplicated logic? And there's tools where you can analyze this, you can analyze your duplicate logic, your soclomatic complexity and kind of figure out. It's the model making

making you and mistakes and then try to kind of uh add some rules and bias it that was not making that or just correcting it by hand. Our next question about it, how do you choose when looking at the code base or an application? How do you choose what to delegate fully to the AI, what to only verify and what to build yourself? Um sure. So as I mentioned, it's all about the consequence, the blast radius of that mistake.

So of course this is project dependent, if the project is not mission critical, then you can freestyle it a bit more. But if it is mission critical, I would check, okay, are we changing any core data structure in the program, in the front end, are we changing state or are we changing anything in the database and the rest APIs. That's the first thing I would check. Because the blast radius of a mistake there is huge.

You can mess up the whole application, you can break your API and people that depend like clients that depend on that API might then be affected. So that's the first thing I would uh I would check. And what I delegate is the things in between. So if this would be as I mentioned the database and this is my API, then I can just delegate the the writing the declarative code and I just tell the model a certain style because it's pretty good at, okay, this is the API, this is the database.

It's pretty good that filling that gap, what the models are pretty bad at is if the API has a certain shape, then they'll try to replicate that in the database. But the way we store things, because the the constraints of database storage are totally different from the constraints of APIs. So usually, if your API looks exactly like your database, um, you know, kind of structures or columns, then you you did something wrong.

Because there's there's no way that you could fulfill both of these constraints with the same shape. And that's why as a backend engineer, for example, you're going to spend most of your time. Meanwhile, the AI kind of closes the gap once you have these things in a good shape and you're happy with it, then AI can really easily close this gap. Give you a SQL diagram that you can really fast analyze.

is the monetization okay and trick for duplication. So if I understood correctly, everything that has to do with data and it's sensitive, you would at least verify, um, and all the others the stuff in between you can delegate. Now, what is the stuff that you still build yourself? I would build myself anything that I'm not familiar with. Uh, a recent example would be I was building this kind of SVG and I tried to do it. I was building this graph with SVG where we show kind of it's like a HD display where you show different skills. And it was impossible to get it right with AI. But also the problem is, uh, you know, you have all this specific logic where, you know, it's like SVG based and if you don't understand how canvas works in HTML and how they handle, um, SVG is, you're just kind of shooting in the dark. And so that's the opportunity where you say, okay, well, now that I have all this time in my hands, let me go deeper into something that usually I'll just skim through. So I would go in and really learn that. Things I delegate could also be things where they're not complicated, but maybe I don't know the syntax because I don't touch it a lot. For example, you want to write a Docker file. Yeah, you want to write a Docker file, then probably you don't remember exactly how to write it, but you know what you really what you want. So you can use AI to that, but make sure you review everything. Awesome. On to the next question, Bogdan, you are a senior engineer and you notice a junior developer team, it's pushing huge pull requests. Definitely written they are written with AI, okay? Now, this generates a lot of work, review work for you and the team. How do you deal with this?Um, so that's, yeah, that's pretty common these days. because poor requests are pretty big. Um, I would try to review it, uh, kind of skim through and if I find more than five code smells, then I would directly reach out to the person. I'll start the code review right there because I'm doing the work for them at this point. You know, like why would I why would I do this? I'm I'm basically QAing your code. So, you're ultimately responsible and if you're already committing code smells to be reviewed by me,

That's already kind of professionally irresponsible. So I would eventually kind of talk to them and be like, hey, I saw your pull request, there's a couple of code smells I wanted to just discuss with you, let me know when you have time available. And so, the thing is when you bring this face to face, people have to face the responsibility of pushing unreviewed code. And there's there's a social penalty to it. You cannot just push a a huge code a huge pull request to me, and then expect me to do the work for you. Because then what? I will drop some feedback, you're going to feed that back to cloud code, and you're basically just a proxy to cloud code. So I would bring them in and be like, okay, let's have 30 minutes, have them explain the code. If they didn't do any thinking, they probably can't explain that. It's going to make them look bad. And again, it's in private, so they don't lose face, they can recover for that. But they will get a bit nervous and ideally they will they will change that. And I would also try to go into the team and propose ways to make pull requests as small as possible. So, a big pull request, it's assignment of poor engineering. That's really the culture. The way you do this is usually you have, you know, you make sure you have your your prettier settings, kind of your your linter, your code formatter, they look the same, so any difference in the product, it's a very small difference in the code. And the other way you do that is you kind of have this as a culture, you're like, hey, you know what, if you're pushing a a big pull request, it's because you you didn't think enough about expanding the codebase. So, again, in this new age, speed, it's not scares. Quality, it's scares. So the problem with coding with AI is that in the beginning, right, it's if you look at the speed of the lingual feature, and it's always the same, it didn't change in the last two years. You always feel like you're going to be super fast. So speed goes like you start here, right? You prompt it and you get a feature. But then you start kind of fixing the bugs, you start fixing all the other issues, you realize there's part of the code you have no idea what it does, so you need to read it, and then speed kind of goes very low, if you don't do it well. And then with manual coding, it used to be like this, where you start

very low because you need to set up everything, there's no speed, but then you're very fast. And ideally, what you try to do as a AI powered engineer, what I would recommend is to try to find the intermediate here, where you kind of start here because you still do a lot of manual coding, but then they decrease, it's much better. And you're more constant. It's kind of a mix. Understood. Would you add a fixed limit to like lines of code per PR, maximum lines of code or anything you implement quantifiably at code level, or not?

The thing, yeah, that very much depends on the code base, too. Because 1,000 lines in a backend service are much harder to review. In my personal experience, then 1,000 lines in the front end where they might just be like a JSX layout where every line it's closing and opening a tag. So, not all code changes are born equal. Obviously, whenever they change any infrastructure, I would call it out and if they if they make obvious mistakes, like I mentioned the CSS thing, I would immediately stop it.

I would say like, look, if if this is the mistake already in these three files, you coded this with AI, so probably the mistake has propagated. It's not like a human review where you'd be like, well, if I find a mistake in the first file, it doesn't mean it's going to be there in the in all the other files. But here with AI, I don't need to review all your code. I'm just going to sample it because again, what I'm checking is, are you good at making the model create high quality work?

And if, you know, if 25% of your work is bad, then most likely the rest is just a projection. So, again, you can set a limit, you can be like, okay, in the front end, it's 5k limit in in in the back end, it's 1,000k. But it's it's kind of there's no silver bullet. If I find code smells, that's the only thing I care. If you're already making code smells, then we need to talk. Because it's already trash, I don't care how much trash you produced.

Like the the more trash you produce, the worse. So the next question, Barton, in your experience, is there a difference when you use AI coding on a green field or a brown field legacy code base? Yeah, so I feel like a lot of people that are talking about AI coding are doing so Greenfield project and they feel like they're so productive because they get you know, they get something done very fast, but there's very little value there if you don't have real users. So, because you don't have real users in Greenfield, you can go much faster, you can validate if the application looks like what you wanted to achieve and then you can heavily use AI until you get to the point where okay, you get a bunch of users in and then you start king about quality because users get frustrated and they bounce. When you talk about Brownfield, we're talking about legacy or corporate, the problem there is that the most important thing is what is the consequence of a production bug. So if you're attacking insurance, banking, healthcare, the consequence is very expensive. So, that's the biggest fallacy right now, is that people think, well, code is very cheap. Yes, but coding the wrong thing is very expensive and that's why you need verification because the cost of verification it's less than the cost of a production bug. And whenever the consequence of a production bug is high, whenever you are looking at payments or transactions or using customer data or patient data, then in those cases even if you generate the code with AI, you'll have to review it and refactor it yourself, you have to test it, you have to read the test yourself, you have to run those tests, you have to test manually. So, in those cases, the productivity increase it's minimum. Maybe you're 10%, 15% faster, if anything. And just to bring the point home, when you are building something from scratch and you're just looking for that first version, proof of concept or MVP, you can be more in the spectrum of vibe coding where you're just giving the prompt, giving it more or less rough architecture choices and have the model doing all the coding. But when you are going into more of a legacy code, then I would advise you use a lot more for the traditional software way where you go through the code. You can use AI for read only, when it explains you the code base, especially if it's legacy, it can help you with that. But you still have to go a bit slower because in the end that will actually

to make you faster. Next Christian, let's say you are in the middle of delivering a very critical feature, a big feature, and you just ran out of tokens. What do you do? So, that actually happened to me the other day. And to give it a short answered, uh I tried to see where where are we in the in the code changes? How far is it? If you have another coding agent that you can usually switch, I would recommend switching to a coding agent that has a different model. So you don't depend on the same company. I was using cloud code and I switched to Kimi. Kimi it's a Chinese model, so maybe your company doesn't allow you to use it, but I find it to be super reliable. By the time my limits were back, I I just stick to that one to Kimi in that in that case because it was a lot better. But let's say you have no access to any to any coding agent. What I would do then it's it depends on the time pressure. I would use the time to really on board myself on the code changes that it made so far. I would review the planet head and see if I can bring it home myself. And if not, I would switch coding agent. It's always good to have two of those because you never know. They they are very unstable and you get flaky results. And you don't want to have any kind of vendor locking, understood. And final question, what do you do while cloud code is coding? So, whenever the agent goes ahead and does work, I usually either review another poor request that I have open or review tests. Or I go in and read documentation of something that I'm, you know, if we see a library, a new library that we added. And I know that I'm not unboarded, then I can use that time to upskill. So, it's not like you want to stay at the agent and and just do that. Or you can spin up a pallan agent and then use it to explore the database. I know there's a lot of flexing right now in Silicon Valley with people having 10 agents at the same time. I would not recommend that that's just another, you know, Silicon Valley flex. When you have so many agents, you end up just kind of shipping whatever the agent does. So, what's the point, right? Because if if you're really going to have no supervision, then just give the agent to the product person and have them write tickets and good luck with that.

I I generally feel like they're going into into a direction that's not feasible, but it's kind of like this flex. I usually work with one or two agents Max. Whenever I try to have more, the code quality, the gift will be huge. Awesome. Thank you, Bogdan. By the way, folks, if you're interviewing right now and you're a JavaScript engineer looking to get to senior and improve your skills, the best way to do that is to first find your technical gaps.

Check the links in comments. We give you a free technical assessment that you can take to find that out and if you're training on how to get to senior in 2026 and beyond. Also, let us know if you like the format of this AI coding interview questions and we'll see you folks in the next one.