25 Pertanyaan Wawancara Data Engineering Terpopuler di Tahun 2026

Peran data engineer telah menjadi salah satu posisi paling dicari di industri teknologi pada tahun 2026. Dengan meningkatnya kebutuhan perusahaan terhadap infrastruktur data yang andal, kandidat diharapkan menguasai berbagai topik mulai dari optimasi SQL, arsitektur pipeline, hingga desain sistem berskala besar. Panduan ini menyajikan 25 pertanyaan wawancara data engineering yang paling sering diajukan, disertai jawaban mendalam dan contoh kode yang siap dipraktikkan.

1. SQL dan Optimasi Query

Pertanyaan 1: Apa perbedaan antara GROUP BY dan window function? Kapan sebaiknya masing-masing digunakan?

GROUP BY menggabungkan beberapa baris menjadi satu baris ringkasan per kelompok, sehingga jumlah baris pada hasil query berkurang sesuai dengan jumlah grup yang terbentuk. Sebaliknya, window function mempertahankan semua baris asli sambil menambahkan kolom hasil agregasi di setiap baris.

Skenario penggunaan GROUP BY yang tepat adalah ketika diperlukan satu nilai ringkasan per kelompok, misalnya total penjualan per wilayah. Sementara itu, window function lebih cocok digunakan ketika diperlukan perbandingan antara nilai baris individual dengan agregat kelompoknya, seperti menghitung peringkat karyawan berdasarkan gaji dalam setiap departemen.

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Untuk pembahasan lebih mendalam tentang window function dan CTE, baca panduan lengkap SQL for Data Analysts: Window Functions, CTEs and Advanced Queries.

Pertanyaan 2: Bagaimana cara mengoptimalkan query lambat di PostgreSQL?

Proses optimasi query dimulai dengan menjalankan EXPLAIN ANALYZE untuk melihat execution plan yang sebenarnya. Beberapa langkah kunci yang perlu diperhatikan meliputi:

• Indexing: Menambahkan index pada kolom yang sering digunakan dalam klausa WHERE, JOIN, dan ORDER BY. Index komposit sangat berguna ketika beberapa kolom sering difilter secara bersamaan.
• Menghindari sequential scan pada tabel besar: Jika EXPLAIN menunjukkan Seq Scan pada tabel jutaan baris, kemungkinan besar diperlukan index yang sesuai.
• Partitioning: Membagi tabel besar berdasarkan rentang tanggal atau kategori tertentu agar query hanya memindai partisi yang relevan.
• **Menghindari SELECT ***: Hanya memilih kolom yang benar-benar diperlukan untuk mengurangi I/O dan penggunaan memori.
• Materialized views: Menyimpan hasil query kompleks yang sering diakses sebagai materialized view, terutama untuk dashboard dan laporan.

Pertanyaan 3: Jelaskan perbedaan antara HAVING dan WHERE.

WHERE memfilter baris sebelum proses agregasi dilakukan, sedangkan HAVING memfilter hasil setelah agregasi selesai. Secara urutan eksekusi, WHERE dijalankan terlebih dahulu pada data mentah, kemudian GROUP BY mengelompokkan hasilnya, dan terakhir HAVING memfilter kelompok berdasarkan kondisi agregat. Contohnya, WHERE salary > 50000 menyaring karyawan individual, sementara HAVING AVG(salary) > 50000 menyaring departemen yang rata-rata gajinya memenuhi kriteria tersebut.

2. ETL vs ELT dan Arsitektur Data Pipeline

Pertanyaan 4: Apa perbedaan mendasar antara ETL dan ELT? Kapan masing-masing pendekatan digunakan?

Kedua pendekatan ini berbeda dalam urutan proses transformasi data. Berikut perbandingan lengkapnya:

| Aspek | ETL | ELT | |---|---|---| | Urutan proses | Extract, Transform, Load | Extract, Load, Transform | | Lokasi transformasi | Server ETL / staging area | Di dalam data warehouse | | Kecepatan pemuatan | Lebih lambat (transformasi dulu) | Lebih cepat (data langsung dimuat) | | Cocok untuk | Data warehouse tradisional, volume kecil-menengah | Cloud data warehouse (BigQuery, Snowflake, Redshift) | | Fleksibilitas | Skema harus ditentukan di awal | Transformasi dapat dilakukan berulang kali | | Contoh tools | Informatica, Talend, SSIS | dbt, Dataform, Snowflake SQL |

