Aşırı mühendislik bir uyarı işareti midir? [kapalı]

Bu yüzden bazı iyi tanımlanmış gereksinimleri olan yeni adaylara basit bir kodlama çalışması sunuyoruz. Zaman zaman problemi gerçekten çözmeyen, fakat genellikle alıştırmanın sınırlarının dışında algılanan bir problemi çözmek için fazla tasarlanan çözümler alıyoruz.

Şimdi sorum şu, bu bir uyarı işareti mi?

EDIT: Tartışmaların çoğu, kusurlu teste dayanıyor - ki bu adil bir nokta. Bir yorumda tanımladığım gibi, testin temel önermesi dosyadaki verileri mantıklı bir şekilde nasıl okuyabileceğinizi (ve gördüğümüz çeşitli yaklaşımlara hayran kalacaksınız) ve bunları nasıl eşleştireceğinizi göstermektir. güncellemeler arasındaki gecikmeyi hesaplamadan önce öğeler. Şimdi bunun çalışması için verilerle ilgili bazı varsayımlar yapılması gerekiyor ve bu varsayımları arıyoruz ve açıkça aldığınız yaklaşımı (OO yaklaşımı vb. Dahil) görmek istediğimizi de açıkça belirtiyoruz. zaman aralığı.

IMHO, röportaj yaparken karşılaştığım en eksiksiz egzersizdi.

Üzerinde durduğum belirli senaryo, bir adayın dosyadan okumak yerine, açıkça kapsam dahilinde olmayan, çok iş parçacıklı bir uygulamada "ağ" girdisini kabul etmesidir.

Sorun testin yamulmasıdır. Birinden, sadece birkaç dakika süren basit bir alıştırma kullanarak karmaşık, kurumsal düzeyde yazılım yazma yeteneklerini göstermesini istiyorsunuz. Adayların bu uygulamalarla nesne yönelimli tasarım konusunda yeterli beceri göstermediğinden şikayet eden başka şirketlerde görüşmeci var, bu yüzden insanlar aşırı telafi etme eğilimindedir. Bu, şartın gerektirdiği durumlarda adayınızın daha basit kod kullanamadığı anlamına gelmez.

Adayınızla durumun böyle olup olmadığını bilmek istiyorsanız, sadece onlara bazı özel kurallar vererek, tekrar yapmalarını isteyin. “Nesne yönelimli tasarım becerilerinizi sergilediğinizi görebiliyorum, ancak bu kadar basit bir sorun için fazla mazeretli görünüyor. Yalnızca iki küçük işlevi kullanarak yeniden yazabilir misiniz?”

Bunun açık bir uyarı işareti olduğunu söyleyebilirim, ancak bir aday için mutlaka diskalifiye edilmesi gerekmez.

Adayların göründüğü iki ayrı sorun var:

1. Egzersizin noktasını kaçırmak - Bu oldukça endişe verici. Dünyadaki tüm programlama becerileri, eğer birileri doğru şekilde çözdükleri problemi çözemezse, iyi bir sonuç vermeyecektir. En üretken mühendislerin, ortaya konulan problem olmasa bile, çözülecek asıl sorunu tanımlayabilenler olduğunu buldum. Sorulan soru hakkında eleştirel düşünme ve belki de çözmesi daha kolay olan bir şeyi yeniden biçimlendirme yeteneğine sahip olmak kritik bir beceridir. Sorunun açıkça söylendiği noktayı kaçırmak büyük bir kırmızı bayrak olmalıdır.
2. Çözümün gereğini yapmak - Bu ikincil bir konudur ve genellikle ilk sayının sonucudur. Bu sonucu alabilecek birkaç farklı patoloji var. Birincisi, problemi doğru bir şekilde anlamadığınız veya çok geniş bir şekilde yaymak, çok karmaşık bir çözüme yol açabilir. Bu açıkça yukarıdaki ilk nokta ile ilgilidir. İkincisi, gerçekten alakalı olmayabilecek gelecek senaryoları düşünerek "göstermeye" çalışmak. Bu sorunlu olabilir, çünkü adayın çözümlerdeki sadeliğin değerini anlamadığını ve gerçekten gerekli oluncaya kadar karmaşıklığı ertelemediğini gösterir. Bu, iyi rehberlikle düzeltilebilecek bir şeydir, ancak birisini organizasyona getirirken dikkat edilmesi gereken bir şeydir.

