This post is about what to prepare for technical interviews for any software engineer entry to mid level

Technical interview processes vary widely across companies, but most typically involve several types of rounds, each focusing on a different skill set. Here’s a breakdown of what to expect and how to prepare.

Types of Rounds:

1. DSA Coding interview

2. Machine coding (low level design)

3. Take home project and machine coding

4. High level design

5. Behavioural Round (HM Round)

6. HR discussion

1. For DSA round:

Practice is your friend and nothing else, Practice is the KEY🔑, Nothing beats consistent practice for DSA preparation. Avoid relying too much on theory or watching endless tutorial videos these can help with the basics, but real progress comes through problem-solving.

Choose a Dedicated Question List: Pick one well-curated list of questions and stick with it until completion. Recommended lists:

• Start with Leetcode 75 or Blind 75 or Grind 75

  • Leetcode 75: https://leetcode.com/studyplan/leetcode-75/

  • Blind 75: https://leetcode.com/discuss/general-discussion/460599/blind-75-leetcode-questions

  • Grind 75: https://www.techinterviewhandbook.org/grind75/

• Use flashcards for patterns if needed (reco:Leetcard app): Flashcards are especially useful for identifying problem types and common solutions at a glance.

• For people struggling with DP and graphs: highly recommend watching below playlist to get intuition. However, try tackling problems independently before resorting to videos, as struggling with problems can lead to deeper insights.

  Subscribe now

• For graphs

2. Machine coding (low level design): This has become part of interview process for most companies and I think, it is better way of evaluation compared to DSA, since problem solving is mixed with implementation as well.

   1. Learn and Apply Design Patterns: Understanding design patterns is crucial, as they provide reusable solutions to common problems. Apply them in your current projects if possible, real-life application is the best way to grasp their utility.

      1. Head first design patterns book

      2. https://refactoring.guru/design-patterns

      3. https://github.com/ashishps1/awesome-low-level-design

      Note: Don’t aim to memorize all patterns; instead, understand key ones and incorporate them into real-world applications. The GitHub repository above is especially valuable as it covers both design patterns and preparation for low-level design interviews.

   2. Many developers overlook design patterns, but these universal solutions are a valuable skill that can enhance your career. Whether or not they are always implemented, knowledge of patterns helps you write more structured, scalable, and efficient code.

   3. For guidance on approaching low-level design, explore a few well-curated playlists. However, don’t watch tutorials for every problem, only use them when you’re stuck or need insights into problem-solving approaches.

3. Take home project and machine coding:

   With the rise of large language models (LLMs), it can be tempting to rely on AI for coding solutions. However, especially in machine coding interviews, it’s essential to start with your own approach. These interviews often require you to extend and adapt your code on the spot, making it crucial to understand every part of your solution.

   1. Start with Your Own Solution

   2. Refine with AI if Needed

   3. Gain Confidence in Extending Code

      Write first, Refine later

4. High level design

   1. There is no finite answer when it comes to system design, different interviewers expect different solution, at that moment you should try to drive the conversation as per the interviewers focus.

      1. ByteByteGo (Volumes 1 and 2): If you prefer a single, comprehensive resource, ByteByteGo offers a structured, in-depth approach to system design. Available both online and offline, these volumes cover fundamental and advanced topics in system design, making them ideal for a focused study.

      2. Grokking System Design: This resource provides a variety of system design patterns and is well-suited for interview preparation. Stick to one book at a time to avoid overwhelming yourself with differing explanations or approaches.Grokking system design is also helpful, focus on finishing single book instead of going back and forth.

   2. Although books are generally preferable for a thorough understanding, certain YouTube playlists can provide additional insights. These can help clarify specific concepts or introduce different perspectives, but avoid switching frequently between resources. Use them sparingly, focusing on areas where you need further clarification or alternative viewpoints.

      Youtube:

   That is all about technical interview, when it comes to behavioural I will share a future post, below resource will come handy if you want to rush through it https://www.techinterviewhandbook.org/behavioral-interview/

Share

This is part#2 extension to #1 raft-protocol, although both can be read independently as well

Paxos is used for replication, master election, locking, replicating of metadata & configuration.

From #1 Data replication

Hardware failures are inevitable to escape for any distributed system. Some of the expected one’s are machine crashes, disk failures, network partitions and clock skews. To stay unaffected by these failures, replication is used to make data available & durable.

