Pola “Interview Yourself”: Teknik Klarifikasi dengan Claude

Teknik interview yourself untuk klarifikasi spec golang berangkat dari satu kenyataan: keahlian paling berharga seorang senior engineer bukan tentang kode, tapi tentang kemampuan mengajukan pertanyaan yang tepat sebelum mulai coding. Kemampuan untuk mengubah “buatkan fitur X” menjadi understanding yang jelas tentang apa sebenarnya yang dibutuhkan.

Pola “Interview Yourself” adalah teknik yang mensimulasikan proses ini dengan Claude sebagai interviewer. Alih-alih langsung menulis spec, kamu memulai dialog di mana Claude mengajukan pertanyaan klarifikasi — dan kamu menjawabnya — sampai spec bisa ditulis dengan presisi.

07.1 Mengapa Klarifikasi Itu Sulit Dilakukan Sendiri

Ada psychological challenge dalam self-clarification: kita cenderung tidak tahu apa yang tidak kita tahu. Ketika menulis spec sendiri, kita mengisi kekosongan dengan asumsi yang terasa obvious — padahal asumsi tersebut mungkin tidak shared oleh developer lain, QA, atau AI yang akan mengimplementasikan. Contoh nyata di Santekno Shop berikut memperlihatkan bagaimana satu kalimat spec bisa dibaca sangat berbeda oleh dua orang.

 1Developer A menulis spec:
 2"User bisa cancel order yang belum diproses"
 3
 4Asumsi A (tidak tertulis): "belum diproses" = status PENDING
 5Asumsi B (tidak tertulis): cancel bisa kapan saja selama PENDING
 6Asumsi C (tidak tertulis): stok langsung balik saat cancel
 7
 8Developer B membaca spec yang sama dan assume:
 9"belum diproses" = status PENDING atau CONFIRMED (belum shipped)
10"cancel bisa kapan saja" = tapi ada timeout 24 jam dari order date
11"stok balik" = dijadwalkan, bukan immediate

Tiga developer, tiga interpretasi berbeda, satu spec yang ambigu — dan pola Interview Yourself mengeliminasi ini dengan mensurface asumsi-asumsi tersembunyi sebelum menjadi masalah di production.

07.2 Struktur Dasar Pola Interview Yourself

Agar mudah dibayangkan, alur pola ini bisa digambarkan sebagai pertukaran pertanyaan-jawaban antara kamu dan Claude yang berperan sebagai interviewer.

 1┌─────────────────────────────────────────────────────────┐
 2│                  INTERVIEW YOURSELF                     │
 3├─────────────────────────────────────────────────────────┤
 4│                                                         │
 5│  Kamu           Claude (sebagai Interviewer)           │
 6│    │                          │                         │
 7│    ├── "Saya ingin fitur X" ──►                         │
 8│    │                          │                         │
 9│    │◄── Q1: [pertanyaan 1] ───┤                         │
10│    ├── [jawaban 1] ───────────►                         │
11│    │                          │                         │
12│    │◄── Q2: [pertanyaan 2] ───┤                         │
13│    ├── [jawaban 2] ───────────►                         │
14│    │                          │                         │
15│    │◄── Q3-Q5: [...] ─────────┤                         │
16│    ├── [jawaban 3-5] ─────────►                         │
17│    │                          │                         │
18│    │◄── "Spec siap ditranslate"│                         │
19│    │                          │                         │
20│    │◄── [Draft Spec] ─────────┤                         │
21│                                                         │
22└─────────────────────────────────────────────────────────┘

Inti dari diagram di atas adalah lima langkah berurutan: kamu deskripsikan fitur high-level, Claude bertanya satu per satu, kamu jawab, Claude follow-up bila perlu, dan setelah cukup Claude menghasilkan draft spec. Sifat satu-pertanyaan-per-giliran inilah yang membuat setiap asumsi terungkap secara bertahap, bukan tertimbun dalam satu balasan panjang.

07.3 Prompt Pemula: Memulai Interview Session

