Ile pomocy powinienem udzielić podczas wywiadów technicznych? [Zamknięte]

Podczas wielu wywiadów technicznych jestem proszony o występ lub zasiadanie. Zadajemy pytania logiczne i proste problemy programistyczne, które rozmówca ma rozwiązać na papierze. (Wolałbym, żeby mieli dostęp do klawiatury, ale to jest problem na inny czas.) Czasami czuję, że ludzie wiedzą, jak podejść do problemu, ale są rozłączeni przez zdenerwowanie lub jakieś wtórne odgadnięcie pytania ( nie są przeznaczone do podstępnych pytań).

Nigdy nie słyszałem, aby mój szef udzielał jakiejkolwiek pomocy lub podpowiedzi. Po prostu dziękuje rozmówcy za odpowiedź (bez względu na to, jak dobrze lub źle jest) i przechodzi do następnego pytania lub problemu. Ale wiem coś na temat króliczej nory, którą porażka i nerwy mogą cię sprowadzić w dół, i jak to wyłącza twój umysł, i nie mogę się zastanawiać, czy udzielenie pomocy teraz i wtedy ostatecznie pomogłoby nam ostatecznie uzyskać bardziej zdolnych programistów więcej nieudanych wywiadów.

Czy powinienem udzielać wskazówek i pomocy zdezorientowanym rozmówcom (a jeśli tak, to jak daleko mam się posunąć, zachowując sprawiedliwość wobec lepiej przygotowanych kandydatów)?

Kiedy byłem w podobnej sytuacji, powiedziałem rozmówcy: „Udawaj, że jestem Google. Jeśli potrzebujesz czegoś po prostu powiedzieć”.

W jednym pytaniu rozmówcy musieli być w stanie obliczyć objętość cylindra, więc nie przeszkadzało mi to, gdyby ktoś powiedział: „Będę musiał znaleźć w Google formułę objętości cylindra”. Chciałem wiedzieć, czy potrafią zaatakować problem, a nie, czy zapamiętali formuły. Do pracy musieli dobrze zrozumieć, jak przełożyć prawdziwy świat na oprogramowanie, więc była to ważna koncepcja.

Z drugiej strony nie zamierzałem im mówić, że potrzebowali tej formuły.

Masz rację, że nerwy mogą stanowić problem, ale nadal oczekuję, że ludzie będą w stanie wyrazić swój proces myślowy, nawet jeśli będą nerwowi. Po prostu nie udzielenie odpowiedzi było nie do przyjęcia.

Masz dwa podejścia, które działają zarówno w przypadku rozwiązywania problemów, jak i krótkich pytań technicznych:

1. Pierwszego używa Twój szef: nie udzielaj żadnej pomocy, aby sprawdzić, jak dana osoba zachowuje się w stresującym kontekście. Jest to całkowicie poprawne podejście i może dać pewne wskazówki na temat osoby. W końcu, kiedy zatrudnisz tę osobę, ona nie będzie w stanie otrzymywać stałej pomocy od wszystkich swoich kolegów.

2. Drugim jest zapewnienie wskazówek i wsparcia. Poziom wsparcia nie ma większego znaczenia; liczy się tylko to, że im więcej pomocy zapewnisz osobie, tym mniej będziesz musiał doceniać jej sukces.

Osobiście uważam, że powinieneś poświęcić wystarczająco dużo czasu, aby upewnić się, że dana osoba nie jest w stanie rozwiązać problemu samodzielnie i sprawić, że dana osoba nie będzie w stanie rozwiązać problemu bez pomocy. Ale wtedy możesz udzielić progresywnej pomocy, dopóki nie powiesz osobie samej odpowiedzi.

Przykład:

- Czy możesz mi powiedzieć, jak tworzyć właściwości tylko do odczytu w języku C #, tj. Właściwości o wartości, które można zainicjować tylko w konstruktorze i których nie można później zmienić?
- Oczywiście. Po prostu używam słowa kluczowego readonly.
- Jesteś pewny? Czy możesz mi wyjaśnić różnicę między właściwością a polem?
- Hm. Właściwość to ... widzisz ... weź i ustaw ...
- Ok. Zatem pole jest zmienną zadeklarowaną w klasie lub strukturze i prawidłową w zakresie klasy / struktury, podczas gdy właściwość jest jak pole, ale zapewnia także mechanizm odczytu, zapisu lub obliczania wartości. Co teraz readonly? Czy jest używany z właściwościami?
- Uważam, że jest używany tylko na polach ...
- Racja. A co z właściwościami?
- Nie można ich czytać tylko.
- Jesteś pewny? Co z właściwościami, które mają tylko pobierające?
- Są tylko do odczytu.
- Czy to oznacza, że ​​ich wartość zawsze pozostanie taka sama?
- Tak.
- Nie, nie bardzo. Fakt, że masz właściwość z modułem pobierającym, nie oznacza, że ​​jej wartość nie zmienia się w czasie trwania instancji klasy. Jeśli obiekt pobierający odnosi się do pola, które jest zwiększane za każdym razem, gdy uzyskujesz dostęp do właściwości, zwracana wartość będzie stale wzrastać.
- Dobrze.
- Więc? Czy masz pomysł na sposób wdrożenia właściwości o wartości, która nigdy się nie zmienia?
- Nie.
- Możesz użyć pola tylko do odczytu. Czy wiesz, co to jest zaplecze?
[...]

