Iskandar Dev

Iskandar aka Anvarov bilan bo'lgan suhbatimizni YouTubega 5 kun oldin YouTubega yuklagan edim, "organic" qancha ko'rilar ekan deb, menimcha YouTubeda doimiy kuzatadiganlar ko'rib bo'lishdi. Ko'rmay yoki eshitmay qolganlar bo'lsa marhamat, suhbatni tomosha qiling. Suhbat davomida, Gollandiyadagi hayot, Amazonda ish va ijtimoiy hayot balansi va hozirgi kundagi aktual mavzu sun'iy intelekt haqida ham gaplashdik. Xullas tomosha qilamiz 👀 Qo'llab quvvatlash uchun, kanalga obuna, videoni ulashib, izoh qoldirish va like bosishingizni iltimos qilamiz 😊 P.S. Qo'llab quvvatlaganlanlardan biriga Iskandar aka shaxsan taqdim etgan kitobni topshiramiz. Shartlarini video oxirida bilib olishingiz mumkin @khumoyun_codes https://youtu.be/LaXUP_C360s

Principal Engineer bilan ishlash Amazonda Senior engineerdan keyin Principal Engineer(PE) position keladi. Agar system design interview-ga tayyorlangan bo'lsangiz, o'sha high-level architecture-ni PE odatda boshlab beradi - interviewdan farqlisi haqiqatdan ham ishlashi, hech qaysi bir qismda dead-end bo'lmasligi kerak (protocol, component/tools, trust boundaries, security, ops, va h.k.). PE dokumentiga qarab microservicelar tuziladi. Va odatda o'sha microservice-lar jamoalarga bo'lib beriladi. PE-larning umumiy jihati - chuqur texnik va domain bilim. Amazonda muhim komponentlar PE review-dan o'tishi kerak va ochiq savollarni (yechilmagan qismlarni) yopishga PE yordam beradi. PE-larda odatda ochiq soatlari bo'ladi - katta jamoadagi har kimda meeting tashash imkoni bor. Yani jamoa document tayyorlaydi (HLD yoki PRFAQ), qanday yo'l tanlashganini yozib berishadi va PE yo tasdiqlaydi (approval) yoki blocking comment qoldiradi. PE review-dan o'tish qiyinligi - PE kamchilikni ishingizda albatta topadi -💯 . Yuqori standard va talab qo'yish ularning ish-tamoyillaridan biri (insist on highest standards, raise the bar). Lekin sizni bloklab qoymasligi muhim. Shu joyda balans topish qiyin. Har doim ham o'xshamaydi. PE-larning yana bir tamoili - dont afford to be conservative Positiv tajribam: 1 NY-dagi PE o'ta chuqur texnik nuanslarga kirib, barcha muhim qismlarda comment yozib ketadi. Slack-da oz kanali bo'lib, kunlik tarzda tekshirib javob beradi. Kerak bo'lsa, 300 talik guruhlarda to'g'ridan to'g'ri qong'iroq tashab, injener/jamoa bilan ishlaydi. O'zi ham code-review qiladi, kimdir so'rasa. Ya'ni domain va technical bilimi yuqori bo'lgani bilan componentlar qanday ishlashi kerakligini biladi va o'z kutilmalari bilan bo'lishadi. Nimadir to'g'ri kelmasa muammoni tushunishga va yechim topishga harakat qiladi. 2 Seatle-dagi PE ham deyarli shunaqa, faqat o'zini tag qilmaguncha, ishga kirishmaydi. Va bu shaxsan menga tushunarli, har biri 50-60ta injenerga biriktirilgan bo'ladi. Mixed-feeling tajribam: 1 Berlindagi PE ko'p holatda sayoz darajadagi ishga kirishib, umumiy (best practice, company policy) commentlar qoldirib ketadi. Maslahat va takliflarini qarab/yechib chiqanda, keyin yana bog'lanish qiyin boladi. Yani conservative yondashuv bilan ishga kirishadi, riskni to'liq yo'q qilishga harakat qiladi (which isnt possible a-priori in distributed systems) . O'zi PE oldiga savollarni konkret keltirib o'tish kerak, yani slack/meetingdan kutayotgan qaror/javob larni sanab o'tish kerak (odatda ular o'zi ham so'raydi - "nima kutvosan" deb boshlashadi). Ular bilan ishlab o'rgangan narsam - umumiy va boshqa jamolarning tasklarini vaqti-vaqti bilan tanishib, umumiy meetinglarga qo'shilib turish. Boshqa jamoalarning qarorlari va yondashuvlari, qolaversa fuckup (CoE) larini o'rganib turish kerak. Bu bilan tanish ham ortiriladi, domain knowledge ham oshadi. Amazonda bunday meetinglar odatda optional boladi, lekin implicit qadri yuqori. Qoshimchasiga PE va har qanday L7+ odam o'z vaqtini himoyalashni biladi, kerek emas yoki tushunarsiz kommunikatsiyaga kirishmaydi. Ozida imkoni bo'lmaguncha boshqaga javob bermaydi. Blocked/reserved hours-lari har doim boladi. Ha aytgancha, yuqoridagi ikkala PE 3 oylik otpusk olishgani, burnout-driven-development degan hazil bizada chiqargandi. Ular "Q Developer"- ni GA, va aws re:invent uchun tayyorlashgan. Ularning o'ta muhim qismlardagi chuqur ishtiroki , baland narxda kegan desa ham bo'ladi. Lekin kompaniya ularni support qilgani ham e'tiborga sazovor.

