Practice/Anthropic/Recipe Manager (Online Assessment)

Recipe Manager (Online Assessment)

CodingMust

Problem Overview

You are building an in-memory recipe management system for a cooking platform. This is a multi-level online assessment problem that progressively adds features:

• Level 1: Basic CRUD operations (create, read, update, delete)
• Level 2: Search functionality and sorting by ingredient count
• Level 3: User authentication and permission validation
• Level 4: Version history and rollback capabilities

Each level builds on the previous one. Subsequent levels unlock when you correctly solve the current level.

Time Limit: 90 minutes

Important Notes

• Start simple and extend your data structure as needed for each level
• Recipe names must be unique in a case-insensitive manner
• Focus on correctness first, then optimize
• Test your code thoroughly at each level before moving to the next

Level 1: Basic CRUD Operations

Implement a recipe manager that supports creating, retrieving, updating, and deleting recipes.

Operations

add_recipe(recipe_id, name, ingredients) → bool

Creates a new recipe with the given ID, name, and list of ingredients. Returns True if successful, False if the recipe ID or name already exists (names are case-insensitive).

get_recipe(recipe_id) → dict | None

Retrieves the recipe as a dictionary containing id, name, and ingredients. Returns None if not found.

update_recipe(recipe_id, name, ingredients) → bool

Updates an existing recipe with new name and ingredients. Returns True if successful, False if the recipe doesn't exist or the new name conflicts with another recipe.

delete_recipe(recipe_id) → bool

Deletes the recipe. Returns True if successful, False if not found.

Example

` manager = RecipeManager()

manager.add_recipe("1", "Pasta Carbonara", ["pasta", "eggs", "bacon"])

Returns True

manager.add_recipe("2", "pasta carbonara", ["pasta"])

Returns False (name already exists, case-insensitive)

manager.get_recipe("1")

Returns {"id": "1", "name": "Pasta Carbonara", "ingredients": ["pasta", "eggs", "bacon"]}

manager.update_recipe("1", "Classic Carbonara", ["pasta", "eggs", "bacon", "cheese"])

Returns True

manager.delete_recipe("1")

Returns True

`

Requirements

• Recipe IDs are unique identifiers (strings)
• Recipe names must be unique in a case-insensitive manner
• Store original casing provided by user
• When updating, a recipe can keep its current name (even with different casing)

Clarification Questions to Ask

• Should we validate that ingredients list is non-empty?
• Can recipe IDs be any format, or are they always numeric strings?
• Should we preserve the original name casing when storing?

Level 2: Search and Sorting

Add search functionality with specific sorting rules.

New Operations

search_recipes(query) → list[dict]

Searches for recipes where the name contains the query string (case-insensitive substring match). Returns a list of matching recipes sorted by:

1. Primary sort: Number of ingredients (ascending, fewer first)
2. Secondary sort: Recipe ID (ascending, numeric if possible)

Returns an empty list if no matches found.

get_all_recipes() → list[dict]

Returns all recipes sorted using the same rules as search_recipes.

Example

` manager = RecipeManager() manager.add_recipe("3", "Caesar Salad", ["lettuce", "croutons"]) manager.add_recipe("1", "Pasta Carbonara", ["pasta", "eggs", "bacon", "cheese"]) manager.add_recipe("2", "Simple Pasta", ["pasta"])

manager.search_recipes("pasta")

Returns [

{"id": "2", "name": "Simple Pasta", "ingredients": ["pasta"]},

{"id": "1", "name": "Pasta Carbonara", "ingredients": ["pasta", "eggs", "bacon", "cheese"]}

]

Sorted by ingredient count (1, then 4), then by ID

manager.get_all_recipes()

Returns all 3 recipes sorted by ingredient count, then ID

`

Requirements

• Case-insensitive substring search
• Sort by ingredient count ascending (fewer ingredients first)
• Break ties by recipe ID ascending (numeric comparison if IDs are numeric strings)
• Return empty list if no matches

Level 3: User System

Add user authentication and validation for recipe editing.

New Operations

add_user(user_id, username) → bool

Creates a new user. Returns True if successful, False if user_id already exists.

edit_recipe(user_id, recipe_id, name, ingredients) → bool

Updates a recipe, but only if the user_id is valid. Returns True if successful, False if:

• User doesn't exist
• Recipe doesn't exist
• New name conflicts with another recipe (case-insensitive)

Example

` manager = RecipeManager() manager.add_recipe("1", "Pasta", ["pasta", "sauce"]) manager.add_user("u1", "chef_john")

manager.edit_recipe("u1", "1", "Updated Pasta", ["pasta", "sauce", "cheese"])

Returns True (user exists, recipe updated)

manager.edit_recipe("u2", "1", "Another Update", ["pasta"])

Returns False (user "u2" doesn't exist)

`

Requirements

• User validation must occur before any recipe operations
• All previous Level 1-2 operations still work as before
• edit_recipe adds user validation on top of update logic

Level 4: Version Control

Add version history tracking for recipes. Updates now create new versions instead of overwriting.

Modified Behavior

edit_recipe (now creates versions instead of overwriting)

Each edit appends a new version to the recipe's history. The most recent version is the "current" version. Version numbers start at 1.

New Operations

get_recipe_history(recipe_id) → list[dict] | None

Returns the complete version history for the recipe, ordered from oldest to newest. Each entry includes version number, name, and ingredients. Returns None if recipe doesn't exist.

rollback_recipe(user_id, recipe_id, version) → bool

Creates a new version that is a copy of the specified historical version. Does NOT delete any versions. Returns True if successful, False if:

• User doesn't exist
• Recipe doesn't exist
• Version doesn't exist
• Rollback would cause name conflict with another recipe's current name

Example

` manager = RecipeManager() manager.add_user("u1", "chef") manager.add_recipe("1", "Pasta", ["pasta"]) # Version 1

manager.edit_recipe("u1", "1", "Spaghetti", ["spaghetti", "sauce"]) # Version 2 manager.edit_recipe("u1", "1", "Linguine", ["linguine", "sauce"]) # Version 3

manager.get_recipe_history("1")

Returns [

{"version": 1, "name": "Pasta", "ingredients": ["pasta"]},

{"version": 2, "name": "Spaghetti", "ingredients": ["spaghetti", "sauce"]},

{"version": 3, "name": "Linguine", "ingredients": ["linguine", "sauce"]}

]

manager.rollback_recipe("u1", "1", 1) # Creates Version 4 = copy of Version 1

Returns True, now current version has name "Pasta" again

`

Important Edge Cases

Case-Insensitive Name Conflicts

When rolling back, check if the old version's name conflicts with any OTHER recipe's current name:

` manager.add_recipe("1", "Pasta", ["pasta"]) manager.add_recipe("2", "Salad", ["lettuce"]) manager.edit_recipe("u1", "1", "Updated", ["pasta", "sauce"]) # v2 for recipe 1 manager.update_recipe("2", "Pasta", ["lettuce"]) # Recipe 2 now named "Pasta"

manager.rollback_recipe("u1", "1", 1)

Returns False (version 1 has name "Pasta" which conflicts with recipe 2)

`

Version Numbering

• Versions start at 1
• Each edit (including rollback) increments version number
• Version numbers are never reused or reset

Requirements

• Maintain complete version history for all recipes
• Rollback creates a new version (doesn't delete history)
• Check name conflicts against other recipes' current names only
• A recipe can always rollback to its own previous version name if no other recipe uses it