Röportajda keyfi bir sistemi nasıl tasarlarım? [kapalı]

Teknik Röportajda ortak bir soru, genellikle şirketin mevcut ürünü olan belirli bir sistemi tasarlamaktır. Örneğin, "Google Dokümanlar Tasarla".

Böyle bir soru için beklenen cevap nedir? Yani, bu tür sistemler kesinlikle herhangi bir görüşmenin kapsamı dışında kalan karmaşık bir tasarıma sahiptir. Bu kadar kısa sürede görüşmeci ne bekliyor?

Beyniniz bu soruna nasıl baktığına dair içgörü. İşte bu sohbeti nasıl yapmayı deneyebileceğime dair birkaç başlangıç ​​noktası:

• Yukarıdan aşağıya - Çok yüksek bir seviyeden aşağıya bakmak, bir tasarım oluşturur ve çeşitli bileşenler yapılırken tasarıma son verir ve işte görebildiğim birkaç parça bileşen vardır.

• Aşağıdan yukarıya doğru - Yukarıdan yukarıya doğru bakıldığında, bir araya getirmeye çalışmak için inşa edilebilecek parça ve parçalar ...

• Gereksinim açıklama - Bu tasarım için kullanılan öngörülen ölçek, büyüklük, bütçe ve ekip hakkında sorular sormak. Bir kişinin kodunu çok basitleştirilmiş bir kelime işlemcisi olarak deneyebilir veya Google Dokümanın uç noktalara nasıl götürdüğüne inandığınızı düşündüğünüz nihai doküman yönetim sistemini yapmak için yüz milyonlarca dolar harcamayı planlayabilirsiniz. Ayrıca burada, "Google Dokümanı ile ne kastediyorsunuz? Bu işlevselliğin ne kadarını çoğaltmak istiyorsunuz?" sorular da.

Kilit nokta, bir kullanıcının size yaklaştırabileceği ve "Psst, 2 hafta içinde böyle bir şey yapabilir misiniz?" Bu gerçekten olabilirdi. Bu nedenle, cevabı nasıl verdiğiniz, cevabın ne olduğundan daha önemlidir .

Benim kişisel görüşüm, geçmiş projelerin burada iyi bir fikir olmadığı yönünde olacaktır. İnsanın bulmaya çalıştığı şey, geçmişte nasıl bir şey yapıldığını hatırlamak yerine , yeni bir alanda ne tür bir yaratıcılık ve iletişim becerileri olduğudur. Yeni ihtimalde olan bir şey geçmişten gelenlere benzer olsa da, eski çözümün yapamayacağı kadar farklılıklar olabilir. Bu nedenle inşa edilebilir olanın mevcut uygulamaya benzer olmasına rağmen, çözümü ilk örnekten oldukça farklı kılan çeşitli özelleştirmeler olabilir.

Görüşmeler iki yönlü bir caddedir. Yöneticiler ve diğer geliştiriciler nadiren görüşme ustalarıdır, bu yüzden iş görüşmelerinde konu uzmanı olmaları gerektiğini söylemeye değerimin farkında değilim. İşverenler Nasıl röportaj yapılacağını bilmeyi beklemekteydim, ancak bunun neden her zaman iyi bir fikir olmadığını gösteren örnekler olarak kullanılabilecek çok sayıda zayıf işveren var.

Özellikle kıdemli geliştiriciler için bu soruların çok iyi olabileceğini düşünüyorum. Bir geliştiricinin geniş ve karmaşık bir tanımdan gerçekçi bir uygulamaya geçme yeteneğine sahip olduğunu gösterirler. Tamamen yabancı bir sistemde bile, görüşmeci için bir dizi ilginç aktivite yapabilmelisiniz:

• Soruyu cevaplamak için gereksinimleri toplayın (örneğin, kapsam)
• Sorunu daha yönetilebilir parçalara ayırın; İhtiyaç duyulabilecek arayüzleri veya nesneleri tanımlayabilir veya mantığı ön uç, arka uç, DB vb.
• Bu tür bir sistemin arkasındaki yapı ve kavramlara aşinalık gösterin, örneğin Google Dokümanlar durumunda web uygulamaları
• Bir tasarım problemi ile ne zaman odaklanacağınızı gösterin (Nesne tasarımı? SQL tabloları? Tasarım kalıpları?)
• Patrona sizinle birlikte yeni bir sistem geliştirmenin nasıl bir önizlemesini gösterin, patronun bir spesifikasyonla girip "Bunu inşa etmek için ne gerekir?"

