LeetCode Solutions


Гео и язык канала: Узбекистан, Английский
Категория: Образование


Engineering journey
Reliable resources and questions given in M/FAANG companies.

Связанные каналы  |  Похожие каналы

Гео и язык канала
Узбекистан, Английский
Категория
Образование
Статистика
Фильтр публикаций






Репост из: kamoloff.log
𝟮𝟳 𝗳𝗿𝗲𝗲 𝗿𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀 𝘆𝗼𝘂 𝗰𝗮𝗻'𝘁 𝗺𝗶𝘀𝘀 𝗼𝘂𝘁 𝗮𝘀 𝗮 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿:


🗞️ Newsletters:

🗞️ System Design by Neo Kim
🗞️ Algo Master by Ashish Pratap Singh
🗞️ Rocky's System Design Newsletter
🗞️ Coding Challenges by John Crickett
🗞️ TechWorld with Dr Milan Milanović
🗞️ High Growth Engineer by Jordan Cutler
🗞️ Level Up Coding by Nikki Siapno
🗞️ Developing dev by Ryan Peterman
🗞️ Programming Digest
🗞️ Quastor
🗞️ Hungry Minds by Alexandre Zajac


📺 Youtube channels:

📺 @Fireship' rel='nofollow'>Fireship
📺 @ArjanCodes' rel='nofollow'>Arjan Codes
📺 @ByteByteGo' rel='nofollow'>Byte Byte Go
📺 @TechWithTim' rel='nofollow'>Tech with Time
📺 @BeABetterDev' rel='nofollow'>Be a Better Dev
📺 @freecodecamp' rel='nofollow'>FreeCodeCamp
📺 @LowLevel-TV' rel='nofollow'>Low-level learning


✍️ Engineering blogs:

✍️ Pinterest Engineering
✍️ GitHub Engineering
✍️ LinkedIn Engineering
✍️ Twitter Engineering
✍️ Airbnb's blog
✍️ Netflix Engineering
✍️ Google AI's blog
✍️ Uber Engineering
✍️ Dropbox Tech


What are your favourite resources?

Source: LinkedIn

#softwareengineering #systemdesign #programming #copypaste

---------------
@kamoloff_log


Репост из: Vohid Karimov | Hello world 🌍
Keyingi podcast albatta Rustam Zokirov bilan bo’ldi.

Rustam Zokirov O'zbekistondan turib Googlega job offer olgan birinchi o'zbek bo'ldilar. Rustam hozirda Germaniyaning Munich ofisida Software Engineer in Test lavozimida ishlashni boshladilar.

Suxbat FAANGga bo'lgan yo'l borasida ko'p foydali malumotlarga to'la bo'ldi:
— Birinchi ishni topish
— O’zingizni “sotish”
— Software Engineering in Test
— Universitetni bitirmay senior darajasiga chiqish
— EPAM vs Exadel
— FAANGga tayyorgarlik
— Google: Recruiter call
— Google: Screening interview
— Google: Onsite interviews
— Google: Testing interview
— Google: Behavioral interview
— Interviewda o’zingizni tutish
— Google Germaniyada ishlash
— FAANGga topshirish uchun maslahatlar
— Googledagi perklar

https://www.youtube.com/watch?v=vH9Dd5-IasI


System design resources:

System design daily
Grokking System Design
System Design Roadmap

System Design Interview Problems:

— How to Design WhatsApp
— How to Design URL Shortener like TInyURL
— How to Design Test Storage Service like Pastebin
Design Content Delivery Network (CDN)
— How to Design Parking Garage
— Design Distributed Key-Value Store
— Design Distributed Cache
— Design Distributed Job Scheduler
— How to Design Authentication System
— How to Design Unified Payment Interface (UPI)


Репост из: My Engineering Space | Cracking MAANG 🪐
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


Репост из: Vohid Karimov | Hello world 🌍
Keyingi podcastimiz Women Techmakers (WTM) ambassadorlari Durdona Bakhronova, Aziza Abdurakhmonova, Mukarramkhon Kodirova, va Madinabonu Alisherova bilan Bavariyaning eng churoyli joylaridan biri Neuschwanstein "Disney" qal'asida bo'ldi.

