Rehber

Davranışsal mülakat: STAR, hikâye bankası ve şirketlere göre odak

Davranışsal sorulara STAR ile cevap vermeyi, 8-10 hikâyelik bir bankayı kurup Amazon'un 16 Leadership Principle'ına ve diğer şirketlerin değerlerine eşlemeyi, İngilizce cevap kalıplarını ve en sık sorulan 20 soruyu üç seviyede örnek cevaplarla anlatır.

Cevaplar:

Bu rehberde

Teknik turları geçip davranışsal turda elenmek, deneyimli backend geliştiricilerin en sık yaşadığı sürprizdir. Sebep çoğu zaman yetersiz deneyim değil, deneyimin anlatılamaması: "biz yaptık" diye başlayan, sayısı olmayan, iki dakikada bitmeyen, sonunda ne öğrenildiği belli olmayan hikâyeler. Bu rehberde davranışsal mülakatın neyi ölçtüğünü, STAR çerçevesini, 8-10 hikâyelik bir bankayı nasıl kuracağını, Amazon'un 16 Leadership Principle'ına ve diğer şirketlerin değerlerine eşlemeyi, Türkçe konuşan biri olarak İngilizce cevap verirken işine yarayacak kalıpları, en sık sorulan 20 soruyu ve bunların altısından fazlasına üç seviyede örnek cevabı bulacaksın.

Bölüm 20'deki "Davranışsal-teknik sorular ve STAR" kısmı bu rehberin kısa halidir; oradaki "zor teknik problem" ve "production incident" cevapları teknik derinliğe odaklanır. Burada odak, aynı hikâyelerin liderlik, iş birliği ve sahiplik sinyali olarak nasıl anlatılacağı.

Davranışsal mülakat neyi ölçer

Temel varsayım: geçmişteki davranış, gelecekteki davranışın en iyi göstergesidir. "Bir anlaşmazlığı nasıl çözersin?" (varsayımsal) yerine "Bir anlaşmazlığı nasıl çözdün?" (davranışsal) sorulur, çünkü varsayımsal soruya herkes ideal cevabı verir; gerçek bir olayın ayrıntısı ise uydurulamaz. Google'ın re:Work rehberi bu ayrımı açıkça yapar: davranışsal sorular ("Tell me about a time...") geçmiş davranış kalıplarını, varsayımsal sorular ("Imagine if...") yeni durumlarda akıl yürütmeyi ölçer; yapılandırılmış mülakatlarda ikisi de önceden belirlenmiş takip sorularıyla kullanılır.

Mülakatçının not defterinde genelde şu sorular vardır:

Kapsam ve etki: Bu kişi hangi büyüklükte problemlerle uğraşmış? Etkisi kendi görevinde mi, ekipte mi, ekipler arasında mı?
Sahiplik: Kimse istemeden bir şeyi üstlenmiş mi? Sonuna kadar götürmüş mü? Hata yaptığında kabul etmiş mi?
İş birliği ve çatışma: Farklı görüşteki insanlarla nasıl çalışmış? Kazanmak mı, doğru sonuca ulaşmak mı önemli?
Belirsizlikte karar: Eksik bilgiyle nasıl ilerlemiş, riski nasıl yönetmiş?
Öğrenme: Geri bildirimi nasıl almış, aynı hatayı tekrar etmemek için ne değiştirmiş?
Seviye: Anlatılan davranış hangi seviyeye uyuyor? Mid seviye bir mühendis görevini iyi yapar; senior olan ekibin nasıl çalıştığını değiştirir.

Hikâye uydurma ve başkasının hikâyesini sahiplenme. Mülakatçı takip sorularıyla iki dakikada ayrıntıya iner ("O toplantıda tam olarak ne dedin?", "Metriği nereden ölçtün?"); uydurma hikâye orada çöker ve tüm görüşmenin güvenilirliğini bozar. Anthropic'in aday rehberi de bunu açıkça yazar: AI'ı fikirlerini rafine etmek için kullanabilirsin, ama deneyim uydurmak için kullanamazsın. Bu rehberdeki örnek cevaplar yapıyı göstermek içindir; kendi gerçek deneyiminle doldur.

STAR çerçevesi

STAR, bir hikâyeyi dinleyenin takip edebileceği sıraya sokar:

Harf	İçerik	Süre payı (2-3 dk cevap)
Situation (durum)	Bağlam: sistem, ölçek, ekip, ne zaman. 1-2 cümle.	~%15
Task (görev)	Senin sorumluluğun ve risk: neden önemliydi, ne kaybedilebilirdi?	~%10
Action (eylem)	Senin ne yaptığın: teşhis, seçenekler, neden birini seçtiğin, kimi nasıl ikna ettiğin.	~%55-60
Result (sonuç)	Ölçülebilir sonuç ve ne öğrendiğin, neyi kalıcı olarak değiştirdiğin.	~%15-20

Resmi kaynaklardan üç ek:

Amazon: Kendi mülakat rehberinde STAR'ı davranışsal mülakatlarının temeli olarak tanımlar; cevapların yaklaşık 2-3 dakika sürmesini, ekip başarısında bile senin katkını anlatan "ben" cümlelerini ve sonucun ölçülebilir veriyle gösterilmesini önerir.
Microsoft: Kariyer sayfası STAR'ın sonuna bir R daha ekler: STAR(R), yani Situation, Task, Action, Result, Reflection. "Bugün olsa neyi farklı yapardım?" kısmı büyüme zihniyeti (growth mindset) sinyalidir.
Meta: Mühendislik mülakat hazırlık yazısı davranışsal tur için STAR'ı önerir, başarısızlıklar konusunda dürüst olmayı ve teorik cevaplar yerine somut örnekler getirmeyi ister.

