it-swarm.asia

Bir röportajda keyfi bir sistemi nasıl tasarlayabilirim?

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

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

36
Shamim Hafiz

Beyninizin bu soruna nasıl baktığına dair bilgi. İşte bu konuşmayı nasıl deneyebiliriz için görebildiğim birkaç başlangıç ​​noktası:

  • Yukarıdan aşağıya - Çok yüksek bir seviyeden aşağı bakarken bir tasarım oluşturun ve çeşitli bileşenler yapıldıkça tasarımı ortaya çıkarın ve burada görebildiğim bir avuç bileşen var ....

  • Aşağıdan yukarıya - Zeminden yukarı baktığımızda, bir araya getirmeye çalışmak için inşa edebileceğiniz bitler ve parçalar ...

  • Gereksinim açıklaması - Bu tasarım için kullanılan öngörülen ölçek, boyut, bütçe ve ekip hakkında sorular sorma. Bir kişinin çok basitleştirilmiş bir Word işlemcisini kodlamasını deneyebilir veya Google Dokümanının aşırı bir şekilde ele alındığına inandığınız nihai belge yönetim sistemini yapmak için yüz milyonlarca dolar harcayabilirsiniz. Ayrıca burada, "Google Dokümanla ne demek istiyorsun? Bu işlevin ne kadarını çoğaltmak istiyorsun?" sorular da.

Burada kilit nokta, bir kullanıcının size yaklaşmasını ve "Psst, 2 hafta içinde böyle bir şey yapabilir misiniz?" bu gerçekten olabilir. Bu nedenle how cevabını verdiğinizde cevabından daha önemlidir.


Kişisel düşüncem, geçmiş projelerin burada iyi bir fikir olmadığı olabilir. Birinin bulmaya çalıştığı şey, geçmişte bir şeyin nasıl yapıldığını hatırlamaktan ziyade yeni bir alanda ne tür yaratıcılık ve iletişim becerileridir. Muhtemelen, yeni pozisyonda olan bir şey geçmişten bir şeye benzese de, eski çözümün mümkün olmadığı kadar farklı olabilir. Bu nedenle, inşa edilebilenler mevcut bir uygulamaya benzer olsa da, çözümü ilk örnekten oldukça farklı kılan çeşitli özelleştirmeler olabilir.

Röportajlar iki yönlüdür. Yöneticiler ve diğer geliştiriciler nadiren görüşme ustasıdır, bu yüzden iş görüşmelerinde konu uzmanı olmaları gerektiğini belirtmeye çalıştığım değeri göremiyorum. İşverenler Bir röportajın nasıl yapılacağını bilmeyi beklediğimi görebiliyordum, ancak bunun neden her zaman iyi bir fikir olmadığının örnekleri olarak kullanılabilecek çok sayıda fakir işveren var.

22
JB King

Özellikle üst düzey geliştiriciler için bu soruların çok iyi olabileceğini düşünüyorum. Bir geliştiricinin büyük ve karmaşık bir açıklamadan gerçekçi bir uygulamaya geçebildiğini gösteriyorlar. Tamamen tanıdık bir sistemde bile, görüşmeci için bir dizi ilginç etkinlik yapabilmelisiniz:

  • Soruyu cevaplamak için gereksinimleri toplayın (ör. Kapsam)
  • Sorunu daha yönetilebilir parçalara ayırın; muhtemelen gerekli olabilecek arabirimleri veya nesneleri tanımlayabilir veya mantığı ön uç, arka uç, DB, vb.
  • Bu tür bir sistemin arkasındaki yapı ve kavramlara, örneğin Google Dokümanlar söz konusu olduğunda web uygulamalarına aşina olduğunuzu gösterin
  • Bir tasarım sorunu ile sunulduğunda neye odaklandığınızı gösterin (Nesne tasarımı? SQL tabloları? Tasarım modelleri?)
  • Patronun sizinle yeni bir sistem geliştirmenin nasıl bir önizlemesini gösterin, burada patron bir spesifikasyonla içeri girer ve "Bunu yapmak için ne gerekir?"

Bu soru yalnızca, bunun için kullanacağınız nesne hiyerarşisini açıklayın. "Bunun için tasarlayacağınız arayüzü açıklayın." "Orta ve orta seviyeli geliştiricilere verilecek olan bu veriler için bir dizi ilişkisel DB tablosu tasarlayın." Daha alt düzey geliştiricilerde, görüşmeci kişinin şirketteki uzun vadeli büyüme potansiyelini değerlendiriyor ya da sadece büyük bir problemle karşı karşıya kaldığında ne yaptıklarını görüyor olabilir.

16
Ethel Evans

Düşünce süreçlerinizi hareket halinde görmekle ilgilidir; bir çözümle ilgilenmezler, ancak sorunu çözmeye nasıl yaklaşacağınız, hangi soruları soracağınız, hangi sorunları tanımlayacağınız vb.

