CV Programmer: Tunjukkan Proyek, Kontribusi, dan Bukti yang Siap Dibahas

CV programmer yang berisi “Python, JavaScript, SQL, dan Git” belum menjelaskan pekerjaan yang bisa kamu lakukan. Tunjukkan proyeknya, bagian yang kamu kerjakan, dan bukti perilaku perubahan pada kasus yang diperiksa. Hubungkan setiap teknologi utama dengan perubahan yang kamu kerjakan dan dapat kamu jelaskan.

Mulailah dari satu klaim yang bisa kamu pertanggungjawabkan. Misalnya, “Membuat validasi impor CSV untuk menolak ID duplikat, disertai pengujian input valid dan tidak valid.” Kalimat itu memberi arah untuk membaca kode dan mengajukan pertanyaan. Latih penjelasannya lewat Explain Your Most Meaningful Project Contribution.

Batas bukti: saran penulisan dalam artikel ini adalah pertimbangan editorial, bukan aturan seluruh perusahaan atau jaminan lolos ATS. Contoh kandidat dan proyek bersifat fiktif. Komponen Python ilustratif di bawah benar-benar dijalankan secara lokal dengan 14 kasus uji, tetapi bukan proyek milik kandidat nyata, sistem produksi, atau bukti dampak bisnis. Tidak ada laporan kandidat yang digunakan untuk memprediksi proses rekrutmen.

Pilih proyek dari pekerjaan yang ingin kamu tunjukkan

Panduan CV programmer dari Cake, yang bertanggal 2022 dan kami periksa kembali pada 11 Oktober 2026, sudah membahas bagian CV, keterampilan, pengalaman, dan proyek pribadi untuk pelamar tanpa pengalaman kerja. Itu adalah saran penerbit panduan karier, bukan ketentuan resmi perusahaan yang kamu lamar.

Tambahan yang kita kerjakan di sini adalah hubungan antara satu kalimat CV, kode yang relevan, dan penjelasan teknisnya. Untuk lowongan yang menekankan pemrosesan data, komponen impor dengan validasi dapat lebih relevan daripada halaman profil yang hanya menampilkan tampilan. Untuk pekerjaan antarmuka, pilih perubahan pada formulir, aksesibilitas, atau keadaan aplikasi yang memang kamu pahami.

Jangan memilih proyek hanya karena namanya terdengar besar. Aplikasi kecil dapat menunjukkan keputusan yang jelas: data apa yang diterima, kegagalan apa yang ditolak, dan bagaimana kamu memeriksanya. Proyek besar yang tidak bisa kamu jelaskan justru meninggalkan banyak klaim tanpa batas tanggung jawab.

Baca persyaratan pengiriman dari lowongan sebelum mengatur format. Jika perusahaan meminta berkas tertentu atau jawaban pada formulir, ikuti instruksi tersebut. Artikel ini tidak menetapkan jumlah halaman, foto, bahasa, atau format berkas yang berlaku untuk semua pemberi kerja.

Susun informasi agar kontribusi mudah ditemukan

Tempatkan identitas profesional dan kontak yang kamu gunakan, ringkasan yang relevan, pengalaman atau proyek, keterampilan, dan pendidikan sesuai kebutuhan lamaran. Untuk pemula, proyek yang relevan dapat muncul lebih awal daripada pekerjaan yang tidak berkaitan. Untuk programmer berpengalaman, perubahan pada pekerjaan terakhir mungkin menjadi bukti yang lebih penting.

Ringkasan tidak perlu menjadi kumpulan sifat seperti “pekerja keras, cepat belajar, dan berorientasi hasil”. Contoh fiktif yang lebih terarah adalah: “Programmer junior dengan proyek Python untuk validasi data CSV dan pengujian otomatis; ingin bekerja pada pemrosesan data aplikasi.” Gunakan kalimat itu hanya bila pengalamanmu memang mendukungnya.

Pada setiap proyek, beri konteks singkat: proyek pribadi, tugas kuliah, kerja magang, pekerjaan berbayar, atau kontribusi pada proyek orang lain. Kemudian tulis perubahan milikmu. Label tersebut menentukan bagaimana pembaca menafsirkan skala pekerjaan dan siapa yang mengambil keputusan.

