Senior Frontend Developer (React) Mülakat Hazırlık Soruları

Kurumsal ölçekli ürünler geliştiren, React ağırlıklı, design system ve ölçeklenebilir mimariye önem veren, AI destekli geliştirme araçlarını iş akışına dahil eden bir şirketin senior frontend developer ilanı temel alınarak hazırlanmıştır. Aynı profildeki ilanların büyük kısmında aynı başlıklar ve aynı tarzda sorular çıkar, bu doküman genel geçer bir hazırlık kaynağı olarak kullanılabilir.

1. React Temelleri ve İleri Seviye Kullanım

Reconciliation (uzlaştırma) süreci nasıl işler, Fiber mimarisi neden getirildi?

State değiştiğinde React yeni bir Virtual DOM ağacı oluşturur ve bunu bir önceki ağaçla karşılaştırır (diffing).
Karşılaştırma sonucunda yalnızca değişen kısımlar gerçek DOM’a yansıtılır, tüm ağaç yeniden yazılmaz.
Liste render’larında key prop’u stabil ve benzersiz olmalıdır; index kullanmak, liste sırası değiştiğinde yanlış eşleşmelere ve gereksiz DOM güncellemelerine yol açar.
React 16 öncesi stack reconciler senkron ve kesilemezdi, büyük component ağaçlarında ana thread’i bloke edebiliyordu.
Fiber mimarisi, render işini küçük birimlere (unit of work) böler ve tarayıcıya öncelikli işler (kullanıcı input’u gibi) için ara verme imkânı tanır.
Bu yapı, React 18’deki startTransition ve useDeferredValue gibi eşzamanlı (concurrent) özelliklerin temelini oluşturur.

useEffect ile useLayoutEffect arasındaki fark nedir, hangisi ne zaman kullanılır?

useEffect tarayıcı ekranı boyadıktan (paint) sonra asenkron çalışır.
useLayoutEffect paint öncesinde senkron çalışır.
DOM ölçümü yapıp bu ölçüme göre hemen bir DOM güncellemesi gerektiren durumlarda (örneğin bir tooltip’in pozisyonunu hesaplama) useLayoutEffect kullanılır.
Aksi halde, yani useEffect kullanılırsa, kullanıcı kısa süreli bir görsel kayma (flicker) görebilir.
Genel kural: varsayılan tercih useEffect‘tir, useLayoutEffect yalnızca layout kaynaklı görsel sorun varsa devreye girer.

Bir component’in gereksiz yere re-render olduğu nasıl tespit edilir, nasıl önlenir?

React DevTools Profiler ile hangi component’in neden render olduğu incelenir.
React.memo, useMemo ve useCallback referans eşitliğine (referential equality) dayanır.
Her render’da yeni bir obje, array veya fonksiyon oluşturulursa bu optimizasyonlar işe yaramaz.
Context API kullanımında, context değeri değiştiğinde o context’i tüketen tüm component’ler re-render olur.
Bu durumda context’i daha küçük parçalara bölmek (context splitting) veya ilgili state için ayrı bir state management çözümü kullanmak gerekebilir.

Custom hook yazarken hangi prensiplere dikkat edilir?

Bir custom hook tek bir sorumluluğa odaklanmalıdır.
İsimlendirme use prefix’i taşımalı ve React’in hook kurallarına (yalnızca en üst seviyede çağrılma, koşullu çağrılmama) uymalıdır.
Dependency array’lerin eksiksiz ve doğru tanımlanması, stale closure (eski değerlere referans veren kapanış) sorunlarını önler.
Hook’un dışa açtığı API (dönen değerler ve fonksiyonlar) sade ve tahmin edilebilir olmalıdır.

“Controlled” ve “uncontrolled” component nedir, büyük formlarda hangisi tercih edilir?

Controlled component’te form değeri React state’inde tutulur, her karakter girişinde re-render tetiklenir, değer üzerinde tam kontrol sağlanır.
Uncontrolled component’te değer DOM’un kendisinde tutulur, ref ile okunur; anlık validasyon veya UI senkronizasyonu zorlaşır ama re-render maliyeti düşer.
Çok sayıda input içeren büyük formlarda, her keystroke’ta tüm formun re-render olmasını önlemek amacıyla genellikle uncontrolled yaklaşımı temel alan kütüphaneler (örneğin react-hook-form) tercih edilir.

Prop drilling nedir, nasıl önlenir?

