ORM and Data Access

ORM and data access interviews test whether you can design persistence boundaries—not whether you memorized one library API. Strong answers compare patterns (Active Record, Data Mapper, repository, Unit of Work), loading strategies, migrations, transactions, and tool trade-offs before naming Prisma or TypeORM.

This domain spans general concepts, Mongoose for MongoDB documents, Prisma, Drizzle, MikroORM, and TypeORM in TypeScript backends.

On interviews: given a feature, explain where persistence code lives, how you prevent N+1, how schema changes deploy safely, and when hand-written SQL or a thinner query layer is clearer.

Common pitfalls: generic repositories with no use-case shape; transactions around every request; trusting generated migrations blindly; treating document ORMs like relational databases.

The trade-off is developer speed and type safety versus SQL visibility, operational discipline, and clear domain boundaries.

Checklist:

• Start from access patterns and invariants.
• Name loading, migration, and transaction strategy.
• Compare tools by modeling style and ops risk.
• Use child topics for stack-specific depth.