50 Pertanyaan Interview Developer 2026 Beserta Jawaban Tips dari HRD

Mau interview untuk posisi developer? Artikel ini berisi 50 pertanyaan interview developer yang paling sering ditanyakan di perusahaan Indonesia — dari startup sampai corporate. Lengkap dengan contoh jawaban, tips dari perspektif interviewer, dan red flags yang harus dihindari. Pertanyaan dibagi berdasarkan level (junior, mid, senior) dan tipe (technical, behavioral, system design). Bookmark halaman ini untuk persiapan interview-mu.

Bagian 1: Apa yang Interviewer Sebenarnya Cari

Interview Bukan Ujian

Mindset pertama yang perlu diubah: interview bukan ujian dengan jawaban benar atau salah.

Interview adalah conversation untuk cari tahu apakah kamu dan company cocok — dari kedua sisi. Interviewer tidak cari kandidat yang hafal semua jawaban. Mereka cari kandidat yang bisa think, communicate, dan grow.

Kandidat yang tidak tahu jawaban tapi bisa explain thought process-nya sering lebih impressive daripada yang hafal tapi tidak bisa elaborate.

4 Hal yang Dinilai Interviewer

Setiap pertanyaan interview sebenarnya menilai satu atau lebih dari 4 hal ini:

1. Technical Competence

  • Bisa solve problems, bukan hafal syntax
  • Understand fundamentals, bukan cuma pakai framework
  • Tahu limitations dan kapan perlu minta bantuan
  • Bisa learn hal baru dengan cepat

2. Culture Fit

  • Cara komunikasi cocok dengan tim
  • Values align dengan company
  • Bisa collaborate, bukan lone wolf
  • Attitude yang positive dan constructive

3. Growth Potential

  • Curiosity dan willingness to learn
  • Humble tapi confident
  • Coachable — bisa terima feedback
  • Self-driven improvement

4. Communication Skills

  • Bisa explain technical concepts dengan jelas
  • Listen dan respond appropriately
  • Ask good questions
  • Structured thinking

Perbedaan Interview Startup vs Corporate

Style interview berbeda tergantung tipe company:

AspekStartupCorporate
VibeCasual, conversationalFormal, structured
FocusProblem solving, adaptabilityExpertise, process
InterviewerBisa langsung founder/CTOHR → Tech → Manager → HR
TimelineCepat (1-2 minggu)Lama (3-6 minggu)
Yang dicariOwnership, scrappinessStability, teamwork

Adjust style-mu sesuai tipe company. Research dulu sebelum interview.

Cara Pakai Artikel Ini

Artikel ini panjang karena comprehensive. Ini cara pakainya:

  1. Scan semua pertanyaan untuk familiar dengan scope
  2. Deep dive ke level kamu (junior/mid/senior)
  3. Practice jawab out loud — bukan cuma dibaca di kepala
  4. Prepare stories untuk behavioral questions (STAR method)
  5. Bookmark untuk review sebelum interview day

Setiap pertanyaan punya format:

  • Kenapa ditanya — insight dari sisi interviewer
  • Contoh jawaban — template yang bisa di-adapt
  • Tips — cara maximize nilai
  • Red flag — yang harus dihindari

Let's go! 🚀

Bagian 2: Technical Questions — Junior Level

Pertanyaan untuk junior fokus pada fundamentals dan basic problem solving. Interviewer mau tahu apakah kamu punya foundation yang solid untuk di-develop lebih lanjut.

Q1: "Jelaskan apa itu OOP dan 4 pilarnya"

Kenapa ditanya: Cek pemahaman fundamental programming paradigm. Interviewer tidak mau hafalan textbook — mereka mau tahu kamu benar-benar paham dan bisa apply.

Contoh jawaban:

"OOP atau Object-Oriented Programming adalah paradigma yang mengorganisir code ke dalam objects — yang punya properties (data) dan methods (behavior).

4 pilarnya:

Encapsulation — menyembunyikan internal state, expose hanya via methods. Contoh: class User punya private password, di-access via method authenticate(), bukan langsung baca password.

Inheritance — class bisa mewarisi properties dan methods dari parent class. Contoh: class Admin extends User, dapat semua fitur User plus tambahan admin-specific.

Polymorphism — satu interface, banyak implementasi. Contoh: method calculateShipping() bisa punya implementasi berbeda untuk PhysicalProduct vs DigitalProduct.

Abstraction — hide complexity, tampilkan yang essential. User tidak perlu tahu detail implementasi, cukup tahu cara pakainya.

Di project e-commerce yang saya buat, saya pakai inheritance untuk berbagai tipe Product yang share base class tapi punya behavior berbeda untuk shipping calculation."

Tips:

  • Selalu kasih contoh praktis dari experience kamu
  • Okay untuk bilang "yang paling sering saya pakai adalah X"
  • Connect ke real project kalau bisa

Red flag: Hafal definisi textbook tapi tidak bisa kasih contoh konkret atau explain dengan kata-kata sendiri.

Q2: "Apa perbedaan let, const, dan var di JavaScript?"

Kenapa ditanya: Cek apakah paham language fundamentals atau cuma copy-paste tanpa understanding. Pertanyaan ini juga test attention to detail.

Contoh jawaban:

"Ketiganya untuk declare variable, tapi beda behavior:

var — function-scoped dan di-hoist ke atas function. Bisa di-reassign dan di-redeclare. Ini cara lama dan sebaiknya dihindari karena bisa bikin bugs yang susah di-track.

let — block-scoped (hanya exist di dalam { }). Bisa di-reassign tapi tidak bisa di-redeclare di scope yang sama. Pakai ini kalau value perlu berubah.

const — juga block-scoped, tidak bisa di-reassign reference-nya. Tapi penting: untuk objects dan arrays, isinya masih bisa dimodifikasi — yang const cuma reference-nya.

javascript

const user = { name: 'John' }; user.name = 'Jane'; // Ini valid user = { name: 'Jane' }; // Error: Assignment to constant

Di code saya, saya default pakai const untuk semua variable. Switch ke let hanya kalau memang perlu reassign, seperti counter di loop. Saya tidak pernah pakai var."

Tips:

  • Tunjukkan preference dan reasoning kenapa
  • Mention practical habit di real code
  • Kalau pakai TypeScript, bisa mention itu juga

Red flag: "Sama aja sih, saya biasa pakai var" atau tidak bisa explain perbedaan scoping.

Q3: "Bagaimana cara kerja Git? Jelaskan workflow yang biasa kamu pakai"

Kenapa ditanya: Git adalah tool wajib di semua company. Interviewer mau tahu kamu paham konsepnya, bukan cuma hafal commands.

Contoh jawaban:

"Git adalah distributed version control system — setiap developer punya full copy repository di local, bukan cuma connect ke central server.

Workflow yang saya pakai:

  1. Pull latest dari main atau develop branch
  2. Buat feature branch: git checkout -b feature/nama-fitur
  3. Code dan commit dengan pesan yang descriptive
  4. Push ke remote dan buat Pull Request
  5. Code review dari teammate
  6. Setelah approved, merge ke develop

Untuk commit message, saya ikuti conventional commits format: feat: untuk feature baru, fix: untuk bug fix, refactor: untuk refactoring, docs: untuk dokumentasi.

Contoh: feat: add user authentication with JWT

Kalau ada conflict, saya prefer resolve manual daripada auto-merge — lebih aman untuk pastikan tidak ada code yang hilang atau salah merge. Biasanya saya review conflict satu per satu sambil communicate dengan author code yang conflict."

Tips:

  • Jelaskan workflow yang actually kamu pakai, bukan teori
  • Mention branching strategy: gitflow, trunk-based, atau GitHub flow
  • Tunjukkan awareness tentang collaboration aspect

Red flag: "Saya biasa langsung push ke main" atau tidak pernah pakai branching sama sekali.

Q4: "Apa itu REST API? Jelaskan HTTP methods yang umum dipakai"

Kenapa ditanya: Hampir semua aplikasi modern pakai API untuk komunikasi. Ini fundamental yang wajib dikuasai.

Contoh jawaban:

"REST adalah architectural style untuk membangun API yang menggunakan HTTP methods untuk operasi pada resources.

HTTP methods utama:

GET — mengambil data. Idempotent (berkali-kali hasilnya sama) dan tidak mengubah state server.

POST — create resource baru. Tidak idempotent karena setiap call bisa create data baru.

PUT — update atau replace seluruh resource. Idempotent.

PATCH — update sebagian resource saja.

DELETE — hapus resource. Idempotent.

Contoh untuk resource users:

  • GET /users → list semua users
  • GET /users/123 → get user dengan id 123
  • POST /users → create user baru
  • PUT /users/123 → replace seluruh data user 123
  • PATCH /users/123 → update sebagian data user 123
  • DELETE /users/123 → hapus user 123

Saya juga biasa pakai proper HTTP status codes:

  • 200 OK untuk success
  • 201 Created untuk resource baru berhasil dibuat
  • 400 Bad Request untuk client error
  • 401 Unauthorized, 403 Forbidden untuk auth issues
  • 404 Not Found
  • 500 Internal Server Error untuk server error"

Tips:

  • Jelaskan dengan contoh konkret
  • Mention status codes untuk bonus points
  • Kalau familiar dengan konsep idempotent, jelaskan

