Permintaan untuk Menghentikan Tantangan Coding yang Tidak Realistis
(blackentropy.bearblog.dev)- Tugas coding yang tidak realistis dalam sebagian wawancara teknis menciptakan situasi bertekanan yang berbeda dari pekerjaan nyata, dan tidak mampu mengukur kemampuan kerja praktis developer dengan tepat
- Tugas bertekanan tinggi yang dikerjakan sendirian tidak mencerminkan lingkungan kerja yang melibatkan kolaborasi dan dukungan, serta mudah berubah menjadi debugging codebase lama tanpa dokumentasi atau bantuan tim
- Bahkan tugas yang disebut perusahaan sebagai “tugas 4 jam” bisa meluas menjadi 8–10 jam atau lebih jika ditambah riset tentang perusahaan, peninjauan kebutuhan peran, dan merapikan hasil akhir
- Tugas dengan stack teknologi yang tidak relevan dengan peran sering dibenarkan atas nama penilaian adaptabilitas, tetapi meminta developer Ruby melakukan debugging PHP bisa meleset dari kecocokan nyata terhadap pekerjaan
- Rekrutmen seharusnya berfokus pada teknologi yang relevan, pemecahan masalah, kolaborasi, dan potensi berkembang alih-alih tugas bertekanan tinggi yang arbitrer; tugas yang berlebihan bisa membuat kandidat bagus kelelahan dan mundur
Tugas wawancara yang tidak selaras dengan pekerjaan nyata
- Sebagian wawancara teknis meminta developer menyelesaikan tugas seperti debugging PHP lawas atau membuat mini-app dalam beberapa jam
- Tugas individu seperti ini berbeda dari cara kerja nyata
- Dalam pekerjaan, biasanya ada kolaborasi tim dan dukungan yang diperlukan bisa didapat
- Situasi harus cepat-debug codebase lama sendirian tanpa dokumentasi atau bantuan tim tidak sesuai dengan lingkungan pengembangan pada umumnya
- Perusahaan melihat ini sebagai penilaian atas “kemampuan memecahkan masalah”, tetapi jika tugasnya tidak terhubung dengan tuntutan nyata dari peran tersebut, akan sulit menilai kecocokan praktis kandidat
Biaya waktu tersembunyi dan beban bagi kandidat
- Durasi yang disarankan untuk tugas coding sering tidak cukup mencerminkan waktu yang benar-benar dihabiskan kandidat
- Sebelum mengerjakan tugas, kandidat perlu meneliti perusahaan dan meninjau kebutuhan peran
- Waktu juga dibutuhkan untuk merapikan proyek agar hasil yang dikumpulkan berada dalam kondisi baik
- Tugas “4 jam” bisa berkembang menjadi 8 jam, 10 jam, atau bahkan lebih
- Bagi developer yang harus menyeimbangkan pekerjaan dan kehidupan pribadi, ini bisa terasa seperti kerja tanpa bayaran demi pekerjaan yang bahkan belum didapat
Saat penilaian adaptabilitas meleset
- Tugas dengan stack teknologi yang tidak terkait kadang dibenarkan sebagai penilaian atas “adaptabilitas”
- Meminta developer Ruby melakukan debugging PHP, terlepas dari pentingnya adaptabilitas, bisa menjadi tolok ukur yang tidak tepat untuk menilai nilai seorang kandidat
- Kemampuan menangani tugas yang ambigu dan tidak relevan dengan cepat saja tidak cukup untuk menentukan apakah seseorang cocok dengan peran nyata
- Sebagian tugas bisa terasa lebih seperti cara perusahaan memamerkan standar “elit” daripada alat menilai kecocokan kandidat
- Jika setiap perekrutan memasang penghalang ala “1% teratas”, kandidat berpengalaman yang sebenarnya bisa bekerja dengan baik pun dapat mundur karena situasi yang dibuat-buat dan penuh tekanan
Apa yang seharusnya dinilai oleh tugas rekrutmen
- Proses rekrutmen harus dirancang dengan berfokus pada keterampilan konkret yang dibutuhkan oleh peran tersebut
- Hindari tugas ala bootcamp coding yang tidak terkait dengan tuntutan kerja nyata
- Fokus pada pemecahan masalah, kolaborasi, dan potensi berkembang di area yang relevan
- Adaptabilitas seharusnya dinilai sebagai kemampuan untuk belajar dalam jangka panjang, bukan seberapa cepat seseorang menyelesaikan tugas yang arbitrer
1 komentar
Komentar di Hacker News
Kapan terakhir kali kamu men-debug codebase lama tanpa dokumentasi maupun bantuan tim? Selalu begitu. Isinya 300–400 ribu baris C++, dan “legacy” berarti sama sekali tidak ada pengujian, dokumentasinya nyaris tidak ada, sementara sebagai satu-satunya developer di perusahaan kecil saya harus terus melayani puluhan ribu pengguna sambil memperbaiki bug dan menambahkan fitur.
Contoh terbaru: ada patch untuk fitur inti yang sudah mengendap lebih dari setahun, penulis aslinya sudah tidak ada, dan saya harus menulis ulang kodenya dari awal atau menghidupkan kembali patch itu agar sesuai dengan
master.Kemampuan untuk terjun ke proyek dan mengarahkan orang-orang menuju tujuan jelas merupakan keterampilan yang dibutuhkan developer senior, dan saya setuju dengan kesimpulan bahwa kemampuan memecahkan masalah perlu diuji. Namun isi wawancara teknis harus berbeda tergantung perannya; tidak perlu menanyakan algoritma graf di papan tulis kepada developer web junior, tetapi developer senior atau arsitek untuk produk jejaring sosial memang harus memahaminya secara mendalam.
Minggu lalu saya juga men-debug kode Go dari tahun 2020 yang sama-sama tanpa komentar maupun dokumentasi; itu juga bagian inti sistem dan tampak seperti ditulis oleh orang-orang gila. Menyakitkan.
Menurut saya, kemauan untuk menggali ke bawah demi menyelesaikan masalah di lapisan yang tepat adalah salah satu soft skill besar yang membedakan engineer senior. Alih-alih mengakali bug atau fitur yang hilang di lapisan bawah dengan koreksi susulan di kode sendiri, memperbaikinya di lapisan yang benar membuat seluruh sistem lebih kokoh terhadap perubahan di atas dan bawah stack serta use case masa depan yang tidak terduga.
Sebaliknya, jika pendekatan seperti ini tidak dilakukan, codebase mulai membusuk setelah engineer senior keluar atau digantikan oleh junior. Misalnya, jika untuk setiap edge case parsing input kita terus menambahkan satu regex validasi naif lagi di depan parser yang menakutkan dan buram, alih-alih memperbaiki tata bahasa parser itu sendiri, codebase sedang berevolusi menjadi gumpalan lumpur.
Tentu saja, memperbaiki di lapisan yang benar sering membuat perusahaan harus memelihara branch hotfix jangka panjang privat yang kecil untuk software ekosistem yang dipakai di stack. Upstream biasanya tidak menganggap masalah itu sebagai masalah dan tidak akan menerima patch, jadi kita harus menyimpannya sendiri.
Sebagai candaan, mungkin senioritas seorang engineer bisa diukur jauh lebih sederhana daripada coding test dengan mengautentikasi profil GitHub lalu menghitung berapa kali ia membuat atau memelihara branch hotfix privat jangka panjang semacam ini.
Berpura-pura seolah itu tidak berguna di dunia nyata tidak akan membantu. Dunia nyata itu berantakan, dokumentasi sering tidak ada atau tidak bisa dipercaya, dan orang atau tim yang menulis kode awalnya mungkin sudah tidak ada.
Ada anekdot kecil. Pasangan seorang teman berhenti kerja awal tahun ini, lalu menyiapkan wawancara untuk tiap perusahaan Big Tech selama 4–6 minggu. Untuk Meta 4–6 minggu, Stripe 4–6 minggu, dan seterusnya; di sela-selanya ia juga menjalani wawancara acak untuk berlatih dan membangun muscle memory, meneliti soal-soal yang mungkin keluar di tiap perusahaan, lalu mengerjakan LeetCode beberapa jam sehari
Hasilnya berjalan baik, dan ia menerima tawaran L6/staff dari MAANG. Namun ketika kami mengobrol minggu ini, katanya ia bahkan belum mulai peran barunya, tetapi sebagian besar detail yang ia latih sudah ia lupakan. Ia bilang persiapan system design paling berat karena tidak punya pengalaman system design, tetapi sekarang ia sudah menjadi staff eng di MAANG. Dari pengalaman nyata mengerjakan proyek kecil bersama, ia memang bagus, tetapi bukan engineer yang luar biasa menonjol
Ini benar-benar aneh, dan sepertinya menjelaskan banyak hal tentang siklus boom dan bust dalam perekrutan. Kalau melihat video persiapan wawancara system design, rasanya hampir seperti naskah. Tinggal masuk wawancara dan mengikuti naskah; apakah kandidat benar-benar pernah merancang sistem serupa atau yang lebih kompleks tampaknya tidak penting. Tujuan wawancara system design pada akhirnya sepertinya adalah “apakah tahu naskahnya”
Jika menonton dua video ini berurutan pada kecepatan 2x, mengejutkan betapa miripnya proses itu dengan menjalankan naskah: https://www.youtube.com/watch?v=4_qu1F9BXow, https://www.youtube.com/watch?v=_K-eupuDVEc
Kedua orang tua saya berada di industri teknologi Santa Cruz pada 1980–1990-an, dan saat itu talent pool tidak besar, jadi ini adalah alat inklusif untuk mencari orang yang bisa dikembangkan menjadi developer. Industri sekarang mengadopsi praktik itu, tetapi membuatnya menjadi kebalikannya: eksklusif
Salah satu orang yang saya rekrut adalah fisikawan; ia sama sekali tidak tahu istilah teknis dan ketakutan saat pertama kali melihat soal whiteboard. Setelah saya membimbingnya sampai ke titik yang nyaman, ia mulai bercerita tentang alat-alat yang ia buat untuk membantu pekerjaan fisika, dan terkejut ketika saya mengatakan bahwa alat-alat yang ia buat tanpa pengetahuan pengembangan itu adalah software. Itu bukan hanya benar-benar software, tetapi juga sangat mengesankan, dan soal whiteboard adalah alat untuk menyingkap potensi
Saya paham perusahaan besar menginginkan widget yang bisa langsung dipasang alih-alih manusia, tetapi lucu bahwa mereka memakai sesuatu yang awalnya dibuat untuk tujuan yang persis berlawanan. Kadang saya malah merasa lega sudah cukup tua sehingga tidak punya harapan masuk ke perusahaan keren yang mengadakan code challenge seperti ini
Logikanya, apa pun universitasmu, kelas apa pun yang pernah kamu ambil, dan keuntungan atau kerugian apa pun yang kamu miliki, jika kamu punya kualitas yang dibutuhkan untuk peran itu, materi ini bisa dipelajari dalam beberapa bulan. Karena teknologinya sangat terstandardisasi, prosesnya juga menjadi cukup objektif
Mereka tidak mengharapkan kamu memakai teknik spesifik itu dalam pekerjaan nyata. Sebaliknya, kamu menunjukkan bahwa kamu bisa mempelajari jenis teknik seperti itu dan tampil pada level tinggi dalam situasi wawancara yang penuh tekanan. Logikanya, ini adalah sinyal yang baik apakah kamu bisa mempelajari teknik yang dibutuhkan untuk proyek yang nanti akan ditugaskan, dan bisa berkinerja di bawah tekanan deadline besar
Saya tidak sedang membela sistem ini, tetapi jelas ada logika di baliknya
Ia bilang sudah lupa, tetapi kalau ia mendapatkan posisi itu, kemungkinan besar ia bisa menyelesaikan soal LeetCode tingkat medium. Sulit percaya semuanya terlupakan; kemungkinan ia masih bisa menyelesaikan soal-soal mudah yang kebanyakan orang tidak bisa selesaikan spontan. Ia juga kemungkinan masih tahu kompleksitas operasi backend esensial seperti pencarian, pengurutan, array dan lookup hash, serta traversal tree dan graph
Dan bakat akting mungkin lebih umum di populasi luas daripada bakat pemrograman
Baru-baru ini saya menjalankan proses wawancara untuk peran engineer yang cukup senior di sebuah startup kecil. Saya percaya setiap orang cocok dengan format wawancara yang berbeda, jadi saya memberi semua orang pilihan
Karena saya sering melihat kemarahan terhadap tes take-home, saya mengira pilihan akan tersebar merata di antara ketiganya. Namun mengejutkan, sekitar 90–95% kandidat memilih tes take-home. Bagi saya itu data yang menarik karena kalau saya pelamar, itu juga format yang saya sukai, dan sangat mengejutkan bahwa mayoritas juga menyukainya
Wawancara tatap muka juga menuntut biaya yang cukup besar dari perusahaan, jadi bisa dianggap kemungkinan waktu saya terbuang lebih kecil. Asimetri dalam proses mencari kerja sudah makin besar, dan format take-home makin mempercepat tren itu
Seorang teman non-teknis masih memandang saya kurang baik karena dulu saya tidak menyelesaikan suatu tugas. Persyaratan intinya jelas-jelas sepele, tetapi instruksinya cukup kabur sehingga saya bisa menghabiskan berjam-jam hanya untuk menilai apakah hasilnya sudah cukup baik untuk dikirim. Selain itu, mereka mengharapkan set teknologi yang sempit; meski tidak sulit, saya tidak ingin mempelajarinya hanya demi kemungkinan membantu perusahaan yang katanya “tidak bisa menemukan talenta teknis”
Saya rasa saya akan lebih memilih nomor 1 dan 2 daripada nomor 3. Karena pewawancara perlu memahami masalah yang saya selesaikan agar bisa menilai pendekatan saya dengan lebih baik
Jika saya mengerjakannya di rumah lalu mengirimkannya belakangan, pewawancara dapat membandingkan solusi saya dengan solusi mereka sendiri atau solusi lain, dan lebih memahami gaya coding saya berdasarkan tugas yang sama
Jika kami mengerjakannya bersama lewat pairing, mereka bisa melihat proses berpikir saya, dan saya juga bisa menjelaskan dengan lebih baik mengapa memilih idiom tertentu
Kode masa lalu hampir tidak punya konteks. Itu hanya kode yang ditulis untuk proyek lain. Pada tahap awal, mengirimkannya bersama resume berguna untuk memastikan saya benar-benar bisa menulis kode, tetapi di tahap berikutnya baru akan mengesankan jika ada aplikasi yang berjalan dan saya bisa memandu mereka ke kode fitur tertentu. Namun berapa banyak orang yang begitu saja punya perangkat lunak yang berjalan? Biasanya yang ada hanya kode yang kurang lebih berjalan berkat beberapa trik
Saya lebih memilih nomor 1 daripada nomor 2. Karena peluang melakukan kesalahan berkurang. Daripada mengambil risiko gagal dalam 2 jam di tempat karena tekanan dan hukum Murphy, jelas lebih baik menghabiskan 2 jam tambahan di rumah dan punya waktu bebas untuk mencari tahu hal yang belum saya ketahui
Saya juga pernah berada di sisi yang menilai tes take-home, dan saya tahu betapa sulitnya membuat seseorang benar-benar terkesan lewat itu
Terakhir kali saya mengikuti wawancara coding sungguhan, saya bisa memilih bahasa pemrograman apa pun, dan juga bisa memilih satu dari 3 soal. Saya cukup menyukainya dan juga mendapat tawaran. Dalam wawancara berbatas waktu, bisa memilih Python alih-alih C++ terasa hampir seperti cheat
Semakin banyak keluhan tentang wawancara coding di internet, semakin kuat keyakinan saya bahwa wawancara coding adalah cara terbaik secara mutlak untuk menyaring kandidat posisi pengembangan perangkat lunak. Di seluruh industri ada terlalu banyak orang yang hanya pandai bicara, penipu identitas, dan orang yang pekerjaannya menjadwalkan rapat, sementara orang yang mau menyingsingkan lengan baju, terjun ke kode, dan benar-benar menyelesaikan pekerjaan justru kurang
Masalah ini makin parah di level yang lebih tinggi. Silakan mengeluh sesuka hati, tetapi pekerjaan FAANG yang nyaman dengan gaji 500 ribu dolar per tahun bukan sesuatu yang otomatis diberikan. Jika tidak mau mengulang pemrograman dasar dan menulis beberapa for loop, perusahaan akan beralih ke orang yang mau melakukannya
Jika wawancara benar-benar menguji kemampuan untuk menyingsingkan lengan baju dan terjun ke kode, saya tidak mengerti mengapa ketika masuk sebagai karyawan baru saya harus begitu sering menjelaskan praktik software engineering dan debugging kepada orang-orang yang sudah lama di sana
Jika pernah benar-benar bekerja di perusahaan besar, Anda akan tahu bahwa 90% pekerjaan nyata dilakukan oleh kurang dari 5% orang. Jika wawancara bekerja dengan benar, rasio ini seharusnya jauh lebih baik
Ada Cracking the Coding Interview, Elements of Programming Interviews in Java/Python/bahasa lain, LeetCode dan situs langganan premium berbayar, sampai bootcamp wawancara tiruan. Sekarang ini lebih mirip masalah mengakali sistem daripada kemampuan sebenarnya
Mengejutkan bahwa tidak ada disonansi kognitif sama sekali antara premis bahwa wawancara coding adalah metode perekrutan standar dan kenyataan bahwa hasilnya seburuk ini
Jika soalnya sesuatu seperti tokenisasi LLM, bagaimana cara melarang penggunaan LLM dalam soal “ML-LeetCode”?
Jika kandidat adalah ahli yang piawai coding dengan Cursor dan Claude, menyelesaikannya dalam 10 menit dengan 3 prompt dan memperbaiki 2 bug yang mudah ditemukan, serta punya paper setingkat NeurIPS dan kode open source, apakah saya menyaring penipu palsu atau justru menyaring kandidat papan atas?
Saya tidak melihat soal ala LeetCode masuk akal untuk orang yang bekerja di bidang terkait LLM. Suka atau tidak, ke depan makin banyak dari pekerjaan nyaman FAANG+ bergaji 500 ribu dolar per tahun akan berkaitan dengan LLM
Meminta developer Ruby men-debug PHP sebagai tes fleksibilitas terdengar seperti tes yang masuk akal. Developer yang bagus, terutama developer senior, seharusnya bisa melakukan hal semacam itu. Menggolongkan diri hanya sebagai “developer Ruby” adalah jebakan karier
Ada kalanya kita harus men-debug DSL lama yang spesifik vendor, atau kode yang framework dan standarnya sudah begitu tua sampai hampir menjadi bahasa lain
Ada juga pekerjaan menambahkan dukungan untuk fitur yang di-backport, atau menambal celah keamanan pada klien lama dan stack legacy. Di perusahaan besar, kami juga pernah bertanggung jawab atas kode escrow milik partner yang jauh lebih kecil
Menyiapkan lingkungan agar bisa benar-benar di-debug sering kali merupakan pekerjaan yang lebih besar daripada perbaikan sebenarnya. Meski begitu, ini tes yang bagus untuk level senior ke atas
Pewawancara berkata, “Coba balik array ini,” lalu saya menjawab, “Kalau di Python saya akan memakai array.reverse() atau reversed(array), dan di JS kemungkinan ada salah satunya, jadi mungkin metode .reverse.” Pewawancara berkata, “Tebakan yang bagus”
Saya keluar dengan perasaan benar-benar menikmatinya dan belajar beberapa hal, sementara mereka juga bisa melihat bagaimana saya menalar masalah baru
Saya sudah berkali-kali men-debug codebase lama tanpa dokumentasi maupun bantuan tim. Sistem yang pembuatnya sudah tidak ada, dan dokumentasinya tidak ada atau tidak bisa ditemukan, memang benar-benar ada. Jadi contoh ini tidak terlalu bagus. Kemampuan men-debug program, mengikuti alur request, dan melihat apa yang terjadi adalah keterampilan yang bagus
Namun bagian yang benar-benar buruk dari contoh ini adalah mengurung developer seperti ke dalam kotak merpati berdasarkan teknologi tertentu. Jika ada aplikasi PHP legacy, Anda akan menyaring keluar developer Java, Python, Ruby, atau Go yang sebenarnya punya kemampuan debugging seperti itu tetapi akan lebih lambat karena tidak tahu PHP. Padahal setelah beberapa bulan langsung menyentuh PHP, mereka bisa saja menjadi developer yang lebih kuat
Saya setuju bahwa “tugas 4 jam” mudah sekali melebar menjadi 8 jam, 10 jam, atau lebih demi menghasilkan sesuatu yang bagus. Waktu yang disebutkan mudah dimanipulasi, sehingga orang yang punya lebih banyak waktu bisa terlihat seperti kandidat yang lebih baik
Kapan saya men-debug codebase lama tanpa dokumentasi maupun bantuan tim? Setiap hari minggu ini
Kalau soal dokumentasi, kodenya terakhir diperbarui pada Juni, sedangkan dokumentasinya terakhir diperbarui pada Januari 2022
Kalau soal tim, separuh yang tidak di-PHK dua tahun lalu semuanya sudah pergi ke tempat yang lebih baik. Tentu saja ada tim yang memiliki proyek ini, tetapi mereka juga punya tiga proyek lain, dan selama setahun terakhir kontribusi mereka di sini hanya belasan baris, 11 di antaranya adalah update dependensi
Pernyataan seperti “ini seperti menyuruh developer Ruby men-debug PHP” dan “kalau pekerjaan membutuhkan teknologi tertentu, ujilah teknologi itu” terdengar seperti ucapan orang yang gagal dalam coding challenge
Secara serius, perusahaan jarang menerapkan praktik rekrutmen hanya untuk bersenang-senang. Biasanya itu adalah cara terbaik yang terpikir oleh kecerdasan kolektif mereka. Meminta praktik itu dihapus tanpa mencoba memahami masalah apa yang ingin mereka pecahkan dan tanpa menawarkan alternatif bukanlah hal yang produktif
Menurut saya dalam pengembangan software kita terlalu sering menciptakan ulang roda, alih-alih meminjam praktik dari profesi lain. Mari lihat proses rekrutmen seperti apa yang dilalui insinyur sipil agar mendapat setengah gaji developer software, lalu integrasikan itu ke praktik kita. Maka kita semua akan menjadi prajurit yang bahagia
Saya rasa kemungkinan mereka benar-benar merenungkan apa yang ingin dicapai sangat kecil. Mereka hanya ikut-ikutan karena orang lain melakukannya, dan percaya bahwa ada seseorang di suatu tempat yang merancang prosedur itu dengan maksud tertentu
Rekrutmen teknis sudah terlalu tersesat, sampai rasanya paling banter kita menetap di sesuatu yang tampak seperti maksimum lokal
Saya punya pengalaman sangat buruk di perusahaan yang sama sekali tidak melakukan tes coding. Hanya ada 2–3 wawancara
Masalahnya muncul ketika saya mulai bekerja dengan tim data engineering. Sebagian besar stack berbasis Hadoop, Kubernetes, Ruby, Python dan berbagai teknologi lain, serta membutuhkan pemahaman dasar tentang cloud computing
Namun pengalaman kerja dan latar belakang orang-orangnya terlalu beragam, sehingga alih-alih mengerjakan pekerjaan yang menjadi alasan saya direkrut, saya sering harus menambal kekurangan orang lain. Beberapa rekan kerja bahkan tidak bisa melakukan tugas dasar seperti packaging Python CLI dengan Docker atau memeriksa job Hadoop, sehingga saya banyak melakukan pekerjaan perekat untuk menutupinya
Pada akhirnya saya pergi. Bukan karena saya merasa istimewa, tetapi karena saya lelah menghabiskan 80% waktu untuk mendukung orang-orang yang direkrut pada level yang sama atau lebih tinggi. Saya akui praktik rekrutmen perusahaan itu sangat buruk, tetapi tes keterampilan dasar dalam bentuk apa pun tetap diperlukan
Pertanyaan penting lainnya adalah apakah Anda harus menjelaskan hal yang sama berulang kali kepada orang yang sama. Tidak tahu sesuatu masih bisa diterima, tetapi tidak mau belajar sulit diterima
Bagian menarik dari tes berbentuk tugas adalah adanya moral hazard yang mendorong orang menghabiskan lebih banyak waktu meskipun diminta “gunakan hanya X jam”. Jika perusahaan bertanya, muncul juga insentif untuk berbohong soal waktu yang benar-benar dihabiskan
Saya beberapa kali menekankan agar tetap sesuai waktu yang disarankan, menyelesaikan masalah secukupnya, lalu mengumpulkan tugas; tetapi dalam wawancara lanjutan saya pernah ditegur, “Kenapa X tidak diimplementasikan?”
Terkait ini, tes berbentuk tugas yang terlalu terbuka adalah tugas yang buruk. Karena itu menguntungkan orang yang punya lebih banyak waktu luang untuk mengerjakannya secara sangat teliti. Salam untuk tes berbentuk tugas data science yang meminta materi presentasi PowerPoint sebagai hasil akhir