Replication in short means copying data to multiple physically isolated hardware and sync data continuously. While there are many pro’s due to replication while scaling, Implementation of replication is far from simple.

Consensus based replication is one way to do it.

Consensus algorithms are used to reach consensus to commit a transaction in all the replicas.
Paxos is also consensus based replication protocol and it is more complex at the implementation layer compared to raft, it is still used in world class products such as Google Spanner, Megastore.

🏎️ It is used in F1 as well, not the race, but another distributed SQL database https://stephenholiday.com/notes/f1/

2PC: Two phase commit

Leader election is a different process, it can be static same leader, dynamic leader election using leader lease or any other way.

2 steps: 1. Prepare 2. Commit

Leader initially issues the ‘Prepare’ message to all the Acceptors and the Acceptors responds with a ‘Prepared’ message if the acceptor doesn’t have any other transaction in progress on the same file. On receiving ‘Prepared’ message from all the acceptors involved in the transaction, the leader begins the second phase of the 2PC. The leader issues a ‘Commit’ message to all the acceptors. Then the acceptors commit the value to the persistence storage that is agreed upon in the previous phase. Acceptors respond optionally with ‘Committed’ or ‘Aborted’ message depending on the implementation. If there is an in-progress transaction the acceptor responds with ‘Abort’ message in the first phase. If the Leader receives an Abort message from any one of the acceptors, then the leader issues, ‘Abort’ message to all the other acceptors to cancel the transaction that the leader initiated.

Problems;

1. Leader fails after prepare or during leader lease, system might take forever to comeback as acceptors have to drain waiting till timeout or health check

2. Any acceptor fails, entire transaction should be aborted

These leads to bottlenecks of latency and transaction failures.

Paxos tries to address these concerns suing Proposers, Acceptors and Learners.

The significant optimization in the Paxos compared to 2PC is that there is no need for all the acceptors to accept the proposal from the Proposer. Instead, it is considered that the consensus is reached when the majority of the acceptors accepts the proposal.

There can be more than one proposers at a time too.The acceptors that do not participate are learner, who can be synced asynchronously and can be moved out of transaction.

Happy case flow

Each paxos run will have only one consensus reached and it cannot be changed until another paxos run comes into place, paxos nodes must be persistent, they cannot forget what they accepted .

Paxos algorithm

Contention can be caused in paxos, if several proposals can run int the same paxos run, exponential backoff is used to not stall the system in such cases.

Plata O Plomo

In direct to the general complications, you can see it needs to have other ways for state machine replication, log replication, these cons make RAFT more easier to implement

Let's summarise the key components and concepts of Paxos:

1. Proposers, Acceptors, and Learners:

   1. Proposers suggest values to be agreed upon.

   2. Acceptors receive proposals and decide whether to accept them.

   3. Learners learn the chosen value after consensus is reached.

2. Phases of Paxos:

   1. Phase 1 (Prepare/Promise): A proposer sends a prepare request with a proposal number to a quorum of acceptors.

   2. Phase 2 (Propose/Accept): If an acceptor has not promised a higher proposal number, it responds with a promise and optionally the highest proposal it has accepted so far. The proposer then sends an accept request with the proposal number and value to the acceptors.

3. Quorum: A majority of acceptors must agree on a proposal for it to be chosen.

   ---

Implementations:

1. https://www.freecodecamp.org/news/how-to-implement-paxos-algorithm-in-pure-functions/

2. https://github.com/dibyendumajumdar/paxos

3. https://github.com/cocagne/paxos

References:

1. https://lamport.azurewebsites.net/pubs/paxos-simple.pdf

2. https://substack.com/home/post/p-145189829

3. https://medium.com/@logeshrajendran/paxos-a9d76ebf04f3

4. video:

   Share System savvy

   
   

Do checkout the #1 post related to Raft protocol

Subscribe now

Related to Learning coding, architecture & design

1. One of the best from

   

   Architecture Notes — System Design & Software Development

   Build » Scale » Succeed. Unlock engineering potential with insider tips, skyrocket your career - in your inbox every Sunday! ⚡️

   By Mahdi Yusuf

2. No one’s gonna miss this one &

   ByteByteGo Newsletter

   Explain complex systems with simple terms, from the authors of the best-selling system design book series. Join over 500,000 friendly readers.

   By Alex Xu

