MongoDB interview questions

Embed or reference

The defining question. The answer is always driven by access pattern, and interviewers want to hear that reasoning rather than a rule.

• Embed when the child is read with the parent, is bounded in size, and changes with it - order line items, an address.
• Reference when the child is large, unbounded, shared between parents, or updated independently.
• The unbounded array problem - comments embedded in a post that grows forever, eventually hitting the document size limit.
• Duplication is acceptable here in a way it is not in a relational schema, and you should be able to say what it costs: every copy must be updated.

Indexes and queries

• Compound index field order, and the prefix rule - an index on (a, b, c) serves queries on a, on a+b, and on a+b+c, but not on b alone.
• How do you find out why a query is slow? `explain()`, and looking at whether it used an index or scanned the collection.
• Multikey indexes on arrays and their limitations.
• TTL indexes for expiring data.
• The aggregation pipeline - `$match` early to reduce documents before `$group`, and why stage order matters for performance.

Consistency and scale

• Replica sets - primary and secondaries, elections, and what reading from a secondary costs you in freshness.
• Write concern and read concern, and what `majority` buys.
• Are transactions supported? Yes, across documents since 4.0 - with the caveat that needing them often signals the schema is fighting the database.
• Sharding, choosing a shard key, and what a poor key does - hot shards and unbalanced growth.

The comparison question

"Why Mongo over Postgres?" A defensible answer names genuinely variable document shapes, a read pattern that matches the document boundary, and horizontal scaling needs - and concedes that for highly relational data with ad-hoc queries, Postgres is usually the better tool, particularly now that it handles JSONB well. The relational counterpart is in PostgreSQL interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus a schema you have designed around real access patterns. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: sharding decisions and a migration you have run on live data. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a MongoDB interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common MongoDB interview questions?

When to embed versus reference, compound index field order and the prefix rule, the aggregation pipeline and stage ordering, replica sets with write and read concerns, and choosing a shard key.

When should you embed instead of reference in MongoDB?

Embed when the child data is read together with the parent, is bounded in size, and changes alongside it. Reference when it is large, unbounded, shared across parents, or updated independently - the unbounded embedded array is the classic design failure.

Is MongoDB really schemaless?

The database does not enforce a schema, but your application always has one - it just lives in code rather than in the database. Mature deployments add schema validation deliberately, and recognising this distinction is what the question is testing.

When is PostgreSQL a better choice than MongoDB?

When data is highly relational, when you need ad-hoc queries across entities, or when strong transactional guarantees across many records are central. Postgres also handles semi-structured data well through JSONB, which narrows MongoDB's traditional advantage.