Kötü ve iyi Action karşılaştırması:

text

Kötü: "We had performance issues, so we optimized the queries and added caching. It worked well."

İyi:  "I pulled the slowest traces and saw that 80% of the time went to N+1 queries in the
       account summary endpoint. I considered caching, but the data changes on every
       transaction, so I rewrote the query with a single join and added a composite index.
       I rolled it out behind a feature flag to 10% of traffic first."

İkincisinde teşhis yöntemi, reddedilen alternatif ve gerekçesi, riskin nasıl yönetildiği var; mülakatçıya beş takip sorusu kapısı açıyor ve aday hepsine hazır.

Hikâye bankası nasıl kurulur

Davranışsal turda 4-6 soru gelir ve her şirket aynı temaları farklı kelimelerle sorar. Her soruya ayrı hikâye hazırlamak yerine, birden çok temaya cevap verebilen 8-10 güçlü hikâyelik bir banka kur. Bir hikâye en fazla iki kez kullanılır; aynı görüşmede aynı hikâyeyi tekrarlamamak için temalara göre birden fazla aday olmalı.

Adım 1: Ham madde topla

Son 3-4 yılın her projesi için şunları yaz: ne yaptın, kimlerle, ne zor oldu, ne ters gitti, ne ölçüldü. Kaynaklar: performans değerlendirmelerin, CV'ndeki maddeler, incident postmortem'leri, büyük PR'ların, Jira epic'lerin, aldığın teşekkür mesajları. Bankacılık ve fintech'te çalışan biri için zengin damarlar: feature owner olduğun bir API'nin tasarımdan production'a yolculuğu, regülasyon kaynaklı sıkı bir teslim tarihi, mutabakat (reconciliation) farkı çıkan bir gece, başka bir ekibin servisine bağımlılık, bir squad bölünmesi ya da yeniden yapılanma, yeni gelen birinin onboarding'i.

Adım 2: On kategoriye eşle

#	Kategori	Ölçülen sinyal	Tipik soru
1	Çatışma	Görüş ayrılığını veriyle ve ilişkiyi bozmadan çözmek	"Tell me about a time you disagreed with a teammate."
2	Başarısızlık	Sorumluluk almak, kök neden, kalıcı değişiklik	"Tell me about a time you failed."
3	Sahiplik	Kimse istemeden üstlenmek, sonuna kadar götürmek	"Tell me about something you owned end to end."
4	Belirsizlik	Eksik bilgiyle ilerlemek, varsayımları doğrulamak	"Tell me about a time requirements were unclear."
5	Sıkı deadline	Kapsamı pazarlık etmek, kaliteyi koruyarak önceliklendirmek	"Tell me about a time you had to deliver under a tight deadline."
6	Mentorluk	Başkasını büyütmek, bilgi paylaşmak	"Tell me about a time you helped someone grow."
7	Yöneticiyle anlaşmazlık	Yukarıya saygılı itiraz, "disagree and commit"	"Tell me about a time you disagreed with your manager."
8	Veriyle karar	Ölçmek, hipotez kurmak, sezgiyi veriyle sınamak	"Tell me about a decision you made based on data."
9	Production incident	Baskı altında sakinlik, iletişim, postmortem	"Tell me about a production incident you handled."
10	Yetkisiz etki	Raporlama ilişkisi olmadan başka ekipleri ikna etmek	"Tell me about a time you influenced without authority."

Ek sık temalar: en gurur duyduğun proje, zor bir geri bildirim almak ve vermek, müşteri (iç ya da dış) için standart dışı bir şey yapmak, teknik borcu iş tarafına satmak, yanlış olduğunu fark edip fikir değiştirmek.

Adım 3: Matris kur

Hikâyeleri satırlara, kategorileri sütunlara koy ve her hücreye o hikâyenin o kategoriye ne kadar uyduğunu yaz (güçlü, zayıf, yok). Hedef: her kategoride en az bir "güçlü" ve bir yedek. Boş kalan sütun hazırlık açığındır: ya yeni bir hikâye bul ya da var olan bir hikâyenin o yönünü geliştir.

Adım 4: Hikâye kartı yaz

Her hikâye için bir kart; ezber metni değil, iskelet:

text

Başlık:       Hesap özeti endpoint'inin p99'unu 1,8 sn'den 220 ms'e indirmek
Kategoriler:  sahiplik (güçlü), veriyle karar (güçlü), yetkisiz etki (zayıf)
S:            Bankanın mobil uygulamasının ana ekranı, günde ~2M çağrı, 6 kişilik squad
T:            Feature owner'dım; şikâyetler artıyordu, kimse sahiplenmemişti
A:            (1) trace analizi, N+1 tespiti  (2) cache'i reddetme gerekçesi
              (3) sorgu + index değişikliği  (4) feature flag ile %10 → %100
              (5) DBA ekibini index için ikna etme
R:            p99 1,8 sn → 220 ms, ilgili şikâyet kategorisi ~%60 azaldı
              Ders: dashboard'a ortalama değil p99 koydurduk; PR şablonuna "sorgu planı" maddesi
