Perintah
Ceritakan tentang saat Anda menemukan risiko keandalan yang belum terukur dalam sebuah rilis, mendorong untuk menjeda atau mempersempit cakupannya, dan kemudian mendapatkan persetujuan untuk memulainya kembali dengan bukti. Pewawancara ingin mengetahui pertimbangan, komunikasi, tindakan, dan hasil Anda, bukan sekadar daftar istilah teknis.
Skenario dan batasan
Gunakan proyek nyata dengan batasan waktu yang jelas, pengguna atau layanan yang terpengaruh, sinyal yang tersedia saat itu, dan wewenang pengambilan keputusan Anda. Anda mungkin pernah menjeda peluncuran penuh, beralih ke canary kecil, atau menambahkan kemampuan rollback terlebih dahulu. Jangan menampilkan fakta yang baru diketahui belakangan sebagai bukti yang Anda miliki saat itu.
Hal yang diuji
Ujian ini menilai apakah Anda dapat mengubah intuisi menjadi risiko yang dapat diverifikasi, mengubah perbedaan pendapat menjadi tolok ukur keputusan bersama, dan menjaga keandalan tanpa mengorbankan pengiriman. Koordinasi peluncuran Google SRE menekankan keandalan dan komunikasi lintas tim; tinjauan insiden GitLab menekankan pemahaman terhadap keputusan daripada melimpahkan kesalahan ke individu.
Struktur jawaban referensi
Gunakan STAR-L: Situation (Situasi) memberikan jadwal peluncuran dan sinyal risiko; Task (Tugas) menyatakan dampak bagi pengguna dan wewenang yang Anda miliki; Action (Tindakan) menjelaskan bagaimana Anda mengusulkan jeda, menentukan metrik, mengatur validasi, menyelaraskan pemangku kepentingan, dan mempertahankan kemampuan rollback; Result (Hasil) memberikan hasil peluncuran, dampak bagi pengguna, dan perbaikan; Learning (Pembelajaran) menunjukkan bagaimana gerbang kontrol baru diterapkan ke dalam proses.
Detail penting
Kuantifikasi risiko dengan batas atas tingkat kesalahan (error-rate ceiling), latensi jalur kritis, sampel canary, durasi rollback, atau versi dependensi. Sebutkan siapa pemilik keputusan akhir, bagaimana setiap orang melihat data yang sama, dan kondisi apa yang memungkinkan peluncuran dilanjutkan. Sertakan kerugian yang berhasil dihindari dan biaya nyata dari penundaan tersebut.
Jebakan umum
Mengatakan bahwa orang lain mendengarkan karena Anda benar; hanya menjelaskan perbaikan teknisnya; menjadikan rekan kerja sebagai sumber risiko; mengklaim risiko nol; melaporkan keberhasilan tanpa memperhitungkan biaya akibat penundaan; atau mengganti tolok ukur konkret dengan sekadar "kami meningkatkan pemantauan."
Rubrik evaluasi
Jawaban yang kuat memiliki lini masa konkret, tindakan pribadi, dan hasil yang dapat diverifikasi. Jawaban tersebut mengakui adanya tekanan bisnis dan risiko keandalan, menjelaskan keputusan eskalasi dan peluncuran ulang, serta mengubah pembelajaran menjadi perubahan proses. Jawaban yang lemah berisi konflik abstrak, tanpa angka, atau tanpa kontribusi keputusan pribadi.
Pertanyaan lanjutan
Bagaimana jika pemimpin produk tidak setuju dengan penundaan tersebut?
Kumpulkan risiko, hal-hal yang belum diketahui, opsi yang dapat dibatalkan (reversible), dan tenggat waktu dalam satu dokumen keputusan. Usulkan canary terkecil atau validasi singkat. Jika hal itu melebihi wewenang Anda, gunakan jalur eskalasi yang telah disepakati, catat perbedaan pendapat, dan nyatakan risiko yang diterima.
Bagaimana Anda membuktikan bahwa jeda tersebut tidak menjadi hambatan tanpa batas waktu?
Tetapkan penanggung jawab, metode validasi, dan tenggat waktu untuk setiap hal yang belum diketahui, dengan gerbang peluncuran ulang yang eksplisit. Perbarui status setiap hari; lanjutkan saat gerbang terpenuhi, serta persempit cakupan atau evaluasi ulang jika tidak terpenuhi.
Bagaimana Anda menjaga agar evaluasi tetap bebas dari saling menyalahkan (blameless)?
Jelaskan kondisi sistem, sinyal yang terlewat, konteks keputusan, dan perubahan proses menggunakan lini masa faktual, bukan menduga-duga motif pribadi. Sebutkan perilaku Anda sendiri yang perlu diperbaiki dan pantau apakah tindak lanjut diselesaikan.