Interview Questions
MongoDB Interview Questions and Answers
MongoDB interviews often probe whether you understand document-oriented schema design as its own discipline, not just "SQL without the joins."
Example: An aggregation pipeline
JavaScript// Find total order value per customer, for customers with more than 5 orders
db.orders.aggregate([
{ $match: { status: "completed" } },
{ $group: {
_id: "$customerId",
totalSpent: { $sum: "$amount" },
orderCount: { $sum: 1 }
}},
{ $match: { orderCount: { $gt: 5 } } },
{ $sort: { totalSpent: -1 } }
]);Frequently Asked Questions
MongoDB stores data as flexible, JSON-like documents (BSON) grouped into collections, rather than rows in fixed-schema tables. Related data is often embedded directly within a single document (e.g. an order document containing its line items as a nested array) instead of being split across separate tables joined at query time.
Embed when the related data is always accessed together with its parent and doesn't need to be queried independently (e.g. an address embedded in a user document). Reference (storing just an ID, like a foreign key) when the related data is large, shared across many parents, updated independently, or queried on its own -- similar reasoning to normalization in relational design, just applied more selectively.
MongoDB's framework for multi-stage data processing -- documents flow through an ordered sequence of stages ($match to filter, $group to aggregate, $sort, $project to reshape output, etc.), each stage's output feeding the next. It's MongoDB's equivalent of SQL's GROUP BY plus JOINs plus window functions, expressed as a pipeline instead of a single query.
Yes, multi-document ACID transactions have been supported since MongoDB 4.0, including across multiple collections and (since 4.2) across a sharded cluster. Earlier MongoDB versions only guaranteed atomicity at the single-document level, which shaped a lot of "embed related data in one document" schema design advice that predates full transaction support.
Similar in principle to relational databases -- an index on a field (or fields) lets MongoDB avoid scanning every document to find matches. The _id field is indexed automatically. Compound indexes (on multiple fields) follow an order-matters rule similar to SQL: an index on {a: 1, b: 1} efficiently supports queries filtering on a alone or on a and b together, but not on b alone.
MongoDB's approach to horizontal scaling -- a large collection is split ("sharded") across multiple servers based on a shard key, so no single server needs to hold the entire dataset or handle the entire query load. Choosing a good shard key (one that distributes both data and query load evenly) is one of the harder decisions in scaling MongoDB.
Treating it exactly like a relational database -- normalizing everything into separate collections and doing the equivalent of joins in application code for every read. MongoDB's document model is designed to let you embed related data specifically to avoid that; over-normalizing gives up much of the performance benefit of the document model without gaining anything in return.