40 Pertanyaan Wawancara DBMS Teratas di 2026

Pertanyaan Wawancara DBMS Tingkat Menengah

Pertanyaan ini menguji kecakapan teknis Anda dengan alat dan konsep DBMS.

Pewawancara menggunakan pertanyaan tingkat menengah untuk melihat apakah Anda dapat menerapkan pengetahuan basis data untuk memecahkan masalah nyata. Mereka mencari pengalaman praktis dengan optimasi kueri dan pemahaman cara kerja basis data di balik layar.

Jelaskan berbagai jenis indeks dan kapan menggunakannya

• Clustered index mengurutkan ulang data tabel secara fisik berdasarkan nilai key - Anda hanya bisa memiliki satu per tabel karena data hanya bisa diurutkan dengan satu cara.
• Non-clustered index membuat struktur terpisah yang menunjuk ke baris tabel tanpa mengubah urutan fisik. Anda dapat memiliki banyak non-clustered index pada sebuah tabel.
• Composite index mencakup beberapa kolom dan bekerja paling baik saat kueri memfilter pada kolom-kolom tersebut secara bersamaan.
• Unique index menegakkan keunikan sambil memberikan pencarian cepat.
• Partial index hanya mengindeks baris yang memenuhi kondisi tertentu, menghemat ruang.

Apa perbedaan antara clustered dan non-clustered index?

• Clustered index menentukan urutan penyimpanan fisik data dalam tabel - pikirkan buku telepon yang diurutkan berdasarkan nama belakang.
• Non-clustered index seperti indeks di bagian belakang buku teks - mereka menunjuk ke lokasi data sebenarnya tanpa mengubah urutan halaman buku.

Berikut cara membuat clustered dan non-clustered index:

-- Primary key membuat clustered index secara default
CREATE TABLE employees (
    id INT PRIMARY KEY CLUSTERED,
    name VARCHAR(100),
    email VARCHAR(100)
);

-- Indeks terpisah untuk pencarian email cepat
CREATE NONCLUSTERED INDEX idx_email ON employees(email);

Sebuah tabel hanya bisa memiliki satu clustered index namun banyak non-clustered. Clustered index lebih cepat untuk kueri rentang, sementara non-clustered lebih baik untuk pencocokan tepat pada kolom berbeda.

Bagaimana Anda mengoptimalkan kueri yang lambat?

Mulailah dengan menganalisis execution plan untuk melihat di mana hambatannya.

EXPLAIN SELECT * FROM orders o 
JOIN customers c ON o.customer_id = c.id 
WHERE o.order_date > '2025-07-01';

Berikut teknik optimasi umum:

• Tambahkan indeks pada kolom yang digunakan di klausa WHERE, JOIN, dan ORDER BY
• Batasi hasil dengan klausa WHERE sebelum melakukan join
• Gunakan covering index yang mencakup semua kolom yang dibutuhkan kueri
• Tulis ulang subquery menjadi JOIN jika memungkinkan
• Hindari SELECT * - ambil hanya kolom yang Anda butuhkan

Periksa table scan dalam execution plan - ini biasanya pembunuh performa terbesar.

Apa itu transaksi basis data dan tingkat isolasi?

Transaksi basis data mengelompokkan beberapa operasi menjadi satu kesatuan yang berhasil sepenuhnya atau gagal sepenuhnya.

Tingkat isolasi mengontrol bagaimana transaksi bersamaan melihat perubahan satu sama lain:

• READ UNCOMMITTED: Dapat membaca perubahan yang belum di-commit (dirty read mungkin terjadi)
• READ COMMITTED: Hanya membaca data yang sudah di-commit (default di sebagian besar basis data)
• REPEATABLE READ: Kueri yang sama mengembalikan hasil yang sama dalam satu transaksi
• SERIALIZABLE: Isolasi terkuat, transaksi berjalan seolah-olah berurutan

Semakin tinggi tingkat isolasi, semakin banyak masalah yang dicegah, tetapi mengurangi konkurensi dan performa.

Jelaskan konsep pemartisian (partitioning) basis data

Partitioning membagi tabel besar menjadi bagian-bagian yang lebih kecil dan mudah dikelola sambil tetap logis sebagai satu tabel. Ada empat pendekatan yang perlu Anda ketahui.

• Horizontal partitioning membagi baris berdasarkan kriteria seperti rentang tanggal:

-- Tabel Orders dipartisi berdasarkan tahun
CREATE TABLE orders_2023 (...);
CREATE TABLE orders_2024 (...);
CREATE TABLE orders_2025 (...);

• Vertical partitioning membagi kolom - kolom yang sering diakses di satu partisi, yang jarang digunakan di partisi lain.
• Hash partitioning mendistribusikan baris berdasarkan fungsi hash.
• Range partitioning menggunakan rentang nilai seperti tanggal atau ID.

Manfaatnya termasuk kueri yang lebih cepat (hanya mengkueri partisi relevan), pemeliharaan lebih mudah, dan paralelisasi yang lebih baik.

