Instacart Software Engineer Interview Experience — A Full-Stack CodeSignal Challenge With No Tests to Check My Work

I recently completed an Instacart CodeSignal assessment that was very different from the usual LeetCode-style rounds. It was a full-stack repository-based assessment, and some sections required me to have conversations with an AI "Product Manager" before making changes. Very annoying. Because unlike other CodeSignal rounds there are no tests to test against!! So I had no idea how well I did and unsurprisingly for me, I didn't pass.

The entire assessment used the same Library Lending System application, and the sections were connected to each other. One part would establish requirements, the next would have you implement them, and later sections could expose bugs or consequences from earlier changes.

Rough structure

Example: item search and filtering

One part involved extending the existing /api/items functionality. The requirements I ended up working with were roughly:

• Search items by title
• Case-insensitive partial matching
• Filter by item type
• Filter by availability/status
• Combine multiple filters using AND logic
• Return all items when no filters are supplied
• Perform filtering on the backend
• Update the frontend with search/filter controls
• Add tests for the new behaviour

Conceptually, the API ended up looking like:

GET /api/items?search=harry&itemType=book&status=available

And the backend needed to dynamically construct the query depending on which parameters were supplied. For example:

const where: any = {};
if (search) {
  where.title = {
    contains: search,
    mode: "insensitive"
  };
}
if (itemType) {
  where.itemType = itemType;
}

One complication was that availability was not necessarily just a simple database field, so you had to understand how the existing application calculated whether an item was available. The frontend also needed to send the selected filters to the backend rather than simply filtering the fetched list locally.

Tests would cover things like:

it("searches titles case-insensitively");
it("filters by item type");
it("filters by availability");
it("combines search and filters");
it("returns all items when no filters are supplied");
it("returns an empty list when nothing matches");

Another feature: notifications

Another part involved adding notifications to the lending system. There were two main areas.

Hold notifications:

• Notify a patron when a held item becomes available
• Respect hold queue priority
• Check whether the patron is eligible
• Take overdue items/account status into account
• Avoid duplicate notifications

Loan reminders:

• Notify patrons when a loan is approaching its due date
• Notify them when a loan becomes overdue
• Avoid sending duplicate reminders

This required changes across multiple layers, including persistence, backend business logic, API endpoints and frontend notification UI.

AI coding agent

The assessment also expected you to use an AI coding agent. The interesting constraint was that you were supposed to create your own prompts for the agent rather than simply copying the challenge requirements into it. So part of the assessment was effectively:

Understand PM requirements
↓
Inspect existing repository
↓
Create a useful coding-agent prompt
↓
Review the agent's implementation
↓
Run tests
↓
Find missing behaviour / bugs
↓
Iterate

That made it feel much closer to working inside an existing codebase than a normal coding challenge.

The part I found most unusual

All of the existing tests were already passing. I'm used to interview exercises where the workflow is something like:

failing test
↓
find bug
↓
fix implementation
↓
test passes

Here, the repository started in a working state. You instead had to figure out:

What did the Product Manager ask for?
↓
What behaviour does not exist yet?
↓
Where in this repository should it go?
↓
What new tests should exist?
↓
Implement it without breaking existing behaviour

In retrospect, one of the best approaches would probably have been to convert every statement from the PM conversation into an explicit acceptance criterion and then create failing tests for those requirements before touching the implementation.

Overall, it was much more of a requirements → existing codebase → AI-assisted implementation → testing/debugging exercise than a traditional CodeSignal algorithm round.