Keterampilan dapat dikelompokkan berdasarkan penggunaannya. “Python: parsing CSV dan unit test” memberi bukti yang berbeda dari “Python: pernah mengikuti kursus”. Keduanya boleh dicatat dengan jujur; tidak perlu menyamakan penyelesaian kursus dengan pengalaman mengoperasikan aplikasi.

Ubah klaim umum menjadi kalimat yang bisa ditelusuri

Gunakan empat unsur: komponen, tindakanmu, perilaku yang berubah, dan cara memeriksanya. Tidak semua unsur harus panjang. Yang penting, kalimat tersebut tidak mengambil hasil seluruh tim sebagai hasil individu.

Angka 90% pada contoh awal sengaja tidak dipertahankan: tidak ada definisi kualitas, jumlah sampel, atau pengukuran yang mendukungnya. Hasil uji dapat menggantikan klaim besar yang tidak terbukti, tetapi bukan menggantikan semua bentuk hasil. Jika kamu memiliki metrik nyata, simpan definisi, periode, pembanding, dan peranmu dalam perubahan tersebut.

Contoh butir CV untuk proyek pribadi: “Membuat parser CSV Python pada prototipe pencatatan pengeluaran; memvalidasi ID dan nominal rupiah serta menambahkan uji kasus valid dan penolakan input.” Ini tidak mengklaim penggunaan oleh pelanggan, penyimpanan transaksi, atau peningkatan pendapatan.

Contoh pekerjaan pemeliharaan harus lebih sempit bila peranmu memang terbatas: “Menambahkan pemeriksaan ID duplikat dan uji regresi pada modul impor tim; rancangan alur dan rilis ditangani anggota lain.” Kedua contoh menunjukkan kontribusi teknis, tetapi tidak menunjukkan tingkat kepemilikan yang sama.

Proyek contoh: parser kecil dengan aturan yang jelas

Berikut komponen asli untuk latihan. Aturannya: header harus tepat id,amount_rupiah; ID tidak kosong dan unik setelah spasi di tepi dibuang; nominal berupa digit ASCII untuk bilangan bulat nonnegatif. Angka nol diterima. Tidak ada pemisah ribuan atau pecahan, dan fungsi mengembalikan daftar tanpa menulis ke basis data.

Simpan sebagai expense_import.py:

import csv
import io
import re


def parse_expenses(text):
    reader = csv.DictReader(io.StringIO(text), strict=True)
    if reader.fieldnames != ["id", "amount_rupiah"]:
        raise ValueError("header harus id,amount_rupiah")
    seen, result = set(), []
    for row in reader:
        line = reader.line_num
        if None in row or any(value is None for value in row.values()):
            raise ValueError(f"baris {line}: jumlah kolom salah")
        item_id = row["id"].strip()
        amount = row["amount_rupiah"].strip()
        if not item_id or item_id in seen:
            raise ValueError(f"baris {line}: id kosong atau duplikat")
        if not re.fullmatch(r"[0-9]+", amount):
            raise ValueError(f"baris {line}: nominal harus integer nonnegatif")
        seen.add(item_id)
        result.append({"id": item_id, "amount_rupiah": int(amount)})
    return result

Menurut dokumentasi resmi Python tentang CSV, DictReader memetakan kolom ke nama field; kolom berlebih dan nilai yang hilang memiliki perlakuan khusus. Karena itu, komponen ini memeriksa bentuk baris sebelum memanggil .strip(). Aturan ID dan nominal adalah keputusan contoh kita, bukan validasi yang otomatis disediakan modul CSV.

Untuk input a,100, hasilnya berisi ID a dan nominal integer 100. Untuk dua baris dengan ID a, pemanggilan gagal dengan ValueError pada baris duplikat. ID a dianggap sama dengan a; ID A tetap berbeda karena contoh ini tidak menormalkan huruf besar dan kecil.

Keputusan seperti itu harus bisa dijelaskan. Mengapa menolak duplikat, bukan menjumlahkannya? Dalam prototipe ini, setiap ID mewakili satu catatan, sehingga penggabungan diam-diam dapat menyembunyikan kesalahan input. Aplikasi lain mungkin memiliki aturan berbeda. Mulailah dari kontrak data, kemudian pilih perilaku kode.