Untuk memulai session Interview Yourself, kamu butuh prompt pembuka yang menetapkan peran Claude sekaligus aturan mainnya. Prompt berikut sudah teruji untuk konteks e-commerce.

 1Kamu adalah seorang senior product engineer yang sangat berpengalaman
 2dalam mendefinisikan requirements untuk sistem e-commerce.
 3
 4Saya akan mendeskripsikan sebuah fitur yang ingin diimplementasikan.
 5Tugasmu adalah mengajukan pertanyaan klarifikasi seperti interview
 6yang akan mengungkap semua asumsi tersembunyi dan ambiguitas.
 7
 8Rules untuk interview:
 91. Ajukan SATU pertanyaan per giliran (jangan multiple sekaligus)
102. Pertanyaan harus spesifik dan concrete — bukan "bagaimana dengan error handling?"
11   tapi "jika user mencoba cancel order yang sudah CONFIRMED, apa yang harus terjadi?"
123. Ikuti thread pertanyaan sebelumnya sebelum pindah topik baru
134. Setelah merasa sudah cukup informasi, katakan "Saya sudah cukup informasi,
14   boleh saya buat draft spec-nya sekarang?"
155. Fokus pada area: happy path, error cases, concurrent scenarios,
16   external dependencies, data consistency
17
18Oke, saya ingin mengimplementasikan fitur cancel order di platform e-commerce
19Santekno Shop. Cancel dilakukan oleh customer.

Aturan nomor 1 dan 2 adalah yang paling menentukan kualitas session: memaksa satu pertanyaan konkret per giliran mencegah Claude melempar daftar pertanyaan generik yang mudah kamu jawab asal-asalan.

07.4 Contoh Session Interview Lengkap: Cancel Order

Teori akan lebih jelas lewat contoh nyata. Berikut transkrip session Interview Yourself yang realistis untuk fitur cancel order — perhatikan bagaimana setiap jawaban memunculkan pertanyaan lanjutan yang lebih tajam.

[Kamu]: Saya ingin mengimplementasikan fitur cancel order di Santekno Shop. Cancel dilakukan oleh customer.

[Claude sebagai Interviewer]: Pertanyaan pertama: Pada status order apa saja customer diperbolehkan melakukan cancel? Hanya PENDING, atau juga CONFIRMED?

[Kamu]: Hanya PENDING saja. Setelah CONFIRMED, merchant sudah mulai processing.

[Claude]: Baik. Apakah ada batas waktu untuk melakukan cancel? Misalnya, PENDING tapi sudah lebih dari 24 jam — apakah tetap bisa dicancel?

[Kamu]: Ya, kami putuskan ada batas waktu 15 menit dari waktu order dibuat. Setelah itu tidak bisa cancel meskipun masih PENDING.

[Claude]: Menarik. Ketika cancel berhasil, apa yang terjadi dengan stok produk dalam order tersebut?

[Kamu]: Stok harus dikembalikan secara otomatis. Harus atomic — semua atau tidak sama sekali.

[Claude]: Siapa yang mendapat notifikasi setelah cancel berhasil? Customer saja, atau merchant juga?

[Kamu]: Customer dapat email. Merchant juga harus dapat notifikasi karena mereka sudah reserve stok. Notifikasi via Kafka event.

[Claude]: Bagus. Jika ada dua request cancel bersamaan untuk order yang sama — misalnya customer klik dua kali — apa yang harus terjadi?

[Kamu]: Hanya satu yang berhasil, yang lain dapat error. Tidak boleh ada duplikasi.

[Claude]: Apakah ada kasus di mana cancel bisa dilakukan oleh pihak selain customer? Misalnya oleh sistem secara otomatis (timeout) atau oleh admin?

[Kamu]: Bukan scope spec ini. Admin cancel dan auto-cancel akan jadi spec terpisah.

[Claude]: Baik. Jika Kafka publish event gagal setelah order berhasil dicancel di database — apa yang harus dilakukan? Rollback, atau tetap sukses?

[Kamu]: Tetap sukses. Order sudah CANCELLED dan stok sudah dikembalikan. Kafka failure harus di-log sebagai warning, tapi tidak rollback. Notification service punya retry mechanism sendiri.

[Claude]: Satu lagi: apakah ada refund yang terkait dengan cancel? Apakah uang customer otomatis dikembalikan?

