System design resource: — System design primer — Data intensive applications — Awesome scalability Coding resources: — Competitive programmer's book — Google Techdev guide — Awesome leetcode resources credits to Alex N

Systemdesigndaily

System Design Daily

System Design Daily is an interactive system design study guide where engineers of all skill levels can learn scalable software concepts in a fun and engaging way.

Cracking the Google Interview Part #2: Interview Preparation Roadmap

This article will guide you through my steps for preparing for my Google interviews. Overall, it took me 2 years to crack the MAANG interview and almost 500 solved LeetCode problems: including learning algorithms and data structures, practicing coding & problem-solving, and applying and passing all interviews.

My General Roadmap for Preparing for the Interview:
1. Learning algorithms and data structures.
2. Solving algorithms, and learning patterns and concepts.
3. Practicing coding & problem-solving questions together with friends on the whiteboard.
4. Learning System Design.
5. Writing a resume. Applying to jobs.
6. Preparing for a behavioral interview.
7. Getting an interview invitation, passing all interviews, and getting an offer! ?

How Did I Learn Data Structures and Algorithms? Here are the Resources I Used:
1. I had a Data Structures class at university. Here are the notes from the class.
2. Naso Academy DS playlist
3. Jenny's DSA playlist
4. Programiz.com
5. Data Structures by a Google Software Engineer
6. NeetCode videos: here’s one of them
7. AlgoExpert Data Structures course
8. Extra:
• *Tech Interview Handbook Algorithms Cheat Sheet
• The Last Algorithms Course You'll Need

Practicing Coding & Problem Solving Questions:
1. InterviewBit
2. LeetCode Explore (only data structures cards)
3. LeetCode Study Plan — Data Structure 1, Algorithm 1, Programming Skills 1
4. "Cracking the Coding Interview" + CTCI problems in LeetCode
5. LeetCode Study Plan — Data Structure 2, Algorithm 2, Programming Skills 2
6. AlgoExpert video solutions
7. Neetcode.io & NeetCode playlist
8. LeetCode company-tagged questions

Problem-Solving Approach (Constraints, Ideas, Complexities, Code, and Tests):1. Read the problem. Don’t immediately jump into coding!
2. Understand inputs and outputs. Draw some examples on paper.
3. Clarify requirements, ask questions, and find constraints (edge cases). Example questions: Is it ASCII or Unicode? What is the max value? Is there a difference between capital letters and small letters?
4. Think about the solution in your mind. Divide problems into sub-problems. Come up with different ideas (ask whys, think about trade-offs, solve simpler versions, imagine helper functions - go from high level to low level).
5. Evaluate the complexity and trade-offs.
6. Think of a better alternative solution.
7. Write code on paper.
8. Debug your code on paper and test with new corner case inputs.
9. Write code. Write clean code.
10. Write tests. Positive, negative, with edge-cases.
11. More to read:
• HiredInTech Algorithm Design Canvas
• Cracking the Coding Skills
My List of Clarifying Questions:* Questions, Corner Cases, and Constraints
General Tips:**
Interviews are not only about evaluating your technical knowledge. Explain your thought process and show how you approach problem-solving in a structured way step by step. Many questions asked by interviewers are open-ended, so ask good questions to clarify a full set of criteria to solve the problem and clarify requirements. Always, always, always ask clarifying questions before jumping to a solution. Try thinking of different solutions to a given problem and explain why you came up with this solution or this code. Compare your solutions, compare complexities, and think about their trade-offs. Overall, the interview should be like a dialogue – show how it is to work with you, how collaborative you are.

Must Watch and Must Read Resources:
• Interview Cake Coding Interview Tips
• Prepare for Your Google Interview: Coding• Interview tips from Google Software Engineers• Coding Mock Interview

Extra resources to Watch and Read:
• Tech Interview Process• Preparing for a Technical Interview• Prepare for your Google Interview: General Cognitive Ability• Prepare for your Google Interview: Leadership
• "100ta Intervyu Nima O'rgatdi?" by Azimjon Pulatov• Mock interview with Vohid Karimov and Azimjon Pulatov

#google #faang #maang #coding #google_interview #faang_interview

There still might be a positive scenario where software engineering is outsourced to Uzbekistan. I'll describe it here.

