Yazılım Mülakatlarında En İyi Performansı Göstermenin 3 Adımı

Neden Sistemli Hazırlık Önemlidir?

Bir üretim ERP’sinde bir mülakat sorusu yanıtlayamadığımda, aklıma gelen tek şey “derinlemesine bir hazırlık eksikliği” oldu. O an, bir sonraki fırsatta aynı hatayı tekrarlamamak için hazırlık sürecimi yeniden yapılandırmaya karar verdim. Sistemli bir hazırlık, sadece sorulara hâlihazırda bir cevap bulmak değil, aynı zamanda zihin haritasını netleştirerek stres seviyesini düşürmek anlamına gelir.

Hazırlık aşamasında not aldığım en kritik veri, “sorunun köküne inmek” idi. Örneğin, bir “deadlock” sorusuna yanıt verirken, sadece “PostgreSQL” demek yerine, SELECT pg_blocking_pids(pid) FROM pg_locks WHERE NOT granted; komutunun çıktısını incelemek gerektiğini fark ettim. Bu detay, sorunun teknik yönünü göstermekle kalmaz, aynı zamanda “gerçek dünyada nasıl izlenir?” sorusuna da hazır bir yanıt sunar.

Adım 1: Sistemli Problem Çözümleme

Mülakatlarda en çok karşılaştığım “performans darboğazı” soruları, problem çözümleme becerilerini ölçmek için kullanılır. İlk adım, sorunu tanımlamaktır: “Uygulama yavaşlıyor, ancak nerede?” Bu soruya cevap bulmak için htop çıktısını doğrudan paylaşmak etkili bir kanıt olur. Örneğin:

$ htop -d 5
PID   USER      PRI  NI  VIRT   RES   SHR S  %CPU %MEM    TIME+  Command
1234  www-data  20   0  1.2G  150M  10M  S   45.0  3.2   00:12.34 python app.py

Bu çıktı, CPU kullanımının yüksek olduğunu gösterir ve “CPU bound” bir problemi işaret eder. Ardından, strace -c -p 1234 komutunu çalıştırarak sistem çağrılarının dağılımını inceleyebiliriz. Çıktıdaki read ve write oranları, I/O sınırlı bir sorunu işaret ediyorsa, çözüm stratejimiz farklı olur.

Problem çözümlemesinde sıkça gözden kaçan bir nokta, “yanlış varsayım”dır. Örneğin, “veritabanı yavaş” diyerek hemen bir indeks eklemek, gerçek sorun bir network gecikmesi olduğunda çözüm olmaz. Bu yüzden, her adımda “çözümüm neden bu sorunu çözüyor?” sorusunu sormak kritik.

Adım 2: İletişim ve Algoritma Düşüncesi

Mülakat sırasında soruyu anladıysen bile, düşünce sürecini paylaşmadan doğrudan kod yazmak, iletişim eksikliği yaratır. Ben bir soruyu “iki yönlü tarama” yöntemiyle çözerim: önce problemi sözel olarak özetler, ardından algoritmik adımları bir kağıda çizerim. Bu yaklaşım, mülakatörün beklentisini netleştirir ve “benim aklımda ne var?” sorusuna cevap verir.

Algoritma aşamasında, zaman karmaşıklığını hemen düşünmek gerekir. Örneğin, bir “kuyruk” problemi için deque kullanmak, list.append ve list.pop(0) yerine O(1) performans sağlar. Bu farkı göstermek için aşağıdaki Python kodunu ve çıktısını paylaşırım:

from collections import deque
q = deque()
for i in range(1000):
    q.append(i)
print(q.popleft())

0

Bu basit örnek, algoritmanın amortize O(1) olduğu kanıtını verir. Ayrıca, “rekürsif” bir çözümün stack overflow riskini değerlendirirken, sys.getrecursionlimit() çıktısını göstererek sınırları netleştiririm. Böyle bir şeffaflık, mülakatörün güvenini artırır.