Rakamlar:     2M/gün, 1,8 sn, 220 ms, %10 canary, 2 sprint
Takip soruları için hazırlık: sorgu planında ne vardı? neden cache değil? DBA neden itiraz etti?
Kısa (60 sn) ve uzun (4-5 dk) versiyon: ikisini de sesli prova et

Rakamlar hikâyenin omurgasıdır ama uydurma rakam verme. Tam sayıyı bilmiyorsan "yaklaşık", "kabaca yarıya indi" de ve nasıl ölçtüğünü söyle. Bir rakamın kaynağını açıklayabilmek, rakamın kendisinden daha güçlü bir sinyaldir.

Adım 5: Sesli prova et ve kaydet

Kartları yazmak yetmez; davranışsal tur konuşma sınavıdır. Her hikâyeyi İngilizce olarak telefonuna kaydet, dinle, şunları say: "we" sayısı, dolgu kelimeleri ("basically", "actually", "like"), toplam süre, sonuç kısmında rakam var mı. Üçüncü provada süre 2-3 dakikaya oturmalı.

Amazon Leadership Principles eşlemesi

Amazon davranışsal soruları Leadership Principle'larına (LP) bağlar ve kendi rehberinde bu ilkeleri her işe alım kararının temeli olarak tanımlar. Aynı rehbere göre döngüde ekip dışından, objektif bir "Bar Raiser" da bulunur. Aday raporlarına göre her mülakatçıya birkaç LP atanır ve her biri için 1-2 soru sorulur; bu yüzden tek bir döngüde aynı LP'ye iki farklı mülakatçıdan soru gelmesi nadirdir, ama birbirine yakın LP'ler için farklı hikâyeler gerekir. Aşağıdaki 16 ilkenin adları amazon.jobs'taki resmi sayfadan alındı; Türkçe açıklamalar özettir.

#	İlke (resmi adı)	Kısa anlamı	Bankadaki hikâye kategorisi	Örnek soru
1	Customer Obsession	Müşteriden geriye doğru çalışmak, güvenini kazanmak	Sahiplik, veriyle karar	"Tell me about a time you went above and beyond for a customer."
2	Ownership	Uzun vadeli düşünmek, "bu benim işim değil" dememek	Sahiplik, incident	"Tell me about a time you took on something outside your responsibilities."
3	Invent and Simplify	Yenilik ve sadeleştirme, "burada icat edilmedi" dememek	Sahiplik, veriyle karar	"Tell me about a time you simplified a complex process."
4	Are Right, A Lot	İyi muhakeme, kendi inancını sınamak	Veriyle karar, başarısızlık	"Tell me about a time you made a decision with incomplete data."
5	Learn and Be Curious	Sürekli öğrenmek, merak	Başarısızlık, belirsizlik	"Tell me about something you learned recently that changed how you work."
6	Hire and Develop the Best	Çıtayı yükseltmek, insanları geliştirmek	Mentorluk	"Tell me about a time you helped a teammate grow."
7	Insist on the Highest Standards	Sürekli yüksek standart, hatayı aşağı akışa geçirmemek	Incident, çatışma	"Tell me about a time you refused to compromise on quality."
8	Think Big	Cesur bir yön belirlemek ve iletmek	Sahiplik, yetkisiz etki	"Tell me about a time you proposed something bigger than asked."
9	Bias for Action	Hız önemli; geri alınabilir kararlarda hızlı davranmak	Sıkı deadline, incident	"Tell me about a time you made a calculated risk under time pressure."
10	Frugality	Az kaynakla çok iş	Sıkı deadline	"Tell me about a time you delivered with limited resources."
11	Earn Trust	Dinlemek, açık konuşmak, hatayı kabul etmek	Başarısızlık, geri bildirim	"Tell me about a time you had to deliver bad news."
12	Dive Deep	Ayrıntıya inmek, metrik ile anekdot çeliştiğinde sorgulamak	Incident, veriyle karar	"Tell me about a problem you solved by digging into the details."
13	Have Backbone; Disagree and Commit	Saygılı itiraz, karar verilince tam bağlılık	Çatışma, yöneticiyle anlaşmazlık	"Tell me about a time you disagreed with your manager."
14	Deliver Results	Önemli girdilere odaklanıp zamanında sonuç	Sıkı deadline, sahiplik	"Tell me about your most challenging delivery."
15	Strive to be Earth's Best Employer	Çalışanlar için daha iyi bir ortam yaratmak	Mentorluk, yetkisiz etki	"Tell me about a time you improved your team's working environment."
16	Success and Scale Bring Broad Responsibility	Kararların geniş etkisini düşünmek	Veriyle karar, sahiplik	"Tell me about a time you considered the broader impact of a technical decision."

Pratik kural: her LP için bir birincil ve bir yedek hikâye olsun. 10 hikâye ile 16 LP'yi kapsamak mümkündür, çünkü iyi bir hikâye 3-4 LP'ye dokunur. Customer Obsession, Ownership, Dive Deep, Have Backbone; Disagree and Commit ve Deliver Results için hikâyelerin en güçlüleri olmalı; aday raporlarında mühendislik döngülerinde en sık bunlar anılıyor.