Dalam ekosistem cloud modern, pendekatan ELT semakin dominan karena memanfaatkan kapasitas komputasi data warehouse yang elastis. Namun, ETL tetap relevan untuk skenario yang memerlukan transformasi kompleks sebelum data dimuat, atau ketika ada batasan kepatuhan yang mengharuskan data dibersihkan sebelum masuk ke sistem tujuan.

Untuk latihan lebih lanjut tentang pola-pola ini, kunjungi modul ETL/ELT patterns.

Pertanyaan 5: Bagaimana merancang pipeline yang idempoten?

Pipeline yang idempoten menghasilkan output yang sama ketika dijalankan berulang kali dengan input yang sama, tanpa menciptakan data duplikat. Prinsip ini sangat penting untuk menangani kegagalan dan proses retry secara aman.

Strategi utama untuk mencapai idempoten meliputi:

• Partition overwrite: Menimpa seluruh partisi target alih-alih menambahkan data (append). Dengan cara ini, menjalankan ulang pipeline untuk tanggal yang sama akan menghasilkan output identik.
• Upsert (MERGE): Menggunakan operasi upsert berdasarkan natural key sehingga data yang sudah ada diperbarui, bukan diduplikasi.
• Deduplikasi: Menghapus duplikat berdasarkan identifier unik sebelum penulisan akhir.

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Pertanyaan 6: Apa itu backfill dalam konteks data pipeline dan bagaimana menanganinya?

Backfill adalah proses menjalankan ulang pipeline untuk rentang waktu historis, baik karena adanya bug yang perlu diperbaiki, perubahan logika transformasi, maupun penambahan sumber data baru. Penanganan backfill yang baik memerlukan pipeline yang diparameterisasi berdasarkan tanggal, bersifat idempoten, dan memiliki mekanisme monitoring untuk melacak progresnya. Pada Apache Airflow, backfill dapat dilakukan dengan perintah airflow dags backfill --start-date 2026-01-01 --end-date 2026-03-31, yang akan menjalankan DAG untuk setiap interval dalam rentang tersebut.

3. Streaming dan Pemrosesan Data Real-Time

Pertanyaan 7: Apa perbedaan antara pemrosesan batch dan streaming? Kapan masing-masing dipilih?

Pemrosesan batch mengolah data dalam kelompok besar pada interval terjadwal (per jam, harian), sedangkan pemrosesan streaming mengolah data secara kontinu saat data tiba. Batch cocok untuk laporan analitik, proses ETL harian, dan perhitungan yang memerlukan dataset lengkap. Streaming diperlukan ketika latensi rendah menjadi kebutuhan bisnis, seperti deteksi penipuan real-time, personalisasi konten, dan monitoring sistem.

Banyak arsitektur modern mengadopsi pendekatan hybrid: data streaming untuk kebutuhan operasional real-time, sementara batch processing tetap digunakan untuk rekonsiliasi dan analitik historis.

Pertanyaan 8: Jelaskan konsep event time vs processing time dalam stream processing.

Event time adalah waktu ketika sebuah peristiwa benar-benar terjadi di sumbernya, sedangkan processing time adalah waktu ketika sistem memproses peristiwa tersebut. Perbedaan keduanya menjadi kritis ketika ada keterlambatan pengiriman data (late-arriving data). Sistem stream processing modern seperti Apache Flink dan Kafka Streams menggunakan watermark untuk menentukan seberapa lama sistem menunggu data yang terlambat sebelum menutup sebuah window agregasi. Penanganan watermark yang tepat menjadi kunci akurasi hasil pada sistem streaming.

Pertanyaan 9: Apa perbedaan antara at-least-once, at-most-once, dan exactly-once delivery?

Tiga semantik pengiriman pesan ini menentukan jaminan pemrosesan dalam sistem terdistribusi:

• At-most-once: Pesan dikirim sekali tanpa retry. Risiko kehilangan data, tetapi tidak ada duplikasi. Cocok untuk metrik non-kritis.
• At-least-once: Pesan dikirim ulang jika tidak ada acknowledgment. Tidak ada kehilangan data, tetapi mungkin ada duplikasi. Solusinya adalah membuat consumer bersifat idempoten.
• Exactly-once: Setiap pesan diproses tepat sekali. Dicapai melalui kombinasi transaksi atomik, idempotent producer, dan checkpointing. Kafka mendukung ini melalui fitur transactional API dan idempotent producer.