parse_expenses mengumpulkan hasil dalam memori dan berhenti ketika validasi sebuah baris gagal. Jika baris kedua gagal, pemanggil tidak menerima daftar hasil sebagian. Itu tidak membuktikan rollback basis data: tidak ada operasi basis data dalam fungsi ini. Jangan menulis “membangun impor transaksional” di CV berdasarkan komponen tersebut.

Pertanyaan lanjutan yang berguna adalah, “Bagaimana jika pengguna ingin tetap menerima baris yang valid?” Jawabannya memerlukan perubahan kontrak: hasil dapat memuat daftar diterima dan daftar kesalahan, kemudian pemanggil memutuskan apakah akan menyimpan sebagian. Itu belum diterapkan di sini. Sebutkan alternatif tersebut sebagai pertimbangan desain, bukan fitur proyek yang sudah selesai.

Pertanyaan lain adalah mengapa 1.000 ditolak, padahal pengguna Indonesia dapat memakainya sebagai pemisah ribuan. Contoh ini menerima angka mesin tanpa pemisah agar tidak menebak arti tanda titik. Jika produk harus menerima format lokal, tentukan aturan secara terpisah dan tambahkan kasus ambigu sebelum mengubah parser. Menulis “mendukung format rupiah” akan terlalu luas untuk kontrak saat ini.

Simpan hubungan ini dalam catatan persiapan: klaim CV, fungsi yang relevan, input pembuktian, keputusan pribadi, dan bagian yang belum dibuat. Catatan tersebut tidak perlu memenuhi CV; gunanya membantu kamu menjawab pertanyaan yang muncul dari kalimat pendek di sana.

Buat pengujian yang menjelaskan klaim CV

Simpan pengujian berikut sebagai test_expense_import.py di folder yang sama. Dokumentasi resmi unittest menjelaskan kerangka pengujian, assertion, dan subtest; contoh di sini menggunakan dua metode dengan total 14 kasus di dalamnya.

import unittest
from expense_import import parse_expenses


class ImportTests(unittest.TestCase):
    def test_valid(self):
        cases = [
            ("id,amount_rupiah\na,100\n", [{"id":"a","amount_rupiah":100}]),
            ("id,amount_rupiah\na,0\n", [{"id":"a","amount_rupiah":0}]),
            ("id,amount_rupiah\n a , 100 \n", [{"id":"a","amount_rupiah":100}]),
            ("id,amount_rupiah\n", []),
        ]
        for source, expected in cases:
            with self.subTest(source=source):
                self.assertEqual(parse_expenses(source), expected)

    def test_rejected(self):
        bad_rows = [
            "a,100\na,200\n", "a,100\n a ,200\n", ",100\n",
            "a,-1\n", "a,1.5\n", "a,100,extra\n", "a\n",
            "a,١٠٠\n",
        ]
        for body in bad_rows:
            with self.subTest(body=body), self.assertRaises(ValueError):
                parse_expenses("id,amount_rupiah\n" + body)
        for header in ["amount_rupiah,id\n100,a\n", ""]:
            with self.subTest(header=header), self.assertRaises(ValueError):
                parse_expenses(header)


if __name__ == "__main__":
    unittest.main()

Buka terminal di folder kedua berkas, lalu jalankan python -m unittest -v test_expense_import.py dengan Python 3.12. Pada Python 3.12.14, dua metode tersebut selesai dengan status OK, mencakup empat kasus diterima dan sepuluh kasus ditolak. Laporan runner menampilkan dua metode uji; angka 14 menghitung kasus di dalamnya. Keduanya tidak mengukur persentase coverage atau jumlah bug produksi yang diperbaiki.

Kasus ID yang hanya berbeda spasi memeriksa aturan normalisasi. Kasus nominal negatif dan pecahan memeriksa batas format. Kasus kolom tambahan dan kolom kurang memeriksa bentuk input. Digit non-ASCII ditolak karena kontrak contoh membatasi nominal ke karakter 0 sampai 9.