Udzielenie odpowiedzi jest dobrym pomysłem we wszystkich przypadkach. Było kilka przypadków, w których rozmówca skomentował moją odpowiedź w interesujący sposób, pokazując, że nawet jeśli nie był w stanie odpowiedzieć na pytanie w pierwszej kolejności, nadal wie powiązane rzeczy.

Ponadto, po prostu zadając pytanie bez dalszej pomocy, nie masz zbyt wielu informacji o osobie, pomijając fakt, że ona zna lub nie zna odpowiedzi . Udzielanie pomocy progresywnej może pozwolić ci zobaczyć, jak dana osoba myśli o problemie.

Może również pokazywać inne rzeczy, których dana osoba nie wie. Weźmy powyższy przykład: gdybym zatrzymał się przy pierwszej odpowiedzi, nie wiedziałbym, że dana osoba nie jest w stanie wyjaśnić różnicy między polem a właściwością lub że nie wie, co to jest pole zaplecza.

Jeśli osoba odpowie natychmiast, jest w porządku. Jeśli potrzebuje pomocy, nie ma w tym nic złego. Jeśli sam odpowiesz na pytanie, jest to zły znak i mam nadzieję, że rozmówca będzie w stanie odpowiedzieć na pozostałe.

Zawsze lubię pomagać ankietowanym, jeśli utkną w jakiejś prostej rzeczy (np. Nazwa określonego wzorca, jeśli oczywiście wiedzą, co to jest), i pozwalam im rozmyślać o szczegółach takich jak nawiązywanie połączenia z bazą danych. Jeśli jednak próbują coś zaprojektować, nie mówię wiele, ponieważ nie chcę ich prowadzić ani wyrzucać, jeśli myślą o czymś innym niż przypuszczam, że idą.

Pamiętam, że pytający zapytał mnie o rozwiązanie konkretnego problemu, który miał bardzo konkretny wynik, ale nie był w stanie przekazać mi jasno tego pytania. Opisuje to sytuację, w którą napotyka wielu rozmówców. Czasami puste spojrzenie nie wynika z tego, że dana osoba nie jest dobrym rozwiązaniem problemu, ale dlatego, że osoba zadająca pytanie nie jest jasna w swoim pytaniu. W takim przypadku podejście twojego kolegi do mówienia i nie robienia nic tylko dowodzi, że kandydat nie myśli tak jak twój kolega lub nie znajduje się w jego głowie. Myślę, że wyjaśnienie pytania innymi słowy może zapewnić lepsze wyniki dla wszystkich zainteresowanych.

Biorąc pod uwagę, że programiści (przynajmniej większość z nas) nie pracują w próżni, a wywiady są wystarczająco stresujące bez sztucznych ograniczeń, chętnie udzielę takiej pomocy, o jaką pyta rozmówca lub potrzebuje.

Ale weź to wszystko pod uwagę przy podejmowaniu ostatecznej oceny rzeczywistego poziomu kompetencji wnioskodawcy.

Ktoś, kto szuka pracy na wyższym stanowisku, ale potrzebuje dużej pomocy, zadzwoni.

Osobom starszym oferuję krótkie, otwarte pytania i zwracam większą uwagę na zadawane pytania niż na odpowiedź. Znajduję starszych ludzi, którzy słuchają, komunikują się, używają aktywnego słuchania, wyjaśniają, a następnie dostarczają rozwiązania, które lubię.

W przypadku „inżynierów liniowych” zastosowałem technikę programowania testów, w której dajesz kandydatowi komputer i problem, a po kilku godzinach wracasz. W tej sytuacji z góry zapytaliśmy wnioskodawcę, jaki system operacyjny i narzędzia preferują (również interesująca część wiedzy programisty). Kiedy zostały ukończone, jako grupa poprosiliśmy ich o przedstawienie rozwiązania i dlaczego jest ono lepsze od innych rozwiązań - przegląd kodu. Wszystkie umiejętności oczekuję od doświadczonego inżyniera w dniu 1.