Suxbat ochiq va qiziqarli bo'ldi. Quyidagi mavzularni yoritdik:
— Intro
— Kim qanday dasturlash tilida ishlaydi?
— Nega Germaniyaga keldilar?
— WTM ambassador bo'lish uchun nima qilish kerak?
— Munich sizlarga yoqdimi?
— Dasturlashga qanday kelib qolgansizlar?
— Mukarramkhon: dasturlashdan project managementga o'tish
— WIUT vs INHA battle
— Dasturchi karyerasida mentorning o'rni
— Aziza lampochka yoqishiga ozgina qolgani
— Work-and-Travel vs Dasturlash
— Nega tez tashlab qo'ymaslik kerak?
— Aziza bank serverini uxlatgani
— Beginner/junior dasturchilarga maslahatlar
— Ayol/qiz bo'lib IT soxasiga kirish qiyinmi?


Link: https://youtu.be/RCNDwAkiouk

#Karyera #Career #SWECareer #CareerTips #Dasturlash #Programming #SoftwareEngineering #IT


Репост из: Nodir.log
Hiring. My experience as a hiree at Amazon was absolutely superb. I felt like I am at 5-star hotel and I am the one being paid. My recruiter responded quickly, listened to me carefully, delivered the offer faster than other companies and were patient with me when I took my time to decide (you can read the story earlier in my log). I was surprised to know that the interviewers meet up before and after interviewing the candidate. They asked me to write an essay, essentially, to assess my writing skills. What I'd change? Probably make the technical part harder. In contrast, my Microsoft experience was simply terrible. I had to ping them many times and it took them days to respond.

Technical. I was unplesantly surprised with the technical skills of an average Amazonian compared to an average Googler. I had some bizzare experiences with folks when I said "here, you have a race condition" and was asked "how many customers complained about it?"; or I replaced a list with a hashtable, and the reviewered ask me "you are still calling contains method. What's the difference?". This is a reflection of the hiring process: Google interview is very technical, and Amazon interview is more behavioral. The technical part of my Amazon interview was rather trivial. I think I've seen more shitty code at Amazon than at Google, and this is generally depressing to me because I care about details. The code reviews I've seen were not very detailed either.

Internal tools at Amazon are shitty compared to Google and this was very disappointing. The code search is particularlly shitty because it treats code as plain text and doesn't distinguish symbol declaration from its usage. Compare this to https://source.chromium.org - try starting to type "BindStateBase", where you have auto-completion and it will be navigated directly to its definition. From there you can do "find references". Nothing like that at Amazon. Worst, Amazonians do not even comprehend why it is such a big deal, while a Googler would say "how do you get any work done without code search?". Code review is OK. Github codereview is better, but Gerrit was the best. Partially, this is beceause internal teams do not make money, are constantly underfunded and can't afford making quality tools.

There were other differences from Google (where I spent 7y and got used to), but not necessarily surprising. Just different. I got used to them.

[1]: https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/?did=ba_card&trk=ba_card
[2]: https://aws.amazon.com/builders-library/static-stability-using-availability-zones/?did=ba_card&trk=ba_card
[3]: https://health.aws.amazon.com/health/status


Репост из: My Engineering Space | Cracking MAANG 🪐
Received an offer from Google 🎉


Репост из: Nodir.log
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.


Репост из: Jakhongir Rakhmonov - IT
“Umid yo’q. Siz xohlagan ishingizni topa olmaysiz. Balki 1000ta joyga topshirsangiz chiqib qolar. Vaqtingizni bekorga sarflayapsiz”

deb Computer Science yo’nalishini o’qib tugatgan bir odam dardini yozibdi.

Bu gaplarga Y Combinator kompaniyasi CEOsining javobini qarang:

Haqiqiy loyihlarda, side projectlarda, open source loyihalarda, shunchaki qiziqish uchun qilinayotgan loyihalarda ishlash bu muammoga davodir.

Computer Science bitiruvchilarining ko’pchiligi hech narsa yasay olmaydilar.

Agar siz nafaqat loyihalar qura olishingizni, balki o’zingiz qiziqqaningiz uchun loyihalar qilganingizni isbotlay olsangiz, imkoniyatlar eshiklari siz uchun ochiladi.


E’tibor beringa. Loyiha, loyiha, loyiha. Qurish, yasash, qiziqish.

Ish topa olmayotganlardan so’rasangiz qilgan ishi CRUDdan uyo’giga o’tmagan. Oddiy web loyihadan uyog’iga o’tmagan.

