Silikon Vadisi'nde Çalışmak İsteyen Yazılımcıların Soru Bankası: LeetCode
yazılımcı arkadaşların, üniversite seçme sınavına çalışır gibi çalışmasını tavsiye ettiğim soru bankalarından biridir leetcode.
veteran bir leetcoder olarak, leetcode'a minik bir giriş rehberi yazalım. baştan söyleyeyim; ingilizce ile sorunum var diyorsanız algoritma sorularına ayıracağınız zaman kadar ingilizceye de ayırın çünkü cızırtılı kalitesiz telefon/internet görüşmelerinde size bu soruları hint aksanıyla konuşan bir bangladeş'linin sorma ihtimali bir native ile görüşmenizden binlerce kat daha fazla olacak. bu nedenle bu entry ingilizce teknik terimlerle dolu olacak efendiler.
altın kuralı baştan söylüyorum:
1. önce soruyu çözün
2. sonra ben bunu daha iyi nasıl yaparım diye düşünün
bugün amazon ile de görüşmeye girseniz, on kişilik bir start-up ile de görüşmeye girseniz iş görüşmeniz bu iki kural üzerinden ilerleyecek. bu değişmez. şimdi bu iki kuralın ne olduğuna değinelim.
soruyu çözmek
"when in doubt, use brute force." - ken thompson
soruya baktınız aklınıza hemen bir çözüm gelmedi ve/veya ilk çözüm brute force oldu. bu şekilde önce bir base case oluşturmuş oluyorsunuz, iş görüşmelerinde de kritik nokta budur. karşınızdaki insan sizin aklınıza brute force yönteminin bile gelmediğini düşünmesin. kısaca her olasılığı deneyen kodu bir yazın, öz güveniniz artsın. (iş görüşmelerinde bazen bu kısım sözlü ifade edilerek de geçilebiliyor, o da olumlu).
soruyu bu şekilde çözmek ancak ve ancak kod yazabildiğinizi gösterecektir yani başarı için yeter koşul için soruyu daha güzel çözebiliyor olmanız gerekiyor.
soruyu daha güzel nasıl çözmek
bunun anlamı, sorudaki her bilgi kırıntısını sonuna kadar kullanarak yapılabilecek en verimli çözümü bulmak. verim ölçütü bilgisayar bilimlerinde (bkz: big-o notation) ile ölçülür. yani kodu yazarken computational complexity ile memory complexity kavramlarını artık şakkadanak anlayacak kadar verimli yazabilmeniz lazım. bu ikisinin de optimum olması idealdir ama çoğu zaman bu iki kavram arasında bir trade off yaparken bulacaksınız kendinizi.
algoritma sorularını çözmeye yeni başlayanlar başlarda bunun için kendi başlarına çok kasmasınlar çünkü bu, zamanla sindirerek öğrenilen bir teknik. tabi ki soruların çözümlerine bakmadan önce yeterli derecede kendinizi zorladığınızdan emin olun, sonrasında ise cevapları içselleştirerek okuyabilirsiniz. asla ama asla çözümü kopyalayıp yapıştırıp submit etmeyin çünkü eğer anladıysanız sıfırdan yazabilirsiniz, yazamıyorsanız anlamamışsınızdır. 10 yıllık yazılımcılar bile eğer bu işe yeni başlıyorsa hemen en verimli kodları yazamıyorlar. bu iş tamamen bol soru bol pratik ve zinde kalmayla alakalı.
bir süre sonra easy soruları öyle ya da böyle çözebiliyorsanız ve biraz da alışkanlık kazandıysanız, güzel bir zamanı da ben bu soruyu daha verimli nasıl çözerime harcayın. adında kolay geçmesine bakmayın sorulan interview sorularının bir kısmı buradan geliyor, mesele soruyu çözebilmekte değil zaten asıl mesele o soruyu çözerken gelişen düşünce sürecinde. yani dostlarım, o(n) computational + o(n) memory complexity ile çözdüğünüz soruyu bazen sizden "pekiiiğ biz bunu memory efficient çözmek istersek nasıl yaparız?" diye rica ettiklerinde sorunun sadece n*log(n) computational complexity ile de çözebilmek sizi bir anda seattle uçağına bindirebilir.
easy - medium - hard
diyelim ki artık easy soruları çözebiliyorsunuz, hepsini olmasa da çoğunu güzel çözebiliyorsunuz. işte tam bu zamanda medium sorulara geçmeniz gerekiyor. bu ikisi arasındaki temel fark şu: easy sorular genelde tekdüze bir düşünce şekli ile çözülebiliyor yani yakalamanız gereken asıl nokta bir tane oluyor çoğunlukla, onu yakaladığınız anda da soruyu çözmüş oluyorsunuz. buna daha çok veri yapılarına olan hakimiyeti sağlamlaştırma diyebiliriz. medium sorular ise asıl karşılaşacağınız soru tipleri, asıl noktayı(kaba yöntem, kullanılacak veri yapısı) yakaladıktan sonra biraz daha detaylı düşünüp birkaç aşamayı bulmanızı gerektiriyor. çoğu zaman easy sorular gibi bakar bakmaz kafanızda cevap şekillenmez bu sorularda. bazen sadece çözümü bulabilmeniz bile uzun zaman alabilir.
hard sorular ise adı üstünde zor, kolay çözülmemesi üzerine tasarlanmış sorular. bu soruları da soruyorlar iş görüşmelerinde lakin sorunun tamamını 45 dkikada çözmenizi beklemiyorlar, rehavete kapılmayın yine de ilerlemiş olmanız gerekiyor. bu soruları hakkıyla çözebilmek, her gün ayrılan birkaç saat ile bazen günler sürebilir bu nedenle yeni başlayan ya da orta şeker takılan arkadaşlar olarak bunlardan uzak duruyoruz bir süre. hobi amaçlı bakabiliriz ama öz güveniniz kırılmasın.
özet ve ek önemli tavsiyeler
- soru, kağıt üzerinde çözülür, kod en son yazılır. kağıt kalemsiz sorulara girişmemeye çalışın. hatta kodu önce kağıda yazmaya alışırsanız karada size ölüm yok.
- soruyla yeterince uğraşmadan cevaplara bakmamak çok kritik, beynin bu pratiği yapması şart. cevabına bakılan soruyu da içselleştirip baştan elle çözüyoruz. en kritik nokta ise bu sorulara en az 3 gün sonra sıfırdan tekrar bakıyoruz.
- recursion, dynamic programming, graph soruları farkı belirleyen konular. özel çabanızı bunlara ayırın derim.
- her soruyu her zaman çözebilmek kimse için mümkün değil. dolayısıyla moral bozmak yok yola devam.
- günde en az 1-2 soru çözme alışkanlığını edinirseniz 7/24 interview'a hazırlıklı bir bordo bereli olabilirsiniz.
son olarak, yeni başlayanlar ve uzun süredir bu işle uğramayanlar için güzel bir başlangıç olabileceğini düşündüğüm ve bir facebook mühendisi tarafından hazırlanmış şu liste harika bir başlangıç olacaktır.
Bir Yazılım Mühendisi İçin Almanya ve ABD'nin Çalışma Koşulları Kıyaslaması
