Petunjuk dan konteks
Pewawancara ingin mengetahui bagaimana Anda menangani perbedaan pendapat teknis, bukan apakah Anda dapat mengatakan "Saya menegakkan standar saya." Bayangkan sebuah pull request di mana Anda yakin kompleksitas konkurensi baru, risiko privasi, atau pengujian yang terlewat akan mengurangi kesehatan kode; penulis menganggapnya masalah kecil dan meminta untuk menggabungkannya (merge) terlebih dahulu. Jelaskan fakta, diskusi, keputusan, dan hasilnya.
Google Engineering Practices merekomendasikan untuk memeriksa apakah penulis memiliki konteks yang lebih baik, lalu menjelaskan kekhawatiran tersebut dari sudut pandang kesehatan kode. Jika kompleksitas akan tetap ada di basis kode, biasanya lebih baik untuk mengatasinya dalam perubahan saat ini; keadaan darurat adalah pengecualian. Jawaban yang kuat mendasarkan prinsip tersebut pada satu peristiwa kolaborasi yang dapat diverifikasi alih-alih mencap penulis sebagai orang yang sulit diajak bekerja sama.
Apa yang dievaluasi pewawancara
- Anda memeriksa ulang penilaian Anda sendiri dan dapat mengakui konteks yang dimiliki oleh penulis.
- Anda menjelaskan kekhawatiran dengan risiko, dampak pengguna, pengujian, dan biaya pemeliharaan daripada status atau gaya pribadi.
- Anda memisahkan pemblokir kebenaran logika (correctness), keamanan, privasi, atau regresi dari tugas lanjutan dan preferensi.
- Anda mengusulkan perubahan sekecil mungkin yang layak, mengundang peninjau yang tepat, dan menentukan jalur keputusan atau eskalasi.
- Anda mengukur hasilnya: cacat yang dihindari, penurunan jumlah rollback, waktu peninjauan, kepercayaan tim, dan peningkatan proses.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah perbedaan pendapat ini mengenai kebenaran logika, keamanan, privasi, performa, pemeliharaan, atau preferensi pengodean?
- Lapisan mana yang menjadi perhatian komentar tersebut: implementasi, pengujian, kontrak antarmuka, risiko rilis, atau kebijakan tim?
- Apakah penulis memberikan bukti baru, batasan historis, atau tenggat waktu? Siapa yang memegang keputusan teknis akhir?
- Apakah perubahan ini mendesak, dan dapatkah gray release, rollback, atau feature flag mengurangi risiko?
- Bagaimana Anda akan melindungi privasi penulis dan menjaga agar diskusi publik tidak menjadi penilaian pribadi?
Jawaban 30 detik
"Pertama-tama, saya mereproduksi atau memverifikasi fakta dan memeriksa apakah penulis memiliki konteks yang saya lewatkan. Jika masalah tersebut memengaruhi kebenaran logika, privasi, atau jelas-jelas menurunkan kesehatan kode, saya menggunakan jalur kode, hasil pengujian, dan risiko pengguna untuk menjelaskan mengapa masalah ini harus diselesaikan dalam perubahan ini, lalu mengusulkan perbaikan terkecil. Jika itu preferensi, saya menjadikannya non-blocking. Jika kami masih belum sepakat, saya mengundang peninjau domain atau lead teknis serta mencatat keputusan dan tindak lanjutnya. Saya mengakhiri dengan meninjau hasil delivery, kualitas, dan hubungan kerja."
Solusi langkah demi langkah
Langkah 1: Ubah penilaian pribadi menjadi klaim yang dapat diuji
Ganti "kode ini berbahaya" dengan "dua pembaruan bersamaan dapat menimpa nilai yang lebih baru karena tidak ada pemeriksaan versi." Berikan reproduksi masalah, log, pengujian, atau tolok ukur (benchmark). Pastikan komentar tetap berfokus pada kode dan risiko, jangan pernah pada kemampuan penulis. Tanpa bukti, ajukan pertanyaan sebelum memblokir.
Langkah 2: Periksa konteks Anda yang terlewat
Tanyakan tentang kontrak antarmuka, kompatibilitas, jendela rilis, tim yang bergantung, dan rollback. Panduan Google mencatat bahwa penulis mungkin lebih dekat dengan implementasi dan memiliki informasi yang lebih baik. Jika bukti baru membantah saran Anda, akui dan tarik kembali saran tersebut alih-alih memperlakukan kegigihan sebagai kualitas.
Langkah 3: Klasifikasikan komentar dan usulkan perubahan minimum
Klasifikasikan masukan sebagai pemblokir (blocker), saran non-blocking, atau penguatan positif. Pemblokir berkaitan dengan kebenaran logika yang dapat direproduksi, keamanan, privasi, atau risiko regresi berprobabilitas tinggi; preferensi gaya dapat berupa Nit atau konvensi yang terdokumentasi. Tawarkan patch kecil, pengujian, atau feature flag alih-alih refaktor yang tidak terkait dalam pull request yang sama.
Langkah 4: Jelaskan alasannya melalui kesehatan kode
Hubungkan perbaikan dengan biaya pemeliharaan di masa mendatang, pencegahan insiden, atau pengalaman pengguna. Jangan menempelkan tautan aturan tanpa menerapkannya pada jalur, dampak, dan kriteria penerimaan perubahan ini. Jika penulis meminta untuk "membersihkannya nanti", evaluasi apakah kompleksitas tersebut akan terlupakan atau mempersulit peninjauan di masa mendatang.
Langkah 5: Tetapkan jalur keputusan dan eskalasi
Rangkum kesepakatan dan pertanyaan terbuka dalam tinjauan. Jika diperlukan, jadwalkan diskusi singkat atau undang peninjau yang memiliki otoritas domain. Seorang lead teknis harus memutuskan berdasarkan bukti, kesehatan kode, dan batasan delivery, bukan jabatan. Lacak item non-blocker yang belum terselesaikan dengan penanggung jawab dan tenggat waktu.
Langkah 6: Verifikasi hasil dan tingkatkan proses
Sebelum merge, verifikasi pengujian, pemeriksaan statis, metrik peluncuran, dan rollback. Setelah merge, amati cacat, rollback, putaran peninjauan, dan waktu delivery. Jika penolakan yang sama terulang kembali, tingkatkan design review, templat pull request, atau dokumentasi alih-alih mengandalkan persuasi setiap saat. Batasi peninjauan untuk keadaan darurat tetapi catat risiko dan remediasinya.
Contoh jawaban yang kuat
"Selama migrasi cache konkuren, saya memberikan komentar bahwa penulisan data tidak memiliki pemeriksaan versi. Penulis menganggapnya teoritis dan meminta untuk melakukan merge. Saya mereproduksi nilai lama yang menimpa nilai baru dengan dua pembaruan bersamaan dan mengonfirmasi bahwa endpoint tersebut mengubah status pesanan, jadi itu adalah pemblokir kebenaran logika untuk perubahan ini. Saya mengakui bahwa penulis lebih memahami bidang kompatibilitas warisan (legacy), mempertahankan bidang tersebut, menambahkan penulisan berversi bersyarat, serta menambahkan pengujian konflik dan metrik."
"Kami meminta peninjau penyimpanan pesanan untuk memverifikasi desain dan setuju untuk memantau tingkat konflik serta rollback selama gray release. Penulis menerima patch kecil tersebut, dan peluncuran tidak mengalami penimpaan data lagi. Saya menjelaskan buktinya dalam peninjauan dan melacak refaktor cache yang lebih luas secara terpisah. Sebagai retrospeksi, tim menambahkan pengujian penulisan konkuren ke templat pull request, mengurangi perselisihan serupa."
Kesalahan umum
- Menggunakan senioritas atau 'aturannya memang begitu' → penulis tidak dapat melihat risikonya → tunjukkan jalur kode, bukti, dan pengujian penerimaan.
- Menjadikan setiap komentar sebagai pemblokir → delivery dan kepercayaan terganggu → pisahkan risiko, saran, dan preferensi.
- Menganggap penulis salah → konteks implementasi terlewatkan → periksa ulang dan tarik kembali saat bukti berubah.
- Memperlakukan 'bersihkan nanti' sebagai default → kompleksitas cenderung menetap → perbaiki sekarang atau tetapkan penanggung jawab dan batas waktu.
- Menilai seseorang dalam peninjauan publik → perbedaan pendapat menjadi konflik → diskusikan kode, dampak, dan langkah selanjutnya.
- Melewatkan metrik hasil → efektivitas tidak dapat dibuktikan → catat pengujian, peluncuran, cacat, waktu peninjauan, dan perubahan proses.
Pertanyaan lanjutan dan jawaban
Apa yang Anda lakukan ketika menyadari bahwa Anda salah?
Sampaikan fakta yang terlewat, tarik kembali pemblokir, dan jelaskan bukti baru secara terbuka. Ucapkan terima kasih kepada penulis atas konteksnya dan berhenti membela otoritas; tambahkan catatan singkat jika itu mencegah kesalahan berulang.
Bagaimana jika penulis mengatakan tenggat waktu mengharuskan merge segera?
Evaluasi apakah risiko memengaruhi kebenaran logika, keamanan, atau kepatuhan. Pertahankan pemblokir berisiko tinggi dan usulkan cakupan yang lebih kecil, feature flag, gray release, dan rollback yang jelas. Saran berisiko rendah dapat dibuat non-blocking dengan tindak lanjut yang memiliki penanggung jawab dan tanggal target.
Bagaimana jika kedua belah pihak tidak mencapai kesepakatan?
Tuliskan klaim, bukti, risiko yang dapat diterima, dan alternatifnya. Undang peninjau domain atau lead teknis untuk memutuskan, lalu catat alasannya dalam pull request agar pembaca di masa mendatang tidak membuka kembali perdebatan yang sama.
Bagaimana Anda menjaga agar peninjauan tidak menjadi hambatan (bottleneck)?
Diskusikan desain lebih awal, bagi menjadi pull request kecil, dan otomatisasi pengujian serta pemeriksaan gaya kode. Tinjau desain berisiko tinggi terlebih dahulu, kemudian saran lokal. Untuk keadaan darurat, pertahankan tinjauan minimal dan catatan remediasi.