Amazon'da "müşteri" iç müşteri de olabilir: senin API'ni kullanan mobil ekip, raporunu bekleyen operasyon ekibi. Bankacılıkta son kullanıcıyla doğrudan teması olmayan bir backend geliştirici için Customer Obsession hikâyesi çoğu zaman buradan çıkar.

Şirketlere göre odak farkları

Şirket	Resmi kaynakta vurgulanan	Hazırlıkta ağırlık ver
Amazon	16 Leadership Principle; STAR; ölçülebilir sonuç; "ben" cümleleri; döngüde Bar Raiser	Her LP için hikâye; takip sorularında ayrıntıya inmeye (Dive Deep) hazır ol; rakam
Meta	45 dakikalık davranışsal tur; geçmiş işler, iş birliği, ekip çalışması, liderlik, mentorluk, çatışma yönetimi, geri bildirim verme ve alma; Meta'nın değerleriyle uyum; STAR ve somut örnek	Çatışma ve geri bildirim hikâyeleri; hızlı tempolu ortamda etki; kapsamın (scope) büyüklüğü
Google	Yapılandırılmış mülakat: aynı sorular, aynı ölçek, önceden belirlenmiş rubrik; değerlendirilen alanlar arasında rol bilgisi, problem çözme ve liderlik; davranışsal ve varsayımsal sorular	Varsayımsal sorulara ("Imagine your team...") da hazırlık; belirsizlikte akıl yürütmeyi sesli anlatmak. Aday raporlarında "Googleyness" diye anılan iş birliği ve alçakgönüllülük sinyali
Microsoft	STAR(R): sondaki R, Reflection; growth mindset ("learn-it-all" olmak); kapsayıcılık, One Microsoft (ekipler arası iş birliği), müşteri odaklılık, saygı, dürüstlük ve hesap verebilirlik	Her hikâyenin sonunda "ne öğrendim, şimdi ne farklı yapardım"; ekipler arası iş birliği hikâyesi
Netflix	Kültür sayfası: özgürlük ve sorumluluk, "context not control", "highly aligned, loosely coupled", olağanüstü açık sözlülük (candor), "keeper test"; sekiz değer (selflessness, judgment, candor, creativity, courage, inclusion, curiosity, resilience)	Açık ve doğrudan geri bildirim verdiğin/aldığın hikâyeler; az kuralla, yüksek sorumlulukla çalıştığın örnekler; muhakeme
Anthropic	Kariyer sayfasındaki değerler: insanlığın uzun vadeli iyiliği için hareket etmek, risk ve faydayı birlikte görmek, kullanıcıya iyi davranmak, güvenlikte "race to the top", "do the simple thing that works", yüksek güven ve düşük ego, misyonu önde tutmak. Canlı mülakatlarda aksi söylenmedikçe AI yardımı yok	Basit çözümü seçtiğin bir hikâye; düşük egolu iş birliği; misyona dair düşünülmüş bir "neden"; güvenlik ve sorumluluk bilinci
OpenAI	Resmi mülakat rehberi: problemlere nasıl yaklaştığın, karar verme ve gerekçeni açıklama; iş birliği, geri bildirime açıklık, misyon ve değerlerle uyum; final turları 4-6 saat, 4-6 mülakatçı	Kararlarının arkasındaki akıl yürütme; geri bildirimle değiştirdiğin bir şey; neden bu misyon

İngilizce cevap kalıpları

Hedef akıcı ve sade İngilizce; edebi değil. Mülakatçı dil bilgisi değil, netlik değerlendirir. Aşağıdaki kalıplar cevabın iskeletini taşır; aradaki içerik senin.

Hikâyeye giriş ve bağlam

"Sure. Let me tell you about a time when I was the feature owner of an API at a bank."
"For context, the service handled around two million calls a day, and my squad had six engineers."
"The challenge was that..." / "What made it tricky was that..."

Görev ve risk

"I was responsible for..." (not: responsible from)
"The risk was that if we didn't fix it before the release, ..."

Eylem (hikâyenin kalbi)

"The first thing I did was..." / "Then I..." / "Once I had the data, I..."
"I considered two options: A and B. I went with B because..."
"I set up a short meeting with the other team and walked them through the numbers."
"I didn't have the authority to change their roadmap, so instead I..."

Sonuç ve yansıma

"As a result, p99 latency dropped from 1.8 seconds to about 220 milliseconds."
"What I learned was..." / "Looking back, I would have involved the DBA team earlier."
"Since then, I always..." (kalıcı değişikliği gösterir)

Zaman kazanmak ve netleştirmek

"That's a great question. Let me think for a second about the best example."
"Do you mean a disagreement on a technical decision or on priorities?"
"I have two examples; one is more technical, one is more about people. Which would be more useful?"

Başarısızlık ve hata

"I made a mistake that caused..." (sorumluluğu pasif cümleyle saklama: mistakes were made deme)
"I owned it publicly in the incident channel and..."

Türkçe konuşanların sık yaptığı hatalar

Yanlış	Doğru	Not
I am working here since 2021.	I have been working here since 2021.	"since" ile present perfect continuous
We discussed about the design.	We discussed the design.	"discuss" edat almaz
I made a research.	I did some research.	"research" sayılamaz
informations, feedbacks	information, feedback	sayılamaz isimler
I was responsible from the API.	I was responsible for the API.
It was very much important.	It was very important. / It was critical.
According to me, ...	In my view, ... / I think ...
We have done it last year.	We did it last year.	belirli geçmiş zaman: past simple

