Pytania dotyczące projektowania OO w wywiadach technicznych [zamknięte]

Ostatnio brałem udział w kilku wywiadach i firmy poprosiły mnie o więcej niż kilka odpowiedzi na pytania „zaprojektuj model [wstaw model]”.

1. Czy jest to obecnie normalne w branży? Jestem w świecie oprogramowania od ponad dwóch dekad i uczestniczyłem w moich wywiadach, ale widzę ten wzorzec w wywiadach, który pojawia się dopiero niedawno.
2. Czuję, że pytanie jest bardzo otwarte. Na przykład: Poproszono mnie o narysowanie schematu klasowego w celu zaprojektowania parkingu. Nie jestem pewien, jakiego poziomu szczegółowości oczekuje ankieter. Było to w teście online, w którym miałem dołączyć diagram Visio, więc nie mogłem zapytać ich, jakie są ich oczekiwania.
3. Czy używasz tego rodzaju pytań w trakcie rozmowy kwalifikacyjnej? Czy są one powiązane tylko z diagramami klas, czy też pytasz o sekwencję, schematy blokowe i ERD (oczywiście w oparciu o charakter stanowiska). Czy były skuteczne w procesie rekrutacji?

* Edycja odpowiedzi Kevina *

Na przykład: kompletne pytanie może brzmieć „Zaprojektuj system zarządzania parkingiem, którego można użyć do znalezienia wolnych miejsc”

I można zrobić z 2 klasy, ParkingLoti Slotczy mogę iść na dodanie IVehiclei Vehiclei Cari Motorcycleklas. Gdzie narysować linię?

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. Do pewnego stopnia tak. Każdy może recytować składnię lub skopiować / wkleić sobie rozwiązanie. Chcemy zatrudniać ludzi, którzy mogą rozwiązać problemy.

2. Oczekują, że udokumentujesz projekt na tyle, aby mógł go zrozumieć (i nie więcej).

3. Pytam ludzi, jak rozwiązaliby problem XYZ, tak. Zazwyczaj opisują to werbalnie. Chcę sprawdzić, czy zadają pytania w celu wyjaśnienia wymagań. Chcę zobaczyć, jak komunikują się z innymi programistami. Chcę zobaczyć, czy potrafią myśleć na własnych nogach.

To było dla mnie pomocne. Nie chcę małp kodowych, chcę inżynierów oprogramowania.

Uważam te pytania za raczej głupie. Prawdziwa odpowiedź brzmi „jakie są przypadki użycia?” Bez przypadku użycia nie ma potrzeby żadnego projektu. Na przykład tutaj jest całkowicie rozsądna odpowiedź na pytanie parkingowe:

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

Spełnia jeden oczywisty przypadek użycia.

Faktycznie demonstrujesz jedno użycie tego pytania w swojej edycji, gdzie nie udało się zaprojektować sprawnego modelu.

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!??

Wspominasz także o tworzeniu Cari Motorcycleklasach, co nie ma większego sensu bez dalszego rozważania. Twój projekt nie skorzysta na podziale Vehicle. Jeśli wprowadzisz Motorcyclebez różnic behawioralnych Vehicle, uważam, że to porażka.

Gdybyś nie zauważył ani jednego Vehicleproblemu, moglibyśmy skończyć podczas wywiadu na żywo. Jeśli to poprawiłeś (prawdopodobnie robiąc to a List<IVehicle>), użyłbym tego jako punktu wyjścia do przyjrzenia się ewolucji twojego projektu. Jest powód, dla którego wymagania są podstawowe, i nie ma dobrze zdefiniowanych przypadków użycia - tak w zasadzie działa świat.

Mogę rzucić na ciebie nowy wymóg, że „dwa motocykle mogą zaparkować w jednym miejscu”, aby zobaczyć, jak rozwinąłbyś swój projekt, aby sobie z tym poradzić. Może wtedy będziemy rozmawiać na temat współbieżności (co, jeśli mamy dwa wejścia i dwa samochody podjeżdżają jednocześnie - czy twój projekt zawiedzie? Jak? Co możemy zrobić, aby to naprawić?). Innymi możliwymi sposobami do zbadania byłyby sposób wdrożenia przypisanego parkowania, opłaty za parkowanie, stawki za rząd (być może w bliższych rzędach trzeba zapłacić więcej), parking ograniczony czasowo i jak znaleźć przestępców itp., Itp.

Uważam również, że twój proces myślenia wokół parkingów wskazuje na twoją ogólną zdolność do inteligentnej analizy problemu. Jeśli musisz zapytać mnie o podstawowe przypadki użycia i / lub wymyślić dziwne (np. 2 za 1 specjalne na parkingu), zaczynam się mocno martwić, że nigdy wcześniej nie korzystałeś z parkingu i że jesteśmy będzie miał trudności z komunikacją na temat czegoś nieco skomplikowanego.