Apa perbedaan antara UNION dan UNION ALL?

UNION menggabungkan hasil dari beberapa kueri dan menghapus duplikat, sedangkan UNION ALL menggabungkan hasil tetapi mempertahankan semua baris, termasuk duplikat.

-- UNION menghapus duplikat (lebih lambat)
SELECT name FROM employees WHERE department = 'IT'
UNION
SELECT name FROM employees WHERE salary > 50000;

-- UNION ALL mempertahankan duplikat (lebih cepat)
SELECT name FROM employees WHERE department = 'IT'
UNION ALL
SELECT name FROM employees WHERE salary > 50000;

Gunakan UNION ALL saat Anda tahu tidak akan ada duplikat atau duplikat tidak masalah - jauh lebih cepat karena melewati langkah deduplikasi.

Bagaimana Anda menangani deadlock dalam basis data?

Deadlock terjadi ketika dua transaksi saling menunggu satu sama lain untuk melepaskan sumber daya, menciptakan ketergantungan melingkar.

Sebagian besar basis data secara otomatis mendeteksi deadlock dan menghentikan satu transaksi ("korban deadlock"), sehingga transaksi lainnya dapat berlanjut. Transaksi yang dihentikan di-rollback dan menghasilkan error.

-- Transaksi 1
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- menunggu lock pada akun 2

-- Transaksi 2  
BEGIN;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
-- mencoba memperbarui akun 1 -> DEADLOCK

Berikut strategi untuk mencegah deadlock:

• Akses tabel dalam urutan yang sama di seluruh transaksi
• Jaga transaksi tetap singkat
• Gunakan tingkat isolasi yang sesuai
• Terapkan logika retry di aplikasi Anda

Apa tujuan constraint (kendala) basis data?

Constraint basis data menegakkan aturan bisnis dan menjaga integritas data di tingkat basis data. Berikut lima jenis constraint yang harus diketahui setiap profesional basis data:

• Primary key: Memastikan identifikasi unik
• Foreign key: Menjaga integritas referensial
• Check: Memvalidasi data memenuhi kondisi tertentu
• Not null: Mencegah nilai kosong
• Unique: Memastikan tidak ada duplikasi

Berikut cara kerjanya dalam praktik:

CREATE TABLE employees (
    id INT PRIMARY KEY,
    email VARCHAR(100) UNIQUE NOT NULL,
    age INT CHECK (age >= 18 AND age <= 65),
    department_id INT,
    FOREIGN KEY (department_id) REFERENCES departments(id)
);

Constraint mencegah data buruk masuk ke basis data Anda dan menangkap kesalahan lebih awal, sebelum menyebar ke aplikasi Anda.

Jelaskan replikasi basis data dan jenis-jenisnya

Replikasi basis data menyalin data dari satu basis data ke basis data lain untuk meningkatkan ketersediaan, performa, dan pemulihan bencana.

Ada empat jenis replikasi yang harus Anda ketahui:

• Master-slave replication: Satu master menangani tulis, beberapa slave menangani baca. Perubahan mengalir dari master ke slave.
• Master-master replication: Beberapa master dapat menangani tulis dan baca. Lebih kompleks, tetapi menghilangkan single point of failure.
• Synchronous replication: Menunggu konfirmasi dari replika sebelum commit (lebih lambat tetapi lebih konsisten).
• Asynchronous replication: Commit segera, replikasi belakangan (lebih cepat tetapi berpotensi kehilangan data).

Apa itu trigger basis data, dan kapan sebaiknya digunakan?

Trigger basis data adalah prosedur khusus yang berjalan otomatis sebagai respons terhadap peristiwa basis data seperti INSERT, UPDATE, atau DELETE.

Berikut contoh sederhana:

CREATE TRIGGER update_modified_date
BEFORE UPDATE ON employees
FOR EACH ROW
BEGIN
    SET NEW.modified_at = NOW();
END;

Trigger berguna untuk memperbarui timestamp secara otomatis, mencatat perubahan untuk audit trail, menegakkan aturan bisnis kompleks, atau mempertahankan kolom terhitung.

Namun trigger bisa mempersulit debugging, memperlambat operasi, dan menciptakan dependensi tersembunyi. Gunakan seperlunya dan dokumentasikan dengan baik.

Sekarang mari lompat ke pertanyaan wawancara DBMS tingkat lanjut.

Pertanyaan Wawancara DBMS Tingkat Lanjut

Pertanyaan ini menguji pengetahuan mendalam Anda tentang arsitektur DBMS dan operasi basis data yang kompleks.

Pewawancara menggunakan pertanyaan tingkat lanjut untuk melihat apakah Anda dapat merancang dan memecahkan masalah sistem basis data dalam skala besar. Mereka ingin melihat apakah Anda memahami trade-off antara pendekatan yang berbeda dan dapat membuat keputusan yang tepat tentang arsitektur basis data.

Jelaskan sharding basis data dan trade-off-nya

Sharding membagi basis data besar secara horizontal di beberapa server, dengan setiap shard hanya berisi subset data.