Prop drilling, bir veya birden fazla ara katman component’in sadece alt bileşene aktarmak amacıyla kullanmadığı prop’ları taşımasıdır.
Component ağacı derinleştikçe okunabilirliği ve bakım kolaylığını düşürür.
Context API, state management kütüphaneleri veya component composition (children prop’u ile iç içe yerleştirme) prop drilling’i azaltmak için kullanılan yaklaşımlardır.
Her prop drilling’in Context ile çözülmesi gerekmez; bazen basitçe component yapısını yeniden düzenlemek (composition) yeterlidir.

React’te error boundary nedir, nerelerde kullanılır?

Error boundary, alt component ağacında oluşan JavaScript hatalarını yakalayıp uygulamanın tamamının çökmesini önleyen, bunun yerine bir fallback arayüz gösteren bir mekanizmadır.
Şu an yalnızca class component’lerde componentDidCatch ve getDerivedStateFromError ile uygulanabilir.
Genellikle uygulamanın kritik bölümlerini (örneğin bir dashboard widget’ı) izole etmek için, o bölümün hatası tüm sayfayı etkilemesin diye kullanılır.

key prop’unun React’in iç işleyişindeki rolü nedir?

key, React’in liste elemanlarını render’lar arası eşleştirmesini (reconciliation) sağlayan tanımlayıcıdır.
Doğru ve stabil bir key kullanılmazsa (örneğin array index kullanımı, liste sırası değiştiğinde) React yanlış elemanları güncelleyebilir.
Bu durum hem görsel hatalara hem de gereksiz DOM işlemlerine yol açar.
key değiştiğinde React o component’i tamamen unmount edip yeniden mount eder; bu davranış bazen bilinçli olarak bir component’i sıfırlamak için de kullanılır.

Suspense ve lazy loading React’te nasıl çalışır?

React.lazy, bir component’i ilk render anında değil, ihtiyaç duyulduğunda (örneğin bir route’a girildiğinde) yüklemeyi sağlar.
Suspense, bu component yüklenene kadar gösterilecek bir fallback arayüz (loading state) tanımlar.
Bu ikili, route bazlı code splitting’in temelini oluşturur.
İlk yükleme süresini (initial bundle size) küçültmede kritik rol oynar.

2. Modern JavaScript (ES6+) ve TypeScript

interface ile type arasındaki fark nedir?

interface declaration merging (aynı isimle birden fazla tanım yapılıp otomatik birleştirilmesi) destekler.
interface genellikle nesne şekillerini (object shape) tanımlamak için kullanılır.
type union, intersection ve mapped type gibi daha esnek yapılar kurmaya izin verir.
Genel pratikte, dışa açık API/props tanımlarında interface, karmaşık union veya koşullu tiplerde type tercih edilir.

Generic kullanarak yeniden kullanılabilir bir veri çekme hook’u nasıl tiplenir?

Dönen verinin tipi generic parametre olarak alınır (useFetch<T>).
Loading, success ve error durumları ayrı ayrı boolean bayraklarla değil, discriminated union ile modellenir ({status: 'loading'} | {status: 'success', data: T} | {status: 'error', error: string}).
Bu yapı, hatalı state kombinasyonlarını (örneğin hem loading hem data dolu olması) derleme zamanında engeller.
Generic parametre sayesinde aynı hook farklı veri tiplerinde tekrar tekrar yazılmadan kullanılabilir.

any, unknown ve never arasındaki fark nedir?

any tip kontrolünü tamamen devre dışı bırakır ve mümkün olduğunca kaçınılması gereken bir tiptir.
unknown güvenli bir alternatiftir, değeri kullanmadan önce tip daraltma (narrowing) zorunludur.
never hiçbir zaman değer üretmeyen (örneğin her zaman hata fırlatan) fonksiyonları ifade eder.
never, switch/case yapılarında tüm olasılıkların ele alındığını garanti eden exhaustive check senaryolarında da kullanılır.

Promise.all ile Promise.allSettled arasındaki fark nedir?

Promise.all, verilen promise’lerden biri reddedilirse (reject) tüm işlemi anında reddeder.
Promise.allSettled tüm promise’lerin sonucunu (başarılı veya başarısız) bekler ve hiçbirini erken sonlandırmaz.
Birden fazla bağımsız isteğin bazıları başarısız olsa bile diğerlerinin sonucunun kullanılması gereken senaryolarda allSettled tercih edilir.

Strict TypeScript konfigürasyonunun (strict: true, noImplicitAny vb.) faydaları nelerdir?