3. Daily bytes from TLDR, can’t keep up reading everything they share, but you can choose and read what you like
   
   link: tldr.tech/webdev
   🫣referral link

4. The best reads from Who?
   samwho.dev

   my fav: https://samwho.dev/bloom-filters/

5. Encore.dev Sometimes

   https://encore.dev

6. I also follow top 2 trending hackernews on daily basis and sometimes on some subreddits

   https://news.ycombinator.com

Share System savvy

Tech related [In general]

1. Webcurios: webcurios.co.uk

2. SpaceCadet: spacecadet.ventures [please wait for the page to load]

Add your reco in comments

Leave a comment

Data replication

Hardware failures are inevitable to escape for any distributed system. Some of the expected one’s are machine crashes, disk failures, network partitions and clock skews. To stay unaffected by these failures, replication is used to make data available & durable.

Replication in short means copying data to multiple physically isolated hardware and sync data continuously. While there are many pro’s due to replication while scaling, Implementation of replication is far from simple.

Consensus based replication is one way to do it.

Consensus means multiple servers agreeing on a value, If in a cluster there are 5 servers, a quorum consensus is used to agree on reading and writing values from/to DB, to form a strong consistent system of 5 servers, at least 3 servers should be up and running to agree on a decision. Under consensus, there are Raft and Paxos most commonly used protocols where leaders manage the replication.

Paxos is three phase commit(3PC) protocol, which we will discuss in a later post. Keep subscribed

Subscribe now

Raft was proposed as an alternative to Paxos, owing to solve complexities in paxos implementation by separating leader election process. “The separation of logic stems from the fact that Raft makes leader election a separate and mandatory step before the leader can get the data replicated, whereas a Paxos implementation would make the leader election process an implicit outcome of reaching agreement through data replication.” quoted from reference. This allows adding & removing servers to be easier, more like an abstraction. Raft imposes the restriction that only the servers with most up-to-date data can become leaders.

When there are no unplanned failures or planned changes, the leader election step can be skipped. The leader election step is automatic whenever such changes happen even when no new writes are coming into the system. These optimizations radically simplify edge cases in which a succession of leadership changes can result in data discrepancies, but the tradeoff is that leader election in Raft can be more complicated than its counterpart in Paxos.

A distributed SQL database uses the Raft consensus algorithm for both leader election and data replication. Instead of having a single Raft group for the entire dataset in the cluster, a distributed SQL database applies Raft replication at an individual shard level where each shard has a Raft group of its own.

Raft is the defacto standard today for achieving strong consistency

Going back to the definition: Raft protocol is used to achieve high read performance with single-key linearizability and leader leases.

Linearizability

 A consistency model that ensures each operation on a shared object appears instantaneously at some point between its invocation and its response. It provides the illusion that operations are executed in a sequential order, which is consistent with the real-time order of operations.

Without Linearizability

With Linearizability

Linearizability means that modifications happen instantaneously, and once a registry value is written, any subsequent read operation will find the very same value as long as the registry will not undergo any modification.

Cons:Inter-Key Operations: Single-key linearizability does not provide guarantees about the order or atomicity of operations that span multiple keys. For applications that require strong consistency across multiple keys, additional mechanisms (like transactions) are needed.

Share System savvy

Linearizability is one of the strongest single-key consistency models. It implies that every operation appears to take place atomically and in some total linear order. This means it’s consistent with the real-time ordering of those operations. In other words, the following should be true of operations on a single key:

• Operations can execute concurrently, but the state of the database at any point in time must appear to be the result of some ordered, sequential execution of operations.

• If operation A completes before operation B begins, then B should logically take effect after A.

The Raft consensus algorithm solves this problem.

Leader leases are a mechanism used in distributed systems to ensure a consistent and reliable leader election process.They are particularly useful in systems that require a single leader to coordinate actions or make decisions to maintain consistency.

1

References:

• https://stackoverflow.com/questions/9762101/what-is-linearizability

• https://www.yugabyte.com/tech/raft-consensus-algorithm/

• https://www.yugabyte.com/blog/how-does-consensus-based-replication-work-in-distributed-databases

• https://raft.github.io/

  Thank you for reading System savvy. This post is public so feel free to share it.

  Share