Zastanawiałem się, czy dobrym pytaniem byłoby zadać potencjalnemu pracodawcy podczas rozmowy kwalifikacyjnej na stanowisko programisty:
Jaka jest największa siła i słabość twojego zespołu programistów?
Wszyscy otrzymujemy to pytanie podczas wywiadu, więc dlaczego nie zadać im w zamian? Myślę, że to bardzo dobre pytanie, ponieważ moglibyśmy dowiedzieć się o zespole io tym, jak ta siła lub słabość może na nas wpłynąć, ale nie chcę denerwować ankietera.
Czy zadawanie tego pytania ma negatywną stronę podczas rozmowy o stanowisko programisty?
Odpowiedzi:
Nie jest to złe pytanie, ale osobiście nie powiedziałbym tego w ten sposób.
Zacznę od pytania o zespół programistów i ich procesy, a ja sam spróbuję ustalić, co jest w nich silnego i słabego. Trudno jest zadać dobry zestaw pytań, ponieważ byłyby różne w zależności od udzielonych odpowiedzi, na jakie stanowisko aplikujesz i co najbardziej cenisz w zespole programistów.
Najlepszą radą, jaką mogę ci dać, jest, aby pytania brzmiały bardziej jak rozmowa, a mniej jak przesłuchanie. Zaplanuj także listę rzeczy, o których chcesz dowiedzieć się z wyprzedzeniem.
źródło
Nie wyrażaj tego w ten sposób. Wszyscy nie znoszą fałszywego pytania o „mocne i słabe strony”. Nie trzeba go odwracać i używać ponownie.
Znacznie lepsze i bardziej autentyczne pytania dotyczące tych samych informacji byłyby następujące:
Opowiedz mi o historii swojego zespołu, jak zacząłeś, skąd się wzięli członkowie zespołu? Dokąd poszli poprzedni członkowie zespołu, kiedy odeszli?
Dlaczego chcesz wypełnić pozycję x?
Jakie są najtrudniejsze wyzwania, przed którymi pracujesz tutaj i twój zespół?
Czy poprowadzisz mnie przez cały cykl życia projektu, nad którym pracował ten zespół? Jak to się zaczęło i skończyło? Jaki jest związek zespołu z interesariuszami, testerami (jeśli istnieją), operacjami (jeśli istnieją) i utrzymaniem?
Kiedy coś pójdzie nie tak, jak reaguje twój zespół? Czy możesz mi powiedzieć o ostatnim / obecnym / największym kryzysie?
Odpowiedź na te pytania pomaga zobrazować, jak to jest pracować z tym zespołem. Są to wygodna okazja dla menedżera ds. Zatrudnienia, aby naprawdę opisać zalety / wady środowiska pracy. Łatwo jest również znaleźć fałszywą odpowiedź na takie pytania, która wskazywałaby, że coś jest ukryte.
źródło
Nie wiem, jak cenne jest pytanie, ponieważ zatrudniając ciebie (i ewentualnie innych ludzi) zmieniają dynamikę zespołu. Wyraźnie zidentyfikowali obecną słabość, czy to brak konkretnej umiejętności, czy po prostu potrzeba wykonania pracy przez innego programistę i starają się ją naprawić. Gdy tylko dodadzą osobę lub osoby do zespołu, dynamika się zmieniła, a ich odpowiedź może już nie być ważna.
Prawdopodobnie bardziej wnikliwe byłoby zapytanie o obecne praktyki zespołu i pożądane usprawnienia procesu. Obecny zespół pod względem sposobu wykonania pracy prawdopodobnie nie zmieni się radykalnie między rozmową kwalifikacyjną a potencjalną datą rozpoczęcia (chyba że termin rozpoczęcia upływa za kilka miesięcy) i pytaniem o pożądane usprawnienia procesów, metodologii i narzędzi może dać ci możliwość wskazania, że możesz posiadać umiejętności lub wiedzę, które pomogą Ci w tych wysiłkach.
źródło
Tak, jest więcej niż kilka wad zadawania tego pytania. Po pierwsze, jak dobrze osoba, o którą pytasz, naprawdę jest w stanie odpowiedzieć na to pytanie? Jeśli pytasz kogoś z działu HR na to pytanie, może on nie mieć pojęcia, jaka jest prawidłowa odpowiedź. Nawet menedżer może nie wiedzieć, czy zespół jest wciąż stosunkowo nowy, a rzeczy nie są tak dobrze znane pod względem dynamiki społecznej i robienia rzeczy. Drugą stroną jest to, jak jesteś przygotowany na gimnastykę językową, możesz zacząć od tego pytania, ponieważ istnieje więcej niż niewielka szansa, że każda odpowiedź będzie tak wypełniona modnymi słowami lub niejasna, że będzie miała niewielką wartość, chyba że wiesz, jak kontynuować z trudniejszymi pytaniami. Na przykład, jeśli twierdzą, że współpracują i dobrze dostarczają siły, czy jesteś przygotowany na dalsze przesłuchanie?
Z drugiej strony bardziej pokusiłbym się o odrobinę historii zespołu:
Byłoby to o wiele bardziej przydatne dla mojego umysłu niż pytanie, które może być postrzegane jako raczej obciążone. Choć mogę podziwiać wysiłek, zastanawiam się, jak dobrze każda firma badałaby dynamikę zespołu, aby znaleźć swoje mocne strony i styl do tego stopnia, aby móc je ujawnić.
Komentarz na temat zadawania tego pytania osobie, nie wiedząc, jak dobrze odpowiada, trafia do „gimnastyki językowej”, o której wspomniałem powyżej, ponieważ mogę łatwo przewidzieć, że ktoś powie coś podobnego, „Zatrudniamy tylko najlepszych tutaj” lub coś innego, co jest płytą główną dla odpowiedzi, która wymagałaby trochę sondowania, aby znaleźć odpowiedź, był to po prostu ktoś, kto próbował być uprzejmy, a nie oferować dokładnej odpowiedzi. Inną ogólną odpowiedzią byłoby to, że „wszyscy tak dobrze się dogadują”, że można się zastanawiać, czy istnieją ukryte działania wojenne, czy też zespół jest naprawdę grupą dojrzałych ludzi, którzy dobrze ze sobą współpracują.
Zamiast prosić o słabość, ponownie sformułuję pytanie: „Jakie jest największe wyzwanie Twojego zespołu programistów?” aby nie była uważana za osobę celowo próbującą wywołać problemy, ale raczej próbującą uzyskać wgląd w sposób postrzegania zespołu.
źródło
W pewnym momencie powinni przynajmniej odpowiedzieć pozytywnie, jeśli chcą zachęcić cię do dołączenia do zespołu. Każdy menedżer jakości / lider zespołu powinien zadawać sobie to pytanie codziennie. Nikt i nic nie jest idealne. Prawdopodobnie nie będziesz kontynuować tego, co działa, jeśli nie możesz tego rozpoznać.
Jeśli uznają to za obraźliwe lub nie uważają, że Twoim zadaniem jest zadawanie takich pytań, możesz nie chcieć pracy. Każda awersja do pytania może oznaczać brak poczucia bezpieczeństwa lub przynajmniej słabą komunikację.
Osobiście lubię ludzi, którzy atakują problemy, ponieważ chętnie je rozpoznają (czy to nie jest krok 1 z 12?).
Często istnieją problemy niezależne od lidera: budżet, starszy kod, wielkość personelu, dobrzy ludzie wyjeżdżają na lepiej płatne prace, charakter pracy oznacza, że programiści muszą przyjmować członków zespołu w różnych strefach czasowych, kierownictwo ma pewne tendencje w zakresie mikro-zarządzania, zasady obowiązujące w całej firmie, takie jak strój, godziny pracy itp. Każde z nich może negatywnie wpłynąć na zespół lub go ograniczyć.
źródło
Jedno z moich pytań do mojego potencjalnego przyszłego pracodawcy brzmi „dlaczego lubisz pracować dla swojej firmy?”
Ma na celu uzyskanie tego samego rodzaju informacji, ale w pozytywny i optymistyczny sposób. W świetnych miejscach pracy często przekonasz się, że Twój ankieter zaczyna gromadzić różnego rodzaju wspaniałe informacje, które naprawdę chcesz wiedzieć, aby podjąć decyzję!
źródło
To dziwne pytanie. Jakiej odpowiedzi lub informacji można się spodziewać?
Jeśli ubiegasz się o stanowisko programistyczne, spodziewam się, że zapytasz więcej o aspekty techniczne. Na przykład: „jakich metod używasz?”, „Jakich narzędzi używasz?” Itp.
źródło
Pytanie zespołu o opinię na jego temat nie jest tak prawdopodobne, jak pytanie o to, jak ich reakcja na wydarzenia zakończyła się wynikiem. Tego rodzaju pytania są znane jako pytania behawioralne i opierają się na założeniu, że zachowanie w przeszłości jest najlepszym predyktorem przyszłych zachowań.
Podczas przygotowywania pytań typu behawioralnego powszechnym sposobem ich modelowania jest zastosowanie metody STAR, co oznacza, że pytanie jest skonstruowane w taki sposób, aby prowadzić dyskusje do konkretnej sytuacji, zadania, działania i wyniku omawianej sytuacji.
Na przykład: „Jaki był największy sukces zespołu od momentu dołączenia do zespołu, co go stworzyło, jakie działania zespołu miały największy wpływ na jego realizację i jaki był wpływ tego sukcesu na firmę?”
źródło
Myślę, że to świetne pytanie, choć zadałbym to nieco inaczej. W przeszłości zadawałem pytania takie jak:
Te pytania pomagają pośrednio ujawniać informacje o tym, jak działa zespół. Wyzwania techniczne ujawniają podejście zespołu do (nowej) technologii. Zakres umiejętności ujawnia profesjonalne zaplecze zespołu. Silo-ing ujawnia kwestie własności kodu i ego.
źródło