This post is another question that I failed to answer in a structured manner in an interview that I thought was going to be non-technical and more about my experience. You can read more about the background in my previous post

Compare NoSQL and SQL

NoSQL and SQL databases are two different database management systems, each with its own strengths and use cases. So what do they do differently?

SQL Database (Relational Database)

  1. Data Structure: SQL databases follow a rigid, structured data model based on tables with predefined schemas. They enforce strong data consistency, integrity, and relationships through the use of primary and foreign key constraints.
  2. Querying: SQL databases use the Structured Query Language (SQL) for querying and manipulating data. SQL provides a standardized and powerful set of operations to retrieve, filter, join, and aggregate data from multiple tables.
  3. ACID Transactions: SQL databases typically support ACID (Atomicity, Consistency, Isolation, Durability) transactions, ensuring that database operations are either fully completed or rolled back in case of failures, maintaining data integrity.
  4. Scalability: SQL databases are designed for vertical scalability, where additional resources (CPU, memory) are added to a single server to handle increased load. Horizontal scalability (scaling out to multiple servers) is possible but often requires more complex setups like sharding or replication.
  5. Data Relationships: SQL databases excel at handling complex relationships between data entities through the use of joins, foreign keys, and relational algebra. They are suitable for applications with highly structured data and complex queries.

NoSQL Database (Non-relational Database)

  1. Data Structure: NoSQL databases have a flexible, schema-less data model. They can handle unstructured, semi-structured, or varying data formats. The lack of a predefined schema allows for greater agility and adaptability.
  2. Querying: NoSQL databases use various querying mechanisms, such as key-value lookups, document-based queries, graph traversals, or column-based queries. The query capabilities are often tailored to the specific data model used by the database.
  3. Scalability: NoSQL databases are designed for horizontal scalability. They can distribute data across multiple nodes, enabling seamless scalability to handle high traffic and large datasets. This scalability is achieved through techniques like sharding, replication, or data partitioning.
  4. Performance: NoSQL databases can offer high performance and low-latency access to data due to their distributed nature and optimized data models. They are suitable for use cases that require massive read or write throughput, such as real-time analytics or high-volume web applications.
  5. Data Relationships: NoSQL databases may not handle complex relationships between data entities as efficiently as SQL databases. However, they often provide mechanisms like denormalization, embedding related data, or supporting graph databases to handle relationships.


SQL databases are well-suited for applications with structured data, complex relationships, and a need for strong data integrity and consistency. NoSQL databases are a better fit for applications with rapidly changing requirements, unstructured or semi-structured data, and the need for horizontal scalability and high performance. The choice between the two depends on the specific requirements, data models, and scalability needs of the application.

I did pretty much cover most of what I answered in the summary. But I guess the interviewers lost interest in me as I had not clearly answered the earlier question.

What did I take away from my experience

  1. Always refresh your technical knowledge before going into an interview even if it isn’t a technical interview. THis helps you give structured answers rather than just read randomly from your memory. Especially if you haven’t used any of those tech in the last 2 years.
  2. Different roles might need different skills. Thus those hiring could be looking for either the technical engineering manager - someone who is more of a technical lead than a people leader or vice versa. Don’t feel like you weren’t good enough if you didn’t suit the role. You don’t have to fit in.
  3. Having reviewed my experience so far, I should be applying for Head of Engineering or beyond roles