Jak mogę polepszyć swoje pytania podczas wywiadów na tablicy? [Zamknięte]

Siedziałem podczas wywiadów i zauważyłem dużą rozbieżność między osobami o podobnych kompetencjach w odpowiadaniu na pytania na tablicy podczas wywiadu.

Ogólnie rzecz biorąc, umiejętność jasnego wyjaśnienia swojego myślenia, pisanie czytelnego kodu za pomocą pióra z suchą gumką, unikanie długich chwil ciszy zwykle skutkowało korzystniejszymi recenzjami kandydata, mimo że ostatecznie odpowiedzi były równie poprawne.

Jak można poprawić się w zadawaniu pytań na tablicy? Czy są sposoby na lepsze przygotowanie?

Powinieneś kupić małą tablicę i ćwiczyć, ćwiczyć, ćwiczyć. Poproś znajomych, aby zadali Ci pytania z książki, takiej jak Wywiady programistyczne . Następnie rozwiąż problem i wyjaśnij im swoje procesy myślowe dokładnie tak, jak w prawdziwej transakcji. Twoim celem jest nie brzmieć jak oszalały. Chcesz wyrazić jasne myśli. Nawet jeśli nie możesz rozwiązać problemu, pokaż im, że twój proces myślowy jest inteligentny i właściwy.

Pisanie odpowiedzi na tablicy nie jest intuicyjne. To wymaga praktyki. Byłem nauczycielem jednego z tych programów szkoleniowych SAT i spędziłem wiele godzin na szkoleniu, pisząc na tablicy i wyjaśniając nasze procesy myślowe. Na początku programu większość ludzi potknęła się o swoje słowa i pisała okropnym pismem ręcznym. Pod koniec wyglądaliśmy jak wytrawni weterani. Nie chcesz wyglądać tak jak my na początku programu.

Morał tej historii: nie idź na rozmowę nieprzygotowaną. Rozwiązywanie problemów na tablicy jest czymś, co powinieneś ćwiczyć.

Są trzy pytania, na które należy odpowiedzieć podczas wywiadu na tablicy:

1. Czy potrafisz rozwiązać problem?
2. Czy potrafisz jasno powiedzieć o problemie i rozwiązaniu?
3. Czy możesz otrzymywać informacje zwrotne od innych?

Więc nie o to chodzi, chodzi o to, jak do niego dotarłeś , i na tym oceniają cię ankieterzy.

Czy potrafisz być w tym lepszy? Tak, możesz:

Następnym razem musisz wyjaśnić coś swoim rówieśnikom (innym studentom, jeśli studiujesz lub innym współpracownikom, jeśli pracujesz):

1. Przeciągnij je na tablicę
2. Podnieś pióro i gumkę
3. Zacznij wyjaśniać problem
4. ???
5. Zysk

Och, i nie wstydź się. Po prostu załóż, że twoje szkice i pseudo-kod i tak będą ssały i zamiast tego będą improwizować. Celem jest osiągnięcie odpowiedzi wraz z rówieśnikiem i zawsze być otwartym na opinie od rówieśników. Punkty bonusowe, jeśli możesz rozwiązać problemy. Im więcej to robisz, tym lepiej sobie z tym radzisz. Praktyka czyni mistrza.

Inne niż pisanie kodu; naucz się rysować diagramy UML i rozmawiać o nich. To wszystko pola, koła i strzałki, a typy, które zwykle rysujesz, to diagramy klas, diagramy sekwencji i (bardzo rzadko) diagramy przypadków użycia. We wszystkich innych przypadkach wystarczy narysować pola, koła i strzałki.

Tablice służą nie tylko do przeprowadzania wywiadów

To może wydawać się radykalnym pojęciem, ale kiedy zadaję kandydatowi pytanie na tablicy, porównuję jego odpowiedź w myślach do kilku ostatnich przypadków, gdy kolega używał tablicy, aby coś mi wyjaśnić lub poprosić o pomoc. To nie tylko test do przeprowadzenia w czasie rozmowy kwalifikacyjnej, to ważna umiejętność codziennej komunikacji.

Więc w jaki sposób pomaga mi to przygotować się do pytań na tablicy, gdy udzielam wywiadu? Traktuję to jak rozwiązanie problemu razem z kolegą, a nie egzamin uniwersytecki. Oznacza to, że przedstawiam swoje pomysły, a kiedy potrzebuję więcej informacji, pytam. Jeśli coś nie wygląda dobrze, rozmawiam o tym z ankieterem, dopóki nie będę zadowolony.

