Pertanyaan Wawancara Data Scientist

Kerangka: Asosiasi versus efek kausal

Korelasi berarti dua variabel bergerak bersama secara statistik. Kausalitas berarti perubahan pada satu variabel menghasilkan perubahan pada variabel lain, dengan asumsi faktor lain tetap sama. Korelasi saja tidak membuktikan kausalitas karena hubungan tersebut bisa didorong oleh faktor perancu (confounding), kausalitas terbalik, bias seleksi, atau kebetulan. Contohnya, pengguna yang menerima lebih banyak push notification mungkin memiliki retensi lebih tinggi. Itu tidak membuktikan bahwa notifikasi menyebabkan retensi. Pengguna yang lebih aktif bisa saja secara alami menerima lebih banyak notifikasi atau memicu lebih banyak peristiwa yang memang layak dinotifikasikan. Untuk mengestimasi kausalitas, kita membutuhkan eksperimen acak, eksperimen alami, variabel instrumental, regression discontinuity, difference-in-differences, atau desain kausal yang cermat beserta asumsinya. Jawaban data scientist yang kuat juga menjelaskan risiko keputusannya. Jika kita menganggap korelasi sebagai kausalitas, kita bisa saja menambah notifikasi dan justru merugikan pengguna. Langkah berikutnya yang tepat adalah merancang eksperimen atau analisis kausal yang mengisolasi efek notifikasi.

Kerangka: Positif palsu versus negatif palsu

Kesalahan Tipe I adalah positif palsu (false positive): menolak hipotesis nol padahal hipotesis itu sebenarnya benar. Dalam A/B test, artinya kita merilis fitur karena tampak membantu padahal tidak. Kesalahan Tipe II adalah negatif palsu (false negative): gagal menolak hipotesis nol padahal efek nyata ada. Artinya kita melewatkan fitur yang sebenarnya membantu. Tingkat signifikansi alpha mengendalikan tingkat kesalahan Tipe I. Power, yaitu 1 - beta, berkaitan dengan kesalahan Tipe II. Menambah ukuran sampel umumnya meningkatkan power. Ada trade-off di sini: ambang signifikansi yang lebih ketat mengurangi positif palsu, tetapi dapat menambah negatif palsu jika ukuran sampel tidak disesuaikan. Dalam keputusan produk, tingkat kesalahan yang dapat diterima bergantung pada biayanya. Untuk perubahan checkout yang berisiko, positif palsu bisa sangat mahal. Untuk perbaikan UI yang berisiko rendah, risiko positif palsu yang sedikit lebih tinggi mungkin masih dapat diterima jika kecepatan iterasi penting.

Kerangka: Hipotesis -> probabilitas -> ketidakpastian

Hipotesis nolnya adalah koin itu seimbang, dengan probabilitas muncul gambar sebesar 0,5. Mendapatkan 8 gambar atau lebih dari 10 lemparan masih mungkin terjadi pada koin yang seimbang, jadi kita tidak boleh langsung menyimpulkan bahwa koin itu bias. Untuk uji dua sisi, kita mempertimbangkan hasil yang setidaknya sama ekstremnya dengan 8 gambar atau 2 gambar. Probabilitas mendapatkan 8, 9, atau 10 gambar adalah (45 + 10 + 1) / 1024 = 56 / 1024, sekitar 5,5%. Jika digandakan untuk memperhitungkan ekor bawah, hasilnya sekitar 10,9%. Angka itu tidak berada di bawah ambang signifikansi 5%. Kesimpulannya, 10 lemparan adalah sampel yang kecil. Hasil ini memberi indikasi, tetapi belum cukup kuat untuk menyatakan dengan yakin bahwa koin itu bias. Kita perlu mengumpulkan lebih banyak data jika keputusannya penting.

Kerangka: Hipotesis -> unit -> metrik -> guardrail -> durasi -> keputusan