Anda mempartisi data berdasarkan kunci shard, seperti ID pengguna, lokasi geografis, atau rentang tanggal. Setiap shard beroperasi secara independen, memungkinkan Anda menskalakan melampaui kemampuan satu server.

-- Contoh: Sharding pengguna berdasarkan rentang ID
-- Shard 1: user_id 1-1000000
-- Shard 2: user_id 1000001-2000000
-- Shard 3: user_id 2000001-3000000

Manfaatnya termasuk skalabilitas horizontal, performa lebih baik, dan isolasi kesalahan (kegagalan satu shard tidak mematikan semuanya).

Trade-off mencakup logika aplikasi yang kompleks, tidak ada transaksi lintas shard, penyeimbangan ulang yang sulit, dan hilangnya beberapa jaminan ACID di seluruh shard. Kueri yang melintasi beberapa shard menjadi mahal.

Apa itu teorema CAP, dan bagaimana pengaruhnya pada desain basis data?

Teorema CAP menyatakan bahwa sistem terdistribusi hanya dapat menjamin dua dari tiga properti: Konsistensi, ketersediaan, dan toleransi partisi:

• Consistency: Semua node melihat data yang sama pada waktu yang sama
• Availability: Sistem tetap beroperasi meski ada node yang gagal
• Partition tolerance: Sistem tetap berjalan meski terjadi kegagalan jaringan antar node

Karena hanya dua dari tiga yang dapat dijamin, berikut kombinasi yang paling umum:

• Sistem CA (seperti RDBMS tradisional) mengorbankan toleransi partisi - kurang mampu menangani pemisahan jaringan
• Sistem CP (seperti MongoDB pada konfigurasi tertentu) mengorbankan ketersediaan - mungkin menolak permintaan untuk menjaga konsistensi
• Sistem AP (seperti Cassandra) mengorbankan konsistensi - tetap tersedia, tetapi data mungkin sementara tidak konsisten antar node

Sebagian besar basis data terdistribusi modern eventually consistent - mereka memprioritaskan ketersediaan dan toleransi partisi sambil mencapai konsistensi seiring waktu.

Bagaimana Anda merancang skema basis data untuk konkurensi tinggi?

Mulai dengan mengurangi persaingan lock dengan merancang tabel yang mengurangi konflik antar operasi bersamaan.

Gunakan optimistic locking dengan kolom versi alih-alih lock pesimis:

-- Tambahkan kolom versi untuk optimistic locking
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10,2),
    inventory_count INT,
    version INT DEFAULT 1
);

-- Update dengan pemeriksaan versi
UPDATE products 
SET inventory_count = inventory_count - 1, version = version + 1
WHERE id = 123 AND version = 5;

Tips lain untuk desain konkurensi tinggi:

• Partisi tabel panas berdasarkan waktu atau batas logis lainnya
• Gunakan tabel terpisah untuk pola akses berbeda alih-alih tabel lebar dengan penggunaan campuran
• Hindari indeks lebar yang menciptakan kontensi
• Rancang untuk beban kerja yang sebagian besar append bila memungkinkan - insert menimbulkan lebih sedikit kontensi daripada update

Jelaskan MVCC (Multi-Version Concurrency Control)

MVCC memungkinkan beberapa transaksi mengakses data yang sama secara bersamaan tanpa locking dengan mempertahankan beberapa versi setiap baris.

Saat Anda memulai transaksi, Anda mendapatkan snapshot basis data pada saat itu. Transaksi lain dapat memodifikasi data, tetapi transaksi Anda hanya melihat versi yang ada saat dimulai.

-- Transaksi A mulai pada waktu T1
BEGIN; -- Melihat versi 1 dari semua data

-- Transaksi B memodifikasi data pada waktu T2  
UPDATE accounts SET balance = 1000 WHERE id = 1; -- Membuat versi 2

-- Transaksi A tetap melihat versi 1
SELECT balance FROM accounts WHERE id = 1; -- Mengembalikan nilai lama

COMMIT; -- Transaksi A commit dengan snapshot-nya

Keuntungannya termasuk pembaca tidak memblokir penulis, penulis tidak memblokir pembaca, dan pembacaan konsisten dalam transaksi.

Kekurangannya termasuk overhead penyimpanan untuk banyak versi dan proses pembersihan untuk menghapus versi lama.

Apa itu materialized view, dan kapan sebaiknya digunakan?

Materialized view menyimpan hasil kueri secara fisik di disk, tidak seperti view biasa yang mengeksekusi kueri setiap kali.

Mereka ideal untuk agregasi mahal yang tidak membutuhkan data real-time:

-- Buat materialized view untuk ringkasan penjualan bulanan
CREATE MATERIALIZED VIEW monthly_sales AS
SELECT 
    DATE_TRUNC('month', order_date) as month,
    SUM(total_amount) as total_sales,
    COUNT(*) as order_count
FROM orders 
GROUP BY DATE_TRUNC('month', order_date);