Co ważne, cały zespół przeprowadzający wywiady poświęcił popołudnie na wykonanie tego samego testu, więc wiedzieliśmy, że test był sprawiedliwy. Spędziliśmy godzinę badając podejście każdej osoby, tak jak robiliśmy to z rozmówcą, co dało nam poczucie różnych podejść.

Ta druga technika pozwoliła nam znaleźć jednych z najlepszych „nieuczciwych” programistów (kiepskie CV, kiepskie umiejętności prowadzenia wywiadów), jakie kiedykolwiek znalazłem.

Wolę rozpoczynać rozmowy od łatwego pytania budującego zaufanie, aby kandydat czuł się dobrze z tym procesem. Kiedy to działa, nadal pozwala ci zebrać jak najwięcej informacji z późniejszych pytań, nie dając przewagi kandydatom, którzy lepiej rozumieją mowę ciała niż materiały związane z pracą.

Czasami udzielenie odpowiedzi minor hintspodczas rozmowy ustnej pomaga zobaczyć, jak dobrze kandydat rozumie dany temat. Powinny być jednak no hintsprzeprowadzane standardowe testy, do których przeprowadzenia zobowiązany jest każdy kandydat.

Zasadniczo są pewne rzeczy, two main thingsktóre możesz chcieć wiedzieć o potencjalnym kandydacie:

a) Cechy osobowe - czy pasuje dobrze do Twojej firmy lub zespołu

b) Umiejętności techniczne - czy ma on dobre zaplecze techniczne i zainteresowanie wybieraniem nowych rzeczy

Aby dowiedzieć się o tych punktach, musisz zaangażować potencjalnego kandydata w rozmowę. Ważne jest również, aby upewnić się, że kandydat ma comfortable during the interviewna celu maksymalne zrozumienie jego obecnych umiejętności (zarówno miękkich, jak i technicznych), a także jego potencjału do wykonania pracy.

Ponadto umiejętności komunikacyjne potencjalnego kandydata są równie ważne, jak jego umiejętności techniczne i kompetencje do rozwiązywania problemów.

Należy zwrócić uwagę na umiejętności komunikacyjne. Jeśli kandydat nie ma jasności co do pytania, powinien zadać pytania w celu wyjaśnienia. To jest, moim zdaniem, dobra rzecz. Zbyt często podejmowane są złe decyzje, ponieważ pewne założenia są podejmowane podczas czytania specyfikacji lub, w tym przypadku, przetwarzania pytania podczas rozmowy kwalifikacyjnej. Kandydat może odpowiedzieć na podstawie tych założeń i całkowicie nie dociera do zamierzonego punktu. Pytanie może być błędne lub może być kandydatem. W obu przypadkach wyjaśnienie za pomocą komunikacji pokazuje cenną umiejętność, której powinni szukać pracodawcy.

Myślę, że ostatecznie sprowadza się to do twojej osobowości jako ankietera, a to, co uważasz za ważne, dlatego naprawdę ocenia kandydata.

Osobiście cenię praktyczne / pragmatyczne możliwości nad akademickimi / ezoterycznymi ciekawostkami. Bardziej interesuje mnie kandydat, który może przyjść, dostać się do pracy i skutecznie przyczynić się w jakiś cenny sposób do każdego projektu (projektów), nad którym są zatrudniani, niż jestem przekonany, jak dobra jest ich pamięć do drobiazgów.

Więc trenuję trochę, jeśli kandydat utknie w czymś ezoterycznym, rzadko używanym niuansie lub przypadkowym przypadku, który może być istotny w złożonym pytaniu podczas rozmowy kwalifikacyjnej, ale rzadko, jeśli w ogóle jest istotny w prawdziwym życiu. Zwłaszcza wszystko, co mogliby uzyskać w ciągu kilku minut w Google lub przy pomocy podręcznego podręcznika lub pisać „ustaw i zapomnij”.

Nie będę ich jednak trenować w codziennych, codziennych, powszechnych, podstawowych, fundamentalnych sprawach. To są rzeczy, które chcę im być wrodzone.

Myślę, że zależy to od sytuacji podczas wywiadu i pytań. Użyłem obu technik.

Dlaczego mogę nie zadawać pytań uzupełniających? Kiedy próbuję znaleźć odpowiedź osoby na stres. Przeprowadziłem wywiady z osobami, które pracowały w bardzo stresujących warunkach, a to, jak dobrze sobie radziły ze stresem, było kluczowym czynnikiem w naszych ocenach, dlatego zadaliśmy bardzo trudne pytania, na które nikt nie byłby w stanie odpowiedzieć bez stresu.

