Ostatnio brałem udział w kilku wywiadach i firmy poprosiły mnie o więcej niż kilka odpowiedzi na pytania „zaprojektuj model [wstaw model]”.
- 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.
- 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.
- 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, ParkingLot
i Slot
czy mogę iść na dodanie IVehicle
i Vehicle
i Car
i Motorcycle
klas. 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; }
}
Odpowiedzi:
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.
Oczekują, że udokumentujesz projekt na tyle, aby mógł go zrozumieć (i nie więcej).
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.
źródło
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:
Spełnia jeden oczywisty przypadek użycia.
źródło
Faktycznie demonstrujesz jedno użycie tego pytania w swojej edycji, gdzie nie udało się zaprojektować sprawnego modelu.
Wspominasz także o tworzeniu
Car
iMotorcycle
klasach, co nie ma większego sensu bez dalszego rozważania. Twój projekt nie skorzysta na podzialeVehicle
. Jeśli wprowadziszMotorcycle
bez różnic behawioralnychVehicle
, uważam, że to porażka.Gdybyś nie zauważył ani jednego
Vehicle
problemu, moglibyśmy skończyć podczas wywiadu na żywo. Jeśli to poprawiłeś (prawdopodobnie robiąc to aList<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.
źródło
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ź!
źródło
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ść.
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.
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.
źródło
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:
W wywiadzie na żywo idealnymi krokami, których oczekuje się od kandydata, byłyby:
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).
źródło
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ć.
źródło
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.
źródło