-- Refresh saat diperlukan
REFRESH MATERIALIZED VIEW monthly_sales;

Mereka bagus untuk kueri dasbor, pelaporan, dan analitik kompleks yang berjalan berulang pada data yang stabil.

Trade-off mencakup ruang penyimpanan ekstra, beban pemeliharaan, dan keterlambatan data antara penyegaran. Paling efektif bila Anda dapat mentolerir data sedikit usang demi performa kueri yang lebih baik.

Bagaimana Anda menangani dataset yang sangat besar yang tidak muat di memori?

Rancang untuk operasi berbasis disk dengan memahami bagaimana basis data Anda mengakses data dari penyimpanan.

Gunakan partitioning untuk memastikan kueri hanya menyentuh segmen data yang relevan:

-- Partisi berdasarkan tanggal agar kueri bisa melewati partisi yang tidak relevan
CREATE TABLE sales_data (
    sale_date DATE,
    amount DECIMAL(10,2),
    customer_id INT
) PARTITION BY RANGE (sale_date);

Tips lain untuk menangani dataset lebih besar dari memori:

• Optimalkan indeks untuk pemindaian rentang alih-alih akses acak
• Gunakan penyimpanan kolumnar untuk beban kerja analitik di mana Anda melakukan agregasi kolom tertentu
• Terapkan caching hasil kueri dan paginasi untuk kueri yang dihadapi pengguna
• Gunakan read replica untuk mendistribusikan beban kueri ke beberapa mesin
• Pertimbangkan pengarsipan data - pindahkan data lama ke penyimpanan lebih murah dan hanya simpan data terbaru di basis data utama

Jelaskan perbedaan antara locking pesimis dan optimis

Locking pesimis mengasumsikan konflik akan terjadi dan segera mengunci sumber daya untuk mencegahnya, sedangkan locking optimis mengasumsikan konflik jarang terjadi dan hanya memeriksa konflik saat melakukan commit perubahan.

-- Pesimis: Kunci baris segera
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE; -- Mengunci baris
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

-- Optimis: Periksa versi sebelum memperbarui
SELECT id, balance, version FROM accounts WHERE id = 1;
-- Logika aplikasi di sini
UPDATE accounts 
SET balance = balance - 100, version = version + 1 
WHERE id = 1 AND version = 3; -- Gagal jika ada orang lain yang memperbarui

• Pesimis lebih cocok untuk skenario dengan kontensi tinggi di mana konflik umum terjadi.
• Optimis lebih cocok untuk beban kerja yang dominan baca di mana konflik jarang terjadi.

Apa itu denormalisasi, dan kapan tepat digunakan?

Denormalisasi dengan sengaja menambahkan redundansi ke tabel yang sudah dinormalisasi untuk meningkatkan performa kueri.

Anda menduplikasi data di beberapa tabel untuk menghindari join yang mahal:

-- Dinormalisasi: Membutuhkan join untuk detail pesanan
SELECT o.id, c.name, c.email 
FROM orders o 
JOIN customers c ON o.customer_id = c.id;

-- Didenormalisasi: Info pelanggan disimpan di tabel orders
SELECT id, customer_name, customer_email 
FROM orders_denormalized;

Kapan melakukan denormalisasi:

• Performa baca lebih penting daripada performa tulis
• Anda memiliki pola kueri yang dapat diprediksi yang diuntungkan dengan menghindari join
• Penyimpanan lebih murah daripada waktu komputasi
• Anda dapat menangani kompleksitas menjaga sinkronisasi data yang didenormalisasi

Risikonya termasuk inkonsistensi data, peningkatan biaya penyimpanan, dan logika pembaruan yang lebih kompleks.

Bagaimana Anda merancang untuk pemulihan bencana dan ketersediaan tinggi?

Mulailah dengan merancang redundansi di setiap level - beberapa server basis data, jalur jaringan, dan pusat data.

Siapkan replikasi dengan failover otomatis:

• Primary: Menangani semua penulisan
• Replica 1: Menangani kueri baca di wilayah yang sama
• Replica 2: Menangani kueri baca di wilayah berbeda
• Replica 3: Siaga untuk pemulihan bencana

Tips lainnya:

• Terapkan backup rutin dengan kemampuan pemulihan titik-waktu
• Uji prosedur failover secara berkala - rencana pemulihan bencana yang tidak bekerja di bawah tekanan tidak berguna
• Gunakan load balancer untuk mengarahkan lalu lintas dari server yang gagal
• Monitor semuanya - Anda harus mengetahui masalah sebelum pengguna Anda mengetahuinya
• Rencanakan berbagai skenario kegagalan - kegagalan satu server, pemadaman pusat data, bencana regional, dan korupsi data

Jelaskan connection pooling basis data dan mengapa itu penting

Connection pooling mempertahankan cache koneksi basis data yang dapat digunakan ulang oleh aplikasi alih-alih membuat koneksi baru untuk setiap permintaan.

Membuat koneksi basis data itu mahal - melibatkan handshake jaringan, autentikasi, dan alokasi sumber daya. Connection pool menghilangkan overhead ini.

