13-BOB. To'liq Mock (sinov) Intervyu Ssenariylari

Bu bob — kitob nazariyasini amaliyotga bog'laydigan bo'g'in. Bu yerda siz uch xil daraja (Junior, Middle, Senior) uchun boshidan oxirigacha real intervyu dialogini o'qiysiz: tanishuvdan tortib nomzodning o'z savollarigacha. Har bir savoldan keyin kuchli javob namunasi, ba'zan zaif javob, va izoh beriladi. Maqsad — sizni jonli suhbatga tayyorlash.

Mock intervyudan qanday foydalanish kerak

Mock intervyu — bu "o'qib chiqiladigan" material emas, balki "mashq qilinadigan" trenajor. Undan maksimal foyda olish uchun quyidagicha ishlang:

1. Avval o'zingiz javob bering. Har bir savolni o'qigach, "Kuchli javob" qismini darrov ochib yubormang. Ekranni yoping yoki qo'lingiz bilan berkiting va ovoz chiqarib javobingizni ayting. Ovoz chiqarib gapirish — kalitli nuqta, chunki intervyuda ham xuddi shunday bo'ladi.

2. Vaqtni o'lchang. Texnik savolga 1-2 daqiqa, live-coding masalasiga 15-25 daqiqa, system design'ga 30-40 daqiqa ajrating. Sekundomer bilan mashq qilish sizni real bosim ostida gapirishga o'rgatadi.

3. Javobingizni namuna bilan solishtiring. O'zingiz aytgan javobni "Kuchli javob" bilan qiyoslang. Nimani tushirib qoldirdingiz? Qaysi atamani noto'g'ri ishlatdingiz? Farqni daftaringizga yozib qo'ying.

4. Izohni sekin o'qing. "Izoh" qismi eng qimmatli — u intervyuchining boshida nima kechayotganini ko'rsatadi. Savol nima uchun berilganini tushunsangiz, kelajakda o'xshash savollarga ham javob bera olasiz.

5. Rolni almashtirib mashq qiling. Do'stingiz yoki hamkasbingiz bilan juftlashib, biri intervyuchi, biri nomzod bo'lib o'ynang. Keyin rollarni almashtiring. Intervyuchi tomonida turish sizga "ular nimani kutayotganini" ochib beradi.

6. Zaif javoblarga alohida e'tibor bering. "Zaif javob" namunalari — bu real nomzodlar qiladigan tipik xatolar. O'zingizni ularda tanib qolsangiz, aynan o'sha odatni tuzatish ustida ishlang.

7. O'zingizga mos darajadan boshlang, lekin bir pog'ona yuqorini ham o'qing. Agar Junior bo'lsangiz, Middle mock'ini ham o'qing — bu sizga qayerga o'sish kerakligini ko'rsatadi.

Muhim eslatma: Bu ssenariylardagi javoblar "yod olish uchun" emas. Ularni o'z so'zlaringiz bilan qayta aytishga harakat qiling. Intervyuchi yodlangan matnni bir zumda sezadi. Maqsad — tushunchani egallash, matnni emas.

1-MOCK: JUNIOR FRONTEND DASTURCHI INTERVYUSI

Kontekst: Nomzod — bootcamp yoki o'z-o'zini o'qitish orqali 8-10 oy o'rgangan, 1-2 ta pet-loyihasi bor Junior frontend dasturchi. Vakansiya — React asosidagi kichik startapda. Intervyu davomiyligi ~50 daqiqa. Intervyuchi — jamoaning katta dasturchisi (Tech Lead).

1-bosqich: Tanishuv

Intervyuchi: Assalomu alaykum, tashrifingiz uchun rahmat. Boshlashdan oldin, o'zingiz haqingizda qisqacha gapirib bera olasizmi? Dasturlashga qanday kelib qoldingiz va hozir nima ustida ishlayapsiz?

Kuchli javob: Assalomu alaykum, taklif uchun rahmat. Men frontend dasturlash bilan taxminan bir yil oldin jiddiy shug'ullana boshladim. Boshida HTML va CSS bilan oddiy sahifalar yasaganman, keyin JavaScript'ga o'tib, DOM bilan ishlashni o'rgandim. So'nggi olti oyda esa asosan React'ga sho'ng'idim. Hozir o'zimning eng katta loyiham — kichik "vazifalar rejalashtiruvchi" ilova: React va localStorage'da ishlaydi, foydalanuvchi vazifa qo'shishi, tahrirlashi va filtrlashi mumkin. Uni yozish jarayonida state boshqaruvi va komponentlarni bo'lish men uchun eng ko'p narsa o'rgatgan. Sizning jamoada real mahsulot ustida ishlab, tajribali dasturchilardan o'rganishni juda istayman.

Izoh: Bu javob qisqa, tuzilgan va aniq. Nomzod xronologik yo'lini bergan (HTML/CSS JS React), konkret loyiha nomini aytgan va undan nima o'rganganini ta'kidlagan. Oxirida vakansiyaga qiziqishini bildirgan. Intervyuchi bu yerda texnik bilimni emas, balki nomzodning o'zini ravon ifodalay olishi va yo'nalishini baholaydi. "Real mahsulot ustida o'rganishni istayman" degan jumla junior uchun ayni muddao — u kamtar va o'sishga tayyor ekanini ko'rsatadi.

Zaif javob: "Ha, men dasturlashni yaxshi ko'raman. YouTube'dan ko'p video ko'rganman va React bilaman. Boshqa nima deyishni bilmayman."

Bu javob juda qisqa, tuzilmagan va o'ziga ishonchsizlik hissini beradi. "Boshqa nima deyishni bilmayman" degan jumla suhbatni to'xtatib qo'yadi. Konkret loyiha yoki natija yo'q — intervyuchi nomzodning haqiqatan nima qila olishini tasavvur qila olmaydi.

2-bosqich: Texnik savollar (osondan qiyinga)

Intervyuchi: Yaxshi. Keling, asoslardan boshlaymiz. JavaScript'da let, const va var o'rtasida qanday farq bor?

Kuchli javob: Uchalasi ham o'zgaruvchi e'lon qilish uchun ishlatiladi, lekin qamrovi (scope) va qayta tayinlanishi bilan farq qiladi. var — funksiya qamrovli (function-scoped) va u eskirgan uslub hisoblanadi, hozir kam ishlatamiz. let va const esa blok qamrovli (block-scoped), ya'ni jingalak qavs ichida amal qiladi. let bilan e'lon qilingan o'zgaruvchini keyin qayta tayinlash mumkin, const esa qayta tayinlanmaydi — u doimiy. Ammo shuni ta'kidlash kerak: agar const bilan obyekt yoki massiv e'lon qilsak, uning ichini o'zgartirish mumkin, faqat o'zgaruvchini yangi qiymatga bog'lab bo'lmaydi. Men odatda birinchi navbatda const ishlataman, faqat qiymat o'zgarishi kerak bo'lsagina let'ga o'taman.

