Panduan Wawancara Software Engineer

Kerangka: Pencarian komplemen

Pendekatan brute force memeriksa setiap pasangan sehingga butuh O(n^2). Pendekatan yang lebih baik memakai hash map dari nilai ke indeks. Saat kita memindai array, untuk setiap angka x, nilai yang kita butuhkan adalah target - x. Jika komplemen tersebut sudah ada di map, kita kembalikan indeks saat ini dan indeks yang tersimpan. Jika belum, simpan x beserta indeksnya, lalu lanjutkan. Gagasan kunci yang menjamin ketepatannya: saat kita memproses indeks i, map berisi tepat nilai-nilai dari indeks sebelumnya. Artinya, jika ada pasangan valid yang berakhir di i, kita akan langsung menemukannya. Cara ini juga mencegah elemen yang sama terpakai dua kali karena kita hanya mencocokkan dengan elemen sebelumnya. Kompleksitas waktunya O(n) karena setiap nilai dimasukkan dan dicari satu kali. Kompleksitas ruangnya O(n) untuk map. Edge case yang perlu diperhatikan meliputi nilai duplikat, bilangan negatif, nol, dan kondisi tanpa pasangan valid jika soal memungkinkan kasus itu.

Kerangka: Sliding window dengan indeks kemunculan terakhir

Gunakan sliding window yang selalu berisi karakter unik. Simpan pointer left dan map dari karakter ke indeks kemunculan terakhirnya. Iterasikan right di sepanjang string. Jika karakter saat ini pernah muncul di dalam window yang sedang berjalan, geser left ke satu posisi setelah indeks sebelumnya. Lalu perbarui indeks karakter tersebut dan catat panjang window maksimum. Detail pentingnya: left hanya boleh bergerak maju. Jika sebuah karakter terakhir muncul sebelum window saat ini, karakter itu tidak boleh membuat window menyempit. Itulah sebabnya pembaruannya ditulis left = max(left, lastSeen[char] + 1). Kompleksitas waktunya O(n) karena setiap karakter diproses satu kali dan pointer left hanya bergerak maju. Kompleksitas ruangnya O(k), dengan k adalah ukuran himpunan karakter. Edge case meliputi string kosong, semua karakter unik, semua karakter berulang, serta Unicode jika bahasa pemrogramannya memperlakukan karakter secara berbeda dari byte.

Kerangka: Kunci kanonis

Anagram memiliki komposisi karakter yang sama. Buat kunci kanonis untuk setiap kata, lalu kelompokkan kata-kata berdasarkan kunci tersebut di hash map. Kunci yang paling sederhana adalah karakter kata yang sudah diurutkan. Misalnya, “eat”, “tea”, dan “ate” semuanya dipetakan ke “aet”. Jika string-nya pendek, mengurutkan setiap kata adalah cara yang sederhana dan andal. Jika alfabetnya terbatas pada huruf kecil bahasa Inggris dan string-nya panjang, tuple frekuensi berisi 26 hitungan bisa lebih cepat karena menghindari pengurutan O(k log k) untuk setiap kata. Kompleksitas waktu dengan pengurutan adalah O(n * k log k), dengan n adalah jumlah string dan k adalah panjang rata-rata string. Dengan penghitungan alfabet tetap, kompleksitasnya bisa menjadi O(n * k). Kompleksitas ruangnya O(n * k) untuk output beserta kuncinya. Edge case meliputi string kosong, duplikat, aturan huruf besar/kecil, dan karakter di luar bahasa Inggris.

Kerangka: Tiga pointer: previous, current, next

Gunakan tiga pointer. previous diawali dengan null, current diawali dari head. Untuk setiap node, simpan next = current.next, arahkan current.next ke previous, lalu pindahkan previous ke current dan current ke next. Saat current menjadi null, previous adalah head yang baru. Invariannya: previous menunjuk ke bagian yang sudah dibalik, sedangkan current menunjuk ke node pertama yang belum dibalik. Menyimpan next sebelum mengubah current.next sangat penting; jika tidak, sisa list akan hilang. Kompleksitas waktunya O(n). Kompleksitas ruangnya O(1). Edge case meliputi list kosong, list dengan satu node, dan memastikan head awal menjadi tail dengan next bernilai null.