Strict mod, örtük any kullanımını, null/undefined kontrolü eksikliğini ve benzer hataları derleme zamanında yakalar.
Kısa vadede geliştirme hızını bir miktar düşürür.
Uzun vadede refactoring güvenliği sağlar.
Çalışma zamanı (runtime) hatalarının azalmasına katkıda bulunur.
IDE’nin daha doğru autocomplete ve öneriler sunmasını sağlar.

Discriminated union (ayırt edici birleşim tipi) nedir, neden kullanılır?

Bir tip birleşiminde (union type) her varyantın ortak bir alan (genellikle type veya status) üzerinden ayırt edilmesidir.
switch veya if ile bu alan kontrol edildiğinde, ilgili varyanta özgü diğer alanlara güvenli şekilde erişim sağlanır (tip daraltma).
API yanıtlarının veya UI state’lerinin (loading/success/error gibi) modellenmesinde geçersiz durum kombinasyonlarını derleme zamanında engellemek için kullanılır.

Utility type’lardan (Partial, Pick, Omit, Record vb.) hangileri sık kullanılır, ne işe yararlar?

Partial<T>, bir tipin tüm alanlarını opsiyonel yapar; güncelleme (update) fonksiyonlarında sıkça kullanılır.
Pick<T, K> ve Omit<T, K>, bir tipten belirli alanları seçip almak veya çıkarmak için kullanılır; örneğin bir form tipini API response tipinden türetmek için idealdir.
Record<K, T> anahtar-değer eşlemelerini tiplemekte kullanılır.
Bu utility type’lar, aynı veri şeklini birden fazla yerde elle tekrar tanımlamak yerine mevcut tiplerden türetmeyi sağlar, tip tutarlılığını korur.

Event loop, microtask ve macrotask kuyruğu arasındaki fark nedir?

JavaScript tek thread’de çalışır.
Senkron kod bittikten sonra event loop, önce microtask kuyruğunu (Promise callback’leri, queueMicrotask) tamamen boşaltır.
Ardından bir sonraki macrotask’a (setTimeout, setInterval, I/O) geçer.
Bu sıralama, örneğin setTimeout(fn, 0) içindeki kodun neden bir Promise .then() callback’inden sonra çalıştığını açıklar.
Bu mekanizmayı anlamak, çok sayıda asenkron işlemin sıralamasının önemli olduğu senaryolarda kritik hale gelir.

3. State Management

Redux, Zustand, Recoil ve Context API arasındaki tercih kriterleri nelerdir?

Context API, sık değişmeyen ve sınırlı kapsamlı global state için (tema, oturum açmış kullanıcı bilgisi gibi) uygundur; sık güncellenen state’lerde performans sorunlarına yol açabilir.
Redux, özellikle Redux Toolkit ile, büyük ekiplerin çalıştığı, öngörülebilirlik ve middleware (loglama, geri alma, zaman içinde hata ayıklama) gerektiren kurumsal projelerde tercih edilir.
Zustand, daha az boilerplate ile orta ölçekli projelerde hızlı kurulum sağlar.
Recoil, atom bazlı bir yapı sunar; component ağacında dağınık, bağımsız state parçalarının yönetilmesi gerektiğinde kullanılır, ancak topluluk desteği ve uzun vadeli bakım açısından ayrıca değerlendirilmelidir.

Server state ile client state ayrımı nasıl yapılır?

Server state, backend’den gelen ve cache, senkronizasyon, geçersiz kılma (invalidation) gibi ek yönetim gerektiren veridir.
Client state, yalnızca arayüze özgü verilerdir (bir modal’ın açık olup olmadığı, bir form alanının anlık değeri gibi).
Bu iki tür state’i aynı store içinde aynı mantıkla yönetmek gereksiz karmaşıklığa yol açabilir.
React Query / TanStack Query gibi araçlar, server state için cache yönetimi, arka planda yeniden veri çekme (background refetch) ve iyimser güncelleme (optimistic update) gibi hazır çözümler sunar.

Büyük bir Redux store’da gereksiz re-render sorunları nasıl teşhis edilir ve çözülür?

Selector’ların memoize edilmemesi (örneğin reselect veya createSelector kullanılmaması) gereksiz re-render’lara yol açar.
Her render’da yeni bir obje veya array döndürülmesi de aynı soruna neden olur.
State’in normalize edilmemiş, iç içe geçmiş (deeply nested) bir yapıda tutulması performans sorunlarını büyütür.
Bunun yerine normalized entity yapısı ({byId, allIds}) kullanılması önerilir.

