MongoDB Interview Questions and Answers

MongoDB interviews test whether you can model documents, query efficiently, and operate clusters—not only insert JSON.

Choose MongoDB when document shape matches access patterns, schema evolves quickly, or horizontal scale is a first-class requirement. Choose SQL when complex relational integrity and ad-hoc JOIN analytics dominate—see SQL interviews.

MongoDB's own recruiting blog stresses problem-solving and depth on data modeling, not trivia about founding year.

Run MongoDB Atlas free tier or Docker mongodb/mongodb-community-server locally for hands-on practice.

MongoDB is a document database storing records as BSON (binary JSON) documents in collections (like tables without fixed columns).

db.orders.insertOne({
  _id: ObjectId(),
  customerId: "c-42",
  items: [{ sku: "A1", qty: 2 }],
  total: 59.98,
  status: "PAID"
});

"Schemaless" means the server does not enforce one shape—but applications should enforce schema via validation rules or ODM layers.

A strong answer is:

MongoDB stores flexible BSON documents in collections; I still design schema deliberately because schemaless does not mean schema-free in production.

Common types:

Type consistency matters—mixing string and int in the same field breaks indexes and queries.

A strong answer is:

I use consistent BSON types per field path, Decimal128 for money, and Date for timestamps—mixed types in one field path cause subtle query bugs.

Example: order line items embed in order; customer profile referenced by customerId if reused across orders.

Anti-pattern: unbounded arrays (all comments on a viral post) → bucketing or separate collection.

A strong answer is:

I embed when data is read together and bounded; I reference when relationships are many-to-many or arrays can grow without limit.

MongoDB can enforce document shape at insert/update:

db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["email", "createdAt"],
      properties: {
        email: { bsonType: "string" },
        age: { bsonType: "int", minimum: 0 }
      }
    }
  },
  validationLevel: "moderate"
});

validationLevel: strict on new inserts; moderate only validates valid docs being updated.

A strong answer is:

Server-side validation catches bad documents at the database boundary—I use it with application validation, not instead of it.

CAP: Consistency, Availability, Partition tolerance—pick two under network partition.

MongoDB replica sets prioritize availability + partition tolerance with tunable consistency via read/write concerns.

Interviewers want nuance—not "MongoDB is eventually consistent" as a blanket statement.

A strong answer is:

MongoDB clusters are AP-oriented with tunable consistency—I use majority writes and appropriate read concerns when stale reads are unacceptable after failover.

db.orders.createIndex({ customerId: 1, createdAt: -1 });

Indexes speed reads but cost write amplification and RAM—index only what you query.

A strong answer is:

I index query predicates and sort fields, prefer compound indexes following ESR, and avoid indexing every field by default.

ESR: Equality → Sort → Range when building compound index field order.

Query:

db.orders.find({ status: "PAID", createdAt: { $gte: ISODate("2026-01-01") } })
  .sort({ createdAt: -1 });

Good index: { status: 1, createdAt: -1 } — equality on status, sort/range on createdAt.

Wrong order wastes index efficiency or forces in-memory sorts.

A strong answer is:

I order compound index fields equality first, then sort, then range so the index supports both filter and sort without COLLSCAN.

db.orders.find({ status: "PAID" }).explain("executionStats");

Watch:

High docsExamined / nReturned ratio means index is not selective enough.

A strong answer is:

I run explain with executionStats, eliminate COLLSCAN on hot paths, and compare keys examined to documents returned.

A query is covered when the index alone satisfies it—all fields in projection and filter are in the index, and _id is excluded or in index.

Benefit: MongoDB need not fetch full documents from disk.

Trade-off: larger indexes; include only needed fields in compound index.

A strong answer is:

Covered queries avoid document fetches—I design projections and indexes together when read paths are extremely hot.

Regex prefix ^foo can use index; leading wildcard cannot.

A strong answer is:

I index for real query patterns, follow ESR, and review explain plans instead of adding indexes reactively without measurement.

db.products.updateOne(
  { sku: "A1" },
  { $inc: { stock: -1 }, $set: { updatedAt: new Date() } }
);

Updates are atomic per document; multi-document ACID needs transactions.

A strong answer is:

CRUD is document-scoped; I use update operators instead of read-modify-write races when one document holds the counter or state.

db.users.find({
  age: { $gte: 18 },
  tags: { $elemMatch: { name: "premium", active: true } }
});

A strong answer is:

I match filters to indexes and use elemMatch for array objects instead of loose dot queries that over-match.

Projection limits returned fields—less network and disk:

db.orders.find(
  { customerId: "c-42" },
  { _id: 0, total: 1, status: 1, createdAt: 1 }
);

In aggregation, $project reshapes documents and can compute fields.

Pair with covered queries when possible.

A strong answer is:

I project only fields the API needs—smaller payloads and better chance of covered queries on hot reads.

Upsert = update if exists, insert if not:

db.counters.updateOne(
  { _id: "orders" },
  { $inc: { seq: 1 } },
  { upsert: true }
);

Useful for idempotent writes and counter collections—watch race conditions without proper filter uniqueness.

A strong answer is:

