Instacart Senior Backend Engineer Interview Experience — A 5-Part OA That Was Basically Vibe-Coding With Claude

I've compiled some tips I saw online and added my own experience.

The deadline was two weeks. What surprised me was that this OA was completely different from the Instacart OAs I had seen discussed before. It was a 5-part assessment, and the overall format felt more like "AI-assisted full-stack feature implementation" than a traditional coding assessment. Time limit was 90 minutes.

The assessment had 5 rounds:

Round 1: Talk to an AI PM to gather requirements

The first round was a chat with an AI PM. The prompt was about a book/library management system where users felt the frontend table was too long and hard to use. After chatting with the AI PM, I figured out that the requested feature involved adding two dropdowns and a text input for search/filtering. However, some details still felt unclear, such as the exact dropdown labels, wording, styling, etc. I spent quite a lot of time asking follow-up questions and taking notes because I thought maybe the notes or requirement-gathering process would be part of the score. In hindsight, this felt like a waste of time.

Round 2: Use Claude Code to implement the feature

In this round, you are given a project directory and need to use Claude Code to implement the feature from Round 1. You are not allowed to directly copy and paste your full conversation with the AI PM. The requested feature was basically a search/filter UI for the library/book management system. The PM had also mentioned that full unit test and integration test coverage was expected. Claude Code was extremely slow. When submitting, it tried to run all tests, and at one point the whole page became stuck. A lot of my time was spent waiting for Claude to respond.

One important note: remember to commit your code after finishing a feature. CodeSignal was buggy for me and seemed capable of losing code.

Round 3: Debugging task

This was the only round where the requirements were clear and the result was easy to test. The prompt said that a value on the metrics page was incorrect and needed to be fixed. I applied for a backend role, but the frontend was written in JS, so at first I thought it was a frontend bug. After looking into it, the actual issue was in the Python backend. The bug was that the backend was returning results before correctly filtering them — the metrics were being computed before the filter was applied. The fix was basically moving the metrics-calculation lines to after the filter was applied. I had never used FastAPI before, but after staring at the code for about 5 minutes, the bug was not too hard to identify.

Round 4: Talk to the AI PM again for another feature

This round was another requirement-gathering chat with the AI PM, but it was much more complicated than Round 1. The feature involved a notification system in the library management app. The requirements included both frontend and backend changes, idempotency, and full test coverage. The specific feature was roughly: patrons should receive notifications 24 hours before a borrowed item is due and again when the item is due. Another feature was that a patron can place a hold on an item. When the item becomes available, patrons who placed holds should be notified. Multiple patrons can hold the same item, and when copies are returned, the system should notify the first N patrons in FIFO order. The logic was much more complex than the first feature, and you have to extract the details by chatting with the AI PM.

Round 5: Use Claude Code to implement the second feature

By this point, I only had around 30 minutes left, so I was basically out of time. I tried running two Claude agents in two terminals to speed things up, but they ended up modifying the same folder/files and broke the whole project. I spent the last couple of minutes just trying to get the page to run again and submitted something incomplete.

Another important note: the work from Round 2 does not carry over into Round 5. Also, terminal errors could not be copied and pasted into Claude, which made debugging even more annoying.

Overall thoughts:

This OA felt very strange to me. I applied for a backend role, and the job description said C++ was acceptable, but the OA had no C++ option at all. It felt much more like a full-stack "vibe coding with Claude" assessment than a backend engineering assessment.

The scoring criteria were also unclear. Other than the debugging round, I had no idea what exactly they were evaluating. Was it requirement gathering? Notes? Test coverage? Claude usage? Product sense? Speed? It was hard to tell.

My advice:

Spend less time chatting with the AI PM than you think you need to. Get the core requirements, then save as much time as possible for Claude Code implementation. Commit after every completed feature because CodeSignal can be unreliable. Also, be prepared for Claude Code to be slow.

Overall, the experience was pretty bad. It felt like it mostly tested Claude Code familiarity and typing speed rather than backend engineering ability. I'm probably not expecting to move forward.

A few more things I picked up along the way:

• Time overall was very limited and tight.
• During the AI-coding stage, the codebase is large and not easy to read — my advice is to just have the AI search for the files that need to change and get straight to work.
• Launch multiple terminals at the same time — one handles the business logic, one handles writing the tests.
• I personally used the Mac's built-in dictation (speech-to-text), which let me type especially fast.
• While the agent is running on one question, you can work on the other question at the same time. I tested this myself — you can work on multiple questions at once without the terminal agent for each one interfering with the others.
• In theory you're not supposed to feed your chat transcript with the AI PM directly into the AI, but there's no hard blocker stopping you from doing it.
• Final score was 844/1000, but I got rejected a few days later.