Kerangka: Batasan rentang

Kesalahan yang umum adalah hanya memeriksa apakah setiap node lebih besar dari anak kirinya dan lebih kecil dari anak kanannya. Itu tidak cukup karena seluruh subtree harus memenuhi batasan dari semua node di atasnya (ancestor). Gunakan DFS dengan batas bawah dan batas atas. Untuk setiap node, pastikan lower < node.value < upper. Anak kiri menerima batas bawah yang sama dan nilai node saat ini sebagai batas atas. Anak kanan menerima nilai node saat ini sebagai batas bawah dan batas atas yang sama. Jika ada node yang melanggar rentangnya, kembalikan false. Kompleksitas waktunya O(n) karena setiap node dikunjungi satu kali. Kompleksitas ruangnya O(h) untuk kedalaman rekursi, dengan h adalah tinggi tree. Edge case meliputi duplikat, batas min/max integer, tree kosong, dan tree yang miring (skewed). Klarifikasi apakah duplikat diperbolehkan dan, jika ya, di sisi mana duplikat itu ditempatkan.

Kerangka: Breadth-first search per lapisan jarak

Modelkan setiap sel terbuka sebagai node graph dan setiap langkah ke atas, bawah, kiri, atau kanan sebagai edge dengan bobot yang sama. Karena setiap langkah memiliki biaya yang sama, BFS menghasilkan jalur terpendek. Mulai dari sel sumber, masukkan ke queue dengan jarak 0, dan tandai sebagai visited. Untuk setiap sel yang dikeluarkan dari queue, jelajahi tetangga valid yang belum dikunjungi, berada di dalam batas grid, dan bukan rintangan. Saat pertama kali kita mencapai target, jaraknya pasti minimal. Ketepatannya berasal dari cara BFS memproses node secara berurutan dari jarak terdekat. Begitu sebuah sel dikunjungi, mencapainya lagi nanti tidak mungkin menghasilkan jalur yang lebih pendek pada graph tanpa bobot. Kompleksitas waktunya O(baris * kolom) karena setiap sel dikunjungi paling banyak satu kali. Kompleksitas ruangnya O(baris * kolom) untuk queue dan himpunan visited. Edge case meliputi sel awal atau akhir yang terblokir, sumber yang sama dengan target, tidak ada jalur, dan apakah langkah diagonal diperbolehkan.

Kerangka: Map visited dari node asli ke node salinan

Gunakan hash map yang memetakan setiap node asli ke node salinannya. Selama DFS atau BFS, saat mengunjungi node asli, buat salinannya jika belum ada. Lalu salin setiap tetangganya secara rekursif atau iteratif, dan tambahkan tetangga hasil salinan itu ke adjacency list node salinan. Map visited menyelesaikan dua masalah: mencegah loop tak berujung pada graph yang memiliki siklus dan mempertahankan referensi bersama sehingga graph salinan memiliki topologi yang sama dengan graph aslinya. Kompleksitas waktunya O(V + E), dengan V adalah jumlah node dan E adalah jumlah edge. Kompleksitas ruangnya O(V) untuk map serta stack atau queue traversal, tanpa menghitung graph output. Edge case meliputi input null, self-loop, graph yang tidak terhubung jika soal hanya meminta penyalinan dari node awal, dan entri tetangga yang duplikat.

Kerangka: DP bottom-up berdasarkan nominal

