MongoDB Developer Associate common mistakes
MongoDB Developer Associate · Understand the traps and how to avoid them.
When asked to insert several documents with the Node.js driver, the candidate issues one await collection.insertOne(...) per document inside a for loop instead of a single insertMany call, and then cannot answer follow-up questions about ordered vs unordered writes.
Tutorials teach insertOne first, and the loop pattern feels safe because each failure is isolated; candidates never connect the bulk-write API to the ordered option and writeConcern behaviour that the exam probes.
What to do instead
Practise writing insertMany([...], {ordered: false}) and be able to state exactly what happens to remaining documents when document 3 of 10 violates a unique index: with ordered true the batch stops, with ordered false the rest continue and the error reports the failing indexes.
The candidate answers a query-performance question by saying 'add an index' without specifying the exact index key pattern and sort order that matches the query's equality fields, range field, and sort, and without mentioning explain().
Indexing is memorised as a single verb rather than as a design step; candidates skip the ESR (equality, sort, range) ordering rule and never verify with an execution plan.
What to do instead
For any query, write the compound index explicitly, e.g. a query filtering status equality, sorting by createdAt descending, and ranging over amount needs {status: 1, createdAt: -1, amount: 1}. Then run explain('executionStats') and confirm totalKeysExamined equals nReturned and stage is IXSCAN, not COLLSCAN.
On a question about atomicity, the candidate claims MongoDB transactions are required to update two fields in one document, or claims a multi-document transaction works on a standalone server.
Relational instincts carry over: candidates assume any multi-step write needs a transaction, and they have never actually run one outside a replica set.
What to do instead
State the rule precisely: single-document writes are always atomic, including updates to multiple fields and $push/$inc operators. Multi-document transactions require a replica set or sharded cluster (not standalone), and the session must be passed to every operation. Practise startSession, withTransaction, and commitTransaction in a local single-node replica set.
The candidate writes an aggregation pipeline that filters with $match after a $group or $lookup, producing a stage order that forces the server to process every document, and then cannot explain why the pipeline is slow.
Candidates translate SQL mentally (filter after aggregating) instead of thinking about document flow through stages; the pipeline is written left to right without reordering.
What to do instead
Always place $match and $limit as early as possible, before $group and $lookup, so indexes can be used. Rewrite the pipeline so the first stage is an indexable $match, and be ready to explain that $match before $group reduces input while $match after $group filters aggregated output and cannot use the collection index.
For a Java question using the synchronous driver, the candidate filters with new Document("age", new Document("$gt", 30)) but forgets that the collection type parameter and codec registry must match the POJO, or mixes the legacy MongoClient API with the current com.mongodb.client packages.
Older tutorials and Stack Overflow answers use deprecated classes (Mongo, DB, DBCollection) and untyped collections, so the candidate reproduces code that does not compile against the modern driver.
What to do instead
Memorise the current import surface: com.mongodb.client.MongoClient, MongoClients.create(connectionString), MongoDatabase, MongoCollection, and com.mongodb.client.model.Filters.gt("age", 30). For POJOs use PojoCodecProvider and CodecRegistries, and know that Filters and Updates are the static helper classes rather than raw Document nesting.
The candidate designs a schema by normalising everything into separate collections and joining at read time with $lookup, then cannot justify the choice when the exam describes an embeddable one-to-few relationship.
Relational modelling habits dominate, and candidates treat embedding as a shortcut rather than a deliberate decision based on access patterns and document growth.
What to do instead
Apply the decision rule out loud: embed when data is accessed together, the child set is bounded, and the parent document stays well under 16 MB; reference when the child set is unbounded or shared across parents. For a bounded one-to-few such as a user's shipping addresses, embed an array; for a one-to-many such as millions of log entries, reference.
On a Python question, the candidate writes collection.find_one({"name": "x"}) and then treats the returned value as a dictionary without checking for None, or iterates a cursor twice and gets nothing the second time.
PyMongo returns a dict or None from find_one and a lazy, single-pass cursor from find, but candidates assume list-like repeatable behaviour from other drivers.
What to do instead
Always guard find_one results with an explicit None check, and materialise a cursor once with list(collection.find(query)) when it must be traversed more than once. Also remember PyMongo requires ObjectId from bson for _id values rather than a plain string.
The candidate cannot distinguish read concern from write concern, answering that w: "majority" guarantees a document is durable on disk, or that readConcern "majority" prevents reading uncommitted data in all cases.
Both concepts are named 'concern' and are studied together, so their separate roles in the consistency model blur; candidates memorise the option names without their guarantees.
What to do instead
Separate them clearly: write concern (w, j, wtimeout) governs acknowledgement and durability of writes, where j: true forces the journal; read concern governs the isolation and consistency of data returned, where "local" may show data later rolled back and "majority" returns only data acknowledged by a majority. Know that "snapshot" is available in transactions and on majority-read-enabled deployments.
When asked to update a nested field, the C# candidate writes an update with Builders<BsonDocument>.Update.Set("address.city", ...) on a strongly typed model but uses the wrong member-expression overload, or uses ReplaceOne when the requirement is to change a single field and preserve the rest.
The typed builder API offers several overloads that look interchangeable, and candidates default to replace semantics because they are simpler to reason about.
What to do instead
Use the member-expression overload, Update.Set(x => x.Address.City, "Berlin"), so the field name is derived from the model and refactoring-safe. Reserve ReplaceOne for full-document replacement and remember it drops any fields absent from the replacement document; use Update.Set, Update.Inc, or Update.Push for partial changes.
The candidate picks a shard key by intuition (for example _id or a low-cardinality status field) and cannot explain why it causes hot shards or scatter-gather queries.
Sharding is studied as a list of components (mongos, config servers, shards) rather than as a distribution problem, so key selection criteria are never internalised.
What to do instead
Evaluate any candidate shard key against four properties: high cardinality, low frequency, non-monotonic values, and presence in most queries. Explain that a monotonically increasing _id sends all inserts to one chunk (hot shard) and that a query without the shard key becomes a scatter-gather across all shards. Prefer a compound key such as {tenantId: 1, createdAt: 1} with a hashed or ranged strategy chosen deliberately.