Ajoyib yangilik! Do'stim Shamsiddin keyingi oydan Uberda ish boshlaydi. Shamsiddinga omad tilaymiz. P.S. Endi ofisda manam o'zbekcha gapiraman 😁 @kamoloff_log

Offtopic - Abbosbek Fayzullaev Cska-dagi oyligi (bonus va premiyalarsiz) FAANG-dagi middle engineer-ning to'liq kompensatsiyasi bu raqamga teng yoki ko'proq (lokatsiyaga qarab). IT-kompaniyalarini aktsiyalari ham sezilarli o'sib boradi. Xabarni oqigach Azim Pulat intervyularini esladim - "if one of our players is bought by a European club, many people will be happy. But no one is saying that they are leaving us. ".

Tiger team Bu tushuncha NASA-da yaratilgan bo'lib, Amazonda ham tadbiq qilingan. Aslida, birinchi Tiger-team apollo 13-dagi kamchiliklarni to'g'irlash uchun saralangan yangi jamoa bo'ladi. Jamoaning har bir vakili o'z yo'nalishida usta bo'lishgan va vazifa bilan endi tanishishgan bo'lishadi. Shunga qaramay qisqa muddat ichida muvaffaqiyatga erishishadi, va AQSh presidenti ularni medal bilan tag'dirlaydi. Siri esa ular muammoga yangi ko'z bilan qarashi va bir biriga nisbatan hech qanday bog'liqlik bo'lmagani uchun (ichki siyosiy, emotsional yoki martaba) faqat ishga focus olishi, chunki muammoni yechimini topgandan keyin kundalik ish-tartibiga qaytishadi. Amazonda muhim proektlarga qisqa muddat belgilaganda, tiger team tuziladi. Ular odatda director (L8) orqali boshqa jamoalardan kuchli injenerlarni saralab oladi. Ular hammasi har xil jamoadan bo'lishi shart emas, lekin proektga bog'liq bo'lgan tajribaga ega va ko'zga ko'ringan bo'lishi kerak (shu qismi muhim). Qiyinchiligi: 1 yangi service va code-base bilan tanishib boshqa jamoa bilan birga ishlash. 2 Qisqa muddatda result olib kelish 3 Yuqori darajadagi boshqaruv - audit va hisobot berganda o'ta professional bo'lish. Hosili: 1 yuqori darajdagi boshqaruv - departamentlar aro (cross org) muammolarni/to'siqlarni yechishga yordam beradi 2 Kuchli stress vaziyatda ishlashni o'rganish - keyinchalik kun-tartibdagi vaziyatlar sodda bo'lib ko'rinadi 3 Lavozimda o'sish - tiger-teamdagilar odatda career-growth-ga maqsadlangan bo'lishadi va, muvafaqiyat vaziyatda, L8 digilardan qo'llab-quvatlanadi. Men 2 marta tiger-team bilan ishlaganman. Ikkala galda ham faqat Amerikadagi expatlar edi. O'zimni ko'p ishlaydigan pedant deb bilsam ham, ularga nisbatan hali o'sish kerakligini ko'rdim. 3ta shaxs keyingi 6 oy ichida lavozimda o'sdi - 1 Principal-ga, 2tasi seniorga. Amazon uchun bu juda tez. Avvalroq yozganimdek odatda 1-1.5 yilda bajariladigan process. Tiger-team, keyingi 1-2 oy ichida, asosiy jamoalarga qo'shimcha texnik va organizatsion yordam va tushintirish ishlarini olib borishadi. Director bu - L8 , undan keyin senior manager(SSDM - L7) va oddiy manager(SDM -L6) bo'ladi. Director servis uchun yo'nalish va budget belgilaydigan odam.