Bu soru, "Bunun için kullanacağınız nesne hiyerarşisini tanımlayın." “Bunun için tasarlayacağınız arayüzü tanımlayın.” “Bu veri için bir dizi ilişkisel veri tabanı tablosu tasarlayın. Daha düşük seviyeli geliştiricilerde, görüşmeci, kişinin şirkette uzun vadeli büyüme potansiyelini değerlendirebilir veya yalnızca büyük olasılıkla zor olabilecek büyük bir sorunla karşılaştığında ne yaptıklarını görüyor olabilir.

Düşünce süreçlerinizi çalışırken görmekle ilgili; bir çözümle ilgilenmiyorlar, ancak sorunu çözme, ne gibi sorular soracağınız, hangi sorunları tanımlayacağınız vs.

Google Dokümanlar örneği göz önüne alındığında, akla gelen sorunlar depolama, güvenlik, ölçeklenebilirlik, kullanılabilirlik, istemci arayüz tasarımı, tarayıcı uyumluluğu vb. Gibi şeylerdir. Sunucu ve istemci arasındaki sorumluluğu nasıl bölerdiniz? Yedekleri nasıl idare edersiniz? Bir sunucu çöktüğünde ne olur? "Abandonded" belgelerle ne yaparsınız (uzun süredir erişilmemiş veya değiştirilmemiş şeyler)?

Yine, amaç bu sorunların hiçbirini çözmemek değil, tanımlamak, onlarla konuşmak, nasıl ele alınacağı hakkında biraz beyin fırtınası yapmaktır.

Röportajlarda sık sık bu tür bir soru soran suçlu taraflardan biriyim. (Kayıt için, aynı zamanda "favori projeleri" hakkında da benzer sorular soruyorum.) Sormamın nedeni, buralarda sık sık yaptığımız bir şey. Arayüzün her tarafından tasarım mühendisleri alıyoruz, sistem mühendisliği, test, test ve müşteri bilgisi olan bazı kişiler bu özelliği kullanıyor. Bir beyaz tahtanın etrafında durup "Tamam, bu şeyi nasıl yapacağız?" Deriz. Genelde bu noktada yeni özellik hakkında çok az şey biliyorsunuzdur ve yalnızca sisteminizin kendi konusundaki uzmanlığınız nedeniyle varsınız, ancak yine de üretken olarak katkıda bulunmanız bekleniyor. Bu sadece varsayımsal bir akademik egzersiz değil.

Ne tür bir cevap beklediğim kadarıyla, örneğin, bir sahadaki 5000 set üstü kutuyu bir kerede yükseltmek için bir merkez ofisteki 20 gömülü hat kartı aracılığıyla bir sunucudan yeni firmware indirmek için bir sistem tasarlamak. Sunucu ve hat kartları arasındaki bağlantıda çok az boş kapasite olduğunu varsayalım.

Kötü cevap:

Muhtemelen ethernet ya da onun gibi bir şey kullanırdım.

İyi cevap:

Ne kadar büyük bir görüntüden bahsediyoruz? [Yaklaşık 7 MB.] İndirme sırasında servisin etkilenmediğinden emin olmak istersiniz. Aynı anda iki görüntüyü saklamak için ekstra flaş veya RAM gerekir. Sunucudan aynı resmi indirmeyi önlemek için muhtemelen görüntüyü hat kartlarınızda önbelleğe almak isteyebilirsiniz. Katıştırılmış olması nedeniyle, hat kartlarınız muhtemelen sınırlı CPU'ya sahiptir, bu nedenle servis için yeterli kapasite bırakmak için indirilenleri seri hale getirmeniz gerekebilir. Görüntünün iyi olduğunu doğrulamak için bir yol istiyorum ve işe yaramazsa eski sürüme geri dönün. Yükseltme başarısız olursa birkaç kez yeniden denemek ve hataları bir insana bildirmek için bir yol gerekir. Farklı set üstü kutuları varsa, hangi görüntüyü göndermeniz gerektiğini belirlemek için bir yol gerekir.