Süreç boyunca adayın cevaplarını takip etmesini öneririm. Sadece sonuçlarına bakmak yerine, sonuçlara neyin yol açtığını saptamaya çalışın ve bazı önerilerde bulunup cevaplarını nasıl yanıtlayacaklarını ve cevaplarını nasıl değiştireceklerini belirlemeye çalışın. Bu muhtemelen yetenekleri hakkında sadece soruna doğrudan cevap vermekten daha açıklayıcı olacaktır. Yaklaşımlarının "nedenleri", sadece anlamadıklarını ya da anlamalarına nasıl cevap vermeyi seçtiklerini anlama konusunda biraz hafif olmanın bir anlamı olabilir. Bu tür bir takip, problem çözme konusundaki genel yaklaşımları hakkında daha fazla bilgi verecektir.

Ayrıca, sorunun kendisini yeniden gözden geçirin ve belki de belirsiz olup olmadığına bakın ve belki de insanların cevaplarını formüle ederken yanlış yolda olmalarına neden olun.

Hayır, iş görüşmesi sırasında olmaz. Çok fazla görüşmeci gereksinimleri kasıtlı olarak belirtmek ve görüşülen kişinin daha fazla soru sormasını beklemek veya açıkça belirtilmeyen gerçek dünya meselelerine dikkat etmek gibi şeyler yapar.

İşte kafamın tepesinden, gereksinimlerinizin muhtemelen bahsetmediği bazı şeyler:

• Kodlama standartları

• Yorumlar

• İstisna işleme

• Tanımlayıcı değişken isimleri, sınıflar, yöntemler

• Dilin deyimsel kullanımını takiben

• Uygun nesne yönelimli tasarım

• Olası eşzamanlılık sorunlarına dikkat

• Kod için test senaryoları yazma

Açıkça belirtmeden, bunlardan birine dikkat ettin mi? Aday hangisine önem verdiğinizi ve hangilerini umursamadığınızı nasıl bilebilir?

Bir röportaj son derece yapay bir ortamdır. Görüşme yapanlar, görüşmecinin kendisine duymak istediklerini söylemesini zorlaştırmak için adayı biraz "kandırmaya" çalışıyor ve görüşmeci, görüşmecinin gerçekte ne istediğini tahmin etmeye çalışıyor .

Genel olarak, bu tahminde hata yapmak, gerçek dünya tasarım kararlarında hata yapmaktan oldukça farklıdır. Eğer birşeyin aşırı mühendis olup olmadığını bilmek istiyorsanız, muhtemelen çok yapay bir kodlama çalışmasına bakmak yerine tasarım hakkında konuşmak zorundasınız.

IMHO cevabı açıkça evet , eğer bir uyarı işareti

• kodlama alıştırmasının net bir görevi vardı
• iyi tanımlanmış (aynı zamanda iyi yazılmış) şartlara sahiptir,
• adayların doğru sorunu çözdüklerinden emin olmak için soru sorma şansı vardı.
• mimari astronotları değil zeki ve ekibinizde işleri yapan insanları istiyorsunuz .

Elimizdeki sorunu çözmemek kadar büyük bir uyarı işareti değildir . Sınavda başarısız olduğu ve doğru çözümü sağlamadığı gerçeği bir uyarı işaretidir. Kesin olarak çözülmeyen bir senaryo değil, çünkü nasıl ve neden doğru çözümü sağlamadığına bağlı.

Çoğu zaman soru tam bir saçmalık ve kesinlikle cevaplanamaz. Görüşme yapanların asla hata yapmamış gibi davranma. Sorunun neden saçma olduğunu anlamak için hala bir başarısızlık var. Gereksinim yapmasına yardım etmesi beklenen bir mühendis kiralıyorsanız, bu bir problemdir. Bir kodlayıcı tutuyorsanız, sadece onun yapmasını beklemeyin.

Kodlama alıştırmasının berbat bir şekilde dağılmadığını varsayarsak, başarısız olduğu şekilde sorunu yanlış yorumluyor ve orada olmayan bir sorunu çözmeye çalışan yabancı otlara gidiyormuş gibi görünüyor. Evet, bu bir uyarı işaretidir.