[Kamu]: Refund adalah proses terpisah. Spec ini hanya tentang cancel order, bukan refund. Refund akan di-handle secara terpisah.

[Claude]: Saya sudah cukup informasi. Boleh saya buat draft spec-nya sekarang?

[Kamu]: Silakan.

Setelah semua asumsi terungkap lewat dialog, Claude merangkumnya menjadi draft spec yang setiap barisnya bisa ditelusuri ke satu jawaban konkret. Berikut hasilnya.

 1# Cancel Order by Customer
 2# Versi: 1.0 — draft
 3# Owner: [belum ditentukan]
 4# Status: Draft — perlu review
 5
 6## User Story
 7Sebagai customer Santekno Shop yang ingin membatalkan pembelian,
 8saya ingin cancel order yang masih dalam status PENDING dan dibuat
 9dalam 15 menit terakhir agar stok produk dikembalikan dan merchant
10mendapat notifikasi untuk membatalkan preparasi.
11
12## Scope
13**Termasuk:** Cancel oleh customer, stock restore, Kafka event notification.
14**Tidak termasuk:** Cancel oleh admin (spec terpisah), auto-cancel (spec terpisah),
15proses refund (spec terpisah).
16
17## Acceptance Criteria
18
19### Happy Path
20- AC1: DELETE /orders/{id} dengan valid JWT Bearer token
21- AC2: Order harus milik user yang melakukan request (validated via user_id dari JWT)
22- AC3: Order harus dalam status PENDING
23- AC4: Waktu sejak order dibuat (created_at) harus ≤ 15 menit
24- AC5: Setelah cancel: status order berubah ke CANCELLED dan stok semua item
25       dikembalikan dalam satu atomic transaction di PostgreSQL
26- AC6: Event ORDER_CANCELLED dipublish ke Kafka (best effort, tidak blocking)
27- AC7: Response: 204 No Content
28
29### Error Cases
30- AC8: Order tidak ditemukan ATAU bukan milik user yang request →
31       404 Not Found (tidak expose apakah order exist tapi milik orang lain)
32       error_code: ORDER_NOT_FOUND
33- AC9: Order status bukan PENDING →
34       409 Conflict
35       error_code: ORDER_NOT_CANCELLABLE
36       message: "order cannot be cancelled: current status is {status}"
37- AC10: Lebih dari 15 menit sejak order dibuat →
38        409 Conflict
39        error_code: CANCEL_WINDOW_EXPIRED
40        message: "cancellation window has expired (order created at {created_at})"
41- AC11: Tidak ada Authorization header atau token invalid →
42        401 Unauthorized
43        error_code: UNAUTHORIZED
44
45## Edge Cases
46- EC1: Dua concurrent cancel request untuk order yang sama →
47       satu berhasil (204), yang lain mendapat 409 ORDER_NOT_CANCELLABLE
48       Implementasi: SELECT FOR UPDATE di dalam transaction
49
50- EC2: Kafka publish gagal setelah DB commit berhasil →
51       Log WARNING dengan order_id dan error detail
52       Tetap return 204 ke client — DB sudah final
53       Notification service bertanggung jawab atas delivery via retry
54
55- EC3: Stock restore parsial (satu item gagal di tengah) →
56       Rollback seluruh transaction
57       Return 500 Internal Server Error ke client
58       Log ERROR dengan detail item mana yang gagal
59
60## Non-Functional Requirements
61- NFR1: Response time < 300ms untuk p95
62- NFR2: Operasi cancel HARUS atomic (DB level)
63- NFR3: Metric: cancel_order_total (label: status=success|failure),
64        cancel_order_duration_seconds (histogram)
65
66## Changelog
67| v | Tanggal | Perubahan | Author |
68|---|---------|-----------|--------|
69| 1.0 | [hari ini] | Initial draft dari interview session | [nama] |

Bandingkan spec padat di atas dengan requirement satu kalimat di awal session: dari “cancel order oleh customer” kita sampai ke 11 AC, 3 edge case, dan 3 NFR — semuanya lahir dari jawaban, bukan asumsi AI.

07.5 Variasi Interview: Domain Expert Perspective

