MongoDB Interview Questions

You already know the SQL side of indexes, transactions and isolation from Backend, Lesson 07, and the ORM traps from Backend, Lesson 08. This lesson covers what is different in MongoDB, and the questions interviewers ask at 4+ years. They rarely ask "what is a collection?". They ask "your orders query is slow, and the document keeps growing: what do you do?"

Words used in this lesson

• MongoDB is a database that stores data as documents (objects with fields, arrays and nested objects) instead of table rows. A collection is a group of documents, like a table. The documents in one collection do not need the same fields.
• BSON is the binary format MongoDB uses to store JSON-like data. It has more types than JSON: dates, ObjectId, 64-bit integers and decimals.
• A replica set is a group of MongoDB servers that keep the same data. One is the primary (takes writes). The others are secondaries (copy the primary's changes from its oplog, a log of every change).
• A shard is one replica set that holds part of a big collection. Sharding splits a collection across shards. A shard key is the field that decides which shard gets a document.
• An index is a sorted copy of some fields that lets the database find documents without reading the whole collection. A collection scan (COLLSCAN) reads every document.
• An aggregation pipeline is a list of stages. Each stage takes documents in, changes them and passes them on, like a factory line.
• ACID means a transaction is all-or-nothing and safe even if the server crashes.

1. Document model vs relational

Difference in one line: in SQL you normalise first (no duplicate data) and join later; in MongoDB you model for the queries first and accept some duplicate data.

The strongest point: a write to one document is atomic. If an order and its line items live in one document, you do not need a transaction to update them together. "Flexible schema" does not mean "no schema". Your application still has a shape. The shape is just kept in code (and in validation rules) instead of only in the database.

2. Embed or reference?

Embedding means putting related data inside the parent document. Referencing means storing the _id of another document and loading it with a second query (or $lookup).

Rule of thumb: "one-to-few" embeds, "one-to-many" often references, "one-to-squillions" always references (the child holds the parent's _id).

Patterns you can name in an interview:

• Subset: keep only the data the page needs in the main document (for example the last 10 reviews) and the rest in another collection. This keeps the working set small.
• Extended reference: copy a few fields you always show (the customer's name) into the order, so the common read needs no join. The cost: you must update copies when the source changes. Copy only fields that rarely change, or that should be frozen anyway (the price at order time).
• Bucket: group many small items into one document per time window (one document per sensor per hour). Fewer documents, fewer index entries.
• Computed: store a calculated value (a count, a total) and update it on write, so reads are cheap.
• Schema versioning: keep a schemaVersion number in each document, so old and new shapes can live together while you migrate.
• Attribute (many rare fields as { k, v } pairs, one index) and Archive (move old data to cheaper storage) are the other two names to know.

3. _id and ObjectId

Every document has a unique _id, and it is always indexed. If you do not give one, the driver makes an ObjectId. It is 12 bytes: a 4-byte timestamp (seconds), a 5-byte random value (per process) and a 3-byte counter. It prints as 24 hex characters. I generated some:

const a = new ObjectId();            // 6ac7b2bd40ac35250d1f3873a.getTimestamp();                    // 2026-10-08T15:11:57.000Z  (first 4 bytes)

Two ObjectIds made by the same process in the same second share the first nine bytes, and only the counter changes. Facts to say out loud:

• ObjectIds are roughly ordered by time but not strictly: they have one-second resolution and the clocks of different clients differ. Do not use _id order as a perfect timeline; add a createdAt.
• The ID is made by the driver, not the server, so you know it before the insert (useful for retries).
• _id is a good key for cursor pagination, but a bad shard key (it grows with time, see section 8).
• In JSON, an ObjectId becomes a string. Comparing String to ObjectId in a filter finds nothing, a very common bug: { _id: "6ac7..." } does not match { _id: ObjectId("6ac7...") }. Convert with new ObjectId(str). (Mongoose casts for you; the native driver does not.)

4. Indexes

An index speeds up reads and slows every write a little, and it uses memory. Know these types:

Limits: up to 64 indexes per collection and 32 fields in a compound index.

The ESR rule (Equality, Sort, Range)

For a compound index, order the fields: first the fields you match with equality, then the field you sort by, then the fields with a range ($gt, $lt, $in with many values, $ne, $regex). Example query:

db.orders.find({ userId, status: "paid", total: { $gt: 100 } }).sort({ createdAt: -1 })// index:  { userId: 1, status: 1, createdAt: -1, total: 1 }//          equality-----------   sort--------    range

Why: equality fields narrow the index to one small slice that is already in sorted order, so the sort comes free. A range field before the sort breaks that order, so MongoDB would need an in-memory sort. ESR is a guideline, not a law: if the range is very selective, putting it before the sort (ERS) can be faster, even with an in-memory sort. Test with explain.

Reading explain()

explain("executionStats") shows what MongoDB did. Look at:

• Stage names: COLLSCAN (read everything, usually bad on big collections), IXSCAN (used an index), FETCH (load full documents), SORT (in-memory sort; slow on large data).
• totalKeysExamined, totalDocsExamined vs nReturned. If you return 20 documents but examine 200,000, the index is wrong or missing. Aim for these three numbers to be close.
• A covered query reads only the index (no FETCH), because all needed fields are in the index and are projected.

I could not run a real server for this lesson, so these names come from the official docs, not from my own run.

Index traps

• Unique index and missing fields. A unique index treats a missing field as null. The second document without email fails with a duplicate error. Fix: a partial unique index (partialFilterExpression: { email: { $exists: true } }), so documents with no email field are left out. (A document with an explicit email: null still has the field, so store a real value or leave the field out.)
• Partial index filters are limited: equality, $exists: true, $gt/$gte/$lt/$lte, $type, $and, $or, $in. For "not deleted" use a real boolean such as isDeleted: false.
• Array queries. { "items.sku": "a", "items.qty": { $gt: 1 } } can match when different array elements satisfy each part. I tested a document with [{sku:"a",qty:1},{sku:"b",qty:5}]: the dotted form matched, and $elemMatch: { sku: "a", qty: { $gt: 1 } } did not. Use $elemMatch when both conditions must hold for one element.
• Too many indexes. Each costs write speed and memory. Drop unused ones; {a:1} is not needed if you have {a:1,b:1}. Build indexes on big collections in a quiet time, and with Mongoose set autoIndex: false in production.

5. The aggregation pipeline

A pipeline is an array of stages. The ones you must know:

A worked example. Orders paid per customer, with the customer name:

db.orders.aggregate([  { $match: { status: "paid" } },                                   // 1. filter first, uses an index  { $group: { _id: "$userId", revenue: { $sum: "$total" }, orders: { $sum: 1 } } },  { $sort: { revenue: -1 } },  { $lookup: { from: "users", localField: "_id", foreignField: "_id", as: "user" } }, // 2. join AFTER shrinking  { $unwind: "$user" },  { $project: { _id: 0, name: "$user.name", revenue: 1, orders: 1 } },])// [ { name: "Ben", orders: 1, revenue: 250 }, { name: "Asha", orders: 2, revenue: 200 } ]

I ran this logic on four sample orders; the result is the one in the comment. Things to know:

• Put $match (and $sort + $limit) as early as possible so later stages see fewer documents.
• $lookup needs an index on the foreignField. Without it, each input document scans the other collection. Do the $group first so you join 2 rows, not 2 million.
• $unwind drops documents whose array is empty or missing, unless you set preserveNullAndEmptyArrays: true. I tested this: an order with items: [] disappeared after a plain $unwind.
• $facet gives several results in one request (for example a result list and counts by status for a search page). Each stage inside is limited to 100 MB (no spilling to disk), the whole output must fit in one 16 MiB document, and a $facet that comes first does a collection scan, so put $match before it.
• Memory: a stage like $group over 100 MB writes temporary files to disk by default since MongoDB 6.0.
• $merge writes results into a collection (insert, replace, merge or fail on match). It needs a unique index on the on fields, and the index cannot be partial. It is the base for "materialised views": a nightly job pre-computes a summary and the app reads that.

6. Transactions, read concern and write concern

A transaction groups several operations so they all succeed or all fail. MongoDB supports multi-document transactions on replica sets and sharded clusters. They are not free: they hold resources, they have a time limit (60 seconds by default), and they conflict with other writers. Good modelling often removes the need.

const session = client.startSession();try {  await session.withTransaction(async () => {    const res = await orders.updateOne({ _id: orderId, status: "new" }, { $set: { status: "paid" } }, { session });    if (res.modifiedCount !== 1) throw new Error("order not payable");    await ledger.insertOne({ orderId, amountCents, at: new Date() }, { session });  }, { readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } });} finally { await session.endSession(); }

Rules from the driver documentation, worth remembering:

• Pass { session } to every operation. One that forgets it runs outside the transaction.
• withTransaction may call your function more than once (it retries after transient errors), so do not send emails or call payment APIs inside. Keep it to database work.
• Do not run operations in parallel inside it (Promise.all is undefined behaviour). Await them one by one.
• Do not swallow errors inside the callback, or the driver cannot tell the transaction failed.
• Keep it short. Long transactions create cache pressure and write conflicts. Two transactions that touch the same document do not wait; one fails with a write conflict and you retry.

Write concern says how many servers must confirm a write before you get "OK". w: 1 is the primary only. w: "majority" means a majority of the voting members have it, so it survives a failover. Since MongoDB 5.0 the default is majority (with one edge case: if arbiters leave too few data-bearing voting members, the default falls back to w: 1). Read concern says how safe the data you read is. The default "local" can return data that is later rolled back. "majority" returns only data confirmed by a majority. "snapshot" (in transactions) gives one consistent view. Drivers have retryable writes and reads on by default (retryWrites=true), which retry once after a network error or failover, but not inside a transaction.

7. Replica sets and elections

A replica set has one primary and several secondaries. If the primary stops answering, the secondaries hold an election and one becomes primary. By default a secondary calls an election when it has not heard from the primary for 10 seconds (electionTimeoutMillis). The docs say the median time to get a new primary is under about 12 seconds with default settings. During that time there are no writes.

• Use an odd number of voting members (3 or 5) so a majority exists. With 3 members, you can lose 1. An election needs a majority of voting members.
• An arbiter votes but holds no data. It weakens w: "majority", so avoid it when you can.
• Reads go to the primary by default. Secondary reads can be stale (replication lag); use them only for reports.
• If a primary that took a write that never reached a majority fails, that write is rolled back when the old primary comes back. w: "majority" prevents surprise rollbacks.
• Transactions and change streams need a replica set (a one-node replica set is fine for local development).

8. Sharding

Sharding spreads one collection over several shards. The mongos router sends each query to the right shard(s) using the shard key. A query that includes the shard key is targeted (one shard). One that does not is scatter-gather (all shards, slower).

A good shard key has:

1. High cardinality: many distinct values. A key like country with a few values limits you to few chunks.
2. Low frequency: no single value holds a big share of the data (one huge customer).
3. No steady growth: a key that only goes up (a timestamp, an ObjectId) sends all new inserts to the last chunk, so one shard is a hot shard and the rest idle.
4. Matches your queries: most queries should contain it.

The fixes: a hashed shard key (even spread, but range queries become scatter-gather), or a compound key such as { tenantId: 1, _id: 1 } (even spread across tenants, and tenant queries stay targeted). Since MongoDB 5.0 you can change the key with reshardCollection, and refineCollectionShardKey can add suffix fields. This is possible but heavy, so choose carefully. Default chunk (range) size is 128 MB. And remember: most apps never need sharding. Try better indexes, a bigger machine, or archiving first.

9. Change streams

A change stream lets your app subscribe to changes (insert, update, delete) on a collection, database or cluster, without reading the oplog yourself. It needs a replica set.

const stream = orders.watch(  [{ $match: { operationType: { $in: ["insert", "update"] } } }],  { fullDocument: "updateLookup", ...(savedToken ? { resumeAfter: savedToken } : {}) },);for await (const change of stream) {  await handle(change);  await saveToken(change._id);     // the resume token}

• Save the resume token (change._id) after you handle each event. If your process restarts, pass it as resumeAfter and you continue without gaps, as long as the oplog still holds that point. Use the same pipeline and options when you resume.
• fullDocument: "updateLookup" fetches the current document when the event is read. It can be newer than the change itself. For the exact before and after, enable changeStreamPreAndPostImages on the collection (MongoDB 6.0 and later).
• Typical uses: keep a search index in sync (for example Meilisearch), invalidate caches, feed a queue. Handlers must be idempotent (safe to run twice), because an event can arrive again after a restart.

10. Atlas Search and Vector Search

MongoDB Atlas is MongoDB's hosted service. Two features of it matter now:

• Atlas Search is full-text search (word matching, ranking, typo tolerance, autocomplete) built into Atlas. You define a search index and use the $search stage in an aggregation. The plain text index is basic; Atlas Search is the real option, and it avoids running a separate engine. A separate engine like Meilisearch can feel better for some apps, but you must sync it (for example with a change stream) and run it.
• Vector Search finds documents by meaning, using embeddings (arrays of numbers produced by an AI model; similar meaning gives close numbers). It is the "R" in RAG (retrieval-augmented generation: find relevant text, then give it to an LLM). You create a vector search index and use $vectorSearch:

db.docs.aggregate([  { $vectorSearch: { index: "vec_idx", path: "embedding", queryVector, numCandidates: 200, limit: 10, filter: { lang: "en" } } },  { $project: { _id: 0, title: 1, score: { $meta: "vectorSearchScore" } } },])

numCandidates is how many nearest candidates the approximate (ANN) search looks at, and limit is how many you get back. A larger numCandidates gives better recall but costs more time. Use the same embedding model for documents and query. Both features run on Atlas, so ask which the team uses.

11. Mongoose vs native driver vs Prisma

Facts I checked:

• Driver defaults: maxPoolSize 100, serverSelectionTimeoutMS 30,000, retryWrites and retryReads true. Create one MongoClient per process and reuse it. A client per request creates connection storms.
• Mongoose: unique: true creates an index; it is not a validator (a duplicate gives an error from the server, code 11000). Unknown fields are dropped by strict mode (I saw an extra field vanish). populate() runs a separate query, not a server-side join. lean() skips building full Mongoose documents: faster, but you get plain objects without methods. Without a connection, calls wait (buffer) and fail after bufferTimeoutMS (10 s default); I saw Operation users.find() buffering timed out.
• In Mongoose 9: pre hooks no longer take next (use async functions), validateSync() is deprecated (use await doc.validate()), new: true is replaced by returnDocument: "after", and isValidObjectId(6) is now false.
• Prisma with MongoDB: Prisma's own docs say it uses transactions for nested writes, so you need a replica set; ids are mapped with @map("_id") and @db.ObjectId; you use db push (there are no SQL-style migrations); it cannot tell null from a missing field; and count() on huge collections is slow. Support changed between major versions: the v7 docs say MongoDB support for v7 is "coming" and tell you to stay on v6 (6.19) for MongoDB, and v8 (a release candidate as of this writing) has a new, different MongoDB package. Check your Prisma version before you promise anything in an interview.

12. Validation, pagination, soft delete, migrations, backup, security

Schema validation. MongoDB can enforce a $jsonSchema: required fields, types and ranges. validationAction: "error" rejects bad writes; "warn" only logs them. validationLevel: "moderate" checks new inserts and updates of already-valid documents, and leaves old invalid ones alone, so you can add rules to messy data. Keep app-level validation too (Backend, Lesson 03) for better error messages.

Pagination. skip(n) makes the server walk past n entries, so page 5,000 is slow. Use range (keyset) pagination: find({ _id: { $gt: lastId } }).sort({ _id: 1 }).limit(20). For another sort field, sort by { createdAt, _id } and filter on both, so ties have a stable order. Fetch limit + 1 rows to know if there is a next page, and return an opaque cursor. countDocuments() with a filter can be slow on big collections; estimatedDocumentCount() is fast but cannot filter.

Soft delete. Store isDeleted: false (set at creation, so a partial index sees it) and deletedAt. Every read must filter on it, so use one helper. A unique index with partialFilterExpression: { isDeleted: false } lets a user re-register an email after deleting. Purge or archive later with a job. Trade-off: easy undo and audit, but every query must remember the filter, and privacy rules may still need real deletion.

Migrations. Schemaless does not mean migration-free. Use schema versioning: a schemaVersion field, code that reads both shapes, and a script that updates small idempotent batches (updateMany({ schemaVersion: { $lt: 2 } }, ...)). Release in steps: write both shapes, backfill, switch reads, remove the old. A runner such as migrate-mongo keeps scripts in order.

Backup. In Atlas use continuous cloud backup with point-in-time restore. Self-hosted: filesystem or volume snapshots, or Ops/Cloud Manager. mongodump and mongorestore are for small deployments; the docs call them tools for small ones. Plain file copies need writes stopped. A backup is real only after you practise a restore and measure how long it takes.

Security.

• Turn on authentication and give each app a user with the least rights. Do not expose the port to the internet; the server listens on localhost by default, so you must open it on purpose. Use TLS, IP allow-lists and private networking.
• NoSQL injection is real. If req.body.password can be an object, { "password": { "$ne": "" } } matches any account. I tested this: the filter matched the admin. Defences: validate that fields are strings first (Backend, Lesson 03), and in Mongoose use sanitizeFilter, which wraps objects in $eq (I saw { $ne: "" } become { $eq: { $ne: "" } }). Avoid $where and server-side JavaScript.

Common mistakes

1. Unbounded arrays and huge "everything" documents; $lookup as a habit.
2. Wrong index order, or one index per field instead of a compound index.
3. Comparing a string with an ObjectId.
4. Transactions for what one document already does, or with side effects inside.
5. A growing shard key (_id, timestamp); skip for deep pages.
6. Trusting request JSON in filters (NoSQL injection).
7. A new MongoClient per request.

Interview questions

Key takeaways

• Model for your queries. Embed small, bounded, read-together data; reference growing or shared data. One document is atomic.
• ObjectId is 12 bytes (time, random, counter), roughly ordered, made by the driver. Never compare it with a plain string.
• Compound indexes: Equality, Sort, Range. Read explain and compare keys and documents examined with documents returned.
• Know the traps: unique and missing fields, array conditions without $elemMatch, $unwind dropping empty arrays, $lookup without an index.
• Transactions are the exception: pass the session, stay short, no side effects. Use w: "majority" for important writes.
• Replica sets fail over in about ten seconds. A shard key must not grow forever. Most apps do not need sharding.
• Change streams need a saved resume token and idempotent handlers. Vector Search powers RAG; Atlas features run on Atlas.
• Validate input as strings to stop NoSQL injection, use sanitizeFilter, turn on auth, and test your restores.

What's next

You now have the Node and MongoDB layers. Go back to Backend in Depth for the SQL view of the same ideas (indexes, isolation, N+1), or practise end to end with Practical Design Problems.