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

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

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)

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

Good articles to read during weekends:

— How Google Search Works
— I Worked More and Achieved Less. How To Get Your Team Engaged
— Can We Please Avoid Over-Engineering - YAGNI
— Even Data can't Escape Physics..
— Some Undesirable Behaviors in Software Engineers
— The best way to test Web APIs
— Why your job search is failing as an engineer or a manager
— Session Management Demystified
— Design spotify system design interview

Original post

Books must read list:

— Cracking the coding interview
— Grokking Algorithms
— Introduction to Algorithms
— Programming Interview Exposed
— Designing Data-Intensive Applications

JetBrains dan offer oldim 🎉

Maqola uchun havola.

Bollar biz yutamiz!

Google is hiring Junior Engineers (L3)! 🚀

🇺🇿 O‘zbekistondan turib men kabi ariza topshirib "offer" olishingiz mumkin. Men shu oyda O‘zbekistondan turib suhbatdan o‘tgan 3 nafar nomzodni bilaman.

Yevropa bo‘ylab 30 ta bo‘sh ish o‘rni mavjud!
• 6 tasi Germaniyaning Munich shahrida 🇩🇪
• 8 tasi Shveysariyaning Zurich shahrida 🇨🇭
• Yana bir nechtasi Polshada 🇵🇱

Intervyuga qanday tayyorgarlik ko‘rganim haqida post shu yerda.

European Championship 2025 - Online Mirror (Unrated, ICPC Rules, Teams Preferred) will take place on the 2nd of March at 10:35 UTC.
Please, join by the link https://codeforces.com/contests/2068

Otabek studied in Poland and received offers from Meta, IBM, Google, and Dropbox. He is now a Senior Software Engineer at Dropbox. A very useful podcast for those who are studying in Poland or planning to.

⸻
🇺🇿 Otabek Polshada o’qib Meta, IBM, Google, va Dropbox’dan offer olgan, hozir Dropbox'da Senior Software Engineer. Polshada tahsil olayotgan yoki rejalashtirayotgan talabalar uchun juda foydali podcast.

🔗 https://www.youtube.com/watch?v=UKUHx5P3ISk

1. 𝐈𝐧𝐝𝐞𝐱𝐢𝐧𝐠: Create indexes on frequently queried columns to speed up data retrieval.

2. 𝐕𝐞𝐫𝐭𝐢𝐜𝐚𝐥 𝐒𝐜𝐚𝐥𝐢𝐧𝐠: Upgrade your database server by adding more CPU, RAM, or storage to handle increased load.

3. 𝐂𝐚𝐜𝐡𝐢𝐧𝐠: Store frequently accessed data in-memory (e.g., Redis, Memcached) to reduce database load and improve response time.

4. 𝐒𝐡𝐚𝐫𝐝𝐢𝐧𝐠: Distribute data across multiple servers by splitting the database into smaller, independent shards, allowing for horizontal scaling and improved performance.

5. 𝐑𝐞𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧: Create multiple copies (replicas) of the database across different servers, enabling read queries to be distributed across replicas and improving availability.

6. 𝐐𝐮𝐞𝐫𝐲 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐚𝐭𝐢𝐨𝐧: Fine-tune SQL queries, eliminate expensive operations, and leverage indexes effectively to improve execution speed and reduce database load.

Original source

Phew! What a crazy period it was. I've honestly never worked so hard! The models are launched, I'm on an airplane and it is time for a post ✏️.

I think it's ok if I talk a bit about what I built without revealing confidential stuff. Very roughly speaking, there are two big phases of training a model:

- During pretraining (PT) the model acquires base knowledge from the internet text, code, images and whatever else the Tokens team has. The goal is to predict next token, so this is supervised learning.

- During Reinforcement Learning (RL), the pretrained model is put into various RL "environments" where it is given some goal and it generates "action tokens" that should get it closer to the goal. For example, if this was a game of Chess, the environment would a chess board and the action tokens would be moves. After a model performs an action, the environment state might change and the model can reassess the situation and produce new actions. The goal here is not to predict some specific token, but generate action tokens such that some reward goes up, for example it wins a game or all tests pass. An action can also be a tool invocation, e.g. call Bash or edit a file. I like to think of RL Envs as classrooms where Claude studies and we have a lot of different ones. An RL loop is basically doing some sampling, computing the rewards, computing gradients, updating the model, rinse and repeat.

The more training we do and the more diverse representative environments we have, the smarter the model gets. We use word "sampling" for token generation (because we "sample" from the probability distribution that the model represents) and at our RL scale we need A LOT of identical sampling replicas/deployments, each consisting of multiple VMs.

One critical part of an RL step is, each time the model is updated, we need to to redistribute the new version to all sampling replicas, as fast as possible. I cannot talk about the specifics of the scale, but it is a proportional to the product of the model size (Opus is gigantic) and the number of sampling replicas (we want a LOT). We are multi cloud, so the solution must work on both GCP and AWS, and unfortunately GCS doesn't scale to our needs 🤷🏻‍♂️ . Note that we must do this transfer after each RL step, so saving a gigantic model to an object store just for a brief period of time is not very efficient.

In fact we want so many AI chips for RL that no single data center has enough AI chips, so the sampling servers reside in multiple data centers. The bandwidth across data centers is not the same as within the data center, so ideally the transfer solution is aware of the network topology. By data center I don't necessarily mean a region, but more abstractly, e.g. even a single AZ has non-uniform bandwidth within.

To add some complexity to this, the model is large enough that it doesn't fit one machine, obviously, so it has to be sharded, but trainers and samplers want it sharded along different dimensions. To give an oversimplified example, imagine that N training machines have rows of a 2D matrix but M sampling machines (of one sampling replica) want columns. So, not only we need to transfer a model, we also want to reshard it.

I've designed and implemented the model transfer solution that covers all above, and led a couple of people to implement some parts of it. I think I've rewritten it twice at this point and the latest version is in Rust. It is used in production RL since Sonnet 3.7.

I can't talk about the actual solution and will leave this as an exercise for the reader 😄. How would you solve it? The optimization metric is transfer latency. The constraints of the problem are:
- gigantic model
- a lot of destination replicas
- each destination replica has multiple machines
- multiple tensors of different shapes and sizes
- source and destination shard the tensors differently
- non-uniform network topology
- the model params comes from/goes to AI chip memory (HBM)
- potentially multiple NICs
- must support cross-region transfers
- Linux

💡 Coding Project Ideas for Learning & Leveling Up Programming Skills

https://dev.to/kishansheth/200-project-ideas-from-beginner-to-advanced-with-open-source-contributions-3g6a

MORE:
1. 50 project ideas, 100 simple coding tasks

2. https://codingchallenges.fyi/challenges/intro/

3. https://github.com/codecrafters-io/build-your-own-x

@cracking_maang