Question 1

Rapid-fire raunduna necə hazırlaşmaq lazımdır?

Accepted Answer

Hazırlığın açarı əzbər deyil, məşqdir — bildiyin şeyi 30 saniyəyə sığdırmaq ayrıca bacarıqdır və onu yalnız yüksək səslə təkrarlayaraq qazanırsan. Mənim yanaşmam: (1) 25-30 ən çox verilən sualın siyahısını hazırlayıram (auto-waiting, locator strategiyası, fixture, storageState, flaky, piramida, page vs context, iframe, yeni tab, sharding, mock); (2) hər biri üçün 2-3 cümləlik cavab yazıram — yazmaq fikri strukturlaşdırır; (3) yüksək səslə məşq edirəm və vaxtı ölçürəm — 40 saniyəni keçirsə, qısaldıram; (4) hər cavaba bir konkret nümunə əlavə edirəm, çünki nümunə cavabı əzbərdən ayırır. Məşq zamanı gördüyüm ən çox yayılmış səhv: sadə suala uzun cavab. "Auto-waiting nədir?" sualına 3 dəqiqə danışmaq bilikli görünmür — sualın səviyyəsini oxuya bilmədiyini göstərir. Bir də bilmədiyim sahələri əvvəlcədən müəyyən edirəm və onlar üçün dürüst cavab hazırlayıram: "Bunu istifadə etməmişəm, prinsipi belə təsəvvür edirəm..." Bu cümləni əvvəlcədən hazırlamaq stress anında uydurmaqdan qoruyur.

Question 2

Rapid-fire zamanı yanlış cavab verdiyini anlayırsan. Nə edirsən?

Accepted Answer

Dərhal və sakitcə düzəldirəm: "Bir dəqiqə — əvvəlki suala qayıtmaq istəyirəm, dediyim tam dəqiq deyildi. Doğrusu belədir..." Bunun niyə güclü hərəkət olduğunu başa düşmək vacibdir: intervyuer səhvi çox güman ki, artıq qeyd edib. Sən özün qayıdıb düzəldəndə iki şey göstərirsən — birincisi, mövzunu həqiqətən başa düşürsən (səhvi görə bildin); ikincisi, səhvini etiraf edə bilirsən. İkincisi komanda işində birincidən daha vacib keyfiyyətdir və müsahibədə ayrıca qiymətləndirilir. Nə etməmək lazımdır: (1) səhvi bilə-bilə üstündən keçmək — sonrakı sualların cavabları da şübhə altına düşür; (2) uzun-uzadı üzr istəmək və özünü aşağılamaq — bir cümlə kifayətdir, sonra irəli; (3) həddindən artıq narahat olub ritmi itirmək — bir səhv müsahibəni müəyyən etmir, amma özünə inamın çökməsi edə bilər. Eyni prinsip live coding-də də keçərlidir: yanlış yolla getdiyini görəndə "burada səhv istiqamətə getdim, geri qayıdıram" demək zəiflik yox, mühəndis refleksidir.

Question 3

İntervyuer bir cavabında "niyə?" deyə dərinləşməyə başlayır. Bu nə deməkdir?

Accepted Answer

Bu, demək olar ki, həmişə müsbət siqnaldır və çox namizəd bunu səhv oxuyur. İki mümkün səbəb var: (1) intervyuer sənin bu sahədə həqiqətən dərinliyin olub-olmadığını yoxlayır — yəni cavabın maraqlı gəldi və dərinliyə dəyər; (2) o özü bu mövzu ilə maraqlanır və peşəkar söhbət qurmaq istəyir. Hər iki halda bu, cəza deyil, fürsətdir. Rapid-fire raundunda dərinləşmə olmur — dərinləşmə o deməkdir ki, artıq keçidi qazanmısan. Düzgün davranış: (1) müdafiəyə keçmə — sual hücum deyil; (2) düşüncə prosesini aç: "Bu qərarı belə verirəm, çünki...", trade-off-ları adlandır; (3) konkret nümunə ver — real layihədən bir hal cavabı dərhal ikiqat gücləndirir; (4) sərhədi bilirsənsə de: "Bundan sonrasını dəqiq bilmirəm, amma güman edirəm ki..." Bir incə məqam: bəzən "niyə?" ardıcıllığı sənin harada dayanacağını görmək üçün qəsdən sərhədə qədər aparılır. Yəni sonda mütləq "bilmirəm" nöqtəsinə çatacaqsan — və bu, planlaşdırılmış nəticədir, uğursuzluq deyil. Ora təmkinlə çatmaq düzgün davranışdır.

Question 4

"Playwright-ı Selenium-dan seçmə səbəbin?" — 30 saniyəyə cavab qur.

Accepted Answer

Struktur: 3 üstünlük + 1 dürüst güzəşt + kontekst cümləsi. Bu format həm bilik, həm balanslı mühakimə göstərir və 30 saniyəyə sığır. Model cavab: "Üç əsas səbəb: birincisi, auto-waiting — flakiness-in ən böyük mənbəyini kökündən azaldır; ikincisi, sürət — WebSocket protokolu və default paralellik; üçüncüsü, alətlər — trace viewer CI-dakı fail-i araşdırmağı dəqiqələrə salır, üstəlik API testing daxilidir. Selenium-un güclü tərəfi hələ də dil və brauzer əhatəsinin genişliyi, böyük legacy suite-lərdə mövcud ekosistemdir. Bizim kontekstdə — JS/TS stack, müasir web app — Playwright açıq şəkildə üstün gəldi." Niyə bu struktur işləyir: (1) səbəblər konkret və texnikidir ("daha yaxşıdır" deyil); (2) rəqibin güclü tərəfini tanıyırsan — bu, balanslı mühakimə siqnalıdır və çox namizəd bunu buraxır; (3) son cümlə kontekst əsaslı seçim göstərir: alət kontekstə görə seçilir, moda görə yox. Ən çox rast gəlinən səhv: Selenium-u pisləmək ("köhnəlib", "yavaşdır"). İntervyuerin özü Selenium ilə 10 il işləmiş ola bilər — və hər halda kateqorik mövqe təcrübəsizlik göstəricisidir.