Pengujian ini tidak mencakup semua ukuran berkas, seluruh variasi CSV, integrasi antarmuka, atau penyimpanan persisten. Header kosong ditolak, sedangkan header yang benar tanpa baris data menghasilkan daftar kosong. Sebutkan perbedaan itu bila ditanya tentang “berkas kosong”; istilah yang sama dapat menunjuk dua kondisi berbeda.

Kamu tidak harus menyalin proyek ini ke CV. Gunakan cara kerjanya untuk memeriksa proyekmu sendiri: ambil klaim, temukan perilaku yang dimaksud, lalu tunjukkan kasus yang dapat membuktikan atau membantahnya. Menjalankan contoh orang lain belum menjadikan kontribusinya milikmu.

Siapkan paket bukti yang ringkas dan dapat dibuka

Untuk proyek yang boleh dipublikasikan, arahkan tautan CV ke halaman yang membantu pembaca memulai, bukan ke folder tanpa penjelasan. Dokumentasi GitHub tentang README menjelaskan penggunaannya untuk menerangkan kegunaan proyek, cara mulai, dan pihak yang berkontribusi.

Untuk komponen contoh, README cukup menjelaskan format CSV, aturan validasi, versi Python yang dipakai, perintah uji, dan batas bahwa tidak ada penyimpanan basis data. Tambahkan satu input valid dan satu input ditolak. Dengan informasi itu, pembaca dapat menjalankan contoh dan memeriksa perilaku yang disebut pada butir CV.

Buka tautan dari jendela yang tidak memakai sesi akunmu untuk memastikan izin aksesnya sesuai tujuan. Periksa apakah README menyebut nama berkas yang benar, perintah masih bekerja, dan hasil yang kamu jelaskan masih cocok dengan revisi kode. Tautan hidup saja belum membuktikan proyek siap dipahami.

Untuk pekerjaan perusahaan yang tidak boleh dibuka, siapkan uraian yang diizinkan: masalah input, tanggung jawab pribadi, alternatif yang dipertimbangkan, dan bentuk pemeriksaan. Jangan membuat repository publik berisi kode internal untuk memenuhi saran portofolio. Kamu dapat menjelaskan keputusan tanpa memindahkan data pelanggan atau rahasia perusahaan.

Pisahkan tutorial, bantuan AI, dan keputusan sendiri

Jika proyek berawal dari tutorial, sebutkan asalnya pada dokumentasi, lalu tunjukkan perubahan yang kamu kerjakan. Contoh yang jujur: “Mengikuti tutorial dasar impor CSV, kemudian menambahkan aturan ID duplikat dan pengujian kasus kolom kurang.” Jangan mengaku merancang seluruh aplikasi apabila struktur utamanya berasal dari panduan.

Bantuan AI juga tidak menggantikan penjelasan. Bila kode dihasilkan dengan bantuan alat, kamu tetap perlu memahami kontrak input, alur kesalahan, dan alasan uji yang dipilih. Siapkan jawaban tentang apa yang disarankan alat, apa yang kamu ubah, serta bagaimana kamu memeriksa hasilnya. Ikuti pula aturan penggunaan alat jika pemberi kerja mengaturnya dalam tugas rekrutmen.

Jika pertanyaan sederhana tentang kode belum bisa dijawab, persempit klaim dan pelajari bagian tersebut. Kalimat yang lebih kecil tetapi dapat dibahas lebih berguna daripada daftar kemampuan yang memerlukan banyak pengecualian baru saat wawancara.

Gunakan lima pertanyaan untuk menguji kesiapan penjelasan

Tautan berikut adalah halaman latihan PracHub yang sudah diperiksa. Judul berbahasa Inggris dipertahankan sesuai halaman. Ini bukan daftar pertanyaan yang dilaporkan oleh kandidat pada perusahaan Indonesia tertentu.

Mulai dari penjelasan kontribusi proyek. Baca satu butir CV, lalu jelaskan komponen, keputusan, bukti, dan batasnya tanpa menambah hasil yang tidak pernah diukur. Bila penjelasan lisan berbeda dari yang tertulis, perbaiki CV atau buktinya sebelum mengirim lamaran.

Sources and Further Reading

• Cake: Contoh CV Programmer dan Cara Membuatnya
• GitHub Docs: About READMEs
• Python 3.12: CSV File Reading and Writing
• Python 3.12: unittest