Kekuatan Interview Yourself berlipat ketika kamu meminta Claude berperan sebagai domain expert yang berbeda-beda. Variasi pertama adalah QA engineer skeptikal yang misinya mencari celah.

1Berperan sebagai QA engineer senior yang terkenal dengan kemampuannya
2menemukan bug di production. Kamu skeptikal dan selalu mencari celah.
3
4Saya akan describe fitur, kamu ajukan pertanyaan yang seorang QA
5akan ajukan untuk memastikan testing coverage yang komprehensif.
6
7Fokus pada: race conditions, boundary values, invalid input combinations,
8external system failures, dan data integrity issues.

Persona QA ini akan menggali skenario kegagalan yang jarang terpikirkan saat kamu fokus pada happy path. Variasi kedua menggeser sudut pandang ke keamanan.

1Berperan sebagai security engineer yang berfokus pada OWASP Top 10
2dan security best practices untuk API.
3
4Ajukan pertanyaan klarifikasi tentang aspek keamanan fitur ini:
5authentication, authorization, input validation, rate limiting,
6data exposure, dll.

Persona security memastikan aspek autentikasi dan otorisasi tidak terlewat dari spec. Variasi ketiga membawa perspektif performa di bawah beban tinggi.

1Berperan sebagai performance engineer yang pernah debug production
2outage di e-commerce platform selama flash sale.
3
4Ajukan pertanyaan tentang: expected load, database query performance,
5caching strategy, concurrent access patterns, dan scaling concerns.

Dengan bergiliran memakai ketiga persona ini, satu fitur diaudit dari sudut fungsional, keamanan, dan performa sekaligus — cakupan yang sulit dicapai jika kamu hanya berpikir dari satu sudut pandang.

07.6 Interview untuk Fitur yang Melibatkan Multiple Service

Ketika fitur membentang di beberapa service, interview jadi lebih kompleks tapi justru makin krusial. Prompt berikut menempatkan Claude sebagai senior architect distributed systems.

 1Kamu adalah senior architect yang berpengalaman dalam distributed systems.
 2
 3Saya ingin mengimplementasikan fitur "order confirmation email" yang
 4melibatkan Order Service, Notification Service, dan Email Provider.
 5
 6Ajukan pertanyaan klarifikasi tentang:
 71. Service boundaries (siapa yang responsible untuk apa)
 82. Communication patterns (sync vs async, yang mana pakai event)
 93. Error handling di setiap service
104. Idempotency dan eventual consistency
115. What happens when downstream service is down
12
13Mulai dari pertanyaan yang paling fundamental tentang ownership.

Menyuruh Claude “mulai dari pertanyaan tentang ownership” mengarahkan dialog ke akar masalah sistem terdistribusi — siapa memiliki apa — sebelum tenggelam ke detail komunikasi antar-service.

07.7 Mencatat Hasil Interview: Interview Notes

Setelah session selesai, keputusan yang terkumpul harus di-capture sebelum spec formal ditulis, agar alasan di baliknya tidak hilang. Format interview notes berikut memisahkan keputusan dari asumsi yang masih perlu dikonfirmasi.

 1# Interview Notes: Cancel Order Feature
 2Date: 2025-07-15
 3Participants: [nama engineer] + Claude (sebagai interviewer)
 4
 5## Key Decisions Made
 6
 7### Status eligibility
 8- **Decision:** Hanya PENDING yang bisa dicancel
 9- **Reason:** Setelah CONFIRMED, merchant sudah mulai processing