4. Data Modeling dan Desain Skema

Pertanyaan 10: Apa perbedaan antara star schema dan snowflake schema?

Kedua skema ini merupakan pendekatan fundamental dalam data warehousing dimensional:

| Aspek | Star Schema | Snowflake Schema | |---|---|---| | Struktur | Tabel fakta di pusat, dimensi langsung terhubung | Dimensi dinormalisasi ke sub-dimensi | | Normalisasi | Denormalized | Normalized (3NF pada dimensi) | | Performa query | Lebih cepat (lebih sedikit JOIN) | Lebih lambat (lebih banyak JOIN) | | Penyimpanan | Lebih besar (data redundan) | Lebih efisien (tanpa redundansi) | | Kompleksitas | Sederhana, mudah dipahami | Lebih kompleks | | Cocok untuk | BI tools, analitik ad-hoc | Skenario yang memerlukan integritas data ketat |

Dalam praktik modern, star schema lebih sering dipilih karena biaya penyimpanan cloud yang relatif murah dan kebutuhan performa query yang tinggi. Untuk latihan lebih lanjut, kunjungi modul wawancara data modeling.

Pertanyaan 11: Apa itu Slowly Changing Dimension (SCD) dan jelaskan tipe-tipe utamanya.

SCD menangani perubahan data pada tabel dimensi sepanjang waktu. Tiga tipe utamanya adalah:

• SCD Type 1: Nilai lama ditimpa dengan nilai baru. Tidak ada histori yang disimpan. Digunakan ketika histori tidak diperlukan, misalnya koreksi kesalahan penulisan.
• SCD Type 2: Baris baru ditambahkan untuk setiap perubahan, dengan kolom effective_date, end_date, dan is_current. Histori lengkap dipertahankan. Ini tipe yang paling umum digunakan.
• SCD Type 3: Kolom tambahan ditambahkan untuk menyimpan nilai sebelumnya (misalnya previous_address). Hanya satu level histori yang tersimpan.

Pertanyaan 12: Kapan sebaiknya menggunakan pendekatan wide table (One Big Table) dibandingkan model dimensional?

Pendekatan wide table atau One Big Table (OBT) menggabungkan semua data ke dalam satu tabel besar yang sudah di-denormalize. Pendekatan ini cocok ketika pola akses data terbatas dan dapat diprediksi, jumlah dimensi sedikit, dan performa query menjadi prioritas utama. Namun, model dimensional tetap lebih unggul untuk skenario yang memerlukan fleksibilitas query, memiliki banyak tabel fakta, dan membutuhkan konsistensi data lintas domain bisnis. Data warehouse modern sering menggunakan kombinasi keduanya: model dimensional sebagai lapisan utama dan wide table sebagai mart tujuan khusus.

5. Apache Spark dan Pemrosesan Terdistribusi

Pertanyaan 13: Apa perbedaan antara transformation dan action di Spark?

Spark menggunakan evaluasi lazy, di mana transformation (seperti filter, map, groupBy) hanya mendefinisikan rencana komputasi tanpa langsung mengeksekusinya. Eksekusi baru terjadi ketika sebuah action (seperti count, collect, write) dipanggil. Pendekatan ini memungkinkan Spark mengoptimalkan keseluruhan rencana eksekusi melalui Catalyst optimizer sebelum menjalankan komputasi. Pemahaman tentang konsep ini sangat penting untuk menulis kode Spark yang efisien, karena menempatkan filter sedini mungkin dalam DAG transformasi dapat mengurangi jumlah data yang diproses secara signifikan.

Pertanyaan 14: Apa itu data skew di Spark dan bagaimana mengatasinya?

Data skew terjadi ketika distribusi data pada partisi tidak merata, menyebabkan beberapa task memproses data jauh lebih banyak dari yang lain. Gejala utamanya adalah sebagian besar task selesai dengan cepat sementara satu atau dua task membutuhkan waktu sangat lama.

Solusi yang umum digunakan meliputi:

