Planning Your Approach

After you've oriented yourself in the codebase, form a plan — so you're the one making architectural decisions rather than passively accepting whatever the AI generates. How you plan, how much detail you need, and whether you involve the AI in planning itself depend on the format and the interviewer.

Two approaches to planning

The first is to ask the AI itself for a plan — using something like plan mode in Cursor or Claude — and then carefully vet and revise it before executing. This is faster, and works well when the interviewer is comfortable with AI for design thinking. You're still in control because you're evaluating every part, pushing back where it's wrong, and shaping it into something you fully understand and can defend.

The line to watch is vetting versus rubber-stamping. Pushing back on a plan you understand is control. Nodding along to one you couldn't have written yourself is what interviewers penalize.

The second approach is to sketch the class design and architecture yourself — more like a traditional low-level design exercise — and only bring in the AI for implementation. Some interviewers specifically want to see you do the design work and will view AI-generated plans as offloading too much responsibility.

Name the ambiguity before you prompt

Specs handed out in advance always contain at least one decision nobody made. What happens on invalid input, what an empty state renders, whether two edits can land at once, what "done" means for a half-filled form. The spec is silent, and both answers are defensible.

Resolve it out loud, before your first prompt. Name the gap, say which way you're going, say why, and say what you'd ask a product owner if one were sitting there.

The spec doesn't say what happens when the search returns nothing — empty list or a message. I'm going with an explicit empty state because the spec mentions a loading state, so it clearly cares about non-happy paths. If there were a PM here I'd ask whether that copy is theirs to write.

This carries more weight than it looks like it should, for a structural reason: two engineers watching you for an hour cannot read your diff carefully. Most of what you produce, they'll skim. Requirement judgment is the part of your thinking that never shows up in the code at all — an observer either hears it live or never learns you did it.

It's also the part that doesn't get easier as models improve. A better model writes the reducer faster; it still can't tell you which behavior the business wanted. And resolving the ambiguity visibly converts a guess into a decision: if you choose wrong, you chose wrong for a stated reason, which is a conversation. Choosing wrong silently just looks like you missed it.

Decompose the problem

Most AI-enabled interview problems have multiple phases. At Meta, the typical structure is fix a bug, implement a feature, then optimize for scale. At Rippling, you build features incrementally with the interviewer providing test cases along the way. Whatever the format, your first job is to break the problem into discrete steps and figure out the order.

For open-ended interviews — building from scratch — decomposition is especially critical because there's no existing code to guide you. Start by modeling your entities before writing any logic. Defining your data structures first forces you to think through the system before you touch the AI, and it's one of the most effective ways to stay in control. From there, follow a clear ordering:

For structured interviews, decomposition is usually more obvious since the problem statement often spells out the phases. But even then, within each phase, think about how much a step requires thinking versus how much is just implementation volume. Straightforward boilerplate is a great candidate for the AI with minimal direction. The parts that require careful reasoning about edge cases, data structures, or algorithm selection are the ones where you do the thinking yourself, then direct the AI to implement your specific approach.

Say the problem is a task scheduler with dependencies. A right-sized decomposition might be: model the task and dependency types, build the dependency graph from the input, compute the run order with a topological sort, then handle the cycle case. Each one is a single prompt-and-verify cycle you could explain on its own.

State your plan out loud

Once you have a plan, say it to the interviewer before you touch the AI:

I'm going to start by fixing the parser bug, then implement the search feature using BFS, then optimize it with a priority queue if we need to handle weighted edges.

That takes ten seconds and does several things at once. It shows you're thinking strategically. It gives the interviewer a window to redirect you if you're heading somewhere unproductive. And it creates a shared understanding of what you're trying to accomplish, so everything afterward is easier to follow.

Guide AI with your strategy

Your plan should directly shape how you prompt — one step at a time, with specific direction about your chosen approach. There's a meaningful difference between these two prompts:

Implement a BFS traversal of the maze, starting from the start position in the Grid class, returning the shortest path as a list of coordinates.

Solve this maze problem.

The second prompt is technically fine if you're the one who decides what "solve" means. The point is that on an interview, you decide the approach first. Be specific about data structures, algorithm choices, and how your code should interact with what already exists. If you know the codebase has a Graph class with an adjacencyList property, reference it. The AI will produce code that fits the existing architecture instead of inventing its own parallel structure.

You can be too specific. If you're dictating every variable name and implementation detail, you're not directing the AI — you're writing the code through it. Give the AI enough direction to implement your approach correctly while leaving it room to handle syntax and structure. That's also what gives the interviewer a chance to evaluate you, not just watch Claude type.

When the AI comes back with something, check whether it actually implemented what you asked. Models will sometimes swap your chosen algorithm for a different one, or add unnecessary abstractions you didn't ask for. Catch these deviations early and course-correct before building on top of them.

Know when to revise the plan

Plans should change when you learn something new — a performance constraint you didn't anticipate, a data model more complex than it looked, an interviewer hint that changes the scope. All of these are legitimate reasons to revise, and doing so shows adaptability.

Plans should not change just because the AI suggests something different. If you abandon your approach every time the AI offers an alternative, you're no longer driving. The test is whether you can articulate why the new approach is better for this problem. If the AI suggests a different data structure and you can explain why it's a better fit, that's a good pivot. If it suggests refactoring the entire class hierarchy and you can't say why that helps, that's scope creep.

Watch for the AI spiral. When a model doesn't know the answer, it often starts proposing rewrites, restructuring your architecture, or suggesting you start over from scratch. This can feel like momentum, but it's really the AI flailing. Interviewers want to see you recognize that pattern and interrupt it — step back, reassess, redirect.

When you do pivot, say so explicitly:

I realized the brute force approach won't scale for the larger inputs in phase three, so I'm switching to a heap-based solution.

That narration turns what could look like confusion into a demonstration of adaptive problem-solving — exactly how senior engineers work on real projects.