Jeśli chcą, abyś odwrócił połączoną listę, a nie pamiętasz, czym jest połączona lista, zapytaj. Jeśli wynik końcowy jest lepszy, dam ci wyższe oceny niż facet, który wie, co połączona lista jest poza jego głową, ale kto pisze kiepski kod, aby nim manipulować. To nie tak, że zaczniesz pracę w jakiś magiczny sposób, znając cały nasz kod i inne zastrzeżone informacje, bez względu na to, jak jesteś doświadczonym programistą.

Moim zdaniem, wywiady nie są czymś, za co można wbijać, a gdybyś mógł, wypaczyłoby to postrzeganie tego, jak dobrze nadajesz się do pracy i odwrotnie. Łatwo jest stwierdzić, kiedy ktoś recytuje zapamiętaną odpowiedź. To jeden z powodów, dla których celowo staram się wypchnąć kandydatów poza ich strefę wiedzy. Chcę zobaczyć, jak reagują na pytania, na które się nie przygotowali.

Możesz myśleć, że jestem szalony, ale tak mocno odczuwam korzyści płynące z oceny czyjegoś procesu myślenia w porównaniu do ich zdolności zapamiętywania, że ​​powiedziałem ankieterom, kiedy w zasadzie zwracam odpowiedź na to samo pytanie na 3 ostatnich wywiadach i zapytaj, czy chcieliby wybrać coś trudniejszego. W każdym razie zawsze proszą mnie o „humor”, na wypadek, gdybym blefował, ale przynajmniej dostają uczciwą ocenę moich umiejętności.

Siedziałem podczas wywiadów i zauważyłem dużą rozbieżność między osobami o podobnych kompetencjach w odpowiadaniu na pytania na tablicy podczas wywiadu. Zasadniczo umiejętność jasnego wyjaśnienia swojego myślenia, pisanie czytelnego kodu za pomocą pisaka z suchą gumką, unikanie długich chwil ciszy zwykle skutkowało korzystniejszymi recenzjami kandydata, mimo że ostatecznie odpowiedzi były równie poprawne.

Nie pamiętam, kiedy ostatni raz pracowałem jako programista. Zawsze musiałem koordynować swoje działania z innymi, omawiać moje decyzje dotyczące projektowania i wdrażania oraz współpracować z innymi przy tworzeniu oprogramowania. Wykazanie umiejętności komunikacyjnych w wywiadzie to ogromny plus. Wywiady mogą cię denerwować, ale może to oznaczać zbliżające się terminy i presję związaną z pracą.

Chciałbym również powtórzyć mój komentarz. Biorąc pod uwagę zorientowany na zespół charakter inżynierii oprogramowania, musisz rozważyć coś więcej niż kompetencje techniczne. Umiejętność mówienia i pisania, szczególnie technicznie, jest ważna na większości stanowisk. Oceniłbym kompetencję kogoś na podstawie wszystkich czynników związanych z pracą, a nie tylko jego umiejętności tworzenia oprogramowania.

W jaki sposób można uzyskać lepsze wyniki w rozmowach na tablicy?

Czy są sposoby na lepsze przygotowanie?

Mogę wymyślić dwa powody, dla których ktoś może źle reagować na pytania na tablicy: nie ma dobrego zrozumienia informacji technicznych lub jest słabym mówcą / prezenterem. Oczywiście zawsze może to być jedno i drugie.

Sposób poprawy zależy od problemu. Ulepszenie techniczne polega na czytaniu, robieniu i zadawaniu pytań (zwykle w tej kolejności). Słaba umiejętność prezentacji wynika z praktyki, chociaż niektórzy ludzie są naturalnie dobrymi mówcami, podczas gdy inni nie. Myślę, że każdy może rozwinąć umiejętności komunikacyjne, ale osobowość będzie odgrywać ogromną rolę w tym, jak naprawdę ktoś jest dobry.

Wskazówki, jak postępować podczas rozmowy kwalifikacyjnej?

To zależy.