• Salting: Menambahkan komponen acak pada join key untuk mendistribusikan data secara merata.
• Broadcast join: Jika salah satu tabel cukup kecil, menggunakan broadcast join untuk menghindari shuffle.
• Adaptive Query Execution (AQE): Fitur bawaan Spark 3.x yang secara otomatis mengoptimalkan partisi saat runtime.

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

Pertanyaan 15: Jelaskan perbedaan antara cache() dan persist() di Spark.

cache() menyimpan DataFrame di memori dengan level penyimpanan default MEMORY_AND_DISK, sedangkan persist() memberikan kontrol lebih granular atas level penyimpanan (MEMORY_ONLY, MEMORY_AND_DISK, DISK_ONLY, OFF_HEAP, dan variannya). Caching sebaiknya digunakan ketika sebuah DataFrame direferensikan berulang kali dalam DAG yang sama. Namun, caching yang berlebihan dapat menghabiskan memori executor dan justru menurunkan performa. Disarankan untuk selalu memanggil unpersist() setelah DataFrame tidak lagi diperlukan.

6. Orkestrasi dan Manajemen Pipeline

Pertanyaan 16: Bandingkan Airflow, Dagster, dan Prefect sebagai tools orkestrasi data.

| Aspek | Apache Airflow | Dagster | Prefect | |---|---|---|---| | Paradigma | DAG berbasis task | DAG berbasis asset (Software-Defined Assets) | Flow dan task berbasis Python | | Konfigurasi | Python DSL, operator-based | Decorator-based, asset-centric | Decorator-based, Pythonic | | Testing | Sulit, memerlukan mock | Built-in testing framework | Unit test langsung pada flow | | UI | Mature, fokus pada monitoring DAG | Modern, asset lineage graph | Cloud-based dashboard | | Komunitas | Terbesar, ekosistem plugin luas | Berkembang pesat | Aktif, fokus pada kemudahan | | Cocok untuk | Tim besar, kebutuhan enterprise | Tim data modern, pendekatan data-as-code | Tim kecil-menengah, iterasi cepat |

Untuk memperdalam pemahaman tentang Airflow, kunjungi modul dasar-dasar Airflow.

Pertanyaan 17: Apa itu DAG dan mengapa penting dalam orkestrasi data?

DAG (Directed Acyclic Graph) adalah representasi visual dan logis dari urutan eksekusi task dalam sebuah pipeline. Sifat "directed" berarti setiap edge memiliki arah yang jelas (task A harus selesai sebelum task B), dan "acyclic" berarti tidak ada siklus atau dependensi melingkar. DAG memungkinkan orkestrator untuk menentukan task mana yang dapat dijalankan secara paralel, menangani kegagalan pada titik yang tepat tanpa menjalankan ulang seluruh pipeline, dan memberikan visibilitas penuh terhadap dependensi antar komponen.

Pertanyaan 18: Bagaimana menangani kegagalan task dalam pipeline orchestration?

Penanganan kegagalan yang baik melibatkan beberapa strategi berlapis:

• Retry policy: Mengonfigurasi jumlah retry dan delay antara percobaan. Untuk kegagalan sementara (network timeout), retry biasanya cukup efektif.
• Alerting: Mengintegrasikan notifikasi (Slack, email, PagerDuty) pada callback on_failure agar tim segera mengetahui masalah.
• Idempoten task: Memastikan setiap task aman untuk dijalankan ulang tanpa efek samping.
• Circuit breaker: Menghentikan eksekusi pipeline jika tingkat kegagalan melebihi ambang batas tertentu, mencegah kerusakan data yang lebih luas.
• Dead-letter queue: Untuk pipeline streaming, menyimpan event yang gagal diproses ke antrian terpisah untuk investigasi dan reprocessing manual.

7. Platform Data Cloud dan Arsitektur Lakehouse

Pertanyaan 19: Apa itu arsitektur lakehouse dan apa keunggulannya?

Arsitektur lakehouse menggabungkan keunggulan data lake (penyimpanan murah, format terbuka, fleksibilitas skema) dengan fitur data warehouse (transaksi ACID, time travel, performa query tinggi). Implementasi utamanya menggunakan format tabel terbuka seperti Delta Lake, Apache Iceberg, atau Apache Hudi yang berjalan di atas object storage (S3, GCS, ADLS).