Upsert gives idempotent single-document writes—I ensure the filter uniquely identifies the logical record before relying on it.

db.orders.find({ _id: { $gt: lastSeenId } })
  .sort({ _id: 1 })
  .limit(20);

Avoid large skip on page 10,000—see SQL pagination parallels.

A strong answer is:

I use keyset pagination on an indexed field for deep pages; skip/limit only for small offsets.

A pipeline processes documents through stages—each stage transforms a stream.

Common stages:

Put $match first to reduce documents early when indexed.

A strong answer is:

Aggregation is a staged dataflow—I filter early with $match, index match fields, and avoid unnecessary $lookup on hot paths.

Pipeline logic in testable JavaScript (same semantics as a simple pipeline):

const orders = [
  { status: "PAID", category: "books", amount: 20 },
  { status: "PAID", category: "books", amount: 15 },
  { status: "PAID", category: "tools", amount: 50 },
  { status: "PENDING", category: "books", amount: 10 },
];

const matched = orders.filter((o) => o.status === "PAID");
const grouped = [...matched.reduce((map, o) => {
  const key = o.category;
  const cur = map.get(key) || { _id: key, total: 0, count: 0 };
  cur.total += o.amount;
  cur.count += 1;
  map.set(key, cur);
  return map;
}, new Map()).values()];

console.log(grouped);

When you click Run, you should see grouped totals for books and tools with PAID orders only.

A strong answer is:

$match reduces the working set; $group aggregates by _id—I always filter before grouping and index $match predicates when this runs in production.

$lookup performs a left outer join to another collection:

db.orders.aggregate([
  { $match: { status: "PAID" } },
  {
    $lookup: {
      from: "customers",
      localField: "customerId",
      foreignField: "_id",
      as: "customer"
    }
  },
  { $unwind: "$customer" }
]);

Cost: for each input doc, lookup queries foreign collection—index foreignField.

Prefer embedding or denormalized fields on read-heavy paths; $lookup for occasional reports.

A strong answer is:

$lookup is a join—I index the foreign field, match first, and denormalize when the join runs on every user-facing request.

$unwind expands array fields into one document per element:

{ $unwind: "$items" }

Use preserveNullAndEmptyArrays: true to keep docs with empty arrays.

$facet runs parallel sub-pipelines on the same input—e.g. return paginated results + total count in one round trip:

{
  $facet: {
    data: [{ $sort: { createdAt: -1 } }, { $limit: 20 }],
    meta: [{ $count: "total" }]
  }
}

A strong answer is:

$unwind normalizes arrays for per-item analytics; $facet bundles multiple report branches without multiple client queries.

Some stages ($sort, $group, large $lookup) buffer data in memory—default 100 MB limit per stage.

allowDiskUse: true spills to disk when needed—slower but completes large jobs.

Better: filter earlier, index, project fewer fields, or pre-aggregate in application/batch layer.

A strong answer is:

I treat allowDiskUse as a safety valve—I redesign pipelines that routinely hit memory limits instead of relying on disk spill in production hot paths.

A replica set is a group of MongoDB nodes with the same data:

Automatic failover elects new primary (typically seconds). Use odd member count for elections (3 nodes common).

Read scaling: secondaryPreferred—accept replication lag trade-off.

A strong answer is:

Replica sets give HA and optional read scaling—I deploy at least three voting members and set read concerns when staleness matters.

Oplog (operations log) is a capped collection recording writes on the primary. Secondaries tail the oplog to stay in sync.

Also powers:

• Change streams (real-time notifications)
• Backup coordination
• Replication lag monitoring

Lag spikes indicate network, disk, or heavy write load secondaries cannot keep up with.

A strong answer is:

The oplog is the replication journal—I monitor replication lag and oplog window when writes spike or secondaries fall behind.

Sharding partitions data across shards (each a replica set) for horizontal scale.

Components:

Use when one replica set cannot hold data size or write throughput—not as default day one.

A strong answer is:

I shard when a single replica set hits storage or write limits—not prematurely; sharding adds operational complexity and immutable shard key choice.

Good shard key:

Bad: monotonic createdAt alone—all writes to one chunk.

Better: hashed _id, or compound { tenantId: 1, orderId: 1 } for multi-tenant apps.

Shard key is immutable per document—choose carefully.

A strong answer is:

I pick high-cardinality keys that spread writes and match query patterns—never a monotonic timestamp alone without hashing or compound tenant prefix.

Since 4.0 (replica sets) / 4.2 (sharded), multi-document ACID transactions are supported:

const session = db.getMongo().startSession();
session.startTransaction();
try {
  const orders = session.getDatabase("shop").orders;
  const inventory = session.getDatabase("shop").inventory;
  orders.insertOne({ ... }, { session });
  inventory.updateOne({ sku: "A1" }, { $inc: { stock: -1 } }, { session });
  session.commitTransaction();
} catch (e) {
  session.abortTransaction();
} finally {
  session.endSession();
}

Trade-offs: performance cost, 16 MB limit, timeouts—prefer single-document designs when possible.

A strong answer is:

I use transactions when multi-document atomicity is required but design single-document updates first because transactions add latency and limits in MongoDB.

