Proses Wawancara Stripe, Tahap demi Tahap
Oleh Aaron Cao · Diperbarui

Stripe menjalankan seleksi perekrut, tes teknis praktis, dan onsite virtual dengan empat hingga lima tahap. Tahap coding menggunakan kode sungguhan, bukan soal whiteboard: melakukan debugging pada repository yang belum dikenal dan membangun fitur dengan API sama-sama umum dilaporkan.
Tahap apa saja dalam proses wawancara Stripe?
Anda sudah membaca bahwa wawancara Stripe tidak biasa, dan Anda ingin tahu apa artinya itu untuk persiapan Anda. Bagian ini memetakan tahap-tahap yang umum dilaporkan kandidat, sehingga Anda bisa mengarahkan latihan ke hal yang tepat. Bentuknya tetap stabil meski nama masing-masing tahap bisa berubah.
- Seleksi perekrut. Kecocokan peran, linimasa, kisaran kompensasi, dan tim mana yang akan Anda ikuti.
- Tes telepon teknis. Soal coding praktis di editor bersama yang benar-benar berjalan, bukan pseudocode di dokumen bersama.
- Bug squash. Anda dilempar ke codebase yang belum pernah dilihat dan diminta menemukan serta memperbaiki cacatnya.
- Integrasi atau pembuatan API. Anda membangun fitur kecil yang berfungsi terhadap endpoint yang terdokumentasi.
- Desain sistem atau produk. Biasanya berkaitan dengan pembayaran: idempotensi, retry, pergerakan uang, penanganan kegagalan.
- Percakapan dengan hiring manager dan nilai perusahaan. Motivasi, kolaborasi, dan bagaimana Anda menulis serta mengambil keputusan.
Tidak semua kandidat melalui semua tahap. Tim, level, dan tahun semuanya memengaruhi daftar ini, jadi konfirmasikan jadwal spesifik Anda dengan perekrut, bukan berasumsi dari versi yang Anda baca online. Peta yang lebih luas tentang proses wawancara berbagai perusahaan ada di hub proses wawancara perusahaan.
Mengapa Stripe mewawancarai dengan kode sungguhan?
Format praktis ini adalah proksi yang disengaja untuk pekerjaan sebenarnya. Pekerjaan di bidang pembayaran sebagian besar adalah membaca sistem yang sudah ada, memahami mengapa sebuah request gagal, dan membuat perubahan yang hati-hati tanpa merusak pergerakan uang. Soal membalik binary tree tidak menyampel itu; bug di layanan yang belum dikenal justru menyampelnya.
Konsekuensinya bagi Anda adalah keterampilan yang dinilai pun bergeser. Kecepatan membaca menjadi penting. Begitu pula penggunaan tooling yang biasa Anda pakai: menjalankan test, mencetak state sementara, mencari di repository alih-alih menggulirnya. Kandidat yang mencoba bernalar diam-diam melalui kode asing, seperti yang Anda lakukan di whiteboard, biasanya kehabisan waktu.
Menulis muncul di mana-mana karena Stripe berjalan di atas dokumen tertulis. Bersiaplah untuk menjelaskan sebuah tradeoff dalam bentuk prosa, di chat atau ringkasan singkat, dan bersiaplah bahwa penjelasan itu dibaca sebagai bagian dari penilaian Anda, bukan sekadar formalitas.
Bagaimana cara mempersiapkan tahap-tahap praktis?
Latih formatnya, bukan hanya topiknya. Bug squash dan tahap integrasi sama-sama menghargai kebiasaan yang hanya bisa Anda bangun dengan berlatih di bawah batasan yang sama.
- Bekerja di repository sungguhan dengan pengatur waktu. Clone proyek open source yang belum Anda kenal, pilih satu issue yang tercatat, dan perbaiki dalam 45 menit.
- Narasikan pencarian Anda. Katakan apa yang Anda grep dan apa yang Anda harapkan ditemukan. Pewawancara menilai nalar yang bisa mereka dengar.
- Baca dokumentasi API tanpa persiapan. Bangun klien kecil terhadap sesuatu yang belum pernah Anda pakai, dengan dokumentasi sebagai satu-satunya referensi.
- Latih jalur kegagalan. Untuk jawaban desain apa pun, siapkan jawaban soal retry, request duplikat, dan kegagalan sebagian sebelum ditanyakan.
- Tuliskan nalar Anda. Setelah setiap sesi latihan, ringkas perubahan tersebut dalam lima kalimat.
Seorang backend engineer dengan lima tahun pengalaman di bidang pembayaran mempersiapkan diri untuk proses wawancara Stripe dengan menggarap soal algoritma selama tiga minggu, lalu gagal di bug squash karena ia belum pernah menavigasi layanan asing di bawah tekanan waktu. Solusinya bukan lebih banyak algoritma; solusinya adalah sepuluh sesi berwaktu di repository yang bukan ia yang menulis. Jika Anda ingin tahap perilaku dan desain dilatih dengan diucapkan lantang lengkap dengan pertanyaan lanjutan, mode latihan mock interview menjalankan drilling itu.
Di mana bantuan AI cocok, dan di mana tidak
Persiapan tidak diperdebatkan. Melatih tahap desain dengan diucapkan lantang, menggarap pertanyaan yang biasa ditanyakan hiring manager tentang sebuah proyek, dan meninjau kembali rekaman jawaban Anda sendiri, semuanya adalah cara belajar yang wajar.
Bantuan langsung selama wawancara adalah pertanyaan yang lebih sempit, dan jawaban jujurnya tergantung pada tahapnya. Tahap percakapan lewat panggilan video adalah situasi yang berbeda dari latihan coding di mana Anda membagikan layar Anda di dalam lingkungan yang diawasi proktor. Ketika pewawancara melihat layar Anda, apa pun yang ada di layar itu terlihat, dan tidak ada alat yang mengubah itu. Tahap praktis Stripe sering kali melibatkan persis situasi itu, dan itulah kasus yang perlu direncanakan, bukan janji samar soal ketidakterlihatan.
Aaron Cao, pendiri SubcueAI, membangun produk ini berdasarkan pembagian itu, bukan berdasarkan klaim ketidakterlihatan universal: aplikasi desktop native macOS dan Windows menjaga overlay-nya tetap lokal di perangkat Anda, tidak ada meeting bot yang bergabung ke panggilan, dan tidak ada yang disuntikkan ke halaman meeting. Yang tidak bisa dilakukannya adalah bertahan dari layar yang dibagikan atau perangkat yang dikelola perusahaan. Batasannya dijelaskan di hub detectability.