Interactive guide · 4 chapters · ~15 min read

MongoDB Interview & Revision

MongoDB interviews tend to probe schema design trade-offs, index selection, and when document modeling breaks down — this section condenses those questions into revision notes, a self-check quiz, and a cheat sheet for the night before.

Mangesh MandlikLast updated: 1 October 2026

01 · Q&A

Interview Questions

The questions that come up again and again, with the shape of a strong answer.

"What happens when you run a find()?"

The query planner evaluates candidate plans (collection scan vs available indexes), picks the lowest-cost one, and the executor streams matching documents back via a cursor.

"Embedding vs referencing — how do you decide?"

Embed when data is read together with the parent and bounded in size; reference when data is large, shared across many parents, or updated independently and often.

"How does MongoDB achieve high availability?"

Replica sets: a primary accepts writes, secondaries replay its oplog continuously, and an automatic election promotes a secondary if the primary fails — no external tool required.

"How does sharding route a query?"

mongos consults the config server's chunk map. Queries including the shard key are targeted to one shard; queries without it scatter-gather across every shard.

"What's the difference between w:1 and w:majority?"

w:1 acknowledges once the primary alone has the write — fast, but can be lost if the primary crashes before replicating. w:majority waits for a majority of replica set members — slower, but durable through a primary failure.

"When would a collection scan beat an index scan?"

When the query needs a large fraction of the collection — similar to the relational sequential-scan trade-off, an index lookup plus document fetch per match can cost more than one linear pass.

02 · Quick recall

Revision Notes

Key takeaways

MongoDB stores BSON documents in collections, without an enforced schema by default.
_id is unique and automatically indexed on every document.
B-Tree index lookup = O(log n); collection scan (COLLSCAN) = O(n).
Aggregation pipeline stages: $match, $group, $sort, $project, $lookup — composed in sequence.
Replica sets provide automatic failover via elections — no external orchestrator needed.
Sharding distributes documents across shards using a shard key, routed by mongos.
Write concern (w:1 vs w:majority) trades latency for durability; read concern trades recency for consistency guarantees.
Embed data that's read together and bounded in size; reference data that's large, shared, or updated independently.

03 · Self-check

Quiz

Answer these before checking the Revision Notes above — if you can explain the "why" for each, you're interview-ready.

1. Why does MongoDB not require a migration to add a new field to some documents in a collection?

2. A collection has 10 indexes and write latency has crept up over months. What's your first hypothesis and how would you confirm it?

3. Why can a scatter-gather query on a sharded cluster be much slower than a targeted one?

4. What's the practical difference between w:1 and w:majority write concern?

5. The primary in a replica set crashes. What happens next, and does the application need to do anything special?

6. When should you choose referencing over embedding, even though embedding usually means fewer round trips?

Engineering Insight

Answers, in order: (1) MongoDB doesn't enforce a schema by default — each document is independently structured BSON. (2) Unused/overlapping indexes — confirm with $indexStats. (3) A scatter-gather query has to contact every shard and merge results, instead of routing directly to the one shard holding the data. (4) w:1 is faster but can lose the write if the primary crashes before replicating; w:majority waits for a majority of members, surviving that failure. (5) Remaining members hold an election and promote the most up-to-date secondary automatically; the driver reconnects to the new primary, though in-flight writes during the election may need a retry. (6) When the related data is large, shared across many parents, or updated independently and often — embedding it would duplicate updates across every parent.

04 · Reference

Cheat Sheet

javascriptThe commands worth memorizing — they cover most day-to-day MongoDB diagnosis.

// Explain a query's plan and stats
db.orders.find({ customerId: 42 }).explain('executionStats');

// Find unused indexes
db.orders.aggregate([{ $indexStats: {} }]);

// Current operations / long-running queries
db.currentOp({ 'secs_running': { $gt: 5 } });

// Replica set status and lag
rs.status();
rs.printSecondaryReplicationInfo();

// Sharding: check chunk distribution
sh.status();

// Aggregation pipeline skeleton
db.sales.aggregate([
  { $match: { region: 'EU' } },
  { $group: { _id: '$region', total: { $sum: '$amount' } } },
  { $sort: { total: -1 } },
  { $project: { region: '$_id', total: 1, _id: 0 } },
]);