Interview at Company X

Here are the questions asked during my interview at Company X.

Questions

1. What is a transaction in a database?

A transaction is a single logical unit of work that accesses and possibly modifies the contents of a database. Transactions are often expected to have the ACID properties:

• Atomicity: All operations in the transaction succeed or the entire transaction is rolled back.
• Consistency: The database moves from one valid state to another.
• Isolation: Transactions are executed as if they are the only one in the system.
• Durability: Once a transaction is committed, it will remain so, even in the event of power loss.

2. What is CAP theory?

CAP theorem states that a distributed data store can only provide two of the following three guarantees:

• Consistency: Every read receives the most recent write or an error.
• Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
• Partition Tolerance: The system continues to operate despite an arbitrary number of messages being dropped or delayed by the network between nodes.

In the presence of a network partition (P), one must choose between Consistency (C) and Availability (A).

3. What is the difference between a B-tree and a Binary Search Tree (BST)?

• Structure: A BST is a binary tree (max 2 children), whereas a B-tree is a self-balancing network tree where nodes can have multiple children (order m).
• Usage: BSTs are typically used for in-memory lookups. B-trees are optimized for storage systems (databases, filesystems) because they minimize disk I/O by storing keys in large blocks (pages) and having a shallow height.
• Balance: Standard BSTs can become unbalanced (skewed), leading to O(n) search time. B-trees are always balanced, guaranteeing O(log n).

4. What is a Bloom filter?

A Bloom filter is a space-efficient probabilistic data structure used to test whether an element is a member of a set.

• It returns either “possibly in set” or “definitely not in set”.
• False positives are possible, but false negatives are not.
• It uses multiple hash functions to map an element to positions in a bit array.
• Commonly used in databases (e.g., Cassandra, PostgreSQL) to avoid expensive disk lookups for non-existent rows.

5. What is the difference between HTTP/1, HTTP/2, and HTTP/3?

• HTTP/1.1: Text-based protocol. It suffers from Head-of-Line (HOL) Blocking because it must handle one request at a time per TCP connection (though Pipelining exists, it’s rarely supported). It requires multiple TCP connections to load a page in parallel.
• HTTP/2: Binary protocol that introduces Multiplexing. It allows multiple requests/streams over a single TCP connection, solving HTTP/1.1’s HOL blocking. However, it still suffers from TCP HOL blocking (if one packet is lost, the entire TCP stream waits). Header compression (HPACK) is also introduced.
• HTTP/3: Built on top of QUIC (UDP) instead of TCP. It solves the TCP HOL blocking issue because streams are independent at the transport layer. Connection establishment is faster (1-RTT or 0-RTT) and it handles network switching (e.g., Wifi to Cellular) smoothly via Connection IDs.

6. What is a signature in security?

A digital signature is a cryptographic mechanism used to verify the authenticity and integrity of digital data. It is the digital equivalent of a handwritten signature or stamped seal, but far more secure.

• Authenticity: Guarantees the message came from the claimed sender (because only they have the private key).
• Integrity: Guarantees the message was not altered in transit (because any change would invalidate the signature verification).
• Non-repudiation: The sender cannot deny having sent the message (because only they could have created the signature).

How it works:

1. Hash: The data is hashed (e.g., SHA-256) to create a fixed-size digest.
2. Sign: The hash is encrypted with the sender’s Private Key. This encrypted hash is the “signature”.
3. Verify: The recipient decrypts the signature using the sender’s Public Key to get the original hash, then hashes the received data themselves. If both hashes match, the signature is valid.