Pertama, tetapkan hipotesisnya. Misalnya, algoritma ranking baru meningkatkan kepuasan pengguna dengan menampilkan item yang lebih relevan tanpa mengorbankan keberagaman, latensi, atau retensi jangka panjang. Unit randomisasi itu penting. Jika pengguna melihat konten hasil ranking berulang kali, lakukan randomisasi di level pengguna agar setiap pengguna mendapat pengalaman yang konsisten. Jika ada efek jaringan atau efek limpahan (spillover) di marketplace, randomisasi sederhana di level pengguna mungkin tidak cukup, dan kita mungkin memerlukan randomisasi klaster atau holdout yang dirancang dengan cermat. Metrik utama harus mencerminkan tujuannya: engagement yang bermakna, konversi, sesi yang berhasil, retensi lanjutan, atau pendapatan, tergantung produknya. Metrik sekunder bisa mencakup click-through rate, dwell time, jumlah simpan, pembelian, atau item yang disembunyikan. Metrik guardrail (pembatas pengaman) sebaiknya mencakup latensi, tingkat keluhan, keberagaman, keadilan bagi kreator/penjual, berhenti berlangganan atau churn, serta metrik kualitas apa pun yang rentan dimanipulasi. Jalankan uji cukup lama untuk mencakup pola musiman mingguan dan mencapai ukuran sampel yang dibutuhkan. Sebelum merilis, periksa efek kebaruan (novelty effect), perbedaan antarsegmen, kondisi guardrail, dan apakah kenaikan metrik benar-benar bermakna secara praktis, bukan hanya signifikan secara statistik.

Kerangka: Validasi -> keandalan segmen -> dampak bisnis -> strategi rollout

Pertama, pastikan hasil segmen itu nyata. Periksa ukuran sampel, interval kepercayaan, segmen yang sudah ditentukan sebelumnya, risiko multiple testing, dan apakah pengguna baru sudah diklasifikasikan dengan benar. Subkelompok yang penuh noise tidak boleh mengalahkan hasil keseluruhan yang kuat tanpa bukti. Jika penurunan pada pengguna baru memang andal, pahami mekanismenya. Fitur tersebut mungkin menguntungkan pengguna lama yang sudah memahami produk, tetapi membingungkan pengguna baru. Pengguna baru sering membutuhkan onboarding yang lebih sederhana, penjelasan yang lebih lengkap, atau pengaturan default yang berbeda. Rekomendasinya bergantung pada besarnya efek dan kepentingan strategisnya. Jika pengguna baru sangat penting bagi pertumbuhan, saya tidak akan merilisnya secara global. Saya mungkin meluncurkannya hanya untuk pengguna lama, membuat varian khusus untuk pengguna baru, atau menjalankan eksperimen lanjutan dengan perubahan onboarding. Jika efek negatifnya kecil dan berumur pendek, sedangkan retensi jangka panjang membaik, saya akan menyelidikinya lebih jauh sebelum memblokir peluncuran. Jawaban ini perlu menunjukkan bahwa Anda mampu menyeimbangkan metrik agregat dengan efek perlakuan yang heterogen (heterogeneous treatment effects) dan konteks bisnis.

Kerangka: Perlakuan non-acak dengan tren kelompok kontrol yang sebanding

Difference-in-differences berguna ketika randomisasi tidak memungkinkan, misalnya pada perubahan kebijakan, peluncuran per wilayah, perubahan harga, atau perubahan operasional yang memengaruhi satu kelompok tetapi tidak kelompok lain. Metode ini membandingkan perubahan dari waktu ke waktu pada kelompok perlakuan dengan perubahan dari waktu ke waktu pada kelompok kontrol. Asumsi utamanya adalah tren paralel (parallel trends): tanpa perlakuan, kelompok perlakuan dan kelompok kontrol akan bergerak serupa. Kita perlu memeriksa tren sebelum perlakuan untuk melihat apakah asumsi ini masuk akal. Jika kelompok perlakuan sudah memiliki tren yang berbeda sejak awal, estimasinya bisa bias. Contohnya, sebuah fitur diluncurkan di Kanada tetapi tidak di AS. Kita membandingkan retensi di Kanada sebelum dan sesudah peluncuran dengan retensi di AS sebelum dan sesudah periode yang sama. Selisih kedua perubahan itu mengestimasi efek perlakuan, asalkan kelompok kontrol menangkap pola musiman dan faktor eksternal. Saya akan mengomunikasikan hasilnya dengan lebih hati-hati dibandingkan eksperimen acak, karena validitas kausalnya bergantung pada asumsi yang tidak dapat dibuktikan sepenuhnya.