Gdy próbuję poznać ich wiedzę techniczną, zadaję pytania uzupełniające, które mogą zawierać wskazówki dotyczące tego, czego szukam. W przeciwieństwie do myśli kierownika, który powiedział, że musisz zadawać wszystkim te same pytania, aby być uczciwym, uważam, że jest to uczciwe, o ile zostanie spełnionych kilka warunków. Najpierw wszyscy otrzymują to samo podstawowe pytanie. Po drugie, nie powinieneś zadawać pytań uzupełniających, aby pomóc tylko jednej osobie. Jeśli pozwoliłeś innym flądrować bez pomocy, musisz pozwolić flądrze bez pomocy. Po drugie, powinieneś porównać wyniki kandydatów w tym pytaniu, nie tylko pod względem ich ostatecznej odpowiedzi, ale także pod względem tego, jak trudno było wyciągnąć je z nich. Ten proces nadal traktuje wszystkich uczciwie.

Zależy, jakiego programisty chcesz. Introwertyk, który potrafi napisać świetne 20 wierszy kodu na papierze, będzie dobrze dla ciebie wyglądał. Deweloper oprogramowania, który może pracować na milionach kodów linii w zespole, aby skutecznie produkować dobre oprogramowanie, prawdopodobnie nie będzie zbyt dobrze. Uwielbiam tego rodzaju rozmowy kwalifikacyjne jako kandydaci - wiele mi mówią o tym, jak szef traktuje swoich pracowników i jaka jest kultura pracy. W przypadku takim jak ten, kiedy opuściłem wywiad, powiedziałem: „Dziękuję - Oszczędzaj nam trochę czasu, jeśli nie zadzwonisz, nie zadzwonię”. Zapytany dlaczego wskazałem, że nie chcę pracować dla firmy, która doprowadziła mnie do upadku.

Podejście prawdopodobnie zapewni lepsze możliwości rozwoju oprogramowania. Wasze podejście do bossów byłoby dobre dla kolekcjonerów śmieci i facetów, którzy trzymają lizaki Stop / Go przy robotach drogowych.

Tworzenie oprogramowania to wysiłek zespołu, a nie gra solo / czytanie w myślach / gra interaktywna. Ile projektów kończy się niepowodzeniem, ponieważ oprogramowanie wykonuje to, o co poproszono, a nie to, czego chcieliśmy.

Byłem ostatnio w podobnej sytuacji. Kierunek, który otrzymałem od mojego kierownika i HR, był taki, że musimy być całkowicie uczciwi wobec wszystkich 6 rozmówców, więc musiałem zadać ten sam zestaw pytań technicznych przy minimalnej pomocy, aby zobaczyć, jak radzi sobie każdy z rozmówców. Czasami, gdy znali odpowiedź, ale trzymali się terminu technicznego lub czegoś, pomogłem im pośrednio w niektórych pytaniach, które doprowadziły ich do tego terminu. Po technicznej rundzie odbyła się druga runda wywiadu na temat cech osobowości i zachowania, jeśli udało im się przejść przez pierwszą rundę.

Częścią tego, czego chcesz od pracownika, jest ktoś, kto może wchodzić w interakcje z resztą zespołu. To prawda, potrzebujesz kogoś o wymaganych umiejętnościach. Ale potrzebujesz także kogoś, kto wie, kiedy potrzebuje pomocy i ma do tego samoświadomość i umiejętności społeczne. Ten ostatni zestaw parapetów będzie budował firmę na dłuższą metę lepiej niż jakikolwiek konkretny Du-Jour w języku komputerowym.

Z mojego punktu widzenia wywiad to próbna sesja coworkingowa, a nie test . Staram się przede wszystkim odpowiedzieć na pytanie „jak to jest pracować z tą osobą?” Czasami nawet udaję, że zapomniałem odpowiedzi na pytanie, aby ćwiczenie było bardziej oparte na współpracy.

Czy kiedykolwiek pracowałeś z kimś, z kim po prostu nie mogłeś dostać się na tę samą stronę, gdy rozmawiałeś przez jakiś problem? A może ktoś, kto zadał zbyt wiele pytań zamiast wskakiwać i rozwiązywać problemy? W wywiadzie głównie upewniam się, że osoba, z którą rozmawiam, nie jest jedną z nich. Jest tam silny element chemii.

W trakcie tego procesu oczywiście nauczę się też takich rzeczy, jak: „czy pisze czysty kod”, „czy zna wymagane koncepcje” i „czy może sprytnie narzucić problem, aby dojść do wglądu?” Kandydat nadal będzie tym, który „prowadzi” i pisze kod. Ale po drodze mam nadzieję, że będzie bardziej zrelaksowana i zobaczę jej wersję, która jest bliższa temu, co faktycznie widziałbym z dnia na dzień jako współpracownik.