10- **Open questions:** [tidak ada]
11
12### Time window
13- **Decision:** 15 menit dari created_at
14- **Reason:** Keputusan UX untuk mencegah abuse
15- **Open questions:** Apakah perlu configurable? (out of scope sekarang)
16
17### Stock restore
18- **Decision:** Atomic dengan status change
19- **Reason:** Consistency requirement
20- **Implementation note:** SELECT FOR UPDATE di transaction
21
22### Notifications
23- **Decision:** Customer email + Merchant notification via Kafka
24- **Reason:** Merchant needs to know to stop preparing
25- **Implementation note:** Best effort, tidak blocking cancel operation
26
27### Concurrent cancel
28- **Decision:** Hanya satu yang berhasil
29- **Mechanism:** SELECT FOR UPDATE
30
31### Kafka failure
32- **Decision:** Log warning, tetap sukses
33- **Reason:** Notification service punya retry, cancel sudah committed
34
35### Refund
36- **Decision:** OUT OF SCOPE — spec terpisah
37
38## Assumptions Made (perlu dikonfirmasi dengan stakeholder)
39- [ ] 15 menit window apakah berdasarkan timezone user atau server?
40- [ ] Apakah customer dapat notifikasi jika cancel GAGAL (karena sudah expired)?
41- [ ] Merchant notification format apa yang dibutuhkan?

Bagian “Assumptions Made” di bawah adalah yang paling sering diabaikan padahal paling berharga: ia mendokumentasikan pertanyaan terbuka secara eksplisit, sehingga tidak ada keputusan diam-diam yang menyusup ke spec tanpa persetujuan stakeholder.

07.8 Kapan Menggunakan Interview Yourself vs Langsung Tulis Spec

Interview Yourself tidak selalu diperlukan; untuk pekerjaan yang sudah jelas, ia justru pemborosan waktu. Tabel berikut memetakan situasi umum ke rekomendasi yang tepat.

Pola dari tabel di atas jelas: semakin tinggi ketidakpastian dan dampak sebuah fitur, semakin besar payoff dari Interview Yourself — sementara pekerjaan rutin cukup ditulis langsung tanpa ritual klarifikasi.

07.9 Interview untuk Requirement dari Non-Technical Stakeholder

Sering requirement datang dari product manager atau business analyst yang tidak technical, dan Interview Yourself bisa dipakai untuk “menerjemahkannya” menjadi spec engineering. Prompt berikut menempatkan Claude sebagai jembatan antara bisnis dan teknis.

 1Requirement dari product manager:
 2"Kita mau tambah fitur loyalty points. Customer dapat poin setiap beli,
 3 bisa di-redeem untuk diskon. Seperti yang ada di Tokopedia."
 4
 5Berperan sebagai technical product manager yang bridge antara business
 6dan engineering. Ajukan pertanyaan untuk:
 71. Mengklarifikasi business rules (berapa poin per rupiah, conversion rate)
 82. Mendefinisikan edge cases (poin kadaluarsa? minimum redeem? maximum diskon?)
 93. Mengidentifikasi technical implications (apakah real-time atau batch?)
104. Memisahkan scope MVP dari future features
11
12Mulai dari pertanyaan yang paling business-critical.

Referensi “seperti yang ada di Tokopedia” adalah tipikal requirement non-teknis yang menyembunyikan puluhan keputusan; prompt ini memaksa keputusan tersebut dipecah menjadi business rules dan edge case yang eksplisit sebelum kode disentuh.

07.10 Advanced: Interview dengan Multiple Personas

Untuk fitur yang sangat kompleks, jalankan interview dengan beberapa persona secara berurutan sehingga setiap sudut pandang membangun di atas temuan sebelumnya:

Round 1: Product Engineer — happy path dan business rules Round 2: QA Engineer — edge cases dan testing scenarios Round 3: Security Engineer — authentication, authorization, data protection Round 4: Performance Engineer — load, latency, scaling

Rangkaian empat round ini bisa dijalankan dalam satu sesi terstruktur lewat prompt berikut.

 1Kita akan lakukan 4 round interview untuk fitur checkout.
 2
 3Round 1 — Product Engineer perspective:
 4Ajukan pertanyaan tentang business rules dan happy path.
 5Setelah saya jawab, kamu compile semua ke draft spec Round 1.
 6
 7Round 2 — QA Engineer perspective:
 8Baca draft dari Round 1. Ajukan pertanyaan tentang edge cases
 9dan testing scenarios yang belum ter-cover.
10Update draft spec dengan temuan Round 2.
11
12[lanjut untuk Round 3 dan 4]
13
14Di akhir semua round, hasilkan spec final yang komprehensif.
15Mulai Round 1.

Karena setiap round membaca draft round sebelumnya, spec tumbuh berlapis: pertanyaan security di Round 3 muncul dengan konteks penuh dari business rules dan edge case yang sudah dibahas, bukan dari nol.

