Teknik görüşmelerde OO Design ile ilgili sorular [kapalı]

Son zamanlarda oldukça az sayıda röportaja katıldım ve şirketler tarafından "bir model ekle" sorularını birkaç defadan fazla cevaplamaları istendi.

1. Günümüzde sektörde bu normal mi? Yirmi yılı aşkın süredir yazılım dünyasında bulundum ve görüşmelerden payımı aldım, ancak görüşmelerde bu modelin son zamanlarda ortaya çıktığını görüyorum.
2. Sorunun çok açık uçlu olduğunu hissediyorum. Örneğin: "Otopark tasarımı" na bir sınıf diyagramı çizmem istendi. Görüşmecinin ne kadar ayrıntı beklediğinden emin değilim. Bu, bir visio diyagramı eklemem beklenen çevrimiçi bir testti, bu yüzden onlara beklentilerinin ne olduğunu soramadım.
3. Görüşme sürecinde bu tür soruları kullanıyor musunuz? Bunlar sadece sınıf diyagramları ile mi ilgili, yoksa sıra, akış şemaları ve ERD'ler de (pozisyonun niteliğine göre tabii) soruyor musunuz?

* Kevin'in yanıtı için düzenle *

Örneğin: Tam bir soru "Boş alanları bulmak için kullanılabilecek bir otopark yönetim sistemi tasarlamak" olabilir.

Ben 2 sınıfları ile yapılabilir, ParkingLotve Slotya ben eklemek için gidebiliriz IVehicleve Vehicleve Carve Motorcyclesınıfları. Çizgiyi nerede çizerim?

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

1. Bir dereceye kadar, evet. Herkes bir sözdizimi okuyabilir veya çözüm yoluyla kopyalayıp yapıştırabilir. Sorunları çözebilecek insanları işe almak istiyoruz.

2. Tasarımı, anlayabilecekleri (ve bundan daha fazlasını değil) yeterince belgelemenizi bekliyorlar.

3. İnsanlara XYZ problemini nasıl çözeceklerini soruyorum, evet. Genellikle sadece sözlü olarak tanımlarlar. Gereksinimleri açıklığa kavuşturmak için soru sorup sormadıklarını görmek istiyorum. Diğer programcılarla nasıl iletişim kurduklarını görmek istiyorum. Ayakları üzerinde düşünüp düşünemeyeceklerini görmek istiyorum.

Benim için yararlı oldu. Kod maymunları istemiyorum, yazılım mühendisleri istiyorum.

Bu soruları aptalca buluyorum. Gerçek cevap "kullanım örnekleri nelerdir?" Bir kullanım çantası olmadan, herhangi bir tasarıma gerek yoktur. Örneğin, otopark sorusuna mükemmel bir cevap:

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

Bir bariz kullanım durumunu karşılar.

Aslında bu sorunun tek bir kullanımını, uygulanabilir bir model tasarlayamadığınız düzenlemenizde gösterirsiniz.

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

Ayrıca oluşturma Carve Motorcyclesınıflardan da bahsediyorsunuz , bu da daha fazla düşünmeden çok mantıklı değil. Tasarımınız alt sınıflardan faydalanmayacaktır Vehicle. Herhangi Motorcyclebir davranış farklılığı olmadan tanıtırsanız Vehicle, başarısız olduğunu düşünürdüm.

Tek Vehicleproblemi fark etmediyseniz , canlı bir röportajda hemen hemen tamamlanırdık. Bunu düzelttiyseniz (muhtemelen bunu a yaparak List<IVehicle>), bunu tasarımınızın evrimine bakmak için bir başlangıç ​​noktası olarak kullanırdım. Gereksinimlerin temel olmasının bir nedeni var ve iyi tanımlanmış kullanım örnekleri yok - dünyanın işleyişi bu.

Tasarımınızı ele almak için tasarımınızı nasıl geliştireceğinizi görmek için "iki motosikletin bir yuvaya park edebilmesi" konusundaki yeni gereksinimi size atabilirim. O zaman belki de eşzamanlılık hakkında bir konuşma yaparız (Ya iki girişimiz varsa ve iki araba aynı anda yukarı çıkarsa - tasarımınız başarısız olur mu? Nasıl? Bunu düzeltmek için ne yapabiliriz?). Keşfedilecek diğer olası yollar, atanmış park etme, park ücreti alma, sıra başına ücretler (belki daha yakın satırlar daha fazla ödemek zorunda), zaman sınırlı park etme ve suçluların nasıl bulunacağı vb.

Ayrıca, park alanları etrafındaki düşünce sürecinizi, bir sorunu akıllıca analiz etme yeteneğinizin bir göstergesi olarak değerlendiririm. Bana temel kullanım durumlarını sormak ve / veya tuhaf toplarla karşılaşmak zorunda kalırsanız (park etme konusunda 1 özel ürün için 2 gibi), daha önce hiç bir park yeri kullanmadığınızdan ve biraz karmaşık bir şey hakkında iletişim kurmakta zorlanacak.