Kerangka: Definisikan label -> bangun fitur -> baseline -> evaluasi -> deploy dengan hati-hati

Pertama, definisikan churn. Untuk produk berlangganan, churn bisa berarti pembatalan, kegagalan pembayaran, atau tidak memperpanjang langganan dalam jangka waktu tertentu. Waktu prediksi harus berada sebelum peristiwa churn, misalnya memprediksi apakah pengguna aktif akan churn dalam 30 hari ke depan. Buat dataset pelatihan pada tanggal snapshot yang konsisten. Fiturnya bisa mencakup frekuensi penggunaan, recency, adopsi fitur, tiket dukungan, masalah penagihan, jenis paket, lama berlangganan, tren engagement, utilisasi lisensi (seat), dan riwayat downgrade. Hati-hati agar tidak terjadi kebocoran data (leakage): jangan sertakan fitur yang terjadi setelah timestamp prediksi atau yang secara langsung mengodekan hasil churn. Mulailah dengan baseline sederhana seperti regresi logistik atau gradient boosted trees, tergantung kebutuhan interpretabilitas dan performa. Evaluasi dengan AUC, precision/recall, kalibrasi, lift pada desil teratas, dan dampak bisnis dari intervensi. Akurasi saja sering menyesatkan jika churn jarang terjadi. Deployment menuntut hasil yang bisa ditindaklanjuti. Skor churn hanya berguna jika perusahaan bisa melakukan intervensi. Pantau drift model, keadilan antarsegmen, efektivitas intervensi, dan apakah model benar-benar mengidentifikasi pengguna yang masih bisa dipertahankan.

Kerangka: Kecocokan pada data latih versus generalisasi

Overfitting terjadi ketika model mempelajari noise atau keanehan khas pada data latih, bukan pola yang dapat digeneralisasi. Model tersebut berkinerja baik pada data latih, tetapi buruk pada data yang belum pernah dilihatnya. Cara mengurangi overfitting antara lain menggunakan pembagian train/validation/test, cross-validation, regularisasi, model yang lebih sederhana, pruning pohon, early stopping, dropout untuk neural network, menambah data, seleksi fitur, dan hyperparameter tuning yang tepat. Kebocoran data bisa tampak seperti performa yang sangat baik tetapi gagal di produksi, sehingga pemeriksaan leakage juga sangat penting. Cara pencegahan yang tepat bergantung pada model dan masalahnya. Untuk model sparse berdimensi tinggi, regularisasi bisa membantu. Untuk gradient boosted trees, kedalaman pohon, learning rate, jumlah estimator, dan early stopping sangat berpengaruh. Untuk data deret waktu atau data perilaku pengguna, validasi harus mengikuti urutan waktu agar model tidak dilatih dengan data dari masa depan.

Kerangka: Interpretabilitas, nonlinearitas, ukuran data, performa, deployment

Regresi logistik adalah baseline yang kuat untuk klasifikasi biner. Model ini cepat, mudah diinterpretasikan, lebih mudah dikalibrasi, dan bekerja baik ketika hubungan antarvariabel kurang lebih linear setelah feature engineering. Regresi logistik sering menjadi pilihan tepat ketika stakeholder membutuhkan penjelasan yang jelas atau ketika datanya terbatas. Random forest dapat menangkap hubungan nonlinear dan interaksi antarfitur tanpa banyak spesifikasi manual. Model ini mungkin berkinerja lebih baik pada data tabular yang kompleks, tetapi lebih sulit diinterpretasikan, ukurannya bisa lebih besar saat dijalankan di produksi, dan mungkin tidak mampu melakukan ekstrapolasi dengan baik di luar distribusi data latih. Saya akan membandingkan keduanya menggunakan pembagian train/validation yang sama, metrik yang tepat, kalibrasi, biaya inferensi, dan batasan bisnis. Jika regresi logistik berkinerja hampir sama baiknya dan interpretabilitas penting, pilih regresi logistik. Jika random forest memberikan peningkatan yang berarti serta dapat dijelaskan dan diterapkan di produksi secara bertanggung jawab, gunakan random forest atau bandingkan juga dengan gradient boosted trees. Jawaban terbaik bukanlah bahwa satu model selalu lebih unggul. Semuanya bergantung pada tujuan, data, batasan, dan seberapa jauh hasilnya bisa ditindaklanjuti.