Berikut contoh Python:

# Tanpa pooling: Membuat koneksi baru setiap kali
def get_user(user_id):
    conn = create_connection()  # Mahal!
    result = conn.execute("SELECT * FROM users WHERE id = ?", user_id)
    conn.close()
    return result

# Dengan pooling: Menggunakan ulang koneksi yang ada
pool = ConnectionPool(max_connections=20)
def get_user(user_id):
    conn = pool.get_connection()  # Cepat!
    result = conn.execute("SELECT * FROM users WHERE id = ?", user_id)
    pool.return_connection(conn)
    return result

Keuntungannya termasuk waktu respons lebih cepat, beban basis data berkurang, penggunaan sumber daya terkendali, dan penanganan lonjakan trafik lebih baik.

Ukuran pool sebaiknya disesuaikan dengan pengguna bersamaan dan kapasitas basis data—terlalu kecil menyebabkan antrean, terlalu besar membuang sumber daya.

Pertanyaan DBMS Perilaku dan Berbasis Skenario

Pertanyaan ini mengevaluasi keterampilan pemecahan masalah dan pengalaman Anda bekerja dengan klien dan tim data.

Pewawancara menggunakan pertanyaan perilaku dan skenario untuk melihat bagaimana Anda menangani tantangan basis data dunia nyata. Mereka ingin memahami proses berpikir, keterampilan komunikasi, dan kemampuan Anda bekerja dengan pihak non-teknis saat masalah basis data muncul.

Ceritakan saat Anda harus mengoptimalkan kueri yang lambat. Apa pendekatan Anda?

Susun jawaban Anda untuk menunjukkan proses pemecahan masalah yang jelas.

Mulailah dengan menjelaskan masalah dan dampaknya: "Dasbor pelanggan kami membutuhkan 45 detik untuk dimuat karena kueri utama melakukan full table scan pada tabel berisi jutaan baris. Ini membuat pengguna frustrasi dan menyebabkan mereka meninggalkan halaman."

Jelaskan pendekatan diagnostik: "Saya menganalisis execution plan kueri dan menemukan bahwa kami kekurangan indeks pada kolom yang digunakan di klausa WHERE. Saya juga melihat klausa ORDER BY tidak dioptimalkan."

Jelaskan solusi dan hasilnya: "Saya membuat indeks komposit yang mencakup kolom filter dan sort. Setelah pengujian di lingkungan staging, saya menerapkannya saat lalu lintas rendah. Waktu kueri turun dari 45 detik menjadi kurang dari 2 detik, menyelesaikan masalah performa dasbor."

Selalu tekankan pengukuran, pengujian, dan hasil yang terukur dalam jawaban Anda.

Jelaskan situasi saat Anda harus menerangkan konsep basis data yang kompleks kepada pemangku kepentingan non-teknis

Fokuskan pada bagaimana Anda membuat konsep teknis menjadi mudah dipahami oleh pemangku kepentingan bisnis.

Pilih contoh spesifik ketika Anda berhasil menjembatani kesenjangan teknis. Anda bisa berkata: "Tim pemasaran kami frustrasi karena laporan segmentasi pelanggan butuh 20 menit untuk berjalan. Alih-alih menjelaskan join dan indeks basis data, saya menggunakan analogi sederhana."

Jelaskan pendekatan komunikasi Anda: "Saya minta mereka membayangkan mencari pelanggan yang membeli produk A dan produk B. Sistem saat ini seperti mencari manual setiap struk di lemari arsip besar. Setelah dioptimalkan, itu seperti memiliki folder terorganisir per jenis produk, membuat pencarian jauh lebih cepat."

Tunjukkan dampak bisnis: "Saya fokus pada hal yang penting bagi mereka - laporan akan berjalan dalam 2 menit, bukan 20, sehingga mereka bisa mendapatkan insight lebih cepat dan merespons perubahan pasar lebih sigap."

Tunjukkan bahwa Anda dapat menerjemahkan pekerjaan teknis menjadi nilai bisnis tanpa membebani pihak non-teknis dengan detail implementasi.

Bagaimana Anda menangani situasi ketika basis data down saat jam sibuk?

Tunjukkan keterampilan manajemen krisis melalui respons terstruktur:

• Penilaian segera: "Pertama, saya tentukan cakupan - apakah mati total atau sebagian layanan masih berfungsi? Saya periksa apakah read replica masih dapat diakses untuk operasi baca kritis."
• Komunikasi dengan pemangku kepentingan: "Saya segera memberi tahu tim respons insiden dan mengirim pembaruan status singkat ke unit bisnis yang terdampak dengan perkiraan waktu pembaruan, bahkan jika solusi belum ada."
• Proses diagnostik: "Saya cek log sistem, ruang disk, penggunaan memori, konektivitas jaringan, dan log error basis data untuk mengidentifikasi akar masalah. Jika kegagalan perangkat keras, saya inisiasi failover ke server siaga."
• Pembaruan berkala: "Saya mengirim pembaruan status setiap 15-30 menit agar pemangku kepentingan tetap mengetahui perkembangan, meski belum ada kemajuan. Komunikasi sama pentingnya dengan memperbaiki masalah."
• Tinjauan pasca-insiden: "Setelah terselesaikan, saya dokumentasikan apa yang terjadi, mengapa terjadi, dan apa yang akan kami lakukan untuk mencegahnya di masa depan."

