Implement a versioned recipe management system

Q: Implement a versioned recipe management system

This question evaluates data-structure design and state-management competencies, covering CRUD, case-insensitive search/sort semantics, user management, and versioning/rollback for an in-memory Recipe Management System in the Coding & Algorithms domain.

Q: How do I approach Coding & Algorithms interview questions?

Coding & Algorithms questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master coding & algorithms interviews.

Q: What difficulty level is this interview question?

This is a medium difficulty Coding & Algorithms question, commonly asked during Take-home Project rounds at Coinbase.

Q: What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Coinbase during technical interviews.

Question

You are asked to implement an in-memory Recipe Management System (similar in difficulty to a simple banking/in-memory DB exercise). The system supports incremental feature “levels”. Design the data structures and implement the required APIs.

Data model

Assume each Recipe has at least:

recipeId (unique string or integer)
name (string)
size (integer; used only for sorting)

Assume each User has at least:

userId (unique)
userName

No persistence is required (everything is in memory).

Level 1: Basic CRUD for recipes

Implement the following operations:

addRecipe(recipe) : add a new recipe (reject or overwrite if recipeId already exists—state your choice clearly).
updateRecipe(recipeId, fields...) : update an existing recipe.
getRecipe(recipeId) : return the recipe or “not found”.
deleteRecipe(recipeId) : delete an existing recipe.

Define expected behavior for edge cases (e.g., updating/deleting a non-existent recipe).

Level 2: Search and list

Implement:

searchRecipes(query) : search recipes by name , case-insensitive (define whether it’s exact match or substring match; choose one and be consistent).
listRecipes(sortBy) : return all recipes sorted by either:
- name (lexicographic, case-insensitive), or
- size (numeric ascending)

Specify tie-breaker behavior (e.g., tie-break by recipeId).

Level 3: Add user

Implement:

addUser(user) : add a user (keep it simple—no extra features unless needed).

Define behavior on duplicate userId.

Level 4: Version history and rollback

Add versioning to support:

versionHistory() : return stored version metadata (at minimum, a monotonic versionId and what changed).
rollback(versionId) : restore the system state to exactly how it was at that versionId .

Guidance: treat each mutating operation (e.g., add/update/delete recipe, add user) as producing a new version; maintain whatever additional structures you need (e.g., a versionMap).

Constraints / expectations

Assume up to ~100k recipes/users.
Aim for clean APIs and reasonable time complexity.
You may implement this as a class/module with methods in your preferred language.