4. Component-Driven Development ve Design System

Sıfırdan bir design system kurulurken hangi katmanlar tanımlanır?

En temelde design token katmanı bulunur (renk, spacing, typography, radius değerleri).
Bunun üzerine primitive component’ler inşa edilir (Button, Input, Icon).
Ardından composite/pattern component’ler gelir (Form, Modal, DataTable).
Son olarak sayfa şablonları bu katmanların üzerine kurulur.
Bu yaklaşım, Atomic Design metodolojisindeki atom/molecule/organism ayrımına benzer bir hiyerarşi izler.

Reusable component tasarımında esneklik ile tutarlılık arasındaki denge nasıl kurulur?

Bir component’e sınırsız prop veya style/className override imkânı tanımak esneklik sağlar ama tasarım tutarlılığını bozar.
Bunun yerine token/variant tabanlı bir API (variant="primary" size="md") tercih edilerek hem esneklik hem tutarlılık korunur.
Compound component pattern (örneğin Select ve Select.Option birlikte kullanımı) kontrollü esneklik sağlayan bir yaklaşımdır.
Slot pattern de benzer şekilde, component’in belirli bölümlerinin özelleştirilebilmesine izin verirken genel yapıyı korur.

Paylaşılan bir component kütüphanesinde breaking change nasıl yönetilir?

Semantic versioning ile değişikliklerin etkisi (patch, minor, major) net şekilde iletilir.
Kaldırılacak (deprecated) prop veya API’ler önce console uyarısıyla işaretlenir.
Ardından bir migration guide veya codemod ile geçiş kolaylaştırılır.
Değişikliklerin changelog üzerinden takip edilebilir olması, tüketen ekiplerin güvenle güncelleme yapmasını sağlar.

5. API, WebSocket ve Gerçek Zamanlı Veri

WebSocket bağlantısı React uygulamasında nasıl yönetilir, kopan bağlantı nasıl toparlanır?

Bağlantının yaşam döngüsü, tek bir component’in yaşam döngüsüne bağlanmamalıdır; bağımsız bir servis veya singleton yapı üzerinden yönetilmelidir.
Aksi halde component unmount olduğunda bağlantı anlamsız yere kesilip açılabilir.
Bağlantı koptuğunda exponential backoff ile yeniden bağlanma (reconnect) denemesi yapılır.
Heartbeat/ping-pong mekanizmasıyla bağlantının canlılığı kontrol edilir.
Çok sık gelen mesajlarda her mesajda ayrı render yapmak yerine kısa aralıklarla toplu (batched) state güncellemesi performansı korur.

REST API entegrasyonlarında hata yönetimi nasıl katmanlandırılır?

Merkezi bir HTTP client (axios interceptor veya fetch wrapper) üzerinden hata tipleri normalize edilir.
Network hatası, 4xx (istemci hatası, örneğin validasyon) ve 5xx (sunucu hatası) durumları ayrı ayrı ele alınır.
Kullanıcıya gösterilecek mesaj ile geliştirici/log tarafında tutulan detaylı hata bilgisi birbirinden ayrılır.
Retry mantığı network timeout gibi geçici hatalarda anlamlıdır, 400 validation hatalarında anlamsızdır.

Optimistic update nedir, nasıl uygulanır?

Kullanıcı deneyimini hızlandırmak için sunucu yanıtı beklenmeden arayüz hemen güncellenir.
Sunucudan hata dönerse önceki state’e geri dönülür (rollback).
React Query gibi kütüphaneler bu akışı onMutate, onError ve onSettled callback’leri ile yapılandırılmış şekilde destekler.

6. CSS, Responsive Design ve Modern Yaklaşımlar

Tailwind, SCSS ve CSS-in-JS arasındaki seçim kriterleri nelerdir?

Tailwind, tutarlı design token kullanımı ve hızlı geliştirme sağlar, ancak class kalabalığı ve öğrenme eğrisi getirir.
CSS-in-JS (styled-components, emotion) dinamik stil ihtiyacı yüksek projelerde esneklik sunar.
CSS-in-JS’in dezavantajı, runtime’da stil enjeksiyonu maliyeti ve SSR (sunucu tarafı render) ile entegrasyonda ek karmaşıklık getirebilmesidir.
SCSS, büyük ve nispeten statik design system’lerde derleme zamanlı (build-time) bir çözüm olarak daha öngörülebilir performans sağlar.