07.11 Menggunakan Hasil Interview untuk Estimasi

Interview Yourself tidak hanya menghasilkan spec — ia juga memberikan bahan yang lebih akurat untuk estimasi karena AC dan EC sudah terurai. Setelah spec dari interview selesai, prompt berikut mengubahnya menjadi breakdown estimasi.

 1Berdasarkan spec yang baru saja kita hasilkan dari interview session,
 2bantu saya buat estimasi implementasi.
 3
 4Pertimbangkan:
 5- Task breakdown berdasarkan AC dan EC
 6- Complexity dari setiap task (low/medium/high)
 7- Dependencies antar task
 8- Testing effort (unit test untuk setiap AC)
 9- Review dan buffer time
10
11Output format:
12| Task | Complexity | Estimate (jam) | Dependencies |
13|------|-----------|----------------|--------------|
14| ... | ... | ... | ... |
15
16**Total estimate:** X jam
17**Confidence:** [high/medium/low]
18**Risks:** [hal yang bisa membuat estimate meleset]

Karena estimasi diturunkan dari AC yang sudah konkret, angkanya jauh lebih dipercaya daripada tebakan gut-feeling — dan kolom “Risks” memaksa asumsi yang bisa menggagalkan estimasi ikut ditulis di depan.

07.12 Dokumentasi Interview sebagai Artefak Proyek

Interview notes adalah artefak berharga yang sebaiknya disimpan berdampingan dengan spec-nya, bukan dibuang setelah dipakai. Struktur direktori berikut menempatkannya di dalam folder khusus di samping spec final.

1specs/
2└── domain/
3    └── order/
4        ├── cancel-order.md              ← spec final
5        └── _interviews/
6            └── cancel-order-2025-07-15.md  ← interview notes

Dengan menyimpan interview notes di dalam repo, ia menjadi sumber jawaban untuk pertanyaan onboarding (“kenapa 15 menit, bukan 30?”), debugging (“kenapa behavior-nya begini?”), sampai post-mortem — semua alasan keputusan terekam, bukan hilang bersama ingatan penulisnya.

07.13 Teknik Lanjutan: Socratic Questioning

Variasi paling advanced adalah Socratic Questioning, di mana Claude tidak hanya bertanya tentang fitur tapi juga mempertanyakan asumsi di balik jawabanmu. Prompt berikut mengaktifkan mode ini lengkap dengan contoh dialognya.

 1Gunakan metode Socratic dalam interview ini.
 2
 3Artinya:
 4- Bukan hanya ajukan pertanyaan untuk klarifikasi
 5- Tapi juga pertanyakan asumsi di balik jawabanku
 6- Bantu saya menemukan apakah keputusan yang saya buat benar-benar
 7  yang terbaik untuk user dan sistem
 8
 9Contoh:
10Kamu: "Kenapa batas waktunya 15 menit?"
11Saya: "Supaya user tidak bisa abuse dan cancel setelah stok langka habis"
12Kamu: "Apakah ada cara lain untuk mencegah abuse selain time window?
13       Misalnya rate limiting cancel per hari per user?"
14Saya: [mungkin menemukan bahwa time window bukan solusi terbaik]
15
16Fitur yang ingin saya spec: [nama fitur]

Metode Socratic ini berguna ketika kamu curiga keputusan awalmu didorong kebiasaan, bukan analisis — Claude membantu menguji apakah “15 menit” benar-benar solusi terbaik atau sekadar angka yang terasa aman.

07.14 Integrasi Interview dengan CLAUDE.md

Ketika Claude sudah membaca CLAUDE.md, hasil interview menjadi jauh lebih contextual karena ia sudah paham stack dan arsitektur proyek. Prompt berikut memanfaatkan konteks itu untuk memfokuskan pertanyaan ke keputusan bisnis.

 1[Di sesi di mana CLAUDE.md sudah dibaca]
 2
 3Jalankan Interview Yourself untuk fitur cancel order.
 4Kamu sudah tahu:
 5- Stack: Go 1.22, Echo v4, pgx/v5, Kafka
 6- Architecture: clean architecture
 7- Domain: Order (PENDING → CONFIRMED → SHIPPED → DELIVERED/CANCELLED)
 8- Pattern: lihat create_order.go untuk referensi
 9
