Hacking the Software Engineer Interview

https://puncsky.com/hacking-the-software-engineer-interview/?isAdmin=true
Making decisions and negotiating. Never accept an offer without negotiating!

1. throw your book Cracking the Coding Interview into the trash. The coding questions there are obsolete and too easy. Elements of Programming Interviews is better. However, by and large, books are not very helpful because what you need is deliberate practice not reading books.
2. Go to Online Judge like Leetcode and Lintcode. Solve at least 70 medium to hard questions. The key is to practice in a large amount and with speed repeatedly.

What can we communicate in soft skills interview?

What is an interview? 

An interview is a process for workers to find future co-workers, during which they are finding signals to answer the following three key questions:

1. capability question - can you do the job?
2. willingness question - will you do the job?
3. culture-fit question - will you fit in?

Why is soft skill so important? 

None of the critical questions above can be answered without good communication. Your job will be taken away by people who can talk better than you.

Generic answers (stories) to prepare 

1. hard-won triumph. How do you deal with failure? Briefly talk about the harshest moment, and then focus on how you battled back, and then salute the people who helped you. It demonstrates that you have the grit, team-building skills, and relevance to the job.
2. influence. Can you guide people to yes? leaders = visionaries who inspire self-sacrifice. A leader does not exist without the ability to persuade.
3. technical skills. Do you have a story proving your great technical skills?
4. culture-fit. The FBI used to ask prospective agents what books they read until an underground network of tipsters figured out the ideal answer: “Tom Clancy spy novels.”
5. fascination. What’s fascinating about you? What makes you different from other people?

Experience Deep Dive

Intended Audience 

Moderate experience or less, or anyone who was not in a leadership or design position (either formal or informal) in their previous position

Question Description 

Describe one of your previous projects that was particularly interesting or memorable to you. Followup questions:

What about it made it interesting? What was the most challenging part of the project, and how did you address those challenges? What did you learn from the project, and what do you wish you had known before you started? What other designs/implementation methods did you consider? Why did you choose the one that you did? If you were to do the same project over again, what would you do differently?

Interviewer tips 

Since the goal here is to assess the technical communication skill and interest level of someone who has not necessarily ever been in a role that they could conduct a crash course in, you should be prepared to keep asking them questions (either for more details, or about other aspects of the project). If they are a recent grad and did a thesis, that’s often a good choice to talk about. While this question is in many ways similar to the Resume Questions question from phone screen one, this question is intended to be approximately four times as long, and should get into proportionally more detail about what it is that they have done. As such, the scoring criteria are similar, but should be evaluated with both higher expectations and more data.

A great candidate will

• Be able to talk for the full time about the project, with interaction from the interviewer being conversational rather than directing
• Be knowledgeable about the project as a whole, rather than only their area of focus, and be able to articulate the intent and design of the project
• Be passionate about whatever the project was, and able to describe the elements of the project that inspired that passion clearly
• Be able to clearly explain what alternatives were considered, and why they chose the implementation strategy that they did.
• Have reflected on and learned from their experiences

A good candidate will

• May have some trouble talking for the full time, but will be able to with some help and questions from the interviewer
• May lack some knowledge about the larger scope of the project, but still have strong knowledge of their particular area and pieces that directly interacted with them
• May seem passionate, but be unable to clearly explain what inspired that passion
• May be able to discuss alternatives to what they did, but not have considered them in depth
• Have reflected on and learned from their experiences

A bad candidate will

• Have difficulty talking for the full time. The interviewer may feel as if they are interrogating rather than conversing with the candidate
• May lack detailed knowledge of the project, even within the area that they were working. They may not understand why their piece was designed the way it was, or may not understand how it interacted with other systems
• Does not seem very interested in the project - remember that you are asking them about the most interesting project that they have done, they should be very - interested in whatever it was
• May not be familiar with potential alternatives to their implementation method
• Does not seem to have learned from or reflected on their experiences with the project. A key sign of this is that the answer to ‘what did you learn’ and ‘what would you do differently’ are short and/or nearly identical.

When we design a distributed system, trading off among CAP (consistency, availability, and partition tolerance) is almost the first thing we want to consider.

• Consistency: all nodes see the same data at the same time
• Availability: a guarantee that every request receives a response about whether it succeeded or failed
• Partition tolerance: system continues to operate despite arbitrary message loss or failure of part of the system

In a distributed context, the choice is between CP and AP. Unfortunately, CA is just a joke, because single point of failure is a red flag in the real distributed systems world.

To ensure consistency, there are some popular protocols to consider: 2PC, eventual consistency (vector clock + RWN), Paxos, In-Sync Replica, etc.

To ensure availability, we can add replicas for the data. As to components of the whole system, people usually do cold standby, warm standby, hot standby, and active-active to handle the failover.