Data-yoğun ekranlarda responsive tasarım nasıl ele alınır?

CSS Container Query’ler, klasik media query’lerin aksine bir component’in kendi konteynerinin genişliğine göre stil almasını sağlar.
Bu yapı, component bazlı responsive tasarımda önemli bir avantaj sunar.
Tablo veya grafik gibi veri-yoğun ekranlarda mobil görünümde kartlara dönüştürme kullanılabilir.
Kontrollü yatay kaydırma da veri yoğun tablolarda alternatif bir strateji olarak uygulanır.

Büyük bir ekipte CSS specificity ve cascade çakışmaları nasıl önlenir?

BEM metodolojisi, sınıf isimlendirmesini standartlaştırarak çakışma riskini azaltır.
CSS Modules, stilleri component bazında izole eder.
Utility-first (Tailwind) yaklaşımı, tekil ve öngörülebilir sınıflarla specificity sorunlarını büyük ölçüde ortadan kaldırır.
!important kullanımı, specificity sorununu çözmek yerine ertelediği için son çare olarak görülmelidir.

7. Performans Optimizasyonu

İlk yükleme (initial load) performansı nasıl iyileştirilir?

Route bazlı code splitting (React.lazy ve Suspense) ile ilk yüklenen bundle küçültülür.
Bundle analiz araçlarıyla (webpack-bundle-analyzer, vite-plugin-visualizer) gereksiz büyük bağımlılıklar tespit edilir.
Tree-shaking ile kullanılmayan kod bundle’dan çıkarılır.
Kritik CSS öne alınır, font ve resim yükleme stratejileri (font-display: swap, lazy loading, modern görsel formatları) uygulanır.
Ölçüm için Lighthouse ve Core Web Vitals metrikleri (LCP, INP, CLS) kullanılır.

Binlerce satırlık bir liste veya tabloda performans nasıl korunur?

Virtualization (react-window, react-virtualized, TanStack Virtual) yalnızca görünür alandaki (viewport) elemanların DOM’a render edilmesini sağlar.
Görünür alan dışındaki elemanlar DOM’da tutulmaz, bu da render maliyetini büyük ölçüde azaltır.
Pagination veya infinite scroll, virtualization’a alternatif veya tamamlayıcı bir yaklaşım olarak kullanılabilir.
Hangi yöntemin seçileceği veri hacmine ve kullanıcı davranışına göre değişir.

useMemo ve useCallback her yerde kullanılmalı mıdır?

Hayır; memoization’ın kendisi de bir hesaplama ve bellek maliyeti taşır.
Gereksiz kullanım kod karmaşıklığını artırır.
Gerçek performans kazancı çoğu zaman ölçülemeyecek kadar küçük kalır.
Optimizasyon, Profiler ile ölçüm yapılmadan, varsayım üzerine değil somut veriyle uygulanmalıdır.

Memory leak nasıl tespit edilir, en sık görülen sebepler nelerdir?

Chrome DevTools’un Memory sekmesinde heap snapshot karşılaştırmaları ile bellek sızıntısı tespit edilir.
En sık görülen sebep, useEffect içinde temizlenmeyen event listener, subscription veya timer’lardır.
Bir diğer sık sebep, unmount olmuş bir component’te state güncellemeye çalışılmasıdır.
Cleanup fonksiyonlarının her useEffect‘te dikkatle yazılması bu sorunların çoğunu önler.

8. Test Süreçleri

Bir component için hangi test seviyeleri yazılır?

Test piramidi mantığında çok sayıda hızlı çalışan unit test bulunur.
Orta düzeyde integration test, component’lerin birlikte çalışmasını doğrular.
Az sayıda ama kritik kullanıcı akışlarını kapsayan e2e test (Cypress, Playwright) en üstte yer alır.
React Testing Library felsefesi, implementasyon detayını değil kullanıcının gördüğü ve etkileşime girdiği davranışı test etmeyi önceliklendirir.

Bug fix sürecinde test yazma alışkanlığı nasıl işler?

Önce hatayı yeniden üreten (reproduce eden) başarısız bir test yazılır.
Ardından kod düzeltilir ve test yeşile döner.
Bu yaklaşım, aynı hatanın gelecekte tekrar oluşmasını (regression) test suite’i kırmızıya düşürerek erken tespit eder.

API çağrıları test edilirken mocking nasıl yapılır?