Olabilir.

Sorunu çözmemek elbette bir şeyin yanlış olduğu konusunda kesin bir uyarı işaretidir. Ne yanlış gitti? Ya sorunu yanlış anladılar ya da kötü bir çözüm yaptılar. Basit bir şey için kötü bir çözüm, adayın zayıf olduğuna dair açık bir işarettir.

Sorunu yanlış anladılarsa, gereksinimlerinize uzunca bir bakın. Sizin için kristal gibi görünen şeyler bile, bir etki alanına aşina olmayan başkaları veya farklı bir arka plandan (yerel, yaş, terbiye) açık olmayabilir. Aday odada sizinle birlikte olsaydı ya da soru sorma fırsatı bulduysa ve hala başarısız olsaydı, kendi taraflarında bir başarısızlık olduğunu düşünürdüm. Gereksinimler duvarın üzerinden atılırsa, onlara şüphenin avantajını verirdim (ve görüşme sürecini düzeltmeyi düşünüyorum).

Çözüm doğru olsaydı daha az netleşir. Şahsen, birçok insanın YAGNI'yi çok fazla aldığını düşünüyorum . Belirli bir sorunu çözebilir ve karmaşıklığı artırmadan veya sürdürülebilirliği arttırmadan genel bir çözüm oluşturabiliyorsanız, neden genel çözümü yapmıyorsunuz? (Bir ipi ters çevirmeyi ya da herhangi bir koleksiyonu ters çevirmeyi düşünün) Bu tür "fazla mühendislik" benim görüşüme göre açıkça iyidir.

Diğer her şey o gri orta yoldur. Çözüm olası değişim eksenlerini ele alıyor mu? Çözüm, karmaşıklık ekler mi yoksa bakım kolaylığı sağlar mı? Kazanmak neredeyse garanti edilen gelecekteki sorunları çözmek için biraz karmaşıklık eklemek. Tamamen muhtemel olmayan bir şeyi hesaba katmak için büyük oranda sürdürülebilirliğe zarar vermek.

İyi bir yazılım mühendisi olmak, burada doğru dengeyi yakalamak anlamına gelir. İyi bir görüşmeci olmak, adayın bu dengeyi nasıl ve niçin seçtiğine ilişkin doğru yargı / çıkarımı vurmak anlamına gelir, değerlendirmek için genellikle görüşmenin diğer kısımlarını kullanarak.

Belki ama aşağıdakileri göz önünde bulundurun:

• Görüşmeler zor: İnsanlar stres altında. Bu, birisine verdiğiniz herhangi bir soruna ağır bir şekilde dahil edilmelidir

• Gereksinim Uzunluğu: Gereksinimler ne kadar uzun ve açık? Her şeyi dahil ettiğinden emin olmak için fazladan işlerini yaptın mı? Sonuç olarak, onlar sizin için açık olabilir, ancak gereksinimler belki de fazlaca geliştirilmiştir! Göreceli olarak basit bir problem için bir saatlik bir problem için yaklaşık 3 sayfa metin içeren bir iş görüşmesi yaptım. Bazen tüm bu metinler bir röportajı okumak ve yorumlamak için zor olabilir ve aynı zamanda yanlış da yorumlanabilir.

• Bazen Daha Az Daha Fazlası: Ana gereklilikleri gösteren birkaç madde işareti, cümle, veya örnekler ve ardından soru sormak ve gerektiğinde belki de onlara ulaşmak için birisiyle bir tartışma yapmak istiyorum. Sanırım söylemeye çalıştığım şey, önce test gereksinimlerinizin basit bir problem için fazla karmaşık olmadığını kontrol etmeniz gerektiğidir.

• İletişim Becerisi: Adaylara önce problem hakkında akıllıca sorular yöneltme ve sorular sorma yeteneklerini test etmelisiniz ve bir kez problemi anladıklarını gösterdikten sonra bunları uygulamaya koyabileceklerini öğrendikten sonra.

• Bottom Line: Sorunun anlaşıldığını kontrol etmediyseniz, gerçekte neyin üzerinde mühendisliği yapacağınızı bilmiyorsunuz. Diğerlerinin bunun iyi ya da kötü bir şey olabileceğini söylediği gibi, ancak sorunla ilgili anlayışı kontrol etmediyseniz veya aday ile iletişim kurmadıysanız, sorunu genel olarak anlamalarını ve ne yapmaları gerektiğini bilmek zordur.