Hikâyelerini önce Türkçe değil, doğrudan İngilizce madde madde yaz. Türkçe yazıp çevirmek uzun, iç içe cümleler üretir. Kısa cümle, aktif fiil, bir cümlede bir fikir.

Sık sorulan 20 soru

Her sorunun yanında hangi hikâye kategorisinin cevap verdiği ve sorunun arkasındaki asıl sinyal var.

"Tell me about yourself." Hikâye değil, 90 saniyelik özet: şimdi ne yapıyorsun, en güçlü 1-2 başarın, neden bu rol. Sinyal: iletişim, odak.
"Why do you want to work here?" Şirkete özgü, araştırılmış bir sebep artı kendi hedefinle bağlantı. Sinyal: motivasyon, ciddiyet.
"Tell me about a time you disagreed with a teammate." Çatışma. Sinyal: veriyle ikna, ilişkiyi koruma.
"Tell me about a time you disagreed with your manager." Yöneticiyle anlaşmazlık. Sinyal: saygılı itiraz, disagree and commit.
"What is the biggest mistake you've made?" Başarısızlık. Sinyal: sorumluluk, kök neden, kalıcı değişiklik.
"Tell me about a production incident you handled." Incident. Sinyal: sakinlik, önceliklendirme (önce etkiyi azalt), iletişim.
"Tell me about a project you owned end to end." Sahiplik. Sinyal: kapsam, sonuna kadar götürme.
"Tell me about a time requirements were ambiguous." Belirsizlik. Sinyal: varsayımları açık edip doğrulamak.
"Tell me about a time you had to deliver under a tight deadline." Sıkı deadline. Sinyal: kapsam pazarlığı, risk yönetimi.
"Tell me about a time you received difficult feedback." Geri bildirim. Sinyal: savunmaya geçmemek, değişim.
"Tell me about a time you gave difficult feedback." Geri bildirim, mentorluk. Sinyal: açık sözlülük ve empati.
"Tell me about a time you mentored someone." Mentorluk. Sinyal: başkasının başarısını ölçmek.
"Tell me about a time you influenced another team without authority." Yetkisiz etki. Sinyal: ortak çıkar bulmak, veri, ilişki.
"Tell me about a decision you made based on data." Veriyle karar. Sinyal: hipotez, ölçüm, sezgiyi sınamak.
"Tell me about a time you made a decision with incomplete information." Belirsizlik, Are Right A Lot. Sinyal: geri alınabilirlik, risk sınırlama.
"Tell me about a time you simplified something complex." Invent and Simplify. Sinyal: gereksizi silme cesareti.
"Tell me about a time you pushed back on a requirement." Çatışma, müşteri. Sinyal: "hayır" yerine alternatif sunmak.
"Tell me about your most technically challenging project." Teknik derinlik (bkz. Bölüm 20). Sinyal: mekanizma, trade-off.
"Tell me about a time you had to learn something quickly." Öğrenme. Sinyal: öğrenme yöntemi, hız.
"Do you have any questions for us?" Her zaman evet. Sinyal: ilgi ve önceliklerin (bkz. Bölüm 20, "Mülakatçıya sorulacak sorular").

Üç seviyede cevap

Örnek cevaplar İngilizce, çünkü global şirketlerde tur İngilizce yapılır; analizler Türkçe. Cevaplardaki ayrıntılar örnektir; kendi deneyiminle değiştir.

Soru: "Tell me about yourself."

I'm a backend developer with five years of experience. I mostly use Java and Spring Boot. I worked on banking projects, and I know Kafka, PostgreSQL, Docker and Kubernetes. I like learning new technologies and I'm a team player. I'm looking for a new challenge.

I'm a backend engineer with about five years of experience, mostly Java and Spring Boot. For the last couple of years I've been working at a bank's technology hub on party and account services, the systems that hold customer and account data for other teams. I was the feature owner of one of our core APIs, from design to production. I've done a lot of work with Kafka-based integrations and PostgreSQL performance. I'm now looking for a role where I can work on larger-scale distributed systems.

I'm a backend engineer with five years of experience, and most of it is in banking, where correctness matters more than speed, so I've learned to design for failure from day one. Right now I'm a feature owner in a squad that owns party and account data at a bank's tech hub; other teams build on our APIs, so a lot of my work is making those contracts stable and easy to use. One thing I'm proud of: I owned an API from the first design document to production, including the idempotency and reconciliation pieces, and it's been running without a data incident since launch. Lately I've been pushing my team towards better observability, for example getting p99 dashboards and alerts in place. What I'm looking for next is the same level of ownership, but at a bigger scale, which is why this role caught my attention.

Junior teknoloji listesi okuyor; ne yaptığını, nasıl bir etki yarattığını ve neden bu rolü istediğini söylemiyor; "team player" gibi kanıtsız sıfatlar sinyal taşımaz. Mid somut: domain, rol (feature owner), teknik alanlar ve bir yön. Senior bir anlatı kuruyor: bankacılığın ona öğrettiği bir ilke, şu anki sorumluluğu, kanıtlı bir başarı, ekip üzerindeki etkisi ve neden bu rol; ayrıca mülakatçıya takip sorusu için kapılar bırakıyor (idempotency, reconciliation, observability). 90 saniyeyi geçmiyor.

