Pengalaman Gagal dalam Wawancara Berbasis Tugas di Kagi Search

 (bloggeroo.dev)
4 poin oleh GN⁺ 2025-05-16 | 1 komentar | Bagikan ke WhatsApp
  • Menekankan inefisiensi take-home assignment yang diberikan dalam wawancara pengembang perangkat lunak serta masalah pemborosan waktu kandidat
  • Dalam proses melamar ke Kagi Search, mengalami persyaratan tugas yang terlalu luas dan ambigu
  • Saat mengajukan rencana eksekusi yang konkret, mengalami ketiadaan umpan balik yang jelas dari manajer serta komunikasi yang tidak efisien
  • Setelah menyerahkan proyek yang dikembangkan dengan sangat serius, merasa ada ketidakadilan karena ditolak tanpa alasan yang jelas dan adanya perubahan standar
  • Membagikan alternatif untuk proses rekrutmen yang lebih baik (misalnya, code review secara real-time) serta kesadaran akan masalah tuntutan berlebihan dalam wawancara berbasis tugas

Pendahuluan

  • Take-home assignment adalah metode evaluasi dalam wawancara pengembang perangkat lunak, di mana kandidat diberi sebuah masalah lalu diminta mengimplementasikannya dalam bentuk kode dan mengirimkannya
  • Postingan ini ingin menyoroti ketidakrasionalan metode ini dan masalah pemborosan waktu kandidat melalui tugas nyata dan pengalaman saat melamar ke Kagi Search, sebuah perusahaan yang sebelumnya dianggap bereputasi baik

Melamar kerja ke Kagi Search

  • Mengirimkan resume untuk posisi pengembang backend di Kagi Search
  • Persyaratan untuk peran tersebut adalah sebagai berikut
    • Pengalaman membangun sistem backend
    • Kemampuan menggunakan bahasa Go
    • Pengalaman menskalakan dan memelihara sistem backend berskala besar
    • Kemampuan berkolaborasi dengan anggota tim seperti SRE
    • Pemahaman tentang teknologi kontainer seperti Docker

Panduan tugas wawancara dan persyaratannya

  • Setelah lolos seleksi dokumen, menerima email panduan take-home assignment
  • Topik tugas: "membangun klien email minimal yang terinspirasi terminal"
    • Boleh memilih bentuk terminal atau web app
    • Fitur dasar untuk melihat/mengirim email
    • Bebas memilih backend email palsu atau nyata (IMAP/POP, dll.)
    • Hanya wajib menangani pesan plaintext, rich text tidak diperlukan
    • Penyerahan proyek: repositori GitHub, versi ter-deploy, dan dokumen panduan instalasi
  • Kurangnya panduan yang jelas dan skala proyek cukup besar
  • Tetap memutuskan mengerjakan tugas tersebut, setidaknya karena reputasinya

Komunikasi dengan manajer

  • Saat menanyakan cakupan tugas yang jelas dan fitur tambahan, hanya mendapat jawaban ambigu bahwa “apa yang ingin ditambahkan sepenuhnya bebas bagi kandidat”
  • Sebelum menginvestasikan waktu dan tenaga ke tugas, sempat membagikan rencana eksekusi yang konkret (Proposal) dan meminta tanggapan atasnya, tetapi proses tetap berjalan tanpa umpan balik khusus

Usulan tugas dan rencana

  • Rencana eksekusi:
    • Web app berbasis Go
    • Deployment melalui AWS ECS Fargate dan penerapan SSL
    • Integrasi layanan pengirim email (Postmark)
    • Penambahan fitur login/autentikasi
    • Pengiriman/penerimaan email dan tampilan UI
  • Alasan pemilihan teknologi:
    • Memanfaatkan beragam teknologi yang relevan dengan peran backend
    • Membangun sistem yang nyata dengan memanfaatkan alat Infrastructure-as-Code
    • Mengimplementasikan fungsi yang lebih mendekati layanan nyata, bukan sekadar integrasi API sederhana
  • Elemen implementasi utama:
    • Pocketbase (backend/DB), TEMPL (template), Pulumi (IaC), Postmark (layanan email)
    • Implementasi pagination, login, dan lain-lain
    • Stretch Goal: stabilitas seperti backup dan pemulihan data
  • Kesimpulan: sejak awal sudah memberikan penjelasan dan alasan yang memadai terlebih dahulu, dan berharap ada peninjauan serta tanggapan yang jelas atas hal tersebut

