Petunjuk dan konteks
Ceritakan tentang saat Anda dan tim dependen tidak sepakat mengenai kontrak API. Mereka meyakini usulan Anda akan menambah biaya pemeliharaan, sementara Anda khawatir membiarkan kontrak tanpa perubahan akan merusak keandalan. Bagaimana Anda mengklarifikasi fakta, mengambil keputusan, dan melakukan pengiriman (delivery)?
Pertanyaan ini menguji kolaborasi lintas tim, kompromi teknis (technical trade-offs), dan pengaruh. Panduan wawancara rekayasa Atlassian secara eksplisit mencari pemecahan masalah, ketangkasan belajar (learning agility), kolaborasi, dan komunikasi. Jawaban yang kuat menunjukkan batasan nyata, bukti yang dapat diverifikasi, keputusan bersama, dan hasil akhir alih-alih menggambarkan tim lain sebagai penghambat.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin mengetahui apakah Anda dapat mengubah ketidaksepakatan menjadi tujuan bersama, memisahkan fakta dari preferensi, menjelaskan kompromi kompatibilitas, keandalan, biaya, dan jadwal, mencatat keputusan serta kepemilikan (ownership), dan mengubah arah saat bukti berubah. Mereka juga memperhatikan apakah Anda melindungi kecepatan pengiriman tim dependen.
Pertanyaan klarifikasi
Konfirmasikan konsumen API, versi, SLO, sensitivitas data, jendela rilis, dan kegagalan yang tidak dapat diterima. Identifikasi apakah ketidaksepakatan berkaitan dengan semantik field, kontrak error, durasi kompatibilitas, atau kepemilikan operasional. Siapkan log, lalu lintas (traffic), sampel kegagalan, upaya migrasi, dan kondisi rollback yang dapat diverifikasi oleh kedua tim.
Jawaban 30 detik
“Pertama-tama saya membingkai ulang ketidaksepakatan menjadi tujuan bersama: memenuhi batasan keandalan dan pemeliharaan di dalam jendela rilis. Saya memisahkan fakta yang diketahui, asumsi, dan hal-hal yang belum diketahui, lalu mengundang tim dependen untuk memvalidasinya. Kami membandingkan biaya kompatibilitas, observabilitas, migrasi, dan rollback, kemudian menggunakan pengujian kecil yang dapat dibatalkan (reversible) untuk mengurangi ketidakpastian. Terakhir, kami mencatat keputusan, pemilik, tenggat waktu, dan sinyal rollback. Setelah rilis, kami memeriksa hasilnya dan mengubah pelajaran tersebut menjadi templat yang dapat digunakan kembali.”
Jawaban mendalam
Langkah 1: Selaraskan pada tujuan pengguna dan layanan
Jangan mulai dengan memperdebatkan desain field mana yang benar. Tuliskan dampak pada pengguna, target keandalan, waktu rilis, dan batasan pemeliharaan agar kedua tim mengoptimalkan hasil yang sama. Jika tujuan bertentangan, identifikasi siapa yang memegang kepemilikan atas kompromi produk atau arsitektur.
Langkah 2: Pisahkan fakta, asumsi, dan preferensi
Buat daftar volume panggilan sebenarnya, tingkat kegagalan, klien yang kompatibel, upaya migrasi, dan jendela dukungan. Beri label asumsi pada klaim tanpa data dan jadwalkan pemeriksaan yang dapat dibatalkan. Jangan gunakan senioritas, ukuran tim, atau volume bicara sebagai bukti.
Langkah 3: Bandingkan opsi kontrak
Bandingkan kontrak saat ini, perubahan kompatibel terkecil, dan desain jangka panjang. Untuk masing-masing opsi, catat semantik field, kode error, pembuatan versi (versioning), observabilitas, performa, pemeliharaan, dan rollback. Minta tim dependen mengisi biaya dari sisi mereka agar diskusinya bukan berupa “Anda meminta saya untuk berubah.”
Langkah 4: Rancang eksperimen yang dapat dibatalkan (reversible)
Mulailah dengan field opsional, dual writes, shadow traffic, atau consumer contract tests dan amati hasil nyatanya. Berikan batasan waktu (time box), ukuran keberhasilan, dan kondisi penghentian pada eksperimen tersebut; jangan biarkan lapisan kompatibilitas bertahan selamanya.
Langkah 5: Putuskan dan catat
Tulis konteks, opsi, alasan, risiko, pemilik, tenggat waktu, dan pemicu rollback dalam ADR atau catatan proyek. Orang-orang mungkin tetap memiliki perbedaan pendapat, tetapi mereka harus tahu kapan keputusan tersebut akan ditinjau kembali.
Langkah 6: Lindungi pengiriman tim dependen
Sediakan contoh migrasi, test fixtures, jendela kompatibilitas, dan waktu integrasi bersama. Jika perubahan Anda menambah beban kerja, nyatakan dukungan apa yang menjadi tanggung jawab Anda; jangan diam-diam melimpahkan tanggung jawab migrasi yang belum selesai kepada konsumen.
Langkah 7: Kelola risiko peluncuran dengan metrik
Tentukan tingkat error, latensi, tingkat field yang tidak dikenal, waktu rollback, dan keberhasilan konsumen sebelum rilis. Perluas traffic secara bertahap dan jeda atau rollback ketika ambang batas terlampaui alih-alih menunggu untuk saling menyalahkan.
Langkah 8: Pelajari dan ubah sistem
Periksa apakah hasil sesuai dengan asumsi dan catat bukti mana yang mengubah keputusan. Tambahkan templat kontrak, daftar periksa peninjauan, pengujian kompatibilitas, atau matriks tanggung jawab ke dalam proses agar perselisihan berikutnya muncul lebih awal.
Contoh jawaban model
Selama migrasi API status pesanan, tim konsumen khawatir bahwa hierarki error yang baru akan meningkatkan pemeliharaan klien, sementara saya khawatir error yang ambigu akan melipatgandakan percobaan ulang (retries) saat terjadi kegagalan. Kami sepakat untuk tetap mempertahankan jendela rilis sambil membedakan status yang dapat dicoba ulang dan yang tidak dapat dicoba ulang. Kami meninjau sampel error selama 30 hari, versi klien, dan volume retry, lalu menemukan bahwa dua status menyebabkan sebagian besar risiko. Kami menambahkan field yang kompatibel ke belakang terlebih dahulu serta menggunakan contract tests dan shadow traffic. Saya memegang kepemilikan atas contoh SDK, panduan migrasi, dan dasbor; tim lain memegang dua klien bervolume tinggi. ADR mencatat para pemilik, dua sinyal jeda, dan rollback. Kami meningkatkan traffic secara bertahap, melihat lebih sedikit permintaan duplikat, dan tidak menemukan kegagalan parsing pada klien lama. Retrospektif menambahkan templat kontrak error ke dalam tinjauan. Keputusan ini datang dari metrik bersama dan langkah-langkah yang dapat dibatalkan, bukan dari memaksakan preferensi saya.
Kesalahan umum
Menyebut tim lain lemah secara teknis
Tim dependen biasanya memahami batasan konsumen. Mengabaikannya akan menyembunyikan biaya migrasi dan tidak menunjukkan pembangunan kepercayaan.
Hanya mendeskripsikan desain akhir
Pewawancara perlu melihat bagaimana Anda membandingkan trade-offs. Jelaskan setidaknya dua opsi, buktinya, dan mengapa salah satunya ditolak.
Tidak memberikan hasil terukur atau kepemilikan
“Semua orang setuju” bukanlah sebuah hasil. Sebutkan metrik, rentang waktu, pekerjaan Anda, dan risiko yang tersisa.
Pertanyaan lanjutan dan jawaban
Bagaimana jika tim lain masih tidak setuju?
Periksa apakah fakta baru telah mengubah perselisihan, lalu minta pemilik arsitektur atau produk yang ditunjuk oleh proses pengambilan keputusan untuk memilih. Catat ketidaksepakatan, risiko, dan tanggal peninjauan sambil tetap mengirimkan langkah terkecil yang dapat dibatalkan.
Bagaimana jika hanya tersisa dua hari sebelum rilis?
Kurangi cakupan, lindungi risiko yang tidak dapat diubah (irreversible) dan konsumen kritis, serta gunakan field yang kompatibel, flag, atau verifikasi shadow. Nyatakan apa yang ditunda; jangan mengganti rollback dengan janji lisan.
Bagaimana Anda menunjukkan bahwa desain tersebut tidak over-engineered?
Sebutkan kapabilitas yang Anda hilangkan, bandingkan traffic aktual dan biaya kegagalan, beri batas waktu pada lapisan kompatibilitas, dan rencanakan penghapusannya. Biarkan bukti yang menentukan kompleksitas.
Bagaimana jika data membuktikan penilaian Anda salah?
Akui bahwa asumsi tersebut salah, perbarui ADR dan ambang batas, pilih jalur yang lebih aman, dan tunjukkan bagaimana Anda membagikan bukti baru tersebut kepada tim yang terdampak.
Bagaimana Anda mencegah perselisihan yang sama terulang kembali?
Ubah keputusan kontrak, versi, error, jendela kompatibilitas, dan kepemilikan menjadi sebuah templat. Tambahkan consumer contract tests dan daftar periksa rilis dengan peninjauan singkat sebelum penulisan kode.
Bagaimana hal ini menunjukkan pengaruh alih-alih kontrol?
Tekankan bahwa Anda menciptakan tujuan bersama, bukti, dan keputusan yang dapat dibatalkan sembari bertanggung jawab atas pekerjaan pendukung. Timlah yang memilih hasilnya; Anda tidak mendominasi tim lain.