Red flag: Pakai POST untuk semua operasi atau tidak tahu perbedaan antar methods.

Q5: "Ceritakan project yang pernah kamu buat. Tech stack apa yang dipakai dan kenapa?"

Kenapa ditanya: Cek real experience dan kemampuan explain technical decisions. Ini juga test apakah kamu benar-benar paham project sendiri atau cuma ikut tutorial.

Contoh jawaban:

"Project terakhir yang saya kerjakan adalah sistem point of sale untuk coffee shop.

Frontend: React dengan TypeScript

  • React karena component-based architecture memudahkan reuse UI
  • TypeScript untuk type safety — catch errors saat development, bukan di production

Backend: Laravel

  • Tim saya familiar dengan Laravel jadi development lebih cepat
  • Eloquent ORM memudahkan database operations
  • Built-in features seperti auth, validation, sudah mature

Database: MySQL

  • Relational database cocok untuk data transaksional
  • Butuh ACID compliance untuk transaksi payment

Deployment: DigitalOcean dengan Docker

  • Cost-effective untuk scale coffee shop
  • Docker untuk consistent environment antara development dan production

Saya handle bagian order management dan reporting. Challenge terbesar adalah handling concurrent orders saat peak hours — saya solve dengan optimistic locking di database untuk prevent race condition saat update stock."

Tips:

  • Pilih project yang paling kamu paham
  • Jelaskan WHY untuk setiap tech choice, bukan cuma WHAT
  • Mention specific challenges dan bagaimana solve-nya

Red flag: Tidak bisa jelaskan kenapa pilih technology tersebut ("ikut tutorial aja" atau "disuruh teman").

Q6: "Apa itu database indexing? Kapan harus dipakai?"

Kenapa ditanya: Database fundamentals penting untuk semua level. Ini cek apakah kamu paham cara optimize query, bukan cuma bisa SELECT.

Contoh jawaban:

"Index adalah data structure yang mempercepat query dengan mengurangi jumlah rows yang perlu di-scan database.

Analoginya seperti index di belakang buku. Kalau mau cari topik 'polymorphism', tidak perlu baca seluruh buku dari halaman 1 — langsung lihat index, dapat nomor halaman, langsung jump.

Kapan pakai index:

  • Kolom yang sering di-WHERE clause
  • Kolom yang sering di-JOIN
  • Kolom yang sering di-ORDER BY
  • Foreign keys

Kapan tidak perlu:

  • Table yang kecil (under 1000 rows)
  • Kolom yang jarang di-query
  • Kolom dengan banyak duplicate values (low cardinality)
  • Table yang lebih banyak write daripada read

Trade-off penting: Index mempercepat read tapi memperlambat write. Setiap INSERT atau UPDATE, index juga perlu di-update. Jadi jangan index semua kolom.

Di project saya, saya add index pada kolom user_id dan created_at di table orders karena sering di-query untuk filter orders by user dan sorting by date."

Tips:

  • Tunjukkan pemahaman trade-off, bukan cuma 'bikin cepat'
  • Kasih contoh dari real experience
  • Mention composite index kalau familiar

Red flag: "Index semua kolom biar cepat" — tidak paham ada trade-off.

Q7: "Bagaimana approach kamu ketika ada error atau bug?"

Kenapa ditanya: Debugging adalah skill harian developer. Interviewer mau lihat systematic approach, bukan random trial-and-error.

Contoh jawaban:

"Saya punya systematic approach untuk debugging:

1. Reproduce the error

  • Pastikan bisa recreate consistently
  • Catat exact steps untuk reproduce

2. Baca error message dengan teliti

  • Sering error message sudah kasih hint yang jelas
  • Cek stack trace untuk lokasi exact error

3. Isolate the problem

  • Comment out code untuk narrow down lokasi
  • Cek apakah issue di frontend, backend, atau database

4. Check recent changes

  • Git diff untuk lihat apa yang berubah
  • Sering bug datang dari perubahan terakhir

5. Strategic logging

  • Tambah console.log atau debugger di points yang suspicious
  • Cek value variables di setiap step

6. Google dengan keyword yang tepat

  • Error message + technology + context
  • Stack Overflow, GitHub issues, official docs

7. Rubber duck debugging

  • Explain problem out loud
  • Sering solution muncul saat kita trying to explain

8. Ask for help

  • Kalau stuck lebih dari 30-60 menit
  • Dengan context: apa yang sudah dicoba

Tools yang saya pakai: browser DevTools, console.log strategically, Laravel Telescope untuk backend, dan debugger breakpoints untuk step-through execution."

Tips:

  • Tunjukkan systematic approach, bukan random
  • Mention specific tools yang kamu pakai
  • Show bahwa kamu tahu kapan harus ask for help

Red flag: "Langsung Google" tanpa attempt untuk understand error-nya dulu.

Q8: "Apa perbedaan synchronous dan asynchronous programming?"

Kenapa ditanya: Konsep ini crucial untuk web development, terutama JavaScript. Banyak junior struggle di sini.

Contoh jawaban:

"Synchronous: Code dieksekusi line by line secara blocking. Line berikutnya harus tunggu line sebelumnya selesai.

Asynchronous: Code tidak blocking. Bisa lanjut ke line berikutnya tanpa tunggu operasi selesai. Hasilnya dihandle nanti via callback, promise, atau async/await.

Analogi sederhana:

  • Sync: Seperti antri di kasir. Harus tunggu orang depan selesai baru giliranmu.
  • Async: Seperti pesan makanan di restoran. Kamu pesan, bisa ngobrol atau ngerjain hal lain, makanan diantar kalau sudah ready.

Di JavaScript, async penting untuk:

  • API calls dengan fetch atau axios
  • File operations
  • Database queries
  • Timer functions (setTimeout, setInterval)

Cara saya handle async:

Callbacks — cara lama, bisa jadi callback hell kalau nested

javascript