Balasan manajer dan masalah komunikasi

  • Hanya menerima jawaban singkat seperti “usulan yang menarik” tanpa peninjauan yang konkret
  • Tidak ada umpan balik sama sekali terkait kelayakan usulan atau kebutuhan perbaikan
  • Dari sudut pandang kandidat, hal ini terasa sebagai ketiadaan penghargaan terhadap waktu dan usaha yang diinvestasikan

Mengerjakan proyek tugas

  • Mengimplementasikan semua persyaratan yang diberikan dan hal-hal yang diusulkan, serta menghabiskan satu minggu penuh waktu
  • Juga menyerahkan video demo proyek, repositori GitHub, dan dokumentasi yang rinci

Pemberitahuan penolakan dan umpan balik atasnya

  • Setelah menerima email penolakan otomatis, jawaban yang didapat saat meminta umpan balik adalah:
    • “Ada kiriman kandidat lain yang lebih kuat”, “persaingan perekrutan sangat ketat”
  • Masalahnya
    1. Jika memang lebih menyukai solusi yang sederhana, hal itu seharusnya bisa diberitahukan sejak awal
    2. Jika usulannya kurang memadai, umpan balik bisa diberikan pada saat itu
    3. Bahkan setelah penolakan, lowongan tersebut masih tetap dipasang, sehingga dinilai bukan sekadar soal persaingan, melainkan tuntutan pengurasan waktu yang berlebihan
    4. Persyaratan makin diperketat setelah proyek diserahkan, sehingga solusi yang dikirim justru tampak menaikkan standar

Kesimpulan dan pokok masalah

  • Cara seperti ini tidak adil bagi banyak pencari kerja, bahkan bisa disertai ancaman nyata terhadap penghidupan mereka
  • Menekankan perlunya menolak atau mempertanyakan tuntutan tugas tidak berbayar yang berlebihan
  • Ada proses rekrutmen yang lebih baik yang bisa menggantikan tugas berbentuk proyek, seperti code review secara real-time
    • Kemampuan memecahkan masalah pengembangan yang nyata dapat dilihat melalui code review asinkron/sinkron
    • Menunjukkan adanya kesenjangan antara penyelesaian soal gaya Leetcode dan tuntutan pekerjaan nyata
  • Mendesak perbaikan terhadap budaya kelelahan pencari kerja dan evaluasi yang tidak adil

