Learning from job interviews

I had a job interview that went terribly recently. The interviewer was very knowledgeable in a wide variety of fields.

Many of the questions he asked me on the spot was not something that was too unexpected. However, I found my self unable to answer them on the spot. Thus, I have decided to summarize the questions below to refresh myself before every interview. I hope this resource helps others in need as well.

Operating Systems #

What are the difference between Processes and Threads? #

What are the different ways of inter-process communication between them? Which one of them is the fastest? #

Requires synchronizations (Using locks / semaphores) #

1. Shared memory (With semaphores)
   1. The fastest as memory does not have to be copied from 1 part to another
   2. Pros:
      1. Very fast communication
      2. Bidirectional communication
      3. Resources are saved
      4. Never blocks
      5. Can be accessed by multiple programs
   3. Cons:
      1. Require concurrency control
      2. No data protection
      3. Inconsistency of data occurrences as updates are lost.
2. Shared files

Does not require synchronizations #

3. Piped (Named and unnamed)
   1. Framing problem
      1. Multiple readers can tear the message up
      2. Multiple writers can overwrite each other
4. Message Queues
   1. Pros:
      1. Can be used in a distributed way without any shared variables
      2. Very easy to implement
   2. Cons:
      1. Communication is slower as it takes time to setup communication links between processes
5. Sockets (Sync)
   1. Pros
      1. They are synchronized
   2. Cons
      1. Slower as they go through the OS.
      2. Can only read/write in a linear fashion
      3. Blocks
6. Signals (Async)
   1. Pros:
      1. Can happen any time
   2. Cons:
      1. Used for only a small amount of information.

Useful links #

1. opensource.com.
2. oracle.com.
3. watelectronics
4. jmu.edu

What are some scenarios where one would use sockets instead of shared memory? #

Pros of sockets #

1. Blocking and non-blocking modes
2. No freeing required when using sockets
3. No need for synchronization
4. Easier to implement for distributed computing

Pros of shared memory #

1. Can write in a non-linear fashion
2. Never blocks
3. Can be accessed by multiple processes
4. Fixed memory size

Why sockets instead of shared memory? #

1. Easier to implement
2. Dealing with linear data

Networking #

What happens when you key a website into a browser? #

1. The domain of the site is checked against a DNS Server
   1. If there is a cache hit, the IP address of the website is returned
   2. Otherwise
      1. DNS servers can serve either recursively or iteratively to find the IP address(s) of the domain
2. The browser then connects to the IP address of the website and initiates the TCP connection with the webserver
   1. TCP has a 3 way handshake.
      1. More details here
   2. This can be the CDNs that are set up by the webserver or the actual server itself.
   3. Generally a web request is a http or https request. However, other requests are also accepted
      1. ftp://
      2. mailto://
      3. file://
   4. If HTTPS is used, a TLS handshake takes place
      1. Server present the client with their certificate.
      2. Client verifies the certificate recursively until it reaches a root certificate that is installed on the system and trusted.
      3. Using the public and private keys of the server, the client and the server shares chooses an exponent (a & b) decides on a common message (g)
      4. They will then send over (g, g^a mod p, g^b mod p) where p is a large and safe prime number
      5. They can use it to compute the shared secret (g^ab mod p)
      6. Every communication from then onwards will be encrypted using the shared secret and a shared scheme (rsa, aes, etc)
      7. More details here
3. The browser then sends a HTTP(S) request to the server to request for the relevant network resources.
4. The server processes the request and sends a response to the client.
5. The browser receives the response and renders its contents
   1. Rendering is done using the engines that is used by the browser (IE: v8 for Chromium based browsers)

Useful links #

1. TLS Handshake process
2. What happens when u key in a url in your browser
3. What is a DNS
4. TLS handshake

Why does TCP requires a 4 way handshake to terminate? #

There are 2 ways to terminate a TCP Connection.

1. Graceful Connection release
2. Abrupt connection release

In this case we are going to talk about the Graceful Connection release.

How does it work?

