Preparing for Backend Interviews: SQL and NoSQL Essentials
Hi, I’m Oluwatosin Thompson, a Backend Engineer specialising in Go (Golang) and passionate about creating reliable, scalable, and efficient backend systems that power great products.
I’ve built and maintained production-grade services using Temporal, Prometheus, and AWS, with a strong emphasis on performance optimisation, distributed systems, and clean, maintainable code. My work reflects a balance between technical excellence and real-world business impact.
I enjoy sharing my learning journey through technical writing and documenting how I solve engineering challenges. Known for being teachable, adaptable, and detail-oriented, I’m always eager to take on complex problems and deliver elegant solutions.
I’m committed to engineering growth, collaboration, and continuous improvement, with a long-term goal of building impactful systems used worldwide.
When you’re walking into a backend engineering interview, there are two topics you will almost always face: SQL and NoSQL. It doesn’t matter if you’re targeting a traditional enterprise role, a startup building microservices, or a systems-focused engineering position; interviewers want to see that you can model data, reason about tradeoffs, and think about performance and reliability.
This article serves as your guide to preparing for SQL and NoSQL interview questions, providing the right depth for backend engineers.
Why SQL and NoSQL Matter
SQL (Relational Databases): Think PostgreSQL, MySQL, Oracle - these shine when you need structured data, relationships, transactions, and guaranteed consistency.
NoSQL (Non-Relational Databases): Think MongoDB, DynamoDB, Cassandra -these shine when you need flexibility, scale, and fast reads/writes across distributed systems.
Interviews often test not just your knowledge of each, but your ability to compare them, explain tradeoffs, and choose the right tool for the job.
SQL Fundamentals to Master
1. ACID Properties
Transactions in SQL databases follow ACID:
Atomicity – All steps succeed or none do.
Consistency – Data moves from one valid state to another.
Isolation – Transactions don’t interfere with each other.
Durability – Once committed, the data is permanent.
💡 Interview angle: “Why is isolation important in transactions?” or “Can you explain a situation where durability is critical?”
2. Normalisation vs Denormalisation
Normalisation – Splitting data into multiple tables to remove redundancy and ensure data integrity.
- Example: Users in one table, Orders in another, linked with foreign keys.
Denormalisation – Merging tables or duplicating data to optimise for read performance.
- Example: Embedding user info directly into orders for quick retrieval.
💡 Interview angle: Expect scenarios like “How would you design a schema for an e-commerce app? Normalise or denormalise?”
3. Transactions
A transaction groups multiple operations into a single unit of work.
Start → Perform queries → Commit (or Rollback if errors).
Useful in banking, inventory, or any workflow needing consistency.
💡 Interview angle: “Design a system where users transfer money between accounts.”
4. Joins and Relationships
INNER JOIN, LEFT JOIN, RIGHT JOIN, FULL JOIN – Know how and when to use them.
One-to-one, one-to-many, many-to-many relationships – The bread and butter of relational design.
💡 Interview angle: “How would you fetch all users who have never placed an order?”
5. Indexes
Indexes speed up queries but slow down writes.
Clustered index: Sorts the actual table.
Non-clustered index: Separate structure pointing to table rows.
💡 Interview angle: “Why might adding too many indexes hurt performance?”
NoSQL Fundamentals to Master (MongoDB focus)
1. Types of NoSQL Databases
Document (MongoDB) – JSON-like documents.
Key-Value (Redis, DynamoDB) – Super-fast lookups.
Columnar (Cassandra, HBase) – Wide tables, great for analytics.
Graph (Neo4j) – Perfect for relationships like social networks.
Most interviews stick to MongoDB, but know the landscape.
2. Document Model
MongoDB stores data as documents (BSON).
Documents can embed nested objects.
Great for flexible schemas.
💡 Example: Instead of joining Orders and Users, just embed user info inside the order document.
3. Denormalisation and Embedding
Embed when: Data is accessed together most of the time.
Reference when: Data is reused in multiple places and updated frequently.
💡 Interview angle: “Would you embed product details inside order documents?”
4. CAP Theorem
In distributed databases, you can’t have all three:
Consistency – All nodes see the same data.
Availability – Every request gets a response.
Partition Tolerance – System keeps working despite network failures.
MongoDB trades strong consistency for availability under partition scenarios, but offers tunable consistency via read/write concerns.
💡 Interview angle: “What happens if one MongoDB replica node goes down?”
5. Indexes and Querying in MongoDB
Indexes also exist in MongoDB for performance.
Queries can use operators like
$in,$gt,$lookup(for joins-like behaviour).
💡 Interview angle: “How would you optimise a query that’s scanning millions of documents?”
6. Transactions in MongoDB
MongoDB supports multi-document transactions (since v4.0), but the design philosophy encourages schema modelling to minimise their need.
Comparing SQL vs NoSQL
| Feature | SQL (Relational) | NoSQL (MongoDB, etc.) |
| Schema | Fixed, predefined | Flexible, dynamic |
| Relationships | Strong (joins) | Weak (manual, via embedding) |
| Transactions | Full ACID support | Limited, newer support |
| Scaling | Vertical (scale-up) | Horizontal (scale-out) |
| Best for | Consistency, integrity | Speed, flexibility, scale |
💡 Interview angle: “When would you pick SQL vs MongoDB for a ride-sharing app?”
How to Practice for Interviews
Hands-on Practice:
Write SQL queries on LeetCode, HackerRank, or a local Postgres DB.
Build a sample MongoDB schema for a small project (blog, e-commerce).
Explain Tradeoffs Out Loud:
- Interviewers love it when you reason about design choices, not just code.
Prepare Real-Life Scenarios:
Banking app → SQL (transactions, consistency).
Analytics dashboard → NoSQL (speed, scale).
Short interview-ready answers (practice these out loud)
Q: “Why would you denormalise?”
A: “To reduce join cost for read-heavy paths and meet latency SLOs. I’d denormalise only for the queries that need it and add an update plan (events or background sync) to keep denormalised copies consistent.”Q: “What do you check when a query is slow?”
A: “Run EXPLAIN/EXPLAIN ANALYZE, compare estimated vs actual rows, check indexes and statistics, test with representative parameters, and if necessary, add a covering/partial index or rewrite the query.”Q: “How would you pick a shard key?”
A: “Pick a high-cardinality, evenly-distributed field that query patterns include; avoid monotonic keys. If multi-tenant, tenantId+userId hashed is a good start.”
Final Thoughts
SQL and NoSQL aren’t competitors - they’re tools. What impresses interviewers is your ability to:
Explain why you’d use one over the other.
Write queries and model schemas correctly.
Think about performance, scaling, and tradeoffs.
If you can confidently walk through these topics, you’re already ahead of most candidates.
