MongoDB Interview Questions

A curated set of MongoDB interview questions, ordered roughly from fundamentals to more advanced — the kind you'll actually be asked in real screens and on-sites.

Modeling#

Q: What's the difference between embedding and referencing, and how do you decide which to use? Embedding nests related data directly inside the parent document, so reading everything together takes a single query; referencing stores related data in a separate collection linked by id, requiring a second query (or $lookup) to join it back. Embed when the related data is bounded in size, has a clear single parent, and is almost always read together with it (a post's comments, if the post/comment volume is modest); reference when the data is large or unbounded, needs independent querying, or is shared across many parent documents.

Q: Why can't you just embed everything to avoid joins entirely? Every MongoDB document has a hard 16MB size limit, and even well before hitting that limit, an unbounded embedded array (like comments on a very popular post) makes the parent document progressively slower to read and write as it grows, since most updates touch the whole document. Data that's independently queried, shared across multiple parents, or unbounded in size is better modeled as its own referenced collection.

MongoDB vs. relational#

Q: When would you choose MongoDB over a relational database for a new project? MongoDB tends to fit well when the schema genuinely varies between records or is expected to evolve quickly, when data is naturally read/written as a cohesive document (an order with its line items, a user profile with nested preferences), and when the application needs to scale writes horizontally — sharding is a built-in, first-class MongoDB feature. It's a weaker fit when the domain has many-to-many relationships queried from multiple angles, or when strong multi-table transactional guarantees are the primary requirement — a relational database's join and constraint machinery does that job more naturally.

Q: Does MongoDB support transactions? Yes — multi-document ACID transactions have been supported since MongoDB 4.0, letting multiple document changes across one or more collections commit or roll back together. That said, the document model is specifically designed to reduce how often multi-document transactions are needed in the first place, by grouping related data into a single document that updates atomically on its own.

Aggregation#

Q: Walk through what $match, $group, and $lookup each do in an aggregation pipeline. $match filters incoming documents by a query, the same syntax as find(), and should generally run as early as possible in the pipeline so later, more expensive stages process fewer documents. $group collapses documents sharing a common _id value into one output document per group, computing aggregates ($sum, $avg, $push, etc.) across each group — the rough equivalent of SQL's GROUP BY. $lookup performs a left-outer-join-style lookup against another collection by matching a local field to a foreign field, adding the results as an array field on each document — MongoDB's answer to a SQL JOIN.

Q: Why does $lookup add an array field, and what do you usually do next? $lookup doesn't flatten a SQL-style join into multiple output rows — instead it attaches every matching document from the foreign collection as an array on the original document, since in principle there could be more than one match. When the relationship is one-to-one (or you specifically want one flattened row per match), a $unwind stage typically follows immediately after $lookup to turn that array into a plain object (or to produce one output document per array element).

Indexing#

Q: How would you diagnose a slow MongoDB query, and what would you look for? Run the query with .explain("executionStats") and check the executionStages: a COLLSCAN means MongoDB scanned every document in the collection with no supporting index, while an IXSCAN means an index was used. A large gap between totalDocsExamined and nReturned (examining far more documents than were actually returned) is the clearest sign a missing or poorly-targeted index is the bottleneck, and the fix is usually creating an index that matches the query's actual filter fields — in the right order, for compound indexes.

Transactions and scaling#

Q: If a single document write is already atomic, why does MongoDB support multi-document transactions at all? A single write to one document — even one touching several fields at once — is always atomic on its own, with no transaction needed. Multi-document transactions exist for the rarer case where genuinely independent documents (queried and updated separately, so embedding them together isn't reasonable) must still change together as one unit, such as debiting one account document and crediting another. Before reaching for one, it's worth asking whether the two documents should actually have been modeled as one via embedding — a multi-document transaction is meant as an escape hatch, not the default tool for every multi-part write.

Q: What has to be true of a MongoDB deployment for multi-document transactions to work at all? It must be running as a replica set or a sharded cluster — transactions rely on the same replication oplog that backs replica set durability, so they simply can't run against a single standalone mongod with no replication configured. This is a common surprise in local development, where a quick standalone instance works fine for everything except transaction code, which then fails only once it's pointed at a real replica set–backed environment.

Q: What makes a good shard key, and what's the risk of choosing a monotonically increasing one? A good shard key has high cardinality (so data actually spreads across shards) and lines up with the collection's real query patterns (so common queries can be routed to a specific shard instead of scattering across all of them). A monotonically increasing key — an auto-generated id, or a timestamp — is risky as the sole shard key because every new value is higher than the last, so every new write lands on whichever shard currently owns the top of the range: a "hot chunk" that absorbs all new writes no matter how many shards exist, defeating the point of sharding for write scaling.