Bunlar neredeyse iki farklı adayın kelime transkripsiyonu için bir kelime. Adayların çoğu, aralarında bir yerlerdedir, ancak genellikle sonunda, tamamıyla sorun olmayan küçük bir ipucu ile oraya ulaşırlar. Burada bir sonraki Einstein'ı aramıyoruz, sadece her gün üzerinde çalıştığımız sorun türlerini akıllıca aktarabileceğinizi gösteren bir gösterge.

Ayrıca bu tür bir soru soruyorum ve diğer cevapların çoğuna katılıyorum. Belki de bu tür bir sorunun neden önemli olduğunu anlamak için görüşmecilere yardımcı olacaktır? Karar vermemiz gereken önemli bir iş kararımız olduğunu varsayalım ve bunu yapabilmek için yeni bir sistem kurmamız gerekir. Birisi size karşı gelirse ve X'e sahip bir sistem inşa etmek için ne gerektiğini sorarsa, onlara gereken temel zorlukları ve kaynakları öngören içgörülü bir cevap verebilir misiniz?

Küçük bir programcının nereden başlayacağı hakkında hiçbir fikri yok. Ayrıntılı bir teknik özellik olmadan konuşmaya başlamaya hazır değillerdir. Üst düzey bir programcı, konuyla ilgili birçok yönün olduğunu anında görecek ve bir zorlukla başa çıkmaya çalışacaktır. Her yönüyle mimarlık yapmak zorunda değilsiniz, sadece mimari bir meydan okuma tanımlayın ve sonra nasıl çözeceğinizi düşünün.

Google Dokümanlar sorununu göz önünde bulundurun:

İlginç olan şeylerden biri, gelecek olan taleplerin kayma ölçeğidir. Tek bir sunucuya sahip olamazsınız ve kodunuzu konuşlandırmazsınız - bu daha büyük bir girişimdir. Başarılı bir görüşmeci bu konuda sıfır olabilir ve ihtiyaç duyulacak kaynak türlerini ve bu ölçekte uygulamadaki teknik zorlukların bazılarını, yalnızca devleti olmayan bir uygulamayla birden fazla kullanıcı arasında paylaşır.

Google Dokümanlar ile ilgili başka ilginç bir şey, aynı anda birden fazla kişinin düzenleyebilmesidir. Başarılı bir görüşmeci, sonuçta ortaya çıkan dokümanın çöp olmadığından emin olmak için mekanizmaları tartışabilecek ve gerçekten harika bir aday, düzenlemelerin senkronize edilmesi veya birleştirilmesinin farklı yöntemlerinin performans ve UX üzerinde büyük bir etkisi olacağını fark edecektir. Belki de varyasyonları tartışabilirsiniz: Kod yazmak için paylaşılan bir belge düzenleyici, muhtemelen tipik bir Google Dokümanı'ndan farklı bir çakışma çözme yöntemi kullanmalıdır, çünkü farklı bir düzende gerçekleşen veya biraz farklı bir yapıya sahip olan şeylerin farklı sonuçları vardır.

Google Dokümanlar gibi bir uygulama oluşturmanın tek bir doğru yolu yoktur, her işlem için ne yapacağınızı belirlemeniz gerekmez, ancak ilginç bir sorunu olan bir alan bulmak ve ticaretin ne olduğunu açık bir şekilde açıklamak gerçekten harika -offs olabilir.

-t.

Görüşme yapanların duymak istedikleri şeyin şu olduğundan şüpheliyim:

Google Doküman bir kelime işlemcisi için bir web arayüzüdür. Kullanıcı belgeleri yazılır ve saklanır ve aynı veya farklı bir bilgisayarda kullanıcı tarafından alınabilir.

Daha fazla ne tartışmak istersiniz?

O zaman, top görüşmeci mahkemesinde. Daha fazla ayrıntı istiyorsa, sorabilir. Görüşme yapan kişinin aradığı şey, bir soruna veya bir ürüne bakıp tasarımı ayıklayabiliyor musunuz?

Benim için, kişi kilit kullanım durumlarını / hikayeleri tanımlamakla başlamazsa, bu özel beceri gerektiren bir pozisyon için hazırlıklı olmadıklarını bilmek yeterli olacaktır.