Google Dokümanlar örneği göz önüne alındığında, akla gelen belirgin sorunlar depolama, güvenlik, ölçeklenebilirlik, kullanılabilirlik, istemci arayüz tasarımı, tarayıcı uyumluluğu vb. Konulardır. Sorumluluğu sunucu ve istemci arasında nasıl bölebilirsiniz? Yedekleri nasıl ele alırsınız? Bir sunucu çöktüğünde ne olur? "Abandonded" belgelerle (uzun süredir erişilmeyen veya değiştirilmemiş olan şeyler) ne yapardınız?

Yine, mesele bu konuların herhangi birini çözmek değil, tanımlamak onlara, onlarla konuşmak, onlara nasıl hitap edileceği konusunda biraz beyin fırtınası yapmaktır.

11
John Bode

Röportajlarda sık sık bu tür sorular soran suçlu taraflardan biriyim. (Kayıt için, "favori projeleri" hakkında da benzer sorular soruyorum.) Sormamın nedeni, burada sık sık yaptığımız bir şey. Tasarım mühendislerini bir arayüzün her tarafından, sistem mühendisliğinden, testten birinden ve özellik için müşteri kullanım durumları hakkında bilgi sahibi birinden alıyoruz. Bir beyaz tahtanın etrafında duruyoruz ve "Tamam, bu şeyi nasıl inşa edeceğiz?" Diyoruz. Genellikle bu noktada yeni özellik hakkında çok az şey biliyorsunuz ve sadece sisteminizdeki uzmanlığınız nedeniyle oradasınız, ancak yine de verimli bir şekilde katkıda bulunmanız bekleniyor. Bu sadece varsayımsal bir akademik egzersiz değil.

Ne tür cevaplar beklediğime gelince, örneğin, bir kerede alandaki 5000 set üstü kutusunu yükseltmek için merkezi bir ofiste 20 gömülü hat kartı aracılığıyla bir sunucudan yeni ürün yazılımı indirmek için bir sistem tasarlayın. Sunucu ve hat kartları arasındaki bağlantıda çok az yedek kapasite olduğunu varsayın.

Kötü cevap:

Um, muhtemelen ethernet ya da bunun gibi bir şey kullanırdım.

İyi cevap:

Ne kadar büyük bir resimden bahsediyoruz? [Yaklaşık 7 MB.] İndirme sırasında hizmetin etkilenmediğinden emin olmak istersiniz. Aynı görüntüyü tekrar tekrar indirmemek için muhtemelen birden fazla flash veya RAM bir kerede iki görüntü saklamak istersiniz. Katıştırılmış olarak, hat kartlarınız muhtemelen CPU'nun kendilerine sınırlıdır, bu nedenle hizmet için yeterli kapasite bırakmak için indirmeleri serileştirmeniz gerekebilir.Görüntünün iyi olduğunu doğrulamak ve eski sürüme geri dönmek için bir yol istiyorsunuz. Birkaç kez tekrar denemeniz ve yükseltme başarısız olursa bir insana hataları bildirmeniz için bir yol gerekir. Farklı set üstü kutu markalarınız varsa, hangisini tanımlamak için bir tür yola ihtiyacınız olacaktır. resim göndermeniz gerekir.

Bunlar neredeyse iki farklı adayın Word için Word transkripsiyonlarıdır. Çoğu aday arasında bir yerlerde, ama genellikle sonunda biraz ufak bir istirahat ile, o mükemmel tamam. Burada bir sonraki Einstein'ı aramıyoruz, sadece her gün çalıştığımız problemler hakkında akıllıca akıl yürütebileceğinize dair bir gösterge.

9
Karl Bielefeldt

Ben de bu tür bir soru soruyorum ve diğer cevapların çoğuna katılıyorum. Belki görüşmecilerin bu tür bir sorunun neden önemli olduğunu anlamalarına yardımcı olabilir? Varsayalım ki önemli bir ticari kararımız var ve bunu yapabilmek için yeni bir sistem kurmamız gerekiyor. Birisi size koşar ve X'i yapan bir sistem kurmanın ne gerektiğini sorarsa, onlara gereken büyük zorlukları ve kaynakları tahmin eden içgörü bir cevap verebilir misiniz?

Genç bir programcının nereden başlayacağı hakkında hiçbir fikri yoktur. Ayrıntılı bir belirtim olmadan konuşmaya hazır değiller. Üst düzey bir programcı, konuyla ilgili birçok yön olduğunu anında görecek ve bir meydan okumaya odaklanmaya çalışacaktır. Her yönüyle mimarlık yapmak zorunda değilsiniz, sadece mimari bir meydan okumayı tanımlayın ve sonra bunu nasıl ele alacağınızı anlayın.

Google Dokümanlar konusunu düşünün:

İlginç bir şey, gelecek taleplerin kesme ölçeğidir. Tek bir sunucu alıp kodunuzu ona dağıtamazsınız - bu daha büyük bir girişimdir. Başarılı bir görüşmeci bu konuda sıfıra düşebilir ve ihtiyaç duyulacak kaynak türlerini ve bu ölçekte uygulamada karşılaşılan bazı teknik zorlukları, sadece durumu olmayan bir uygulama ile, durumu birden fazla kullanıcı arasında paylaşır.

