Frontend developer
Frontend developer membangun bagian produk yang benar-benar disentuh penggunanya. Cakupannya membentang dari arsitektur komponen dan state management sampai ke aksesibilitas, performa, dan perilaku browser yang tidak terlihat siapa pun sampai ia rusak. Panduan ini menjelaskan apa saja yang tercakup dalam peran tersebut, kapan sebuah tim benar-benar membutuhkannya, dan bagaimana membedakan kandidat yang kuat dari kandidat yang sekadar terdengar meyakinkan.
Apa yang dikerjakan seorang frontend developer?
Frontend developer membangun lapisan antarmuka sebuah aplikasi web atau mobile â layar, interaksi, dan pengambilan data yang berjalan di browser atau perangkat pengguna. Pekerjaannya mencakup menerjemahkan desain menjadi komponen yang berfungsi, mengelola state aplikasi, menangani kondisi loading dan error, memenuhi persyaratan aksesibilitas, serta menjaga antarmuka tetap cepat pada jaringan dan perangkat yang sesungguhnya dipakai orang. Ini adalah spesialisasi tersendiri, bukan versi ringan dari pekerjaan backend.
Peran ini berada di antara dua disiplin yang menariknya ke arah berbeda. Desain memasok maksud â layout, hierarki, motion, nada â dan frontend developer harus mewujudkannya dalam medium yang berubah-ubah menurut ukuran viewport, metode input, ketersediaan font, kualitas koneksi, dan assistive technology. Backend memasok data, dan frontend developer yang memutuskan kapan data itu diambil, apa yang ditampilkan selama data belum ada, dan apa yang terjadi ketika data tidak pernah datang.
Kesulitan terbesarnya ada pada state, bukan pada layar. Satu tampilan biasanya punya empty state, loading state, partial state, error state, offline state, dan success state â sementara file desain umumnya hanya menggambarkan satu di antaranya. Menilai state mana yang penting dan membangunnya tanpa mengubah komponen menjadi pohon keputusan raksasa adalah sebagian besar dari yang membedakan frontend engineer berpengalaman dari orang yang bisa merangkai halaman.
Cakupannya juga melebar jauh. Server-side rendering, streaming, edge execution, dan hydration membuat keputusan seorang frontend developer kini ikut menentukan biaya server dan perilaku first paint, bukan sekadar kerapian di sisi klien. Orang yang pengalamannya berhenti di browser akan kesulitan dalam arsitektur rendering modern.
Kapan tim membutuhkan kapabilitas ini
Pekerjaan frontend sering diserap begitu saja oleh generalist sampai ada tekanan tertentu yang membuat cara itu mahal. Berikut situasi ketika seorang frontend developer khusus biasanya mulai terbayar.
Antarmuka sudah melampaui strukturnya
Komponen disalin alih-alih dikomposisikan, state dioper lewat props sampai beberapa level ke bawah, dan perubahan di satu layar merusak layar lain. Ini pemicu paling umum sekaligus paling tidak terlihat dari luar codebase â kecepatan tim turun tanpa ada satu pun fitur yang tampak sulit.
Aksesibilitas menjadi persyaratan, bukan lagi aspirasi
Kuesioner procurement, tender sektor publik, atau tinjauan hukum mengubah kesesuaian WCAG menjadi item yang harus dikirimkan. Menambahkan aksesibilitas ke komponen yang dibangun tanpa memikirkannya jauh lebih berat daripada membangunnya sejak awal, dan itu menuntut orang yang paham beda antara lolos automated scan dan benar-benar bisa dipakai dengan screen reader.
Performa terukur menggerus konversi
Core Web Vitals gagal di data lapangan, bukan di lab, dan penyebabnya tersebar di ukuran bundle, penanganan image, resource yang memblokir render, dan ketidakstabilan layout. Mendiagnosisnya menuntut kemampuan membaca data real user monitoring, bukan menjalankan audit sintetis sekali lalu selesai.
Tim sedang memindahkan strategi rendering
Berpindah dari aplikasi yang dirender di klien ke server rendering, static generation, atau kombinasi keduanya mengubah pengambilan data, autentikasi, caching, dan penanganan error sekaligus. Tim kerap meremehkan pekerjaan ini karena tampilan akhirnya terlihat sama saja.
Desain dan engineering sudah saling menjauh
Design system hidup di tool desain dan, secara terpisah dan berbeda, di dalam kode. Harus ada yang memiliki lapisan penerjemahnya â token, primitive, komponen yang terdokumentasi â atau setiap layar baru akan mengulang perdebatan spacing dan warna yang seharusnya sudah selesai.
Backend engineer mengerjakan frontend dengan setengah hati
Engineer yang cakap menghasilkan antarmuka yang tidak bisa mereka nilai sendiri kualitasnya. Hasilnya biasanya berjalan, dan biasanya jatuh pada aksesibilitas, perilaku responsif, dan detail interaksi â dan engineer itu sendiri yang paling pertama mengakuinya.
Kapabilitas inti
Arsitektur komponen
Memutuskan apa yang layak menjadi komponen, di mana batasnya, dan props mana yang pantas diekspos. Salah di kedua arah sama-sama mahal: terlalu granular membuat satu perubahan menyentuh dua puluh file, terlalu kasar membuat setiap komponen menumbuhkan satu flag konfigurasi per kasus pemakaian.
State management
Membedakan server state, client state, form state, URL state, dan state UI sesaat, lalu menjaga masing-masing tetap di tempatnya. Sebagian besar kerumitan frontend lahir dari data server yang disalin ke client state lalu perlahan menyimpang dari sumbernya.
Strategi rendering
Memilih antara client rendering, server rendering, static generation, incremental regeneration, dan streaming per route alih-alih per aplikasi, sambil memahami konsekuensinya terhadap caching, autentikasi, personalisasi, dan biaya.
Aksesibilitas
Markup semantik, keyboard operability, focus management, accessible name, kontras warna, preferensi motion, dan penggunaan ARIA yang tepat â termasuk memahami bahwa aturan pertama ARIA adalah memakai elemen native jika elemen itu tersedia.
Performa
Komposisi bundle dan code splitting, format serta ukuran image, strategi pemuatan font, mencegah layout shift, dan memahami apa yang benar-benar menggerakkan Largest Contentful Paint dan Interaction to Next Paint dibanding apa yang sekadar terlihat seperti optimisasi.
Layout responsif dan adaptif
Membangun antarmuka yang berfungsi lintas ukuran viewport, metode input, penskalaan teks, dan konteks container â bukan hanya pada tiga breakpoint tetap yang kebetulan cocok dengan file desain dan tidak dengan hal lain.
Perilaku browser
Memahami event loop, pipeline rendering, layout dan paint, caching, storage, CORS, serta cara perilaku berbeda antar engine. Inilah pengetahuan yang mengubah bug intermiten menjadi diagnosis, bukan sekadar workaround.
Testing
Component test yang menguji perilaku alih-alih implementasi, cakupan end-to-end pada alur yang penting secara komersial, visual regression bila memang perlu, dan pertimbangan untuk tahu mana di antara ketiganya yang dituntut oleh sebuah risiko.
Kolaborasi dengan desain
Membaca desain secara kritis â mengenali state yang tidak digambar, edge case yang diasumsikan tidak ada, dan batasan yang belum diketahui perancangnya â lalu mengembalikannya sebagai masukan sebelum implementasi, bukan di tengah implementasi.
Keamanan di sisi antarmuka
Mencegah cross-site scripting lewat escaping yang benar dan kehati-hatian saat menyuntikkan raw HTML, menangani token tanpa mengeksposnya ke script, dan memahami bahwa validasi di sisi klien adalah fitur kenyamanan, bukan kontrol keamanan.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam frontend engineering. Daftar ini menggambarkan lanskap disiplin tersebut sebagaimana dipraktikkan secara umum di industri, dan bukan klaim tentang perkakas engineer mana pun â lagi pula frontend developer yang kuat umumnya lebih tepat dinilai dari kedalaman penalarannya soal rendering, state, dan browser ketimbang dari nama framework yang tertulis di posisi terakhirnya.
Bahasa
- JavaScript
- TypeScript
- HTML
- CSS
Framework dan library
- React
- Vue
- Angular
- Svelte
- Solid
Framework aplikasi
- Next.js
- Nuxt
- Remix
- Astro
- SvelteKit
Styling
- Tailwind CSS
- CSS Modules
- Sass
- CSS-in-JS
- Design token
State dan data
- TanStack Query
- Redux Toolkit
- Zustand
- Apollo Client
- tRPC
Testing
- Vitest
- Jest
- Testing Library
- Playwright
- Cypress
Build dan tooling
- Vite
- Turbopack
- webpack
- ESLint
- Storybook
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Apa yang perlu dinilai saat memilih kandidat
Kandidat frontend luar biasa mudah dinilai secara keliru. Portofolio memperlihatkan permukaan yang sudah jadi dan tidak mengatakan apa pun soal keputusan di baliknya, sementara kefasihan framework adalah hal yang paling gampang diuji sekaligus paling lemah daya prediksinya. Area berikut lebih layak digali.
Pertimbangan arsitektur komponen
Tanyakan bagaimana mereka memutuskan sesuatu layak menjadi komponen, dan kapan mereka justru sengaja menduplikasi kode alih-alih mengabstraksikannya. Dalam kode antarmuka, abstraksi yang terlalu dini setidaknya sama merusaknya dengan duplikasi, dan engineer yang pernah memelihara component library selama beberapa tahun biasanya punya pendirian soal ini yang tidak dimiliki engineer yang hanya pernah memakainya.
- Bisa menceritakan komponen yang dibuatnya makin konfigurabel dan belakangan ia sesali
- Membedakan urusan presentational dan container tanpa memperlakukannya sebagai dogma
- Berbicara tentang API yang diekspos sebuah komponen, bukan hanya soal apa yang dirender
Kedalaman aksesibilitas
Tooling otomatis hanya menangkap sekitar sepertiga masalah aksesibilitas yang nyata, sehingga engineer yang seluruh pendekatannya adalah menjalankan scanner punya celah yang mungkin tidak ia sadari. Cari orang yang benar-benar pernah mengoperasikan antarmuka lewat keyboard dan dengan screen reader.
- Menjangkau elemen native lebih dulu sebelum atribut ARIA
- Bisa menjelaskan focus management pada modal atau saat perpindahan route
- Hafal persyaratan kontras tanpa perlu mencarinya, dan menerapkannya juga pada state interaktif
- Memperlakukan preferensi motion dan penskalaan teks sebagai persyaratan, bukan tambahan
Trade-off rendering dan pengambilan data
Tanyakan kapan mereka akan memilih server rendering ketimbang client rendering, dan apa harganya. Jawaban yang kuat menyentuh caching, personalisasi, autentikasi, dan biaya infrastruktur â bukan hanya SEO, yang biasanya menjadi jawaban orang yang membaca soal ini tanpa pernah menjalaninya.
- Memilih strategi per route, bukan per aplikasi
- Bisa menjelaskan berapa mahal sebenarnya hydration
- Memperhitungkan apa yang terjadi ketika sumber data lambat atau tidak tersedia
Performa pada kondisi nyata
Pisahkan kandidat yang mengoptimalkan skor lab dari kandidat yang bekerja dari data lapangan. Yang pertama akan membuat sebuah angka sintetis membaik; yang kedua akan membuat produk terasa lebih cepat bagi orang yang memakainya, dan keduanya tidak selalu perubahan yang sama.
- Merujuk data real user monitoring, tidak hanya audit sintetis
- Memahami beda antara performa pemuatan dan responsivitas interaksi
- Bisa menyebut satu penyebab konkret ketidakstabilan layout dan cara ia memperbaikinya
Kemampuan debugging
Ini pembeda paling andal yang tersedia sekaligus yang paling sering dilewati. Minta satu bug intermiten yang benar-benar sulit, lalu dengarkan metodenya: bagaimana ia mempersempit ruang masalah, apa yang ia singkirkan, dan bagaimana ia memastikan perbaikannya mengenai penyebab, bukan gejala.
- Menceritakan cara menyusun dan menguji hipotesis, bukan mengubah-ubah kode
- Terbiasa dengan browser developer tools lebih jauh dari sekadar console
- Membedakan akar penyebab dari pemicunya
Pertimbangan dalam testing
Pertanyaannya bukan apakah mereka menulis test, melainkan test mana yang mereka anggap layak ditulis. Cari orang yang bisa menjelaskan mengapa sebuah test tertentu akan menangkap kelas kegagalan tertentu, dan yang tidak menguji detail implementasi sehingga refactoring menjadi mahal.
- Menguji perilaku yang bisa diamati pengguna
- Punya pendapat soal sampai di mana cakupan end-to-end masih sepadan
- Memperlakukan test yang flaky sebagai cacat, bukan gangguan yang cukup diulang
Bekerja bersama desain
Frontend engineer yang kuat mengajukan keberatan atas desain secara konstruktif dan sedini mungkin. Tanyakan apa yang mereka lakukan ketika sebuah desain melewatkan error state atau meminta sesuatu yang ditangani buruk oleh platform â jawabannya memperlihatkan apakah mereka memosisikan diri sebagai pelaksana atau sebagai kolaborator.
- Mengidentifikasi state yang hilang sebelum implementasi dimulai
- Bisa menjelaskan batasan platform tanpa meremehkan maksud desainnya
- Pernah bekerja dengan design system dari kedua sisi batas
Pertanyaan wawancara yang layak diajukan
Pertanyaan yang memperlihatkan penalaran, bukan hafalan. Semua ini ditawarkan sebagai panduan untuk proses wawancara Anda sendiri â Anda yang menilai setiap kandidat, dan tidak ada yang bergabung ke tim Anda tanpa penilaian itu.
Ceritakan sebuah komponen yang Anda rancang dan ternyata keliru. Apa yang Anda ubah, dan apa yang akan Anda lakukan berbeda sekarang?
What a strong answer shows
Kemampuan mengoreksi diri dan pengalaman pemeliharaan yang nyata. Engineer yang hanya pernah membangun fitur baru jarang punya cerita ini; engineer yang bertahun-tahun memelihara sebuah antarmuka selalu punya. Perhatikan apakah pelajarannya benar-benar tergeneralisasi.
Sebuah halaman mendapat skor bagus pada audit lab, tetapi pengguna melaporkan halaman itu terasa lambat. Bagaimana Anda menyelidikinya?
What a strong answer shows
Apakah mereka membedakan metrik pemuatan dari responsivitas interaksi, dan apakah mereka menjangkau data lapangan. Jawaban yang kuat menyinggung long task, main thread yang terblokir, dan jurang antara first paint yang cepat dengan halaman yang benar-benar merespons input.
Bagaimana Anda memutuskan antara server rendering, static generation, dan client rendering untuk sebuah route?
What a strong answer shows
Pertimbangan arsitektural, bukan default bawaan framework. Penalarannya semestinya mencakup kesegaran data, personalisasi, autentikasi, caching, dan biaya â serta memperlakukan pilihan itu sebagai keputusan per route.
Apa yang terjadi ketika pengguna keyboard menekan tab menyusuri antarmuka yang paling baru Anda bangun?
What a strong answer shows
Apakah aksesibilitas benar-benar dipraktikkan atau sekadar diklaim. Kandidat yang benar-benar pernah melakukannya akan menceritakan urutan fokus, indikator fokus yang terlihat, dan focus management saat navigasi. Yang belum pernah akan menjawab dengan pernyataan umum.
Jelaskan cara Anda mengelola data server di dalam aplikasi klien. Anda simpan di mana, dan bagaimana Anda tahu data itu masih benar?
What a strong answer shows
Pemahaman atas sumber kerumitan frontend yang paling sering muncul. Jawaban yang kuat memperlakukan server state sebagai cache dengan aturan invalidasi, bukan sebagai state aplikasi yang kebetulan datang dari panggilan jaringan.
Ceritakan satu bug intermiten yang hanya muncul pada sebagian pengguna. Bagaimana Anda menemukannya?
What a strong answer shows
Metode debugging dalam ketidakpastian yang sesungguhnya. Perhatikan cara mempersempit masalah, pemasangan instrumentasi, dan pengujian hipotesis â juga apakah kandidat membedakan apa yang memicu bug dari apa yang menyebabkannya.
Anda menerima sebuah desain tanpa empty state, tanpa error state, dan tanpa loading state. Apa yang Anda lakukan?
What a strong answer shows
Apakah mereka berkolaborasi atau sekadar menurut. Jawaban terkuat mengangkat persoalan itu sebelum implementasi dan mengusulkan state yang konkret, alih-alih mengarangnya diam-diam atau membangun persis sebatas yang digambar.
Ada apa di codebase frontend tim Anda yang ingin Anda hapus jika bisa, dan mengapa benda itu masih ada di sana?
What a strong answer shows
Pertimbangan teknis sekaligus realisme organisasi. Engineer yang hanya bisa menceritakan apa yang ingin mereka tambahkan umumnya belum pernah memikul ongkos dari apa yang mereka bangun.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- Sebuah tim produk sedang memodernkan frontend yang sudah matang sambil tetap merilis fitur. Antarmuka yang ada berfungsi, tetapi batas antar komponen mulai kabur, celah aksesibilitas tersingkap saat tinjauan procurement, dan tim tidak bisa mengambil pekerjaan migrasi tanpa menghentikan pengiriman roadmap.
- Approach
- Kapasitas frontend tambahan bekerja di dalam alur kerja engineering tim yang sudah ada â standar komponen mereka, proses review mereka, ritme rilis mereka, dan arah arsitektur mereka. Engineer internal tetap memegang kepemilikan atas keputusan produk dan arah teknis; kapasitas tambahan menyerap pekerjaan migrasi berdampingan dengan mereka, bukan menjalankan jalur terpisah.
- What this adds to the team
- Tim memperoleh kapasitas pengiriman tanpa memindahkan kepemilikan produk maupun kewenangan arsitektural. Keputusan tentang akan menjadi seperti apa antarmuka itu tetap berada pada orang-orang yang memiliki produknya.
Related disciplines
Frequently asked questions
- Apa beda frontend developer dan full-stack developer?
- Frontend developer berspesialisasi di lapisan antarmuka dan umumnya lebih dalam pada aksesibilitas, performa, perilaku browser, dan arsitektur komponen. Full-stack developer bekerja melintasi antarmuka dan server, biasanya dengan cakupan lebih luas dan kedalaman lebih tipis di kedua ujungnya. Tim yang membangun produk dengan antarmuka berat sering lebih diuntungkan oleh kedalaman frontend; tim yang mengirim fitur dari ujung ke ujung pada permukaan yang kecil sering lebih diuntungkan oleh keluasan full-stack.
- Apakah frontend developer perlu menguasai desain?
- Mereka tidak perlu menghasilkan desain, tetapi perlu membacanya secara kritis â mengenali state yang tidak ada, memahami maksud hierarki dan spacing, serta tahu kapan sebuah interaksi yang dispesifikasikan akan berperilaku buruk di perangkat nyata. Frontend engineer yang mampu berdiskusi substantif dengan desainer menghasilkan antarmuka yang terasa jelas lebih baik dibanding mereka yang mengimplementasikan persis apa yang diberikan.
- Seberapa penting pengalaman framework saat memilih kandidat?
- Tidak sepenting kelihatannya. Engineer dengan fondasi kuat pada state, rendering, aksesibilitas, dan perilaku browser umumnya menjadi produktif di framework asing dalam hitungan minggu, karena konsep dasarnya berpindah. Pengetahuan spesifik framework adalah hal yang paling mudah diuji sekaligus termasuk yang paling lemah memprediksi kontribusi jangka panjang â walau bobotnya lebih besar untuk keterlibatan pendek dibanding keterlibatan panjang.
- Tingkat senioritas seperti apa yang dibutuhkan sebuah tim untuk pekerjaan frontend?
- Bergantung pada apa yang belum diputuskan. Pekerjaan dengan arsitektur yang sudah mapan dan design system yang terdokumentasi bisa dikerjakan dengan baik di level menengah. Pekerjaan yang menuntut penetapan arsitektur komponen, pemilihan strategi rendering, atau memimpin migrasi membutuhkan orang yang pernah menanggung konsekuensi keputusan semacam itu, karena ongkos salah memilih baru terasa berbulan-bulan kemudian.
- Apakah pekerjaan aksesibilitas merupakan spesialisasi terpisah?
- Sebagiannya memang ya â pola ARIA yang rumit dan pengujian dengan assistive technology terbantu oleh spesialis. Tetapi mayoritas cacat aksesibilitas justru lahir dari keputusan biasa yang diambil tanpa memikirkan aksesibilitas: markup yang tidak semantik, fokus yang tidak dikelola, kontras yang kurang, keyboard trap. Semua itu pekerjaan sehari-hari seorang frontend developer yang kompeten, bukan disiplin terpisah, dan menganggap aksesibilitas sebagai urusan orang lain justru itulah yang menciptakan tumpukan pekerjaannya sejak awal.
- Kapan sebuah tim membutuhkan lebih dari satu frontend developer?
- Biasanya ketika antarmuka punya lebih dari satu permukaan independen yang sedang aktif dikembangkan, atau ketika sebuah migrasi harus berjalan berdampingan dengan pengiriman fitur. Satu frontend developer yang menopang beberapa tim produk cenderung menjadi bottleneck sekaligus titik tunggal pengetahuan, dan risiko itu tumbuh tanpa bersuara.
- Bagaimana frontend developer bekerja bersama tim engineering yang sudah ada?
- Dalam model penambahan kapasitas tim engineering, mereka bekerja di dalam alur kerja engineering Anda â standar Anda, proses review Anda, arsitektur Anda, dan prioritas sprint Anda. Anda yang mengarahkan pekerjaan sehari-hari. Talent.ID menangani hubungan kerja, payroll, dan benefit karyawan.
Tell us what your team needs
Describe the gap â the work, the stack, the way your team runs â and we will tell you what we can support. If it is not something we can help with, we will say so.