Adım 3: Kod Üzerinde Pratik ve Optimize Etme

Kod yazarken “çalışan bir şey” yeterli değildir; kodun okunabilirliği, test edilebilirliği ve performansı da aynı derecede önemlidir. Ben bir sorunu çözerken, önce “ilk çalışan versiyon”u yazar, ardından unit test eklerim. Örneğin, pytest -q çıktısını paylaşmak, testlerin geçerli olduğunu gösterir:

$ pytest -q
..                                                                       [100%]
2 passed in 0.04s

Bu aşamadan sonra, profil oluşturmak için python -m cProfile -s time script.py komutunu çalıştırırım. Çıktıdaki “tottime” değerleri, en zaman alan fonksiyonları gösterir ve optimize edilmesi gereken noktaları netleştirir. Örneğin, bir for döngüsü %30 daha yavaş çalışıyorsa, list comprehension veya map ile iyileştirme yapılabilir.

Optimizasyon sırasında sıkça yapılan bir hata, “premature optimization” yani erken optimizasyon. Ben önce fonksiyonel doğru çalıştığından emin olur, ardından sadece gerçekten darboğaz olan kısmı iyileştiririm. Bu yaklaşım, zaman kaybını azaltır ve mülakat süresini verimli kullanmamı sağlar.

Sık Karşılaşılan Hata ve Çözüm Örnekleri

Geçen yıl bir fintech mülakatında, “socket timeout” hatasıyla karşılaştım. socket.recv(1024) komutunun hemen ardından gelen TimeoutError mesajı, sorunun ağ katmanında olduğunu gösterdi. İlk tepkim, “retry” eklemekti, ancak bu sadece sorununu geçici olarak gizledi. Sorunu kökten çözmek için socket.settimeout(5) ile timeout süresini ayarladım ve ardından select.select ile okunabilirliği kontrol ettim. Bu iki adım, sorunun tekrar etmemesini sağladı.

Bir başka örnek, “memory leak” şikayetleriyle karşılaştığım bir yazılım mülakatında, ps aux | grep myapp çıktısında sürekli artan RSS (Resident Set Size) gördüm. tracemalloc modülünü etkinleştirerek, en çok bellek tüketen fonksiyonları listeledim ve gereksiz global değişkenleri yerel değişkenle değiştirdim. Sonuçta, bellek kullanımında belirgin bir düşüş gözlemledim ve bu iyileşmeyi top çıktısıyla belgeledim.

Mülakat Akışını Görselleştirme

graph TD; A["Hazirlik"] --> B["Problem Cozumleme"] --> C["Algoritma Tasarimi"] --> D["Kod Yazma"] --> E["Test ve Optimizasyon"] --> F["Geri Bildirim"]

Bu diyagram, üç adımın birbirine nasıl bağlandığını ve sürecin tekrarlı doğasını gösterir. Her bir aşama, bir öncekinin çıktısını alır ve bir sonraki adım için girdiyi oluşturur. Bu görsel, mülakat sırasında adımları hatırlamak için faydalı bir referans olur.

Sonuc

Mülakatlarda en iyi performansı göstermek, rastgele bir kod parçası sunmaktan çok daha kapsamlı bir yaklaşım gerektirir. Hazırlık, sistemli problem çözümleme, iletişim odaklı algoritma tasarımı ve kodun test edilip optimize edilmesi, başarının üç temel adımıdır. Bu adımları gerçek dünyadaki örneklerle pekiştirerek uyguladığınızda, sadece soruyu cevaplamakla kalmaz, aynı zamanda mülakatörün beyninde kalıcı bir izlenim bırakırsınız.

Net pozisyonum: Mülakat sürecini bir “mini proje” gibi ele alıp, her adımı belgeli ve kanıtlı bir şekilde sunmak, en güvenilir yol. Bir sonraki yazıda, “technical leadership” sorularına nasıl yanıt verilir, onu anlatacağım.