Definisikan dp[a] sebagai jumlah koin minimum yang dibutuhkan untuk membentuk nominal a. Inisialisasi dp[0] = 0 dan semua nilai lainnya dengan tak hingga. Untuk setiap nominal dari 1 sampai target, coba setiap koin. Jika a - coin tidak negatif, dp[a] = min(dp[a], dp[a - coin] + 1). Di akhir, jika dp[target] masih tak hingga, kembalikan -1. Relasi rekurensi ini berlaku karena koin terakhir dalam solusi optimal pasti salah satu dari pecahan yang tersedia. Jika koin terakhir itu bernilai c, sisa nominalnya adalah target - c, yang juga harus diselesaikan secara optimal. Kompleksitas waktunya O(nominal * jumlah jenis koin). Kompleksitas ruangnya O(nominal). Edge case meliputi nominal 0, nominal yang mustahil dibentuk, koin bernilai 1, pecahan duplikat, dan target nominal yang besar.

Kerangka: DP berdasarkan posisi akhir, lalu optimalkan dengan binary search

Solusi DP yang jelas mendefinisikan dp[i] sebagai panjang longest increasing subsequence yang berakhir di indeks i. Untuk setiap i, periksa setiap j sebelumnya. Jika nums[j] < nums[i], nums[i] dapat memperpanjang subsequence yang berakhir di j, sehingga dp[i] = max(dp[i], dp[j] + 1). Jawabannya adalah max(dp). Pendekatan ini membutuhkan waktu O(n^2) dan ruang O(n). Pendekatan O(n log n) yang lebih optimal menyimpan array tails, dengan tails[panjang - 1] adalah nilai akhir terkecil yang mungkin untuk increasing subsequence dengan panjang tersebut. Untuk setiap angka, lakukan binary search untuk menemukan tail pertama yang lebih besar dari atau sama dengan angka itu, lalu gantikan. Panjang array tails adalah panjang LIS. Dalam wawancara, wajar untuk menyajikan DP O(n^2) terlebih dahulu jika waktu terbatas, lalu membahas versi yang dioptimalkan. Edge case meliputi duplikat, array yang menurun, input kosong, dan apakah subsequence harus naik secara ketat (strictly increasing).

Kerangka: Bangun hanya prefiks yang valid

Gunakan backtracking dengan dua penghitung: jumlah kurung buka yang sudah dipakai (open) dan jumlah kurung tutup yang sudah dipakai (close). Di setiap langkah, kita bisa menambahkan kurung buka jika open < n. Kita bisa menambahkan kurung tutup jika close < open. Syarat kedua ini memastikan setiap prefiks tetap valid, sehingga kita tidak pernah menghasilkan string tidak valid yang harus disaring belakangan. Saat panjang string saat ini mencapai 2n, tambahkan ke hasil. Cara ini hanya menjelajahi prefiks yang valid dan memangkas state yang mustahil sejak dini. Jumlah output yang valid adalah bilangan Catalan ke-n, sehingga ukuran output mendominasi waktu eksekusi. Kompleksitas ruangnya mencakup kedalaman rekursi O(n) ditambah output. Edge case meliputi n = 0 atau n = 1, tergantung definisi dalam soal.

Kerangka: Kebutuhan -> API -> pembuatan ID -> penyimpanan -> jalur redirect -> skala

Kebutuhan: pengguna mengirimkan URL panjang dan menerima URL pendek. Saat seseorang membuka URL pendek tersebut, ia harus segera dialihkan (redirect). Fitur opsional mencakup alias kustom, masa kedaluwarsa, analitik, deteksi spam, dan akun pengguna. API inti: createShortUrl(longUrl, optionalAlias, expiration) dan redirect(shortCode). Model data: shortCode, longUrl, userId, createdAt, expiresAt, status, dan metadata analitik jika diperlukan. Untuk pembuatan ID, pilihannya antara lain ID auto-increment yang di-encode ke base62, kode base62 acak dengan pengecekan tabrakan (collision), atau pembuatan ID terdistribusi. Auto-increment sederhana, tetapi membocorkan jumlah URL yang dibuat jika tidak disamarkan. ID acak mudah didistribusikan, tetapi perlu penanganan collision. Pada skala menengah, base62 acak dengan batasan keunikan di basis data sudah memadai. Jalur baca adalah bagian terpenting. Redirect harus cepat: ambil shortCode dari cache, beralih ke basis data jika tidak ditemukan, validasi masa kedaluwarsa/status, lalu kembalikan HTTP 301 atau 302. Gunakan 302 jika analitik atau perubahan tujuan penting; gunakan 301 untuk redirect permanen dengan caching browser yang lebih kuat. Skala: cache short code yang sering diakses di Redis atau edge cache, lakukan sharding berdasarkan shortCode jika perlu, simpan analitik secara asinkron melalui queue, terapkan rate limit pada pembuatan URL, dan jalankan pemeriksaan spam/malware. Pantau latensi redirect, cache hit rate, error rate, laporan penyalahgunaan, dan tingkat saturasi basis data.

