10 Pertanyaan Wawancara Yang Harus Diketahui Bagi Setiap JavaScript Developer
Di mayoritas perusahaan, manajemen harus mempercayai pengembang untuk memberi interviu teknis buat memandang ketrampilan calon. Bila Anda melakukan secara baik sebagai calon, pada akhirannya Anda wajib melakukan interviu. Ini triknya.
Ini Diawali Dengan Orang
Dalam "Langkah Membuat Team Peningkatan Berkecepatan Tinggi", saya membuat beberapa poin yang penting diulang:
"Tidak ada yang meramalkan hasil usaha lebih bagus dibanding team yang hebat. Bila Anda ingin menaklukkan kesempatan, Anda perlu melakukan investasi di sini, pertama."
Sama seperti yang disebutkan Marcus Lemonis, konsentrasilah pada 3 P:
"Orang, Proses, Produk"
Perekrutan awalnya Anda sebaiknya calon tingkat senior yang paling kuat. Beberapa orang yang bisa mengaryakan dan menuntun pengembang lain, dan menolong pengembang tingkat lanjut dan junior yang pada akhirannya ingin Anda karyakan.
Baca "Kenapa Mengaryakan Benar-benar Susah di Sektor Tehnologi" untuk pemerincian yang bagus mengenai beberapa hal umum yang bisa dan jangan dilaksanakan dalam penilaian calon.
Langkah terbaik untuk menilai calon ialah latihan pemrograman berpasangan.
Kenakan program dengan calon. Diamkan calon yang berkendara. Melihat dan dengarkan lebih dari Anda bicara. Project yang baik kemungkinan menarik tweet dari Twitter API dan tampilkannya di timeline.
Yang menjelaskan, tidak ada satu latihan juga yang hendak memberitahu Anda semuanya yang perlu Anda kenali. Interviu dapat menjadi alat yang paling bermanfaat, tapi tidak boleh percuma untuk menanyakan mengenai sintaksis atau fenomena bahasa. Anda perlu menyaksikan deskripsi besarnya. Tanya mengenai arsitektur dan pola — keputusan besar yang bisa berpengaruh besar pada keseluruhnya project.
Sintaks dan feature gampang untuk Google. lebih susah untuk Google untuk kebijakan eksperimen piranti lunak atau pola dan idiom umum yang diambil pengembang JavaScript dengan pengalaman.
JavaScript spesial, dan mainkan peranan utama di nyaris tiap program besar. Ada apakah dengan JavaScript yang membuat benar-benar berlainan dari bahasa lain?
Berikut beberapa pertanyaan yang hendak menolong Anda menelusuri beberapa hal yang betul-betul penting:
1. Dapatkah Anda mengatakan dua pola pemrograman yang perlu untuk pengembang program JavaScript?
JavaScript ialah bahasa multi-paradigma, memberikan dukungan pemrograman imperatif/prosedural bersama dengan OOP (Pemrograman Fokus Object) dan pemrograman fungsional. JavaScript memberikan dukungan OOP dengan pewarisan arketipe.
Senang dengarnya:
- Pewarisan arketipe (: arketipe, OLOO).
- Pemrograman fungsional (: penutupan, peranan kelas satu, lambda).
Bendera merah:
- Tidak paham apakah itu pola, tidak mengatakan arketipe oo atau pemrograman fungsional.
Belajarlah kembali:
- Dua Pilar JavaScript Sisi 1 — Prototypal OO.
- Dua Pilar JavaScript Sisi 2 — Pemrograman Fungsional.
2. Apakah itu pemrograman fungsional?
Pemrograman fungsional hasilkan program dengan membuat peranan matematika dan menghindar status bersama dan data yang bisa diganti. Lisp (ditetapkan di tahun 1958) adalah bahasa pertama kali yang memberikan dukungan pemrograman fungsional, dan benar-benar di inspirasi oleh kalkulus lambda. Lisp dan banyak bahasa keluarga Lisp masih umum dipakai sekarang ini.
Pemrograman fungsional ialah ide penting dalam JavaScript (salah satunya dari 2 pilar JavaScript). Beberapa utilitas fungsional umum dipertambah ke JavaScript di ES5.
Senang dengarnya:
- Peranan murni / kemurnian peranan.
- Jauhi efek.
- Formasi peranan simpel.
- Contoh bahasa fungsional: Lisp, ML, Haskell, Erlang, Clojure, Elm, F Sharp, OCaml, dll…
- Sebut feature yang memberikan dukungan FP: peranan kelas satu, peranan tingkat tinggi, peranan sebagai argument/nilai.
Bendera merah:
- Tidak mengatakan peranan murni / menghindar efek.
- Tidak bisa memberi contoh bahasa pemrograman fungsional.
- Tidak bisa mengenali feature JavaScript yang aktifkan FP.
Belajarlah kembali:
- Dua Pilar JavaScript Sisi 2.
- Dao Kekekalan.
- Parangkat Lunak Penulisan.
- Sekolah Musik Haskell.
3. Apakah bedanya pewarisan klasik dan pewarisan prototipe?
Peninggalan Kelas: instance mewariskan dari kelas (seperti bikin biru — deskripsi kelas), dan membuat jalinan sub-kelas: taksonomi kelas hierarkis. Instance umumnya dibikin instance-nya lewat peranan konstruktor dalam kata kunci `new`. Peninggalan kelas kemungkinan atau tidak memakai keyword `class` dari ES6.
Prototypal Inheritance: instance mewariskan langsung dari object lain. Instance umumnya dibikin instance-nya lewat peranan pabrik atau `Object.create()`. Instance bisa terbagi dalam banyak object berlainan, memungkinkannya pewarisan selective yang gampang.
Dalam JavaScript, pewarisan arketipe lebih simpel dan lebih fleksibel dibanding pewarisan kelas.
Suka dengarnya:
- Kelas: buat kopling ketat atau hierarki/taksonomi.
- Arketipe: mengatakan pewarisan kombinasi, delegasi arketipe, pewarisan fungsional, formasi object.
Bendera merah:
- Tidak ada opsi untuk pewarisan dan formasi arketipe dibanding pewarisan kelas.
Belajarlah kembali:
- Dua Pilar JavaScript Sisi 1 — Prototypal OO.
- Salah paham Umum Mengenai Peninggalan dalam JavaScript.
4. Apa kekurangan dan kelebihan pemrograman fungsional vs pemrograman berorientasi object?
Kelebihan OOP: Benar-benar gampang untuk pahami ide dasar object dan gampang untuk menginterpretasikan arti panggilan sistem. OOP cenderung memakai style imperatif dibanding style deklaratif, yang bisa dibaca seperti rangkaian perintah langsung untuk dituruti oleh komputer.
OOP Cons: OOP Umumnya bergantung pada status bersama. Object dan sikap umumnya digabungkan pada substansi yang serupa, yang bisa dijangkau secara random oleh beberapa peranan dengan posisi non-deterministik, yang bisa mengakibatkan sikap yang tidak diharapkan seperti keadaan ras.
Kelebihan FP: Dengan memakai pola fungsional, pemrogram menghindar kondisi bersama atau mungkin efek apa saja, yang hilangkan bug yang disebabkan karena fungsi-fungsi yang berkompetisi untuk sumber daya yang serupa. Dengan feature seperti tersedianya style point-free (alias pemrograman sembunyi-sembunyi), peranan condong disederhanakan secara radikal dan gampang dikomposisi ulangi untuk kode yang umum bisa dipakai kembali dibanding dengan OOP.
FP cenderung menyenangi style deklaratif dan denotasional, yang tidak merinci perintah langkah setiap langkah untuk operasi, namun kebalikannya fokus dari sesuatu yang harus dilaksanakan, biarkan peranan yang memicu mengurusi triknya. Ini tersisa kelonggaran yang hebat untuk refactoring dan optimalisasi performa, bahkan juga memungkinkannya Anda menukar semua algoritma dengan algoritma yang lebih efektif dengan sedikit peralihan kode. (mis., memoize, atau pakai penilaian malas bukannya penilaian yang semangat.)
Komputasi yang manfaatkan peranan murni gampang untuk diskalakan di sejumlah prosesor, atau di semua kluster komputasi terbagi tanpa takut akan perselisihan sumber daya threading, keadaan ras, dll…
Kekurangan FP: Eksplorasi feature FP yang terlalu berlebih seperti style point-free dan formasi yang besar mempunyai potensi kurangi keterbacaan karena kode yang dibuat sering ditetapkan lebih abstrak, lebih singkat, dan kurang nyata.
Lebih beberapa orang yang dekat dengan OO dan pemrograman imperatif dibanding pemrograman fungsional, hingga bahkan juga idiom umum dalam pemrograman fungsional bisa memusingkan anggota team baru.
FP mempunyai kurva belajar yang lebih terjal dibanding OOP karena reputasi OOP yang luas sudah memungkinkannya bahasa dan materi evaluasi OOP jadi lebih pembicaraan, dan bahasa FP cenderung lebih akademik dan resmi. Ide FP kerap dicatat mengenai pemakaian idiom dan notasi dari kalkulus lambda, aljabar, dan teori kelompok, yang semua memerlukan dasar pengetahuan awalnya dalam domain itu untuk dimengerti.
Suka dengarnya:
- Sebut permasalahan dengan status bersama, beberapa hal berlainan yang berkompetisi untuk sumber daya yang serupa, dll…
- Kesadaran akan kekuatan FP untuk sederhanakan banyak program secara radikal.
- Kesadaran akan ketidaksamaan kurva belajar.
- Artikulasi efek dan bagaimana dampaknya pada perawatan program.
- Kesadaran jika pangkalan kode yang paling fungsional bisa mempunyai kurva belajar yang terjal.
- Kesadaran jika pangkalan kode OOP yang tinggi dapat benar-benar tahan pada peralihan dan benar-benar rapuh dibanding dengan pangkalan kode FP yang sama dengan.
- Kesadaran jika kekekalan munculkan kisah status program yang paling gampang dijangkau dan bisa ditempa, memungkinkannya tambahan feature yang gampang seperti undo/redo tidak terbatas, rewind/replay, debugging perjalanan waktu, dan lain-lain. Kekekalan bisa diraih dalam salah satunya pola, tapi proliferasi object stateful bersama memperumit implikasi di OOP.
Bendera merah:
- Tidak bisa membuat daftar rugi dari 1 style atau yang lain — Siapa saja yang eksper dengan salah satunya style semestinya hadapi beberapa kebatasan.
Belajarlah kembali:
- Dua Pilar JavaScript Sisi 1 — Prototypal OO.
- Dua Pilar JavaScript Sisi 2 — Pemrograman Fungsional.
5. Kapan pewarisan classic jadi opsi yang pas?
Jawabnya tak pernah, atau nyaris tak pernah. Tentunya tak pernah lebih satu tingkat. Hirarki kelas multi-level ialah anti-pola. Saya sudah keluarkan rintangan ini sepanjang tahun, dan salah satu jawaban yang sempat saya dengar adalah dari beberapa salah paham umum. Seringkali, rintangan ditemui dengan diam.
“Kalau fitur kadang berguna dan terkadang berbahaya dan jika ada pilihan yang lebih baik maka selalu gunakan pilihan yang lebih baik.” ~Douglas Crockford
Senang mendengarnya:
-
Jarang-jarang, nyaris tak pernah, atau mungkin tidak pernah.
Satu tingkat kadang OK, dari kelas dasar frame-work seperti
React.Component. - "Memberikan dukungan formasi object dibanding pewarisan kelas."
Belajarlah kembali:
- Dua Pilar JavaScript Sisi 1 — Prototypal OO.
- Object JS — Mewariskan Kerusuhan.
6. Kapan pewarisan arketipe sebagai opsi yang pas?
Ada lebih satu tipe pewarisan arketipe:
- Delegasi (yakni, rantai arketipe).
- Penyatuan (yakni mixin, `Object.assign()`).
- Fungsional (Janganlah bingung dengan pemrograman fungsional. Peranan yang dipakai untuk membikin penutupan untuk kondisi/enkapsulasi individu).
Tiap tipe pewarisan arketipe mempunyai kelompok kasus pemakaiannya sendiri, tapi semua sama bermanfaat dalam kekuatannya untuk aktifkan formasi, yang membuat jalinan has-a atau use-a atau can-do sebagai musuh dari jalinan is-a dibikin dengan pewarisan kelas.
Suka dengarnya:
- Pada kondisi di mana modul atau pemrograman fungsional tidak memberi jalan keluar yang terang.
- Saat Anda perlu membuat object dari beragam sumber.
- Kapan pun Anda memerlukan peninggalan.
Bendera merah:
- Tidak ada pengetahuan mengenai kapan harus memakai arketipe.
- Tidak ada kesadaran akan mixin atau `Object.assign()`.
Belajarlah kembali:
- "Pemrograman Program JavaScript": sisi Arketipe.
7. Apakah yang dimaksud dengan "memberikan dukungan formasi object dibanding pewarisan kelas"?
Ini ialah cuplikan dari "Skema Design: Komponen Piranti Lunak Fokus Object yang Bisa Dipakai Kembali". Ini memiliki arti jika pemakaian kembali code harus diraih dengan membuat unit fungsionalitas yang lebih kecil jadi object baru bukannya mewariskan dari kelas dan membuat taksonomi object.
Dalam kata lain, pakai jalinan can-do, has-a, atau use-a, bukan jalinan is-a.
.Suka dengarnya:
- Jauhi hierarki kelas.
- Jauhi permasalahan kelas dasar yang ringkih.
- Jauhi kopling yang ketat.
- Jauhi taksonomi yang kaku (mau tak mau ialah jalinan yang pada akhirannya salah untuk kasus pemakaian baru).
- Jauhi permasalahan pisang gorila ("yang Anda harapkan ialah pisang, yang Anda peroleh ialah gorila yang menggenggam pisang, dan semua rimba").
- Membuat kode lebih fleksibel.
Bendera merah:
- Tidak berhasil mengatakan salah satunya permasalahan di atas.
- Tidak berhasil melafalkan ketidaksamaan di antara formasi dan pewarisan kelas, atau keunggulan formasi.
8. Apakah itu pengikatan data dua arah dan saluran data satu arah, dan apakah bedanya?
Pengikatan data dua arah memiliki arti sektor UI terlilit ke data mode secara aktif hingga saat sektor UI berbeda, data mode turut berbeda dan kebalikannya.
Saluran data satu arah memiliki arti jika mode ialah salah satu sumber kebenaran. Peralihan di UI memacu pesan yang mengisyaratkan tujuan pemakai ke mode (atau "simpan" di React). Cuma mode yang mempunyai akses untuk mengganti status program. Dampaknya ialah data selalu mengucur pada sebuah arah, yang membuat lebih gampang dimengerti.
Saluran data satu arah memiliki sifat deterministik, dan pengikatan dua arah bisa mengakibatkan efek yang lebih susah untuk dituruti dan dimengerti.
Suka dengarnya:
- React ialah contoh kanonis baru dari saluran data satu arah, menjadi penyebutan React ialah signal yang baik. Cycle.js ialah implikasi saluran data uni-directional terkenal yang lain.
- Angular ialah rangka kerja terkenal yang memakai pengikatan dua arah.
Bendera merah:
- Tidak ada pengetahuan mengenai apakah arti. Tidak bisa melafalkan ketidaksamaan.
9. Apa kontra dan pro arsitektur monolitik versus service micro?
Arsitektur monolitik memiliki arti program Anda dicatat sebagai satu unit kohesif kode yang komponennya direncanakan untuk bekerja bersama, berbagi ruangan memory dan sumber daya yang serupa.
Arsitektur service micro memiliki arti jika program Anda terbagi dalam banyak program mandiri yang lebih kecil yang sanggup berjalan pada ruangan memorinya sendiri dan menskalakan secara mandiri keduanya di beberapa mesin yang mempunyai potensi terpisah.
Kelebihan Monolitik: Keuntungan khusus dari arsitektur monolitik ialah mayoritas program umumnya mempunyai sebagian besar permasalahan lintasi sectoral, seperti logging, limitasi kecepatan, dan feature keamanan seperti lajur audit dan pelindungan DOS.
Saat semua jalan lewat program yang serupa, gampang untuk menyambungkan elemen ke permasalahan lintasi bidang itu.
Ada pula keuntungan performa, karena akses memory bersama bisa lebih cepat dibanding komunikasi antara proses (IPC).
Melawan monolitik: Service program monolitik cenderung dipadukan dan terlilit kuat saat program berkembang, hingga susah untuk menutup service untuk maksud seperti pemetaan mandiri atau perawatan kode.
Arsitektur monolitik lebih susah untuk dimengerti, mungkin karena ada keterikatan, efek, dan fenomena yang tidak kelihatan saat Anda menyaksikan service atau pengatur tertentu.
Pro service micro: Arsitektur service micro umumnya ditata dengan lebih bagus, karena tiap service micro mempunyai tugas yang paling detil, dan tidak berkaitan dengan tugas elemen lain. Service yang dipisah lebih gampang diatur ulangi dan dikonfigurasi ulangi untuk layani arah program yang lain (misalkan, layani client situs dan API khalayak).
Mereka dapat mempunyai keunggulan performa bergantung pada bagaimana mereka ditata karena memungkinkannya untuk menutup service panas dan menskalakannya secara mandiri dari program yang lain.
Melawan service micro: Saat Anda membuat arsitektur service micro baru, Anda kemungkinan mendapati banyak permasalahan lintasi sectoral yang tidak Anda mengantisipasi di saat design. Program monolitik bisa membuat pembantu sulap atau middleware bersama untuk tangani permasalahan lintasi sectoral semacam itu tanpa banyak usaha.
Dalam arsitektur layanan-mikro, Anda perlu keluarkan dana tambahan dari modul terpisah untuk tiap permasalahan lintasi sectoral, atau meringkas permasalahan lintasi sectoral di susunan service yang lain dilewati oleh semua jalan raya.
Pada akhirnya, bahkan juga arsitektur monolitik cenderung merutekan jalan raya lewat susunan service luar untuk permasalahan lintasi sectoral, tapi dengan arsitektur monolitik, kemungkinan untuk tunda ongkos tugas itu sampai project lebih masak.
Service micro kerap dipakai pada mesin atau tempat virtual mereka sendiri, mengakibatkan proliferasi tugas konflik VM. Beberapa tugas ini kerap diotomatisasi dengan alat management armada container.
Suka dengarnya:
- Sikap positif pada service micro, walau ongkos awalnya semakin tinggi versus program monolitik. Sadar jika service micro cenderung bekerja dan menskalakan lebih bagus dalam periode panjang.
- Ringkas mengenai service micro versus program monolitik. Atur program hingga service tidak tergantung keduanya di tingkat code, tapi gampang dipadukan bersama sebagai program monolitik pada awal. Ongkos overhead service micro bisa diundur sampai jadi lebih ringkas untuk bayar harga.
Bendera merah:
- Tidak mengetahui ketidaksamaan di antara arsitektur monolitik dan service micro.
- Tidak ketahui atau mungkin tidak ringkas mengenai overhead tambahan dari service micro.
- Tidak ketahui overhead performa tambahan yang disebabkan karena IPC dan komunikasi jaringan untuk service micro.
- Terlampau negatif mengenai kekurangan service micro. Tidak bisa melafalkan langkah untuk pisahkan program monolitik hingga gampang dibagi jadi service micro saat waktunya datang.
- Menyepelekan keunggulan service micro yang bisa diskalakan secara mandiri.
10. Apakah itu pemrograman asinkron, dan kenapa itu wajib dalam JavaScript?
Pemrograman sesuai memiliki arti jika, terkecuali panggilan keadaanonal dan peranan, kode dilakukan secara berurut di atas ke bawah, memblok pekerjaan yang jalan lama seperti keinginan jaringan dan disk I/O.
Pemrograman asinkron memiliki arti jika mesin bekerja dalam loop kejadian. Saat operasi penutupan dibutuhkan, keinginan diawali, dan kode terus jalan tanpa memblok hasilnya. Saat tanggapan siap, interupsi dipacu, yang mengakibatkan moment handler digerakkan, di mana saluran kontrol bersambung. Dengan langkah ini, satu utas program bisa tangani banyak operasi bertepatan.
Antar-muka pemakai pada intinya asinkron, dan habiskan mayoritas waktunya menanti input pemakai untuk mengusik loop kejadian dan memacu penangan kejadian.
Node asinkron secara standar, maknanya server bekerja secara hampir serupa, menanti pada sebuah lingkaran untuk keinginan jaringan, dan terima semakin banyak keinginan masuk saat keinginan pertama sedang diatasi.
Ini penting dalam JavaScript, karena benar-benar pas untuk code antar-muka pemakai, dan benar-benar berguna untuk performa di server.
Suka dengarnya:
- Pengetahuan mengenai apakah arti penutupan, dan implementasi performa.
- Pengetahuan mengenai pengatasan acara, dan kenapa penting untuk kode UI.
Bendera merah:
- Tidak akrab dengan istilah asinkron atau sesuai.
- Tidak bisa melafalkan implementasi performa atau jalinan di antara code asinkron dan code UI.
Ringkasan
Masih tetap berdasar pada topik tingkat tinggi. Bila mereka bisa menjawab beberapa pertanyaan ini, itu umumnya memiliki arti jika mereka mempunyai pengalaman pemrograman yang cukup buat pahami fenomena bahasa dan sintaksis dalam beberapa minggu, bahkan juga bila mereka tidak banyak memiliki pengalaman JavaScript.
Tidak boleh mendiskualifikasi calon berdasar beberapa hal yang gampang didalami (terhitung algoritma CS-101 classic, atau tipe permasalahan teka-teki apa saja).
Yang betul-betul perlu Anda pahami ialah, "apakah calon ini memahami cara membuat lamaran?"
Itu untuk interview secara lisan.