Sual	Model cavab (20-30 saniyə)
Playwright-da auto-waiting nədir?	Hər action-dan əvvəl Playwright elementin actionable olmasını gözləyir: görünür, aktiv, stabil, hadisə qəbul edir. Ona görə `sleep` yazmağa ehtiyac yoxdur.
`locator` ilə `ElementHandle` fərqi?	Locator lazy-dir — hər istifadədə elementi yenidən tapır, ona görə DOM yenilənəndə sınmır. ElementHandle konkret DOM elementinə bağlanır və köhnəlir (stale olur); müasir kodda istifadə olunmur.
`toBeVisible()` ilə `isVisible()` fərqi?	`expect(...).toBeVisible()` web-first assertion-dır — şərt ödənənə qədər gözləyir. `isVisible()` isə həmin anın boolean cavabını qaytarır, gözləmir — testdə şərt kimi istifadə etmək flakiness mənbəyidir.
Strict mode nədir?	Locator birdən çox elementə uyğun gələndə Playwright xəta atır — səssiz səhv seçimin qarşısını alır. Həlli: locator-u dəqiqləşdirmək, `filter()`, və ya niyyət varsa `first()`/`nth()`.
`page` və `context` fərqi?	`context` izolyasiya olunmuş brauzer profilidir — öz cookie-ləri və storage-ı var; `page` onun içindəki bir tab-dır. İki fərqli istifadəçi üçün iki context lazımdır, iki tab yox.
storageState nə üçündür?	Login-i bir dəfə setup-da edib cookie/localStorage-ı fayla yazır; bütün testlər həmin state ilə başlayır. Hər testdə 5-10 saniyə qənaət edir.
Fixture teardown harada yazılır?	`await use(...)` sətrindən sonrakı kodda. Test fail olsa belə icra olunur — buna görə cleanup üçün ən etibarlı yerdir.
Sharding nədir?	Suite-i bir neçə maşına bölmək: `--shard=1/4`. 4 maşın ümumi müddəti təxminən 4 dəfə azaldır. Şərt: testlər tam müstəqil olmalıdır.
iframe içindəki elementə necə çatırsan?	`page.frameLocator('iframe[title="..."]')` ilə frame kontekstinə keçirəm; içəridə adi locator-lar işləyir. Adi locator frame sərhədini keçmir.
Yeni tab açılırsa nə edirsən?	Klikdən ƏVVƏL `context.waitForEvent('page')` ilə gözləməni qururam, sonra klik edirəm və `await` ilə yeni `page` obyektini alıram.
Fayl yükləməsini necə test edirsən?	`setInputFiles('path/to/file')` — OS dialoqu açılmır. Gizli input-lu custom düymə varsa, `page.waitForEvent('filechooser')` ilə tuturam.
API-ni Playwright-da necə çağırırsan?	`request` fixture-i ilə: `await request.post('/api/orders', { data })`. Test datasını hazırlamaq üçün UI əvəzinə bunu istifadə edirəm — sürətli və stabildir.

Sual	Model cavab
`==` ilə `===` fərqi?	`===` tip çevirməsi etmir; `==` edir (`'1' == 1` → true). Testlərdə həmişə `===`.
Promise nədir, `async/await` nə edir?	Promise gələcəkdə tamamlanacaq əməliyyatın nəticəsidir. `await` onun həllini gözləyir və kodu ardıcıl oxunan formada saxlayır. Playwright API-si bütünlüklə async-dır — `await` unutmaq testi səssizcə yalan yaşıl edir.
`let`, `const`, `var` fərqi?	`const` və `let` block scope-ludur; `var` function scope-lu və hoisting-lidir — istifadə etmirəm. Default `const`, dəyər dəyişəcəksə `let`.
TypeScript-in test kodunda faydası nədir?	Səhvlərin işə salmadan tapılması, IDE avtotamamlaması (Playwright API-si üçün böyük fərq), fixture və test datası üçün tiplər. Həm də `no-floating-promises` kimi typed lint qaydalarını mümkün edir.
Flaky test nədir?	Kod dəyişmədən gah keçən, gah sınan test. Tipik səbəblər: yarış vəziyyətləri, sabit sleep-lər, paylaşılan data. Ən böyük zərəri suite-ə inamı öldürməsidir.
Smoke ilə regression fərqi?	Smoke — ən kritik axınların sürətli yoxlanması (build ümumiyyətlə işləkdirmi?), hər PR-da. Regression — geniş əhatə, mövcud funksionallığın sınmadığını təsdiqləyir, adətən nightly.
Test piramidası nədir?	Çoxlu sürətli unit, orta qədər integration/API, az sayda E2E UI. Prinsip: yoxlamanı mümkün olan ən aşağı səviyyədə et.
Git-də `merge` ilə `rebase` fərqi?	`merge` tarixçəni saxlayır və birləşdirmə commit-i yaradır; `rebase` commit-ləri yenidən yazaraq xətti tarixçə verir. Paylaşılan branch-ı rebase etmək təhlükəlidir.

Sürətli texniki suallar (rapid-fire)