Kuncinya adalah menunjukkan bahwa Anda bisa tetap tenang di bawah tekanan sambil menjaga komunikasi tetap jelas.

Jelaskan langkah Anda merancang skema basis data untuk aplikasi e-commerce baru

Jelaskan pendekatan Anda langkah demi langkah:

• Pengumpulan kebutuhan: "Saya mulai dengan memahami kebutuhan bisnis - produk apa yang dijual, bagaimana pelanggan berbelanja, laporan apa yang dibutuhkan, dan seperti apa perkiraan volume trafiknya."
• Identifikasi entitas: "Saya identifikasi entitas inti seperti Users, Products, Orders, OrderItems, Categories, dan Payments. Setiap entitas merepresentasikan konsep bisnis kunci yang perlu dilacak."
• Desain relasi: "Saya petakan bagaimana entitas ini saling terkait. Misalnya, Users memiliki banyak Orders, Orders berisi banyak Products melalui OrderItems, dan Products termasuk dalam Categories."
• Perencanaan performa: "Saya menambahkan indeks pada kolom yang sering diquery, seperti email pengguna untuk login, SKU produk untuk pencarian, dan tanggal pesanan untuk pelaporan. Saya juga mempertimbangkan pemartisian tabel besar seperti Orders berdasarkan tanggal."
• Perencanaan masa depan: "Saya merancang skema untuk mengakomodasi fitur masa depan yang mungkin, seperti ulasan produk, promosi, dan pelacakan inventaris tanpa perlu restrukturisasi besar."

Tunjukkan bahwa Anda memikirkan kebutuhan langsung dan skalabilitas jangka panjang sejak awal.

Ceritakan saat Anda harus memigrasikan data dari satu sistem basis data ke sistem lain. Tantangan apa yang Anda hadapi?

Fokus pada perencanaan, eksekusi, dan pemecahan masalah.

Mulailah dengan konteks: "Kami bermigrasi dari MySQL ke PostgreSQL untuk memanfaatkan dukungan JSON yang lebih baik dan fitur pengindeksan lanjutan untuk beban kerja analitik kami."

Daftar masalah dan tantangan: "Tantangan terbesar adalah menangani perbedaan tipe data - perilaku timestamp MySQL berbeda dengan PostgreSQL. Kami juga memiliki stored procedure yang perlu ditulis ulang."

Bahas solusi Anda: "Saya membuat rencana migrasi terperinci dengan prosedur rollback. Kami menjalankan migrasi bertahap: pertama subset tabel, lalu secara bertahap memindahkan sisanya sambil menjaga konsistensi data."

Akhiri dengan hasil pengujian dan validasi: "Kami menjalankan sistem paralel selama dua minggu, membandingkan hasil antara basis data lama dan baru untuk memastikan integritas data. Kami juga melakukan uji beban pada sistem baru sebelum beralih sepenuhnya."

Bagaimana Anda menangani perbedaan pendapat dengan rekan tim tentang keputusan desain basis data?

Tunjukkan keterampilan kolaborasi dan penyelesaian konflik:

• Dengarkan dan pahami: "Saya selalu mulai dengan memahami perspektif mereka. Sering kali perbedaan muncul karena prioritas berbeda - mereka mungkin mengutamakan kenyamanan developer sementara saya mengutamakan performa."
• Sajikan argumen berbasis data: "Saya mendukung rekomendasi dengan contoh konkret. Jika saya rasa kita butuh indeks, saya tunjukkan execution plan dan tolok ukur performa."
• Cari titik temu: "Biasanya kami sepakat pada tujuan akhir - aplikasi yang cepat dan andal. Perbedaan hanya soal cara mencapainya."

Contoh: "Seorang developer ingin menggunakan pendekatan NoSQL untuk profil pengguna, tetapi saya menyarankan desain relasional. Kami membahas trade-off, menjalankan prototipe kedua pendekatan, dan memilih solusi yang paling sesuai dengan kebutuhan konsistensi dan keahlian tim kami."

Ceritakan saat Anda harus bekerja dengan tenggat waktu ketat pada proyek basis data

Tunjukkan kemampuan Anda memprioritaskan dan menyelesaikan pekerjaan di bawah tekanan.

Gambarkan situasinya: "Kami membutuhkan laporan pelanggan penting untuk rapat dewan dalam tiga hari, tetapi kuerinya memakan waktu lebih dari satu jam untuk berjalan."

Sebutkan bagaimana Anda memprioritaskan tugas: "Saya fokus pada peningkatan performa terbesar terlebih dahulu. Alih-alih mengoptimalkan semuanya, saya mengidentifikasi dua operasi termahal di execution plan kueri."