Bunların çoğu, soruyu nasıl ifade ettiğiniz ve görüşmenin tamamını perspektife nasıl yerleştirdiğinize bağlanabilir.

“Ne kadar yaratıcı olduğunuzu görelim. 2 + 2 nedir?” Gibi. Dört? Tek bulabileceğiniz en basit, açık ve kesin cevap mı? Bir görüşme sırasında etkilemek için istekli olan genç / giriş seviyesi geliştiricileri, "Kodlama becerilerinizi test etmek veya bir programcının ne kadar iyi olduğunuzu görmek istiyoruz." "çok sofistike bir şey yap" demek. Hepimiz basit düşünmek isteriz ki, işleri daha da zorlaştırdığı durumlar dışında en iyisidir.

Birisinin her zaman aşırı mühendislik işlerine yatkın olup olmadığını anlamanın yolları vardır. Çok karmaşık bir şeye bir kod örneği verin ve daha basit bir çözüm isteyin. Birisi işe yaramayacağını düşündüğünüz bir çözüm sunduğunda, bu, eleştiriye nasıl tepki verdiklerini görmek için harika bir fırsat. Şahsen, birisinin yeni fikirlere açık olduğunu görmek ve aynı hataları tekrar tekrar yapacak olanlardan daha iyi bir çözüm önermek istiyorum.

Ve gerçekte, işe yaramadığı zaman kodumuzu değiştirme fırsatımız olmaz mı? Başlangıçta tasarım altında ya da tasarım üzerinde yapabilirsiniz. Basit çözümü tanıdığınızda, uygulanması daha kolay olmaz mı?

Bu bağlıdır, ancak genellikle hayır.

Genel olarak tasarım, deneyimle öğrenilen bir beceridir. Aaronaught'ın Marjan ile bağlantılı bu ilerleyişin açıklaması genellikle iyi bir şeydir .

Herhangi bir biçimde iletişim de içeriğe çok bağlıdır. Bir bağlamda bir şeyi kastediyor gibi net bir şekilde anlaşılan, farklı bir bağlamda başka bir şeyi açıkça ifade etmek olabilir. Hangi soruların sorulacağını bilmek, aynı zamanda deneyimle gelen bir şeydir.

Düşünceleri ve kararları hakkında nasıl düşündükleri, çözümlerinden çok daha önemlidir. Çözümlerini ve bunlarla ilgili kararlarını gözden geçirmeden, geliştirildiği bağlamı tam olarak değerlendiremezsiniz.

Yukarıdaki ilerleme göz önüne alındığında, aşırı mühendislik çözümü olan bir aday, basit olan adaydan daha iyi olabilir.

Ayrıca: Hangi seviyedeki pozisyon için çalışıyorsunuz? Giriş veya orta seviye bir adaydan fazla mühendislik yapmak, üst düzey bir adaydan fazla mühendislik yapmaktan daha az sorun yaratır.

Programcı sorunu çözmediyse, fazladan kodun tümü kodlayıcının yanıt vermemeyi engelleme girişimidir. Bu konu hakkında pek bir şey bilmeyen bir öğrenci tarafından yapılan deneme sınavında kullanılan aynı tekniktir. Zorlayıcı bir konu hakkında tartışacak, ancak cehaletinin kelime sayımı ile maskelenmesini umduğuyla ilgisiz bir konu.

Programcı sorunu çözdiyse ancak çok daha fazla kod eklediyse, bazı programlama alanlarının diğerlerinden daha büyük toleranslar gerektirmesi nedeniyle programcının arka planını göz önünde bulundurun.

Örneğin, otomatik pilotu ticari bir yolcu uçağında çalıştıran kod, ücretsiz bir Android oyunundan çok başarısızlığa karşı daha az tolerans gösterir. Ulaşılması zor olan ve güncellenmesi neredeyse imkansız olan gömülü aygıtları programlamak için kullanılan bir geliştirici, günde 15 güncelleme yapabilecek bir geliştiriciden daha fazlasını kodlama eğiliminde olacaktır.