Izoh: Bu javob to'liq va nozik nuqtalarni ham qamragan. Nomzod nafaqat farqni aytdi, balki const bilan obyektning ichi o'zgarishi mumkinligini (ya'ni "immutable binding, mutable value" tushunchasini) tushuntirdi — bu ko'p junior tushunmaydigan detal. Oxirida amaliy odati ("avval const") haqida aytishi — u qoidani yodlab emas, ishlatib o'rganganini ko'rsatadi.

Intervyuchi: Yaxshi tushuntirdingiz. Endi HTML tomoniga o'taylik: semantik HTML nima va nega u muhim?

Kuchli javob: Semantik HTML — bu teglarni ularning ma'nosiga qarab ishlatish demakdir. Ya'ni har joyda div va span ishlatish o'rniga, header, nav, main, article, section, footer kabi teglardan foydalanamiz. Bu muhim, chunki, birinchidan, kod o'qilishi osonlashadi — boshqa dasturchi darrov qaysi qism nima ekanini tushunadi. Ikkinchidan, bu SEO uchun foydali, qidiruv tizimlari sahifa tuzilishini yaxshiroq anglaydi. Uchinchidan va eng muhimi — bu foydalanuvchi imkoniyatlari (accessibility) uchun kerak: ekran o'quvchi dasturlar (screen readers) semantik teglar orqali ko'zi ojiz foydalanuvchilarga sahifada navigatsiya qilishga yordam beradi. Masalan, foydalanuvchi to'g'ridan-to'g'ri asosiy kontentga o'tib olishi mumkin.

Izoh: Junior nomzoddan accessibility haqida gapirishni kutish yuqori ball. Ko'pchilik faqat "SEO uchun yaxshi" deb qo'ya qoladi, lekin bu nomzod uchta aniq sabab keltirdi va ekran o'quvchi misolini berdi. Bu uning shunchaki teg nomlarini emas, ular ortidagi maqsadni tushunishini ko'rsatadi.

Intervyuchi: CSS'ga o'taylik. flexbox va grid o'rtasida qanday farq bor, qaysi birini qachon ishlatasiz?

Kuchli javob: Ikkalasi ham zamonaviy layout tizimlari, lekin asosiy farq — o'lchamlar sonida. Flexbox bir o'lchamli (one-dimensional): u elementlarni yo qator bo'ylab, yo ustun bo'ylab, ya'ni bitta yo'nalishda joylashtiradi. Grid esa ikki o'lchamli (two-dimensional): bir vaqtda ham qatorlar, ham ustunlarni boshqara oladi. Amalda men flexbox'ni komponentlar ichidagi elementlarni tekislash uchun ishlataman — masalan, navbar'dagi logotip va menyuni bir qatorga joylash yoki tugma ichidagi ikonka va matnni markazlash. Grid'ni esa butun sahifa maketi uchun ishlataman — masalan, kartochkalar galereyasi yoki header-sidebar-content-footer tuzilishi. Ba'zan ikkalasini birga ham ishlataman: grid bilan umumiy maketni, uning ichidagi har bir katakni esa flexbox bilan tekislayman.

Izoh: Bu javobning kuchi — nazariyani amaliyot bilan bog'lagani. "Bir o'lchamli va ikki o'lchamli" farqi to'g'ri, lekin haqiqiy qiymat konkret misollarda: navbar uchun flex, galereya uchun grid. Oxirgi jumla ("ikkalasini birga") nomzodning real kod yozganini isbotlaydi.

Zaif javob: "Flexbox ham, grid ham layout uchun. Men doim flexbox ishlataman, chunki u osonroq. Grid'ni unchalik ishlatmaganman."

Bu javob nomzodning tajribasi tor ekanini ko'rsatadi. Faqat bittasini bilish yomon emas, lekin "grid'ni ishlatmaganman" deyish o'rniga hech bo'lmasa "grid'ni ikki o'lchamli maketlar uchun deb bilaman, lekin hali amalda kam ishlatganman" deyish yaxshiroq bo'lardi — bu halollik bilan bilimni birlashtiradi.

Intervyuchi: Endi JavaScript'ning muhim tushunchasi. Sinxron va asinxron kod nima? Promise nima uchun kerak?

Kuchli javob: JavaScript — bir oqimli (single-threaded) til, ya'ni u bir vaqtning o'zida bitta ishni bajaradi. Sinxron kod ketma-ket ishlaydi: birinchi qator tugamaguncha ikkinchisi boshlanmaydi. Ammo ba'zi amallar vaqt talab qiladi — masalan, serverdan ma'lumot olish yoki fayl o'qish. Agar bularni sinxron qilsak, butun sahifa muzlab qolardi, chunki brauzer kutib turishga majbur bo'lardi. Shu sababli asinxron kod ishlatamiz: amalni ishga tushiramiz-u, natijasini kutmasdan boshqa ishlarni davom ettiramiz, natija tayyor bo'lgach esa uni qayta ishlaymiz. Promise — aynan shu "kelajakda tayyor bo'ladigan natija"ni ifodalaydigan obyekt. Uning uch holati bor: pending (kutilmoqda), fulfilled (muvaffaqiyatli bajarildi) va rejected (xato yuz berdi). Men odatda Promise'lar bilan async/await sintaksisi orqali ishlayman — u kodni sinxron kabi o'qiladigan va tozaroq qiladi.

Izoh: Junior uchun bu kuchli javob. Nomzod "single-threaded" tushunchasidan boshlab, muammoni (muzlab qolish) va yechimni (asinxronlik) mantiqiy zanjir bilan tushuntirdi. Promise'ning uch holatini aniq aytdi va async/await'ni tilga oldi. Bu junior darajasidan bir oz yuqori — intervyuchi bunday javobdan mamnun bo'ladi.

Intervyuchi: Ajoyib. Endi React'ga kiramiz. useState hook'i nima qiladi va nima uchun oddiy o'zgaruvchi o'rniga uni ishlatamiz?

Kuchli javob: useState — React'ning eng asosiy hook'i, u komponentga holat (state) qo'shish imkonini beradi. U bir massiv qaytaradi: birinchi element — joriy holat qiymati, ikkinchisi — o'sha holatni yangilaydigan funksiya. Masalan, const [count, setCount] = useState(0). Nima uchun oddiy o'zgaruvchi emas? Chunki oddiy let o'zgaruvchini o'zgartirsak, React buni sezmaydi va ekranni qayta chizmaydi (re-render qilmaydi). useState'ning yangilash funksiyasini chaqirsak esa, React holat o'zgarganini biladi va komponentni yangi qiymat bilan qayta render qiladi. Ya'ni asosiy farq — useState React'ga "ekranni yangila" degan signal beradi, oddiy o'zgaruvchi esa bermaydi. Yana bir muhim jihat: holatni to'g'ridan-to'g'ri o'zgartirmaslik kerak, doim setter funksiyasini ishlatish kerak.

Izoh: Bu javobning eng qimmatli qismi — "nima uchun oddiy o'zgaruvchi emas" savoliga aniq javob bergani: re-render mexanizmi. Ko'p junior useState'ning sintaksisini biladi, lekin "React qanday qilib o'zgarishni sezadi" degan savolga qoqilib qoladi. Bu nomzod render mantig'ini tushunadi. "Holatni to'g'ridan-to'g'ri o'zgartirmaslik" haqidagi eslatma ham qo'shimcha ball.

Intervyuchi: useEffect haqida gapiring. U qachon ishga tushadi va dependency array (bog'liqliklar massivi) nima uchun kerak?

Kuchli javob: useEffect — komponentda "yon ta'sirlar"ni (side effects) bajarish uchun ishlatiladi. Yon ta'sir deganda render'ning o'zidan tashqari amallar tushuniladi: serverdan ma'lumot olish, obunaga yozilish (subscription), yoki hujjat sarlavhasini o'zgartirish kabi. useEffect ikkita argument oladi: funksiya va dependency array. U qachon ishga tushishi aynan shu massivga bog'liq. Agar massiv bo'sh bo'lsa — [] — effekt faqat bir marta, komponent birinchi render bo'lganda ishlaydi. Agar massivga biror qiymat qo'ysak, masalan [userId], effekt o'sha qiymat o'zgarganda qayta ishga tushadi. Agar massivni umuman bermasak, effekt har bir render'da ishlaydi — bu ko'pincha xato bo'ladi va cheksiz sikllarga olib kelishi mumkin. Yana useEffect ichida "tozalash" funksiyasini (cleanup) qaytarish mumkin — masalan, obunani bekor qilish yoki taymerni tozalash uchun. U komponent DOM'dan olib tashlanganda yoki effekt qayta ishga tushishidan oldin chaqiriladi.

Izoh: Bu junior uchun juda kuchli javob — hatto middle darajasiga yaqin. Nomzod uchala holatni ([], [qiymat], massiv yo'q) aniq ajratdi va "cheksiz sikl" xavfini eslatdi. Cleanup funksiyasini tushunishi esa uni ko'pchilikdan ajratib turadi. Intervyuchi bu yerda nomzodning React'ni faqat sirtdan emas, mexanizm darajasida bilishini ko'radi.

3-bosqich: Live-coding

Intervyuchi: Endi kichik bir kodlash mashqi qilaylik. Sizdan bir funksiya yozishingizni so'rayman: unga string beriladi, u shu stringni teskarisiga o'girib qaytarishi kerak. Ovoz chiqarib o'ylab, qadam-baqadam yozing.

Kuchli javob (fikrlash jarayoni bilan): Yaxshi, avval masalani tushunib olay. Menga string kiradi, masalan "salom", va men "molas" qaytarishim kerak. Buni bir necha yo'l bilan qilsa bo'ladi. Eng sodda yechim — JavaScript'ning tayyor metodlaridan foydalanish: stringni massivga aylantirib, massivni teskari qilib, yana stringga qaytarish.

function reverseString(str) {
  return str.split("").reverse().join("");
}

console.log(reverseString("salom")); // "molas"

Bu yechim ishlaydi va o'qilishi oson. Lekin agar intervyuda "tayyor reverse metodisiz qiling" deyishsa, men siklda ham yozardim:

function reverseStringManual(str) {
  let result = "";
  for (let i = str.length - 1; i >= 0; i--) {
    result += str[i];
  }
  return result;
}

Bu ikkinchi variant string'ning oxiridan boshiga qarab yuradi va har bir belgini natijaga qo'shadi. Ikkalasi ham to'g'ri ishlaydi; birinchisi qisqaroq, ikkinchisi esa mexanizmni yaxshiroq ko'rsatadi.

Izoh: Bu yerda intervyuchi kodning o'zidan ko'ra jarayonni baholaydi. Nomzod avval masalani misol bilan aniqlashtirdi ("salom" "molas"), keyin sodda yechimni berdi va uni tushuntirdi. Eng muhimi — u ikkinchi, qo'lda yozilgan variantni ham taklif qildi, bu uning tayyor metodlarga tayanibgina qolmasdan, asosiy mexanizmni ham bilishini ko'rsatadi. Ovoz chiqarib o'ylash — live-coding'da eng qadrlanadigan ko'nikma.

Intervyuchi: Yaxshi. Endi biroz murakkabroq: menga massivda takrorlanmaydigan (unique) elementlardan iborat yangi massiv qaytaradigan funksiya kerak. Masalan, [1, 2, 2, 3, 3, 3] uchun [1, 2, 3] qaytishi kerak.

Kuchli javob: Bu masala uchun eng zamonaviy va toza yechim Set'dan foydalanish. Set — bu takrorlanmaydigan qiymatlar to'plami, ya'ni u avtomatik ravishda dublikatlarni olib tashlaydi.

function getUnique(arr) {
  return [...new Set(arr)];
}

console.log(getUnique([1, 2, 2, 3, 3, 3])); // [1, 2, 3]

Bu yerda men massivni Set'ga aylantiraman — Set dublikatlarni o'zi tashlab yuboradi — keyin spread operatori ... bilan uni yana massivga qaytaraman. Agar Set'siz qilishim kerak bo'lsa, filter bilan ham yozsam bo'ladi:

function getUniqueFilter(arr) {
  return arr.filter((item, index) => arr.indexOf(item) === index);
}

Bu ikkinchi variant har bir elementning birinchi uchragan indeksini tekshiradi: agar element joriy indeksda birinchi marta uchrayotgan bo'lsa, uni saqlaydi, aks holda tashlaydi. Set varianti tezroq va o'qilishi osonroq, shuning uchun men amalda birinchisini tanlayman.

Izoh: Yana bir bor nomzod ikki yechim taklif qildi va ularni solishtirdi. Set yechimi zamonaviy JS bilimini, filter yechimi esa massiv metodlarini chuqur bilishni ko'rsatadi. "Set tezroq" degan xulosasi to'g'ri va u samaradorlik haqida o'ylashini bildiradi. Junior uchun bu a'lo natija.

4-bosqich: Behavioral (xulq-atvor) savollari

Intervyuchi: Endi texnikadan tashqari savollar. Ayting-chi, biror marta kodingizda qiyin xato (bug) bilan uchrashganmisiz? Uni qanday hal qildingiz?

Kuchli javob: Ha, o'zimning vazifalar ilovamda shunday holat bo'lgan. Foydalanuvchi vazifani o'chirganda, ba'zan noto'g'ri vazifa o'chib ketardi. Boshida sababi nimada ekanini tushunmadim. Avval console.log bilan qaysi funksiyaga qanday ma'lumot kelayotganini tekshirdim. Ma'lum bo'ldiki, men vazifalarni o'chirishda massiv indeksini kalit sifatida ishlatgan ekanman, lekin filtrlashda indekslar o'zgarib ketardi. Ya'ni ekranda ko'ringan indeks bilan asl massivdagi indeks mos kelmasdi. Buni tushunganimdan keyin, har bir vazifaga noyob id bergandim va o'chirishni indeks o'rniga id bo'yicha qildim. Shundan keyin muammo yo'qoldi. Bu menga har doim ma'lumotni noyob identifikator orqali boshqarish kerakligini o'rgatdi.

Izoh: Bu javob STAR usuliga (Situation, Task, Action, Result) yaqin tuzilgan. Nomzod aniq muammoni (noto'g'ri vazifa o'chishi), o'z harakatlarini (console.log bilan tekshirish, sababni topish) va yechimni (id bo'yicha o'chirish) ketma-ket bayon qildi. Eng muhimi — oxirida undan qanday saboq olganini aytdi. Intervyuchi bu yerda nomzodning muammoni mustaqil hal qila olishini va o'z xatosidan o'rganishini ko'radi.

Zaif javob: "Ha, bug'lar ko'p bo'lgan, lekin men odatda ularni tuzataman. Aniq bir misolni eslay olmayman."

Bu javob imkoniyatni boy beradi. "Eslay olmayman" deyish — nomzod o'z ishini tahlil qilmasligini yoki tayyorgarlik ko'rmaganini bildiradi. Hatto kichik xato bo'lsa ham, konkret misol keltirish har doim yaxshiroq.

Intervyuchi: Faraz qiling, jamoada ishlayapsiz va sizga tushunarsiz vazifa berildi. Nima qilasiz?

Kuchli javob: Birinchi navbatda vazifani o'zim yaxshilab o'qib chiqaman va tushunmagan qismlarni aniq belgilab olaman. Chunki umuman "tushunmadim" deyish o'rniga, "aynan mana bu qism noaniq" deyish yaxshiroq. Keyin, agar bu texnik masala bo'lsa, biroz o'zim izlanaman — hujjatlarni yoki loyihaning o'xshash qismlarini ko'rib chiqaman. Agar 20-30 daqiqadan keyin ham tushunmasam, vaqtni behuda sarflamayman va vazifani bergan odamdan yoki jamoadan aniq savol bilan yordam so'rayman. Savolimni tayyorlab, "men buni shunday tushundim, to'g'rimi?" deb so'rayman — bu ularning vaqtini tejaydi. Menimcha, savol berishdan uyalmaslik kerak, lekin savoldan oldin o'zicha harakat qilib ko'rish ham muhim.

Izoh: Bu javob junior uchun ideal muvozanatni ko'rsatadi: mustaqillik va yordam so'rash o'rtasidagi to'g'ri chegara. "20-30 daqiqa o'zim urinib, keyin aniq savol bilan so'rayman" — bu aynan jamoalar qadrlaydigan xatti-harakat. "Men buni shunday tushundim, to'g'rimi?" degan yondashuv nomzodning muloqot madaniyatini ko'rsatadi. U na o'zboshimcha, na o'ta bog'liq.

Intervyuchi: So'nggi paytda nima yangi narsa o'rgandingiz? Yangi bilimni qanday o'zlashtirasiz?

Kuchli javob: So'nggi paytda men Git va jamoada versiya nazorati bilan ishlashni chuqurroq o'rgandim. Boshida faqat add, commit, push bilan cheklangandim, lekin endi branch'lar bilan ishlash, merge va konfliktlarni hal qilishni o'rganyapman. Yangi narsani o'rganganimda men odatda uch bosqichdan o'taman: birinchi, rasmiy hujjatni yoki sifatli kursni o'qiyman; ikkinchi, darrov kichik amaliy loyihada sinab ko'raman, chunki men faqat o'qib emas, qilib o'rganaman; uchinchi, o'rganganimni o'z so'zlarim bilan qayta tushuntirishga harakat qilaman — ba'zan qog'ozga yozaman yoki do'stimga aytaman. Agar boshqa birovga tushuntira olsam, demak o'zim ham tushunganman. Bu usul menga eng samarali ekanini ko'rsatdi.

Izoh: Intervyuchi bu savolda nomzodning o'rganish qobiliyatini va o'z-o'zini rivojlantirish odatini baholaydi. Junior uchun eng muhim sifat — tez va mustaqil o'rgana olish. Nomzod aniq metodini ("o'qi qil tushuntir") tavsifladi, bu uning ongli o'quvchi ekanini ko'rsatadi. "Boshqaga tushuntira olsam, o'zim ham tushunganman" — bu kuchli va yetuk fikr.

5-bosqich: Nomzodning savollari

Intervyuchi: Mening savollarim shu bilan yakunlandi. Endi sizda menga savollar bormi?

Kuchli javob: Ha, bir necha savolim bor, rahmat. Birinchidan, jamoada junior dasturchi qanday qo'llab-quvvatlanadi? Masalan, mentorlik yoki kod ko'riki (code review) tizimingiz qanday ishlaydi? Ikkinchidan, yangi qo'shilgan dasturchining birinchi bir-ikki oyi odatda qanday o'tadi — qanday vazifalardan boshlanadi? Uchinchidan, jamoa qaysi texnologiyalar bilan ishlaydi va yaqin kelajakda o'rganishim foydali bo'ladigan yo'nalish bormi? Men doim o'sish istagida bo'lganim uchun, jamoada o'rganish madaniyati qanday ekani men uchun juda muhim.

Izoh: Nomzodning savollari — intervyuning eng kam baholanadigan, lekin juda muhim qismi. "Savolim yo'q" deyish — qiziqishsizlik belgisi. Bu nomzod uchta o'ylangan savol berdi va ular aynan junior uchun to'g'ri savollar: mentorlik, birinchi oylar, o'rganish yo'nalishi. Bu savollar nomzodning uzoq muddatli o'sishga qiziqishini va jamoaga jiddiy qarashini ko'rsatadi.

Junior mock: Baholash

Umumiy taassurot: Bu nomzod Junior lavozimi uchun kuchli. Uni ajratib turadigan jihatlar:

Yakuniy qaror: Ishga taklif qilinsin (Hire).

Nomzodga umumiy maslahat: Sizning eng kuchli tomoningiz — bilimlarni yodlab emas, tushunib olganingiz. Har bir savolda "nima" bilan birga "nima uchun"ni ham tushuntirdingiz. Bu junior uchun kamdan-kam uchraydigan sifat. Rivojlantirish uchun: CSS grid'ni ko'proq amalda sinab ko'ring va TypeScript asoslarini o'rganib qo'ying — ko'p zamonaviy jamoalar undan foydalanadi. Ovoz chiqarib o'ylash odatingizni saqlab qoling, bu sizni intervyularda ajratib turadi.

2-MOCK: MIDDLE FULL-STACK DASTURCHI INTERVYUSI

Kontekst: Nomzod — 2.5-3 yillik tajribaga ega, React frontend va Node.js backend bilan ishlagan, bir necha production loyihada qatnashgan Middle full-stack dasturchi. Vakansiya — o'sib borayotgan mahsulot kompaniyasida. Intervyu davomiyligi ~70 daqiqa. Intervyuchi — Senior dasturchi.

1-bosqich: Tanishuv

Intervyuchi: Assalomu alaykum, keling boshlaymiz. Karyerangiz va so'nggi loyihangiz haqida gapirib bering — texnik jihatdan siz nimalarga mas'ul edingiz?

Kuchli javob: Assalomu alaykum. Men taxminan uch yildan beri full-stack dasturchi bo'lib ishlayman. So'nggi ish joyimda logistika kompaniyasi uchun buyurtmalarni kuzatish tizimini ishlab chiqishda qatnashdim. Frontend React va TypeScript'da edi, backend esa Node.js va Express'da, ma'lumotlar bazasi PostgreSQL. Men asosan buyurtmalar moduliga mas'ul edim — bu ham API endpointlarini, ham frontend sahifalarini o'z ichiga olardi. Eng qiziq vazifam — real vaqtda buyurtma holatini yangilash edi: buni WebSocket orqali amalga oshirdim, shunda foydalanuvchi sahifani yangilamasdan buyurtma holati o'zgarganini ko'rardi. Shuningdek, men kod ko'rikida faol qatnashardim va ikki nafar junior dasturchiga mentorlik qildim. Jamoamiz Agile usulida, ikki haftalik sprintlarda ishladi.

Izoh: Middle uchun bu tanishuv ideal. Nomzod texnologiya stekini aniq aytdi, o'z mas'uliyat doirasini belgiladi ("buyurtmalar moduli") va bitta qiyin texnik vazifani (WebSocket real-time) ta'kidladi. Mentorlik va code review'ni tilga olishi uning junior'dan yuqori ekanini ko'rsatadi — u endi faqat kod yozmaydi, balki jamoaga hissa qo'shadi. Agile jarayonini bilishi ham qo'shimcha.

2-bosqich: Chuqurroq texnik savollar

Intervyuchi: JavaScript'dan boshlaymiz. closure (yopilma) nima va uni real hayotda qayerda ishlatgansiz?

Kuchli javob: Closure — bu funksiya o'zi yaratilgan qamrovdagi (scope) o'zgaruvchilarni "eslab qolishi" hodisasi. Ya'ni funksiya boshqa joyda chaqirilsa ham, o'zi tug'ilgan muhitdagi o'zgaruvchilarga kirish huquqini saqlab qoladi. Buning sababi — JavaScript'da funksiya faqat kod emas, balki o'z leksik muhiti bilan birga "o'ralgan" obyektdir. Amalda men closure'ni bir necha marta ishlatganman. Eng aniq misol — "debounce" funksiyasini yozganimda. Qidiruv maydonida foydalanuvchi har harf yozganda serverga so'rov yubormaslik uchun debounce kerak edi. Debounce funksiyasi ichida taymer identifikatorini saqlaydigan o'zgaruvchi bor, va qaytarilgan ichki funksiya closure orqali o'sha o'zgaruvchini eslab qoladi. Yana closure modul namunasida (module pattern) yopiq holat yaratish uchun ham ishlatiladi — masalan, faqat maxsus funksiyalar orqali o'zgartirilishi mumkin bo'lgan hisoblagich.

function createDebounce(fn, delay) {
  let timerId;
  return function (...args) {
    clearTimeout(timerId);
    timerId = setTimeout(() => fn(...args), delay);
  };
}

Bu yerda timerId closure ichida saqlanadi va har chaqiruv orasida eslab qolinadi.

Izoh: Bu javob middle darajasini aniq ko'rsatadi. Nomzod closure'ning ta'rifini berdi, mexanizmini ("leksik muhit bilan o'ralgan") tushuntirdi va — eng muhimi — real, amaliy misol (debounce) keltirib, kodini yozdi. Bu shunchaki nazariya emas, balki "men buni ishlatganman" darajasidagi bilim. Debounce misoli intervyularda juda qadrlanadi.

Intervyuchi: React'ga o'taylik. Komponent keraksiz qayta render bo'lyapti. Buni qanday aniqlaysiz va qanday optimallashtirasiz?

Kuchli javob: Avval muammoni o'lchayman — taxmin qilmayman. React DevTools'ning Profiler'idan foydalanaman: u qaysi komponent qancha vaqtda va necha marta render bo'layotganini ko'rsatadi. "Highlight updates" opsiyasini yoqib, ekranda qaysi qismlar keraksiz yonayotganini ko'zim bilan ko'raman. Sabablarni aniqlagach, bir necha optimallashtirish usulini qo'llayman. Birinchidan, agar komponent bir xil props bilan qayta render bo'layotgan bo'lsa, React.memo bilan uni o'rayman — u props o'zgarmaganda render'ni to'xtatadi. Ikkinchidan, agar prop sifatida funksiya yoki obyekt uzatilayotgan bo'lsa, ular har render'da yangidan yaratiladi va memo'ni buzadi — bularni useCallback va useMemo bilan memoizatsiya qilaman. Uchinchidan, ba'zan muammo state'ni juda yuqorida saqlashda bo'ladi — state o'zgarganda butun daraxt render bo'ladi. Bu holda state'ni pastroqqa, faqat kerakli komponentga tushiraman (state colocation). Lekin men optimallashtirishni ehtiyotkorlik bilan qilaman: memo va useMemo'ni har joyga qo'yish o'zi ham qimmatga tushadi, shuning uchun faqat Profiler haqiqiy muammoni ko'rsatgandan keyingina qo'llayman.

Izoh: Bu a'lo javob. Uning kuchi ikki narsada: birinchi, nomzod "avval o'lchayman, taxmin qilmayman" deb ilmiy yondashuvni ko'rsatdi (Profiler); ikkinchi, u faqat React.memo demasdan, uni buzuvchi omilni (har render'da yangi funksiya/obyekt) va uning yechimini (useCallback/useMemo) tushuntirdi. Oxirgi jumla — "optimallashtirishni ehtiyotkorlik bilan qilaman" — nomzodning yetukligini ko'rsatadi: u premature optimization xavfini biladi.

Intervyuchi: Node.js tomonga o'taylik. Event loop nima va u nima uchun Node'ning masshtablanishida muhim?

Kuchli javob: Node.js — JavaScript kabi bir oqimli, lekin u minglab bir vaqtdagi ulanishni qanday uddalaydi? Javob — event loop. Event loop — bu doimiy aylanadigan mexanizm bo'lib, u asinxron amallarni boshqaradi. Node biror uzoq amalni — masalan, fayl o'qish yoki ma'lumotlar bazasiga so'rov — boshlaganda, uni to'sib qo'ymaydi, balki operatsion tizimga yoki libuv kutubxonasidagi thread pool'ga topshiradi va o'zi boshqa ishlarni davom ettiradi. Amal tugagach, uning callback'i navbatga qo'yiladi va event loop uni kelgusi aylanishda bajaradi. Aynan shuning uchun Node I/O ko'p bo'lgan vazifalarda (masalan, API server) juda samarali — u kutish o'rniga doim boshqa so'rovlar bilan band bo'ladi. Lekin bu bir muhim ogohlantirishni keltirib chiqaradi: agar biz event loop'da og'ir sinxron hisob-kitob (masalan, katta massivni saralash yoki murakkab matematika) bajarsak, u butun loop'ni bloklaydi va barcha boshqa so'rovlar kutib qoladi. Shuning uchun og'ir CPU vazifalarni worker thread'larga yoki alohida servisga chiqarish kerak.

Izoh: Middle uchun bu chuqur va aniq javob. Nomzod nafaqat event loop mexanizmini (libuv, thread pool, callback navbati) tushuntirdi, balki uning kuchli tomonini (I/O uchun samarali) va zaif tomonini (CPU-og'ir vazifalar loop'ni bloklaydi) ham aytdi. "Worker thread'larga chiqarish" degan yechim uning production tajribasidan darak beradi. Bu — kitobdan yodlangan emas, tushunilgan bilim.

Intervyuchi: Ma'lumotlar bazasi savoli. INDEX nima va nima uchun kerak? U bilan bog'liq qanday tanlovlar (trade-off) bor?

Kuchli javob: Index — bu ma'lumotlar bazasidagi maxsus tuzilma bo'lib, u ma'lum ustunlar bo'yicha qidiruvni tezlashtiradi. Uni kitobning alifboli ko'rsatkichiga o'xshatsa bo'ladi: index bo'lmasa, baza kerakli qatorni topish uchun butun jadvalni to'liq ko'zdan kechirishga majbur (full table scan), bu esa katta jadvalda juda sekin. Index bilan esa baza to'g'ridan-to'g'ri kerakli joyga o'tadi. Odatda index B-tree tuzilmasida saqlanadi, bu qidiruvni logaritmik tezlikda qiladi. Lekin index tekin emas — bu yerda trade-off bor. Birinchidan, index qo'shimcha disk joyini egallaydi. Ikkinchidan va muhimrog'i, har safar jadvalga yangi qator qo'shilganda, o'chirilganda yoki yangilanganda, baza index'ni ham yangilashi kerak — ya'ni index yozish amallarini (INSERT, UPDATE, DELETE) sekinlashtiradi. Shuning uchun index'ni ko'p o'qiladigan, lekin kam yoziladigan ustunlarga qo'yish mantiqiy. Men odatda WHERE, JOIN va ORDER BY'da tez-tez ishlatiladigan ustunlarga index qo'yaman, lekin har bir ustunga emas — faqat so'rovlar tahlili (masalan, EXPLAIN) buni oqlaganda.

Izoh: Savol aynan "trade-off" so'zini o'z ichiga olgan va nomzod aynan shuni ochib berdi. U index'ning foydasini (o'qish tezligi) va narxini (disk joyi, yozish sekinlashishi) muvozanatladi. EXPLAIN bilan so'rovni tahlil qilishni tilga olishi uning amaliy tajribasini ko'rsatadi. Middle dasturchidan aynan shu — foyda va narxni tarozida ko'ra olish kutiladi.

Intervyuchi: REST API loyihalashda PUT va PATCH o'rtasidagi farq nima? Va idempotentlik (idempotency) nima degani?

Kuchli javob: PUT va PATCH ikkalasi ham resursni yangilash uchun ishlatiladi, lekin farqi — qancha qismini yangilashda. PUT — bu resursni to'liq almashtirish: siz butun obyektni yuborasiz va u eskisining o'rnini bosadi. PATCH esa qisman yangilash: faqat o'zgartirmoqchi bo'lgan maydonlarni yuborasiz. Masalan, foydalanuvchining faqat emailini o'zgartirmoqchi bo'lsam, PATCH bilan faqat { email: "..." } yuboraman, PUT bilan esa butun foydalanuvchi obyektini. Idempotentlik esa bunga bog'liq muhim tushuncha: agar amalni bir marta yoki o'n marta bajarsangiz ham natija bir xil bo'lsa, u idempotent hisoblanadi. GET, PUT va DELETE idempotent: PUT bilan bir xil ma'lumotni necha marta yuborsangiz ham, resurs oxir-oqibat bir xil holatda bo'ladi. POST esa idempotent emas — uni ikki marta chaqirsangiz, ikkita resurs yaratilishi mumkin. PATCH odatda idempotent emas, garchi uni idempotent qilib loyihalash mumkin. Bu tushuncha amalda muhim, chunki, masalan, tarmoq uzilib qayta urinishlar (retry) bo'lganda idempotent amallar xavfsiz.

Izoh: Bu javob nomzodning API loyihalashni sirtdan emas, tamoyillar darajasida bilishini ko'rsatadi. PUT/PATCH farqini misol bilan aniqladi va idempotentlik tushunchasini to'g'ri ta'rifladi — har bir metod uchun idempotent yoki yo'qligini aytdi. Eng qimmatli qism — oxirgi jumla: idempotentlik nima uchun amalda muhim (retry xavfsizligi). Bu real tizim loyihalash tajribasidan kelib chiqadi.

3-bosqich: Live-coding

Intervyuchi: Endi amaliy masala. Sizga foydalanuvchilar ro'yxati beriladi, har birida name va age bor. Men ikkita narsa xohlayman: birinchidan, faqat 18 yoshdan katta foydalanuvchilarni tanlang; ikkinchidan, ularni yosh bo'yicha kamayish tartibida saralang. Yakuniy natija faqat ismlar massivi bo'lsin.

Kuchli javob: Yaxshi. Bu masalada uch amal bor: filtrlash, saralash va o'zgartirish (map). JavaScript'ning massiv metodlari bilan buni zanjir shaklida yozsam bo'ladi. Avval ovoz chiqarib o'ylay: filter bilan 18 dan kattalarni ajrataman, sort bilan yoshi bo'yicha kamayuvchi tartibda saralayman, keyin map bilan faqat ismlarni olaman.

function getAdultNames(users) {
  return users
    .filter((user) => user.age > 18)
    .sort((a, b) => b.age - a.age)
    .map((user) => user.name);
}

const users = [
  { name: "Aziz", age: 25 },
  { name: "Malika", age: 17 },
  { name: "Bobur", age: 30 },
  { name: "Nodira", age: 19 },
];

console.log(getAdultNames(users));
// ["Bobur", "Aziz", "Nodira"]

Bir nozik nuqtani ta'kidlayman: sort metodi asl massivni o'zgartiradi (mutates), shuning uchun ba'zan uni ishlatishdan oldin nusxa olish kerak, masalan [...users] bilan. Bu yerda men filter'dan keyin chaqirayapman, va filter yangi massiv qaytargani uchun asl users o'zgarmaydi — shuning uchun bu holatda xavfsiz. Agar filter bo'lmaganida, men avval nusxa olardim.

Izoh: Bu javob middle darajasini yaqqol ko'rsatadi. Nomzod masalani uch qismga bo'ldi, metod zanjirini toza yozdi va natijani tekshirib ko'rsatdi. Lekin eng muhim nuqta — sort'ning asl massivni o'zgartirishi (mutation) haqidagi ogohlantirishi. Bu ko'p dasturchi bilmaydigan tuzoq, va nomzodning uni tilga olishi uning nozik detallarga e'tiborli va tajribali ekanini isbotlaydi.

Intervyuchi: Endi backend tomonga o'taylik. Sizdan Express'da oddiy endpoint yozishingizni so'rayman: u POST /users orqali yangi foydalanuvchi qo'shadi. name va email majburiy bo'lsin, bo'sh bo'lsa xato qaytarsin. Xatolarni ham to'g'ri boshqaring.

Kuchli javob: Yaxshi. Bu yerda muhim narsa — validatsiya va to'g'ri HTTP status kodlari. Avval kiruvchi ma'lumotni tekshiraman, keyin foydalanuvchini yarataman, va har bosqichda mos status qaytaraman.

app.post("/users", async (req, res) => {
  try {
    const { name, email } = req.body;

    // Validatsiya
    if (!name || !email) {
      return res.status(400).json({
        error: "name va email maydonlari majburiy",
      });
    }

    // Oddiy email formati tekshiruvi
    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    if (!emailRegex.test(email)) {
      return res.status(400).json({ error: "email formati noto'g'ri" });
    }

    // Ma'lumotlar bazasiga saqlash
    const newUser = await db.createUser({ name, email });

    return res.status(201).json(newUser);
  } catch (err) {
    console.error("Foydalanuvchi yaratishda xato:", err);
    return res.status(500).json({ error: "Ichki server xatosi" });
  }
});

Bir necha nuqtani izohlab o'tay. Birinchidan, validatsiya muvaffaqiyatsiz bo'lsa 400 Bad Request qaytaraman, chunki bu mijoz xatosi. Ikkinchidan, foydalanuvchi muvaffaqiyatli yaratilsa 201 Created qaytaraman — bu 200'dan aniqroq, chunki yangi resurs yaratildi. Uchinchidan, kutilmagan xatolarni try/catch bilan ushlab, 500 qaytaraman va xatoni loglayman, lekin mijozga ichki tafsilotlarni ko'rsatmayman — bu xavfsizlik uchun muhim. Real loyihada validatsiyani Joi yoki Zod kabi kutubxona bilan qilardim, lekin bu yerda mantiqni ko'rsatish uchun qo'lda yozdim.

Izoh: Bu javob nomzodning production-darajasidagi tafakkurini ko'rsatadi. U faqat "ishlaydigan" kod emas, balki to'g'ri status kodlari (400 vs 201 vs 500), xato boshqaruvi (try/catch), xavfsizlik (ichki xato tafsilotini yashirish) va logging haqida o'yladi. Zod/Joini tilga olishi real loyiha tajribasini bildiradi. Middle'dan aynan shu — ishlaydigan emas, ishonchli kod kutiladi.

4-bosqich: Oddiy system design

Intervyuchi: Endi loyihalash mashqi. Faraz qiling, biz URL qisqartiruvchi xizmat (URL shortener, masalan bit.ly kabi) qurishimiz kerak. Uni yuqori darajada qanday loyihalaysiz? Shoshilmang, ovoz chiqarib o'ylang.

Kuchli javob: Yaxshi, avval talablarni aniqlab olay. Asosiy funksiya: foydalanuvchi uzun URL beradi, biz qisqa URL qaytaramiz; keyin kimdir qisqa URL'ga kirsa, uni asl URL'ga yo'naltiramiz (redirect). Aniqlashtiruvchi savollar: qisqa URL'lar qancha yashaydi, muddati bor-yo'qmi? Kuniga qancha so'rov kutamiz? Statistika kerakmi (necha marta bosilgan)? Faraz qilaylik, o'qish yozishdan ancha ko'p — ya'ni odamlar qisqa link yaratgandan ko'ra, unga ko'proq bosishadi.

Yuqori darajadagi tuzilma quyidagicha. Ikki asosiy endpoint: POST /shorten — uzun URL'ni qabul qiladi va qisqa kod qaytaradi; GET /:code — qisqa kod bo'yicha asl URL'ni topib, 301 yoki 302 redirect qiladi.

Eng muhim savol — qisqa kodni qanday yaratish. Ikki yondashuv bor. Birinchisi: har bir yangi URL uchun avtomatik o'suvchi id (masalan, 1, 2, 3...) beramiz va uni base62 (harflar va raqamlar) ga o'giramiz — bu qisqa va noyob bo'ladi. Ikkinchisi: tasodifiy 6-7 belgili kod yaratamiz va bazada mavjudligini tekshiramiz. Men birinchisini afzal ko'raman, chunki u noyoblikni kafolatlaydi va to'qnashuv (collision) tekshiruvi kerak emas.

Ma'lumotlar bazasi uchun oddiy jadval yetarli: code, original_url, created_at. code ustuniga index qo'yaman, chunki har redirect'da u bo'yicha qidiramiz.

O'qish juda ko'p bo'lgani uchun, keshlashni qo'shardim: mashhur qisqa kodlarni Redis'da saqlab, bazaga har safar bormaslik uchun. Bu redirect'ni sezilarli tezlashtiradi.

Nihoyat, agar trafik juda katta bo'lsa, xizmatni bir necha nusxada (horizontal scaling) yugurtirib, oldiga load balancer qo'yardim. Ma'lumotlar bazasi bir joyda bo'lgani uchun avval o'qish uchun replica'lar qo'shardim.

Izoh: Middle'dan kutiladigan darajadagi system design javobi. Nomzod to'g'ri boshladi — avval talablarni aniqlashtirdi va aniqlashtiruvchi savollar berdi (bu system design'da eng muhim odat). Keyin muammoni bosqichma-bosqich yechdi: endpointlar kod yaratish strategiyasi (ikki variantni solishtirib) ma'lumotlar bazasi keshlash masshtablash. "O'qish yozishdan ko'p" degan farazni ilgari surib, unga mos yechim (Redis kesh, read replica) berishi uning tizimli tafakkurini ko'rsatadi. Middle uchun bundan ortiq kerak emas.

5-bosqich: Behavioral savollar

Intervyuchi: Jamoada texnik masalada kelishmovchilik bo'lgan paytni eslay olasizmi? Uni qanday hal qildingiz?

Kuchli javob: Ha. Bir loyihada state boshqaruvi masalasida hamkasbim bilan kelishmovchilik bo'lgan. U butun loyihada Redux ishlatishni taklif qilardi, men esa loyiha hajmi kichik bo'lgani uchun bu ortiqcha murakkablik deb hisoblardim va Context API yetarli deb o'ylardim. Boshida biroz tortishdik. Keyin men muammoga boshqacha yondashishni taklif qildim: har birimiz o'z fikrimizni his-tuyg'usiz, faqat texnik dalillar bilan yozib chiqdik — Redux'ning afzalliklari va narxi, Context'niki ham. Birga o'tirib, loyihaning haqiqiy talablarini ko'rib chiqdik. Ma'lum bo'ldiki, hozircha holat unchalik murakkab emas, lekin kelajakda o'sishi mumkin. Shuning uchun murosaga keldik: hozircha Context bilan boshlaymiz, lekin kodni shunday tuzamizki, keyinchalik kerak bo'lsa Redux'ga o'tish oson bo'lsin. Bu yechim ikkalamizni ham qoniqtirdi va eng muhimi — qaror shaxsiy emas, loyiha manfaati asosida bo'ldi. Men bu holatdan shuni o'rgandimki, texnik bahsda "kim haq" emas, "nima to'g'ri" muhim.

Izoh: Bu javob nomzodning yetuk muloqot va hamkorlik ko'nikmasini ko'rsatadi. U kelishmovchilikni shaxsiy nizoga aylantirmadi, balki uni texnik dalillar asosida hal qildi. "His-tuyg'usiz, dalillar bilan yozib chiqdik" degan yondashuv — professional. Murosa yechimi (Context'dan boshlab, o'tishni oson qilish) uning pragmatik ekanini ko'rsatadi. Oxirgi jumla — "kim haq emas, nima to'g'ri" — kuchli xulosa. Bu javob nomzodni jamoa a'zosi sifatida ijobiy ko'rsatadi.

Intervyuchi: Muddati o'tayotgan, lekin ish tugamagan vaziyatga tushganmisiz? Nima qildingiz?

Kuchli javob: Ha, bir sprintda shunday bo'lgan. Vazifa dastlab ko'ringandan murakkabroq chiqdi — tashqi to'lov tizimini integratsiya qilish edi va ularning hujjatlari to'liq emasdi, ba'zi holatlar kutilmagancha ishlardi. Muddat yaqinlashib qolganida, men buni oxirigacha yashirmadim. Aksincha, darrov jamoa yetakchisiga borib, holatni aniq tushuntirdim: qancha qism tayyor, qaysi qism qoldi va nima uchun kechikish yuz berayapti. Keyin variantlarni taklif qildim: yo muddatni bir necha kunga suramiz, yoki funksiyani ikki qismga bo'lib, asosiy to'lov oqimini shu sprintda, qo'shimcha holatlarni keyingisida chiqaramiz. Yetakchi ikkinchi variantni tanladi. Men shuni o'rgandimki, muammoni erta va ochiq aytish har doim uni oxirigacha yashirib, keyin muddatni o'tkazib yuborishdan yaxshiroq. Menejerlar yomon xabarni erta bilishni afzal ko'radi, chunki unga munosabat bildira oladi.

Izoh: Bu javob nomzodning ochiqlik va mas'uliyat sifatlarini ko'rsatadi. Eng muhim nuqta — muammoni yashirmaslik va erta xabar berish. "Muddatni suramiz yoki funksiyani bo'lamiz" degan konkret variantlar taklif qilishi — u faqat muammoni aytib qolmasdan, yechim ham keltirishini ko'rsatadi. "Menejerlar yomon xabarni erta bilishni afzal ko'radi" degan tushuncha uning yetuk ish madaniyatini bildiradi.

6-bosqich: Nomzodning savollari

Intervyuchi: Endi sizning savollaringiz?

Kuchli javob: Rahmat, bir necha savolim bor. Birinchidan, jamoaning texnik qarorlari qanday qabul qilinadi — masalan, yangi texnologiya kiritish yoki arxitektura o'zgartirish bo'yicha jarayon qanday? Ikkinchidan, texnik qarz (technical debt) bilan qanday munosabatdasiz — uni hal qilishga alohida vaqt ajratiladimi? Uchinchidan, deploy va CI/CD jarayoningiz qanday tuzilgan, kod production'ga qanchalik tez-tez chiqadi? To'rtinchidan, bu lavozimda birinchi olti oyda mendan qanday natijalar kutiladi — muvaffaqiyat qanday o'lchanadi? Menga jamoaning texnik yetukligini va o'sish imkoniyatlarini tushunish muhim.

Izoh: Middle nomzodning savollari junior'nikidan chuqurroq bo'lishi kerak va bu javob aynan shunday. Savollar jarayonlar (texnik qaror qabul qilish), sifat madaniyati (texnik qarz), amaliyot (CI/CD) va o'ziga qo'yiladigan kutilmalar (birinchi olti oy) haqida. Bu savollar nomzodning jamoaning yetukligini baholayotganini va o'zining hissasini jiddiy o'ylayotganini ko'rsatadi. Bu — nafaqat "ishga olinishni", balki "to'g'ri joyni tanlashni" istaydigan tajribali nomzod belgisi.

Middle mock: Baholash

Umumiy taassurot: Bu nomzod Middle lavozimi uchun mustahkam. Baholash quyidagicha:

Yakuniy qaror: Ishga taklif qilinsin (Hire), Middle darajasida.

Nomzodga umumiy maslahat: Sizning eng kuchli tomoningiz — har bir texnik javobni real tajriba bilan bog'lashingiz. Siz "biladigan" emas, "ishlatgan" dasturchi taassurotini qoldirasiz. Bu Middle uchun juda qimmatli. Senior'ga o'sish uchun: system design'da masshtablash chegaralari (masalan, ma'lumotlar bazasini sharding qilish, CAP teoremasi) va tizim ishonchliligi (monitoring, alerting) mavzularini chuqurlashtiring. Shuningdek, mentorlik tajribangizni kengaytiring — Senior'lardan ko'pincha jamoaning texnik o'sishiga javobgarlik kutiladi.

3-MOCK: SENIOR DASTURCHI / TEXNIK YETAKCHI INTERVYUSI

Kontekst: Nomzod — 6+ yillik tajribaga ega, bir necha yirik tizimni loyihalagan, jamoalarga yetakchilik qilgan Senior dasturchi. Vakansiya — tez o'sayotgan mahsulot kompaniyasida arxitekturaga mas'ul lavozim. Intervyu davomiyligi ~80 daqiqa. Intervyuchi — Engineering Manager va Principal Engineer birgalikda.

1-bosqich: Tanishuv

Intervyuchi: Assalomu alaykum. Karyerangizning eng muhim loyihasi haqida gapiring — texnik jihatdan eng qiyin muammo qanday edi va siz uni qanday hal qildingiz?

Kuchli javob: Assalomu alaykum. Karyeramdagi eng ta'sirli loyiha — bir e-commerce platformasini monolit arxitekturadan mikroservislarga bosqichma-bosqich ko'chirish edi. Muammo shundaki, tizim tez o'sib borardi, lekin monolit bir joyda o'zgartirilganda butun tizimni qayta deploy qilishga to'g'ri kelardi va bu jamoalarni bir-biriga bog'lab qo'yardi — bir jamoa ikkinchisini kutardi. Eng qiyin qismi — bu ko'chirishni tizimni to'xtatmasdan, ishlab turgan holda amalga oshirish edi. Biz "strangler fig" namunasidan foydalandik: yangi funksiyalarni alohida servislarda yozdik va eski monolitni asta-sekin, modul-modul chiqarib tashladik. Eng katta qiyinchilik — ma'lumotlar bazasini bo'lish edi, chunki monolitda hamma narsa bitta bazada, ko'p JOIN'lar bilan bog'langandi. Biz avval mantiqiy chegaralarni (bounded context) aniqladik, keyin ma'lumotlarni bosqichma-bosqich ajratdik va servislar orasidagi bog'lanishni sinxron API o'rniga ko'p joyda hodisalarga asoslangan (event-driven) qildik. Bu ikki yilga cho'zilgan ish edi, lekin natijada har bir jamoa mustaqil deploy qila oladigan va tizim ancha barqaror bo'ldi. Men bu loyihada texnik yechimlardan tashqari, uch jamoaning ishini muvofiqlashtirishga ham mas'ul edim.

Izoh: Senior tanishuvi texnik chuqurlik va ta'sir ko'lamini bir vaqtda ko'rsatishi kerak — bu javob aynan shunday. Nomzod aniq va murakkab muammoni (monolitdan mikroservisga migratsiya) tanladi, sanoat namunasini (strangler fig, bounded context, event-driven) to'g'ri ishlatdi va eng nozik qiyinchilikni (ma'lumotlar bazasini bo'lish) ajratdi. Muhimi — u nafaqat texnik, balki tashkiliy ta'sirni (jamoalar mustaqilligi) va o'z yetakchilik rolini ("uch jamoani muvofiqlashtirish") ko'rsatdi. Bu — Senior/Lead darajasining belgisi.

2-bosqich: Arxitektura va chuqur texnik savollar

Intervyuchi: Mikroservislar haqida gapirdingiz. Monolit va mikroservis o'rtasida tanlashda qanday mezonlarga tayanasiz? Har doim mikroservis yaxshimi?

Kuchli javob: Yo'q, aksincha — men ko'pincha monolitdan boshlashni tavsiya qilaman, ayniqsa loyiha yangi bo'lsa. Mikroservislar bepul emas: ular tarqoq tizimning (distributed system) barcha murakkabliklarini keltiradi — tarmoq ishonchsizligi, ma'lumotlar izchilligi (consistency), monitoring, deploy murakkabligi. Agar jamoa kichik va domen hali aniq bo'lmasa, mikroservislar rivojlanishni sekinlashtiradi. Men tanlovda bir necha mezonga qarayman. Birinchi — jamoa tuzilishi: Conway qonuniga ko'ra, tizim arxitekturasi tashkilot tuzilishini aks ettiradi. Agar bir necha mustaqil jamoa bo'lsa va ular bir-birini deploy'da kutayotgan bo'lsa — bu mikroservisga o'tish signali. Ikkinchi — masshtablash ehtiyoji: agar tizimning ba'zi qismlari boshqasidan ancha ko'proq yuklama olsa (masalan, to'lov moduli qidiruvdan 10 barobar ko'p), ularni alohida masshtablash foydali. Uchinchi — domen chegaralari aniqlanganmi: mikroservisga bo'lishdan oldin bounded context'lar aniq bo'lishi kerak, aks holda noto'g'ri joydan bo'lib, "tarqoq monolit" degan eng yomon holatga tushamiz. Xulosa qilib: monolitdan boshlab, real og'riq paydo bo'lganda, aniq chegaralar bo'yicha bosqichma-bosqich ajratish — mening amaliy pozitsiyam.

Izoh: Bu javobning kuchi — "hype"ga ergashmaslik va muvozanatli fikr. Nomzod "mikroservis har doim yaxshi" degan common xatoni rad etdi va aniq mezonlar (Conway qonuni, masshtablash asimmetriyasi, domen chegaralari) keltirdi. "Tarqoq monolit" degan anti-pattern'ni bilishi uning chuqur tajribasini ko'rsatadi. "Monolitdan boshla" degan pragmatik pozitsiya — Senior'ning yetukligi belgisi. Bu javob nomzodning texnik moda ortidan emas, muhandislik mantig'i asosida qaror qabul qilishini isbotlaydi.

Intervyuchi: Tarqoq tizimlarda ma'lumotlar izchilligi (consistency) haqida gapirdingiz. CAP teoremasini qanday tushuntirasiz va u amaliy qarorlaringizga qanday ta'sir qiladi?

Kuchli javob: CAP teoremasi aytadiki, tarqoq tizimda uchta xususiyatning — Consistency (izchillik), Availability (mavjudlik) va Partition tolerance (tarmoq bo'linishiga chidamlilik) — faqat ikkitasini bir vaqtda to'liq kafolatlash mumkin. Amalda tarmoq bo'linishi (P) har doim mumkin bo'lgani uchun — tarmoq ishonchsiz — biz aslida P'ni tanlashga majburmiz, va haqiqiy tanlov C va A o'rtasida qoladi. Ya'ni tarmoq bo'lingan paytda: yo izchillikni saqlaymiz va ba'zi so'rovlarga javob bermaymiz (CP), yo mavjudlikni saqlaymiz, lekin eskirgan ma'lumot qaytishi mumkin (AP). Bu amaliy qarorlarda muhim. Masalan, bank tizimida hisob balansi uchun men izchillikni tanlayman (CP) — noto'g'ri balans ko'rsatishdansa, biroz kutish yaxshi. Aksincha, ijtimoiy tarmoqda "like" hisoblagichi uchun mavjudlikni tanlayman (AP) — foydalanuvchi bir soniya eski sonni ko'rsa ham katta muammo emas, lekin xizmat ishlab turishi muhim. Amalda ko'p zamonaviy tizimlar "eventual consistency" ni tanlaydi — ya'ni ma'lumot vaqt o'tishi bilan izchil bo'ladi, lekin darrov emas. Muhimi — bu tanlovni har bir funksiya uchun alohida qilish kerak, butun tizim uchun bitta emas.

Izoh: Bu javob CAP teoremasini nafaqat ta'riflaydi, balki uning eng ko'p yanglishiladigan nuqtasini to'g'ri tushuntiradi: amalda P majburiy, tanlov C va A o'rtasida. Eng qimmatli qism — ikki qarama-qarshi misol (bank balansi uchun CP, "like" uchun AP), bu nomzodning teoremani amaliyotga bog'lay olishini ko'rsatadi. "Eventual consistency" va "tanlovni har funksiya uchun alohida qilish" degan xulosa uning haqiqiy tarqoq tizim tajribasini isbotlaydi. Bu Senior darajasidagi javob.

Intervyuchi: Tizim ishonchliligiga o'taylik. Servisingiz boshqa tashqi servisga bog'liq va u tez-tez ishdan chiqadi. Tizimingizni undan qanday himoya qilasiz?

Kuchli javob: Bu klassik ishonchlilik masalasi va bir necha himoya qatlamini birga qo'llayman. Birinchidan, timeout: tashqi servisga so'rov cheksiz kutmasligi kerak, aniq timeout qo'yaman, aks holda bir sekin servis mening barcha thread'larimni band qilib, kaskad ishdan chiqishga (cascading failure) olib keladi. Ikkinchidan, retry with backoff: vaqtinchalik xatolarda qayta urinaman, lekin darrov emas — har urinishda kutish vaqtini oshiraman (exponential backoff) va tasodifiy jitter qo'shaman, aks holda hamma bir vaqtda qayta urinib, servisni yanada ko'mib tashlaydi. Uchinchidan va eng muhimi — circuit breaker (zanjir uzgich) namunasi: agar tashqi servis muttasil xato bergani aniqlansa, men unga so'rov yuborishni butunlay to'xtataman va bir muddat "ochiq" holatda turaman, keyin ehtiyotkorlik bilan qayta sinab ko'raman. Bu ishdan chiqqan servisga bosimni kamaytiradi va menga tez javob berish imkonini beradi. To'rtinchidan, graceful degradation: agar tashqi servis, masalan, tavsiyalar tizimi bo'lsa va u ishlamasa, men butun sahifani buzmayman — o'rniga zaxira (fallback) qiymat yoki keshdan eski ma'lumot ko'rsataman. Nihoyat, bularning hammasini monitoring va alerting bilan qo'llab-quvvatlayman, chunki muammoni foydalanuvchidan oldin men bilishim kerak.

Izoh: Bu javob ishonchlilik muhandisligining barcha asosiy namunalarini qamraydi: timeout, retry with backoff va jitter, circuit breaker, graceful degradation, monitoring. Har bir usul uchun nomzod nima uchun kerakligini (masalan, jitter — bir vaqtda urinishning oldini oladi) tushuntirdi. Bu — kitobdan yodlangan ro'yxat emas, balki real production dardining natijasi. "Muammoni foydalanuvchidan oldin bilishim kerak" degan yakun — operatsion yetuklik belgisi. Senior'dan aynan shu — nosozlikni normal deb qabul qilib, unga tayyor tizim qurish kutiladi.

3-bosqich: To'liq system design

Intervyuchi: Endi katta loyihalash mashqi. Bizga Twitter kabi qisqa xabarlar tarmog'ining "yangiliklar tasmasi" (news feed) tizimini loyihalash kerak. Millionlab foydalanuvchi, har biri obuna bo'lganlarining postlarini ko'radi. Boshdan-oyoq loyihalang. Vaqtimiz yetarli, shoshilmang.

Kuchli javob: Yaxshi, bu qiziq masala. Men uni bosqichma-bosqich olib boraman: avval talablarni aniqlayman, keyin ko'lamni baholayman, so'ng yuqori darajadagi arxitekturani chizaman, va eng qiyin qismga — feed'ni qanday yaratishga — chuqur kiraman.

Talablar. Funksional: foydalanuvchi post yozadi; foydalanuvchi boshqalarga obuna bo'ladi; foydalanuvchi o'z tasmasida obunalarining postlarini vaqt bo'yicha ko'radi. Nofunksional: tizim yuqori darajada mavjud bo'lishi kerak; feed'ni o'qish juda tez bo'lishi kerak (bu eng ko'p amal); post yozish biroz kechiksa ham bo'ladi. Aniqlashtiruvchi savol: feed qat'iy vaqt tartibida bo'lsinmi yoki algoritmik? Hozircha soddalik uchun vaqt bo'yicha deb olaylik.

Ko'lam. Faraz qilaylik, 200 million faol foydalanuvchi, kuniga o'rtacha bittasi feed'ini bir necha marta ochadi. Demak o'qish yozishdan yuz barobar ko'p — bu eng muhim xulosa, chunki u butun dizaynni belgilaydi: biz o'qishni tezlashtirishga ustuvorlik beramiz.

Yuqori darajadagi komponentlar. Foydalanuvchi servisi, Post servisi, Obuna (graph) servisi, Feed servisi. Postlar obyekt saqlashda yoki bazada, media (rasm/video) esa alohida obyekt xotira va CDN'da.

Eng muhim qaror — feed'ni qanday yaratamiz. Ikki asosiy yondashuv bor.

Birinchisi — "fan-out on read" (o'qishda yig'ish): foydalanuvchi feed'ini so'raganda, biz uning barcha obunalarini olamiz va ularning so'nggi postlarini real vaqtda birlashtiramiz. Bu yozishni arzon qiladi, lekin o'qishni qimmat — har feed ochilishida ko'p so'rov. Katta ko'lamda bu sekin.

Ikkinchisi — "fan-out on write" (yozishda tarqatish): foydalanuvchi post yozganda, biz uni darrov uning barcha obunachilari feed'iga (masalan, Redis'dagi oldindan hisoblangan ro'yxatga) yozib qo'yamiz. Shunda feed'ni o'qish juda tez — shunchaki tayyor ro'yxatni olamiz. Bu o'qishni tez qiladi, lekin yozishni qimmatlashtiradi.

Men gibrid yondashuvni tanlayman, chunki har birining o'z muammosi bor. Fan-out on write'ning katta muammosi — mashhur foydalanuvchilar (masalan, 50 million obunachisi bor). Ular post yozsa, 50 million feed'ga yozish kerak — bu "hot key" muammosi. Shuning uchun: oddiy foydalanuvchilar uchun fan-out on write ishlataman (feed oldindan hisoblanadi), lekin juda mashhur akkountlar uchun fan-out on read — ularning postlarini feed o'qilayotganda qo'shib beraman. Bu ikki yondashuvning eng yaxshi tomonlarini birlashtiradi.

Ma'lumotlar saqlash. Oldindan hisoblangan feed'lar uchun Redis (tez o'qish uchun). Postlar va obunalar uchun gorizontal masshtablanadigan baza. Obuna grafi uchun maxsus yechim yoki bo'lingan (sharded) baza.

Masshtablash va ishonchlilik. Servislar oldiga load balancer. Bazani o'qish uchun replica'lar va yozuv yukini bo'lish uchun sharding (masalan, user_id bo'yicha). Keshlash qatlamlarini qo'shaman. Feed yozishni asinxron qilib, xabar navbati (message queue, masalan Kafka) orqali qilaman — post yozilganda darrov navbatga qo'yamiz, feed'larga tarqatish fonda bo'ladi.

Xulosa: eng muhim ikki qaror — o'qishga ustuvorlik berish va mashhur akkountlar uchun gibrid fan-out strategiyasi.

Izoh: Bu Senior darajasidagi to'liq system design javobining namunasi. Nomzod to'g'ri tuzilma bilan bordi: talablar ko'lam baholash komponentlar eng qiyin qismga chuqur kirish. Eng muhim ko'rsatkich — u masalaning yuragini (feed generatsiya strategiyasi) topib, ikki yondashuvni (fan-out on read vs on write) trade-off bilan solishtirdi va "hot key" muammosini (mashhur akkountlar) ko'rib, gibrid yechim taklif qildi. Bu — aynan real tizimlar (Twitter, Instagram) qanday ishlashini bilishni ko'rsatadi. Message queue, sharding, replica va CDN'ni to'g'ri joyda tilga oldi. Bu javob nomzodning katta ko'lamli tizimni loyihalay olishini isbotlaydi.

Intervyuchi: Yaxshi. Bitta trade-off haqida chuqurroq so'rayman: siz gibrid yondashuvni tanladingiz. Uning kamchiligi nima va uni qanday boshqarasiz?

Kuchli javob: To'g'ri savol — har bir yechimning narxi bor. Gibrid yondashuvning asosiy kamchiligi — murakkablik. Endi bizda ikki xil kod yo'li bor: oddiy foydalanuvchilar uchun oldindan hisoblangan feed va mashhur akkountlar uchun real vaqtda qo'shish. Bu ikkalasini birlashtirish, test qilish va nosozlikni tuzatishni qiyinlashtiradi. Ikkinchi muammo — "mashhur foydalanuvchi" chegarasini qayerga qo'yish? Bu qattiq son emas, o'zgarib turadi — kimdir birdan mashhur bo'lib qolishi mumkin. Buni men dinamik chegara bilan boshqaraman: obunachilar soni ma'lum chegaradan oshsa, akkount avtomatik "fan-out on read" rejimiga o'tadi, va bu chegarani metrikalar asosida sozlab turaman. Uchinchi nozik muammo — izchillik: gibrid tizimda foydalanuvchi feed'ida postlar biroz turli vaqtda paydo bo'lishi mumkin. Buni men eventual consistency sifatida qabul qilaman — feed'da bir post bir necha soniya kechiksa, bu qabul qilinadigan murosaga. Umuman, men bu murakkablikni faqat ko'lam uni oqlagandagina kiritardim: kichik tizimda oddiy fan-out on read bilan boshlab, foydalanuvchi bazasi o'sgandan keyingina gibridga o'tardim. Murakkablikni oldindan emas, ehtiyoj paydo bo'lganda qo'shish kerak.

Izoh: Bu follow-up savol nomzodning fikrlash chuqurligini sinaydi va u a'lo javob berdi. Senior'ni ajratib turadigan sifat — o'z yechimining kamchiliklarini ochiq tan olishi. Nomzod uchta aniq muammoni (kod murakkabligi, chegara aniqlash, izchillik) ko'rdi va har biriga yechim taklif qildi (dinamik chegara, eventual consistency qabul qilish). Eng kuchli xulosa — "murakkablikni ehtiyoj paydo bo'lganda qo'shish". Bu nomzodning muhandislik hikmatini ko'rsatadi: u eng murakkab yechimni emas, vaziyatga mos yechimni tanlaydi.

4-bosqich: Liderlik va behavioral

Intervyuchi: Endi yetakchilik tomoniga o'taylik. Jamoangizdagi bir dasturchi kutilgan darajada ishlamayotgan bo'lsa, qanday harakat qilasiz?

Kuchli javob: Birinchi navbatda men sababni tushunishga harakat qilaman, xulosaga shoshilmayman. Chunki past natijaning sabablari xilma-xil bo'lishi mumkin: balki vazifa unga juda murakkab, balki kutilmalar aniq tushuntirilmagan, balki shaxsiy hayotida qiyinchilik bor, yoki balki motivatsiya yo'qolgan. Shuning uchun avval u bilan xoli, ochiq suhbat o'tkazaman — ayblovsiz, "qanday yordam bera olaman?" ohangida. Ko'pincha bu suhbatning o'zi ildiz sababni ochib beradi. Keyin men aniq va o'lchanadigan kutilmalar qo'yaman va ularni qo'llab-quvvatlash bilan birga beraman: masalan, agar bilim yetishmasa, mentorlik yoki juftlashib ishlash (pair programming) tashkil qilaman; agar vazifa katta bo'lsa, uni kichikroq bo'laklarga bo'laman, shunda u kichik g'alabalar orqali ishonch qozonadi. Muhimi — muntazam qayta aloqa berish, yiliga bir marta emas, tez-tez. Agar aniq qo'llab-quvvatlash va vaqtga qaramay o'zgarish bo'lmasa, unda halol va hurmatli bo'lish kerak — muammoni ochiq aytish va oqibatlarini tushuntirish. Lekin men doim odamga o'sish imkonini berishdan boshlayman, chunki ko'pchilik to'g'ri qo'llab-quvvatlash bilan o'sadi. Mening tajribamda, past natija ko'pincha odamning qobiliyatsizligi emas, balki noto'g'ri sharoit yoki noaniq kutilmalar oqibati bo'lgan.

Izoh: Bu javob nomzodning yetuk liderlik yondashuvini ko'rsatadi. Eng muhim jihat — u jazolashdan emas, sababni tushunishdan boshlaydi (empatiya + tergov). "Ayblovsiz suhbat", "kutilmalarni qo'llab-quvvatlash bilan berish", "muntazam qayta aloqa" — bularning hammasi zamonaviy menejment amaliyoti. Shu bilan birga, nomzod "cheksiz sabr" tuzog'iga tushmaydi: u oxir-oqibat halol qaror kerakligini ham aytadi. "Past natija ko'pincha sharoit oqibati" degan tushuncha uning tajribali yetakchi ekanini bildiradi.

Intervyuchi: Siz qabul qilgan texnik qaror keyinchalik noto'g'ri bo'lib chiqqan paytni eslay olasizmi? Nima qildingiz?

Kuchli javob: Ha, va bu menga yaxshi saboq bo'ldi. Bir loyihada men yangi, o'sha paytda community'da mashhur bo'lgan ma'lumotlar bazasi texnologiyasini tanlagandim — u qog'ozda bizning ehtiyojlarimizga juda mos edi. Lekin men uni yetarlicha chuqur sinab ko'rmadim va production'da unga o'tdik. Bir necha oydan keyin ma'lum bo'ldiki, uning ekotizimi hali yetuk emas — kutubxonalar cheklangan, muammolarni tuzatish uchun jamiyat bilimi kam, va ba'zi edge case'larda kutilmagan xatolar berardi. Bu jamoani sekinlashtira boshladi. Men avvalambor xatoni tan oldim — jamoa oldida ochiq aytdim, "bu mening qarorim edi va u to'g'ri chiqmadi" deb, chunki ayblovni boshqaga o'tkazish ishonchni buzadi. Keyin his-tuyg'usiz tahlil qildik: qolamizmi yoki ko'chamizmi. Ko'chish narxini va qolish narxini o'lchab, bosqichma-bosqich yetuk, sinovdan o'tgan yechimga qaytishga qaror qildik. Eng muhimi — men bu tajribadan tashkiliy saboq chiqardim: shundan keyin biz muhim texnologik qarorlar uchun kichik "proof of concept" bosqichini majburiy qildik — ya'ni katta majburiyat olishdan oldin, texnologiyani real sharoitga yaqin kichik sinovdan o'tkazamiz. Bu bir marta yo'l qo'ygan xatoni tizimli tarzda oldini olishga yordam berdi.

Izoh: Bu javob Senior'dan kutiladigan eng muhim sifatlarni ko'rsatadi: mas'uliyatni o'z zimmasiga olish, xatoni ochiq tan olish, va — eng qimmatlisi — undan tizimli saboq chiqarish. Nomzod ayblovni boshqaga o'tkazmadi ("bu mening qarorim edi"), qarorni his-tuyg'usiz qayta ko'rib chiqdi (qolish vs ko'chish narxi), va eng yuqori darajadagi javobni berdi: shaxsiy xatodan tashkiliy jarayon (majburiy PoC) yaratdi. Bu — Senior'ni oddiy dasturchidan ajratadigan tafakkur: alohida muammoni tuzatish emas, uning takrorlanishini tizim orqali oldini olish.

Intervyuchi: Jamoada texnik mukammallik (masalan, kodni to'liq qayta yozish) va biznes tezligi (masalan, tezroq yetkazish) o'rtasida ziddiyat bo'lganda qanday muvozanat topasiz?

Kuchli javob: Bu Senior sifatida men doim yuzlashadigan eng muhim ziddiyatlardan biri, va men uni "har doim biri to'g'ri" deb qaramayman — kontekst hal qiladi. Mening asosiy printsipim — qarorni biznes ta'siri asosida qabul qilish, muhandis sifatidagi did asosida emas. Amalda men savol beraman: bu texnik qarz bizni hozir qanchalik sekinlashtiryapti va u kelajakda qanchalik qimmatlashadi? Ba'zi texnik qarz — arzon: u tizimning kam o'zgaradigan burchagida yotibdi va hech kimga xalaqit bermaydi, uni tuzatish resurs isrofi bo'lardi. Boshqa qarz esa — qimmat: u tez-tez o'zgaradigan, ko'p bog'liq joyda va har hafta jamoani sekinlashtiryapti — bu tuzatishga arziydi. Shuning uchun men mukammallikni har joyda emas, eng ko'p ta'sir qiladigan joyda talab qilaman. Tezlik kerak bo'lganida, men ongli murosaga boraman, lekin uni yashirmayman: "biz hozir bu yechimni tez chiqaramiz, lekin bu texnik qarz, va uni so'ng sprintda qaytib tuzatamiz" deb ochiq hujjatlashtiraman va rejaga qo'shaman. Eng yomoni — murosani yashirin qilib, keyin unutish. Biznes tomoni bilan gaplashganda ham men texnik tilda emas, ta'sir tilida gapiraman: "agar buni hozir tuzatmasak, keyingi chorakda har yangi funksiya 30 foiz sekinroq chiqadi" degan gap ularga tushunarli. Xulosa: muvozanat — bu doim tezlikni tanlash ham, doim mukammallikni tanlash ham emas, balki har bir holatda ta'sirni o'lchab, ongli va shaffof qaror qabul qilishdir.

Izoh: Bu javob nomzodning eng yuqori darajadagi muhandislik yetukligini ko'rsatadi — texnik qarorni biznes tili va ta'siri bilan bog'lay olish. Nomzod "mukammallik har doim yaxshi" degan junior xatosidan ham, "biznes har doim ustun" degan sinizmdan ham qochdi. "Arzon qarz vs qimmat qarz" farqi — juda yetuk fikr. Eng kuchli jihat — biznes bilan "ta'sir tilida" gapirishi ("30 foiz sekinroq") va murosalarni "ochiq hujjatlashtirishi". Bu nomzodning nafaqat texnik, balki tashkiliy va strategik yetakchi ekanini isbotlaydi.

5-bosqich: Nomzodning savollari

Intervyuchi: Bizning tomondan savollar shu bilan tugadi. Sizda bizga savollar bormi?

Kuchli javob: Ha, albatta. Bu lavozim arxitekturaga mas'ul bo'lgani uchun, bir necha strategik savolim bor. Birinchidan, kompaniyaning texnik strategiyasi biznes maqsadlari bilan qanday bog'langan — eng katta texnik muammo yoki cheklov hozir nima? Ikkinchidan, texnik qarorlar qanday qabul qilinadi — bu markazlashganmi yoki jamoalar mustaqilmi, va mening bu jarayondagi rolim qanday bo'ladi? Uchinchidan, jamoaning hozirgi eng katta og'rig'i nima — masshtablashmi, ishonchlilikmi, yoki rivojlanish tezligimi? Men birinchi kunlardan qayerga e'tibor qaratishim kerakligini tushunmoqchiman. To'rtinchidan, muhandislik madaniyati haqida: xatolarga qanday munosabatdasiz — ular o'rganish imkoni sifatida ko'riladimi, yoki ayblov madaniyati bormi? Va nihoyat, bu lavozimda birinchi yilda muvaffaqiyat qanday ko'rinadi — men uchun eng muhim natija nima bo'ladi?

Izoh: Senior nomzodning savollari strategik va tashkiliy darajada bo'lishi kerak — bu javob aynan shunday. Savollar texnik strategiya, qaror qabul qilish jarayoni, jamoaning haqiqiy og'rig'i, muhandislik madaniyati (ayniqsa "ayblov madaniyatimi?" degan o'tkir savol) va o'ziga qo'yiladigan kutilmalar haqida. Bu savollar nomzodning kompaniyani jiddiy baholayotganini va o'zining ta'sir ko'lamini oldindan o'ylayotganini ko'rsatadi. "Ayblov madaniyati bormi?" degan savol — nomzod sog'lom jamoa muhitiga qadr berishini bildiradi, bu Senior uchun to'g'ri ustuvorlik.

Senior mock: Baholash

Umumiy taassurot: Bu nomzod Senior / Texnik yetakchi lavozimi uchun kuchli. Baholash:

Yakuniy qaror: Ishga taklif qilinsin (Strong Hire), Senior/Lead darajasida.

Nomzodga umumiy maslahat: Sizni ajratib turadigan asosiy sifat — hech qachon "bitta to'g'ri javob" deb o'ylamasligingiz. Har bir savolda siz trade-off'larni ko'rdingiz, o'z yechimingizning kamchiliklarini tan oldingiz va kontekstga qarab qaror qabul qildingiz. Bu — Senior tafakkurining mohiyati. Yana bir kuchli tomoningiz — texnik qarorlarni biznes va tashkiliy ta'sir bilan bog'lay olishingiz; bu sizni oddiy Senior'dan Lead darajasiga ko'taradi. Rivojlanish uchun: agar Staff yoki Principal darajasiga intilsangiz, o'z ta'siringizni bir jamoadan tashqariga — butun tashkilotning texnik yo'nalishiga qaratishni mashq qiling. Umuman, siz ishga tayyor va kuchli nomzodsiz.

Umumiy yakuniy maslahatlar (barcha darajalar uchun)

Uch mock intervyuni ko'rib chiqdik. Endi ular ortidagi umumiy tamoyillarni jamlaymiz — bular daraja qanday bo'lishidan qat'i nazar amal qiladi.

1. Ovoz chiqarib o'ylang

Intervyuchi sizning oxirgi javobingizdan ko'ra, javobga qanday yetib borganingizni ko'rmoqchi. Jim o'tirib to'g'ri javobni topgandan ko'ra, ovoz chiqarib o'ylab, ba'zan xato qilib, keyin o'zingizni tuzatgan afzal. Bu ayniqsa live-coding va system design'da hal qiluvchi.

2. Avval savolni aniqlashtiring

Har uch mock'da kuchli nomzodlar javobga sakramasdan, avval savolni aniqlashtirdi. Ayniqsa system design'da: talablarni so'ramasdan yechim taklif qilish — eng keng tarqalgan xato. "Faraz qilaylik..." deb aniq shartlar qo'yish sizni professional ko'rsatadi.

3. Trade-off tili bilan gapiring

Junior'dan Senior'ga o'tgan sari, "to'g'ri javob" o'rniga "sharoitga bog'liq javob" muhimlashadi. "Buni shunday qilaman, chunki... lekin agar... bo'lsa, boshqacha qilardim" degan tuzilma sizning yetuk fikrlashingizni ko'rsatadi. Har yechimning narxi borligini tan oling.

4. Nazariyani tajriba bilan bog'lang

Eng kuchli javoblar har doim "men buni ishlatganman" bilan yakunlanadi. Closure haqida so'rashsa, debounce misolini keltiring. Index haqida so'rashsa, real so'rovni tezlashtirgan holatingizni ayting. Nazariya + tajriba = ishonch.

5. Xatolaringizni bekitmang

Junior "bug'ni qanday tuzatdim", Senior "noto'g'ri qarordan qanday saboq oldim" deb gapirdi. Xatoni tan olish zaiflik emas — yetuklik belgisi. Intervyuchilar mukammal odamni emas, o'rganadigan va mas'uliyatli odamni qidiradi.

6. Behavioral savollarga STAR bilan tayyorlaning

Vaziyat (Situation) Vazifa (Task) Harakat (Action) Natija (Result). Bir necha real hikoyani oldindan tayyorlab qo'ying: qiyin bug, kelishmovchilik, muddat bosimi, xato qaror. Har mock'da nomzodlar aynan shunday tayyor hikoyalarni ishlatdi.

7. Har doim savol bering

"Savolim yo'q" deyish — eng katta yo'qotilgan imkoniyat. Savollaringiz orqali siz ham kompaniyani baholayotganingizni, uzoq muddatli o'ylayotganingizni ko'rsatasiz. Daraja qancha yuqori bo'lsa, savollaringiz shuncha strategik bo'lishi kerak.

8. O'z darajangizdan gapiring, lekin yuqoriga qarang

Junior'dan Senior javobi kutilmaydi, va aksincha. Lekin har doim bir pog'ona yuqoriga intilish — o'sish istagingizni ko'rsatadi. Kamtarlik va ishonch o'rtasidagi muvozanat — barcha darajalarda qadrlanadi.

Yakuniy so'z: Intervyu — imtihon emas, suhbat. Intervyuchi sizning "dushmaningiz" emas, u siz bilan birga ishlashi mumkin bo'lgan bo'lajak hamkasbingiz. U sizning muvaffaqiyatingizdan manfaatdor, chunki yaxshi nomzod topish uning ham maqsadi. Shu ruhda, tabiiy va o'zingiz bo'lib boring. Omad tilaymiz.