Sebutkan quick win: "Saya menambahkan covering index untuk kueri utama dan mempartisi tabel terbesar berdasarkan tanggal. Ini mengurangi waktu berjalan dari 60 menit menjadi 8 menit."

Akhiri dengan komunikasi dan hasil: "Saya memberi kabar ke product manager setiap beberapa jam sehingga mereka bisa mengelola ekspektasi dengan dewan jika diperlukan. Kami menyerahkan laporan yang dioptimalkan dua hari lebih cepat, dan itu menjadi template untuk laporan serupa."

Bagaimana pendekatan Anda menelusuri masalah performa basis data yang hanya terjadi sesekali?

Tunjukkan pendekatan debugging sistematis untuk masalah intermiten:

• Bangun monitoring: "Saya menyiapkan pemantauan untuk menangkap metrik performa saat masalah terjadi - waktu eksekusi kueri, sumber daya sistem, koneksi bersamaan."
• Kumpulkan data: "Saya aktifkan pencatatan kueri untuk melihat apa yang berjalan saat performa menurun. Saya juga cek pola - apakah terjadi pada waktu tertentu, dengan pengguna tertentu, atau selama operasi tertentu?"
• Buat hipotesis: "Berdasarkan data, saya membentuk hipotesis. Mungkin ada job batch yang berjalan setiap jam, atau laporan tertentu yang mengunci tabel."
• Isolasi dan pengujian: "Saya mencoba mereproduksi masalah di lingkungan uji dengan volume data dan pola kueri serupa."

Contoh: "Saya pernah melacak masalah performa yang hanya terjadi pada Selasa pagi. Ternyata job sinkronisasi data mingguan berjalan pada waktu yang sama dengan aktivitas puncak pengguna kami, menyebabkan kontensi lock."

Jelaskan bagaimana Anda menangani permintaan akses basis data dari seseorang yang biasanya tidak bekerja dengan basis data

Tunjukkan kesadaran keamanan dan kemampuan mengajar Anda.

Nilai kebutuhan: "Saya pertama-tama memahami apa yang ingin mereka capai. Sering kali ada cara yang lebih baik untuk mendapatkan informasi yang mereka butuhkan tanpa akses langsung ke basis data."

Berikan alternatif untuk menunjukkan perhatian keamanan: "Alih-alih akses basis data, saya mungkin membuat view read-only, membangun dasbor, atau mengekspor data yang mereka perlukan sebagai berkas CSV."

Jika akses diperlukan, jelaskan bahwa keamanan tetap prioritas: "Saya akan membuat akun read-only dengan akses terbatas hanya ke tabel yang mereka butuhkan. Saya juga memberikan pelatihan dasar tentang praktik terbaik SQL dan kueri apa yang dapat berdampak pada performa."

Tetapkan ekspektasi: "Saya jelaskan pentingnya tidak menjalankan kueri mahal saat jam sibuk dan meminta mereka berkonsultasi dengan saya sebelum menjalankan sesuatu yang kompleks."

Tips Mempersiapkan Wawancara DBMS

Cara terbaik untuk sukses di wawancara DBMS adalah berlatih dengan basis data nyata, bukan hanya menghafal teori. Pewawancara ingin melihat bahwa Anda dapat memecahkan masalah nyata, bukan sekadar mengucapkan definisi.

Latih SQL pada dataset nyata

Jangan hanya melatih pernyataan SELECT dasar - bekerjalah dengan data dunia nyata yang berantakan.

Unduh dataset dari Kaggle atau gunakan basis data publik seperti Sampel basis data Sakila untuk MySQL. Latih kueri kompleks yang melibatkan banyak join, subquery, dan agregasi. Tujuannya adalah merasa nyaman dengan skenario yang benar-benar akan Anda temui di tempat kerja.

Kueri seperti ini harus terasa mudah, dan Anda tidak kesulitan menjelaskan bagiannya:

SELECT 
    c.customer_id,
    c.first_name,
    c.last_name,
    COUNT(r.rental_id) as total_rentals,
    SUM(p.amount) as total_spent
FROM customer c
LEFT JOIN rental r ON c.customer_id = r.customer_id
LEFT JOIN payment p ON r.rental_id = p.rental_id
WHERE r.rental_date >= '2025-07-01'
GROUP BY c.customer_id, c.first_name, c.last_name
HAVING COUNT(r.rental_id) > 10
ORDER BY total_spent DESC;

Siapkan lingkungan basis data Anda sendiri

Instal sistem basis data secara lokal dan pelajari cara kerjanya secara nyata.

Pilih salah satu sistem utama - PostgreSQL, MySQL, atau SQL Server - dan siapkan instance lokal. Buat tabel, masukkan data, dan bereksperimen dengan berbagai konfigurasi. Pelajari cara membaca execution plan, membuat indeks, dan memantau performa.

Pengalaman langsung ini akan membantu Anda menjawab pertanyaan tentang administrasi basis data, bukan hanya sintaks SQL.