Takip sorusu: "You mentioned reconciliation. What did you reconcile against, and what happened the first time the numbers didn't match?"

Soru: "Tell me about a time you disagreed with a teammate."

A colleague wanted to use MongoDB for a new service but I thought PostgreSQL was better. We discussed it, and in the end we used PostgreSQL because the team lead agreed with me.

We were designing a notification service, and a teammate wanted to call the SMS provider synchronously from the transaction flow. I thought that would make our transfer endpoint depend on the provider's latency. I explained my concern in the design review and suggested publishing an event to Kafka instead. He was worried about complexity, so we agreed to try the async approach with a simple consumer first. It worked well, and the transfer endpoint's latency wasn't affected when the provider had issues later.

In a design review for a new transfer notification, a senior teammate proposed calling the SMS provider synchronously inside the transfer flow. My concern was coupling: the provider had a p99 of around two seconds, and our transfer endpoint had a one-second SLO. Instead of arguing opinions, I asked if we could look at the provider's latency data together, and I wrote a one-page comparison of three options: synchronous, async via Kafka, and the outbox pattern. His real concern, it turned out, was not complexity in general but losing messages, which was fair, because a plain async publish could drop notifications if the service crashed. So we went with the outbox pattern, which addressed both concerns. I also made sure he presented the final design, since the reliability requirement was his contribution. Since launch, provider incidents haven't affected transfer latency, and we've had zero lost notifications. What I took from it is to find the concern behind the position before defending my own.

Junior "kazandığı" bir tartışmayı anlatıyor ve kararı yetkiye (team lead) bağlıyor; karşı tarafın gerekçesi yok, sonuç ölçülmemiş. Mid makul: somut bir teknik endişe, öneri, ortak deneme ve sonuç. Senior çatışmayı bir anlama sürecine çeviriyor: veriyle (p99, SLO) konuşuyor, seçenekleri yazılı karşılaştırıyor, karşı tarafın asıl endişesini (mesaj kaybı) keşfedip çözüme dahil ediyor (outbox), krediyi paylaşıyor ve ölçülebilir sonuç ile bir ders veriyor. Bu cevap Amazon'da Have Backbone; Disagree and Commit ve Earn Trust, Meta'da çatışma yönetimi için güçlü bir sinyal.

Takip sorusu: "What would you have done if he still disagreed after seeing the data?"

Soru: "What is the biggest technical mistake you've made?"

Once I forgot to add an index and the query was slow in production. I added the index and it was fixed. Now I'm more careful.

I once deployed a database migration that added a NOT NULL column with a volatile default (generated per row) to a large table on PostgreSQL during business hours, which forces a full table rewrite. It locked the table for several minutes and some requests failed. I rolled back, and we re-ran the migration at night. After that, I started checking migrations against a production-size copy of the data and I added a checklist item for long-running DDL.

A few years ago I shipped a change to a Kafka consumer that processed account events, and I configured it to retry failed records indefinitely without thinking through poison messages. One malformed event from an upstream team blocked the partition, and for about forty minutes balance updates for a subset of customers were delayed. I noticed it from the consumer lag alert, and my first step was to stop the impact: I deployed a hotfix that skipped and logged that specific offset, after confirming with the upstream team that the event was invalid. Then I owned the follow-up publicly. I wrote the postmortem, and the real fix wasn't just my code: we added a dead letter topic with alerting, classified errors into retryable and non-retryable, and I added a contract test with the upstream team's schema. The mistake was mine, assuming "upstream data is always valid". Now, any consumer I review has to answer one question first: what happens with a message we can never process?

Junior küçük ve önemsiz bir hata seçiyor (soru "en büyük" diyor), etkiyi ve kök nedeni anlatmıyor; "daha dikkatliyim" kalıcı bir değişiklik değildir. Mid gerçek bir hata, etki, geri alma ve bir süreç değişikliği veriyor; iyi. Senior hatayı açıkça sahipleniyor ("the mistake was mine"), etkiyi nicelendiriyor, önce kanamayı durduruyor, sonra kök nedeni kendi varsayımına kadar indiriyor ve sistemik düzeltmeler (DLQ, hata sınıflandırması, contract test) ile kendi review alışkanlığındaki değişikliği gösteriyor. Mülakatçı burada suçu başkasına atma eğilimini, savunmacılığı ve öğrenmenin kalıcılığını arıyor.

Takip sorusu: "How did you communicate the delay to the business and to affected customers while it was happening?"

Soru: "Tell me about a production incident you owned."

There was an incident where our service was returning 500 errors. I looked at the logs and found a NullPointerException. I fixed the bug and deployed it, and the errors stopped.

Our account service started timing out one evening. I checked the dashboards and saw the database connection pool was exhausted. I found that a new report endpoint was running a slow query and holding connections. I disabled the endpoint with a feature flag, which brought the service back, then optimized the query the next day and added a timeout. I also wrote the postmortem.

One evening our account API's error rate jumped to around 30%. I was on call, so I took the incident commander role and opened a channel so updates were in one place. First question: what changed? A release had gone out an hour earlier, but the metrics pointed elsewhere: the HikariCP pool was exhausted, and the slow query log showed a new reporting endpoint scanning a large table. The fastest safe mitigation was the feature flag on that endpoint, not a full rollback, because the release also contained a regulatory fix. Error rate went back to normal in about eight minutes from the alert. I posted updates every fifteen minutes for the business side in plain language. The next day I ran a blameless postmortem. The root cause wasn't the query alone; it was that reporting traffic shared the same pool as customer traffic. We moved reporting to a read replica with its own pool, added statement timeouts, and added an alert on pool saturation, which had been missing. The part I'd do differently: I should have pulled in the DBA earlier instead of digging alone for the first ten minutes.