10Pertanyaanmu harus lebih focused ke business decisions, bukan tech decisions
11(karena tech decisions sudah ada di CLAUDE.md).

Dengan CLAUDE.md sebagai konteks, Claude tidak lagi membuang giliran menanyakan hal yang sudah tertulis (stack, arsitektur) dan langsung menggali keputusan bisnis yang benar-benar butuh input darimu — interview jadi lebih pendek dan padat.

07.15 Pola Interview untuk Bug Fix yang Kompleks

Interview Yourself tidak terbatas pada fitur baru; ia juga ampuh untuk membedah bug yang kompleks. Prompt berikut menempatkan Claude sebagai senior debugger yang menuntunmu mempersempit root cause.

 1Berperan sebagai senior debugger. Saya akan describe bug yang ada.
 2Ajukan pertanyaan untuk memahami:
 31. Kondisi reproduksi (kapan terjadi, seberapa sering)
 42. Scope dampak (user mana yang teraffect)
 53. Expected vs actual behavior
 64. Recent changes yang mungkin related
 75. Apakah ini regression atau fitur yang tidak pernah benar
 8
 9Bug: "Beberapa customer melaporkan tidak bisa cancel order
10      meskipun baru dibuat 2 menit lalu"
11
12Mulai dari pertanyaan yang akan paling cepat narrow down root cause.

Alih-alih langsung menebak penyebab, interview memaksa investigasi terstruktur — dari kondisi reproduksi sampai perubahan terbaru — sehingga kamu tidak terjebak memperbaiki gejala yang salah.

07.16 Evaluasi Kualitas Interview

Bagaimana tahu apakah session sudah cukup komprehensif? Checklist berikut bisa dijalankan setelah interview untuk memastikan tidak ada dimensi penting yang terlewat.

 1## Interview Completeness Checklist
 2
 3### Business Rules
 4- [ ] Happy path fully defined (siapa, apa, kapan, hasilnya apa)
 5- [ ] Semua error scenarios yang bisa diprediksi sudah di-cover
 6- [ ] Scope boundaries jelas (apa yang IN dan OUT)
 7
 8### Technical Concerns
 9- [ ] Concurrent access scenario sudah di-address
10- [ ] External dependency failure scenarios sudah di-address
11- [ ] Data consistency requirements sudah jelas
12- [ ] Transaction boundaries sudah didefinisikan
13
14### Non-Functional
15- [ ] Performance expectations sudah diklarifikasi
16- [ ] Security requirements sudah di-address
17- [ ] Observability needs sudah disebutkan
18
19### Organizational
20- [ ] Ownership jelas (siapa yang bertanggung jawab)
21- [ ] Dependencies ke team/service lain sudah diidentifikasi
22- [ ] MVP vs future scope sudah jelas dipisahkan

Jika masih banyak kotak yang belum tercentang — terutama di kategori Technical Concerns — itu sinyal bahwa session perlu dilanjutkan atau fiturnya terlalu besar dan harus dipecah.

07.17 Interview Yourself dalam Konteks Sprint Planning

Interview Yourself bisa diintegrasikan langsung ke ritme sprint planning agar rapat perencanaan lebih efisien.

Sebelum sprint planning:

1. Engineer melakukan 15-menit Interview Yourself untuk setiap ticket yang akan masuk sprint
2. Hasil interview menjadi spec draft yang dibawa ke planning
3. Di planning, review spec draft bersama — bukan nol dari scratch

Manfaat:

• Sprint planning jadi lebih focused pada review, bukan exploration
• Estimasi lebih akurat karena sudah ada spec
• Fewer surprises saat implementation karena edge cases sudah identified

Dengan draft spec sudah di tangan sebelum rapat, waktu planning yang mahal dipakai untuk memvalidasi keputusan, bukan menemukannya dari awal — sebuah pergeseran kecil yang berdampak besar pada kualitas estimasi.

07.18 Tips & Gotchas