Kerangka: Pengguna -> postingan -> fanout -> ranking -> pembacaan -> konsistensi

Klarifikasi jenis feed-nya: feed dari akun yang diikuti, feed rekomendasi, atau gabungan keduanya. Asumsikan feed dari akun yang diikuti, yaitu pengguna membuat postingan dan para pengikutnya melihat postingan itu diurutkan berdasarkan relevansi atau waktu terbaru. Objek inti: pengguna, relasi follow, postingan, media, item feed, like/komentar, dan fitur untuk ranking. API mencakup createPost, getFeed, followUser, unfollowUser, dan interactWithPost. Ada dua model pembuatan feed yang umum. Fanout-on-write mendorong postingan baru ke penyimpanan feed para pengikut saat postingan dibuat. Cara ini membuat pembacaan cepat, tetapi penulisan menjadi mahal untuk pengguna dengan banyak pengikut. Fanout-on-read menyusun feed saat diminta dengan mengambil postingan dari akun-akun yang diikuti. Cara ini membuat penulisan murah, tetapi pembacaan lebih lambat. Pendekatan hibrida cukup umum: fanout-on-write untuk pengguna biasa dan fanout-on-read atau penanganan khusus untuk akun selebritas. Arsitektur: post service menulis postingan, graph service menyimpan relasi follow, feed service mengelola timeline feed, ranking service memberi skor pada kandidat postingan, cache menyimpan feed yang sering diakses, dan media disimpan di object storage/CDN. Gunakan queue untuk fanout asinkron dan pembaruan ranking. Trade-off: kesegaran feed versus kualitas ranking, konsistensi perubahan follow, penanganan pengguna selebritas, invalidasi cache, spam, pemblokiran demi privasi, dan backfill setelah queue gagal. Pantau latensi pemuatan feed, kesegaran feed, keterlambatan fanout (fanout lag), engagement, cache hit rate, error ranking, dan laporan penyalahgunaan.

Kerangka: Koneksi -> alur pesan -> persistensi -> pengiriman -> keandalan

Kebutuhan: pesan satu lawan satu dan grup, pengiriman saat penerima online, pengiriman saat penerima offline, riwayat pesan, tanda sudah dibaca (read receipt), indikator sedang mengetik, dan push notification. Klarifikasi apakah end-to-end encryption, lampiran, dan sinkronisasi multiperangkat diperlukan. Klien mempertahankan koneksi WebSocket ke gateway service. Saat pengguna mengirim pesan, gateway mengautentikasinya, menetapkan atau menerima idempotency key, menulis pesan ke penyimpanan yang durable, memublikasikan event, lalu mengirimkannya ke penerima yang sedang online melalui koneksi aktif mereka. Pengguna yang offline menerima push notification dan dapat mengambil riwayat pesan belakangan. Model data: percakapan, peserta, pesan, status pengiriman, status baca, dan perangkat/sesi. Penyimpanan harus efisien untuk pembacaan berdasarkan percakapan dan waktu. Basis data relasional bisa memadai pada skala menengah; penyimpanan terdistribusi digunakan pada skala yang lebih besar. Lampiran sebaiknya disimpan di object storage, bukan di basis data pesan. Aspek keandalan: pengiriman ganda, pesan yang tiba tidak berurutan, koneksi ulang, pesan yang terlewat, fanout untuk grup besar, dan akurasi status kehadiran (presence). Gunakan idempotency key, nomor urut (sequence number) yang terus meningkat per percakapan, acknowledgement, logika retry, dan API sinkronisasi sejak pesan terakhir yang dilihat. Pantau latensi pengiriman pesan, tingkat keberhasilan pengiriman, jumlah koneksi WebSocket, tingkat koneksi ulang, keterlambatan queue, kegagalan push notification, dan error penulisan ke penyimpanan.