MSW (Mock Service Worker) gibi araçlar network katmanını mocklar.
Bu yaklaşım, doğrudan modül seviyesinde mocklamaya (jest.mock) göre genellikle daha gerçekçi test ortamı sağlar.
Gerçek network isteği atılmadığı için testler hızlı ve deterministik kalır.
Bakımı, iç implementasyon değiştiğinde daha az kırılgan olduğu için genellikle daha kolaydır.

9. Git ve Takım Süreçleri

Hangi branching stratejisi tercih edilir, neden?

Trunk-based development, feature flag kullanımıyla birlikte, sık deploy edilen ve CI/CD’ye dayanan projelerde daha hızlı geri bildirim döngüsü sağlar.
Git-flow gibi daha ağır stratejiler, sürüm bazlı ve daha az sık deploy edilen projelerde tercih edilebilir.
Seçim, ekibin release sıklığına ve otomasyon seviyesine göre yapılır.

Karmaşık merge conflict’ler nasıl çözülür, rebase mi merge mi tercih edilir?

Rebase, temiz ve lineer bir commit geçmişi sağlar.
Rebase’in riski, paylaşılan branch’lerde force push gerektirmesidir.
Merge, geçmişi olduğu gibi korur ama karmaşık bir commit grafiği oluşturabilir.
Tercih, ekibin branch stratejisine ve branch’in paylaşılıp paylaşılmadığına göre değişir.

Code review sırasında nelere dikkat edilir?

Kodun çalışıp çalışmadığının ötesinde okunabilirlik değerlendirilir.
İsimlendirmenin anlamlı ve tutarlı olup olmadığına bakılır.
Ele alınmamış edge case’ler kontrol edilir.
Gereksiz re-render riski ve erişilebilirlik (a11y) gibi noktalar incelenir.
Geri bildirim yapıcı ve öğretici bir dille verilir.

10. Mimari ve Sistem Tasarımı

Kurumsal ölçekli bir SaaS ürününde frontend mimarisi kurulurken hangi kararlar en başta netleştirilir?

Monorepo mu multi-repo mu kullanılacağı belirlenir.
Mikro-frontend mi tek bir SPA mı tercih edileceği kararlaştırılır.
State management stratejisi netleştirilir.
Uçtan uca tip güvenliği (örneğin OpenAPI’den otomatik tip üretimi) planlanır.
Design system’in nerede barındırılacağı, CI/CD pipeline’ı ve feature flag altyapısı erken aşamada tanımlanır.
Bu kararlar ekip büyüklüğü, release sıklığı ve ürünün büyüme hızı gibi iş bağlamına göre şekillenir.

Mikro-frontend mimarisinin avantaj ve dezavantajları nelerdir?

Avantajı, bağımsız deploy imkânı sağlamasıdır.
Ekipler arası izolasyon sağlar, her ekip kendi hızında çalışabilir.
Farklı teknoloji seçimi esnekliği sunar.
Dezavantajı, artan bundle boyutudur (aynı kütüphanenin birden fazla mikro-frontend’de tekrarlanması).
Paylaşılan state ve tasarım tutarlılığının sağlanması zorlaşır.
Operasyonel karmaşıklık artar (deploy, izleme, versiyon uyumluluğu).
Küçük veya orta ölçekli, tek bir ekibin çalıştığı projelerde iyi organize edilmiş tek bir SPA genellikle daha az sürtünme yaratır.
Mikro-frontend, çok sayıda bağımsız ekip söz konusu olduğunda anlamlı hale gelir.

Legacy bir kod tabanı kademeli olarak modern mimariye nasıl taşınır?

Strangler fig pattern’i, yeni özelliklerin yeni mimaride yazılmasını önerir.
Eski sistem kademeli olarak çevrelenir, tek seferlik büyük bir yeniden yazım (big-bang rewrite) riskinden kaçınılır.
Kritik akışların önceliklendirilmesi risk yönetiminin bir parçasıdır.
Geri dönüş (rollback) planı önceden hazırlanır.
Feature flag ile kademeli açılış, riski kontrol altında tutar.

Gereksinimler belirsizken frontend tarafında nasıl ilerlenir?

Değişme olasılığı yüksek kısımlar bir soyutlama (abstraction) katmanı arkasına alınır.
Kesinleşmiş kısımlarda doğrudan ilerlenir.
Aşırı erken soyutlama da kendi başına bir risktir, bu yüzden belirsizliğin boyutuna göre denge kurulmalıdır.
Varsayımların ürün ve backend ekibiyle netleştirilmesi önemlidir.
Kısa bir teknik doküman veya RFC ile ilerlenmesi, belirsizliği azaltan bir pratiktir.

