Spring security in action, spring Start Here, How to Read Java gibi kitaplarının yazarı Laurentiu Spilca'nın hazırlamış olduğu Spring Reactive derslerini aşağıdaki linklerden izleyebilirsiniz.
Yazılım Dünyasında Liderlik - JUG-Gökalp Gürbüzer (Video)
"Sene olmuş 2022. Artık bir takım içinde çalışmayan yazılımcı kaldı mı? Çoğu yazılım takımının bir lideri olsa da kimi liderlik yetilerinin, takımın bütün üyeleri tarafından anlaşılmış VE uygulanıyor olması herkese büyük katkı sağlıyor. Diğer bir deyişle, takımın lideri olmasanız da takımın güdülmesine katkınız olması gerekiyor.
Bu konuşmada liderlik konusundaki ortak ve temel bazı konulara değindik; ama bunu bir yazılım takımı ortamında anlattık. Yani sadece yazılım geliştiriciler değil, sosyal bir ortamda çalışan herkesin (ya da istatistiksel olarak bütün çalışanların %101’i) kendine faydalı bulacağı bir şey çıkabilir; ama baştan söyleyelim, dilimiz ve örneklerimiz size biraz ‘nerdy’ gelirse gücenmece yok; sonuçta yazılım geliştiricisiyiz. Başlıklar Yazılım geliştirme takımları - kısa tipoloji ve tarihçe Genel kariyer yolları Liderlerin rolü Lider nasıl tanımlamalı? Lider vs Yönetici - hala var mı böyle bir şey? Sen bu mu olmalısın? Liderlerin emrindeki (kimi) araç ve teknikler Sıfırıncı kural: İletişim, etkili olanından Mikro yönetim Fikir hocalığı Öğretim Delegasyon Talep ve Ricalar Triadlar Bire-bir toplantılar Günlük toplantılar Retrospektifler Ayrıcalıklar Etkinlikler Son soru - sen nasıl yönetiliyorsun? Gökalp Gürbüzer Kimdir? 2006'dan beri aktif olarak kod kodlayıp bug debug'layan Gökalp, 2016'dan beri yine yazılım dünyasında ulusal ve uluslararası şirketlerde teknik ve insani yönetim yapmaktadır. En sevdiği yazılım geliştirme platformu Java, en sevdiği spor basketboldur. Twitter : https://twitter.com/ajitatifGithub : https://github.com/ajitatif"
Canburak Tümer - Yazılımda Kırık Camlar Teorisi
https://medium.com/@canburaktumer/yaz%C4%B1l%C4%B1mda-k%C4%B1r%C4%B1k-camlar-625d7f676cab
Kırık Camlar teorisi wikipedia alıntısı :
"Birkaç kırık penceresi olan bir bina düşünün. Camlar tamir edilmemişse vandallar birkaç cam daha kırmaya meyillidir. Sonunda bina boş ise tüm camları kırılabilir, gecekonduysa belki de yangın dahi çıkarabilirler. Ya da bir kaldırım düşünün. Burada bazı çöpler birikir. Yakın zamanda bu çöpler daha fazla birikir. Sonunda buradaki restoranlar, hatta paket servis yapan insanlar bile çöpleri araba ile poşetler halinde getirerek buraya atarlar."
Hüseyin Babal - Microservices Patterns Kitabı Okuma Seansları (Video)- Türkçe
Hüseyin Babal Yotutube kanalında Chris Richardson'un Microservices Patterns kitabını okuyor ve yorumluyor.
Kitabı buradan temin edebilirsinsiniz.
1-[TR] Reading Microservices Patterns | Introduction, Scale Cube, Hexagonal Architecture
2-[TR] Reading Microservices Patterns | Microservices Architecture Challenges
3-[TR] Reading Microservices Patterns | Decomposition Strategies
4-[TR] Reading Microservices Patterns | Business Capabilities
5-[TR] Reading Microservices Patterns | Message Formats, Sync/Async Communication
6-[TR] Reading Microservices Patterns | Async Communication with Message Brokers
7-[TR] Reading Microservices Patterns | Transactional Messaging
8-[TR] Reading Microservices Patterns - | ACID, Isolation in Microservices
9-[TR] Reading Microservices Patterns | Designing Business Logic, Aggregates
10-[TR] Reading Microservices Patterns | Domain Events Publishing
11-[TR] Reading Microservices Patterns | Event Sourcing
12-[TR] Reading Microservices Patterns | Implementing Event Sourcing
13-[TR] Reading Microservices Patterns | Aggregates & Event Source Implementation
14-[TR] Reading Microservices Patterns | Idempodent Consumers, Saga with Event Sourcing
15-[TR] Reading Microservices Patterns | CQRS
16-Introduction, Unit Test, Integration Test, Contract Tests
Ninja Geliştiricisi kimdir? blog.softtek.com çevirisi
Ninja Geliştiricisi kimdir?
Ninjalar veya Shinobi (Japonca), Japonya'da geleneksel olmayan savaş biçimlerinde eğitilmiş bir askeri birlikti. Bugün, bu eski terim, bir tür özel yazılım geliştiricisi için kullanılmaktadır: Ninja Geliştiricisi.
Teknoloji Stack
Teknoloji stack, belirli bir dizi sorunu çözmek için birlikte çalışan bir teknoloji grubudur. Normalde, ön uç (istemci tarafı), arka uç (sunucu tarafı), veritabanı ve işletim sistemi gibi farklı uygulama katmanları içinde geliştirmeye yönelik programlama dilleri ve çerçevelerden oluşur.
İşte bazı teknoloji yığınları örnekleri:LAMP yığını (Linux, Apache, MySql, PHP)
LEMP (Linux, Nginx, MySql, PHP)
MEAN (Mongo, Ekspres, Açısal, Düğüm)
ELK (ElasticSearch, Logstash, Kibana)
Full Stack Geliştiriciler
Full stack geliştirici, bilinen bir teknoloji yığınına yakından aşinadır ve o yığına özgü teknolojileri kullanarak katmanlarından herhangi birinde programlayabilir.
Neden Ninja Geliştiricileri olarak adlandırılıyorlar?
Ninja Geliştiricileri kendilerini yalnızca bir programlama dili veya bir teknoloji yığını ile sınırlamazlar; onlar 'geliştirici çok dilli'lerdir.
Ninja, belirli bir programlama dilinde uzmandır, ancak başka herhangi bir dili kullanmakta rahattır. Karşılaştıkları teknik zorluk ne olursa olsun çözmek için çeşitli yığınlarda nasıl gezineceklerini biliyorlar.
Ve çok dilli oldukları sürece, Ninja Developers Lisp, Haskell, Scala veya Clojure gibi çeşitli dilleri etkili bir şekilde işleyebilir ve JAVA, Groovy ve C++ gibi statik dillerde uzmanlaşabilir.
Ayrıca JavaScript, Ruby, Python ve PHP gibi dinamik programlama dillerini ustalıkla idare ederler ve ister inanın ister inanmayın, Android, Swift ve Objective-c gibi mobil uygulama geliştirme dillerini bilirler; Lua (c) gibi oyun geliştirme dilleri; Nodejs gibi eşzamansız diller; ve büyük veri projelerinde yaygın olarak kullanılan R gibi istatistiksel modelleme dilleri.
Kalıcı veriler açısından, Ninja Developers NO-SQL (MongoDB, Cassandra, New SQL, vb.) gibi ilişkisel veritabanlarında kolayca gezinebilir. Ve bu yeterli değilse, eldeki sorun için en iyi teknolojiyi seçecek kadar sağlam bir yargıya sahipler.
Çalışma dünyasında Ninja Geliştiricisi
Kuruluşlar, mümkün olan en düşük maaş için en yetenekli profesyonelleri arar, ancak bir Ninja Geliştiricisinin sahip olduğu bilgi türü, dik bir fiyat etiketi ile birlikte gelir. Bunun nedeni, esasen çeşitli teknoloji yığınlarında çalışabilen tam yığın geliştiriciler olmalarıdır - artan talep gören ve çok iyi telafi edilen bir beceri seti!
Ninja Geliştiricisi bir veya iki alanda derin uzmanlıktan ziyade geniş bilgiye sahip olsa da, yukarıda belirtilen beceri setlerinde bilgi edinmek yıllar süren özveri gerektirir. Junior veya Yarı Kıdemli Ninja Geliştiricisi diye bir şey yoktur; ya birsinizdir ya da değilsinizdir… henüz.
Bugün ortalama bir bilgisayar mühendisliği veya MIS öğrencisi bu seviyeye ulaşmak için gerekli bilgi birikimi olmadan mezun oluyor. Ninja Developer olmak için en az 4 yıllık üniversite ve 5-10 yıllık iş başında uygulama bir başlangıçtır.
Bir geliştiriciyseniz ve bir Ninja Geliştiricisi olmak için hala gitmeniz gereken bir yol varsa, endişelenmeyin, işe koyulun!
Bugün 'her şeyi' biliyor olabilirsiniz, ancak bu bilgi iki yıl içinde geçerliliğini yitirecek. Yazılım mesleğinde becerilerinizi geliştirmeye devam etmelisiniz. Sürekli öğrenen biri olmalısınız.
One concept that martial arts experts and good programmers have in common is that economy of effort. Martial arts experts avoid wasted motion; good programmers avoid unnecessary code.
The concept of invisibility translates to transparency in library writing. A good library has an intuitive interface, and you can plug it in and not worry about it.
EDIT: I forgot the most important thing: both ninjas and good programmers are highly skilled as a result of training and practice.
Spotify Mühendislik Kültürü
Spotify bugüne kadar şirket içi organizasyonunu sürekli geliştirmiş ve esnek bir yapı oluşturmuş.
Aşağıdaki videolarda çok iyi bir şekilde anlatmışlar. Benzer yapıyı bizim şirketlerde görmek umuduyla.
Part 1 :
"Bu devam eden bir yolculuktur, tamamlanmış bir yolculuk değildir ve takımdan takıma çok fazla çeşitlilik vardır. Yani videodaki bilgiler her zaman tüm takımlar için doğru değil, ancak çoğu zaman çoğu takım için çoğunlukla doğru görünüyor :o)"
Spotify Engineering Culture - part 1 from Spotify Training & Development on Vimeo.
Part 2 :
"Bu devam eden bir yolculuktur, tamamlanmış bir yolculuk değil, bu nedenle video "Bugün İşler Nasıl" ve "İşlerin Nasıl Olmasını İstiyoruz" arasında bir yerde."
Spotify Engineering Culture - part 2 from Spotify Training & Development on Vimeo.
Seçkin Tozlu - JVM (Java Virtual Machine) nedir? JVM Nasıl Çalışır? Class Dosyalarının Anatomisi
Seçkin Tozlu'nun kendi blogunda yayınladığı JVM ile ilgili yazı dizisine aşaığdaki linklerden ulaşabilirsiniz.
Java Virtual Machine Nedir? :
Google, Facebook, Amazon gibi şirketlerle iş görüşmeleri için hazırlanan Tech Interview Pro'dan çıkardığım özet
-Büyük şirketlerin (google,apple,amazon,facebook vb) interviewleri küçük şirketlerindekilere göre daha tahmin edilebilir ve önceden çalışılabilir oluyor.
-Bazen interviewler çalışacağınız şirketin domaini ile iligi sorular içerebiliyor. Bu sebeple bu domainleri öncesinden araştırmanız size görüşmede fayda sağlayacaktır. Örneğin google mülakatı öncesi web search'in nasıl çalıştığı gibi.
-Şirketlerin size assignment vermesi kendileri için bir fayda sağlayabiliyor. Sizden outsorce hizmeti almış gibi oluyorlar. Bunu kafanıza takmayın, bu işin doğasında var.
-Telefon interviewlerinden kişiler ortalama %25 başarı sağlıyorlar. Ardından yerinde görüşmeye çağrılıyorlar. Yerinde görüşmeden (on-site) baarılı bir şekilde geçiş ve işe başlamaya hak kazanma genelde %10 seviyesinde oluyor.
-Telefon interview'inde görüşmeci sizi görüşmenin başında tanımak istiyor ve geçmişte yaptığınız projelerden bahsetmenizi istiyor. Bu safhada görüşmeci sizin bu interview'den geçip geçmeciğini hemen hemen tahmin edebiliyor. Ardından telefonda online kod mülakatı başlıyor.
-Telefonda online mülakattda yazdığınız kod için temel olarak dört kritere bakılıyor:
1-Kodlama
2-Veri yapıları algoritmalar
3-Dizayn(Big o Analiz gibi, OO design gibi)
4-İletişim
-Teknik açıklamalar yaparken sizden, ne çok basit düzeyde ne de çok complex anlaşılmaz İngilizce konuşmamınızı bekliyorlar.
-Juniorlara genelde kodlama sorulurken, senior ve manager seviyesinde olanlara sistem dizayn, software dizayn, management gibi konularda sorular soruluyor.
-On site görüşmler genel sabah 9'da başlıyor ve akşam 5'e kadar devam ediyor. Öğle yemeği de interview'e dahil. Ekip sizinle tanışıyor ve birlikte çalışıp çalışamıyacağına karar veriyor. Telefon interview'inde de yaşanan bu benzer süreç, sizin agresifi utangaçi dengeli gibi, hangi ruh halinizde olduğunuzu ve iletişiminizi ölçüyorlar.
-Görüşmelerde çok iyi performans gösterseniz bile, şımarık bir yapınız varsa sizi eliyorlar.
-Sonuçta kurumsal bir yerle görüşüyorsunuz. Kurumsal bir şirketin kurumsallığınını eleştiriyorsanız sonuçta o görüşmede olmamalısınız. OOyunu kurallarına göre oynamalı ve baştan kuralları kabul etmelisiniz.
-Herbir görüşmecinin genelde tüm adaylara sorduğu birkaç soru oluyor.
-Görüşmeciler bazen sordukları sorunun cevabını kendileri de bilmiyor. Adayların soruya yaklaşımlarını merak ediyorlar.
-;Startup tarzı şirketlergenelde adaylardan belli teknolojilerde uzman olmalarını bekliyorlar ve sorularını bu teknolojiler üzerinden soruyorlar. Büyük teknolji şirketleri ise genel kavramlardan sorular sorup adayın herhangi bir teknolojiye uyum sağlayıp sağlayamayacaklarını ölüçüyorlar.
-Referans işe girmekte çok etkili. Herşeyi kendiniz ispat etmeye çalışmanız biraz daha zor olacaktır. Bir referansınız varsa kapılar size daha hızlı açılacaktır.
-Referans veren kişinin de sizin üzerinizden ödül alabileceğini unutmayın. Ayrıca şirket de uygun çalışan bulmuş olacak. Sonuçta bu kazan-kazan-kazan ilişkisi oluyor.
-Linkedinden recuierterlar bulup işe yerleşmek de ayrı bir çözüm. Burada önyazı önem kazanıyor. Önyazınızı şirketlerin herbirne özel yazarsanız şansınız daha da artacaktır.
-Önceden yapmış olduğunuz projeler de sizi işe alımda şansınızı artırıyor. Open source projeler de önemli fakat, production ortamında çalışan projelere katkı sağlamanız daha fazla önem arzediyor.
-Gelişigüzel öğrendiğiniz ve projelerde kullanmadığınız programlama dilleri size görüşmede çok fazla katkı sağlamıyor. Bir iki hafta typescript, ruby gibi diller öğrenmeniz çok da önemli değil. Sonuçta işe girer ve ihtiyaç duyarsanız bir dili iki haftada öğrenebilirsiniz.
-Mezun olunca ilk hedefiniz google facebook gibi yerler olmasın. Evet başarabilirsiniz ama şansınız az olacaktır. Onun yerine basamak basamak ilerlemeye çalışın. Girilmesi daha kolay yerlere girip projelerden öğrenebileceğiniz kadar öğrenmeye çalışın.
- Bazen problemleri recurisive yönden bazen iterative yönden çözmek isteyebilirsiniz. Recurisve ile çözerken stack problemlerini düşünmelisiniz.
-Problemleri Java gibi dillerle çözmek, sınıflar ve interfaceler yazmak OOP'ye uygun olabilir. Eğer bu yolla soruları çözüyorsanız bazen complex yardımcı sınıfların var olduğunu sayabilir ve bunu görüşmeciye söyleyebilirsiniz. Şöyle bir sınıfım var ve bana şunları sağlıyor diyip esas problemi çözen sınıfın kodlarını bu varsayımsal sınıfın apisiyle yazabilirsiniz.
-Fakat bu gibi soruların çözümlerinde saf OOP kullanmak yerine fonksiyonel bir şekilde Python gibi dillerle yazmak size ekstra zaman kazandıracaktır.
-Problem çözümü sırasında görüşmeci ile olan iletişiminiz önemlidir. Çünkü bu takım içinde kuracağınız iletişim için ipucu verecektir. Tek başınıza analiz yapıp soruyu çözmeniz iyi bir iletişim için kötü bir yoldur.
-Problemlerin çözümünde time ve space complexity arasında bir seçim çoğu zaman vardır. Görüşmeciye sorular sorarak hangisinin yazdığımız sistem için daha önemli olduğunu sormalıyız. Misal bu işlem kaç milyon kayıt üstünde yürütülecek, tepki süresi en fazla ne kadar olabilir gibi.
-Problemleri farklı data structurelarla ve algoritmalarla çözmek farklı time complexity ve space complexity verecektir. Soruları herhangi bir şekilde çözebilirsiniz. Ama tercihleriniz size farklı sonuçlar verecektir.
-Çözdüğünüz problemin O(N)'ini görüşmeci size sorduğunda tahmin edip bir değer vermemelisiniz. Tahmin yerine kendinizden emişn bir şekilde değeri vermeli ve bu değeri nasıl elde ettiğinizi söylemelisiniz.
-Bilgisayar bilimlerinde genel olarak bilinen algoritmaları bilmeniz size görüşmeler için büyük fayda sağlayacaktır. Sıralama, arama, string işleme algoritmaları gibi. Bu algoritma sorularını leetcode, hackerrank gibi sityeler üzerinde bulup çözebilirsiniz. Yaptığınız çözümler size genel bir görüş sağlayacak ve farklı problem çözümlerinde hızlanmanızda etkili olacaktır.
-Herşeyi Array ile çözmeye çalışmayın. Array problemin çözümlerinde çok önemli olsa da Hasmap, queue, stack de bir o kadar önemlidir. Ayrıca String soruların çözümlerinde trie'ler de çok önemlidir.
-Yapacağınız görüşmeyi interviewer ile yaparsınız. Ama ayrıca bir kurul ve alım müdürü mevcuttur. Eğer interviewr ile kötü ilişkiler kurarsanız diğer ikisinde de kötü etki bırakırsınız.
-Görüşmeci ile yaptıuğınız soru çözümlerinde soruyu biliyorsanız, bilmiyormuş gibi acı çekme numarasına, her detayı tekrar tekrar tekrarlamanıza gerek yoktur. Bu bir nevi rol yapmaktır ve anlaşılabilir. Soruyu biliyorsanız hızlıca çözün ve bitirin.
-Soru çözümlerinde çok fazla detaya ve uç case'lere girmemeye çalışın. Görüşmeci zaten uç noktaları ihtiyaç duyarsa size soracaktır. Herşeyi test etmeye çalışmayın.
-Görüşme sonrası görüşmeci size "son bir sorunuz var mı?" dediğinde, "işinizin en zor kısmı nedir?" gibi olumsuz sorular sormayın. Onun yerine şirketin kullandığı veya piyasada var olan yeni teknolojiler hakkında şirketin görüşleri gibi olumlu sorular sorun.
-Yine görüşme sonrası son sorunuz var mı dendiğinde "Çözümüm iyi miydi?" gibi sorular sormayın.
-On-site görüşmelerde tahtada farklı renkli kalemlerle yazınızı düzeltmeye çalışmayın. Bu size vakit kaybettirecektir. Ayrıca tahtada sol üst köşeden başlayın. Bu şekilde tahtada yeterli alanınız olacaktır.
-CV'inize hakim olun ama CV'nin de her zaman çok detaylı incelenmediğini düşünün ve kenndinizi tanıtma kısmına önem verin. Kibrili olmayan bir şekilde kendinizi ve projelerinizi iyi anlatmaya çalışın. Unutmayın ilk etki ve sörüşme sonu son etki önemlidir.
-CV'inizi her zaman güncel tutmaya çalışın. 2-3 aylık eski CV'lerinizi göndermemeye çalışın.
-CV'nizi bir sayfayı geçirmeyeye çalışın. Aslında burada CV diyorum fakat Amerikada CV için genelde akademik insanların yaptığı yayınları listeleyen 10-15 sayfalık metinler olarak kabul ediyorlar. Amerikada resume kullanmayı tercih ediyorlar.
-Grafiker olmadığınız için CV'nizi renkli ve farklı şekillerle yapmanıza gerek yok.
-Ms Office Word gibi sertfaksyonlarınızı CV'nize eklemyin. eğer 5-10 yıllık mühendis iseniz stajınızı, girdiğiniz hacathlonları CV'nizden silin. Önemli projelerinizi ön plana çıkarmaya çalışın.
-Bildiğiniz teknolojilerin yanına expert-advanced gibi derecelemdirmeler koyun.
-Eğer bir interview'den geçemezseniz sonrası için korkak olmayın. Unutmayın yapabileceğiniz birçok görüşme ve girebilieceğiniz birçok şirket var.
Görüşmeler için en çok yapılan 10 hata :
1- Soru çözme pratiklerinizi sadece leetcode gibi platformlarla bilgisayar üzerinde yapmayın. Gerçek görüşmelerdeki gibi ya tahta kullanın ya da kağıt üstünde de kendinizi deneyin.
2-Davranışsal sorularda ezbere gitmeyin. Bu sohbet yerine sanki biryerden okuyormuş hissi verir. Genel bir kalıp aklınızda olsun ama sohbetin akışını bozmayın. Güzel hikayeler biriktirin ve yeri geldikçe kullanın.
3- Arkadaşlarınızla mock interview yapmamak sizi gerçek görüşmelerde antremansız bırakacaktır. Utanmayıın ve üşenmeyin, arkadaşlarınızla sahte görüşmeler yapın ve ustalaşın.
4-Teknik soru tiplerini ezberlemeyin. Binlerce soru olduğunu unutmayın. Temel veri yapılarını ve problem çözme yollarını kavrayın.
5-Problemleri sessizce görüşmeciyle iletişim kurmadan çözmeyin. Görüşmecinin sizin analizlerinize de puan verdiğini unutmayın. Ayrıca çözerken yanlış bir yola girerseniz, görüşmeci size rehberlik edip sizi doğru çözüme yönlendirecektir.
6-Soruları çözerken hızlı olun ama aşırı acele etmeyin. Çok hata yapıp düzeltmeye çalıştığınızda saçma bir çözüm üretmeniz mümkündür.
7-Clean code yazmamakta ayrı bir hatadır. Görüşmecinin sizin kodunuzun fotoğrafını aldığını ve görüşme kuruluna ilettiğini unutmayın. Kodunuz sade ve açıklayıcı olmalıdır.
8- Kodunuzu gözden geçirip hatalarınızı düzeltmemekte bir hatadır.
9-Hatalarınızı düzeltmek için de acele etmeyin. Şöyle bir geri çekilin ve kodunuzu iyice değerlendirin ve hatalarınızı ve clean olmayan kodunuzu bu şekilde düşünerek düzeltmeye çalışın.
10-Zor bir soru geldiğinde vazgeçmeyin. Unutmayın görüşmeci sizi zor sorulara nasıl tepki verdiğinizi ölçmek isteyecektir. Ayrıca vazgeçmezseniz size bazı sinyaller vererek yardımcı olacaktır. Ayrıca bu soru sizin için zor ise herkes için de zordur.
-Veri yapıları ve algoritmalar görüşmeler için kritik öneme sahip. Konuları iyice kavradıktan sonra leetcode tarzı sitelerde bol bol soru çözmek gerekiyor. Arkadaşı 'ın tavsiyesiyle başladığım Scott Barrett'in https://www.udemy.com/user/scott-barrett-16/ Data Structures and Algorithms kursları. Ben Java versiyonunu seçtim. Eğitmen görseller için 1 sene uğraşmış. Veri yapıları ve algoritmaları görseller sayesinde çok daha hızlı kavrıyorsunuz.
-Eğer Java Developersanız, veri yapıları ve algoritmalar için bu kitap da sizin için uygun olabilir.
- Ayrıca Mosh'un data structure and algorithms kursu da iyi. https://codewithmosh.com/p/data-structures-algorithms
-Bu kaynaklara çalışırken leetcode.com uygulamasından sorular çözerek görüşmelere hazırlanabilirsiniz.
System Design :
-Bu bölümde özellikle senior mühendislere sorulan sistem dizayn soruları ele alınıyor.
-Mobil ve web gibi farklı teknolojilerin sistem dizaynı farklı oluyor.
-Eğer web dizayn ediyorsanız:
Load Balancing Caching Content Delivery Networks (CDN) Databases and Indexing Redundancy and Replication Database Sharding SQL vs NoSQL API design Mobile systems design
-Bu konuyla iligili de yazılmış güzel kitaplar mevcut.
-Sistemin darboğazları,kısıtlar gibi konular da sistem dizayn için önemli.
-Görüşmeler de genel sorulan sorulardan olan twitter gibi bir sistemi nasıl dizayn edersiniz sorusu. Elbetteki sizden bir saat de böyle bir sistemi dizayn etmenizi beklemiyorlar ama yukarıda bahsettiğim konularda genel olarak bir resim ortaya çıkarmanızı bekliyorlar. Bu noktada sizin bakış açınızı ve bilginizi merak ediyorlar. Bunu bir hackathon gibi düşünebilirsiniz.
Devam edecek....