Junior bir hata düzeltmesini anlatıyor, incident yönetimini değil: etki, iletişim, önceliklendirme ve önleme yok. Mid doğru teşhis ve geçici çözüm ile postmortem veriyor. Senior bir incident'ı yönetiyor: rol üstleniyor, iletişim kanalını ve sıklığını kuruyor, "ne değişti" sorusunu soruyor ama veriye göre yön değiştiriyor, riski en az olan azaltmayı gerekçesiyle seçiyor (rollback değil flag), süreyi ölçüyor, kök nedeni mimari seviyeye (paylaşılan pool) indiriyor, eksik alarmı ekliyor ve kendi hatasını (DBA'yı geç çağırmak) söylüyor. Bölüm 20'deki aynı sorunun cevabı teknik teşhise odaklanır; bu soru davranışsal turda gelirse ağırlık sahiplik ve iletişime kayar.

Takip sorusu: "How did you decide between the feature flag and a full rollback? Who did you need to ask?"

Soru: "Why do you want to work here?"

Your company is very famous and a great place to work. I want to work with talented people and improve myself. Also, the benefits are good.

I've been following your engineering blog and I like the scale of the problems you work on. I've worked mostly on banking systems, and I want to apply what I learned about reliability to higher-traffic systems. The team's focus on distributed systems matches what I want to grow in.

Three reasons, and they're specific to this team. First, the problem: the role is on the payments platform, and that's exactly the intersection of what I've done, money movement where correctness is non-negotiable, and what I want to do next, which is the same correctness at a much bigger scale. Second, I read your team's post on how you handle idempotency across retries in checkout, and it was close to a design I built, but you solved the multi-region part I never had to. I'd like to learn that from the inside. Third, the way you described the role: the engineer owns the service in production. That's how I've worked as a feature owner, and I don't want to go back to throwing code over the wall. And honestly, I also think I can contribute from day one on the reliability side, things like reconciliation and safe migrations, because I've done them in a regulated environment.

Junior şirket hakkında araştırma yapmadığını gösteriyor; ün ve yan haklar motivasyon değil. Mid daha iyi ama genel: "ölçek" ve "blog" her şirkete söylenebilir. Senior cevabı bu şirkete ve bu ekibe özgü: rolün kendisi, okuduğu belirli bir teknik içerik ve onunla kendi deneyimi arasındaki bağ, çalışma biçimine (production sahipliği) dair bir tercih ve ne katacağı. Hem "neden siz" hem "neden ben" cevaplanıyor. Not: senior cevabındaki blog yazısı bir örnek; gerçek mülakatta adı geçen her içeriği gerçekten okumuş olmalısın, mülakatçı sorabilir.

Takip sorusu: "What do you think would be the hardest part of this role for you in the first six months?"

Soru: "Tell me about a time you received difficult feedback."

My manager told me I should communicate more. I agreed and started to talk more in meetings.

In a performance review, my manager said my pull requests were too large and hard to review. At first I thought it was because the features were big, but I looked at the data and saw my PRs took twice as long to merge as the team average. I started splitting work into smaller PRs behind feature flags. My review time went down and I got fewer review comments per PR.

About a year into my role, a tech lead from another squad told me, quite directly, that in cross-team meetings I came across as defending my team's API instead of solving their problem. My first reaction was defensive, honestly, because I thought I was protecting the API's consistency. But I asked him for a specific example, and he pointed to a meeting where I'd rejected a field request in two minutes without asking why they needed it. When I replayed it, he was right. What I changed: in every API change request, I now start by writing down the consumer's use case in their words before discussing the contract, and I offer at least one alternative when I say no. A few months later the same team asked me to review their integration design, which I took as a sign the relationship had changed. I also asked him to tell me if he saw it again, which he did once, and that was useful too.

Junior geri bildirimi yüzeysel kabul edip yüzeysel değiştiriyor; kanıt ve sonuç yok. Mid geri bildirimi veriyle doğruluyor ve ölçülebilir bir değişiklik yapıyor; güçlü bir mid cevabı. Senior zor bir geri bildirimi (davranışsal ve başka ekipten) seçiyor, ilk tepkisinin savunmacı olduğunu dürüstçe söylüyor, somut örnek isteyerek anlamaya çalışıyor, davranışını sistematik olarak değiştiriyor, ilişkideki değişimi kanıtla gösteriyor ve geri bildirim döngüsünü açık tutuyor. Microsoft'un growth mindset'i, Netflix'in candor değeri ve Amazon'un Earn Trust ilkesi tam olarak bunu arar.

Takip sorusu: "Tell me about a time you gave difficult feedback to someone. How did you prepare?"

Soru: "Tell me about a time you disagreed with your manager."

My manager wanted to release a feature on Friday, but I thought it was risky. I told him, but he insisted, so we released it. It was fine.

My manager wanted to skip writing integration tests to meet a deadline. I explained that the feature touched money transfers and that a bug could be expensive. We agreed to write integration tests only for the transfer path and skip them for the less critical parts. We met the deadline and didn't have any bugs in the transfer flow.