Keunggulan utama lakehouse meliputi: satu salinan data untuk semua workload (BI, ML, streaming), dukungan transaksi ACID pada data lake, kemampuan schema evolution tanpa migrasi, time travel untuk audit dan rollback, serta penghematan biaya karena tidak perlu menduplikasi data ke warehouse terpisah.

Pertanyaan 20: Bandingkan Delta Lake, Apache Iceberg, dan Apache Hudi.

Ketiganya merupakan format tabel terbuka yang menghadirkan fitur warehouse ke data lake, namun memiliki keunggulan masing-masing. Delta Lake memiliki integrasi terbaik dengan ekosistem Databricks dan Spark. Apache Iceberg unggul dalam dukungan multi-engine (Spark, Flink, Trino, Presto) dan fitur hidden partitioning yang membebaskan pengguna dari pengetahuan detail partisi saat menulis query. Apache Hudi dirancang khusus untuk skenario upsert dan incremental processing dengan performa tinggi. Dalam praktik, pemilihan format sering ditentukan oleh ekosistem cloud dan tools yang sudah digunakan oleh organisasi.

8. Kualitas Data dan Governance

Pertanyaan 21: Bagaimana memastikan kualitas data dalam pipeline produksi?

Kualitas data dijamin melalui validasi berlapis pada setiap tahap pipeline:

• Schema validation: Memastikan tipe data, kolom wajib, dan format sesuai ekspektasi di awal pipeline.
• Data contracts: Mendefinisikan kontrak formal antara producer dan consumer data yang mencakup skema, SLA, dan aturan kualitas.
• Statistical checks: Menggunakan tools seperti Great Expectations atau dbt tests untuk memvalidasi distribusi data, uniqueness, referential integrity, dan aturan bisnis.
• Freshness monitoring: Memantau ketepatan waktu pembaruan data untuk mendeteksi pipeline yang terlambat atau gagal.
• Data observability: Platform seperti Monte Carlo atau Bigeye untuk mendeteksi anomali secara otomatis menggunakan machine learning.

Pertanyaan 22: Apa itu data lineage dan mengapa penting?

Data lineage adalah pemetaan lengkap perjalanan data dari sumber hingga tujuan akhir, mencakup semua transformasi yang diterapkan di setiap tahap. Lineage penting untuk beberapa alasan: root cause analysis (melacak sumber masalah kualitas data dengan cepat), impact analysis (memahami dampak perubahan skema terhadap downstream), compliance (membuktikan asal-usul data untuk kepatuhan regulasi seperti GDPR), dan dokumentasi otomatis (memberikan visibilitas terhadap aliran data tanpa dokumentasi manual). Tools modern seperti OpenLineage, dbt docs, dan Datahub menyediakan lineage secara otomatis dari metadata eksekusi pipeline.

9. Desain Sistem dan Arsitektur

Pertanyaan 23: Bagaimana merancang pipeline data yang dapat menangani 10 miliar event per hari?

Perancangan sistem berskala besar memerlukan pertimbangan menyeluruh pada setiap komponen:

• Ingestion: Menggunakan Apache Kafka atau Amazon Kinesis sebagai buffer dengan partisi yang cukup untuk throughput target. Untuk 10 miliar event/hari (~115 ribu event/detik), diperlukan puluhan partisi Kafka.
• Processing: Memilih antara micro-batch (Spark Structured Streaming) atau true streaming (Flink) berdasarkan kebutuhan latensi.
• Storage: Lakehouse format (Iceberg/Delta) di object storage dengan partisi berdasarkan waktu dan strategi compaction otomatis.
• Compute: Auto-scaling cluster yang menyesuaikan kapasitas berdasarkan volume data.
• Monitoring: Dashboard real-time untuk throughput, latensi, dan error rate di setiap tahap pipeline.

Pertanyaan 24: Jelaskan pola medallion architecture (Bronze-Silver-Gold).

Medallion architecture mengorganisasi data dalam tiga lapisan bertingkat:

• Bronze (Raw): Data mentah yang dimuat apa adanya dari sumber, tanpa transformasi. Berfungsi sebagai sumber kebenaran dan memungkinkan reprocessing kapan saja.
• Silver (Cleaned): Data yang telah dibersihkan, deduplikasi, dan divalidasi. Skema diterapkan, null ditangani, dan data dari berbagai sumber diintegrasikan.
• Gold (Business): Data yang telah diagregasi dan dimodelkan sesuai kebutuhan bisnis spesifik. Biasanya berbentuk star schema atau metric mart yang siap dikonsumsi oleh BI tools dan aplikasi.