1. Horizontal Duplication and Cloning (X-Axis). Having a farm of identical and preferably stateless instances behind a load balancer or reverse proxy. Therefore, every request can be served by any of those hosts and there will be no single point of failure.
2. Functional Decomposition and Segmentation - Microservices (Y-Axis). e.g. auth service, user profile service, photo service, etc
3. Horizontal Data Partitioning - Shards (Z-Axis). Replicate the whole stack to different “pods”. Each pod can target a specific large group of users. For example, Uber had China and US data centers. Each datacenter might have different “pods” for different regions.

Want an example? Go to see how Facebook scale its social graph data store.

ACID (Consistency over Availability)

• Atomicity ensures transaction succeeds completely or fails completely.
• Consistency: In ACID, the C means that a transaction pre-serves all the database rules, such as unique keys, triggers, cascades. In contrast, the C in CAP refers only to single copy consistency, a strict subset of ACID consistency.
• Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially.
• Durability ensures that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g. power outage or crash).

BASE (Availability over Consistency)

• Basically available indicates that the system is guaranteed to be available
• Soft state indicates that the state of the system may change over time, even without input. This is mainly due to the eventually consistent model.
• Eventual consistency indicates that the system will become consistent over time, given that the system doesn’t receive input during that time.

Although most NoSQL takes BASE priciples, they are learning from or moving toward ACID. e.g. Google Spanner provides strong consistency. MongoDB 4.0 adds support for multi-document ACID transactions.

Load Balancer Types

Generally speaking, load balancers fall into three categories:

• DNS Round Robin (rarely used): clients get a randomly-ordered list of IP addresses.
  • pros: easy to implement and free
  • cons: hard to control and not responsive, since DNS cache needs time to expire
• Network (L3/L4) Load Balancer: traffic is routed by IP address and ports.L3 is network layer (IP). L4 is session layer (TCP).
  • pros: better granularity, simple, responsive
• Application (L7) Load Balancer: traffic is routed by what is inside the HTTP protocol. L7 is application layer (HTTP).

Improving availability with failover 

Improving availability with failover

Cold Standby: Use heartbeat or metrics/alerts to track failure. Provision new standby nodes when a failure occurs. Only suitable for stateless services.

Hot Standby: Keep two active systems undertaking the same role. Data is mirrored in near real time, and both systems will have identical data.

Warm Standby: Keep two active systems but the secondary one does not take traffic unless the failure occurs.

Checkpointing (or like Redis snapshot): Use write-ahead log (WAL) to record requests before processing. Standby node recovers from the log during the failover.

• cons
  • time-consuming for large logs
  • lose data since the last checkpoint
• usercase: Storm, WhillWheel, Samza

Active-active (or all active): Keep two active systems behind a load balancer. Both of them take in parallel. Data replication is bi-directional.

3 Programming Paradigms

Structured programming vs. OO programming vs. Functional programming

1. Structured programming is discipline imposed upon direct transfer of control.
   1. Testability: software is like science: Science does not work by proving statements true, but rather by proving statements false. Structured programming forces us to recursively decompose a program into a set of small provable functions.
2. OO programming is discipline imposed upon indirect transfer of control.
   1. Capsulation, inheritance, polymorphism(pointers to functions) are not unique to OO.
   2. But OO makes polymorphism safe and convenient to use. And then enable the powerful plugin architecture with dependency inversion
      1. Source code denpendencies and flow of control are typically the same. However, if we make them both depend on interfaces, dependency is inverted.
      2. absolute control over the direction of all source code dependencies in the system. They are not constrained to align those dependencies with the flow of control.
      3. Interfaces empower independent deployability
3. Functional programming: Immutability. is discipline imposed upon variable assignment.
   1. Why important? All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables.
   2. Event sourcing is a strategy wherein we store the transactions, but not the state. When state is required, we simply apply all the transactions from the beginning of time.

SOLID Design Principles

SOLID is an acronym of design principles that help software engineers write solid code within a project.

1. S - Single Responsibility Principle. A module should be responsible to one, and only one, actor. a module is just a cohesive set of functions and data structures.
2. O - Open/Closed Principle. A software artifact should be open for extension but closed for modification.
3. L - Liskov’s Substitution Principle. Simplify code with interface and implementation, generics, sub-classing, and duck-typing for inheritance.
4. I - Interface Segregation Principle. Segregate the monolithic interface into smaller ones to decouple modules.
5. D - Dependency Inversion Principle. The source code dependencies are inverted against the flow of control. most visible organizing principle in our architecture diagrams.
   1. Things should be stable concrete, Or stale abstract, not concrete and volatile.
   2. So use abstract factory to create volatile concrete objects (manage undesirable dependency.) 产生 interface 的 interface
   3. DIP violations cannot be entirely removed. Most systems will contain at least one such concrete component — this component is often called main.

3. adopt patterns and best practices.
4. avoid anti-patterns
   • callback hell = spaghetti code + unpredictable error handling
   • over-long inheritance chain
   • circular dependency
5. effective refactoring
   • semantic version
   • never introduce breaking change to non major versions
     • two legged change