The new interview round in every SWE interview

I have a lot of friends and old coworkers interviewing right now, and in addition to the standard interview loop (OA, Phone Screen, LC technical, System Design Technical, HM behavioral, Super Day), people are now additionally expected to complete an AI-coding round.

This is BRAND NEW, so if you can master it now, you’ll have a leg up on the competition. I’ve aggregated the best advice I can find across the internet and from my friends who have completed this into a fairly simple recipe you can use for success.

Before you actually implement this strategy, you have to understand what type of AI coding interview you’re in. Some are trying to see if you can build an entire production app in a few hours, and some are trying to see how you’d use AI to add a new feature to a sensitive production code base. MAKE SURE YOU UNDERSTAND THIS before you start. If you try to build an app like you’d make a change to a production system, you won’t finish the interview. If you build the change to a prod system like you’d build an entire app, you’ll seem like you don’t care about quality. Usually you can figure this out ahead of time. Startups tend to want more of an entire app, big tech tends to look for a single feature.

Single feature AI-assisted interview:

1. Read the codebase and understand what you’re looking at BEFORE you start using the LLM. I can’t stress this enough. It’s important to orient yourself inside the codebase so you can understand what changes the LLM is actually making when you go to approve them.

2. MAKE THE PLAN YOURSELF. PLEASE do not just copy paste the interview question itself into the LLM and tell it “please build this”. This is a surefire way to fail an interview. Remember, someone is going to read your prompts and evaluate them as well. Start by constructing a high level plan based on the info you have available, then work with the LLM to refine the plan. You can use a prompt like “I’m planning on implementing X feature in Y part of the codebase. Use the existing Z methods defined in P file unless you see better methods. What do you think of this plan?”, then go back and forth with the model on the plan until you feel confident, then start the implementation.

3. Work in small chunks. Way too many people get lost in the sauce with AI and try to one shot everything. This almost never works and makes it really easy to make a TON of changes you can’t explain. Instead focus on making small changes to your codebase piece by piece and validating those features with both testing and a manual check. An added benefit here is you can actually understand what changes the LLM is making and explain them to an interviewer. This is nearly impossible if you let it just go to town and make a ton of changes.

4. Be able to explain what you did and WHY. Too many people let AI take the wheel and just do whatever it wants, and have no idea how to explain it. If that’s what they wanted, why would they even need a SWE? Be able to explain why you implemented it the way you did, even if all you did was take the LLMs suggestions.

Entire application interview:

1. Make a DETAILED plan. You generally are time constrained on these interviews and need to move very quickly to complete them in time. That does not mean you should not plan and start shipping, it actually means your plan is that much more important. Read and understand the problem and put together INDEPENDENT GOALS that the LLM can work on. This is very important for the next step.

2. Use subagents. This is one of my favorite paradigms in agentic coding. If you’ve designed your goals correctly, you can dispatch multiple sub agents to work on the goals in parallel. This drastically speeds up development. Just make sure you have a loose idea of what they are doing, and that the parent agent (usually the most powerful model) is validating their work with an E2E test (I usually use a browser MCP like playwright for this).

3. Test manually. An LLM typically will be able to fix major errors in an E2E test with browser automation, but they frequently miss UX bugs or take shortcuts to make things work. I usually spend more time manually testing the product than I do reading the code.

4. Be able to explain what you did at a high level. In these types of interviews, there’s no way you can explain specifics of the code, but you can explain the general file structure and architecture. Make sure you are clear on this and why it’s implemented the way it is.

Happy interviewing.

P.S if you want to ask me about interview prep or any other specific questions, you can join my private discord server through Devmaxx.