💡 Tip 1: Jangan rush ke jawaban — pikirkan sebelum menjawab. Interview Yourself paling efektif ketika kamu benar-benar memikirkan jawaban, bukan mengetik yang pertama muncul. Ambil 30 detik sebelum menjawab setiap pertanyaan.

💡 Tip 2: Jawab “tidak tahu” jika memang tidak tahu. Jika Claude bertanya sesuatu yang jawabannya belum kamu ketahui, jawab “Saya tidak tahu, perlu dikonfirmasi dengan [stakeholder X].” Ini lebih valuable daripada mengarang jawaban yang jadi asumsi salah di spec.

💡 Tip 3: Minta Claude ajukan pertanyaan follow-up. Jika Claude pindah topik tapi kamu merasa pertanyaan sebelumnya belum tuntas, katakan: “Sebelum pindah, apakah ada follow-up tentang [topik sebelumnya]?”

💡 Tip 4: Simpan transcript lengkap, bukan hanya hasil akhir. Transcript interview — termasuk pertanyaan dan jawaban — adalah dokumentasi berharga tentang “mengapa” keputusan diambil. Simpan bersama spec finalnya.

⚠️ Gotcha 1: Interview bisa berkepanjangan tanpa fokus. Batasi setiap session maksimum 20-30 menit atau 15-20 pertanyaan. Jika melewati ini dan masih banyak yang unclear, mungkin fiturnya terlalu besar — pecah jadi sub-fitur.

⚠️ Gotcha 2: Claude mungkin tidak tahu domain bisnis spesifik kamu. Claude tidak tahu bahwa “flash sale” di Santekno Shop berarti traffic spike 10x normal. Berikan context ini jika relevan.

⚠️ Gotcha 3: Pertanyaan Claude mungkin terlalu technical. Jika Claude mulai bertanya soal implementasi (SQL, indexing), redirect: “Fokus pada business behavior, bukan implementasi. Biarkan engineer yang putuskan tech detail.”

⚠️ Gotcha 4: Tidak semua jawaban harus masuk ke spec. Beberapa hal yang muncul dalam interview lebih tepat masuk ke ADR (Architecture Decision Record) atau technical notes, bukan ke spec feature. Pisahkan dengan baik.

07.19 Menggabungkan Interview Yourself dengan AI Lain

Interview Yourself tidak harus dilakukan hanya dengan Claude; menggabungkan beberapa AI untuk perspektif berbeda bisa menghasilkan spec yang lebih robust:

Claude Code: Untuk clarification yang butuh code context (arsitektur, patterns) ChatGPT: Untuk business perspective yang lebih general Perplexity: Untuk research tentang industry practice (“apakah 15 menit cancel window adalah standard di e-commerce?”)

Dengan memancing perspektif dari beberapa AI, kamu mengurangi bias satu model dan mendapatkan cross-check yang alami — misalnya memverifikasi apakah keputusan domainmu sejalan dengan praktik industri.

07.20 Ringkasan

Pola “Interview Yourself” adalah teknik klarifikasi yang mensimulasikan proses discovery antara engineer dan stakeholder — tapi dilakukan secara solo dengan Claude sebagai interviewer.

Tiga variasi utama:

1. Product Engineer interview — untuk business rules dan happy path
2. QA Engineer interview — untuk edge cases dan testing
3. Multi-persona interview — untuk fitur yang sangat complex

Kapan digunakan:

• Fitur baru yang belum pernah ada
• Fitur yang melibatkan multiple stakeholder
• Fitur yang menyentuh financial transaction
• Requirement yang datang dari non-technical stakeholder

Output dari Interview Yourself:

• Spec draft yang siap untuk formal review
• Interview notes yang mendokumentasikan “mengapa” keputusan diambil
• Input yang lebih akurat untuk estimasi

Kunci keberhasilan: Jawab jujur (termasuk “tidak tahu”), jangan rush, simpan transcript lengkap.

Di artikel berikutnya, kita masuk ke implementasi contract-first API design: OpenAPI Spec dengan Claude — bagaimana mendefinisikan API contract sebelum kode ditulis, dan bagaimana Claude Code bisa menghasilkan kode dari contract tersebut.