2024 sarhisobotim - 2 ta design doc yozdim, 1 da PRFAQ - Yil davomida, 3 ta Principal Engineer (L7) bilan day-to-day birga ishladim. - 5 ta feature chiqishida xizmat qildim, 2-tasida lead bo'ldim - PRFAQ documentimda director (L8) bilan slackda yozishdik. Qizig'i o'zim organizatsiyadagi emas, balki Identity-centerdan - Hammasi siliq bo'lgani emas. Kamchilik topildi, CoE yozdim. - Kuchli jamoadoshlarimga nisbatan sekin kod yozaman. - Line va Skip managerlarimdan L6 promotion plan yozishga taklif oldim . Hozircha yoq dedim. Nasib etsa yaqin orada tushuntira olaman. - 200+ code-review qildim. Hammasi merge bolgani emas, and that is okay. - Va eng muhimi 2-marta Ada bo'ldim Bularni yozish osonligi - amazonda har yillik self-reflection yozish kerak. Oshandan qisman ko'chirdim. Ko'proq ozim uchun, keyin qaytib kelganimda 2024 yil voqealarini esliman.

Va aytgancha yaqinda ofisimizda bir event bolib otkan edi. Ulashdim. Gergely email-yangiliklariga/substacklariga obuna bolishni maslahat beraman. Yaqinda podkast ham boshlagan

Amazon-dagi product/feature development lifecycle Amazondagi "Working Backwards" processi haqida eshitgan bolsangiz kerak. Qisqacha qilib etkanda yangi product-lar foydalanuchilarga topshirishga tayyor bolgandek tasniflab beruvchi document/reklama bilan boshlanadi - "Product release/frequently asked questions"(prfaq). Bu document product-teamda foydalanuvchilar bilan togridan-togri muloqot qilib muammo va tajribalarini organish jarayonida yoziladi. Ular boshliq va project-management ga pitch qilgan holda texnik detallar va resurslarni aniqlashtirish uchun ishni topshiradi. Management-ning asosiy fazifasi - mahsulotni prioritetini belgilash va pul/vaqt/odam ajratish. Ish injenerga kelganda asosan deadline ham belgilangan boladi. Shuni hisobga olib texnik documentlar yoziladi. 1 High-level design - system behavior/depedency/componentlarni ozaro bogliqligi. Bu yerda ochiq savollar topiladi va product/project managerlarga aniqlashtirish uchun yuboriladi. 2 Low level design - componentlar nima va qanday ish qilishi. Qoshimchasiga Ish qismlarga bolinishi va vaqt olchamlari keltirilib otadi. But qismda ham noaniq detallar project/product ga yuboriladi. Kod yozishga kelganda deyarli hamma narsa ochiq-oydin bolishi kerak. Shunchaki foydalanuvchi koriladigan soz/matnlar tech-writerga yuborilib aniqlashtiriladi. Mahsulot tayyor bolgandan keyin foydalanuvchiga ochiqlanmaydi, balki application security engineer uchun review tashlanadi. Bu kod-yozish paytida parallel olib boriladi. Odatda. Va review tashlangandan keyin security injener threat modelling-dan otkazib, testlar va prooflarni belgilaydi (talab etadi), pentest belgilashi ham mumkin. Bundan keyin product minimal operational readiness bilan tayyor bolib foydalanuvchiga ochiqlanadi. Lekin toliq "operation readiness review" baribir kerak boladi. Bu boshqa injenerlar ham kerak bolganda tizim qanday ozini tutayotganini tushinib muammolarni monitor va hal qila olishi uchun majburiy protses.

