Orang-orang yang Muak dengan Wawancara ala LeetCode
(nelson.cloud)- Setelah keluar dari Robinhood pada akhir November 2023 karena masalah kesehatan dan menjalani beberapa proses rekrutmen, penulis merasa bahwa evaluasi ala LeetCode tidak selaras dengan pekerjaan software engineering yang sebenarnya
- Banyak perusahaan terlihat meniru cara perusahaan teknologi besar seperti Google, Facebook/Meta, dan Amazon, sehingga wawancara serupa terus berulang
- Penulis mengkritik bahwa meski para engineer mengatakan tidak perlu menghafal pengetahuan yang bisa dicari, dalam wawancara mereka justru menanyakan pengetahuan yang bisa dicari seperti kuis, padahal sulit diingat spontan
- Penulis pernah mengalami sukses dan gagal dalam wawancara seperti ini, dan dasar ketidakpuasannya lebih dekat pada pengalaman kerja nyata sebelumnya daripada pengalaman gagal
- Penulis menambahkan bahwa perusahaan yang mencari engineer berpengalaman dengan AWS, Kubernetes, dan Ruby on Rails serta tidak melakukan kuis yang tidak berguna boleh menghubunginya
Titik Ketidakselarasan Wawancara ala LeetCode dengan Pekerjaan Nyata
- Setelah keluar dari Robinhood pada akhir November 2023 karena alasan kesehatan, penulis menjalani wawancara dengan beberapa perusahaan
- Proses rekrutmen tidak berlanjut karena berbagai alasan, tetapi penulis merasa lelah dengan wawancara gaya LeetCode yang berulang
- Wawancara seperti ini dinilai tidak cukup mencerminkan tanggung jawab software engineering yang sebenarnya
- Banyak perusahaan tampaknya mengadopsi metode evaluasi yang sama hanya karena itulah cara yang dipakai perusahaan besar seperti Google, Facebook/Meta, dan Amazon
Benturan antara Evaluasi Berbentuk Kuis dan Pengalaman Kerja Nyata
- Ada engineer yang dalam keseharian mengatakan bahwa pengetahuan yang mudah ditemukan lewat Google tidak perlu dihafal
- Namun dalam wawancara, terkadang mereka menanyakan hal-hal yang bisa diketahui dengan mencari, tetapi sulit diingat seketika, sehingga terasa kontradiktif
- Tidak ada solusi yang jelas untuk masalah ini, tetapi masalahnya sendiri dianggap nyata
- Penulis pernah mengalami sukses dan gagal dalam jenis wawancara ini, dan pandangan ini lebih banyak dipengaruhi oleh pengalaman profesional sebelumnya daripada tingkat kegagalan
- Jika ada perusahaan yang membutuhkan software engineer dengan pengalaman AWS, Kubernetes, dan Ruby on Rails serta tidak melakukan wawancara berbentuk kuis, penulis mengatakan mereka boleh menghubunginya
- Sebagai bacaan terkait, penulis menyertakan Re-imagining Technical Interviews: Valuing Experience Over Exam Skills
1 komentar
Opini di Hacker News
Saya memahami rasa frustrasinya, tetapi pada akhirnya wawancara seperti ini juga punya tujuan. Meski tidak sempurna, cukup bisa dipakai, dan biasanya menghasilkan lebih banyak negatif palsu daripada positif palsu, jadi dari sudut pandang perusahaan ini masuk akal
Biaya ketika orang pintar gagal lolos itu rendah, tetapi jika merekrut orang yang salah, perusahaan harus menghabiskan berbulan-bulan untuk memverifikasi, memecat, lalu merekrut lagi, sehingga biayanya besar. Namun bagi kandidat, ini proses yang sangat menyakitkan, dan bahkan software engineer yang hebat pun bisa gugup, melewatkan sesuatu, atau mengalami hari sial sehingga bisa gagal beberapa kali. Wawancara bukan penilaian akhir atas nilai hidup seseorang, melainkan hanya alat yang tumpul, jadi sebaiknya dilewati saja
Pertanyaan “jebakan” itu bodoh, tetapi kita perlu melihat apakah kandidat memahami dasar-dasarnya sekaligus menunjukkan seperti apa perusahaan kita. Misalnya, bertanya “apakah boleh memodifikasi argumen?” atau mengatakan “saya tidak ingat apakah strlen menyertakan byte 0, jadi saya akan menambahkan 1; biasanya saya akan mencarinya” adalah sinyal bagus. Soalnya berada di tingkat seperti atoi atau “mengocok satu set kartu”: mendasar, tetapi tidak benar-benar sepele seperti fizzbuzz. Salah satu orang terbaik yang pernah kami rekrut membuat kesalahan mendasar, tetapi ketika ditanya apakah itu akan bekerja sesuai maksudnya, ia berkata “saya ini bodoh sekali ya” lalu langsung memperbaikinya. Gaya bicara seperti itu mungkin tidak tepat dalam wawancara, tetapi kami melihatnya sebagai sinyal positif yang kuat. Sebaliknya, ada juga kandidat yang terus bersikeras bahwa pertanyaan untuk mem-parse string dan mengembalikan integer itu tidak adil karena sudah ada fungsi library, padahal sebagian sistem kami memang berjalan di lingkungan embedded tanpa library
Saya berharap mereka tidak meniru cara buruk ujian di sekolah dan universitas yang lebih dulu menguji daya ingat. Saya sangat kesulitan karena tidak bisa langsung mengingat sesuatu saat dibutuhkan, dan saya yakin bukan hanya saya. Saat mewawancarai developer Android, saya mengajukan pertanyaan dan melihat cara mereka berpikir, bukan mengharapkan semua jawaban tepat. Setelah melihat apakah mereka punya pemahaman dasar tentang Android, saya meminta mereka membuat aplikasi kecil di rumah
Pada akhirnya, dalam proses rekrutmen yang harus mengisi posisi, semakin banyak negatif palsu, semakin tinggi pula kemungkinan merekrut positif palsu. Dalam kasus ekstrem, jika di seluruh dunia hanya ada satu orang yang cocok untuk pekerjaan itu dan orang tersebut tersingkir sebagai negatif palsu, satu-satunya pilihan yang tersisa adalah merekrut orang yang salah
Masalahnya bukan kurangnya kecerdasan, melainkan orang itu bisa memecahkan soal algoritma dengan baik tetapi bukan software engineer, atau kurang memiliki kemampuan yang dibutuhkan posisi tersebut. Saya bekerja di tim yang banyak merekrut lewat wawancara jenis puzzle; semua orang pintar, tetapi mereka bukan software engineer, dan perbedaannya sangat terlihat
Jika seseorang berhasil menyelesaikannya, jauh lebih mungkin ia pernah melihat soal yang sama atau mirip saat mengerjakan latihan, daripada benar-benar menurunkan solusi optimal baru
Saya pernah menjalani wawancara yang cukup saya sukai; itu di sebuah bank. Mereka memberi kode berantakan yang ditulis tergesa-gesa, tetapi bukan sengaja dibuat obfuscated, lalu meminta saya me-refactor sebaik mungkin
Pewawancara duduk di sebelah saya dan berdiskusi sepanjang proses, sehingga pada dasarnya terasa seperti pair programming yang dipimpin kandidat. Setelah serangkaian wawancara LeetCode, itu terasa menyegarkan. Tentu saja, bank itu tahu persis teknologi yang mereka gunakan dan tidak terlalu perlu mengukur kemampuan mempelajari teknologi baru, jadi pendekatan seperti itu memungkinkan. Bagi mereka, yang lebih penting adalah apakah kandidat bisa membuat kode yang maintainable, memberi nama dengan tepat, dan berkomunikasi dengan rekan kerja
Yang menarik, ada orang yang hampir gagal di pertanyaan dasar tetapi tampil sangat baik di code review sampai keahlian mendalamnya terlihat. Wawancara adalah alat yang cukup buruk untuk menunjukkan kemampuan kerja seseorang, tetapi jika kandidat bisa melihat masalah secara luas maupun sempit dan juga mampu menulis kode dengan cukup baik, biasanya saya anggap berhasil
Wawancara gaya LeetCode mungkin menjalankan dua fungsi. Pertama, menjadi alat untuk menekan upah dan mobilitas kerja software engineer. Untuk pindah kerja, orang harus belajar satu-dua bulan; siapa yang akan mudah pindah?
Kalau sial bertemu pewawancara yang sudah menyiapkan diri dengan serius lalu melempar bom setingkat LeetCode hard, sulit untuk melamar lagi ke perusahaan itu selama setahun. Kedua, ini menjadi alat untuk menutupi bias dalam proses, sambil mengklaim bahwa semua orang diberi tujuan yang serupa dan jelas. Jika kandidat berasal dari sekolah, gender, atau ras yang sama, meski diberi soal yang sama, pewawancara bisa memberi petunjuk, memaklumi kesalahan sintaks, dan memberi keputusan rekrutmen yang kuat atas dasar “komunikasi” meski kandidat tidak menemukan pendekatan optimal. Kalau kandidatnya tidak disukai, cukup berikan soal sulit dan diam sepanjang wawancara. Bagi perusahaan itu noise yang masih bisa diterima, tetapi bagi individu itu berarti kehilangan peluang kompensasi ratusan ribu dolar. Saya pernah menjalani wawancara FAANG dan juga menjadi pewawancara; saya melihat orang-orang direkrut dengan standar rendah, sementara engineer hebat kehilangan kesempatan karena pertanyaan konyol seperti quadtree atau teori bilangan
Dengan asumsi pewawancaranya adil, metode ini memberi kandidat yang tidak punya nama terkenal di resume kesempatan untuk menunjukkan kemampuan. Sebagian peluang yang saya dapatkan sebagai orang tanpa gelar ilmu komputer tidak akan pernah ada kalau bukan karena wawancara whiteboard. Sulit membayangkan cara untuk mencegah pewawancara yang sengaja membalik prosedur demi merekrut temannya
Banyak perusahaan punya bank soal yang dirancang agar adil dan sampai taraf tertentu terkait dengan masalah nyata. Perusahaan-perusahaan tempat saya wawancara umumnya juga begitu; meski bukan persis soal LeetCode, pada akhirnya tetap soal coding yang terisolasi, jadi saya menganggapnya gaya LeetCode. Wawancara di perusahaan yang menjalankan metode ini dengan baik terasa cukup baik. Perusahaan dan pewawancara yang bagus melihat lebih dari sekadar kode akhir, dan juga memberi rating rekrutmen dalam skala sehingga mengurangi keputusan biner
Secara realistis, fizzbuzz saja sudah menyaring 75%. Banyak orang tidak bisa menulis kode saat berada di bawah tekanan, dan ada juga yang bertahan dengan memaksa lewat copy-paste. Bukan berarti orang-orang seperti ini tidak bisa mengerjakan apa pun, tetapi mereka lambat, menghasilkan abstraksi yang aneh, dan memakan banyak waktu sampai hasilnya layak dipakai. Dan karena bagi mereka juga ada puluhan atau ratusan ribu dolar yang dipertaruhkan, mereka akan membantah dengan cara yang sama
Dari sudut pandang perusahaan, itu masuk akal. Mereka menginginkan karyawan yang tidak terdistraksi dan bisa lembur
Ada banyak kritik yang valid terhadap praktik rekrutmen teknologi saat ini, tetapi keluhan bahwa “tidak bisa menjadi sangat kaya tanpa menjual jiwa” tidak terlalu meyakinkan
Saat menyeleksi software engineer, yang penting bukan pengetahuan, melainkan kemampuan memecahkan masalah dan kemampuan membangun model mental dari masalah
Jika kandidat belum pernah melihat masalah itu sebelumnya dan pewawancara memahami apa yang harus diamati, wawancara whiteboard adalah cara yang baik untuk menilai kemampuan ini. Namun seperti Hukum Goodhart, ketika ukuran menjadi target, ukuran itu tidak lagi menjadi indikator yang baik. Orang yang lemah dalam pemecahan masalah atau kemampuan modeling tetap menginginkan pekerjaan software bergaji tinggi, jadi mereka menggiling LeetCode; seiring waktu, ketika orang-orang itu menjadi pewawancara, mereka menjalankan wawancara seperti tes hafalan, sebagaimana dulu mereka diperlakukan. Meski begitu, dengan batasan yang dimiliki perusahaan, kebutuhan mengurangi pemborosan waktu kandidat, dan mempertahankan lembar evaluasi konsisten yang disukai HR, saya belum melihat metode wawancara yang lebih baik diusulkan, dan metode ini tampaknya akan terus dipakai untuk sementara
Itu lebih dekat dengan pekerjaan membuat software. LeetCode terlalu jauh dari pekerjaan nyata, dan performanya juga terlalu lemah korelasinya dengan kecocokan sebenarnya
Embernya bocor, tetapi perusahaan puas dengan keadaan sekarang, dan developer terus menggiling LeetCode. Sepertinya tidak akan segera berubah, tetapi untungnya saat mencari pekerjaan baru saya berada dalam posisi bisa menolak wawancara seperti ini
Seorang teman pernah tiba-tiba berhenti berbicara di tengah wawancara teknis, berdiri, lalu pergi. Orang-orang perusahaan mengejarnya sambil berkata, “Kenapa, Anda melakukannya dengan baik!”, tetapi ia bilang ia menjadi terlalu murung dan tidak tertarik lagi
Ini menyedihkan, padahal bagi kebanyakan orang pekerjaan ini seharusnya menyenangkan
Namun sekitar pertengahan wawancara, whiteboard dikeluarkan dan para calon rekan kerja masuk, lalu meminta saya mengimplementasikan hal-hal dasar dengan spidol. Semakin berjalan, mereka makin bermusuhan dan kasar, sampai terasa seperti perundungan yang diritualkan. Rasanya seperti mereka sedang menguji apakah saya bisa menahan hinaan dan permusuhan sambil menghasilkan sesuatu yang secara teknis sepele. Akhirnya saya menghentikan wawancara dan berkata, “Saya sudah melihat bagaimana kalian bekerja, jadi saya memutuskan tidak ingin bekerja di sini. Terima kasih atas kesempatannya, dan maaf kita saling membuang waktu,” lalu keluar. CEO mengejar saya sampai ke tempat parkir dan bertanya mengapa itu terjadi; ia tampak benar-benar terkejut bahwa kandidat bisa mengambil keputusan di tengah wawancara. Orang-orang lupa bahwa wawancara kerja berjalan dua arah. Sejak hari itu saya sadar bahwa saya berhak melihat setiap sisi dari perusahaan tempat saya mungkin bekerja, dan jika melihat hal negatif dalam prosesnya, saya tidak perlu berkompromi. Keesokan harinya saya bertemu orang-orang di perusahaan pesaing yang sampai sekarang masih menjadi teman baik sekaligus rekan kerja, jadi itu keputusan yang tepat. Pekerjaan ini menyenangkan, tetapi jika kesenangan itu dipanen dan dieksploitasi seperti di ladang, itu tidak berbeda dari bentuk perbudakan lainnya
Ketika saya berkata, “Sepertinya hari ini bukan hari saya, dan saya ingin menghentikan wawancara,” sejak saat itu mereka berusaha cukup keras agar saya tetap tinggal sampai waktu yang tersisa habis. Menurut saya, jika kandidat ingin pergi, mereka harus dibiarkan pergi
Bahkan setelah 5 tahun berlalu, saya masih menolak wawancara seperti ini dan tidak ingin pernah menjalani proses itu lagi. Saya pernah diganggu dan diejek oleh orang-orang yang memperlakukan manusia seperti permainan menendang selama satu jam, dan saya tidak mau berurusan lagi dengan mereka
Karena ada banyak wawancara LeetCode tanpa pemberitahuan sebelumnya, saya menuliskan dengan jelas di profil LinkedIn [1] dan GitHub [2] saya apa yang boleh dan tidak boleh. “Saya memiliki kebijakan pribadi yang menolak segala bentuk live coding atau tes coding online selama wawancara, dan saya tidak menikmati atau berpartisipasi dalam pemrograman kompetitif. Sebagai gantinya, saya dengan senang hati mengerjakan tugas coding offline dengan tujuan dan tenggat yang masuk akal, serta berdiskusi teknis secara mendalam tentang arsitektur dan desain perangkat lunak serta teknologi terkait.”
[1] https://www.linkedin.com/in/mtodor
[2] https://github.com/mihaitodor
Namun, karena ada cerita bahwa kecurangan merajalela dalam wawancara berbasis tugas, saya khawatir jumlah pemberi kerja yang mau memakai cara ini akan turun tajam
Kalau mencoba menjadi devil’s advocate, LeetCode dipakai untuk menyaring salah satu atau keduanya dalam perekrutan individual contributor rata-rata: apakah orang itu pekerja keras, yakni seseorang yang mempelajari banyak soal, menghafal solusi, dan mengulanginya; atau apakah orang itu pintar, yakni seseorang yang tahu dasar-dasarnya dan bisa menyintesis pengetahuan sebelumnya untuk menjawab pertanyaan baru meski tidak mengerjakan LeetCode
Jika tidak ada informasi apa pun, menurut saya orang yang tidak bisa lolos soal LeetCode lebih besar kemungkinannya bukan termasuk salah satu dari dua kategori itu. Untuk peran yang membutuhkan coding, saya pikir kandidat seharusnya bisa menyelesaikan setidaknya satu soal LeetCode easy sampai medium, walau dengan sedikit arahan dari pewawancara. Dalam praktiknya, perusahaan memang menurunkan bobot kemampuan LeetCode ketika kandidat makin senior atau melamar peran yang makin khusus. Ada juga banyak perbaikan bug, system design, wawancara perilaku, tugas, pertanyaan trivia, pertanyaan khusus latar belakang, dan sebagainya; dalam perekrutan di atas level junior, LeetCode bukan segalanya. Itu bukan alat ajaib untuk memilih engineer terbaik, melainkan hanya satu sinyal lagi yang dipakai komite perekrutan
Itu tidak melihat kemampuan engineering untuk mendorong sesuatu sampai selesai dalam batas anggaran. Paling baik, ini hanya hal sampingan; paling buruk, ini adalah indikator proksi untuk diskriminasi usia yang lebih menyukai orang yang mendekati usia 19 tahun. Mungkin itu sebabnya industri ini begitu kesulitan menghasilkan software berkualitas. Cara yang lebih baik adalah memberikan situasi gagal seperti build yang rusak atau kode yang crash, lalu meminta kandidat memperbaikinya. Jika mereka bisa menelusuri sistem, mendiagnosis cacat, menemukan penyebab, mengusulkan patch, dan menyesuaikan gaya coding serta komentar, merekalah pemain yang benar-benar dibutuhkan. Bisa saja ada branch dan issue tracker, diskusi bug mungkin sudah berjalan, dan mungkin ada file patch di komentar yang harus diterapkan secara manual. Patch itu bisa berisi bug baru, atau menjadi umpan yang menyentuh masalah mirip tetapi tidak terkait. Bisa saja itu regresi dari bug yang sudah ditutup tetapi tidak ada unit test, dan kalaupun ada test, kandidat harus menemukannya, atau test itu sendiri sudah usang dan penuh bug. Inilah pekerjaan yang sebenarnya. Setelah selesai, mengatakan “unit test-nya rusak” dan mengatakan “saya tidak memahami cara menjalankannya dengan benar, jadi saya melewatinya” menunjukkan perbedaan sikap yang besar, dan team player adalah yang kedua
Jadi sebaliknya, Anda bisa saja mendapatkan kandidat yang tidak berprestasi luar biasa di perannya saat ini, tetapi menghabiskan energi sisanya untuk menggiling LeetCode
Dengan hanya beberapa minggu mengerjakan proyek, orang pintar bisa mendapatkan insight yang benar-benar diperlukan. Puzzle mendadak yang dilempar LeetCode lebih mirip teka-teki silang di majalah lama
Satu-satunya alasan seseorang bisa melakukannya adalah karena pernah mempelajarinya sebelumnya
Kalau ini tahun 2022, saya akan setuju bahwa LeetCode bukan alat untuk memilih engineer terbaik, tetapi pada 2024, orang makin sering disaring keluar meski menjawab benar, karena tidak cukup cepat atau tidak bisa menyelesaikan tanpa petunjuk. Saya bukan jenius LeetCode, terlalu banyak hal yang harus dipelajari, dan porsi LeetCode dalam wawancara sekitar 20%, tetapi saya tidak merasa itu jauh lebih buruk dibanding dua tahun lalu. Ekspektasi perusahaan saja yang melesat setinggi langit, dan suasananya seperti mereka ingin membeli peran dengan pengalaman 15 tahun lebih memakai gaji orang dengan 5 tahun pengalaman
Hal menarik yang jarang disebut tentang wawancara ala LeetCode adalah bahwa ini semacam ritual perpeloncoan intelektual
Sudah berkali-kali terbukti bahwa semakin keras ritual masuknya, semakin besar komitmen orang-orang yang berhasil masuk ke kelompok itu
Ketika perusahaan kapitalis merekrut programmer, mana yang lebih baik: “orang-orang pintar yang mirip satu sama lain dan percaya pada jawaban benar” atau “sekumpulan orang terampil yang tercampur acak”? Jika Anda menjawab yang kedua, Anda idealistis, dan pendapat seperti itu sebenarnya tidak penting. Alam akan menggantikannya dengan orang yang lebih pintar dan realistis
Dalam beberapa wawancara terakhir, kami menunjukkan contoh kode kepada kandidat dan meminta mereka meninjaunya. Di dalam contoh itu, setiap baris berisi setidaknya satu bug atau masalah
Setelah itu ada tugas pemodelan, biasanya dilakukan di whiteboard. Ada juga latihan sederhana ala fizzbuzz untuk melihat apakah junior benar-benar bisa menjalankan peran junior, dan dijadikan pijakan untuk membuka percakapan tentang topik seperti kompleksitas waktu eksekusi atau layout memori. Prosesnya berjalan sangat interaktif sesuai performa kandidat, dengan tujuan menyaring kandidat palsu yang entah bagaimana berhasil lolos screening, sekaligus sedikit merasakan kecocokan budaya
Saya membuat masalah yang berantakan seperti validasi zona waktu atau nomor telepon, dan menjadikan dokumen Wikipedia sebagai spesifikasi. Setelah selesai, saya menanyakan solusinya dan melakukan code review. Senior terbaik cukup memakai library. Kandidat yang bagus membuat sendiri, tetapi bisa menjelaskan trade-off-nya. Junior hanya membuat tes lulus lalu berhenti
https://github.com/emilybache/GildedRose-Refactoring-Kata
Saya membiarkan kandidat mengerjakannya dengan bahasa yang mereka sukai, dan itu menjadi filter yang sangat efektif
Saya pernah mewawancarai kandidat developer yang tampaknya tahu banyak teori, tetapi gagal total ketika diminta menulis kode. Ia bahkan tidak bisa mengimplementasikan fizzbuzz, dan seorang developer Senior Java tidak bisa mengimpor HashMap tanpa mencarinya
Ini mirip matematika. Untuk 562 * 1041 memang wajar memakai kalkulator, tetapi kalau seseorang mengeluarkan kalkulator untuk mengetahui 3 * 7, kita akan meragukan apakah dia ahli. Banyak perusahaan memang berlebihan dengan wawancara LeetCode, tetapi wawancara live coding yang menunjukkan manipulasi array, kontrol alur, dan penggunaan struktur data dasar memperlihatkan apakah seseorang punya memori otot yang hanya muncul dari pengalaman. Kalau untuk lulus Anda harus mempelajari algoritma traversal graf, itu mungkin sudah terlalu bergaya LeetCode
Namun sebuah program membutuhkan banyak elemen kecil seperti itu, dan dalam pandangan dunia tersebut semuanya harus dihafal. Untuk 562 * 1041, yang diharapkan adalah memahami prinsip perhitungannya, yaitu tahu cara melakukannya. Perhitungannya bisa saja salah, tetapi ide perkalian panjang tidak boleh salah. Dalam konteks seperti itu, tidak masalah kalau lupa satu item tabel perkalian seperti 3 * 7. Programmer adalah orang yang mengorganisasi perhitungan, bukan orang yang menghitung sendiri; komputerlah yang melakukannya. Saya setuju bahwa untuk algoritma traversal graf, cukup tahu di mana mencari solusinya, tidak perlu memegang semua solusi di tangan
Dalam situasi seperti apa orang-orang ini harus melakukan import sendiri? Apakah tidak ada IDE
Saya tidak yakin apakah ini sindiran terhadap stereotip pewawancara