Let's accept the hypotheses that the bulk of software engineering can be done by an autonomous AI agents, that can read documentation, participate in Slack, interact with the issue tracker, write code, run tests, etc. Still, they need someone else to give them a task because a machine will not, and should not be allowed to, come with its own goals. Even if you organize such systems in a tree, the root of the tree still needs to be a human. If we also accept that only people manage people, we get a tree of red and blue nodes, where red are humans, blue are machines, the root is red, all leaves are blue and a red node cannot have a blue parent. The path from the root to any leaf starts with a red node and at some point switches to blue nodes.

Right now the state of technology is that all nodes are red. At some point the blue nodes will start entering the picture. In the scenario I described in the previous post, a company decides that all outsourced work can be handled by AI and replaces all outsource teams with blue nodes, so then you have all red nodes located in US/Europe. That's a grim scenario. A more positive one, is that the company decides to give individual remote employees a team of AI workers and expect the productivity to go through the roof. In this scenario some red nodes are Uzbekistan.

Not every remote employee would get a team of AI workers though, because not every person would be good at this job. This is a pretty different job: you still have to understand code, but you wouldn't writing a lot of it. What you'd do is clearly articulate problems in English, give good actionable feedback, check on results of their work to ensure it interpreted your words correctly, etc. This reminds me my work as a Staff/Principal engineer. So, if are already in such a role, then I think you are still safe, but if you are a rock star programmer that just cranks out code and doesn't talk to others, then I'd say it is time to grow up.

So, my advice is to start looking at what more senior people in your org are doing. They probably see the big picture better than you, better at communication, are able to articulate complex thoughts more clearly, are more creative, knowledgeable and hopefully still hands on and can help you with a low level task, etc. This doesn't need to turn into mass hysteria of getting promoted, but it does mean that perhaps it is time to start developing those soft skills, learn a bit more about product management, project management, and diversify your skills a bit.

Useful resources for weekends:

— How Discord stores Trillions of Messages
— How Canva scaled Media uploads from Zero to 50 Million per Day
— Building Faster Indexing at DoorDash
— The first 10 years of Stripe's Payments APIs
— How Airbnb Avoid Double Payments
— Real time messaging at Slack
— Capturing a Billion Emojis at Hotstar
— How Pinterest Built a Real-time User Action Counting System for Ads
— How Uber Optimizes the Timing of Push Notifications using ML
— How Facebook uses AI to power its Marketplace

Original source

lnkd.in

LinkedIn

This link will take you to a page that’s not on LinkedIn

#EngX #clean_code

"Clean Coding" resources.

Mostly for Python.

Database Caching is a million-dollar technique you can’t ignore.

it helps your project's data retrieval performance by reducing the need to access the underlying slower storage layer.

So - what's the catch?

There are multiple strategies and you've to choose the right one for the job.

✅ Cache-Aside Strategy
In this strategy, the cache sits next to the database.
Here’s how it works:
- When there is a request for data, the application first checks the cache
- If there’s a cache hit, the application returns from the cache
- In case of a cache miss, the application queries the DB and returns the data
- The application also stores the missing data in the cache for future requests

Pros: Great for read-heavy workloads. Also, better resiliency since a cache failure cannot cripple the system.
Cons: Potential inconsistency between the cache and the database.

✅ Read-Through Strategy
The cache sits between the application and the database.
Here’s what happens in read-through:
- The application goes to the cache for any read request.
- If there’s a cache hit, data is returned from the cache and that’s the end of the flow.
- In case of a cache miss, the cache gets the missing data from the database and returns it to the application.

Pros: The application doesn’t have to worry about fetching from the database or the cache. The cache takes care of it.
Cons: Potential inconsistency between the cache and the DB and the need to go to the database for every brand-new read request.

✅ Write-Around Strategy
Same as Cache-Aside with the added context about the write operations.
In this strategy, all writes go to the database and the data that is read goes to the cache.
For a cache miss, the application reads from the DB and updates the cache for the next time.
Great for cases where data is only written once and rarely updated (like a blog post or a static website).

✅ Write-Through Strategy
Write-through tries to solve the problems with read-through.
Instead of writing to the DB, the application first writes to the cache.
And the cache immediately writes to the DB.
The word “immediately” is the key over here.

Pros: Cache will always have any written data. New read requests won’t experience a delay while the cache requests the data from the main DB.
Cons: Extra write latency because the data must go to the cache and then to the DB.

✅ Write-Back Strategy
It’s a variation of the write-through strategy.
With one key difference…
In the write-back, the application writes directly to the cache.
However, the cache doesn’t immediately write to the database but after a delay.

Pros: The strain on the cache is reduced in case you have a write-heavy workload. Requests to the DB are batched and the overall write performance is improved.
Cons: In case of a cache failure, there are chances of possible data loss.