1. The client send a TCP packet with a FIN bit set in the TCP header
2. The server acknowledges the packet and sends an ACK packet back to the client
3. The server then sends a FIN packet to the client
4. The client sends an ACK to the server

Sometimes the server may send the FIN packet together with the ACK packet for the client FIN packet.

Useful links #

1. TCP Termination
2. Why does TCP require a 4 way termination handshake

How does the certificate work? #

Before we talk about certificate, lets talk about where it will be used.

During HTTPS, the client and the server will perform a TLS handshake (On top of TCP).

The message includes the following (Versions earlier than TLS 1.3):

1. Client Hello
   1. The client initiates the handshake by sending a “hello” message to the server which includes the TLS version supported by the client, cipher suites and random bytes
2. Server hello
   1. Server replies to the client hello with a server hello, including the Server’s SSL’s certificate, chosen cipher suite and another random string generated by the server
3. Authentication
   1. The client verifies the Server’s SSL certificate.
4. Pre-master secret
   1. The client sends one more random string of bytes.
   2. This is encrypted with the public key of the server and can only be decrypted by the private key of the server
5. The server decrypts the pre-master secret
6. Creation of session keys
   1. Both client and server generates the session keys from the client random, server random and the pre-master secret
   2. They will arrive at the same result
7. Client sends a finished message encrypted with the session key
8. Server sends a finished message encrypted with the session key
9. After the handshake completes, the client and server will use the session key to encrypt and decrypt all the messages that they send to each other.

During the server hello step, the certificate is sent from the server to the client.

The image below shows the certificate chain.

The certificate that is sent by the server is the End-entity certificate which is the certificate that is signed by the Intermediate CA. The Intermediate CA’s certificate is signed by the Root CA. The Root CA is a self signed certificate that is installed on the client’s system and is trusted.

The client will continue to traverse up the certificate tree during the verification process until it reaches a root CA that is installed on the client’s system and is trusted. Otherwise, the connection will be marked as not secure.

Useful link #

1. How does SSL work
2. What happens in a TLS handshake
3. Certificate Verification

Are there any processes that have been done to optimize the handshake? #

HTTP 2.0 #

Pros

1. Header compression
   1. HTTP 2.0 uses a binary framing layer to create a stream for communication.
   2. During the time of interaction, the TCP connection remains open for the request and response which improves the overall performance
2. Multiplexing
   1. Enables HTTP 2.0 to send multiple network connections over a single TCP connection
   2. This is made in an asynchronous manner
   3. This reduces the latency manifold.
3. Resource and stream prioritization
   1. This is a feature that allows essential resources to load first.
   2. This developers will need to associate dependency levels which allows the clients to consume only the code to that specific webpage.
4. Server Push
   1. This improvement allows servers to send resources to clients before they are requested instead of letting the browser load some HTML to decide what other assets to download
   2. This pushes assets ahead of time and caches them to improve performance.

Cons

1. The HTTP 2.0 Server push is very tricky to implement and integrate into existing applications
2. TCP level blocking still caused issues with server loading times
3. The concurrent requests used by HTTP 2.0 caused an increase in server load, thus leading to request timeouts
4. Clients on a slow network will have their packets gradually dropped, resulting in only a single HTTP 2.0 connection.
   1. This blocks the loading times of data transfer from the client to the server and the server to the client

Improvements in HTTP 3.0 #

While HTTP 1.1 and HTTP 2 are mainly done over TCP connections, HTTP 3.0 is done over Quick UDP Internet Connections (QUIC). which is a UDP based protocol

QUIC is build on to of UDP and interfaces with HTTP/3 directly. The diagram below illustrates the differences between the 2 protocols.

QUIC uses a single handshake to establish a secure connection and the connection is encrypted in the transport layer.

Pros over HTTP 2.0

1. QUIC instead of TCP is used
2. Has a much quicker hand shake compared to HTTP 2.0
3. Encryption by default.
4. Decreases the effect of packet loss
5. 0 Round trip time
   1. For servers which clients are already connected to, the client can skip the handshake altogether and start sending data immediately.

Useful links #

1. HTTP 2.0 vs HTTP 3.0
2. What is new in HTTP 3.0