Pytałem o to - kiedy tworzyliśmy diagramy klas do generowania kodu. Nadal robię to czasami, ale nie rutynowo. Podoba mi się to pytanie, ponieważ pozwala mi zobaczyć, jak osoba myśli.

Ma być otwarty. W porządku. Nie ma jednej właściwej odpowiedzi. Nie mam na myśli odpowiedzi; Chcę zobaczyć, dokąd to prowadzi. Myślę, że lepiej zadać pytanie osobiście, niż „e-mail w odpowiedzi”. Chodzi o komunikację, założenia i interakcję; nie tylko odpowiedź!

1. Tego typu wywiady widziałem co najmniej 12 lat temu. Takie podejście stosowałem przez ostatnie 6 lat. Doświadczenie pokazuje, że wybiera lepszych kandydatów do pracy niż zadaje 20 pytań i daje im wynik z 20 podejść.

2. Znowu sprawiłbym, że byłby to bardzo otwarty koniec. Celem jest zapewnienie kandydatowi miejsca do wykazania umiejętności. Posiadanie kandydata, który zadałby na tym etapie istotne pytania, byłoby dodatkowym atutem. Podobnie jak kandydat, który przyjmuje dobre założenia, ale zaznacza, że ​​były to założenia i należy je zweryfikować przed wdrożeniem.

3. Wymagam od wszystkich potencjalnych pracowników wykazania umiejętności potrzebnych do pracy podczas rozmowy kwalifikacyjnej. Programiści będą musieli zaimplementować trochę kodu i porozmawiać o jego projekcie. Jest bardzo skuteczny w zapobieganiu złym zatrudnieniom, ale przygotuj się na 90% odsetek niepowodzeń podczas wywiadu.

Projektowanie małego systemu jest w rzeczywistości bardzo odpowiednim ćwiczeniem, o które należy zapytać podczas wywiadu. Pokazuje twoje umiejętności w zakresie wymyślania dobrego oprogramowania dla problemu domeny.

Jednak wydaje mi się dziwne, aby po prostu poprosić o opublikowanie schematu klasowego online bez interakcji człowieka:

• Pominą istotę - uzasadnienie diagramu i to, co skłoniło cię do zaprojektowania tego w ten sposób.
• Nie ma „parapetu”, który powstrzymałby wnioskodawcę przed posunięciem się za daleko. Jeśli odzwierciedlisz ostateczną implementację na diagramie, prawdopodobnie będziesz mieć dziesiątki klas i nieczytelny schemat.
• Umiejętność narysowania diagramu klas UML nie jest tak naprawdę istotną umiejętnością, to tylko jedna notacja OO. Jest możliwość tworzenia solidnych projektów.

W wywiadzie na żywo idealnymi krokami, których oczekuje się od kandydata, byłyby:

• Porozmawiaj o problemie z rekruterem i zacznij wyrażać podstawowe rozwiązanie słownie, zadając pytania i dostosowując się, gdy rekruter daje bardziej precyzyjne potrzeby.
• Wstań i naszkicuj ogólny widok systemu oraz sposób, w jaki komponenty mogą ze sobą współdziałać. Może to być najczystszy styl UML, mogą to być tylko pola i kółka.
• Napisz test, albo test akceptacyjny wysokiego poziomu, albo test jednostkowy dla jednego z komponentów / klas.
• Zacznij pisać odpowiednią implementację.

Mam nadzieję, że w pewnym momencie osoba rekrutująca zgromadzi wystarczającą ilość informacji o umiejętnościach kandydata i nazwie to dniem. Celem nie jest wdrożenie w pełni działającego rozwiązania (chyba że jest to jedna z tych bezpłatnych usług w rozmowach maskujących).

Pytania OOP są otwarte. Nie ma poprawnej lub złej odpowiedzi, ale istnieją pewne zasady, których oczekują ankieterzy (np. Używanie konstruktora do inicjalizacji zmiennych, utrzymywanie małych metod, stosowanie enkapsulacji / kompozycji / polimorfizmu / dziedziczenia, jeśli dotyczy, itp.).

Zawsze oczekuj pytań dotyczących struktury danych, OOP i bazy danych w wywiadach, są one bardzo częste. Książki takie jak „łamanie wywiadu z kodowaniem” i „ujawnienie wywiadów programowych” mogą pomóc ci się przygotować.

Niedawno zostałem poproszony o przedstawienie projektu parkingu. Nie otrzymałem żadnych przypadków użycia, ale wspomniałem o tym kilka później. Uważam, że mój projekt nie pasował do tego, co miał na myśli ankieter. Zgadzam się, że każdy projekt oprogramowania jest ważny tylko dla danego przypadku użycia. Wracając do pytania z wywiadu, uważam, że mój ankieter nie miał żadnego doświadczenia w projektowaniu. Ci ludzie wierzą, że wiedzą, o co proszą. To kolejna historia, czy to rzeczywiście prawda, czy nie.