10 yil bo’libdi. Shu platformasiz Germaniyaga kelmagan bo’lar edim. 🥂

Menga ham shu platforma yordam bergan. Men Amazonga apply qilmaganman, qolgan hamma kompaniyalarga apply qilgan paytimda. Amazon mani leetcode va profilinmi yangilaganim sababli topgan. 2022-yil yanvarda ozlari linkedin orqali chiqishgan. O'sha payt, 1 oydan keyin qaytib kelin deb javob berganman, va qogan FAANGlarga topshirib chiqanman

Agar student yoki kareerani boshlang'ich yo'llaridagi ijnener bo'lsangiz, Nuruddin Iminokhunov interview/podkastlarini maslahat beraman. Nuruddin injener, product va project manager bo'lib ishlagan (Ozbekistondan turib Meta corp. product specialist bo'lgan). Hozirga IT-kompaniya asoschi-boshqaruvchisi, podkastda O'zbekistondagi imkoniyatlar, injenerlarga talab/taklif va product/project manager ishi haqida fikr-mulohazalarini bo'lishadi. Yani yosh kadrlar imkoniyati, ish-talablarini yoritadilar. O'z professional (de fua) yo'llarini yoritadilar (spoiler - har doim harakat qilish kere). O'zim yana bir bor amin bo'ldimki, Super Dispatch istedotlarni kashf etadigan korxona.

2 haftalik ta'tilim ham tugadi. Ta'tildan oldin Shokhrukh (Principal Engineer, Booking.com) aka podcast/interview-larida maslahat bergan kitobni buyurtma bergan edim - the Staff Engineer's Path. Seniorlikka harakat qiladiganlar uchun ham foydali ekan. Agar tech-korxonada yoki senior/lead ro'llarida ishlab kelayotgan bo'lsangiz - ish davomida uchraydigan boshqaruv/tashkiliy muammolarga tasnif va yechim yo'llarini topa olasiz: • Staff+ injener nima qiladi • Yillarga joziladigan texnik-ish qanday boshlanadi. Moliyaviy qoplanish muhakama yo'llari • Bir nechta jamoalarni qamraydigan texnik muammolar/maqsadlar qanday belgilanadi • Qo'shni jamoalar(upstream/downstream dependent) va Project/Product/Design bilan ishlash va maqsadga erishish uchun kommunikatsiya uslublari • Katta yangilikni foydalanuvchilarga chiqarishdagi marketing/operational/customer-adoption ishlari Ayniqsa, qo'shni jamoalarga va project/product managerlar bilan ishlash, o'zaro bog'liqlik va masuliyatni bo'lishish haqida yaxshi keltirmalar mavjud. Kitob muallifi google-da staff enginer bo'lgan va FAANG -dagi ishlash tartiblarini ta'riflab ketgan.

Eeee, kepqolilar podcastlarga! Mana qaynoqqina podcastlar! Eshitmadim demanglar keyin yeg'lab yurmanglar! Bu safargi podcastimiz Amsterdamning Amazon kompaniyasining AWS komandasida Software Engineer bo'lib ishlovchi Iskandar Anvarov bilan bo'ldi. Suxbat olov-olov bo'ldi 🔥🔥🔥 Quyidagi mavzular yoritib tashadik: — Amazondagi o'zbeklar — Iskandarning O'zbekistondagi karyerasi — WIUTning kuchli professorlari — Dilshod Ibragimov va Business Intelligence — Sinelda ishlash va olingan ko'nikmalar — Seniorlar orasida o'sish — Comfortni tashlab Yevropaga ketish — FAANG orzusi va endi nima? — Oila masulyatlari bilan FAANGga harakat qilish — Yevropaga kelganingizga afsuslanmaysizmi? — FAANGga tayyorlanish va interview jarayoni — Amazon leadership printsiplari — Amazon vs Google engineering culture — FAANG orzusidagilar uchun maslahatlar — Amazonda ishchilar ko'p ishlashadimi? — Amazon Q — Amazonda work-life balance — Yevropa va Amerika oyliklari — Amazondagi perklar (banandan tashqari) — Amazondagi texnik o'sish va promotion jarayoni — Performance Improvement Plan (PIP) https://youtu.be/VOdaCZHM6I0

Amsterdamdagi O’zbek dasturchilar bilan birga: Football & Lunch

Nodir Turakulov is visitng Amsterdam's office. For context: He is a Principal Engineer at AWS, and from Uzbekistan. He has teams in Amsterdam under his supervision ( my sister teams)

LLM, GPT va chatbot-ga kirish. (3-minutlik material) Amazon Q va ChatGPT ishlashini ko'rib chiqilaylik. Shunda ish o'rinlarimizni olmoqchi bo'lgan "AI" dushmani yaxshiroq bilib olamiz. Boshlashdan oldin - men ,ML/Data Science va AI larda chuqur Ilmiy bilimlarim yo'q. Men dasturchi va Q-Servisini qurishda, bazaviy ML/AI tushunchalar, chatbotlarning arxitekturasi va ishlash printsiplarini o'rganganim bilan bo'lishaman. Chatbotlarning o'zagi bu LLM - katta til modellari. Eshitgan bo'lsangiz kerak chatGPT 4 trillion token larga o'rgatilgan bo'lgan. Oddiy qilib etkanda token bu so'z + vektor, yani boshqa so'zlarga bog'liqlik darajasi. Misol "ilm" va "fan" so'zlari bir-birig mano jihatdan yaqin, va ko'p holarda birga ishlatiladi. Shunda LLM- da bu ikki so'z vektorlari ham "yaqin" qiymatlariga ega bo'ladi. LLM-ning So'z va Vektorlardan gap tuzish qobiliyati "Transformer Layerlar" dan kelib chiqadi. Ularni vazifasi ham oddiy - so'zlar ketma-ketligini grammatik, sinktatik va kontekst orqali bog'lash. Misol eng mashhur transformer layerlardan biri bu Attention layer - u so'rovdagi asosiy so'zlarni topishda va ularga weight ( o'lchov og'irligi ) beradi. Yana biri Embedding layer, so'zlarni syntaktik va semantik bog'ligini o'lchaydi( grammatika va kontekst). Chatgt-4 da 120 ta transforming layerlar ishlatilgan. Transformerlar Vektor parameterlari/o'lchamlarini boyitshdan tashqari, mavjudlarini ham to'girlab ketishadi. GPT - generative pre-trained transformer - Tekst va unga o'xshash ma'lumotlar(misol kod) yaratishda LLM-dan foydalanib so'zma so'z bog'lanish tuzadigan arxitektura. Yani savolni ham parchalab o'qib, parchalab javob tuzadi. Misol: "eng kuchli kompyuter qaysi" "Eng", "Eng kuchli", "eng kuchli kompyuter" va hakozo. Shu usulda u ikkilamchi, asosiy so'zlarni, ularning bog'liqligi, abstrakt/kontekst va hakozo parameterlarini yeg'adi. Va javob berishda ham so'zma-so'z ketma-ketlik tuzib har bir yangi so'zda transforming layerlarni yurg'izdirib chiqadi. Shuning uchun ham chatbotlarda to'lov belgisi bu so'rov-javobdagi so'zlar/belgilar soni, chunki har biri uchun butun boshlik arxitektura yana boshidan ketma-ketlikda yurg'izdiriladi. Chatgpt-ning texnologik innovatsiyasi ham shunda edi. Birdaniga javob berish o'rniga eng maqbul so'zlarni birin-ketin topish orqali gap tuzish. Shunda eng o'rinli so'zlar bilan ma'noli gap tuzish ehtimoli oshadi LLM lar Foundation Model(FM) ustida qurilgan. Yani training paytida yeg'ilgan bilimlar, va inson aralashuvisiz bilim ustida bilim qurish orqali to'plangan token va vektor qiymatlarini ishlatadi. FM-lar Peta-bayt (million terrabayt) hajmdagi internet-tarmoqda mavjud bo'lgan informatsiya bilan o'rgatilgan. Har bir so'z uchun 120ta transformer algorithm-larni yurg'izish uchun kuchli kompyuterlar kerak. Lekin, xayriyatki, ular parallelashitiriladigan funktsiyalar. Parallel ishlash esa GPU xaritalar orqali juda oson. Va AI revolutsiyasi GPU va Data-Processing narxlarini oshirtirib yuborgan. Keyingi qismda LLM-dagi topK topP va temperaturasi haqida gaplashamiz, chatbotlarning gallyutsinatsiya qilish sabablarini tushunamiz.