My manager committed to a date for migrating our account API consumers to a new version, and I thought the date was unrealistic because three consuming teams hadn't even started. Instead of just saying "it's too risky", I put the data in front of him: each consumer's status, their own estimates, and what would happen to the old version's support if we slipped. I proposed two options: keep the date with a compatibility layer so the old contract kept working, or move the date by six weeks. He explained something I didn't know: the date was tied to a vendor contract ending, so it couldn't move. Once I understood that, I committed fully to his decision and built the compatibility layer, which was the option that respected the constraint. We hit the date, two teams migrated afterwards with no pressure, and we removed the layer two months later. The lesson for me was to ask about the constraint behind a date before arguing with the date.

Junior itirazını söylüyor ama gerekçesiz, alternatifsiz ve sonuçta pasif; "it was fine" şans hikâyesidir. Mid riski iş diliyle anlatıp bir orta yol buluyor; iyi. Senior disagree and commit davranışını uçtan uca gösteriyor: itirazı veriye ve seçeneklere dayandırıyor, yöneticinin bilmediği bir kısıtı dinleyip öğreniyor, karar verildikten sonra tam bağlılıkla kısıtı karşılayan seçeneği uyguluyor ve bir ders çıkarıyor. Mülakatçı burada hem "itiraz edebiliyor mu" hem "karar aleyhine çıkınca baltalamadan uygulayabiliyor mu" sorularının cevabını arıyor.

Takip sorusu: "Was there a time you disagreed and you turned out to be right, but the decision had already been made? What did you do?"

Sık yapılan hatalar

"We" ile anlatmak. Ekip başarısını anlatırken senin payın kaybolur. Her eylem cümlesinde öznenin "I" olup olmadığını kontrol et; ekibe krediyi sonda ver.
Situation'da boğulmak. Bağlamı anlatmak için iki dakika harcayıp eyleme 30 saniye bırakmak. Bağlam 2 cümle.
Sonuçsuz hikâye. "And it worked" sonuç değildir. Rakam, değişiklik ya da öğrenilen ders olmalı.
Kusursuz kahraman. Hiç hata yapmayan, her tartışmayı kazanan aday güvenilmez görünür. Başarısızlık sorusuna "çok çalışıyorum" tarzı sahte zayıflıkla cevap verme.
Başkalarını suçlamak. "Diğer ekip beceriksizdi" diye başlayan bir çatışma hikâyesi, ne söylersen söyle, kötü bir sinyaldir.
Aynı hikâyeyi her soruya uydurmak. Hikâye bankası bunu önlemek içindir.
Ezber metin. Okunuyormuş gibi gelen cevap, takip sorusunda dağılır. İskeleti ezberle, cümleleri değil.
Soru sormamak. "Do you have any questions?" sorusuna "No" demek ilgisizlik sinyalidir.

Hızlı tekrar

S: STAR'ın harfleri ve 2-3 dakikalık bir cevapta zamanın çoğu nereye gitmeli?

C: Situation, Task, Action, Result; zamanın yarısından fazlası Action'a, yani senin yaptıklarına (teşhis, seçenekler, gerekçe).

S: Microsoft'un STAR(R) çerçevesindeki ek R nedir?

C: Reflection: geriye bakınca ne öğrendiğin ve neyi farklı yapacağın; growth mindset sinyali.

S: Hikâye bankası kaç hikâyeden oluşmalı ve nasıl kontrol edilir?

C: 8-10 hikâye; hikâye × kategori matrisi kurulur ve her kategoride bir güçlü hikâye ile bir yedek olup olmadığına bakılır.

S: Amazon'un kaç Leadership Principle'ı var; "itiraz et ama karar verilince bağlan" hangisi?

C: 16; "Have Backbone; Disagree and Commit".

S: Anthropic canlı mülakatlarda AI kullanımı hakkında ne diyor?

C: Aksi belirtilmedikçe AI yardımı yok; hazırlıkta (araştırma, pratik) kullanmak serbest, deneyim uydurmak için kullanmak değil.

S: "Neden bu şirket?" sorusuna güçlü bir cevabın iki yarısı nedir?

C: "Neden siz": bu ekibe ve role özgü, araştırılmış sebepler; "neden ben": deneyimimle bağlantı ve ilk günden ne katacağım.

Kaynaklar

Amazon Leadership Principles: 16 ilkenin resmi adları ve açıklamaları.
Amazon interview guide (About Amazon): STAR'ın davranışsal mülakattaki yeri, 2-3 dakikalık cevaplar, "ben" cümleleri, ölçülebilir sonuç ve Bar Raiser.
Meta: Preparing for your software engineering interview: Davranışsal turun süresi, odak konuları ve STAR önerisi.
Google re:Work: A guide to structured interviewing: Davranışsal ve varsayımsal sorular, rubrik ve değerlendirilen alanlar.
Microsoft: Interview tips: STAR(R), growth mindset ve kültür değerleri.
Netflix Culture: Özgürlük ve sorumluluk, candor, keeper test ve sekiz değer.
Anthropic Careers: Şirket değerleri.
Anthropic: Guidance on candidates' AI usage: Başvuru, hazırlık ve canlı mülakatta AI kullanımı kuralları.
OpenAI Interview Guide: Süreç aşamaları ve değerlendirilen davranışlar.