Google Dokümanlar ile ilgili bir diğer ilginç şey, aynı anda birden fazla kişinin düzenleme yapabilmesidir. Başarılı bir görüşmeci, ortaya çıkan dokümanın çöp olmadığından emin olmak için mekanizmaları tartışabilecek ve gerçekten harika bir aday, düzenlemeleri senkronize etme veya birleştirmenin farklı yöntemlerinin performans ve UX üzerinde büyük bir etkisi olacağını fark edecektir. Belki de varyasyonları tartışabilirsiniz: Kod yazma için paylaşılan bir belge düzenleyicisi, çakışmaları çözmek için tipik Google Dokümanından farklı bir yöntem kullanmalıdır, çünkü farklı bir sırada olan 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 takas için ne yapacağınızı tanımlamanız gerekmez, ancak ilginç bir sorunu olan bir alan bulmak ve takasın ne olduğunu açıkça açıklamak gerçekten harikadır. olabilir.

-t.

5
Tristan Reid

Görüşmecilerin duymak istedikleri şeylerden şüpheleniyorum:

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

Daha fazla ne tartışmak istersiniz?

Sonra top, görüşmeci mahkemesinde. Daha fazla ayrıntı istiyorsa sorabilir. Görüşmecinin aradığı şey, bir soruna veya ürüne bakıp tasarımı çıkarabilir misiniz?

2
Gilbert Le Blanc

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

Daha sonra, temel kullanım senaryolarına/öykülerine dayanan mimari bir çözüm üretebilmelidirler. Umarım modülleri tanımlamaktan başka sistematik bir süreç kullandılar. Çözüm için bir görüşme durumundan daha fazlasını beklemezdim.

Bununla birlikte, mimari modüllerden birini seçebilir ve sadece bazı tasarım becerilerine sahip olup olmadıklarını görmek için daha ayrıntılı bir tasarım isteyebilirim. Ayrıca, başarısızlık durumlarını/performans sorunlarını dikkate aldıklarını görmek de güzel olurdu. Ama bu noktada, bir zaman duvarına gireceğimizden şüpheleniyorum. Bu nedenle, bu konuları dikkate almadığı için onları gerçekten cezalandıramadım çünkü sadece çok fazla zaman var ve bence her türlü senaryoyu zaman sınırlı bir görüşme durumundan beklemediğini varsaymanın makul olduğunu düşünüyorum.

2
Dunk

Geçenlerde bir asansör kontrol sistemi tasarlamamın istendiği bir röportajım vardı. Temelde göreve yaklaşımınızı görmek istiyorlar. Bu soru sorulursa, muhtemelen sizin için çok üst düzey bir işi var. Tebrikler.

1
Michael Brown

Önemli olan, verdiğiniz çözümün yararlarına karşı problemleri nasıl çözeceğinize ve büyük resim problemleriyle başa çıkabiliyorsanız.

Bence yapılması gereken önemli bir şey, gereksinimler hakkında soru sormak. Sadece evcil hayvan çözümünüzün çalışmasını sağlayacak varsayımlar yapmayın. Örneğin, belgeleri açıklamak için doğrudan atlamaya cazip olabileceğiniz belgeleri yazdırmak için gerçekten şık bir yöntem biliyor olabilirsiniz. Ancak Google Dokümanlar doğrudan yazdırmıyor; daha sonra istemcinin yazdırdığı bir PDF) üretir.Bununla başlarsanız, sorunun bir parçası olmayan bir sorunu çözerek zamanınızın yarısını üflersiniz ve müşterinizin sorununu çözmek yerine sıcak teknolojinizi kullanmakla daha fazla ilgilenirsiniz.

1
JohnMcG

Bu tür röportaj sorularını ele almak için, sadece ilgilendiğiniz projelerde değil, deneyimlerinizden çok uzak olduğunu düşündüğünüz projelerde de “işlerin nasıl yürüdüğünü” anlama konusunda genel bir ilginizin olması gerekir.

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

Okuduklarınızın çoğunu unutacağınız gerçeğine rağmen (bu bilgiler kişisel olarak işinize bağlı değildir), "hayal gücü tohumları" olan bazı çerezler ve bu tohumların küçük bir kısmı olabilir. uzak bir gelecekte benzer bir problemle karşılaştığınızda çimlenecektir.

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

0
rwong

Bu tür bir soru sormanın arkasındaki nokta, zihninizi anlamanızdır. Sık kullandığım bir soru programcılardan PacMan'ı simüle edebilecek bir sistem tasarlamalarını istemek.

Ve evet, önce kullanım durumlarını arıyorum, bana kişinin düşündüğünü gösteriyor. Daha sonra, çoklu kullanım için, önce veri yapılarının dikkate alınması (problem için kullanılabilenler, daha sonra kararın nedenleri ile daha uygun veya spesifik olanlar).

Bu, üst düzey gelişim pozisyonları için düşünülen bir zorunluluktur. İnsanların bu geliştirici deneyimi düzeyindeki sıralama uygulamaları hakkında oturup soruları yanıtlaması hem saçma hem de anlamsızdır. Sistem tasarımı bu seviyede beklediğim şey.

0
Wile E K