Kerangka: Ketidaksesuaian data -> leakage -> ketidaksesuaian metrik -> drift -> implementasi -> feedback loop

Ada beberapa kemungkinan penyebab kegagalan. Dataset offline mungkin tidak sesuai dengan trafik produksi. Mungkin terjadi training-serving skew, yaitu fitur dihitung secara berbeda saat online dibandingkan saat offline. Pembagian validasi mungkin membocorkan informasi dari masa depan atau tidak mengikuti urutan waktu. Metrik offline mungkin tidak sejalan dengan tujuan produk. Data produksi bisa mengalami drift: perilaku pengguna, pola musiman, kanal akuisisi, inventaris, harga, atau peristiwa eksternal dapat berubah. Model juga bisa menciptakan feedback loop. Misalnya, model rekomendasi mengubah apa yang dilihat pengguna, yang kemudian mengubah data pelatihan berikutnya. Masalah implementasi juga sering terjadi: fitur yang hilang, nilai default, timeout karena latensi, masalah kesegaran fitur, penetapan threshold yang salah, atau versi model yang tidak cocok. Performa per segmen juga bisa buruk meskipun metrik offline agregatnya terlihat bagus. Saya akan membandingkan distribusi fitur offline dan online, distribusi prediksi, kalibrasi, metrik per segmen, log, dan hasil bisnis. Setelah itu, saya akan memutuskan apakah perlu rollback, menyesuaikan threshold, memperbaiki pipeline fitur, melatih ulang model, atau merancang ulang fungsi objektifnya.

Kerangka: Biaya positif palsu versus negatif palsu

Optimalkan precision ketika positif palsu mahal. Misalnya, jika model fraud memblokir pelanggan yang sah, positif palsu merugikan pelanggan dan menyebabkan hilangnya pendapatan. Precision yang tinggi berarti ketika model menandai sesuatu, tanda itu biasanya benar. Optimalkan recall ketika negatif palsu mahal. Misalnya, pada skrining medis atau deteksi fraud yang serius, melewatkan satu kasus yang benar-benar positif bisa lebih merugikan daripada memeriksa positif palsu tambahan. Recall yang tinggi berarti model berhasil menangkap sebagian besar kasus yang benar-benar positif. Sebagian besar sistem nyata memerlukan trade-off. Threshold harus dipilih berdasarkan biaya bisnis, kapasitas operasional, dampak buruk bagi pengguna, dan alur kerja di tahap selanjutnya. Saya biasanya mengevaluasi kurva precision-recall, bukan hanya satu threshold, terutama untuk kelas yang tidak seimbang.

Kerangka: Kualitas probabilitas, bukan hanya kualitas ranking

Kalibrasi berarti probabilitas yang diprediksi sesuai dengan frekuensi yang teramati. Jika model yang terkalibrasi memberikan probabilitas 0,8 pada 1.000 contoh, sekitar 800 di antaranya seharusnya benar-benar positif. Kalibrasi penting ketika probabilitas menjadi dasar keputusan: skoring risiko, penetapan harga, triase medis, antrean peninjauan fraud, intervensi churn, atau perhitungan nilai harapan (expected value). Sebuah model bisa mengurutkan contoh dengan baik dengan AUC tinggi, tetapi tetap menghasilkan probabilitas yang kalibrasinya buruk. Kita bisa memeriksa kurva kalibrasi atau reliability diagram serta metrik seperti Brier score. Metode kalibrasi antara lain Platt scaling, isotonic regression, dan temperature scaling. Namun, kalibrasi harus diperiksa pada data validasi yang mencerminkan distribusi produksi. Dalam wawancara, tekankan bahwa tidak semua aplikasi membutuhkan probabilitas yang terkalibrasi sempurna. Jika model hanya mengurutkan konten, metrik ranking mungkin lebih penting. Jika angkanya ditafsirkan sebagai risiko, kalibrasi menjadi sangat krusial.

