MongoDB Interview Questions

Analogy categoryAnalogies

Data Modeling and Schema Design Questions

One of the most common interview questions is 'when do you embed versus reference documents?' The rule of thumb: embed when data is accessed together, has a bounded one-to-few relationship, and doesn't need independent querying (e.g., an address inside a user document); reference when the related data is unbounded (e.g., a user's thousands of orders), updated independently, or shared across many parent documents, since MongoDB has no native JOIN and referencing requires a separate query or $lookup aggregation stage.

🏏

Cricket analogy: Like a scorecard embedding a batsman's individual runs directly since they're always viewed together, but referencing a player's full career stats separately since that data is unbounded and queried independently, embedding versus referencing follows the same logic.

Indexing and Query Performance Questions

A frequent follow-up is explaining how to diagnose a slow query: interviewers expect candidates to mention .explain('executionStats') to inspect whether a query used an IXSCAN (index scan) or fell back to a COLLSCAN (full collection scan), how many documents were examined versus returned (totalDocsExamined vs nReturned), and whether the plan was a covered query that used only index fields without touching the documents at all. Candidates should also be able to explain the ESR rule for compound index field order: Equality fields first, Sort fields second, Range fields last.

🏏

Cricket analogy: Like a bowling coach reviewing ball-by-ball data to see whether a bowler hit the right line consistently or scattered deliveries wastefully, explain() shows whether a query used a targeted index scan or an inefficient full scan.

javascript

// Diagnose a slow query
db.orders.find({ status: "pending", createdAt: { $gte: ISODate("2026-01-01") } })
  .sort({ createdAt: -1 })
  .explain("executionStats");

// Compound index following the ESR rule:
// Equality (status) -> Sort (createdAt) -> Range would come after if present
db.orders.createIndex({ status: 1, createdAt: -1 });

The ESR rule for compound indexes: put Equality-matched fields first, Sort fields second, and Range-queried fields last. Following this order lets MongoDB use the index to satisfy the filter, avoid an in-memory sort, and still narrow down range matches efficiently.

Replication and Sharding Questions

Replication and sharding are frequently confused by candidates: replication is about redundancy and availability (multiple copies of the same complete data set), while sharding is about scale (splitting the data set across servers so each holds only a portion). A strong candidate should be able to state that a production sharded cluster typically combines both — each shard is itself a replica set — and should be ready to walk through what happens step by step when a primary fails in a sharded, replicated cluster.

🏏

Cricket analogy: Like confusing 'having backup wicketkeepers' (redundancy, replication) with 'splitting a tournament across multiple venues' (scale, sharding), candidates often mix up MongoDB's replication and sharding concepts the same way.

A common interview mistake: stating that sharding alone provides high availability. Sharding provides scale, not redundancy — a shard with no replica set behind it is a single point of failure. Production clusters combine both: each shard is itself a replica set.

Embed data that is accessed together and bounded; reference data that is unbounded or shared across many documents.
explain('executionStats') reveals whether a query used an index scan (IXSCAN) or a full collection scan (COLLSCAN).
The ESR rule orders compound index fields as Equality, Sort, then Range.
Covered queries answer entirely from the index without touching documents, which is the fastest query shape.
Replication provides redundancy and availability; sharding provides horizontal scale — they solve different problems.
Production sharded clusters combine both: each shard is typically its own replica set.
Be ready to explain step-by-step what happens during failover in a sharded, replicated cluster.