>Jika Anda diwawancarai untuk peran Administrator Basis Data, Anda harus mengetahui jawaban untuk 30 pertanyaan DBA teratas ini

Pelajari masalah performa nyata

Pelajari cara mengidentifikasi dan memecahkan bottleneck performa umum.

Gunakan alat seperti EXPLAIN atau EXPLAIN ANALYZE untuk memahami bagaimana kueri Anda dieksekusi:

EXPLAIN ANALYZE 
SELECT * FROM orders 
WHERE customer_id = 12345 
AND order_date > '2023-01-01';

Latih mengidentifikasi table scan, indeks yang hilang, dan join yang tidak efisien. Buat dataset besar dan lihat bagaimana strategi berbeda memengaruhi performa kueri.

Memahami execution plan adalah pembeda antara developer junior dan senior dalam wawancara.

Latih desain basis data

Kerjakan latihan desain skema yang lengkap, bukan hanya tabel individual.

Pilih skenario dunia nyata seperti situs e-commerce, platform media sosial, atau sistem inventaris. Rancang seluruh skema basis data, termasuk relasi, constraint, dan indeks. Pikirkan bagaimana desain akan menangani pertumbuhan dan perubahan kebutuhan.

Gambar diagram entitas-relasi dan siap untuk menjelaskan keputusan desain Anda. Pewawancara sering bertanya "mengapa Anda memilih pendekatan ini dibanding alternatif?" Pastikan Anda punya jawabannya.

>Saya merekomendasikan untuk melihat kursus Database Design untuk meningkatkan pengetahuan Anda.

Tinjau konsep SQL dan NoSQL

Bahkan jika peran berfokus pada basis data relasional, pahami kapan NoSQL masuk akal.

Ketahui dasar-dasar document store seperti MongoDB, key-value store seperti Redis, dan column-family database seperti Cassandra. Pahami trade-off antara konsistensi dan ketersediaan dalam sistem terdistribusi.

Ini menunjukkan Anda bisa berpikir melampaui satu teknologi dan memilih alat yang tepat untuk masalahnya.

>Kursus NOSQL Concepts adalah titik awal yang sangat baik.

Siapkan cerita tentang masalah basis data nyata

Pikirkan contoh spesifik saat Anda memecahkan tantangan basis data.

Siapkan 3-4 cerita tentang saat Anda mengoptimalkan kueri lambat, merancang skema, memigrasikan data, atau menangani outage basis data. Gunakan metode STAR - Situation, Task, Action, Result - untuk menyusun jawaban Anda.

Latih menjelaskan konsep teknis kepada audiens non-teknis. Pewawancara sering bertanya bagaimana Anda akan mengkomunikasikan masalah basis data kepada pemangku kepentingan bisnis.

Tetap mengikuti tren basis data

Baca tentang teknologi dan praktik basis data modern.

Ikuti blog basis data, hadiri webinar, atau bergabung dengan komunitas basis data. Ketahui topik seperti sharding, MVCC, basis data terdistribusi, dan layanan basis data cloud.

Anda tidak perlu ahli dalam semuanya, tetapi menunjukkan kesadaran tren terkini menunjukkan bahwa Anda tetap terlibat di bidang ini.

Ringkasan Pertanyaan Wawancara DBMS

Wawancara DBMS menguji segala hal mulai dari sintaks SQL dasar hingga keputusan desain sistem yang kompleks.

Untuk sukses, kuasai konsep dasar seperti normalisasi, pengindeksan, dan transaksi. Lalu hadapi topik lanjutan seperti sharding dan desain ketersediaan tinggi. Teori saja tidak cukup - Anda harus mengaitkan pengetahuan basis data dengan masalah bisnis nyata.

Kandidat terbaik mengaitkan konsep teknis dengan hasil praktis. Saat Anda menjelaskan indeks, sebutkan bagaimana mereka memangkas waktu kueri dari menit menjadi detik. Saat Anda membahas replikasi, jelaskan bagaimana itu mencegah downtime yang mahal.

Latih menjelaskan konsep basis data yang kompleks dengan jelas kepada pemangku kepentingan non-teknis. Siapkan cerita spesifik tentang optimasi performa, penanganan outage, atau desain skema dengan hasil terukur - "mengurangi waktu kueri sebesar 90%" lebih kuat daripada "membuat kueri lebih cepat."

>Selain SQL dan DBMS, tidak ada salahnya mempersiapkan diri untuk pertanyaan wawancara Data Warehouse

Kuasai dasar-dasar, berlatih dengan data nyata, dan selalu hubungkan pengetahuan teknis Anda dengan nilai bisnis - itulah cara Anda sukses dalam wawancara DBMS. Latihan membuat sempurna.

Untuk mempelajari keterampilan dasar basis data dan desain basis data, saya merekomendasikan kursus dan materi dari DataCamp berikut:

• Introduction to Relational Databases in SQL
• Introduction to Oracle SQL
• SQL Server for Database Administrators
• Introduction to dbt