Więcej szczegółów jest zawsze dobre, nawet do całkowitego „zrzutu mózgu” ankietera. Jeśli nie podawałem wystarczającej ilości informacji, miałem ankieterów, którzy poprosili mnie o wyjaśnienie czegoś bardziej szczegółowego, i zazwyczaj zadawali bezpośrednie, bezpośrednie pytania dotyczące mojego projektu lub kodu.

Poświęcenie kilku minut na przemyślenie problemu przed ręką, bez mówienia lub robienia czegokolwiek jest zawsze dobrym pomysłem. Możesz wykorzystać ten czas na zadawanie pytań w celu wyjaśnienia, czego szuka ankieter. Zapewni to nie tylko możliwość przekazania ankieterowi dokładnie tego, czego szuka, ale także pokazanie, że możesz przemyśleć wiele możliwości.

Stawanie przed innymi i wygłaszanie prezentacji to umiejętność, której można się nauczyć. Jeśli jesteś słaba, polecam dołączyć do lokalnego rozdziału Toastmasters . Przećwiczysz część „tutaj jest temat, którego nigdy wcześniej nie widziałeś, teraz stań przed nieznajomymi i wyjaśnij go” stres, który napotykasz podczas wywiadów, a zwłaszcza część tablicy (jeśli występuje).

Podczas gdy inni opisywali aspekty fizyczne (ćwiczenie!), Zajmę się aspektami mentalnymi. Niezależnie od tego, jak dużo ćwiczysz, przeprowadzanie wywiadów to inny rodzaj środowiska. Nie będziesz sam ani ze swoimi przyjaciółmi - będziesz z kimś, kogo nigdy nie spotkałeś, kto próbuje ocenić twoje umiejętności.

Podczas ćwiczeń zawsze miej na uwadze to środowisko. Nie musisz im się pochlebiać ani ssać - Twoim celem jest pokazanie swoich kompetencji i postawy. Mów naturalnie i wyjaśnij, co się dzieje w twojej głowie. Chcą zobaczyć, jak myślisz, więc myśl głośno, rozmawiaj, dyskutuj i pozwól im zaangażować się w twoim umyśle.

Innym ważnym czynnikiem jest odbicie. Ćwicz problemy zawsze mają rozwiązania - kiedy utkniesz, możesz sprawdzić następny krok, napisać go, zrozumieć i nauczyć się. Ale twój ankieter nie jest instrukcją rozwiązania. Pomogą ci, ale nikt nie mówi „następnym krokiem jest zrobienie x” - powiedzą „czy myślałeś o y (co jest związane z x)?” Ćwicz więc bez odwoływania się do instrukcji. Poproś znajomego, aby podał ci niejasne, ale powiązane sugestie, i spróbuj stamtąd budować. Wyjaśnij, w jaki sposób ich sugestie pomogły ci rozwiązać problem. Zawsze pokazuj im, jak myślisz.

Mam nadzieję, że to pomoże!

Zadawanie pytań i unikanie założeń to kolejna kwestia w przypadku niektórych pytań na tablicy. To, co może się wydawać: „Hej, zrobiłem już coś takiego, a oto rozwiązanie ...”, to tak naprawdę pytanie o to, czy przyjmiesz te założenia i ześlizgniesz się z nóg. Nie chodzi o to, że ma to być podchwytliwe pytanie lub zawstydzić cię, ale ogólnie jest wiele drobiazgów, które po trafieniu któregokolwiek z nich pokażą się dość łatwo. Kilka przykładowych obszarów:

• Jak szczegółowe są wymagania? Czy jesteś pewien, jak wyglądałby wynik?
• Która miara złożoności jest ważniejsza, czasowa lub przestrzenna, i czy niektóre operacje są warte rozważenia bardziej niż inne, np. Jeśli budujesz strukturę danych, może istnieć potrzeba szybszego dostępu niż dodawanie lub usuwanie lub odwrotnie?
• Jak dobrze możesz wyjaśnić, dlaczego twoje rozwiązanie jest dobre?
• Czy możesz przejść przez przykład lub dwa pokazujące, jak zadziałałoby twoje teoretyczne rozwiązanie? Testowanie przypadków tutaj może być interesujące do odkrycia, jak gdyby były dane wejściowe od użytkownika, gdzie jest to potwierdzone i jak przekazywane są komunikaty o błędach itp.

Są oczywiście inne obszary, ale są to główne, które powinienem wziąć pod uwagę, analizując to, co zrobiłem w próbnym wywiadzie.