Kerangka: Validasi -> persempit cakupan -> perubahan terbaru -> uraian per dependensi -> mitigasi

Pertama, validasi sinyalnya. Periksa apakah kenaikan latensi terlihat di beberapa sistem pemantauan dan apakah kenaikan itu memengaruhi p50, p95, p99, atau hanya endpoint tertentu. Pastikan apakah dampaknya dirasakan pengguna. Lalu persempit cakupan masalah berdasarkan endpoint, region, availability zone, segmen pelanggan, versi, host, dependensi, dan jenis request. Kenaikan secara global mengindikasikan masalah pada dependensi bersama atau deployment. Kenaikan yang terbatas mengarah ke route, query, pelanggan, atau zona infrastruktur tertentu. Berikutnya, periksa perubahan terbaru: deployment, perubahan konfigurasi, migrasi basis data, lonjakan traffic, feature flag, perubahan cache, atau insiden pada layanan downstream. Uraikan latensi per span layanan menggunakan trace. Periksa waktu query basis data, cache hit rate, keterlambatan queue, CPU, memori, garbage collection, thread pool, connection pool, dan API eksternal. Jika pengguna terdampak, mitigasi didahulukan sebelum akar masalah ditemukan secara tuntas. Lakukan rollback, nonaktifkan feature flag, tambah kapasitas, lewati dependensi yang lambat, atau naikkan TTL cache jika aman. Setelah layanan pulih, tuliskan akar masalah, celah deteksi, dan rencana pencegahannya.

Kerangka: Kasus unit -> batas -> input tidak valid -> invarian

Saya akan mulai dengan mengklarifikasi aturannya: jenis diskon, apakah diskon bisa digabung, masa berlaku, minimum belanja, kelayakan pengguna, pembulatan mata uang, dan apakah pajak atau ongkos kirim ikut dihitung. Unit test harus mencakup kasus normal, kasus batas, input tidak valid, dan interaksi antaraturan. Contohnya: tanpa diskon, diskon persentase, diskon nominal tetap, diskon yang lebih besar dari subtotal, minimum belanja yang terpenuhi tepat di angkanya, minimum belanja yang sedikit di bawah ambang, diskon kedaluwarsa, pengguna yang tidak memenuhi syarat, beberapa diskon sekaligus jika diizinkan, serta pembulatan sen. Saya juga akan menguji invarian: harga akhir tidak boleh negatif, diskon tidak boleh melebihi subtotal yang memenuhi syarat, promo yang sudah kedaluwarsa tidak boleh berlaku, dan perhitungan berulang harus selalu memberi hasil yang sama (deterministik). Jika fungsi ini bersinggungan dengan pembayaran, saya akan menambahkan integration test dengan layanan harga dan snapshot test untuk output invoice. Untuk keamanan di produksi, saya akan mencatat setiap keputusan diskon beserta kode alasannya di log agar tim support dan engineering bisa mendiagnosis keluhan soal harga tanpa menebak-nebak.

Kerangka: Ketepatan -> kemudahan perawatan -> risiko -> kejelasan

Saya melakukan review kode secara berlapis. Pertama, apakah kode ini menyelesaikan masalah yang dimaksud dan tetap benar? Kedua, apakah kodenya mudah dirawat: penamaan jelas, batasan modul masuk akal, tidak ada kompleksitas yang tidak perlu, dan gayanya konsisten? Ketiga, apa risikonya: migrasi, konkurensi, keamanan, performa, backward compatibility, dan observability? Keempat, apakah pengujiannya sudah memadai untuk perilaku yang berubah? Code review yang baik bukan ajang menunjukkan siapa yang lebih unggul. Review seharusnya memperbaiki kode sekaligus menjaga kecepatan tim. Saya memisahkan masalah yang bersifat blocking dari yang sekadar saran. Bug yang memengaruhi ketepatan, celah keamanan, atau risiko migrasi bersifat blocking. Preferensi penamaan atau refactor kecil bisa bersifat non-blocking. Saya juga mencari konteks yang belum ada: perilaku produk yang tidak jelas, edge case yang belum diuji, jalur kegagalan yang tidak terdeteksi (silent failure), penanganan error yang lemah, dan tidak adanya metrik di sekitar perubahan yang berisiko.