getData(function(result) { getMoreData(result, function(newResult) { // callback hell... }); });

Promises — lebih clean dengan .then() dan .catch()

javascript

getData() .then(result => getMoreData(result)) .then(newResult => console.log(newResult)) .catch(error => console.error(error));

Async/await — favorite saya, paling readable

javascript

try { const result = await getData(); const newResult = await getMoreData(result); console.log(newResult); } catch (error) { console.error(error); }

Di project saya, saya pakai Promise.all() untuk parallel API calls — fetch data dari 3 endpoints sekaligus daripada sequential, jadi lebih cepat."

Tips:

  • Kasih analogi yang mudah dipahami
  • Tunjukkan preference (async/await) dan reasoning
  • Mention practical usage seperti Promise.all

Red flag: Tidak bisa jelaskan kenapa async penting untuk web development atau tidak pernah handle async properly.

Q9: "Apa itu responsive design? Bagaimana cara implementasinya?"

Kenapa ditanya: Frontend fundamental. Hampir semua project butuh responsive design untuk berbagai device.

Contoh jawaban:

"Responsive design adalah approach di mana layout dan UI menyesuaikan dengan berbagai screen sizes — dari mobile kecil sampai desktop besar.

Implementasi saya:

1. Mobile-first approach

  • Style untuk mobile dulu sebagai base
  • Tambah breakpoints untuk larger screens
  • Lebih efficient karena mobile biasanya simpler

2. CSS Tools:

  • Media queries: @media (min-width: 768px) { }
  • Flexbox: untuk flexible layouts
  • CSS Grid: untuk complex two-dimensional layouts
  • Relative units: rem, em, %, vh/vw instead of fixed px

3. Framework:

  • Tailwind CSS dengan responsive prefixes: sm:, md:, lg:, xl:
  • Contoh: class='w-full md:w-1/2 lg:w-1/3'

4. Breakpoints yang saya pakai:

  • Mobile: < 640px
  • Tablet: 640px - 1024px
  • Desktop: > 1024px

5. Testing:

  • Chrome DevTools device toolbar
  • Test di real devices juga — emulator tidak selalu akurat

Contoh mobile-first CSS:

css

`/* Base: mobile */ .container { padding: 1rem; flex-direction: column; }

/* Tablet ke atas */ @media (min-width: 768px) { .container { padding: 2rem; flex-direction: row; } }`

Di project terakhir, saya juga implement responsive images dengan srcset untuk serve smaller images di mobile — improve loading performance."

Tips:

  • Mention mobile-first approach
  • Show specific breakpoints dan tools
  • Bonus kalau mention performance considerations

Red flag: Cuma tahu media queries exist tapi tidak punya systematic approach atau tidak paham mobile-first.

Q10: Pertanyaan Live Coding

Contoh soal: "Reverse a string", "Find duplicates in array", "FizzBuzz", "Check palindrome"

Kenapa ditanya: Cek basic problem solving dan coding ability secara real-time. Interviewer juga nilai thought process, bukan cuma final answer.

Framework untuk live coding:

1. Clarify requirements (30 detik)

  • "Apakah harus handle Unicode characters?"
  • "Case-sensitive atau tidak?"
  • "Apa expected input dan output?"

2. Think out loud

  • Jelaskan approach sebelum coding
  • Interviewer mau lihat thought process

3. Start dengan brute force

  • Working solution dulu, meskipun tidak optimal
  • Optimize kemudian jika diminta atau ada waktu

4. Test your code

  • Trace dengan example input
  • Consider edge cases: empty string, null, single element

5. Discuss complexity

  • Time complexity: O(n), O(n²), dll
  • Space complexity

Contoh untuk reverse string:

"Saya akan pakai two-pointer approach — swap karakter dari kedua ujung sampai ketemu di tengah.

javascript

`function reverseString(str) { // Convert ke array karena string immutable di JS const arr = str.split(''); let left = 0; let right = arr.length - 1;

while (left < right) { // Swap [arr[left], arr[right]] = [arr[right], arr[left]]; left++; right--; }

return arr.join(''); }

// Time: O(n), Space: O(n) karena convert ke array`

Alternatif dengan built-in:

javascript

const reverse = str => str.split('').reverse().join('');

Mau saya implement yang mana, atau keduanya?"

Tips:

  • Clarify sebelum coding — ini menunjukkan thoroughness
  • Think out loud — silent coding adalah red flag
  • Okay untuk start simple dan optimize later
  • Test dengan edge cases

Red flag:

  • Langsung coding tanpa clarify requirements
  • Completely silent saat coding
  • Give up tanpa attempt sama sekali
  • Tidak bisa explain code yang sudah ditulis

Bagian 3: Technical Questions — Mid Level

Pertanyaan mid-level fokus pada design decisions, code quality, dan practical experience dengan production systems. Interviewer expect kamu bisa work independently dan make good judgment calls.

Q11: "Jelaskan SOLID principles dan berikan contoh penerapannya"

Kenapa ditanya: Mid-level expected paham software design principles untuk menulis code yang maintainable.

Contoh jawaban:

"SOLID adalah 5 principles untuk menulis OOP code yang maintainable dan scalable:

S — Single Responsibility Principle Satu class satu tanggung jawab. Jangan bikin class yang do everything.

php

`// Bad: UserService handle semuanya class UserService { createUser() {} sendEmail() {} generateReport() {} }

// Good: Pisah tanggung jawab class UserService { createUser() {} } class EmailService { sendEmail() {} } class ReportService { generateReport() {} }`

O — Open/Closed Principle Open for extension, closed for modification. Tambah behavior via extension, bukan edit existing code.

L — Liskov Substitution Principle Subclass harus bisa replace parent tanpa break functionality. Kalau Bird punya fly(), jangan bikin Penguin extends Bird karena penguin tidak bisa fly.

I — Interface Segregation Principle Better banyak interface kecil daripada satu interface besar. Client tidak harus implement methods yang tidak dipakai.

D — Dependency Inversion Principle Depend on abstractions, bukan concrete implementations. Inject dependencies, jangan instantiate di dalam class.

php

`// Bad: tightly coupled class OrderService { public function process() { $payment = new StripePayment(); // Hardcoded $payment->charge(); } }

// Good: dependency injection class OrderService { public function __construct( private PaymentInterface $payment ) {}

public function process() { $this->payment->charge(); } }`

Yang paling sering saya apply: Single Responsibility dan Dependency Injection. Dua ini alone sudah significantly improve code maintainability dan testability."

Tips:

  • Tidak perlu hafal semua — focus yang sering dipakai
  • Selalu kasih code example
  • Okay untuk bilang "yang ini jarang saya pakai karena..."

Red flag: Hafal akronim tapi tidak bisa kasih contoh praktis.

Q12: "Bagaimana kamu handle authentication dan authorization?"

Kenapa ditanya: Security adalah tanggung jawab mid-level. Bukan cuma implement, tapi juga paham security implications.

Contoh jawaban:

"Dua konsep berbeda:

  • Authentication: Verify siapa user-nya (identity)
  • Authorization: Verify apa yang boleh dilakukan user (permissions)

Authentication approaches:

Session-based — untuk traditional web apps

  • Server store session, client store session ID di cookie
  • Stateful, perlu session storage

JWT (JSON Web Token) — untuk SPA dan API

  • Stateless, token contains user info
  • Perlu handle token storage dengan aman

OAuth — untuk third-party login

  • Google, GitHub, Facebook login
  • User tidak perlu create password baru

Security practices yang saya terapkan:

  • Hash passwords dengan bcrypt — never store plaintext
  • HTTPS everywhere — encrypt data in transit
  • HttpOnly cookies untuk tokens di web — prevent XSS access
  • Short expiry untuk access token (15-30 min)
  • Longer expiry untuk refresh token (7-30 days)
  • Rate limiting untuk prevent brute force
  • Input validation dan sanitization

Authorization patterns:

RBAC (Role-Based Access Control)

  • User punya role (admin, editor, viewer)
  • Role punya permissions

Policy-based

  • Untuk complex rules: "user hanya bisa edit post sendiri"

php

// Laravel policy example public function update(User $user, Post $post) { return $user->id === $post->user_id; }

Di project terakhir, saya implement JWT dengan refresh token rotation — setiap kali refresh, old refresh token langsung invalidated. Ini protect against token theft."

Tips:

  • Tunjukkan pemahaman security, bukan cuma implementation
  • Mention specific practices yang kamu apply
  • Show awareness of common vulnerabilities (XSS, CSRF)

Red flag: "Saya pakai JWT" tanpa bisa explain security considerations.

Q13: "Ceritakan pengalaman debugging production issue"

Kenapa ditanya: Mid-level harus bisa handle production problems dengan calm dan systematic.

Contoh jawaban:

"Pernah ada incident di project e-commerce — checkout tiba-tiba gagal untuk beberapa users. Error rate naik dari 0.1% ke 5% dalam 30 menit.

Step yang saya ambil:

1. Check monitoring dan logs

  • Buka dashboard monitoring, lihat metrics
  • Error: 'Connection timeout to payment gateway'
  • Pattern: hanya affect transaksi dengan amount tertentu

2. Identify pattern

  • Semua yang fail adalah transaksi > 1 juta
  • Mulai terjadi setelah deploy jam 2 siang

3. Check recent changes

  • Git log: ada perubahan di payment service
  • Found it: timeout setting accidentally di-reduce dari 30s ke 5s
  • Transaksi besar butuh waktu lebih lama di payment gateway

4. Hotfix

  • Revert timeout config ke 30s
  • Deploy dengan fast-track (skip full CI untuk emergency)
  • Monitor error rate

5. Verify fix

  • Error rate turun ke normal dalam 15 menit
  • Manual test beberapa transaksi besar — success

6. Post-mortem

  • Document root cause dan timeline
  • Add unit test untuk timeout configuration
  • Add alert kalau timeout config berubah
  • Review: kenapa config change lolos code review?

Total resolution time: 2 jam dari alert sampai verified fix.

Lesson learned: always have rollback plan, monitor closely after deploy, dan small config changes bisa punya big impact."

Tips:

  • Use specific example dengan timeline dan details
  • Show systematic approach, bukan panic
  • Mention what you learned dan preventive measures

Red flag: Tidak punya production experience atau cerita tentang panic tanpa structured approach.

Q14: "Bagaimana approach kamu untuk code review?"

Kenapa ditanya: Mid-level expected memberikan dan menerima quality code reviews.

Contoh jawaban:

"Code review punya 2 goals: catch issues early dan knowledge sharing antar tim.

Saat review code orang lain:

1. Understand context dulu

  • Baca PR description dan linked ticket
  • Pahami apa yang mau dicapai sebelum lihat code

2. Check functionality

  • Apakah solve the problem stated?
  • Ada edge cases yang terlewat?
  • Logic sudah benar?

3. Code quality

  • Readability: bisa dipahami tanpa penjelasan?
  • Naming: descriptive dan consistent?
  • DRY: ada duplication yang bisa di-extract?
  • Complexity: bisa disimplify?

4. Tests

  • Ada test untuk happy path?
  • Ada test untuk edge cases?
  • Tests meaningful atau cuma untuk coverage?

5. Tone saat comment

  • Constructive, bukan kritik personal
  • Offer suggestions: 'What if we...' bukan 'This is wrong'
  • Acknowledge good parts juga, bukan cuma yang salah

Saat menerima review:

  • Ego aside — feedback untuk improve code, bukan attack personal
  • Respond to all comments
  • Kalau tidak setuju, explain reasoning dengan baik
  • Thank reviewer for their time

Red flags yang saya perhatikan saat review:

  • PR terlalu besar (> 400 lines) — minta di-split
  • No tests untuk logic baru
  • Console.log yang ketinggalan
  • Hardcoded values yang seharusnya config
  • SQL queries di loop (N+1 problem)"

Tips:

  • Show both giving dan receiving perspective
  • Mention specific things you look for
  • Tunjukkan constructive approach

Red flag: "Saya cuma approve kalau sudah jalan" — tidak thorough.

Q15: "Apa itu database transaction? Kapan perlu dipakai?"

Kenapa ditanya: Data integrity adalah tanggung jawab mid-level. Ini test pemahaman tentang konsistensi data.

Contoh jawaban:

"Transaction adalah sekelompok operasi database yang dieksekusi sebagai satu unit atomic — either all succeed atau all rollback. Tidak ada state setengah-setengah.

ACID Properties:

  • Atomicity: Semua operasi succeed, atau tidak ada yang succeed
  • Consistency: Data tetap valid setelah transaction
  • Isolation: Transactions tidak interfere satu sama lain
  • Durability: Committed data akan persist even if system crash

Kapan pakai transaction:

  1. Transfer uang
    • Debit dari account A DAN credit ke account B harus atomic
    • Tidak boleh uang hilang di tengah
  2. E-commerce checkout
    • Create order, create order items, decrease stock
    • Semua harus success atau semua rollback
  3. Batch operations
    • Import data yang harus complete semua atau none

php

`// Laravel example DB::transaction(function () use ($order, $items) { $order->save();

foreach ($items as $item) {
    OrderItem::create([
        'order_id' => $order->id,
        'product_id' => $item['product_id'],
        'quantity' => $item['quantity'],
        'price' => $item['price'],
    ]);
    
    Product::where('id', $item['product_id'])
        ->decrement('stock', $item['quantity']);
}

}); // Kalau ada error di mana pun, semua di-rollback`

Important considerations:

  • Keep transactions short untuk avoid long locks
  • Jangan taruh external API call di dalam transaction — kalau API slow, database locked lama
  • Understand isolation levels untuk handle concurrent access"

Tips:

  • Explain dengan real use case
  • Show code example
  • Mention practical considerations

Red flag: Tidak tahu kapan perlu transaction atau tidak pernah pakai sama sekali.

Q16: "Bagaimana kamu ensure code quality di project?"

Kenapa ditanya: Mid-level expected maintain dan improve quality standards.

Contoh jawaban:

"Code quality adalah kombinasi automated tools dan manual practices:

Automated checks:

  • Linting: ESLint untuk JS, PHP CS Fixer untuk PHP
    • Enforce consistent code style
    • Catch common mistakes
  • Type checking: TypeScript, PHPStan
    • Catch type errors at development time
  • Unit tests: Jest, PHPUnit
    • Verify logic works as expected
    • Catch regressions
  • Integration tests
    • Verify components work together
  • CI/CD pipeline
    • Run all checks automatically sebelum merge
    • Block merge kalau checks fail

Manual practices:

  • Code review: Setiap PR harus di-review minimal 1 orang
  • Documentation: README, inline comments untuk complex logic
  • Consistent naming conventions: Agree di tim dan enforce

Metrics yang saya track:

  • Test coverage: aim 80%+ untuk critical paths
  • Cyclomatic complexity: flag methods > 10
  • PR size: keep under 400 lines

Setup di team saya:

Pre-commit hooks → Lint & type check PR created → CI runs all tests Review required → Minimal 1 approval CI must pass → Tests, lint, build Merge → Auto-deploy ke staging

Ini catch most issues before production. Yang lolos biasanya edge cases yang memang tidak ter-cover."

Tips:

  • Show comprehensive approach: automated + manual
  • Mention specific tools
  • Show awareness of metrics

Red flag: "Saya test manual aja" tanpa any automated checks.

Q17: "Explain caching dan strategi yang kamu pakai"

Kenapa ditanya: Performance optimization adalah mid-level skill. Caching adalah salah satu technique paling impactful.

Contoh jawaban:

"Caching adalah menyimpan data yang sering diakses di storage yang lebih cepat untuk reduce load dan improve response time.

Levels of caching:

1. Browser cache

  • Static assets: CSS, JS, images
  • Control dengan Cache-Control headers
  • Reduce network requests

2. CDN cache

  • Static files di edge servers worldwide
  • Reduce latency untuk users di berbagai lokasi

3. Application cache

  • Redis atau Memcached
  • Computed data, session storage, API responses

4. Database cache

  • Query cache
  • Buffer pool untuk frequently accessed data

Caching strategy yang saya pakai:

Cache-aside pattern:

php

`function getUser($id) { // 1. Check cache $cached = Cache::get("user:{$id}"); if ($cached) return $cached;

// 2. If miss, fetch from DB
$user = User::find($id);

// 3. Store in cache with TTL
Cache::put("user:{$id}", $user, 3600); // 1 hour

// 4. Return
return $user;

}`

Invalidation strategies:

  • TTL (Time-To-Live): Expire after certain time
  • Event-based: Invalidate when data changes
  • Cache key versioning: Bump version to invalidate all

php

// Event-based invalidation public function updateProfile($data) { $this->user->update($data); Cache::forget("user:{$this->user->id}"); // Invalidate }

Trade-offs to consider:

  • Cache hit rate vs data freshness
  • Memory usage vs performance gain
  • Added complexity vs benefit

Di project saya, user profile jarang berubah tapi sering di-access. Saya cache dengan TTL 1 jam dan invalidate on profile update. Hit rate sekitar 95%."

Tips:

  • Show understanding of different cache levels
  • Explain invalidation — ini yang sering dilupakan
  • Give practical example dengan numbers kalau ada

Red flag: "Cache everything" tanpa consider invalidation atau when to NOT cache.

Bagian 4: Technical Questions — Senior Level (5 Pertanyaan)

Senior developer expected bisa design systems, make strategic decisions, dan mentor tim. Pertanyaan di level ini lebih tentang judgment dan impact, bukan sekadar coding.

Q18: "Design sistem URL shortener seperti bit.ly"

Kenapa ditanya: Senior expected bisa design systems end-to-end dan discuss trade-offs.

Framework jawaban:

`1. CLARIFY (2-3 menit)

  • Scale: berapa URLs per day?
  • Features: analytics? expiry? custom URLs?
  1. HIGH-LEVEL DESIGN (5 menit)
    • Components: API server, database, cache
    • Flow: shorten (write), redirect (read)
  2. DEEP DIVE (10 menit)
    • URL generation strategy
    • Database schema
    • Caching layer
    • Scaling considerations`

Contoh jawaban:

"Sebelum design, saya mau clarify dulu: berapa URLs per hari yang expected? Perlu analytics tracking? Support custom short URLs?

Assuming 100M URLs/day dengan high read ratio (100:1 read vs write):

Components:

  • API Gateway untuk rate limiting
  • Shortening Service untuk generate short URL
  • Redirect Service untuk lookup dan redirect
  • Database untuk store mappings
  • Cache layer untuk hot URLs

URL Generation: Saya prefer counter-based dengan base62 encoding. Pakai distributed ID generator seperti Snowflake untuk uniqueness. Ini avoid collision yang jadi masalah di hash-based approach.

Database: PostgreSQL untuk durability, dengan Redis cache di depan. 90% traffic biasanya ke 10% URLs, jadi caching sangat effective.

Scaling: Read-heavy system, jadi focus pada database replicas dan aggressive caching. Shard by short URL hash untuk distribute writes."

Tips:

  • Selalu clarify requirements dulu — ini yang interviewer mau lihat
  • Think out loud, explain reasoning
  • Discuss trade-offs explicitly
  • Tidak ada jawaban perfect — yang dinilai adalah thought process

Red flag: Langsung jump ke solution tanpa clarify requirements.

Q19: "Bagaimana kamu approach technical debt?"

Kenapa ditanya: Senior harus bisa balance delivery dengan long-term code health.

Contoh jawaban:

"Technical debt adalah shortcuts yang mempercepat sekarang tapi akan slow down kemudian. Tidak semua debt buruk — kadang strategic debt acceptable untuk meet deadline.

Cara saya identify debt:

  • Code yang sering butuh bug fixes
  • Areas yang developers takut touch
  • Features yang take longer than expected
  • Outdated dependencies

Prioritization framework: Saya plot di matrix Impact × Effort:

  • High impact, low effort → do first
  • High impact, high effort → plan carefully
  • Low impact → maybe never fix, and that's okay

Approach:

  • Boy Scout Rule: leave code better than you found it
  • Allocate 15-20% sprint capacity untuk debt
  • Refactor incrementally, bukan big bang rewrite
  • Document debt dengan ADRs

Communication: Yang penting adalah make debt visible ke stakeholders. Saya explain dalam business terms — 'kalau tidak fix ini, feature X akan take 2x longer'.

Contoh: di project terakhir, ada monolith yang pain point. Daripada rewrite, kami extract services satu per satu — iterative approach dengan measurable impact setiap milestone."

Tips:

  • Show strategic thinking, bukan cuma coding mindset
  • Demonstrate communication dengan non-technical stakeholders
  • Give specific example dari experience

Red flag: "Technical debt harus selalu dibayar" (tidak pragmatic).

Q20: "Ceritakan saat kamu harus make technical decision yang unpopular"

Kenapa ditanya: Senior perlu influence dan stand by difficult decisions.

Contoh jawaban:

"Tim saya mau adopt microservices karena 'industry best practice'. Saya push back.

Context: Team 5 orang, product masih early stage, belum product-market fit.

My assessment:

  • Microservices punya overhead signifikan: deployment, monitoring, debugging
  • Team terlalu kecil untuk manage distributed system properly
  • Premature optimization — belum tahu di mana bottleneck sebenarnya

Approach saya:

  1. Listen dulu — understand kenapa team excited tentang microservices
  2. Acknowledge benefits yang mereka sebut
  3. Present data tentang overhead dan team capacity
  4. Propose alternative: modular monolith sekarang, extract ke microservices kalau hit specific triggers (misal: team grow ke 15+, atau specific service jadi bottleneck)

Pushback yang saya dapat: 'Nanti susah migrate', 'Interview candidate expect microservices'.

Response saya: 'Modular monolith designed for extraction — boundaries sudah jelas. Dan better hire people yang optimize untuk problem, bukan hype.'

Result: Kita go dengan modular monolith. 2 tahun kemudian, masih belum perlu microservices dan velocity tetap tinggi. Tim eventually setuju itu keputusan yang tepat."

Tips:

  • Show empathy — kamu listen sebelum push back
  • Back up dengan data dan reasoning
  • Propose alternatives, bukan cuma say no
  • Share outcome

Red flag: Push decision tanpa listen ke team atau tidak bisa articulate reasoning.

Q21: "Bagaimana kamu mentor junior developers?"

Kenapa ditanya: Senior expected multiply team capability, bukan cuma individual contribution.

Contoh jawaban:

"Goal mentoring saya: junior jadi independent faster, bukan dependent pada saya.

Approach:

  1. Set context, bukan kasih answers
    • Daripada langsung kasih solusi, saya explain context dan let them find solution
    • 'Ini constraint-nya, apa options yang kamu lihat?'
  2. Scheduled pair programming
    • Bukan ad-hoc, tapi scheduled regular sessions
    • Saya yang drive dulu untuk demonstrate, lalu swap
    • Think out loud saat coding
  3. Code review sebagai teaching moment
    • Explain WHY, bukan cuma 'change this'
    • Link ke resources untuk deeper learning
    • Highlight apa yang sudah bagus, bukan cuma yang salah
  4. Safe to fail environment
    • Kasih tasks yang stretch tapi recoverable
    • Celebrate learning dari mistakes
  5. Gradually increase scope
    • Task → Feature → Small project → Lead initiative

Measuring success:

  • Apakah mereka bisa explain decisions ke orang lain?
  • Apakah pertanyaan mereka makin sophisticated?
  • Apakah PR quality improving?

Example: Junior di team saya awalnya stuck di simple tasks. Setelah 6 bulan mentoring dengan approach ini, dia bisa lead feature end-to-end. Sekarang dia mentor intern baru — that's the multiplier effect."

Tips:

  • Emphasize enabling independence, bukan creating dependency
  • Give concrete techniques
  • Show measurable outcomes

Red flag: "Saya kasih jawaban langsung biar cepat" (tidak develop people).

Q22: "Apa biggest mistake kamu sebagai developer dan apa yang dipelajari?"

Kenapa ditanya: Senior expected punya self-awareness dan genuine learning dari experience.

Contoh jawaban:

"Early career, saya push untuk rewrite legacy system from scratch. Complete rewrite, new tech stack, new architecture.

Apa yang terjadi:

  • Project took 2x longer than estimated
  • New system punya bugs yang sudah solved di old system — years of edge case handling hilang
  • Business features blocked selama rewrite
  • Team morale drop karena never-ending project

Root cause mistakes saya:

  1. Underestimate complexity yang hidden di legacy code
  2. Tidak appreciate years of bug fixes dan edge case handling
  3. Big bang approach vs incremental
  4. Terlalu focus pada technical 'cleanliness', kurang focus pada business value

What I learned:

  • Strangler pattern: replace incrementally, bukan rewrite total
  • Working software > clean architecture
  • Business value > technical idealism
  • Complexity sering invisible sampai kamu dig in

Sekarang approach saya:

  • Default ke incremental improvement
  • Rewrite hanya kalau ada very strong justification dengan clear milestones
  • Involve team dalam assessment
  • Set measurable business value di setiap milestone

Mistake ini expensive, tapi lesson-nya shape how I approach every technical decision sekarang."

Tips:

  • Choose real mistake dengan real consequences — authenticity penting
  • Show genuine reflection dan learning
  • Connect ke how you work differently now

Red flag: "Saya tidak pernah buat mistake besar" — ini tidak credible dan menunjukkan kurang self-awareness.

Bagian 5: Behavioral Questions (15 Pertanyaan)

Behavioral questions menilai soft skills dan past behavior. Interviewer percaya: past behavior predicts future behavior.

STAR Method Framework

Gunakan STAR method untuk structure jawaban:

`S - SITUATION Context dan background. Set the scene.

T - TASK Apa tanggung jawab kamu specifically. Focus pada YOUR role, bukan team.

A - ACTION Apa yang kamu lakukan. Detail steps. Ini bagian terpenting — be specific.

R - RESULT Outcome. Quantify kalau bisa. Include learnings, bukan cuma success.`

Pro tip: Prepare 5-7 stories yang bisa di-adapt untuk berbagai questions. Satu story bisa answer multiple questions dengan different framing.

Teamwork & Collaboration

Q23: "Ceritakan pengalaman kerja dalam team yang challenging"

Kenapa ditanya: Hampir semua pekerjaan butuh collaboration. Interviewer mau lihat bagaimana kamu navigate difficulty.

Contoh jawaban (STAR):

"Situation: Di project e-commerce, ada conflict antara saya sebagai backend developer dengan frontend developer tentang API contract. Dia mau response format yang flexible, saya concern tentang performance dan consistency.

Task: Saya perlu deliver API yang frontend butuhkan sambil maintain backend standards dan performance.

Action:

  1. Setup dedicated meeting untuk understand frontend needs — bukan via Slack yang sering miscommunication
  2. Document both perspectives secara objective
  3. Propose compromise: GraphQL untuk flexibility yang dia butuhkan, dengan query complexity limits untuk performance
  4. Create shared API contract dengan OpenAPI spec sebagai source of truth
  5. Setup weekly sync untuk prevent future misalignment

Result: API delivered on time. Conflict resolution approach ini diadopt sebagai team standard untuk cross-team collaboration. Relationship dengan frontend dev significantly improved — sekarang kami sering pair untuk design API baru."

Tips:

  • Pilih conflict yang resolved positively
  • Show YOUR role dalam resolution
  • Focus pada collaboration dan learning, bukan blame

Red flag: Blame teammate atau show bahwa conflict tidak resolved.

Q24: "Bagaimana kamu handle disagreement dengan teammate?"

Kenapa ditanya: Disagreement pasti terjadi. Yang penting adalah HOW kamu handle.

Contoh jawaban:

"Approach saya untuk disagreement:

  1. Assume positive intent — teammate punya reasoning, mungkin saya yang belum understand
  2. Seek to understand first — tanya 'help me understand why you think X'
  3. Separate ego dari ide — ini bukan personal, ini tentang finding best solution
  4. Data over opinions — kalau bisa, test both approaches
  5. Disagree and commit — kalau sudah decide, commit fully even if bukan preferensi saya

Contoh konkret: Teammate mau pakai library baru yang saya rasa overkill. Daripada langsung push back, saya tanya reasoning-nya. Ternyata ada use case yang saya tidak consider. Kita evaluate together dengan pros/cons list, dan eventually decide pakai library tersebut untuk specific module saja. Both perspectives contributed ke better solution."

Tips:

  • Show maturity dan objectivity
  • Give specific example
  • Mention "disagree and commit" — ini valued di banyak company

Q25: "Ceritakan saat kamu harus work dengan someone yang difficult"

Kenapa ditanya: Kamu akan ketemu berbagai personality. Interviewer mau lihat adaptability.

Contoh jawaban:

"Situation: Ada senior developer yang dikenal 'difficult' — sering dismiss ide orang lain, komunikasi blunt.

Task: Saya harus collaborate dengan dia untuk critical feature.

Action:

  1. Observe dulu — understand communication style-nya
  2. Adapt approach: dia prefer written communication dengan data, bukan verbal brainstorming
  3. Come prepared dengan research sebelum discussions
  4. Acknowledge expertise-nya genuinely — dia defensive kalau merasa tidak respected
  5. Pick battles — tidak semua hill worth dying on

Result: Feature delivered successfully. Relationship improved ke titik dia specifically request collaborate dengan saya untuk next project. Learned bahwa 'difficult' sering berarti 'different communication style'."

Tips:

  • Jangan badmouth orang tersebut
  • Show adaptability dan empathy
  • Focus pada what YOU did differently

Red flag: "Saya avoid dia" atau extensive complaining.

Q26: "Bagaimana kamu communicate technical concepts ke non-technical stakeholders?"

Kenapa ditanya: Developer perlu communicate dengan PM, designer, business people.

Contoh jawaban:

"Prinsip saya: meet them where they are, bukan expect mereka understand technical jargon.

Techniques:

  1. Analogi — relate ke concepts yang mereka familiar
  2. Focus on impact — bukan technical detail, tapi 'what it means for users/business'
  3. Visual aids — diagram simple beats paragraphs of explanation
  4. Avoid jargon — atau define it jika harus pakai
  5. Check understanding — 'does that make sense?' dan genuinely listen

Contoh: Perlu explain kenapa migration akan cause downtime ke business stakeholders.

Daripada: 'Kita perlu alter table schema dan rebuild indexes yang akan lock tables...'

Saya bilang: 'Bayangkan kita pindahan rumah. Selama pindahan, ada waktu di mana barang sudah dipak tapi belum sampai rumah baru. Users akan experience ini selama 2 jam. Kita schedule di jam 2-4 pagi ketika traffic paling rendah, so impact minimal.'

Mereka langsung understand dan approve."

Tips:

  • Give specific example dengan before/after
  • Show empathy untuk audience
  • Mention checking for understanding

Q27: "Ceritakan pengalaman collaborate dengan remote team"

Kenapa ditanya: Remote/hybrid work makin common. Communication skills berbeda.

Contoh jawaban:

"Saya pernah di team dengan members di 3 timezone: Jakarta, Singapore, dan US.

Challenges:

  • Meeting time yang works untuk semua sangat limited
  • Async communication harus sangat clear
  • Context sering hilang di text

Approach saya:

  1. Over-communicate in writing — document decisions, bukan cuma discuss
  2. Timezone-aware scheduling — rotate meeting times agar tidak selalu orang yang sama yang sacrifice
  3. Video untuk complex discussions — text untuk updates, video untuk brainstorming
  4. Clear ownership — siapa responsible untuk apa, deadline kapan
  5. Async-first mindset — tidak expect instant response

Tools yang helpful:

  • Notion untuk documentation
  • Loom untuk async video updates
  • Slack dengan clear channel structure

Result: Successfully shipped major feature dengan team yang tidak pernah ketemu physically. Key learning: explicit communication beats implicit assumption di remote setting."

Problem Solving & Challenges

Q28: "Ceritakan problem tersulit yang pernah kamu solve"

Kenapa ditanya: Melihat problem-solving approach dan persistence.

Contoh jawaban (STAR):

"Situation: Production system tiba-tiba slow. Response time naik dari 200ms ke 5 detik. Ini affect checkout flow dan revenue visibly dropping.

Task: Sebagai developer on-call, saya responsible untuk identify dan fix ASAP.

Action:

  1. Check monitoring — Datadog showed database CPU spiking
  2. Analyze slow query log — found one query doing full table scan
  3. Trace ke source — query dari feature yang baru deploy
  4. Identify root cause — migration script didn't create index properly
  5. Hotfix — manually add index, verify performance restored
  6. Prevent future — add CI check untuk migration validation

Result: Resolved dalam 2 jam dengan minimal revenue impact. Added safeguards yang prevent 3 similar issues dalam 6 bulan berikutnya. Presented post-mortem ke team."

Tips:

  • Choose problem dengan real impact
  • Show systematic approach, bukan random guessing
  • Mention prevention untuk future

Q29: "Bagaimana approach kamu saat stuck di problem?"

Kenapa ditanya: Everyone gets stuck. Yang penting adalah productive response.

Contoh jawaban:

"Saya punya systematic approach:

  1. Time-box frustration — 30 menit struggle sendiri maximum
  2. Rubber duck debugging — explain problem out loud, sering solution muncul
  3. Break down problem — isolate mana yang works, mana yang tidak
  4. Fresh perspective — take break, walk, atau switch task sebentar
  5. Research — Google dengan specific keywords, check Stack Overflow, documentation
  6. Ask for help — dengan context: 'I tried X, Y, Z, still stuck on...'

Yang penting: asking for help bukan weakness. Stuck for hours tanpa progress adalah worse than asking setelah 30 menit genuine effort.

Contoh: Stuck di weird bug selama 2 jam. Take break, makan siang. Balik ke desk, solve dalam 10 menit. Kadang fresh eyes adalah yang dibutuhkan."

Q30: "Ceritakan saat kamu harus learn technology baru dengan cepat"

Kenapa ditanya: Tech landscape berubah terus. Learning agility penting.

Contoh jawaban:

"Situation: Project mendadak butuh React Native, tapi experience saya mostly web React. Timeline: 3 minggu.

Task: Deliver functioning mobile app feature dengan technology yang baru saya pelajari.

Action:

  1. Identify gaps — apa yang sama dengan web React, apa yang berbeda
  2. Focused learning — bukan general tutorial, tapi specific ke feature yang perlu dibuild
  3. Build immediately — learn by doing, bukan passive watching
  4. Find internal expert — ada satu orang di company yang pernah pakai, setup 1-on-1 sessions
  5. Accept 'good enough' — tidak perlu jadi expert, perlu jadi productive

Result: Feature delivered on time. Bukan code terbagus, tapi works dan maintainable. Kemudian refactor dengan knowledge yang lebih mature."

Tips:

  • Show learning strategy, bukan cuma "saya belajar"
  • Mention seeking help dari others
  • Honest bahwa first attempt bukan perfect — that's realistic

Q31: "Bagaimana kamu prioritize ketika semua terasa urgent?"

Kenapa ditanya: Prioritization adalah critical skill, terutama di startup.

Contoh jawaban:

"Step saya:

  1. List everything — brain dump semua yang competing untuk attention
  2. Clarify actual urgency — tanya 'what happens if this waits until tomorrow/next week?'
  3. Identify dependencies — apa yang blocking orang lain?
  4. Eisenhower matrix — urgent+important first, important tapi not urgent schedule
  5. Communicate — kalau tidak bisa semua, be upfront tentang trade-offs
  6. One thing at a time — multitasking adalah myth untuk deep work

Contoh: Pernah ada hari di mana: production bug, deadline feature, dan meeting dengan stakeholder semua di hari yang sama.

Assessment saya:

  • Production bug: affect users NOW → first priority
  • Stakeholder meeting: sudah scheduled, cannot move → attend
  • Feature deadline: discuss dengan PM, bisa extend 1 hari? Yes → moved

Komunikasi yang clear ke semua parties bikin expectations aligned."

Q32: "Ceritakan saat project tidak go as planned"

Kenapa ditanya: Plans selalu berubah. Interviewer mau lihat adaptability.

Contoh jawaban:

"Situation: Sprint planned untuk 3 features, tapi mid-sprint ada critical security vulnerability yang harus di-patch.

Task: Balance security fix dengan committed features.

Action:

  1. Assess impact — security fix estimated 2 hari, 40% of sprint capacity
  2. Communicate immediately — inform PM dan stakeholders about situation
  3. Re-prioritize together — dengan PM, decide feature mana yang bisa defer
  4. Adjust scope — 1 feature moved to next sprint, 2 features dengan reduced scope
  5. Transparent updates — daily update ke stakeholders tentang progress
  6. Retrospective — discuss apa yang bisa improve untuk handle unplanned work

Result: Security fix done, 2 features shipped dengan adjusted scope, stakeholders informed dan tidak surprised. Added 'buffer' untuk unplanned work di future sprint planning."

Growth & Learning

Q33: "Bagaimana kamu keep up dengan technology changes?"

Kenapa ditanya: Tech berubah cepat. Interviewer mau lihat learning habit.

Contoh jawaban:

"Saya punya routine yang sustainable, bukan cramming:

Daily (30 menit):

  • Tech Twitter/X untuk trending topics
  • Hacker News top 5 stories
  • Skim, bukan deep read

Weekly (2-3 jam):

  • Deep read 1-2 articles relevant ke current work
  • Newsletter: JavaScript Weekly, Laravel News, dll

Monthly:

  • Coba 1 new tool/library di side project
  • Watch 1-2 conference talks

Quarterly:

  • Evaluate: apa yang worth deep dive?
  • Take online course kalau ada significant gap

Prinsip saya: Depth before breadth. Lebih valuable untuk deep di relevant tech daripada surface-level di banyak hal.

Saya juga maintain learning log — setiap minggu catat apa yang dipelajari. Ini help retention dan track progress."

Q34: "Apa yang kamu pelajari dalam 6 bulan terakhir?"

Kenapa ditanya: Cek apakah actually learning atau stagnant.

Contoh jawaban:

"Dalam 6 bulan terakhir, focus saya di tiga area:

  1. AI/LLM Integration
    • Learned prompt engineering fundamentals
    • Built internal tool yang pakai Claude API untuk code review suggestions
    • Understand limitations dan when NOT to use AI
  2. System Design
    • Baca 'Designing Data-Intensive Applications'
    • Practice dengan mock system design interviews
    • Applied di actual project: redesign notification system
  3. Leadership Skills
    • Started mentoring 1 junior developer
    • Lead first technical RFC process
    • Learning to influence tanpa authority

Yang paling impactful: AI integration — sudah save team sekitar 5 hours/week untuk routine tasks."

Tips:

  • Be specific dengan concrete examples
  • Show application, bukan cuma consumption
  • Connect ke impact

Q35: "Ceritakan feedback yang pernah kamu terima dan bagaimana kamu act on it"

Kenapa ditanya: Melihat coachability dan self-improvement.

Contoh jawaban:

"Feedback: Manager bilang saya tend to work in silo — solve problems sendiri tanpa involve team, miss opportunities untuk knowledge sharing.

Initial reaction: Honestly, sedikit defensive. Saya pikir itu efisien.

Reflection: Tapi setelah pikir, memang benar. Tim tidak tahu apa yang saya kerjakan, dan saya reinvent solutions yang mungkin sudah ada.

Action:

  1. Start share WIP di daily standup, bukan cuma 'done' items
  2. Write internal blog posts untuk interesting solutions
  3. Before deep dive ke problem, tanya dulu 'has anyone solved this?'
  4. Pair programming lebih sering

Result: 6 bulan kemudian, feedback di review berubah — manager specifically mention improved collaboration. Bonus: saya juga learn dari others yang ternyata punya solutions lebih baik."

Tips:

  • Show genuine reflection, termasuk initial resistance
  • Be specific tentang actions taken
  • Mention measurable improvement

Leadership & Initiative

Q36: "Ceritakan saat kamu take initiative tanpa disuruh"

Kenapa ditanya: Proactive > reactive. Especially valued di startup.

Contoh jawaban:

"Situation: Noticed deploy process manual dan error-prone. Setiap deploy butuh 45 menit dan sering ada human error.

Task: Tidak ada yang assign ini — saya identify sebagai opportunity.

Action:

  1. Document current process dan pain points
  2. Research CI/CD options yang fit dengan stack kita
  3. Build prototype di weekend dengan GitHub Actions
  4. Present ke team dengan demo dan estimated time savings
  5. Setelah approved, implement incrementally

Result: Deploy time dari 45 menit jadi 10 menit. Human errors eliminated. Team adopted dan saya jadi go-to person untuk CI/CD improvements. Later promoted partly karena initiative ini."

Q37: "Bagaimana kamu influence decision tanpa authority?"

Kenapa ditanya: Senior/lead perlu influence tanpa being the boss.

Contoh jawaban:

"Prinsip saya: influence through trust dan data, bukan position.

Techniques:

  1. Build credibility first — deliver consistently sebelum propose big changes
  2. Understand stakeholders — apa concerns dan priorities mereka?
  3. Data over opinions — 'I feel' kurang powerful dari 'data shows'
  4. Find allies — identify siapa yang might support, align dulu
  5. Propose, don't demand — 'What if we try X?' bukan 'We must do X'
  6. Pilot/experiment — 'Can we try for 2 weeks?' lebih acceptable dari permanent change

Contoh: Mau introduce TypeScript ke team yang pakai JavaScript. Daripada propose full migration:

  1. Show data: bugs yang would've been caught dengan types
  2. Find one person yang interested untuk ally
  3. Propose pilot: 1 new module pakai TypeScript
  4. Measure results, share wins
  5. Eventually team mau adopt broader

Took 3 months, tapi sustainable karena team bought in."

Bagian 6: System Design Questions (8 Pertanyaan)

System design interview menilai kemampuan design scalable systems. Biasanya untuk mid-level ke atas, tapi junior juga kadang dapat versi simplified.

Framework untuk System Design

FRAMEWORK (15-20 menit):

1. CLARIFY (2-3 menit)
   ├── Functional requirements: apa yang sistem harus bisa
   ├── Non-functional: scale, latency, availability
   └── Constraints dan assumptions

2. ESTIMATE (2 menit)
   ├── Users dan requests per second
   ├── Storage needs
   └── Bandwidth

3. HIGH-LEVEL DESIGN (5 menit)
   ├── Core components
   ├── Data flow
   └── API design

4. DEEP DIVE (5-8 menit)
   ├── Focus pada 1-2 critical components
   ├── Trade-offs
   └── Scaling considerations

5. WRAP UP (2 menit)
   ├── Bottlenecks dan solutions
   └── Monitoring dan alerting

Q38: "Design Twitter/X timeline"

Focus: Feed generation, caching, fanout strategy

Key considerations:

  • Read-heavy system (users baca lebih banyak dari post)
  • Fanout on write vs fanout on read
  • Celebrity problem (accounts dengan jutaan followers)
  • Real-time vs near real-time

Approach singkat: "Untuk users biasa, saya pakai fanout on write — ketika user post, push ke followers' timeline cache. Tapi untuk celebrities, fanout on read karena terlalu expensive push ke jutaan followers. Hybrid approach: precompute untuk regular users, compute on-demand untuk celebrity follows."

Q39: "Design chat system seperti WhatsApp"

Focus: Real-time messaging, delivery guarantees, presence

Key considerations:

  • WebSocket untuk real-time
  • Message delivery states: sent, delivered, read
  • Offline message queueing
  • Group chat scaling
  • End-to-end encryption

Approach singkat: "WebSocket connections ke chat servers. Messages stored di database dengan delivery status. Untuk offline users, queue messages dan deliver ketika reconnect. Group chat: fan out ke members dengan optimization untuk large groups."

Q40: "Design notification system"

Focus: Multiple channels, queuing, rate limiting

Key considerations:

  • Multiple channels: push, email, SMS, in-app
  • User preferences
  • Rate limiting (jangan spam users)
  • Priority levels
  • Retry dan failure handling

Approach singkat: "Event-driven architecture. Events masuk ke message queue, notification service process dan route ke appropriate channel handlers. Each channel handler manage delivery dan retries. Rate limiter prevent overwhelming users. Priority queue untuk urgent notifications."

Q41: "Design rate limiter"

Focus: Algorithms, distributed implementation

Key considerations:

  • Algorithms: token bucket, sliding window, fixed window
  • Distributed rate limiting across multiple servers
  • Different limits per user/API endpoint
  • Graceful handling saat limit hit

Approach singkat: "Token bucket algorithm untuk flexibility. Store counters di Redis untuk distributed implementation. Key = user_id + endpoint. Return 429 dengan Retry-After header saat limit hit. Different tiers untuk different user levels."

Q42: "Design file storage seperti Google Drive"

Focus: Upload, chunking, sync, sharing

Key considerations:

  • Chunked upload untuk large files
  • Deduplication
  • Sync across devices
  • Sharing dan permissions
  • Versioning

Approach singkat: "Chunk files untuk reliable upload dan deduplication. Metadata di relational DB, actual files di object storage (S3). Sync service track file versions dan push changes to devices. Permission model dengan ACL untuk sharing."

Q43: "Design e-commerce checkout"

Focus: Inventory management, payment processing, consistency

Key considerations:

  • Inventory reservation vs deduction
  • Race conditions (overselling)
  • Payment integration
  • Order state machine
  • Failure handling

Approach singkat: "Reserve inventory saat add to cart (dengan expiry). Checkout: validate stock → process payment → confirm order → deduct inventory. All dalam transaction. Compensating transactions kalau payment fail after inventory deducted. Event-driven untuk post-checkout processing (email, fulfillment)."

Q44: "Design search autocomplete"

Focus: Trie data structure, caching, ranking

Key considerations:

  • Low latency requirement (<100ms)
  • Personalization
  • Trending queries
  • Multi-language support

Approach singkat: "Trie untuk prefix matching, store di memory untuk speed. Cache popular prefixes di CDN. Ranking based on: popularity, recency, personalization. Async update trie dari search logs. Fallback ke simpler search kalau trie unavailable."

Q45: "Design video streaming service"

Focus: Encoding, CDN, adaptive bitrate

Key considerations:

  • Video encoding ke multiple resolutions
  • CDN untuk global delivery
  • Adaptive bitrate streaming
  • Copyright protection (DRM)

Approach singkat: "Upload → encoding pipeline (multiple resolutions/codecs) → store di object storage → distribute via CDN. Player use adaptive bitrate (HLS/DASH) untuk adjust quality based on network. Separate concerns: upload, processing, delivery, playback."

Tips untuk Junior yang Dapat System Design

Kalau kamu junior dan dapat system design question, jangan panik:

  1. Interviewer adjust expectations — mereka tidak expect distributed systems expertise
  2. Focus pada components yang kamu tahu — database, API, basic caching
  3. Be honest — "Di level saya, saya akan approach seperti ini untuk smaller scale..."
  4. Show thought process — yang dinilai adalah bagaimana kamu think, bukan perfect answer
  5. Ask clarifying questions — ini expected dan valued

Contoh response untuk junior:

"Saya belum punya experience design system at scale, tapi ini approach saya untuk scope yang lebih kecil:

  1. Identify core features yang harus ada
  2. Design database schema
  3. Define API endpoints
  4. Add caching untuk frequent queries
  5. Consider failure scenarios

Untuk scaling ke level yang lebih besar, saya tahu konsep-konsep seperti load balancing, database replication, dan message queues, tapi saya butuh learn lebih dalam untuk implementation details."

Bagian 7: Questions untuk Interviewer (5 Pertanyaan)

Interview adalah two-way evaluation. Kamu juga perlu assess apakah company dan role cocok untukmu.

Kenapa Perlu Bertanya

ALASAN BERTANYA:

├── Show genuine interest di company
├── Interview bukan cuma kamu di-evaluate
├── Kamu perlu info untuk make decision
├── Kandidat tanpa questions = red flag
└── Last impression matters

Selalu prepare minimal 3-5 questions. Tanya 2-3 di akhir interview, sisanya untuk follow-up atau interview lain.

Q46: "Apa biggest technical challenge yang team hadapi sekarang?"

Kenapa bagus:

  • Show interest di actual work
  • Gauge complexity of problems
  • Understand what you'll be working on

Follow up: "How is the team approaching it?"

What to listen for:

  • Interesting problems vs boring maintenance
  • Apakah mereka excited atau frustrated
  • Alignment dengan interest kamu

Q47: "Bagaimana engineering culture di sini? Misalnya, bagaimana technical decisions dibuat?"

Kenapa bagus:

  • Reveal decision-making process
  • Understand autonomy vs bureaucracy
  • Culture fit assessment

What to listen for:

  • Collaborative vs top-down
  • Data-driven vs HiPPO (highest paid person's opinion)
  • Innovation vs playing safe

Red flag dari answer: "Keputusan dari atas, kita execute" — kurang autonomy.

Q48: "Apa yang membedakan high performer di role ini?"

Kenapa bagus:

  • Show ambition dan drive
  • Understand success criteria
  • Get insight untuk exceed expectations

What to listen for:

  • Clear expectations atau vague
  • Technical excellence vs soft skills vs impact
  • Realistic atau setting up for failure

Pro tip: Use their answer untuk tailor responses di interview selanjutnya.

Q49: "Bagaimana typical career progression untuk role ini?"

Kenapa bagus:

  • Show long-term thinking
  • Understand growth opportunities
  • Reveal company's investment di people development

What to listen for:

  • Clear path atau "depends"
  • Timeline yang realistic
  • Examples of people yang sudah progress

Red flag: "We're too small for that" atau "Everyone kind of does everything" — might mean no growth path.

Q50: "Apa yang paling kamu enjoy dari kerja di sini?"

Kenapa bagus:

  • Personal question yang build rapport
  • Genuine answer reveal culture
  • Interviewer biasanya suka share

What to listen for:

  • Genuine enthusiasm vs scripted PR answer
  • Specific examples vs generic "great people"
  • Alignment dengan what you value

Questions yang Harus DIHINDARI

JANGAN TANYA:

❌ "Berapa gajinya?"
   → Terlalu early, ada negotiation phase nanti

❌ "Kapan bisa ambil cuti?"
   → Kesan tidak mau kerja

❌ "Apakah ada WFH?"
   → Tanya dengan cara lebih subtle atau research dulu

❌ Hal yang bisa di-Google
   → "Company ini ngapain sih?" = tidak prepare

❌ Nothing at all
   → Biggest red flag — show zero interest

Bagian 8: Red Flags & Green Flags

Dari perspektif interviewer, ada signals yang langsung bikin kandidat ditolak atau di-prioritize.

10 Red Flags — Instant Rejection

RED FLAGS:

1. BERBOHONG DI CV
   ├── Claim experience yang tidak ada
   ├── Inflate job title
   ├── Fake projects
   └── INSTANT REJECTION — integrity issue

2. BADMOUTH PREVIOUS EMPLOYER
   ├── "Bos saya toxic"
   ├── "Company-nya kacau"
   └── Even if true, never badmouth

3. TIDAK BISA EXPLAIN OWN CODE
   ├── Tidak paham project di CV sendiri
   ├── "Itu udah lama, lupa"
   └── Indicate tidak actually do the work

4. ZERO QUESTIONS
   ├── "Tidak ada pertanyaan"
   ├── Show tidak interest
   └── Atau tidak prepare

5. ARROGANT ATTITUDE
   ├── "Itu gampang"
   ├── Tidak acknowledge tidak tahu
   ├── Talk down ke others
   └── Will be nightmare to work with

6. BLAME OTHERS
   ├── "Itu bukan salah saya"
   ├── "Tim-nya jelek"
   ├── "Requirements tidak jelas"
   └── No ownership mentality

7. DESPERATE VIBES
   ├── "Saya butuh kerja apapun"
   ├── Begging tone
   └── Undermines your value

8. DISTRACTED
   ├── Phone buzzing
   ├── Looking elsewhere
   └── Tidak respect interviewer time

9. UNPREPARED
   ├── Tidak tahu company apa
   ├── Tidak baca job description
   └── "Posisinya ngapain ya?"

10. LATE TANPA NOTICE
    ├── Things happen, tapi communicate
    └── Late + no communication = unreliable

10 Green Flags — Interviewer Excited

GREEN FLAGS:

1. PREPARED DENGAN CONTEXT
   ├── Research company dan product
   ├── Questions yang specific dan thoughtful
   └── Know apa yang mereka cari

2. OWN THEIR MISTAKES
   ├── "Saya pernah salah di X, ini yang saya learn"
   ├── Humble tapi confident
   └── Self-aware

3. THINK OUT LOUD
   ├── Show reasoning process
   ├── Comfortable dengan ambiguity
   └── Structured thinking

4. GENUINE CURIOSITY
   ├── Ask follow-up questions
   ├── Interested in learning
   └── Engaged conversation

5. CLEAR COMMUNICATION
   ├── Structured answers
   ├── Concise tapi complete
   └── Know when to elaborate vs stop

6. SPECIFIC EXAMPLES
   ├── Use STAR method
   ├── Numbers dan outcomes
   └── Not vague generalities

7. SELF-AWARE
   ├── Know strengths dan weaknesses
   ├── Accurate self-assessment
   └── Growth mindset

8. COLLABORATIVE MINDSET
   ├── "We achieved" vs excessive "I did"
   ├── Credit to team appropriately
   └── Not lone wolf vibes

9. GROWTH ORIENTED
   ├── Eager to learn
   ├── Coachable attitude
   └── Excited by challenges

10. GOOD FOLLOW-UP
    ├── Thank you email
    ├── Reference ke specific discussion
    └── Shows attention to detail

Bagian 9: Preparation Checklist & Resources

Timeline Preparation

1 MINGGU SEBELUM:
├── ☐ Research company: product, tech stack, recent news
├── ☐ Review job description thoroughly
├── ☐ Prepare 5-7 STAR stories dari experience
├── ☐ Review technical fundamentals
├── ☐ Practice coding (LeetCode easy-medium, 3-5 soal)
└── ☐ Prepare 5 questions untuk interviewer

3 HARI SEBELUM:
├── ☐ Review resume — bisa explain semua yang tertulis
├── ☐ Practice answers OUT LOUD (record yourself)
├── ☐ Setup technical environment kalau ada live coding
├── ☐ Plan outfit dan logistics
└── ☐ Confirm interview details (time, format, who)

1 HARI SEBELUM:
├── ☐ Light review only — jangan cram
├── ☐ Prepare documents: resume, portfolio links
├── ☐ Test tech setup kalau virtual interview
├── ☐ Good sleep — rest > last minute cramming
└── ☐ Layout outfit

HARI H:
├── ☐ Arrive 10 min early / login 5 min early
├── ☐ Bring water, notebook, pen
├── ☐ Deep breaths — confidence!
├── ☐ Be yourself
└── ☐ Thank interviewer di akhir

Printable Pre-Interview Checklist

PRE-INTERVIEW CHECKLIST

RESEARCH:
☐ Company background dan history
☐ Product/service yang mereka buat
☐ Tech stack yang dipakai
☐ Recent news atau blog posts
☐ Interviewer background (LinkedIn)

PREPARATION:
☐ Review job description
☐ Match experience ke requirements
☐ Prepare 5-7 STAR stories
☐ Review fundamental concepts
☐ Practice coding problems

QUESTIONS:
☐ Prepare 5 questions untuk interviewer
☐ Questions specific ke company/role
☐ Avoid questions yang bisa di-Google

LOGISTICS:
☐ Confirm date, time, location/link
☐ Test tech setup (camera, mic, internet)
☐ Plan route kalau onsite
☐ Prepare outfit
☐ Get good sleep

DAY OF:
☐ Eat properly
☐ Arrive/login early
☐ Bring copies of resume
☐ Bring water dan notebook
☐ Phone on silent

Resources untuk Practice

Technical Practice:

ResourceBest ForCost
LeetCodeCoding problemsFree / Premium
HackerRankCoding + certificatesFree
NeetCodeCurated problems + videoFree
PrampMock interviewsFree

System Design:

ResourceBest ForCost
"System Design Interview" by Alex XuComprehensive bookPaid
ByteByteGo YouTubeVisual explanationsFree
Designing Data-Intensive ApplicationsDeep understandingPaid

Behavioral:

ResourceBest ForCost
Record yourselfPractice deliveryFree
Mock dengan temanReal feedbackFree
PrampPeer mock interviewsFree

Skill Building:

ResourceBest ForCost
BuildWithAnggaProject-based learningFree / Premium
freeCodeCampFundamentalsFree
Frontend MastersAdvanced topicsPaid

After Interview

SETELAH INTERVIEW:

DALAM 24 JAM:
├── Send thank you email
├── Reference specific discussion points
├── Reiterate interest
└── Keep it short (3-4 sentences)

TEMPLATE:
"Hi [Name],

Thank you for taking the time to interview me for [role].
I enjoyed discussing [specific topic from interview] and
learning more about [company/team].

I'm excited about the opportunity to [something relevant
to discussion]. Please let me know if you need any
additional information.

Best regards,
[Your name]"

KALAU TIDAK DAPAT KABAR (setelah stated timeline):
├── Follow up sekali via email
├── Keep it brief dan professional
└── Jangan spam atau pushy

Closing: Interview adalah Skill

Key mindset shifts:

  1. Interview adalah skill — makin sering practice, makin bagus. Treat setiap interview sebagai learning.
  2. Rejection bukan failure — itu data point. Maybe bukan fit, maybe timing, maybe ada kandidat lain yang lebih match.
  3. Setiap interview adalah practice — bahkan kalau tidak dapat offer, kamu dapat experience.
  4. Be yourself — faking tidak sustainable. Kalau kamu fake untuk dapat job, kamu akan struggle maintain.
  5. Two-way evaluation — company yang reject 'real you' bukan company yang tepat anyway.

Artikel ini akan terus di-update dengan pertanyaan baru. Bookmark dan check back!

Good luck dengan interview-mu! 🚀

Ada pertanyaan yang belum ke-cover? Atau mau share pengalaman interview? Join komunitas BuildWithAngga untuk diskusi dan mock interview dengan sesama developers.