Erişilebilirlik (a11y) bir component tasarlanırken nasıl baştan dahil edilir?

Semantic HTML kullanımı temel gerekliliktir.
Klavye ile tam navigasyon imkânı sağlanmalıdır.
ARIA rolleri doğru ve gereksiz olmayacak şekilde kullanılmalıdır.
Yeterli renk kontrastı ve screen reader uyumluluğu gözetilmelidir.
Erişilebilirliğin design system seviyesinde (Button, Modal, Dropdown gibi primitive component’lerde) baştan garanti altına alınması, her feature’da ayrı ayrı düşünülmesinden daha verimlidir.

11. Yapay Zeka Destekli Geliştirme

AI destekli geliştirme araçları günlük iş akışında nasıl kullanılır, hangi noktalarda güvenilir, hangi noktalarda güvenilmez?

AI araçları boilerplate kod üretimi, tekrarlayan kod kalıpları, test iskeleti oluşturma ve dokümantasyon taslağı gibi işlerde hız kazandırır.
Mimari kararlar, güvenlik açısından kritik kod ve performans-kritik hesaplamalar gibi noktalarda önerilen kod satır satır incelenmelidir.
Kör güvenle kabul edilmemesi gerektiği, senior seviyenin ayırt edici noktasıdır.
Üretilen kodun proje konvansiyonlarına uyup uymadığı kontrol edilmelidir.
Edge case’leri kapsayıp kapsamadığı değerlendirilmelidir.
Güvenlik açığı (XSS, injection gibi) barındırıp barındırmadığı kontrol edilmelidir.

Üretilen kodun neden çalıştığı anlaşılmadan production’a alınması ne gibi riskler taşır?

Anlaşılmadan kabul edilen kod, ileride bakım (maintenance) sırasında kimsenin tam olarak neden o şekilde yazıldığını bilmediği bir teknik borç yaratır.
Hatalı ya da yetersiz edge case yönetimi geç fark edilir.
Güvenlik açıkları ve performans sorunları da geç fark edilir.
Kodun sorumluluğu, onu yazan veya kabul eden geliştiriciye aittir; bu nedenle AI çıktısı da diğer kod parçaları gibi anlaşılmalı ve gerekirse test edilmelidir.

AI araçları olmadan da yeterli seviyede kod yazılabildiği nasıl gösterilir?

Bu, temel React/JavaScript/TypeScript bilgisinin gerçek ve içselleştirilmiş olmasıyla ilgilidir.
Algoritma ve problem çözme pratiğinin sağlam olması gerekir.
AI aracı olmadan bir component’i, bir fonksiyonu veya bir algoritmayı sıfırdan, mantığını açıklayarak yazabilmek bu yeterliliğin göstergesidir.

12. SaaS/Enterprise, Dashboard, Storybook, Monorepo, Node.js

Enterprise ürünlerde (çok kullanıcılı, rol bazlı yetkilendirmeli sistemler) frontend tarafında ne gibi zorluklar yaşanır?

Role-based access control (RBAC), buton/menü görünürlüğü ve route guard’lar seviyesinde yönetilir.
Çok kiracılı (multi-tenant) yapılarda tema ve marka özelleştirmesi ayrı bir katman gerektirir.
Büyük veri setlerinin (tablolar, raporlar) performanslı gösterimi ayrı bir mühendislik problemi olarak ele alınır.
Farklı kullanıcı rollerinin aynı ekranda farklı davranışlar görmesi, state ve component tasarımını doğrudan etkiler.

Bir admin panel/dashboard tasarlanırken kullanıcı deneyimi açısından nelere dikkat edilir?

Bilgi hiyerarşisinin netliği önceliklendirilir.
Karmaşık formlar adım adım (wizard) veya bölümlere ayrılarak sunulur.
Toplu seçim ve toplu işlem (bulk action) imkânları sağlanır.
Geri alma (undo) mekanizmaları kritik aksiyonlarda kullanıcıyı korur.
Loading/empty/error state’lerinin ekranlar arasında tutarlı tasarlanması gerekir.

Storybook, component galerisinin ötesinde nasıl kullanılır?

Interaction testleri (play function) ile component davranışları otomatik test edilebilir.
Chromatic gibi araçlarla visual regression testing (görsel değişikliklerin otomatik tespiti) entegre edilebilir.
Tasarımcıların component durumlarını (state) inceleyip geri bildirim vermesi için de kullanılabilir.
Dokümantasyon ve component API’lerinin canlı örneklerle gösterilmesi için bir referans kaynağı işlevi görür.