Usulan untuk prosedur perekrutan yang lebih baik

  • Mengajukan alternatif seperti metode code review real-time yang lebih bermakna dalam menilai kemampuan pengembang
  • Menekankan perlunya perubahan dari fokus pada pemecahan teka-teki algoritme berbasis timer menuju penilaian kemampuan nyata dan kemampuan memecahkan masalah

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-16
Opini Hacker News
  • Menyampaikan pendapat secara jujur dari sudut pandang perekrut. Secara pribadi tidak suka tugas takehome. Tugas seperti ini membuang waktu semua pihak. Kalau ini tahap akhir perekrutan masih bisa dimengerti, tetapi menggunakannya untuk menyaring pelamar itu tidak efisien.
    1. Terlalu banyak pertanyaan masuk. Menyelesaikannya dengan menggunakan penilaian di tengah ambiguitas memang bagian dari tugas. Dengan syarat yang diberikan, mestinya cukup menghabiskan satu-dua hari untuk membuat proyek lokal sederhana.
    2. Penulisan dan pembagian proposal terlalu berlebihan. Pelamar tampaknya ingin menunjukkan ketelitian, tetapi dari sisi perusahaan hal itu bisa dianggap tidak efisien dan membuang waktu.
    3. Hasil akhirnya memang fungsional, tetapi terlalu banyak upaya dicurahkan pada infrastruktur dan pemolesan akhir. Saat ditolak, itu akhirnya hanya menjadi buang-buang waktu.
    4. Sepertinya ada syarat berupa klien email yang terinspirasi terminal, tetapi saya tidak menemukan arah itu pada hasilnya.
      Saya mengakui kemampuan pelamar dan semangatnya terhadap pekerjaan. Saya hanya ingin memberi pandangan dari sudut yang sedikit berbeda.
    • Saya merasa sikap penulis blog agak mengganggu. Dari tulisannya saja terlihat akan sulit bekerja bersama, sulit mengambil keputusan secara mandiri, dan tampak membutuhkan panduan yang sangat jelas. Cocok untuk perusahaan besar, tetapi tidak cocok untuk startup.
      "Mengembangkan klien email yang terinspirasi terminal dan melakukan alpha test ke pelanggan" adalah permintaan yang masuk akal untuk engineer startup tahap awal. Meski ada spesifikasi tambahan, banyak bagian tetap bergantung pada penilaian engineer. Pelamar terlalu menginginkan kepastian.
      Bahwa Kagi akan memberi umpan balik seperti apa setelah tugas selesai bukan hal yang baik untuk terlalu dipertanyakan sejak awal. Mereka memang tidak berada dalam posisi bisa memberi jawaban pasti. Mungkin mereka sedang mengevaluasi ratusan atau ribuan lamaran.
    • Penulis bekerja dengan baik, tetapi secara implisit gagal pada syarat "jangan berusaha terlalu keras".
      Jika memang tidak perlu klarifikasi kebutuhan, maka lebih baik suruh saja "tebak angka 1 sampai 10" lalu gugurkan orang yang memilih salah.
      Saya tidak setuju dengan kasus menggugurkan orang karena mereka mencurahkan upaya dan memberikan hasil akhir yang rapi.
      Tugas ambigu seperti ini pada dasarnya hanyalah cara lain untuk menyaring "kecocokan budaya".
    • Menurut saya, pendekatan pelamar dalam memvalidasi idenya mirip dengan praktik engineering masa kini. Tim yang sehat biasanya menjelaskan dokumen desain fitur dalam bahasa Inggris, mendapat persetujuan, lalu lanjut mengerjakannya.
      Budaya "kode dulu, umpan balik belakangan" adalah pengalaman paling merusak dalam karier saya. Pelamar ini mengikuti praktik perangkat lunak yang modern. (Saya perekrut di perusahaan dengan lebih dari 1000 engineer)
    • Dari sudut pandang perekrut, tugas takehome yang saya sukai adalah yang bisa selesai dalam 30 menit, memiliki kriteria evaluasi yang jelas, dan tetap membuka berbagai pendekatan serta pertimbangan trade-off.
      Dalam pencarian kerja saya yang lalu, saya juga pernah gagal pada tugas takehome yang sangat luas karena tidak tahu bagian mana yang menjadi kriteria penilaian. Sejak pengalaman itu saya jadi sangat alergi dengan tugas seperti ini.
    • Saya rasa alasan penolakannya adalah proposal yang menjadi terlalu besar. Instruksi tidak meminta proposal, dan bila mengirim terlalu detail justru bisa ditafsirkan sebagai "kurang punya dorongan mandiri". Kalau sudah begitu, kualitas kode menjadi tidak berarti lagi.
      Menurut saya perusahaan seharusnya tidak membiarkan pelamar terus membuang waktu, dan lebih baik menghentikan tugas pada titik itu.
    • Sangat disayangkan bahwa industri sekarang kekurangan kemampuan memahami kebutuhan sampai-sampai developer disaring berdasarkan kemampuan membaca pikiran.
    • Fakta bahwa pelamar tidak memenuhi tenggat juga masalah. Keterlambatan tanpa penjelasan keadaan khusus sudah cukup untuk gugur. Tujuan tugasnya adalah merancang solusi yang layak dalam batas waktu.
    • Soal poin 4 terkait terminal, di versi lengkap yang dibagikan penulis sebenarnya ada penjelasannya.
    • Diskusi seperti ini selalu mudah dilakukan setelah hasilnya sudah keluar. Kalau pun strateginya dibalik (tidak mengonfirmasi kebutuhan, hanya memenuhi syarat minimum), hasilnya bisa saja tetap sama. Dalam situasi seperti ini, pendapat seperti "seharusnya lebih proaktif mengklarifikasi kebutuhan" selalu bisa juga muncul ke arah sebaliknya.
  • Setelah melihat kodenya dan menonton video demonya, kesan saya adalah dia menghabiskan cukup banyak waktu untuk membuat web app dua halaman selama seminggu.
    Bahkan fungsi email paling dasar (seperti membuka email) tidak ada, dan meski melamar posisi backend engineer, dia sebenarnya memakai produk eksternal seperti postmark dan turso, sementara fungsi dasar (format plain text, tampilan, folder, dan sebagainya) juga tidak ada.
    Memang ada fitur tambahan seperti halaman admin dan login, tetapi struktur data minimum seperti peta header email pun tidak ada.
    Dia mungkin engineer yang baik, tetapi saya menilai dia tidak cocok untuk posisi tersebut.
    Proposal takehome-nya juga terasa terlalu tidak lazim.
    Setelah membaca ulang lowongan awal, tertulis jelas "minimal terminal-inspired email client" dan referensi seperti aerc, mutt, himalaya. Ini jelas kegagalan dalam menafsirkan kebutuhan.
    • Soal ungkapan "kegagalan menafsirkan kebutuhan", saya penasaran sebenarnya kebutuhan apa yang tidak terpenuhi.
      Diminta membuat klien email dalam bentuk terminal atau web app, serta mengimplementasikan fungsi dasar, dan menurut saya itu sudah terpenuhi.
      Bagian untuk mengambil inspirasi dari tool berbasis terminal itu subjektif. Kalau ini posisi backend, saya juga merasa memberi terlalu banyak perhatian pada UI bisa jadi tidak efisien.
    • Sudah menyedihkan ketika pelamar mencurahkan waktu lalu hanya menerima satu email penolakan.
      Kalau setidaknya bisa mendapat umpan balik, itu akan membantu pertumbuhan, tetapi bahkan itu pun sering kali sulit secara realistis.
      Karena itulah saya jadi skeptis terhadap tugas takehome. Baik pelamar maupun perekrut sama-sama perlu saling menghormati waktu.
    • Ada kalimat, "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Evaluasi takehome memang bermakna, tetapi harus selalu memiliki batas waktu.
    Dalam 2~3 jam saja sebenarnya sudah cukup untuk mengevaluasi pelamar. Jika ada batas waktu, pelamar juga bisa memberikan solusi yang sesuai dalam batas itu, dan apa yang diinginkan perusahaan akan lebih jelas.
    Selain itu, perusahaan perlu menjelaskan dengan jelas apakah ‘jawaban apa pun boleh’ atau ‘mengharapkan jawaban terbaik’.
    Maksud dari takehome bisa berbeda-beda, apakah untuk lolos tes, tingkat pemenuhan misi, kualitas kode, dan seterusnya, sehingga pelamar bisa bingung.
    • Dari sudut pandang perekrut, saya rasa tugas Kagi terlalu besar dan tidak menghormati waktu pelamar.
      Malah berisiko menyaring orang-orang sibuk yang sebenarnya tidak punya banyak waktu.
      Di perusahaan kami, kami hanya memberi soal ETL sederhana dengan batas waktu 4 jam.
      Kami juga mendorong bahwa tidak apa-apa bila tidak selesai semua, dan pada tahap lanjutan kami melakukan code review serta sesi tanya jawab.
      Kemampuan nyata justru bisa dinilai dari pertemuan lanjutan itu.
    • Pelamar bisa saja menghabiskan waktu jauh lebih banyak daripada waktu yang sesungguhnya diasumsikan, dan saya penasaran bagaimana perekrut bisa mengetahui hal itu.
      Berbeda dari tugas langsung di lokasi yang menjaga satuan waktu yang adil, takehome bisa merugikan karena pembagian waktu tiap orang berbeda-beda.
      Kalau begitu, lebih baik coding langsung 1 jam. Pelamar dan pewawancara harus sama-sama menginvestasikan waktu agar nilai waktu itu saling dihormati.
    • Menurut saya live review jauh lebih baik daripada live coding. Kalau pun harus live coding, saya lebih suka model bekerja 45 menit di laptop saya sendiri dari jarak jauh lalu kembali untuk review.
  • Memang benar jawaban perusahaan tidak ramah dan tidak membantu, tetapi syarat "terinspirasi terminal" sebenarnya tertulis jelas dalam kebutuhan.
    Di video demo, yang terlihat hanya web app biasa. Secara eksplisit mereka meminta inspirasi dari klien email terminal yang sudah ada seperti aerc, mutt, himalaya.
    Saya penasaran apakah saya melewatkan sesuatu.
    • Akan lebih baik bila email penolakannya menjelaskan alasannya dengan jelas, tetapi sejak awal desain tugas memang secara langsung meminta referensi klien terminal.
      UX khas klien terminal sendiri masih merupakan area yang belum punya "jawaban benar", jadi justru sangat mungkin titik itulah yang dijadikan kriteria evaluasi.
    • Melihat fokusnya pada bahasa Go, membuat CLI itu bahkan tidak sampai 20 baris, jadi saya heran mengapa justru memilih tenggelam dalam pengembangan web GUI.
    • Ada petunjuk, "Email client can either be in the terminal (i.e. a TUI) or a web app".
  • Saya baru-baru ini mengalami pengalaman serupa dalam wawancara. Saya mengumpulkan proyek tugas dengan sangat baik, tetapi tanpa ada percakapan tentang proyek itu saya langsung diberi kabar penolakan.
    Saya percaya bahwa kalau sudah meminta tugas, harus ada pertemuan tindak lanjut.
    Saya sudah lama memakai Kagi berbayar, tetapi karena kejadian ini saya mempertimbangkan menutup akun.
    Jika mereka bahkan tidak punya waktu untuk berbicara dengan kandidat, seharusnya sejak awal jangan meminta tugas seperti itu.
    • Tugas takehome menuntut usaha besar bukan hanya dari pelamar, tetapi juga dari pewawancara yang menilai.
      Setelah sampai tahap review, saya rasa pelamar memang berhak menerima umpan balik.
      Tetapi secara realistis, ketika harus memilih satu orang dari puluhan kandidat hebat, gagal lolos tidak otomatis berarti "kemampuannya kurang".
      Secara hukum pun, jawaban resmi untuk 'mengapa A dipilih dan B ditolak?' pada akhirnya sering hanya menjadi ajang mencari-cari kekurangan.
    • Akan lebih baik bila perusahaan mempublikasikan kriteria yang jelas tentang bagaimana mereka menilai, atau setidaknya memberikan umpan balik. Saya rasa membuang waktu tanpa umpan balik saat gagal itu tidak bisa diterima.
      Banyak perusahaan menangani hal ini dengan baik.
    • Saya ragu apakah itu benar-benar 'solusi yang unggul'. Sepertinya dia sepenuhnya mengabaikan syarat minimal klien email yang terinspirasi terminal beserta referensi terkait.
      Bila kesalahpahaman terhadap kebutuhan sebesar itu, diskusinya sendiri bisa saja dilewati.
  • Kasus ini adalah contoh khas salah membaca maksud tersembunyi dalam isi tugas.
    Perusahaan menginginkan orang yang mandiri dan bisa menetapkan tujuan sendiri.
    Ambiguitas itu dimaksudkan untuk melihat kemampuan pelamar mengeksplorasi jawaban dari berbagai sudut dan memecahkannya.
    • Tugas itu ditujukan untuk orang yang bisa menghasilkan solusi yang sesederhana mungkin, cerdik, dan tetap berfungsi.
      Karena ada orang yang memang tidak cocok dengan perusahaan berorientasi prototipe, beberapa kandidat mungkin cukup berpikir 10 menit lalu menghasilkan yang terbaik dalam 60 menit.
    • Pada proyek R&D yang hanya menekankan 'minimal', jadi tidak jelas apakah ini prototipe, untuk pengguna sungguhan, apakah UX harus diperhatikan, dan seterusnya; akhirnya ini hanya permainan menebak apa yang dianggap penting oleh penilai.
    • Dalam tugas seperti ini yang meminta orang "menafsirkan sendiri", orang yang tidak melakukan klarifikasi kebutuhan atau pertanyaan tambahan justru bisa gugur.
      Tetapi bagi developer, kemampuan bertanya seperti itu adalah kualitas yang sangat penting. Karena itu ekspektasi terhadap cara perekrutan jadi lebih tinggi dan kekecewaannya pun tak terelakkan.
    • Saya rasa "misreading the subtext" justru sudah tertulis dalam kebutuhannya sendiri.
    • Di dunia pendidikan, menyalahkan murid karena "tidak paham" adalah kesimpulan yang terlalu mudah.
      Sering kali penyebabnya justru penjelasan yang ambigu.
      Guru yang hebat membuat sebanyak mungkin orang bisa mengerti. Jika banyak murid bingung, masalahnya ada pada pembuat soal.
      Mahasiswa seharusnya tidak perlu memecahkan koan seperti seorang biksu Zen.
  • Karena penulis postingan ini menulis langsung di sini, saya ingin menjelaskan konteks berdasarkan pengalaman pernah bekerja di Kagi.
    Dulu Vlad sendiri yang menilai kandidat dan tugasnya memang seperti ini.
    Seiring perusahaan tumbuh, tampaknya sekarang orang lain yang menilai.
    Vlad punya kecenderungan ala HN dan ingin bekerja dengan kandidat yang ia rasa "keren".
    Misalnya, kalau seseorang menulis dokumen desain panjang lalu berkata "Saya akan memakai Galactor dan proyek ini siap flop.", efeknya justru akan sepenuhnya berlawanan.
    Dalam syarat "terinspirasi terminal", ada kecenderungan untuk mengharapkan detail nyata seperti semua shortcut keyboard dan sebagainya sebagaimana diimplementasikan pada aplikasi terminal sungguhan.
    Apakah standar seperti ini filter yang baik masih bisa diperdebatkan, tetapi kalau seseorang memahami konteks itu dan punya kemampuan untuk lolos, tugasnya akan terlihat mudah.
    Saya berharap Kagi bisa mengomunikasikan konteks seperti ini dengan lebih baik. Sayang sekali waktunya terbuang, tetapi semoga ia menemukan perusahaan yang lebih cocok secara gaya kerja.
    • Banyak perusahaan ingin mencari orang yang cara berpikirnya mirip dengan mereka.
      Tim yang tidak punya keberagaman bisa mandek karena semua orang menabrak tembok yang sama.
      Fenomena ini sangat umum di startup, dan menurut saya berkaitan juga dengan alasan 9/10 di antaranya gagal.
    • Saya merasa masalahnya adalah Vlad membuang terlalu banyak waktu banyak orang demi mencari "orang keren".
      Tugas yang dinilai tanpa standar jelas terasa tidak adil.
      Pada akhirnya itu tidak berbeda dari tugas implisit untuk menebak "jawaban yang ada di kepala saya".
      Saya mendapat kesan kurangnya kepedulian terhadap orang.
    • Saya bertanya-tanya, "Apakah saya benar-benar harus tahu hal seperti ini sebelumnya?"
      Kalau memang budayanya seperti itu, saya tidak tahu apakah semua orang harus menyelidikinya seperti agen rahasia.
      Akan lebih baik bila pelamar yang 'tidak keren' seperti saya juga mendapat sinyal yang jelas dan bisa cepat mencari perusahaan lain.
  • Setelah meninjau kodenya langsung, saya melihat sejak file pertama ada komentar yang tampaknya hanya menyalin contoh kode tanpa tujuan jelas, penjelasan yang tidak konsisten, dan ungkapan yang menunjukkan kurangnya perhatian pada detail.
    Karena kekurangan pada detail seperti ini, saya akan berhenti me-review.
    • Aplikasinya saya deploy di domain saya dan tidak ada masalah performa. Hal-hal khas backend seperti autentikasi dan infrastruktur juga diimplementasikan dengan baik. Namun saya tidak setuju dengan kritik bahwa dia harus lebih memerhatikan komentar kode.
    • Dalam kasus ini, masalah utamanya bukan penolakan itu sendiri, melainkan cara perekrutan yang sama sekali tidak menghormati waktu pelamar karena tidak memberi panduan yang jelas dan bahkan tidak menyediakan umpan balik.
  • Saya pernah mengalami hal serupa di DuckDuckGo, tetapi di semua tahap lamaran saya menerima kompensasi kecil.
    Dari proposal desain sederhana sampai tugas implementasi, semuanya dilakukan dengan batas waktu yang jelas.
    Pada akhirnya saya tidak diterima, dan alasan yang jelas juga tidak diberikan.
    Mungkin memang pelamarnya terlalu banyak, tetapi pengalaman seperti ini meninggalkan bekas emosional cukup lama. Saya paham perasaan OP.
  • Saya bicara dari sudut pandang interviewer engineering. Baik leetcode maupun takehome sama-sama memakan waktu dan kurang memberi banyak informasi.
    Tetapi kalau saya yang merekrut, saya rasa saya juga akan menolak penulis ini.
    Startup menginginkan orang yang bekerja cepat dan praktis.
    Saya pernah punya rekan yang setelah mengumpulkan pendapat sekitar lalu tenggelam bekerja sendiri selama beberapa hari, ternyata kebutuhannya sudah berubah, dan itu tidak baik untuk siapa pun.