Kerangka: Bulan kohort -> bulan aktivitas -> selisih bulan -> agregasi

Buat CTE kohort yang berisi setiap pengguna beserta bulan pendaftarannya. Buat CTE aktivitas yang berisi user_id unik dan bulan aktivitas untuk event aktif yang memenuhi syarat. Gabungkan (join) aktivitas ke kohort berdasarkan user_id, lalu hitung month_number sebagai selisih antara bulan aktivitas dan bulan pendaftaran. Kelompokkan berdasarkan bulan kohort dan month_number, lalu hitung jumlah pengguna aktif yang unik. Penyebutnya adalah jumlah pengguna dalam kohort awal. Pembilang untuk bulan ke-N adalah pengguna dari kohort tersebut yang aktif pada bulan ke-N. Gunakan left join jika Anda perlu mempertahankan bulan yang tidak memiliki pengguna yang bertahan. Detail penting: definisikan event aktif, keluarkan pengguna uji, tangani pengguna yang mendaftar di dekat batas bulan, gunakan zona waktu yang konsisten, dan hindari menghitung beberapa event aktivitas untuk pengguna yang sama dalam satu bulan. Hasilnya berupa tabel kohort, dengan setiap baris mewakili bulan pendaftaran dan setiap kolom atau offset baris mewakili bulan retensi.

Kerangka: Kuantifikasi -> segmentasi -> diagnosis -> tentukan penanganan

Pertama, saya akan mengukur tingkat nilai yang hilang per kolom: jumlah, persentase, dan tipe data. Di pandas, df.isna().sum() dan df.isna().mean() memberikan gambaran cepat. Lalu saya akan memeriksa apakah nilai yang hilang terkonsentrasi pada waktu, segmen, sumber, perangkat, wilayah geografis, atau label target tertentu. Pertanyaan kuncinya adalah mengapa nilainya hilang. Data yang hilang sepenuhnya secara acak (missing completely at random) berbeda dengan data yang hilang karena pengguna melewati suatu kolom isian, pelacakan gagal, perangkat tidak mendukung suatu event, atau nilainya memang tidak relevan. Penanganannya bergantung pada penyebab dan kebutuhan model. Pilihannya antara lain mempertahankan nilai yang hilang sebagai kategori tersendiri, imputasi dengan median atau modus, imputasi berbasis model, mengeluarkan baris, atau memperbaiki pengumpulan data di hulu. Untuk pemodelan, saya hanya akan melakukan fitting imputasi pada data latih, lalu menerapkannya pada data validasi/uji untuk menghindari leakage. Saya juga akan mengevaluasi apakah keberadaan nilai yang hilang itu sendiri bersifat prediktif. Misalnya, data pendapatan yang kosong pada dataset kredit atau kolom profil yang kosong pada produk konsumen bisa membawa sinyal, tetapi memakainya dapat menimbulkan masalah keadilan atau kepatuhan.

Kerangka: Deteksi -> diagnosis -> putuskan berdasarkan makna bisnis