Kerangka: Konteks -> opsi -> trade-off -> keputusan -> hasil

Pilih keputusan yang memiliki trade-off nyata: membangun sendiri versus membeli, SQL versus NoSQL, monolit versus layanan terpisah, patch cepat versus refactor yang lebih mendalam, atau strong consistency versus availability. Mulailah dengan konteks dan batasannya, lalu jelaskan opsi yang Anda pertimbangkan. Jawaban yang kuat menyebutkan trade-off dengan jelas. Contohnya: “Opsi A memungkinkan kami merilis dalam satu minggu, tetapi menambah beban operasional. Opsi B butuh tiga minggu, tetapi menghilangkan bottleneck skalabilitas.” Lalu jelaskan bukti apa yang mendasari keputusan itu: traffic, tenggat dari pelanggan, riwayat insiden, kapasitas tim, atau roadmap jangka panjang. Tutup dengan hasilnya dan apa yang Anda pelajari. Jika keputusannya tidak sempurna, sampaikan apa yang akan Anda lakukan secara berbeda. Pewawancara lebih menghargai penilaian yang matang daripada sikap seolah-olah setiap keputusan sudah jelas sejak awal.

Kerangka: Insiden -> dampak -> respons -> akar masalah -> pencegahan

Gunakan insiden nyata jika memungkinkan. Mulailah dari dampaknya bagi pengguna: apa yang rusak, siapa yang terdampak, dan seberapa parah. Lalu jelaskan peran Anda dalam penanganannya: deteksi, triase, rollback, mitigasi, komunikasi, atau analisis akar masalah. Jawaban terbaik menunjukkan kemampuan menentukan prioritas dengan tenang. Saat insiden terjadi, memulihkan layanan lebih penting daripada membuktikan sebuah teori. Sebutkan bagaimana Anda memanfaatkan log, metrik, trace, feature flag, rollback, atau pemeriksaan dependensi. Setelah mitigasi, jelaskan akar masalah dan langkah pencegahannya. Pencegahan yang baik bisa berupa pengujian yang lebih baik, rollout yang lebih aman, pemantauan, penyetelan alert, runbook, circuit breaker, backpressure, atau pengaman migrasi. Hindari menyalahkan orang. Tim yang kuat memperbaiki sistem agar kesalahan yang sama lebih sulit terulang.

Kerangka: Tujuan bersama -> batasan -> opsi -> trade-off -> keputusan

Saya mulai dengan menyamakan pemahaman tentang tujuan pengguna dan tujuan bisnis. Banyak perbedaan pendapat sebenarnya bukan soal engineering melawan product, melainkan soal asumsi yang berbeda. Saya akan menjelaskan batasan teknisnya dengan jelas: kompleksitas, risiko keandalan, timeline, kemudahan perawatan, keamanan, atau performa. Lalu saya akan menawarkan beberapa opsi, bukan sekadar menolak. Misalnya: merilis MVP yang lebih kecil, memakai alur kerja manual untuk sementara, menyembunyikan fitur di balik feature flag, mengerjakan bagian teknisnya secara bertahap, atau memilih desain yang lebih sederhana tetapi tetap menyelesaikan masalah inti pengguna. Jika trade-off-nya serius, saya mendokumentasikan opsi, risiko, dan rekomendasinya agar keputusannya transparan. Tujuannya bukan agar engineering menang. Tujuannya agar tim mengambil keputusan yang jelas dengan memahami semua konsekuensinya.