Meta Sistem Tasarımı Mülakat Soruları

Dağıtık sistemler trivia'sını ezberleyerek hazırlanmış olabilirsiniz, ama bu tur bunu ödüllendirmez. Bu bölüm, altyapıdan çok ürün mühendisliğine yakın duran gerçek soru kalıplarını ele alıyor. Tekrar eden örüntü, zaten kullandığınız tüketici ölçekli bir özelliğin size açık uçlu bir problem olarak verilmesidir.

• Bir haber akışı tasarlayın. Sıralama, fanout on write ile fanout on read karşılaştırması ve milyonlarca takipçisi olan hesaplarda neler olduğu.
• Bir mesajlaşma veya sohbet sistemi tasarlayın. Teslimat garantileri, sıralama, presence ve cihazlar arası offline senkronizasyon.
• Bir bildirim sistemi tasarlayın. Deduplication, batching, kullanıcı başına rate limit ve push, e-posta ile uygulama içi teslimat.
• Yakındaki arkadaşlar veya bir konum özelliği tasarlayın. Coğrafi indeksleme, güncelleme sıklığı ve gizlilik modeli.
• Bir arama veya trend bileşeni tasarlayın. İndeks tazeliğinin sorgu gecikmesine karşı dengesi.

Bazı mülakat turları bunu, kullanıcıya dönük davranışa yakın duran bir ürün mimarisi varyantına ayırır. Hangisini alacağınızı işe alım uzmanınıza sorun, çünkü hazırlık farklıdır.

Başarısızlık modu, ikinci dakikada kutu çizmeye başlamaktır. İşe yarayan bir bölüm: gereksinimleri ve kapsamı netleştirin, API ve veri modelini taslak halinde çizin, üst düzey mimariyi çizin, sonra mülakatçının işaret ettiği yerde derinleşin.

• Önce gereksinimler. Hangi kullanıcılar, hangi platformlar, read-heavy mı write-heavy mi ve açıkça neyi inşa etmediğiniz.
• Sonra sayılar. Kabaca günlük aktif kullanıcı, istek oranları ve payload boyutları, böylece sonraki dengeler bir dayanağa sahip olur.
• Diyagramlardan önce veri modeli. Bir entity'nin nasıl göründüğü ve nasıl sorgulandığı genellikle mimariyi belirler.
• Tek bir derinlemesine inceleme. Tek bir bileşene yönlendirilip nasıl bozulacağının sorulmasını bekleyin.

Varsayımlarınızı sesli olarak belirtin. Bir varsayıma katılmayan mülakatçı onu düzeltecektir ki bu bedava bilgidir; dile getirilmemiş bir varsayım sadece bir boşluk gibi görünür.

Ortalama cevaplar doğru bir mimariyi tarif eder. Güçlü cevaplar, kabul ettikleri dengeyi ve göze aldıkları başarısızlığı adlandırır. "Fanout on write seçiyorum çünkü burada okumalar baskın, ve ünlü hesaplar için yavaş yazmayı kabul ediyorum, bunu ayrı bir pull path ile ele alırım" demek, kusursuz bir diyagramdan daha fazlasını yapar.

Kıdemli bir rol için mülakata giren bir backend mühendisini düşünün. Kendisinden bir bildirim sistemi tasarlaması istenir ve ilk altı dakikayı yalnızca gereksinimlere ayırır: bir kullanıcının tek bir olay için iki bildirim alıp alamayacağı, sıralamanın önemli olup olmadığı, saklama penceresinin ne olduğu. Mülakatçı daha sonra deduplication tartışmasının turun belirleyici kısmı olduğunu söyler ve kendisi tek sayfalık bir diyagramın ötesine hiç geçemez.

Bu anlatımı prova etmek, masada tek başına yapılınca zor olan kısımdır. /mock-interview sayfasında tasarım sorularını bir AI mülakatçıya karşı çalıştırabilir ve düşünürken konuşmaya alışabilirsiniz.

Sesli bir video turunda SubcueAI, mülakatçının sorusunu transkribe eder ve sizin tarafınızda, macOS ve Windows üzerindeki masaüstü overlay'de veya Chromium tarayıcı uzantısının yan panelinde önerilen bir yapı gösterir. Görüşmeye hiçbir toplantı botu katılmaz ve toplantı sayfasına hiçbir şey enjekte edilmez. Bir tasarım turu için gerçekçi değer, yüksek sesle okuduğunuz bir cevap değil, baskı altında sürekli unuttuğunuz kapasite tahmini veya başarısızlık modu gibi bir kontrol listesidir.

Sınırlar nettir. Tasarım turları genellikle ekranınız paylaşılmış halde, paylaşımlı bir whiteboard aracında yürür ve ekranınızdaki her şey panel tarafından görülebilir. Üretilmiş bir cevabı okumak da hemen çöker, çünkü mülakatçının bir sonraki sorusu "neden diğer yaklaşım değil?" olur. Diğer işverenler için ilgili mülakat turları company interviews topic sayfasındadır.