Metode deteksi outlier antara lain statistik ringkasan, histogram, box plot, z-score, aturan IQR, ambang persentil, dan pendekatan berbasis model. Namun, deteksi hanyalah langkah pertama. Pertanyaan pentingnya adalah apakah outlier tersebut merupakan kesalahan, kasus langka yang valid, atau justru bagian terpenting dari distribusi. Saya akan memeriksa outlier berdasarkan sumber, timestamp, segmen, dan data mentahnya. Usia negatif kemungkinan besar adalah kesalahan data. Pembelian enterprise yang sangat besar mungkin valid dan tidak boleh dihapus dari analisis pendapatan tanpa alasan. Untuk pemodelan, outlier mungkin memerlukan transformasi, winsorization, model yang robust, atau penanganan khusus per segmen. Hapus outlier hanya jika ada alasan yang dapat dipertanggungjawabkan: nilai yang mustahil, event duplikat, bug instrumentasi, akun uji, atau data di luar cakupan analisis. Jika outlier yang valid memengaruhi kesimpulan, laporkan analisis sensitivitas dengan dan tanpa outlier tersebut.

Kerangka: Kualitas metrik -> diagnosis funnel -> segmentasi -> mekanisme -> tindakan

Klik bisa jadi proksi nilai yang lemah. Pertama, verifikasi hasilnya dan definisikan funnel-nya: impresi, klik, add-to-cart, checkout, pembelian, refund, dan perilaku pembelian ulang. Jika klik naik tetapi pembelian turun, rekomendasi tersebut mungkin hanya memancing rasa penasaran tanpa niat membeli, atau mengalihkan pengguna dari jalur yang lebih baik. Segmentasikan berdasarkan jenis pengguna, sumber trafik, kategori produk, perangkat, dan posisi tampilan rekomendasi. Pengguna baru mungkin lebih sering mengeklik karena modulnya mencolok, tetapi kemudian menemukan item yang tidak relevan. Alur pembelian normal pengguna lama mungkin justru terganggu. Periksa kualitas rekomendasi: relevansi, ketidaksesuaian harga, ketersediaan, waktu pengiriman, keberagaman, dan apakah item yang direkomendasikan sedang kehabisan stok atau bermargin rendah. Periksa juga latensi dan perubahan tata letak halaman. Saran saya: jangan merilis fitur ini hanya berdasarkan klik. Lakukan rollback, batasi eksposur pada segmen yang pembeliannya tetap sehat, atau rancang ulang fungsi objektif agar mengoptimalkan kualitas pembelian di ujung funnel, bukan click-through rate.

Kerangka: Likuiditas -> kualitas -> keseimbangan -> retensi -> unit economics

Kesehatan marketplace bergantung pada kedua sisinya. Konsep intinya adalah likuiditas: apakah permintaan dapat menemukan pasokan yang sesuai dengan cepat, dan apakah pasokan mendapatkan permintaan yang cukup agar tetap aktif? Metriknya bergantung pada jenis marketplace. Untuk ride-hailing: match rate, waktu hingga mendapat pengemudi (time to match), ETA, tingkat pembatalan, utilisasi pengemudi, tingkat pemesanan ulang penumpang, frekuensi lonjakan harga (surge), dan cakupan geografis. Untuk marketplace freelance: persentase pekerjaan yang menerima penawaran dari freelancer yang memenuhi syarat, waktu hingga penawaran pertama, tingkat perekrutan, penyelesaian proyek, tingkat sengketa, perekrutan ulang, dan utilisasi penyedia jasa. Segmentasikan berdasarkan wilayah, kategori, jam dalam sehari, kohort pengguna, tier pasokan, dan niat permintaan. Angka rata-rata marketplace menyembunyikan ketidakseimbangan lokal. Sebuah marketplace bisa tampak sehat secara keseluruhan, padahal gagal di kota atau kategori tertentu. Guardrail-nya mencakup trust & safety, fraud, keluhan kualitas, refund, churn di kedua sisi, dan unit economics. Rekomendasi harus mengidentifikasi sisi mana yang menjadi kendala, pasokan atau permintaan, karena pengungkit pertumbuhannya sama sekali berbeda.

Kerangka: Nilai bagi pengguna -> perilaku berulang -> hasil belajar -> guardrail