Bunları soruyordum - kod üretimi için sınıf diyagramları oluşturduğumuzda. Hala zaman zaman yapıyorum ama rutin olarak değil. Soruyu seviyorum çünkü kişinin düşündüğünü görmemi sağlıyor.

Açık uçlu olması amaçlanmıştır. Bu iyi. Doğru bir cevap yok. Aklımda bir cevap yok; Nereye gittiğini görmek istiyorum. Bence "cevap e-postası" değil, bizzat sormak daha iyi bir soru. Bu iletişim, varsayımlar ve etkileşim ile ilgilidir; sadece bir cevap değil!

1. En az 12 yıl önce bu tür röportajları gördüm. Son 6 yıldır kullandığım yaklaşım bu. Deneyimler, iş için 20 soru sormaktan daha iyi adaylar seçtiğini ve 20 yaklaşımdan bir puan verdiğini göstermektedir.

2. Yine, ben de çok açık uçlu yapardı. Amaç, adayın yeteneklerini göstermesi için alan sağlamaktır. Bu aşamada ilgili sorular soran bir adayın olması bir artı olacaktır. İyi bir varsayımda bulunan ancak varsayımlar olduğunu belirten ve uygulamadan önce gözden geçirilmesi gereken bir aday olduğu gibi.

3. Tüm potansiyel çalışanlara, görüşme sırasında ihtiyaç duydukları becerileri göstermeleri için gerekli koşulları sağlarım. Programcılar için, bazı kodları uygulamaları ve tasarımları hakkında konuşmaları gerekecektir. Kötü işe alımları önlemek için çok etkilidir, ancak görüşmede% 90'lık bir başarısızlık oranına hazırlıklı olun.

Küçük bir sistem tasarlamak aslında bir röportajda sormak için çok uygun bir uygulamadır. Bir etki alanı sorununa iyi bir yazılım çözümü bulma becerilerinizi gösterir.

Ancak, sadece insan etkileşimi olmadan çevrimiçi bir sınıf diyagramı göndermeyi istemek garip buluyorum:

• Şemayı özleyecekler - şemanın arkasındaki akıl yürütme ve sizi bu şekilde tasarlamanıza neden olan şey.
• Başvuranın çok ileri gitmesini engelleyecek bir "korkuluk" yoktur. Diyagramdaki son bir uygulamayı yansıtırsanız, muhtemelen onlarca sınıfınız ve okunamayan bir şemanız olacaktır.
• Bir UML sınıf diyagramı çizebilmek gerçekten önemli bir beceri değil, diğerleri arasında sadece bir OO gösterimi. Sağlam tasarımlar oluşturma yeteneği.

Canlı bir röportajda, bir adayın atmasını beklediğim ideal adımlar:

• İşverenle ilgili sorun hakkında konuşun ve sözlü olarak temel bir çözüm ifade etmeye başlayın, sorular sorun ve işveren daha kesin ihtiyaçlar sağladıkça ayarlayın.
• Ayağa kalkın ve sistemin genel bir görünümünü ve bileşenlerin birlikte nasıl etkileşimde bulunabileceğini çizin. UML'in en saf tarzı olabilir, sadece kutular ve daireler olabilir.
• Bileşenlerden / sınıflardan biri için yüksek seviye kabul testi veya birim testi yazın.
• İlgili uygulamayı yazmaya başlayın.

İnşallah bir noktada işveren adayın becerileri hakkında yeterli bilgi toplayacak ve bunu bir gün olarak adlandıracaktır. Amaç, tam bir çalışma çözümü uygulamak değildir (gizemli görüşmelerde bu ücretsiz hizmetlerden biri olmadıkça).

OOP soruları açık uçlu. Doğru ya da yanlış cevap yoktur, ancak görüşmecilerin görmeyi beklediği bazı ilkeler vardır (değişkenleri başlatmak için bir kurucu kullanmak, yöntemlerinizi küçük tutmak, kapsülleme / kompozisyon / polimorfizm / kalıtım kullanmak, vb. Gibi).

Görüşmelerde daima veri yapısı, OOP ve veri tabanı ile ilgili sorular beklenir, çok yaygındır. “Kodlama röportajını kırmak” ve “maruz kalan programlama röportajları” gibi kitaplar hazırlamanıza yardımcı olabilir.

Çok uzun zaman önce bir otopark için bir tasarım çıkması istendi. İlk etapta herhangi bir kullanım vakası verilmedi, ancak birkaç sonra bahsetti. Tasarımımın görüşmecinin aklında olana uymadığına inanıyorum. Herhangi bir yazılım tasarımının yalnızca belirli bir kullanım durumu için geçerli olduğunu kabul ediyorum. Bu röportaj sorusuna geri dönersek, görüşmemin gerçek dünya tasarım deneyimi olmadığına inanıyorum. Bu insanlar ne istediklerini bildiklerine inanıyorlar. Bunun doğru olup olmadığı başka bir hikaye.