Write concern — acknowledgment level:

Read concern — visibility:

Payment systems often use w: majority + readConcern: majority.

A strong answer is:

Write concern controls durability; read concern controls staleness—I tune both for financial vs analytics workloads explicitly.

Native driver or Mongoose ODM (schemas, middleware, population).

const orderSchema = new Schema({
  customerId: { type: ObjectId, ref: "Customer", required: true },
  total: { type: Number, min: 0 },
  status: { type: String, enum: ["PENDING", "PAID"], default: "PENDING" }
}, { timestamps: true });

See Node.js interviews for async patterns. Avoid N+1 populate like SQL N+1—use aggregation or embed.

A strong answer is:

I use Mongoose or the native driver with explicit schema validation, connection pooling, and aggregation for reports instead of deep populate chains.

Change streams watch oplog for insert/update/replace/delete on a collection, database, or cluster:

const cursor = db.orders.watch([{ $match: { "fullDocument.status": "PAID" } }]);

Use for event-driven integrations, caches, search index sync—requires replica set.

A strong answer is:

Change streams turn database writes into events—I use them for downstream sync when polling is too slow or wasteful.

Never deploy with no auth exposed to internet—historical ransomware targeted open MongoDB.

A strong answer is:

Auth, TLS, network isolation, and least-privilege roles—I never expose an unauthenticated MongoDB instance to the public internet.

Test restore drills—untested backups are wishful thinking.

A strong answer is:

I automate backups with point-in-time recovery where required and run quarterly restore tests to a staging cluster.

Interviews accept either if you explain operational reasoning.

A strong answer is:

Atlas trades control for speed of operations; self-hosted fits strict data residency or teams with strong DBA capacity—I pick based on ops maturity and compliance.

Group measurements into one document per time bucket (e.g. hour) with arrays of readings:

{
  sensorId: "s-1",
  hour: ISODate("2026-06-28T10:00:00Z"),
  readings: [
    { t: ISODate("..."), v: 42.1 },
    { t: ISODate("..."), v: 42.3 }
  ]
}

Reduces document count vs one doc per reading. MongoDB 5.0+ time series collections optimize storage further.

A strong answer is:

I bucket time-series data to limit document churn and use time series collections when the workload is append-only metrics.

Store frequently accessed fields embedded and full detail in a separate collection:

• Product list: name, price, thumbnail embedded
• Full spec sheet: referenced or separate doc loaded on detail page

Balances document size vs read patterns.

A strong answer is:

The subset pattern keeps hot list views small while full documents load on demand—I match embed size to actual UI needs.

Patterns:

No automatic ALTER TABLE—plan migrations like application releases.

A strong answer is:

I version documents and migrate lazily or in batch jobs with backward-compatible readers during rollout.

Compare with SQL EXPLAIN workflow.

A strong answer is:

I explain the query, add or fix indexes for filter and sort, reduce scanned documents, and verify cache pressure—not guess indexes from habit.

Likely poor shard key—monotonic or low-cardinality key funneling writes to one chunk.

Mitigations:

• Reshard to new key (MongoDB 5.0+ online resharding—planned, not casual)
• Hashed shard key on high-cardinality field
• Compound key with tenant prefix for even spread

Prevention: load-test shard distribution before production cutover.

A strong answer is:

Hot shards mean uneven key distribution—I diagnose the shard key monotonic pattern and plan resharding or a better compound/hashed key with ops review.

WiredTiger is MongoDB's default storage engine (since 3.2):

Monitor cache hit ratio and eviction pressure under load.

A strong answer is:

WiredTiger provides document-level concurrency and compression—I size RAM so the working set fits cache for steady-state performance.

Map-reduce was the legacy batch processing model—aggregation pipeline replaced it for almost all use cases: faster, sharding-aware, easier to read.

Mention map-reduce only for maintaining legacy codebases.

A strong answer is:

I use aggregation pipelines for all new analytics; map-reduce is legacy knowledge only.

Create text index on string fields:

db.articles.createIndex({ title: "text", body: "text" });
db.articles.find({ $text: { $search: "mongodb indexing" } }, { score: { $meta: "textScore" } })
  .sort({ score: { $meta: "textScore" } });

For advanced search at scale, teams often integrate Atlas Search (Lucene) instead of basic text indexes.

A strong answer is:

Built-in text indexes cover simple search; Atlas Search or Elasticsearch fits fuzzy ranking and heavy search products.

Prefer $set, $inc, $push for surgical updates.

A strong answer is:

I use update operators for partial changes; replaceOne only when intentionally swapping the whole document shape.

Checklist:

• Embed vs reference with real examples from your domain
• Compound index + ESR for a sample query
• explain("executionStats") — IXSCAN vs COLLSCAN
• Aggregation: $match → $group → $sort
• Replica set failover and read/write concerns
• Shard key good vs bad examples
• Transactions limits and when to avoid them
• One slow query and one failover STAR story
• SQL comparison for relational trade-offs
• Full stack integration narrative

A strong answer is:

I rehearse schema, indexes, and one aggregation on paper, then explain replication and sharding with a production anecdote—not bullet definitions without context.