North Star metric harus menangkap nilai jangka panjang bagi pengguna, bukan sekadar aktivitas. Untuk aplikasi belajar bahasa, jumlah sesi harian saja mungkin terlalu dangkal karena pengguna bisa membuka aplikasi tanpa benar-benar belajar. Kandidat yang lebih baik bisa berupa jumlah pelajar aktif mingguan yang menyelesaikan pelajaran bermakna dengan akurasi yang memadai, atau jumlah menit belajar mingguan yang memenuhi kriteria kualitas. Saya akan mempertimbangkan nilai intinya: membantu pengguna mengalami kemajuan dalam suatu bahasa. Metrik input bisa mencakup jumlah pelajaran yang dimulai, pelajaran yang diselesaikan, hari beruntun (streak), akurasi, penyelesaian review, latihan berbicara, dan kenaikan level. Metrik hasil bisa mencakup retensi, konversi langganan, peningkatan hasil tes penempatan, atau asesmen kemahiran eksternal jika tersedia. Guardrail: kelelahan (burnout), penyelesaian kilat yang berkualitas rendah, kecurangan, pengguna yang menonaktifkan notifikasi, churn, dan rasa frustrasi pengguna. Jika metriknya hanya menghargai waktu yang dihabiskan, metrik itu bisa mendorong latihan berulang yang melelahkan, bukan pembelajaran yang sesungguhnya. Saya akan mendefinisikan North Star bersama stakeholder produk dan pakar ilmu pembelajaran, lalu memvalidasi apakah metrik itu memprediksi retensi dan kemajuan yang dilaporkan pengguna.

Kerangka: Tujuan -> label -> fitur -> metrik -> intervensi -> pemantauan

Pertama, definisikan fraud dan tindakan yang akan diambil. Apakah kita akan memblokir transaksi, mengirimnya ke peninjauan manual, mewajibkan autentikasi tambahan (step-up authentication), atau memberi skor risiko? Tujuan model harus sesuai dengan intervensinya karena positif palsu dapat merugikan pelanggan yang sah. Label bisa berasal dari chargeback, investigasi fraud yang terkonfirmasi, laporan pengguna, atau penanda berbasis aturan. Label ini datang terlambat dan tidak sempurna, jadi perhitungkan keterlambatan dan noise pada label. Fiturnya bisa mencakup nominal transaksi, merchant, perangkat, ketidaksesuaian IP/lokasi, usia akun, velocity transaksi, riwayat metode pembayaran, percobaan yang gagal, jarak pengiriman, dan sengketa sebelumnya. Mulailah dengan aturan dan baseline sederhana, lalu bandingkan model seperti regresi logistik, gradient boosted trees, atau deteksi anomali, tergantung kualitas labelnya. Evaluasi harus menekankan precision-recall, recall pada kapasitas peninjauan yang tetap, tingkat positif palsu bagi pengguna yang sah, nilai fraud yang berhasil ditangkap dalam dolar, dan kalibrasi. Deployment menuntut pemantauan drift, adaptasi dari pelaku fraud, keadilan, latensi, kapasitas peninjauan manual, feedback loop, dan rollback. Model fraud bukan sekadar masalah prediksi; model ini adalah sistem operasional.

Kerangka: Definisi target -> ketersediaan fitur -> metrik -> kalibrasi -> dampak bagi pengguna

Definisikan target sebagai durasi pengiriman aktual sejak pesanan dikonfirmasi hingga tiba, atau pecah menjadi beberapa komponen: waktu persiapan, penugasan kurir, waktu penjemputan, waktu perjalanan, dan serah terima. Pemodelan per komponen bisa lebih mudah diinterpretasikan dan lebih berguna secara operasional. Fitur yang tersedia saat prediksi bisa mencakup restoran, jenis masakan, jam dalam sehari, hari dalam seminggu, cuaca, jarak, ketersediaan kurir, antrean pesanan saat ini, riwayat waktu persiapan, lalu lintas, ukuran pesanan, dan zona geografis. Hindari fitur yang belum diketahui saat prediksi, seperti waktu penjemputan aktual jika prediksi dilakukan saat pesanan dibuat. Metrik harus mencerminkan pengalaman pengguna. MAE mudah ditafsirkan, tetapi estimasi yang terlalu rendah bisa lebih buruk daripada estimasi yang terlalu tinggi. Kalibrasi juga penting: jika kita menjanjikan rentang waktu pengiriman, pesanan harus tiba dalam rentang itu sesuai tingkat yang diharapkan. Hal yang perlu diperhatikan saat deployment antara lain latensi, kesegaran fitur real-time, restoran baru yang belum punya riwayat (cold start), hari libur, cuaca ekstrem yang datang mendadak, dan feedback loop karena ETA yang ditampilkan memengaruhi keputusan pengguna. Pantau error berdasarkan restoran, zona, waktu, dan segmen pelanggan.