Monorepo mimarisinde paylaşılan kod ile proje-özel kod arasındaki sınır nasıl çizilir?

UI kit, ortak yardımcı fonksiyonlar (utils) ve tip tanımları gibi birden fazla projede kullanılan parçalar paylaşılan paketlere taşınır.
Uygulamaya özgü mantık ilgili proje içinde kalır.
Nx veya Turborepo gibi araçların build cache özelliği tekrar eden build işlemlerini hızlandırır.
“Affected” komutları (yalnızca değişen paketleri build/test etme) geliştirme hızını artırır.

Node.js ekosistemine aşinalık frontend tarafında ne gibi avantaj sağlar?

Next.js gibi SSR/SSG framework’leri Node.js runtime’ı üzerinde çalışır.
Backend-for-Frontend (BFF) pattern’i, frontend’e özel bir API katmanının Node.js ile kurulmasını ifade eder.
Vite ve webpack gibi build tool’ları da Node.js üzerinde işler.
Bu araçların çalışma mantığına aşinalık, build ve performans sorunlarının çözümünde avantaj sağlar.

13. Genel Kültür ve Davranışsal Sorular

Bir projede teknik bir konuda ekip içinde fikir ayrılığına düşüldüğünde nasıl bir yol izlenir?

Pozisyon somut verilerle veya örneklerle savunulur.
Karşı görüş dikkatle dinlenir.
Ortak bir karara varılmaya çalışılır.
Ortak karara varılamadığı durumlarda, kararı netleştirmek üzere ilgili sorumlu kişiyle (tech lead, mimari sahibi) birlikte “disagree and commit” (fikir ayrılığına rağmen alınan karara bağlı kalma) prensibi uygulanabilir.

Bir deadline’a yetişilemeyeceği fark edildiğinde nasıl davranılır?

Durum mümkün olan en erken aşamada ilgili kişilere bildirilir.
Kapsam daraltma (scope cutting) önerisi sunulur.
Kalan işler önceliklendirilir.
Şeffaf iletişim, sürprizlerin önüne geçer ve güven ilişkisini korur.

Yeni bir teknoloji veya kütüphane öğrenme süreci nasıl işler?

Yeni bir araç önce küçük ölçekli bir problemde denenir.
Resmi dokümantasyon ve topluluk pratikleri incelenir.
Ardından gerçek bir iş akışına dahil edilip edilmeyeceğine karar verilir.
Kararın gerekçesi (performans, bakım kolaylığı, ekip uyumu gibi) net şekilde ortaya konur.

14. Muhtemel Pratik Değerlendirme Konuları

İlanın “gerçek coding becerileri” vurgusuna göre, mülakat sürecinde bir canlı kodlama veya kod inceleme (code review) egzersizi yer alabilir. Hazırlık için aşağıdaki konular pratik edilmelidir:

Array ve obje manipülasyonu, debounce/throttle fonksiyonunu kütüphane kullanmadan sıfırdan yazabilme.
Bir arama (autocomplete/search) component’ini debounce, API çağrısı, loading/error state ve klavye navigasyonu ile sıfırdan yazabilme.
Kötü yazılmış (gereksiz re-render’lı, prop drilling’li, karmaşık state’li) bir component’i okuyup adım adım refactor edebilme.
Basit bir event emitter veya pub/sub yapısını sıfırdan yazabilme.
Bir array’i belirli bir kritere göre gruplama, sıralama ve normalize etme gibi klasik veri dönüştürme problemlerini hızlı çözebilme.

15. Adayın Mülakat Sonunda Sorabileceği Sorular

Frontend ekibinde mimari kararlar nasıl alınıyor, teknik tasarım dokümanı (RFC) süreci var mı?
Kullanılan state management ve design system yaklaşımı nedir?
AI destekli geliştirme araçlarının kullanımına dair bir ekip politikası var mı?
Frontend ile backend/ürün ekipleri arasındaki iş birliği süreci nasıl işliyor?
Bu pozisyonda ilk aylarda beklenen somut katkı nedir?

İş bulma süreçlerinin bu kadar zorlaştığı bu dönemlerde umarım herkes ihtiyacı olanı en kısa sürede bulabilir. Projelerimi incelemek istersen de https://hub.barisgunduz.com/ adresini ziyaret edebilirsin.