Keunggulan pola ini adalah pemisahan tanggung jawab yang jelas, kemampuan reprocessing tanpa kehilangan data mentah, dan fleksibilitas untuk melayani berbagai kebutuhan konsumen data dari satu platform.

Pertanyaan 25: Bagaimana mendesain strategi partitioning dan bucketing yang efektif?

Partitioning membagi data ke dalam direktori terpisah berdasarkan kolom tertentu (biasanya tanggal), sehingga query hanya membaca partisi yang relevan (partition pruning). Bucketing mendistribusikan data ke dalam sejumlah file tetap berdasarkan hash kolom tertentu, mengoptimalkan operasi join dan agregasi.

Panduan pemilihan strategi:

• Partisi berdasarkan waktu (tanggal, jam) untuk data time-series atau event log.
• Hindari over-partitioning: Jika partisi menghasilkan file-file sangat kecil (< 128MB), ini justru menurunkan performa karena overhead metadata.
• Bucketing digunakan ketika join antar tabel besar sering dilakukan pada kolom yang sama, memungkinkan bucket-level join tanpa shuffle penuh.
• Kombinasi keduanya: Partisi berdasarkan tanggal dengan bucketing berdasarkan user_id pada tabel yang sering di-join berdasarkan pengguna.

10. Strategi Persiapan Wawancara Data Engineering

Mempersiapkan wawancara data engineering memerlukan pendekatan terstruktur yang mencakup teori dan praktik. Berikut rangkuman langkah-langkah yang disarankan:

• Kuasai SQL secara mendalam: Latihan window function, CTE, optimasi query, dan execution plan menjadi pondasi yang tidak bisa ditawar.
• Pahami trade-off arsitektur: Pewawancara tidak mencari jawaban "benar", melainkan kemampuan kandidat menganalisis kelebihan dan kekurangan setiap pendekatan berdasarkan konteks.
• Bangun proyek nyata: Pengalaman membangun pipeline end-to-end, bahkan dalam skala kecil, memberikan kepercayaan diri yang tidak bisa digantikan oleh teori.
• Pelajari ekosistem cloud: Familiar dengan layanan data di AWS, GCP, atau Azure menjadi nilai tambah yang signifikan.
• Latihan system design: Biasakan merancang arsitektur data dari nol dengan mempertimbangkan skalabilitas, keandalan, dan biaya.
• Tetap mengikuti perkembangan terbaru: Format tabel terbuka, arsitektur lakehouse, dan paradigma orkestrasi baru terus berkembang dan sering muncul dalam wawancara.

Kesimpulan

Wawancara data engineering pada tahun 2026 menuntut pemahaman yang luas dan mendalam, mulai dari fondasi SQL hingga desain sistem berskala besar. Dua puluh lima pertanyaan yang dibahas dalam panduan ini mencerminkan topik-topik yang paling konsisten diajukan oleh perusahaan teknologi terkemuka.

Poin-poin utama yang perlu diingat:

• SQL tetap menjadi keterampilan dasar yang paling diuji. Penguasaan window function, optimasi query, dan pemahaman execution plan membedakan kandidat yang kuat.
• Arsitektur pipeline harus idempoten dan fault-tolerant. Pemahaman tentang pola ETL/ELT, backfill, dan penanganan kegagalan menunjukkan kematangan teknis.
• Data modeling bukan sekadar teori. Kemampuan memilih antara star schema, snowflake, atau pendekatan lainnya berdasarkan kebutuhan bisnis nyata sangat dihargai.
• Pemrosesan terdistribusi dan streaming semakin menjadi kebutuhan standar. Pengetahuan tentang Spark, Kafka, dan semantik pengiriman pesan menunjukkan kesiapan untuk tantangan skala besar.
• Platform cloud dan arsitektur lakehouse mendominasi lanskap modern. Familiar dengan format tabel terbuka dan pola medallion memberikan keunggulan kompetitif.

Persiapan yang konsisten dan terstruktur menjadi kunci keberhasilan. Mulailah dengan memahami konsep, lanjutkan dengan praktik langsung, dan validasi pemahaman melalui latihan wawancara yang realistis di jalur persiapan wawancara data engineering SharpSkill.