Kerangka: Masalah -> metode -> keputusan -> dampak -> pelajaran

Pilih proyek ketika hasil kerja Anda berhasil mengubah keputusan, produk, proses, atau metrik. Awali dengan masalah bisnisnya dan alasan masalah itu penting. Lalu jelaskan metode Anda dengan tingkat detail yang pas: sumber data, analisis atau model, validasi, dan trade-off. Jawaban terkuat menghubungkan pekerjaan teknis dengan tindakan bisnis. Misalnya, model churn membantu tim customer success memprioritaskan penjangkauan, eksperimen mengubah keputusan peluncuran, atau analisis harga meningkatkan pendapatan tanpa menurunkan konversi. Kuantifikasi dampaknya jika memungkinkan: kenaikan pendapatan, penurunan churn, waktu yang dihemat, pengurangan biaya, penargetan yang lebih baik, atau pengambilan keputusan yang lebih cepat. Jelaskan juga keterbatasannya dan apa yang akan Anda perbaiki selanjutnya. Jangan menjadikan jawaban sebagai tur penggunaan tool. Pewawancara tidak terlalu peduli library apa yang Anda pakai; mereka lebih peduli apakah pekerjaan Anda benar, dipercaya, diadopsi, dan bermanfaat.

Kerangka: Keputusan -> intuisi -> bukti -> keterbatasan -> tindakan

Saya memulai dari keputusan yang perlu diambil stakeholder, bukan dari arsitektur model. Lalu saya menjelaskan intuisi model dengan bahasa sederhana: apa yang diprediksi, sinyal apa yang digunakan, seberapa akurat, dan kapan model itu tidak boleh dipercaya. Saya menggunakan contoh, feature importance atau reason code jika sesuai, plot kalibrasi, dan grafik trade-off sederhana seperti precision versus recall. Saya tidak berpura-pura bahwa model itu ajaib. Stakeholder perlu memahami keterbatasannya: kualitas data, ketidakpastian, bias, drift, dan edge case. Terakhir, saya menghubungkan model dengan tindakan. Misalnya, “Model ini mengidentifikasi 10% akun teratas yang paling mungkin churn, tetapi nilainya baru muncul ketika kita menguji apakah penjangkauan ke kelompok itu meningkatkan retensi.” Cara ini menjaga diskusi tetap berfokus pada keputusan dan hasil.

Kerangka: Ekspektasi -> bukti -> komunikasi -> keputusan -> hasil

Pilih contoh nyata ketika bukti menantang rencana yang sudah diunggulkan. Jelaskan apa yang diharapkan stakeholder, data apa yang Anda analisis, dan mengapa kesimpulannya berbeda. Uraikan proses validasinya secara spesifik karena kredibilitas sangat menentukan dalam situasi seperti ini. Lalu ceritakan bagaimana Anda menyampaikan temuan tersebut. Jawaban yang kuat menunjukkan diplomasi: mengakui tujuan stakeholder, menyajikan bukti dengan jelas, menjelaskan ketidakpastian, dan menawarkan alternatif. Tujuannya bukan memenangkan perdebatan, melainkan membantu tim mengambil keputusan yang lebih baik. Tutup dengan hasilnya. Mungkin tim menunda peluncuran, mengubah penargetan, menjalankan uji yang lebih kecil, atau memilih metrik yang berbeda. Jika stakeholder mengabaikan rekomendasi Anda, jelaskan apa yang terjadi dan apa yang Anda pelajari tentang cara memengaruhi orang lain dan berkomunikasi.