Search Engine — Razorpay Machine Coding Round
Razorpay machine coding round — design a lightweight in-memory search engine with datasets, substring search, and relevance ranking.
Your organization has started a new tech blog full of interesting stories, and you're responsible for designing and implementing an in-memory search engine that powers search over the blog's content.
The original notes were a rough sketch — a bullet list of requirements plus a worked example, not a fully worded question. This is a framed, cleaned-up version of the same problem: the requirements and example below are taken directly from those notes; the surrounding structure (edge cases, data model, walkthrough) has been filled in to make it usable as a standalone question.
This one tests whether you can design a clean indexing structure and get the ranking logic exactly right — the interesting part isn't finding matches, it's ordering them by how relevant each document is to the search term.
Objective
The primary objective of this project is to design and implement an in-memory search engine that organizes documents into named datasets, supports inserting and deleting documents, and returns search results ranked by relevance to the search term.
Data Model
Each dataset is conceptually a map from a document ID to its text content.
dataset "tech-blog" -> {
doc1: "apple is a fruit",
doc2: "apple, apple come on!",
doc3: "oranges are sour",
doc4: "apple-pie is sweet",
}
Functional Requirements
Requirements are split into two tiers so you know what to prioritize under time pressure: build first, and worth proposing if time allows.
Part 1 — Basic Requirements
Core functionality you must build and get working first.
A document matches if the search term appears as a substring anywhere in its text — case sensitivity is worth clarifying with the interviewer, but the example below treats it as case-sensitive. Results are ordered by descending number of occurrences of the term within each matching document; documents with the same occurrence count can be returned in either relative order.
Example Usage
Search term: apple, over this dataset:
Doc1: apple is a fruit
Doc2: apple, apple come on!
Doc3: oranges are sour
Doc4: apple-pie is sweet
> search("tech-blog", "apple")
[Doc2, Doc1, Doc4] (or [Doc2, Doc4, Doc1] — either order is acceptable)
Doc2 contains "apple" twice and ranks first. Doc1 and Doc4 each contain it once — Doc4's match comes from "apple" as a substring of "apple-pie," confirming that matching is substring-based rather than whole-word. Doc3 has no occurrences and is correctly excluded. Doc1 and Doc4 tie on occurrence count, so either relative order between them is valid.