Dasturchilikdek imkoniyatlari cheksiz kasbni o’rganasizu, o’zingizga qiziq bo’lgan birorta proyekt qilib ko’rmaysizmi? Nima bu hamma yoq CRUD bo’lib yotibdi? Bu hamma yozayotgan blog, internet magazin, yangiliklar sayti hech kimni e’tiborini tortmaydigan bo’lib qolgan. Eng yomon tarafi bularning hammasi uchun deyarli bir xil qobiliyatlar kerak. Qisman farq qiladi holos.

O’yin yozib ko’rmaysizmi? Linux uchun Command-Line loyiha qilib ko’rmaysizmi? Data Engineering qilib ko’rmaysizmi? Bot yozib ko’rmaysizmi? 3D qilib ko’rmaysizmi? Yangi dasturlash tili yozib ko’rmaysizmi? Yangi framework yozib ko’rmaysizmi?

Boshqalardan ajralib turish vaqti keldi.

@jakhonrakhmonov










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.


Видео недоступно для предпросмотра
Смотреть в Telegram
source


8 Popular Network Protocols in 1 Diagram

Network protocols are standard methods of transferring data between two computers in a network.

1. HTTP (HyperText Transfer Protocol)

HTTP is the fundamental protocol that enables all communication on the World Wide Web. It allows web browsers to request documents, images, videos and other resources from web servers.

2. HTTP/3

HTTP/3 is the next major iteration of HTTP, providing faster page loads by running on the QUIC protocol instead of TCP. It's optimized for modern mobile internet usage.

3. HTTPS (HyperText Transfer Protocol Secure)

HTTPS secures HTTP web requests through SSL/TLS encryption. This is critical for protecting sensitive information like financial and personal data transmitted online.

4. WebSocket

WebSocket enables persistent, low-latency real-time communication between clients and servers - ideal for applications like messaging, gaming and stock trading that require constant data streams.

5. TCP (Transmission Control Protocol)

TCP guarantees reliable end-to-end data delivery through sequence numbers, acknowledgments and automatic retransmissions. It ensures complete transfer of data despite network interruptions. Many application-layer protocols build on top of TCP.

6. UDP (User Datagram Protocol)

UDP focuses on sheer speed rather than reliability, blasting video, voice and game data across networks without guaranteed delivery checks. Packets may arrive out of order or go missing altogether.

7. SMTP (Simple Mail Transfer Protocol)

SMTP is the standard that enables routing and transferring of email messages between mail servers, services and clients.

8. FTP (File Transfer Protocol)
FTP allows simple, efficient transfer of files between network devices. Though aging, it's still widely used by services offering file downloads and storage.

Original source




Видео недоступно для предпросмотра
Смотреть в Telegram
explore different type of databases💡

1. SQL Databases: These are relational databases that use Structured Query Language (SQL) for defining and manipulating data. Examples include MySQL, PostgreSQL, ang Oracle Database.

2. Document Databases: These databases store semi-structured data as documents, typically in JSON or BSON format. They are suitable for use cases where flexibility in data schema is required. Examples include MongoDB and Couch base.

3. Columnar Databases: Also known as column-oriented databases, they store data in columns rather than rows, which can provide better performance for analytics and data warehousing. Examples include Apache Cassandra and Apache HBase.

4. Key-Value Stores: These databases store data as key-value pairs, making them simple and efficient for certain types of operations such as caching and session management. Examples include Redis and Amazon DynamoDB.

5. Vector Databases: These databases are optimized for storing and querying vector data, which is common in machine learning and data analytics applications. Examples include Faiss and Milvus.

6. Object Databases: These databases are designed to store objects rather than rows or documents, making them suitable for object-oriented programming paradigms. Examples include db4o and ObjectDB.

7. Graph Databases: These databases are optimized for storing and querying graph data structures, making them suitable for applications like social networks, recommendation engines, and fraud detection.
Examples include Neo4j and Amazon Neptune.

8. In-Memory Databases: These databases primarily store data in memory rather than on disk, resulting in very fast read and write operations. Examples include Redis (again) and Memcached.

9. Time Series Databases: These databases are optimized for storing and querying time-stamped data, making them suitable for loT, monitoring, and financial applications. Examples include InfluxDB and Prometheus.

Original source

Показано 20 последних публикаций.