Wawancara Desain Sistem Frontend

Wawancara frontend tingkat senior meminta Anda merancang fitur UI yang tidak sederhana secara menyeluruh: umpan berita, pelengkapan otomatis, galeri gambar, atau dasbor dengan gulir tanpa akhir. Penilaiannya mencakup arsitektur, pemahaman kompromi, intuisi performa, dan komunikasi — bukan hafalan framework.

Sebagian besar wawancara berdurasi 45–60 menit mengikuti urutan: 1) Memperjelas persyaratan (5 menit). 2) Membuat sketsa arsitektur tingkat tinggi (10 menit). 3) Menguraikan komponen (10 menit). 4) Pengambilan data + state (10 menit). 5) Performa + aksesibilitas (10 menit). 6) Pembahasan mendalam pada satu area (dipilih pewawancara).

Jangan mulai menulis kode. Tanyakan: perangkat target? pengguna yang login atau anonim? dukungan offline? pembaruan waktu nyata? skala yang diharapkan (10 pengguna dibandingkan 10 juta)? persyaratan aksesibilitas? dukungan peramban? Keputusan-keputusan ini memengaruhi seluruh rancangan.

Gambarkan kotak-kotaknya: klien (SPA atau SSR?), gateway API, layanan, cache, CDN. Tandai tindakan pengguna dan aliran data. Sebutkan kasus tepi sejak awal — hal itu menunjukkan bahwa Anda pernah membangun sistem nyata.

Buat sketsa hierarki komponen. NewsFeed → Header, Story[], Composer. Story → Avatar, Content, Actions, Comments. Identifikasi komponen mana yang dapat digunakan kembali dan mana yang khusus untuk fitur tertentu.

Di mana setiap bagian state disimpan? Lokal (useState), URL (router), state server (React Query), atau state klien (Zustand)? Bahas strategi pengambilan data: SSR awal, gulir tanpa akhir, pembaruan WebSocket waktu nyata, atau UI optimistis.

Pemisahan kode pada batas rute. Daftar tervirtualisasi untuk umpan yang panjang. Optimalisasi gambar (pemuatan malas + AVIF/WebP). Hindari pemblokiran utas utama. Anggaran bundel. SW dengan pendekatan cache-first untuk kunjungan berulang.

HTML semantik. Navigasi dengan papan ketik. Peran ARIA dan wilayah live. Kontras warna. Pengujian pembaca layar. Poin tambahan: sebutkan pengelolaan fokus saat rute berubah.

Bahas: gulir tanpa akhir dengan IntersectionObserver, virtualisasi untuk menghemat memori, tanda suka optimistis, indikator kiriman baru waktu nyata, pemuatan malas gambar dengan placeholder buram, SSR untuk SEO, dan caching ISR/edge untuk linimasa populer.

Bahas: input yang di-debounce, AbortController untuk membatalkan permintaan yang sudah usang, deduplikasi permintaan, caching respons (LRU), navigasi dengan papan ketik (atas/bawah/enter/escape), peran ARIA combobox, dan penanganan papan ketik virtual di perangkat seluler.

Bahas: tata letak masonry dibandingkan grid, srcset responsif untuk layar retina, pemuatan malas berbasis persimpangan, prapengambilan gambar berikutnya, lightbox/modal dengan perangkap fokus, gestur usap di perangkat seluler, navigasi panah dengan papan ketik, dan deep linking.

Untuk setiap pilihan, sebutkan alternatifnya dan alasan Anda memilih salah satunya. "Saya akan menggunakan IntersectionObserver untuk pemuatan malas karena bersifat native dan efisien. Alternatifnya adalah listener gulir dengan throttle — lebih sederhana, tetapi lebih tersendat pada CPU lambat." Inilah yang dihargai oleh pewawancara tingkat senior.

1) Langsung menulis kode sebelum melakukan klarifikasi. 2) Mengabaikan aksesibilitas. 3) Melupakan keadaan error (kegagalan jaringan, hasil kosong). 4) Tidak memikirkan keadaan pemuatan. 5) Jawaban yang samar ("Saya akan menggunakan React" — arsitektur yang mana?).

Anda diminta merancang kotak pencarian pelengkapan otomatis dalam wawancara rancangan sistem. Apa hal pertama yang harus Anda lakukan?

Perjelas cakupan terlebih dahulu. Arsitektur tingkat tinggi (klien, API, cache, CDN). Pohon komponen. Lokasi state (lokal, URL, cache server, global). Strategi pengambilan data. Performa (pemisahan kode, virtualisasi, optimalisasi gambar). Aksesibilitas (papan ketik, ARIA, kontras). Komunikasikan kompromi. Hindari langsung menulis kode. Latih pola klasik: umpan, pelengkapan otomatis, galeri, dan dasbor.