- Dalam proses rekrutmen backend Kagi Search, seorang developer mengimplementasikan klien email bernuansa terminal secara full-time selama sekitar seminggu, tetapi ditolak setelah mengirimkannya tanpa wawancara lanjutan
- Tugasnya bersifat terbuka: TUI atau web app, fungsi dasar membaca dan mengirim email, pilihan backend palsu atau IMAP/POP/JMAP, sehingga kandidat harus menilai sendiri cakupan implementasi dan kriteria evaluasinya
- Kandidat sebelumnya mengirim rencana terperinci yang mencakup Go web app, AWS ECS Fargate, SSL, Postmark, login, Pulumi, Pocketbase, TEMPL, dan lainnya, tetapi pihak Kagi tidak memberi kriteria kelulusan yang spesifik
- Dalam umpan balik yang diminta setelah penolakan, jawaban yang diterima hanya bahwa ada “submission yang lebih sederhana dan lebih kuat”, serta diberitahukan bahwa pada tahap ini biasanya mereka tidak memberikan umpan balik individual
- Pengalaman ini menunjukkan bahwa wawancara berbasis tugas tanpa bayaran dan puzzle coding dengan batas waktu dapat lebih banyak menguji waktu dan kondisi hidup kandidat daripada kemampuan engineering yang sebenarnya
Melamar dan Menerima Tugas
- Kandidat mengirim resume untuk peran backend di Kagi Search, dan ringkasan perannya mencakup kemampuan berikut
- Pengalaman membangun sistem backend
- Kemahiran dalam Go
- Pemahaman tentang penskalaan dan pemeliharaan sistem backend
- Kemampuan berkolaborasi dengan SRE dan anggota tim
- Pemahaman teknologi kontainerisasi seperti Docker
- Setelah itu, ia menerima email dari Kagi yang memintanya menyelesaikan Kagi Developer Assessment sebagai tahap berikutnya
- URL tugas dikirim melalui HackMD
- Isinya menyebutkan bahwa setelah selesai dan menghubungi mereka, mereka akan meninjau hasilnya, dan jika lolos, pendekatan serta solusinya akan dibahas dalam wawancara lanjutan
Persyaratan Tugas dan Kriteria Evaluasi yang Terbuka
- Tujuan tugas adalah membuat “klien email minimal dengan nuansa terminal”
- Ketentuan implementasinya relatif sangat terbuka
- Klien email dapat diimplementasikan sebagai TUI terminal atau web app
- Diperlukan fungsi dasar membaca dan mengirim email
- Dapat menggunakan backend palsu (DB, in-memory, dll.) atau backend nyata IMAP/POP/JMAP
- Pesan rich text dikecualikan; cukup menangani teks biasa
- Dijelaskan bahwa yang dinilai bukan hanya kemampuan coding, tetapi juga kemampuan menangani ambiguitas dan masalah terbuka yang dibutuhkan dalam proyek R&D seperti Kagi Labs
- Ketentuan deliverable adalah sebagai berikut
- Diimplementasikan dengan cara yang menunjukkan kemampuan sebagai developer
- Proyek yang selesai diunggah ke repositori GitHub dan dideploy di suatu tempat agar mudah diuji
- README berisi cara konfigurasi
Komunikasi dengan Perekrut
- Kandidat menilai persyaratannya terlalu luas dan mengirim pertanyaan kepada perekrut
- Perekrut menjawab bahwa ada banyak kandidat; sebagian hanya mengimplementasikan hal dasar, sementara sebagian lain memberikan fitur tambahan, dokumentasi yang baik, penjelasan keputusan, deployment demo, hingga rencana ke depan
- Saat ditanya fitur tambahan seperti apa yang dinilai tinggi, perekrut menjawab bahwa “itu sendiri adalah bagian dari evaluasi” dan mereka ingin melihat fitur tambahan yang dipikirkan kandidat
- Kandidat memutuskan untuk menulis dan mengirim rencana implementasi seluruh deliverable secara terperinci sebelum benar-benar mulai coding
- Ia berharap, jika usulannya diterima, ia bisa lebih dekat ke wawancara telepon atau penawaran kerja
- Setelah melihat hasil akhirnya, ia menilai bahwa upayanya untuk menyesuaikan ekspektasi sebelumnya tidak terlalu berarti bagi perekrut
Implementasi yang Diusulkan Kandidat
- Inti usulannya adalah klien email berbasis Go web app
- Deploy ke AWS
- Menggunakan ECS Fargate
- Menerapkan SSL/HTTPS
- Integrasi dengan penyedia pengiriman email
- Autentikasi melalui layar login
- Pengiriman email berbasis form
- Menampilkan email masuk di UI
- Dalam proposal, tanggal deliverable ditetapkan pada Minggu, 30 Maret EOD, dan ia menulis bahwa jadwal itu terlambat dua hari kerja dibanding titik dua minggu setelah email awal
- Pilihan teknologinya adalah sebagai berikut
- Backend Go: menggunakan Pocketbase dan TEMPL
- Infrastructure as Code: menggunakan Pulumi, dengan TypeScript SDK
- Penyedia layanan email: menggunakan Postmark
- UI: pagination untuk email terkirim dan diterima, layar login, serta menyediakan 2 akun untuk demo
- Alasan pemilihannya lebih condong untuk menunjukkan cakupan peran dan area evaluasi secara luas
- Meski perannya backend, menambahkan web frontend dapat menunjukkan keluasan teknologi web
- Database relevan dengan peran backend
- AWS dan deployment dengan infrastructure as code terhubung dengan pembahasan IaC, Docker, networking, dan resiliency
- Layanan email seperti Postmark mengurangi kompleksitas integrasi IMAP/POP sambil tetap mempertahankan fungsionalitas
- Kandidat bertanya “respons seperti apa yang bisa diharapkan dari Kagi jika ini selesai”, tetapi balasannya hanya sebatas “sangat menarik dan kami menantikan submission Anda”
Submission dan Penolakan
- Kandidat mengimplementasikan semua yang ia usulkan, dan menyatakan seluruh pekerjaan memakan waktu satu minggu full-time
- Demo aplikasi web diunggah ke YouTube, dan kodenya dipublikasikan di GitHub bersama dokumentasi
- Setelah menerima email penolakan otomatis lalu meminta umpan balik, pihak Kagi menjawab sebagai berikut
- Pada tahap ini, biasanya mereka tidak memberikan umpan balik
- Ada submission yang lebih sederhana dan lebih kuat, sehingga mereka memutuskan melanjutkan proses dengan kandidat tersebut
- Ada banyak minat dan lamaran untuk setiap posisi, sehingga proses seleksinya sangat kompetitif
- Mereka meminta kandidat terus memantau posisi mendatang dan melamar kembali
Pertanyaan yang Tersisa Setelah Penolakan
- Kandidat menilai, jika yang diinginkan adalah “solusi yang lebih sederhana”, mereka bisa mengatakannya saat ia mengirim proposal pada 18 Maret
- Jika solusinya tidak cocok untuk peran tersebut, ia juga merasa hal itu bisa dinilai pada tahap proposal 18 Maret
- Ia menulis bahwa per 13 Mei, satu setengah bulan setelah penolakan, lowongan kerja itu masih terpasang
- Ia mengakui bahwa perusahaan bisa mengisi beberapa peran dengan lowongan yang sama
- Namun, ia menilai sulit melihatnya sebagai “kompetisi yang posisi pemenangnya sudah terisi”
- Dalam instruksi tugas awal, deployment demo disebut baik untuk dimiliki tetapi tidak wajib, sedangkan setelah submission, instruksinya berubah menjadi menjadikan deployment sebagai persyaratan ketat
Usulan untuk Metode Seleksi yang Lebih Baik
- Kandidat mengkritik bahwa tugas tanpa bayaran menjadi beban besar bagi pencari kerja, terutama orang yang sedang menganggur dan tabungannya terus berkurang
- Ia juga bersikap negatif terhadap wawancara ala LeetCode
- Dalam peran berbasis Clojure baru-baru ini, ia mengerjakan soal “coin change”; dalam 50 menit ia berhasil meloloskan sekitar setengah test, tetapi tidak punya cukup waktu untuk mengimplementasikan bagian backtracking
- Sebagai alternatif, ia mengusulkan live code review
- Menurutnya, ini bisa dilakukan secara asinkron maupun sinkron
- Masalah dan topik dari proyek software nyata dapat dibahas secara verbal
- Cara ini dapat lebih baik mengungkap pengetahuan software engineer berpengalaman
- Ia tidak sepenuhnya menentang live coding itu sendiri, tetapi menilai kemampuan menyelesaikan knapsack dalam 50 menit jauh dari pekerjaan engineering sehari-hari
- Ia menyarankan untuk menolak peran yang meminta pekerjaan tanpa bayaran semacam ini jika situasinya tidak benar-benar mendesak
1 komentar
Opini Hacker News
Dari sudut pandang perekrut, saya tidak menyukai seleksi berbasis tugas karena alasan-alasan ini. Itu membuang waktu semua orang, dan meski boleh saja sebagai tahap terakhir sebelum perekrutan, tidak tepat dipakai sebagai filter
Meski begitu, kemampuan dan keseriusannya jelas terlihat; saya hanya mencoba menjadi devil's advocate dari sudut pandang lain
Permintaan “buatkan klien email bergaya terminal yang bisa diuji alfa oleh beberapa pelanggan” adalah permintaan yang masuk akal untuk engineer startup tahap awal, dan detailnya memang mau tidak mau diserahkan kepada engineer
Terutama permintaan “saya ingin tahu respons seperti apa yang bisa saya harapkan dari Kagi jika saya melanjutkan sampai selesai” kurang baik. Dalam situasi harus melihat ratusan hingga ribuan submission, tidak ada cara untuk memberi jawaban pasti
Kalau mencoba memperjelas persyaratan adalah perilaku yang tidak diinginkan, itu tidak jauh berbeda dari menyuruh orang memilih angka antara 1 sampai 10 lalu menyingkirkan yang salah
Tes berbasis tugas seharusnya untuk menunjukkan kemampuan, tetapi tanpa panduan konkret, bagaimana orang bisa menebak sejauh mana mereka harus menunjukkannya?
Tenggat waktu hanya buruk ketika menghalangi pengiriman, dan menolak seseorang karena “terlalu dipoles” terasa seperti menolak karena ia bekerja terlalu baik
Tes ambigu seperti ini pada akhirnya terlihat lebih seperti cara lain untuk menyaring orang dengan alasan bukan kecocokan budaya
Lingkungan “buat dulu, review belakangan” adalah salah satu tempat paling toksik dalam karier saya, dan rasanya paling buruk ketika sudah menghabiskan berhari-hari membuat fitur lalu tahu bahwa fitur itu tidak diinginkan
Karena itu, cara menjelaskan fitur secara tertulis dan mendapat persetujuan lebih dulu hampir menjadi standar industri untuk peluncuran proyek, dan kandidat ini mengikuti praktik software yang diikuti organisasi sehat
Bahkan dari sudut pandang hiring manager di perusahaan dengan lebih dari 1.000 engineer, saya melihatnya begitu
Tentu saja, ini hanya perlu diberikan kepada kandidat yang hasilnya memang bisa menentukan lolos tidaknya mereka
Saat pencarian kerja terakhir, saya menerima tugas yang sangat luas seperti ini, dan meski itu pekerjaan yang kualifikasinya di bawah kemampuan saya, saya ditolak karena tidak bisa menebak bagian mana yang akan dinilai
Ke depan, kemungkinan saya mendapatkan pekerjaan lewat cara selain rekomendasi tampak kecil, tetapi saya jadi sangat enggan menerima maupun memberikan tugas seperti ini
Tugas ini dimaksudkan untuk melihat kemampuan mengajukan beberapa pertanyaan, menuliskan asumsi, lalu dengan percaya diri terjun membangun sesuatu yang ambigu
Kemungkinan besar setelah email itu dikirim, kodenya tidak lagi penting, dan perusahaan seharusnya menghentikan proses pada saat itu agar kandidat tidak membuang waktu mengimplementasikan tugas
Saat melihat kode dan video demonya, pikiran pertama saya adalah “butuh seminggu untuk membuat aplikasi web dua halaman, dan bahkan fungsi email paling dasar seperti membuka pesan pun tidak ada”
Melihat persyaratannya, orang ini melamar sebagai “Email Backend Engineer”, tetapi untuk backend email yang sebenarnya ia memakai produk pihak ketiga seperti Postmark dan Turso
Elemen dasar seperti format email teks biasa, tampilan, folder mailbox, setidaknya inbox dan sent mail, tidak ada; sementara fungsi opsional seperti layar login, halaman admin, dan framework backend justru ada
Di database backend bahkan tidak ada map header email
Ia mungkin saja engineer yang hebat, tetapi tampaknya tidak cocok untuk posisi spesifik ini, dan saya pun akan menolaknya
Melihat lowongan aslinya, judulnya adalah “The project is to build a minimal, terminal-inspired email client”, dan secara eksplisit disebutkan agar mengambil inspirasi dari alat email terminal yang sudah ada seperti aerc, mutt, himalaya
Ini tampak seperti tingkat tidak membaca persyaratan dengan benar, jadi menurut saya tidak bisa direkrut
Keduanya tampaknya sudah cukup terpenuhi
Mengambil inspirasi dari alat yang sudah ada itu subjektif, dan untuk tugas posisi backend, ia mungkin tidak menganggap menghabiskan waktu pada antarmuka pengguna sebagai cara terbaik menunjukkan kemampuan
Saya paham bahwa kalau recruiter harus meninjau ratusan orang untuk posisi populer, itu tidak selalu realistis, tetapi justru karena itulah seleksi berbasis tugas kurang bagus
Kandidat bisa membuang beberapa jam hidupnya tanpa mendapatkan apa pun, jadi kedua pihak harus saling menghargai waktu masing-masing
Saya paham bahwa tanggapannya sangat singkat dan tidak membantu, tetapi persyaratannya jelas meminta untuk membuat klien email yang terminal-inspired.
Jika melihat video yang dibagikan https://www.youtube.com/watch?v=yY1sVXMkP_o, hasilnya tampak seperti aplikasi web email biasa tanpa unsur yang secara khusus terinspirasi terminal.
Jika yang diinginkan adalah salah satu dari TUI sungguhan atau aplikasi web, kemungkinan besar aplikasi webnya pun seharusnya bergaya terminal.
Bagian “Inspiration” dari seluruh persyaratan menyatakan secara jelas untuk “mengambil inspirasi dari alat email terminal yang sudah ada seperti aerc, mutt, himalaya”.
Meski begitu, prompt-nya memang secara eksplisit menyebut klien terminal lain sebagai inspirasi.
Selain itu, persyaratan klien terminal sangat mengubah objek evaluasi. UI web email adalah ranah yang sudah lama dikenal, tetapi pengalaman pengguna klien terminal belum menjadi ranah yang sepenuhnya “terselesaikan”.
Kemungkinan besar rubrik evaluasinya memberi bobot besar pada keputusan desain klien terminal yang sama sekali tidak disentuh oleh kiriman pelamar.
Evaluasi berbasis tugas bisa bernilai dalam proses wawancara, tetapi harus ada batas waktu. Dalam 2–3 jam, informasi yang dibutuhkan sudah cukup bisa diperoleh; lebih dari itu cenderung seperti menyaring hanya kandidat junior yang tidak punya tanggungan keluarga, hobi, atau tanggung jawab lain.
Jika dibatasi 3 jam, dalam skenario terburuk pelamar hanya kehilangan 3 jam, dan dalam skenario yang lebih mungkin, ia akan mengajukan proposal atau solusi yang sama sekali berbeda sesuai waktu tersebut.
Pelamar juga perlu memastikan apakah mereka menginginkan “jawaban apa saja” atau “jawaban yang bagus”.
Ada tugas yang hanya melihat apakah sekumpulan tes lolos dan tidak peduli caranya, tetapi ada juga tugas yang lebih menyukai kode yang lebih baik meski hanya memenuhi 80% persyaratan. Saya pernah melihat pelamar salah menilai di kedua sisi.
Tugas seperti ini bisa menyaring orang yang mampu membuang banyak waktu untuk proyek, dan justru membuat orang-orang sibuk—yakni orang-orang yang kemungkinan diinginkan—menjauh.
Saat merekrut kemampuan data engineering, saya memberi tugas ETL sederhana. Pelamar diminta mengambil data dari berkas ZIP, mentransformasikannya, lalu memasukkannya ke basis data apa saja.
Saya membiarkan beberapa bagian ambigu, dan memasukkan elemen tersembunyi dalam dataset seperti nilai null tak terduga atau CSV yang formatnya salah untuk melihat kemampuan pengerjaannya.
Saya membatasinya 4 jam tetapi belum memberi panduan saat waktunya kurang; itu saran yang bagus.
Dalam panggilan setelahnya, kami melihat kode bersama dan bertanya hal seperti “bagaimana jika dataset tidak muat seluruhnya di memori?”, lalu menanyakan arah perbaikannya; di titik itulah evaluasi teknis yang sebenarnya terjadi.
Karena tidak ada jaminan semua pelamar memakai durasi yang sama, ini menjadi masalah game theory, dan pelamar umumnya dirugikan dalam satu atau lain bentuk.
Dalam banyak kasus, jawaban yang benar adalah meluangkan lebih banyak waktu untuk membuat solusi yang sangat rapi—tetapi tidak terlalu rapi—lalu berpura-pura mematuhi batas waktu.
Bahkan 3 jam adalah waktu yang sangat panjang bagi pelamar yang belum tentu bisa berbicara dengan orang berikutnya.
Dalam wawancara 1 jam, tugas pemrograman bisa dilakukan sambil memastikan pelamar tidak membuang waktu tambahan.
Jika pelamar mau, mereka juga bisa mengirim jawaban perbaikan belakangan, dan biasanya pada titik itu saya sudah menilai kemampuannya baik sehingga bisa mengatakan, “silakan kalau mau, tapi Anda sebenarnya sudah lolos.”
Dengan menjaga investasi waktu pelamar dan pewawancara tetap setara, saya jadi menghormati waktu pelamar sebagaimana saya menghormati waktu saya sendiri.
Jika manajer perekrutan tidak menghormati waktu pelamar, kecil kemungkinan mereka akan menghormati waktu karyawan.
Belakangan saya menjalani wawancara di beberapa tempat, dan pengalamannya sangat mirip dengan ini. Saya membuat solusi yang sangat baik untuk tugasnya, tetapi ditolak tanpa diskusi tentang hasilnya.
Dari pengalaman beberapa kali menjalankan proses berbasis tugas sebagai perekrut, saya percaya bahwa jika Anda meminta seseorang mengerjakan tugas di rumah, Anda wajib berbicara tentang kodenya.
Jika menerima tugas take-home, sangat disarankan untuk memastikan apakah akan ada percakapan lanjutan terlepas dari hasil evaluasi; jika tidak setuju, saya sangat menyarankan untuk tidak mengerjakan “PR” tersebut.
Sejujurnya, banyak tim perekrutan levelnya rendah, sehingga mengimplementasikan solusi yang bagus justru bisa menjadi minus. Anda bisa tersingkir karena alasan yang menjengkelkan: tim perekrutannya tidak mampu memahami level tersebut.
Saya pengguna awal Kagi, tetapi karena kejadian ini saya mempertimbangkan untuk menutup akun. Jika tidak punya waktu untuk berbicara dengan pelamar, seharusnya jangan memberi mereka pekerjaan sejak awal.
Tugas take-home membutuhkan upaya besar bukan hanya dari pelamar, tetapi juga dari orang yang mengelolanya dan tim perekrutan; jika sebuah proyek sudah ditinjau, wajar untuk mengharapkan umpan balik atau respons saat diminta.
Namun ada juga realitasnya. Jika ada 20 kandidat hebat untuk satu posisi, banyak orang kompeten tetap akan ditolak. Itu tidak berarti mereka kurang mampu atau “gagal”.
Jika secara hukum harus menjelaskan mengapa memilih A dan bukan B, sulit mengatakan “keduanya hebat, tetapi kami memilih salah satu”, dan menurut saya akhirnya mudah bergeser ke mencari-cari kekurangan yang sebenarnya tidak ada.
Dalam budaya perusahaan AS, saya sering melihat cara seperti itu, dan Kagi berbasis di Palo Alto.
Gagal di sebuah tugas tidak masalah, tetapi membuang waktu seseorang tanpa mengembalikan apa pun sulit diterima.
Banyak perusahaan, termasuk startup populer, menangani hal ini dengan baik.
Hasilnya tidak terlalu mirip dengan “klien email minimal bergaya terminal”, dan tampaknya sepenuhnya mengabaikan alat-alat yang disebut sebagai sumber inspirasi.
Jika persyaratannya disalahpahami sebesar ini, saya pun tidak akan menghabiskan waktu untuk berdiskusi.
Ini kasus klasik salah membaca konteks tersembunyi. Perusahaan menginginkan orang yang bisa secara mandiri menciptakan pekerjaan dan tujuannya sendiri
Ambiguitas tugas itu bukan dimaksudkan untuk dikorek lewat banyak email, melainkan kanvas kosong untuk menunjukkan bagaimana seseorang menerima tugas yang cukup luas, mengeksplorasi ruang masalah sendiri, lalu menghasilkan sesuatu
Ini sangat mirip dengan mahasiswa yang tidak memahami tugas lalu mengeluh setelah mendapat nilai yang tidak mereka duga saat kita bekerja di universitas
Dalam situasi wawancara ketika ingin terlihat mengesankan, tidak banyak orang yang berani bersikap “malas”
Jika perusahaannya punya pendekatan yang berpusat pada rilis eksperimen cepat dan prototipe, sebagian orang memang sangat tidak cocok, dan itu buruk bagi semua pihak
Mungkin ada kandidat yang berpikir selama 10 menit tentang apa yang bisa dibuat dalam 60 menit, memanfaatkan autentikasi HTTP dan form, menjalankannya dengan backend Go kecil, lalu mengirimkannya bersama email singkat. Orang seperti itu kemungkinan besar terlihat jauh lebih baik dalam prosesnya
Kita tidak tahu apakah ini prototipe sekali pakai, sesuatu yang akan dilihat pengguna sungguhan, apakah pengalaman pengguna yang tidak sempurna akan dikritik, atau hanya ingin melihat sesuatu
Pada akhirnya ini berubah menjadi latihan menebak selera reviewer
Sebaliknya, mungkin ada juga orang yang gugur karena tidak terus mendorong agar requirement diperjelas, padahal itu adalah kualitas penting bagi engineer
Hidup memang tidak adil, tetapi kita berharap lebih banyak dari manajer perekrutan, dan karena itu terus kecewa
Bisa saja mahasiswa salah paham karena mereka tidak bisa membaca pikiran dan instruksinya ditulis dengan buruk
Guru yang baik adalah orang yang membuat sebanyak mungkin murid memahami, sedangkan guru yang buruk adalah kebalikannya
Di bawah para guru terbaik, rubrik penilaian sudah transparan sejak awal sehingga tidak perlu meragukan nilai
Jika banyak mahasiswa kebingungan, penyebut umumnya mungkin adalah gurunya
Fakta bahwa biksu Buddha belajar dengan memecahkan teka-teki sulit bernama koan bukan berarti metode yang sama harus diterapkan kepada mahasiswa yang membayar uang kuliah
Karena sepertinya penulisnya sendiri yang memposting, saya akan coba menjelaskan konteks reaksi yang diterima. Saya pernah bekerja di Kagi dan melalui tes take-home serupa
Saat itu perusahaannya masih sangat kecil, Vlad meninjau kandidat secara langsung, dan menggunakan proyek take-home seperti ini. Sekarang perusahaannya sudah lebih besar, jadi mungkin ia tidak melihat langsung, tetapi intinya tampak mirip
Kalau berbicara dengan Vlad, ia hampir seperti arketipe komentator Hacker News, dan wawancaranya lebih mirip pengecekan suasana untuk melihat apakah seseorang “terlihat seperti orang yang oke”
Menulis dokumen desain panjang kepadanya yang berbunyi “akan memakai Galactor, membuatnya florp-ready, dan melakukan fleem” adalah kebalikan total dari keren
Jika tugasnya adalah “klien email bergaya terminal”, proyek yang nyaris mendapat nilai penuh mungkin adalah sesuatu yang semua fiturnya punya shortcut keyboard dan dijelaskan dalam satu paragraf bahwa menggambar satu frame tidak pernah lebih dari 2 ms
Pewawancara mungkin melihat kandidat ini terlalu berpikir ala enterprise untuk bekerja di Kagi
Tentu saja, apakah metode seleksi seperti ini bagus adalah persoalan lain. Vlad menginginkan orang yang berpikir seperti dirinya, dan ada banyak masalah dalam wawancara seperti ini yang sudah lama dibahas dan diteliti
Namun jika memahami itu dan punya keleluasaan untuk menanggung proses semacam ini, tugasnya sebenarnya masuk akal. Kagi bisa saja menyampaikan hal ini dengan lebih baik
Sayang sekali waktunya banyak terbuang, tetapi semoga menemukan tempat yang lebih cocok dengan cara kerja Anda
Untuk memberi wawasan baru terhadap masalah, dibutuhkan keberagaman cara berpikir. Jika semua orang berpikir dengan cara yang sama, ketika satu orang buntu, kemungkinan semuanya ikut buntu
Ini tampak seperti masalah umum di startup, dan mungkin merupakan sinyal yang menunjukkan mengapa 9 dari 10 startup gagal
Ini berbeda dari menguji kemampuan. Di sini, seseorang harus mendapat nilai tinggi pada metrik yang tidak diberitahukan agar lolos
Memberi tugas “coba coding apa saja, karena kamu harus bisa menangani ambiguitas” pada dasarnya tidak jauh berbeda dari menyuruh orang menebak apa yang ada di kepala saya
Itu cara yang sangat tidak berempati terhadap orang lain, dan juga bukan sinyal yang baik tentang sosok Vlad
Apakah untuk mengetahuinya saya harus mengorek media sosial orang-orang di perusahaan itu?
Pada akhirnya, jika meski saya sudah cukup menunjukkan bahwa saya tidak keren mereka tetap menyuruh “lanjutkan” hanya demi memuaskan rasa penasaran, saya berharap mereka diperlakukan sebagaimana mereka memperlakukan orang lain
Terima kasih atas penjelasannya, tidak ada perasaan buruk. Hanya saja, saya berharap bisa membaca tulisan seperti ini lebih awal
Ke depan, pekerjaan yang punya “take-home” sebaiknya diklasifikasikan sebagai pekerjaan untuk anak-anak keren. Dengan begitu, para engineer yang membosankan tetapi berpengalaman bisa menekan perusahaan untuk mengubah caranya jika mereka benar-benar menginginkan tenaga kerja kami
Jika perusahaan tidak berubah, kita bisa menyimpulkan seperti apa perusahaan yang “menawarkan” peran itu
Saya melihat kodenya untuk membayangkan bagaimana reviewer akan menilainya
Saya mungkin sudah berhenti di sini pada file pertama yang saya buka: https://github.com/Sleepful/mymail/blob/main/app/router/page...
Komentar pertama sangat aneh karena tidak relevan dengan pekerjaan, dan tampak seperti disalin dari contoh blog. Bagaimanapun, membiarkannya begitu saja menunjukkan kurangnya perhatian
Ungkapan di baris kedua tidak konsisten dengan baris ketiga
Saya mungkin menghentikan review di sini. Ini adalah kurangnya perhatian pada detail, dan tidak menunjukkan kemampuan berpikir dengan jernih
Tetapi yang kembali hanyalah email penolakan kosong
Dalam situasi itu, sulit bagi saya untuk setuju bahwa saya seharusnya menghabiskan lebih banyak waktu untuk komentar kode
Saya ingin berbicara sebagai pewawancara engineering. Saya tidak suka LeetCode maupun tugas take-home. Keduanya memakan banyak waktu dan informasi yang didapat sedikit
Meski begitu, dalam kasus ini kemungkinan besar saya juga akan menolak penulis. Kagi Search adalah startup, dan tempat seperti ini biasanya mencari optimis pragmatis yang bisa bergerak cepat serta menyeimbangkan kedalaman dan keluasan
Dulu ada rekan kerja yang mengumpulkan masukan, lalu mengurung diri selama beberapa hari untuk membuat solusi; saat ia keluar, persyaratannya sudah berubah. Itu bukan pengalaman yang menyenangkan bagi siapa pun
Saya benar-benar benci proses seleksi berbasis tugas
Kalimat “proyek ini tidak hanya menguji coding, tetapi juga kemampuan menangani ambiguitas dan masalah terbuka” terdengar seolah sebenarnya berarti a) tugasnya dirancang terlalu buruk sampai mereka bahkan tidak membuat rubrik penilaian, atau b) lingkungan kerjanya begitu kacau sehingga spesifikasi atau persyaratan apa pun tidak pernah didefinisikan dengan jelas
Selain itu, instruksi “pamerkan kemampuan teknismu” dan “berikan solusi yang praktis dan fungsional” saling bertentangan. Solusi sederhana yang baik tidaklah mencolok
Fakta bahwa seseorang bisa membuat permintaan HTTP dan layar edit CRUD dasar hampir tidak memberi tahu apa-apa. Alat AI pun bisa membuat hal seperti ini dengan cukup cepat dan kualitas yang lumayan
Yang ingin saya lihat adalah bagaimana seorang engineer mengimplementasikan logika bisnis yang canggung
Apakah hasilnya menjadi sejuta
ifbertingkat dan komentar “di sini ada naga”, atau apakah ia menemukan pola yang tepat dan membuat kode yang bisa dibaca serta dinalarIni jauh lebih bernilai dalam pekerjaan nyata, sinyal wawancaranya lebih kuat, lebih sulit ditebak oleh AI, dan juga membutuhkan lebih sedikit waktu
Membuat solusi sederhana yang baik justru bisa menjadi cara menunjukkan kemampuan
Menurut saya itu adalah bagian besar dari peran senior software engineer
Format ini mungkin bukan cara terbaik untuk mengujinya, tetapi “kami ingin melihat apakah Anda bisa menangani ambiguitas” tidak berarti semua pekerjaan bersifat ambigu
Itu bisa berarti semua pekerjaan harus melalui proses dari “persyaratan yang ambigu” menjadi “spesifikasi yang jelas”