Cara Menjelaskan Trade-off Teknis dalam Bahasa Inggris

"Kenapa kamu pakai PostgreSQL, bukan MongoDB?" "Kenapa tidak pakai microservices?" Pertanyaan seperti ini sering muncul di wawancara teknis, terutama untuk posisi menengah ke atas. Tujuannya bukan mencari jawaban "benar". Pewawancara ingin melihat apakah kamu memahami bahwa setiap pilihan punya harga.

Masalahnya, menjelaskan pertimbangan dalam bahasa Inggris itu sulit. Kalimatnya cenderung panjang dan penuh "but… and… so…". Artikel ini memberi rumus sederhana supaya jawabanmu terstruktur dan mudah diikuti.

Kenapa pewawancara menanyakan trade-off

Engineer junior biasanya bilang "A lebih bagus". Engineer yang lebih berpengalaman bilang "A lebih cocok untuk situasi ini, dan harganya adalah X". Perbedaan itu yang dicari.

Jawaban trade-off yang baik menunjukkan bahwa kamu:

• memahami kebutuhan bisnis atau produk, bukan hanya teknologi,
• tahu kelemahan pilihanmu sendiri,
• bisa mengubah keputusan kalau situasinya berubah.

Kabar baiknya, kamu tidak perlu kosakata canggih. Yang perlu adalah struktur yang jelas.

Rumus lima langkah

Gunakan urutan ini, satu atau dua kalimat per langkah:

1. Pilihan — sebutkan dua opsi yang dipertimbangkan.
2. Konteks — apa kebutuhan atau batasan saat itu.
3. Keputusan — apa yang dipilih.
4. Harga — apa kekurangan yang diterima.
5. Kapan berubah — dalam kondisi apa kamu akan memilih opsi lain.

Contoh lengkap:

We had two options: PostgreSQL or MongoDB. Our data had many relations, like orders and customers. So we chose PostgreSQL. The downside was slower schema changes. If the data became less structured, I'd look at MongoDB again.

Lima kalimat pendek, dan pewawancara langsung paham cara berpikirmu.

Kosakata dan frasa yang berguna

Frasa	Fungsi
We had two options: …	membuka perbandingan
The main concern was…	menjelaskan konteks
So we went with…	menyatakan keputusan
The downside is… / The cost was…	mengakui kekurangan
We accepted that because…	alasan menerima kekurangan
It depends on…	menunjukkan bahwa jawabannya tergantung kondisi
If X changes, I'd switch to…	kapan berubah pikiran
In hindsight, I'd…	refleksi terhadap keputusan lama

Hati-hati dengan "it depends". Frasa ini bagus, tapi harus langsung diikuti "on what". Kalau hanya berhenti di "it depends", terdengar seperti menghindar.

It depends on the traffic. For a few hundred users, a single server is fine. For heavy traffic, I'd add a cache first.

Contoh trade-off yang sering ditanyakan

Ganti detailnya dengan pengalamanmu sendiri. Kalau belum pernah menghadapi pilihan tertentu, katakan terus terang dan jelaskan bagaimana kamu akan menimbangnya.

Monolith vs microservices

We kept a monolith. The team was only three people. Microservices would add a lot of deployment work. The cost is that one bug can affect the whole app. If the team grew a lot, I'd split out the busiest parts.

Menambah cache

We added Redis to cache product pages. Pages loaded much faster. The downside is stale data for a short time. We accepted that because prices change rarely.

Membangun sendiri vs memakai layanan pihak ketiga

We used a payment gateway instead of building our own. It saved us months of work. The cost is a fee per transaction. We also depend on their uptime.

Kecepatan rilis vs kualitas

We shipped the first version without full tests. The client needed a demo in two weeks. We wrote tests for the payment flow only. After the demo, we added the rest.

Contoh terakhir ini bagus karena jujur: kamu tidak berpura-pura semua proyek dikerjakan dengan cara ideal. Cara menceritakan proyek secara utuh ada di cara menjelaskan proyek dalam bahasa Inggris.

Mengakui keputusan yang ternyata kurang tepat