Daha sonra, anahtar kullanım durumlarına / hikayelerine dayanan bir mimari çözüm bulabilmeliler. Umarım, modülleri tanımlamak için kendilerinden çekmekten başka bazı sistematik süreçler kullandılar ... Çözüm için görüşme durumundan çok daha fazlasını beklemem.

Ancak, mimari modüllerden birini seçip daha ayrıntılı bir tasarım isteyebilirim, sadece bazı tasarım becerilerine sahip olup olmadıklarını görmek için. Başarısızlık durumlarını / performans sorunlarını düşündüklerini görmek de güzel olurdu. Fakat bu noktada şüpheleniyorum, zaman duvarına giriyorduk. Bu yüzden, bu konuları dikkate almadıkları için gerçekten ceza veremedim, çünkü çok fazla zaman var ve olası her senaryoyu düşünmenin zaman sınırlı bir görüşme durumundan beklenmeyeceğini varsaymanın makul olacağını düşünüyorum.

Geçenlerde bir asansör kontrol sistemi tasarlamamın istendiği bir röportaj yaptım. Temel olarak, göreve olan yaklaşımınızı görmek istiyorlar. Bu soru sizden isteniyorsa, muhtemelen sizin için aklımda çok üst düzey bir iş vardır. Tebrikler.

Önemli olan, nasıl çözdüğünüzün özniteliğine karşı sorunları çözme yolunda ilerlemeniz ve büyük resim sorunlarıyla başa çıkabilmeniz durumunda.

Bence yapılması gereken önemli bir şey gereksinimler hakkında sorular sormak . Sadece evcil hayvanınızın çözümünün çalışmasını sağlayacak varsayımlarda bulunmayın. Örneğin, doğrudan anlatmaya girmeye istekli olabileceğiniz belgeleri yazdırmak için gerçekten şık bir yöntem biliyor olabilirsiniz. Ancak Google Dokümanlar doğrudan yazdırmıyor; istemcinin daha sonra yazdırdığı bir PDF üretir. Bu nedenle, bununla başlarsanız, sorunun bir parçası olmayan bir sorunu çözme zamanınızın yarısını atmış olacaksınız ve müşterinin problemini çözmekten çok sıcak teknolojinizi kullanmakla daha fazla ilgilendiğinizi göstermiş olacaksınız.

Bu tür görüşme sorularını ele almak için, sadece ilgilendiğiniz projelerle değil, deneyimlerinizden çok uzak olduğunu düşündüğünüz projeleri de "işlerin nasıl yürüdüğünü" anlama konusunda genel bir ilginiz olması gerekecektir.

Bu, blogları, makaleleri, http://www.infoq.com , Hacker News, vb. Okumak anlamına gelir . Kodlama Korkusundan donanım blöfleri bile.

Okuduklarınızın çoğunu unutacağınıza rağmen (bu bilgiler işinizle kişisel olarak bağlantılı olmadığı için), "hayal gücü tohumları" olan bazı bilgiler ve bu tohumların küçük bir kısmı olabilir Uzak, uzak bir gelecekte benzer bir problemle karşılaştığınızda filizlenecek.

Bu yüzden, görüşmeci belki de okuma alışkanlığınızla ilgileniyor (hobinizin bir parçası olarak) ve rastgele yerlerden fikir toplamak için düzenli bir alışkanlığınız olup olmadığını görün.

Bu tür bir soruyu sormanın arkasındaki amaç, aklınıza bir fikir edinmektir. Kullandığım yaygın bir soru, programcılardan PacMan'ı simüle edebilecek bir sistem tasarlamalarını istemektir.

Ve evet, önce kullanım davalarını arıyorum, bana kişinin düşündüğünü gösteriyor. Ardından, çoklu kullanım için, önce veri yapılarını göz önünde bulundurun (problem için kullanılabilecekler, daha sonra kararın nedeniyle daha uygun veya spesifik olanlar).

Bu, kıdemli gelişim pozisyonları için göz önünde bulundurulması gereken bir husustur. İnsanların bu geliştirici deneyim seviyesindeki sıralama uygulamaları hakkındaki soruları yanıtlamaları hem aptal hem de anlamsızdır. Sistem tasarımı bu düzeyde bekleyeceğim şey.