System Design Interview Process…

System Design Interview Process:

1. Ask Questions to understand requirements:

  • Functional Requirements
  • Non-Functional Requirements

2. Handle Data 

  • What’s the size of the data right now?
  • At what rate is the data expected to grow over time?
  • How will the data be consumed by other subsystems or end users?
  • Is the data read-heavy or write-heavy?
  • Do we need strict consistency of data, or will eventual consistency work?
  • What’s the durability target of the data?
  • What privacy and regulatory requirements do we require for storing or transmitting user data?

3. Divide and Conquer – Discuss the components and trade-offs

  • Different components have different pros and cons. We’ll need to carefully weigh what works for us.
  • Different choices have different costs in terms of money and technical complexity. We need to efficiently utilize our resources.
  • Every design has its weaknesses. As designers, we should be aware of all of them, and we should have a follow-up plan to tackle them.

What not to do in an interview

Here are a few things that we should avoid doing in a system design interview:

1. Don’t write code in a system design interview.

2. Don’t start building without a plan.

3. Don’t work in silence.

4. Don’t describe numbers without reason. We have to frame it.

5. If we don’t know something, we don’t paper over it, and we don’t pretend to know it.

Reverse Conway’s Law…

You can deliberately structure your team the way you want your code to look like.

Geographically distributed teams will tend toward more modular distributed software. 

Most importantly – Development teams that include product users will produce software that clearly reflects their involvement making it more relevant to the users. Whereas teams that don’t bother will reflect that in the product with not much relevancy to the users.

Focus on quality as AI beats quantity…

With more tasks being automated today with advent of AI (GPT3), the value of quality is enhanced much more now.

AI or bot can do only limited quality work but can easily beat humans in quantity. Hence as an expert in your field you will be valued more because you bring quality. Your uniqueness, your experience will have more value, since no one can copy or generate it.

At the same time quantity will be culled out more and more because of its abundance. And for those who go after quantity, beware of it, as it will hit roadblocks sooner or later and leave you stranded.

Best case will be, to have right mix of quality and quantity as you go along.

Solve complex problems or solve consumer problems?

As a technologist or product owners, we have a choice – Solve complex problems or solve consumer problems? Believe me, there is a huge difference.

Being techy it gives us people a thrill to solve complex problems even if the problem has zero correlation to a real consumer.

As long as its complex we want to solve it :). Let’s not get into why of it? Maybe it gives a mind thrill or gives a good massage to our ego.

But then what’s the point of product & technology, if it does not solve consumer problems? or real-world problems?

I would say this is one of the biggest learning for me, now that I have my own startup. And I can safely say this makes a huge difference between a successful techy and an average one. Anyone who gets this prospective can not only deliver things much faster but adds tremendous value to the product.

I learned it the hard way, here is how it happened:

Initial days as a techy I had very little interaction with clients who were using our software. But one day I had a call with one of our biggest clients to explain (We use to provide a platform for sellers to sell their items and ship it to the consumer, something similar to eBay) why a major release got postponed leading to shipping & tracking problems. The Client was losing a lot of money because of this issue.

I was dreading the call and was ready with all the tech explanations why it happened, what are we doing to fix it, etc, etc…

The call started, my sales colleague did a quick intro along with the business side updates and handed over to me …

I started with all sorts of technical jargon and then tried explaining that the architecture of the dashboard was scraped and rebuilt for scale…blabbering as much as possible to convince him.

Off-course he couldn’t understand a single word.

But here comes the surprise:

Me – “Sir, the release got delayed because blah blah…we are working day and night to get it live by next week and again blah blah blah more jargons”

Client – “That’s fine but can u please enable my shipping address in the success page”

Me – After long pause….“Sorry, didn’t get, Please tell me again..”

Client – “You guys have removed my shipping address from the success page to make it more prominent on the next page, and hence my customer couldn’t find it easily. ” Client Continued – “Because of this, my customers are not able to understand and have been canceling orders. Also, I need to coordinate with every customer on the phone/mail and losing money…”

Me – Again a longer pause, but some sense of relief and guilt for making this guy and others suffer for our favorite “Dashboard Release”
“Sure Sir, I am sorry for the issue it might be a product bug let me fix it asap”

Client as politely as possible – “I am not much concerned with when the dashboard goes live but please fix this asap and I am more than happy”

Me – Now with more confidence, since its just a shipping address to be added to the success page.
“Sure Sir, I assure you, we will release it by tomorrow”

We fixed the shipping address display issue in the success page, The Client(s) was happy and we released our dashboard in next two weeks (BTW – there were very few usages of the Dashboard but that’s a different story)

This was a life-changing moment for me, I couldn’t understand what happened for some time, why is the client not bothered to use Dashboard built with great technology and supposedly help him so much.

Later I figured that most of the clients had a simple system to show the shipping address and get their team to process it thru excel. Why would they want their team to learn Dashboard and make it difficult, learn a new skill set and invest more?

If we would have understood their problem a bit deeper and had integrated excel into it. It would have been much easier to implement, much faster, and would be very helpful to them. But we were solving a very difficult problem of integration of data from different sources into a single Dashboard and was being proud doing it.

Remember 80-20 Rule

To all the techies and product folks, remember – 20% of product & product features are used 80% of the time hence if we can hone this 20% we are winners. Of course, it’s difficult to identify the 20% and that’s where our focus should be.

So next time if you see a complex problem to be solved, first raise questions what & why, is it really helping someone? and if it does not go solve a complex puzzle to massage your ego 🙂 but please ignore the complex problem.

4 Questions to Ask Before Starting a Big Data Project…

Up to 85% of big data projects fail, often because executives don’t accurately assess the project risks at the outset. Before investing in your next big data initiative, ask these four questions to determine its chances of success.

#1: Is your data valuable and rare? Not all available data is useful, nor is it unique or exclusive.

#2: Can employees use the data to create solutions on their own? You need to decentralize decision-making in order to encourage people to autonomously initiate, create, and adapt solutions.

#3: Can your technology actually deliver the solution? You can have all the data and ideas in the world, but if your technology can only deliver a prototype or a non-scalable solution, your project will fail.

#4: Is your solution compliant with laws and ethics? Even if it’s legal, if users find your solution to be “creepy,” the project is doomed from the start.

Go ahead and use these as your litmus paper test for Big Data Projects…

6 Ways to Go from Good to Great

What we can learn from Good-to-great companies?

How does strategic management differ at good-to-great companies versus mediocre ones?

# Finding a simple “Hedgehog concept (Shaded part – Intersection of passion, skill, and economic value)“ provides a clear path to follow.

 

# Success comes from many tiny incremental pushes in the right direction.

New technology should be viewed only as an accelerator toward a goal, not as a goal itself.

How do the people and culture differ at good-to-great companies versus mediocre ones?

Team drives successful transformations from good to great. Right people in the right place are the foundation of greatness.

Success requires confronting the nasty facts, while never losing faith. Leaders must create an environment where the brutal facts are aired without hesitation.

A culture of rigorous self-discipline is needed to adhere to the simple Hedgehog concept.

Follow the above steps to build a great company.