Kadang pewawancara bertanya, "What would you do differently?" Ini kesempatan bagus, bukan jebakan. Mengakui keputusan lama yang kurang tepat menunjukkan bahwa kamu belajar.

In hindsight, I'd add monitoring earlier. We only found slow queries after users complained. Now I set up basic monitoring in the first week.

Polanya: apa yang terjadi → apa yang dipelajari → apa yang sekarang dilakukan berbeda. Jangan menyalahkan orang lain, dan jangan terlalu merendahkan diri. Cukup fakta dan pelajarannya.

Saat pilihanmu ditantang

Pewawancara sering sengaja menantang jawabanmu: "But what if traffic grows ten times?" atau "Why not just use a NoSQL database?" Ini bukan tanda jawabanmu salah. Mereka ingin melihat apakah kamu bisa berdiskusi dengan tenang, tanpa defensif dan tanpa langsung menyerah.

Langkah yang bisa dipakai: akui poinnya → jelaskan apa yang akan berubah → tetap jujur soal batas pengetahuanmu.

That's a fair point. At ten times the traffic, the database would be the bottleneck. I'd add read replicas first. Then I'd measure before changing anything bigger.

Good question. NoSQL would make schema changes easier. But we needed transactions for payments. For that part, I'd still keep PostgreSQL.

Kalau tantangannya menyentuh hal yang belum pernah kamu tangani, jangan berpura-pura ahli:

I haven't run a system at that scale. My guess is caching and queues would help first. I'd want to test that before deciding.

Jawaban seperti ini menunjukkan dua hal sekaligus: kamu paham arah solusinya, dan kamu tidak mengklaim pengalaman yang tidak kamu punya.

Kalimat pendek, satu ide per kalimat

Jebakan terbesar saat menjelaskan trade-off adalah kalimat yang terlalu panjang:

Terlalu panjang: We chose PostgreSQL because our data was relational and we needed transactions but it made schema changes harder so we had to plan migrations carefully which slowed us down a bit.

Bandingkan dengan:

Lebih jelas: We chose PostgreSQL. Our data was relational. We also needed transactions. The downside was harder schema changes. So we planned migrations carefully.

Isinya sama, tapi versi kedua jauh lebih mudah diucapkan dan dipahami. Teknik memecah kalimat dibahas lebih dalam di kalimat pendek, jawaban lebih jelas.

Kesalahan umum dan template siap isi

Hindari kesalahan berikut:

• Hanya menyebut kelebihan. Tanpa kekurangan, jawabanmu terdengar seperti iklan.
• Jawaban teori tanpa konteks. "MongoDB lebih scalable" tanpa menjelaskan kebutuhan proyekmu.
• Berhenti di "it depends". Selalu lanjutkan dengan "on what" dan contohnya.
• Mengklaim keputusan tim sebagai keputusanmu. Pakai "we decided" kalau itu keputusan bersama, dan sebutkan peranmu.
• Mengarang pengalaman. Kalau belum pernah memilih antara dua teknologi itu, jangan pura-pura. Jelaskan bagaimana kamu akan menimbangnya.

Lalu siapkan jawabanmu dengan template ini:

We had two options: [A] or [B]. The main concern was [kebutuhan/batasan]. So we went with [pilihan]. The downside was [kekurangan]. If [kondisi berubah], I'd consider [opsi lain].

Isi template ini untuk tiga keputusan teknis nyata dari proyekmu. Ucapkan keras-keras sampai lancar. Ketiganya bisa dipakai di wawancara teknis maupun sesi system design.

Ringkasan

Pertanyaan trade-off menguji kedewasaan teknis, bukan hafalan. Sebutkan dua pilihan, jelaskan konteks, nyatakan keputusan, akui harganya, dan sebutkan kapan kamu akan berubah pikiran. Gunakan kalimat pendek dan contoh dari proyekmu sendiri.

Kalau keputusan teknis dari proyekmu sudah tercatat di profil Repartee, naskah jawaban yang muncul saat wawancara akan memakai contoh nyata itu, bukan contoh karangan.