Dlaczego wywiady inżynierskie SW są nieproporcjonalnie trudne (w porównaniu z wywiadami badawczymi)? [Zamknięte]

Najpierw trochę o mnie. Mam doktorat z CS i pracowałem zarówno jako inżynier oprogramowania, jak i naukowiec w dziale badań i rozwoju, zarówno w Very Large Corporations, które znasz bardzo dobrze. Niedawno zmieniłem pracę i przeprowadziłem rozmowy kwalifikacyjne na oba rodzaje stanowisk (tak jak to robiłem w przeszłości).

Moja obserwacja: rozmowy kwalifikacyjne z inżynierami SW są o wiele bardziej trudne niż rozmowy z badaczami CS, ale praca naukowca jest bardziej opłacalna, bardziej konkurencyjna, bardziej satysfakcjonująca, interesująca i ma wyższą zaletę.

Oto typowa pętla wywiadu dla badacza:

• Wywiad telefoniczny, aby sprawdzić, czy moje badania są zgodne z badaniami laboratoryjnymi
• Osobiście: przedstaw prezentację na temat moich ostatnich badań przez godzinę (co może być warte 9 miesięcy pracy) i odpowiedz na pytania publiczności
• Osobiste wywiady z około 5 badaczami, w których zadają mi bardzo rozsądne pytania dotyczące mojej pracy / publikacji / patentów, w tym: pytania techniczne, gdzie moja praca pasuje do pokrewnej pracy i jak mogę rozszerzyć swoją pracę na nowe obszary

Oto typowa pętla wywiadu dla inżyniera SW:

• Wywiad telefoniczny, w którym zadawane mi są pytania dotyczące algorytmu i być może dokonuję kodowania. Dość standardowy.
• Wywiady osobiste na tablicy, w których wiercą F *** na ezoterycznych minutach C ++ (np. Jak działa polimorficzne wywołanie funkcji wirtualnej), algorytmy (sprawiają, że algorytm najkrótszej ścieżki dla wszystkich par działa dla wierzchołków 1B) , projektowanie systemu (projektowanie modułu równoważenia obciążenia bazy danych) itp. Odnosi się to do sześciu lub siedmiu wywiadów. Absurdalny, niedorzeczny.

Dlaczego ktokolwiek miałby się z tym pogodzić? Po co pytać o ciekawostki w C ++ lub pisać kod, żeby się udowodnić? Dlaczego nie uczynić wywiadu z SE bardziej podobnym do wywiadu z badaczem, w którym opowiadasz o tym, co zrobiłeś?

Jakie są techniczne rozmowy kwalifikacyjne w innych dziedzinach, takich jak fizyka, chemia, inżynieria lądowa, inżynieria mechaniczna?

Jest stosunkowo łatwo ustalić, czy jesteś technicznie wystarczająco kompetentny, aby przeprowadzić badania - masz publikacje, które menedżerowie ds. Rekrutacji mogą przeczytać, i te publikacje prawdopodobnie wskazują na innych ludzi, z którymi mogą porozmawiać, aby cię sprawdzić.

Z drugiej strony inżynieria oprogramowania jest dyscypliną, w której jest mnóstwo niekompetentnych marnotrawstw miejsca, dlatego należy zrobić wiele staranności, upewniając się, że zatrudniony facet rzeczywiście może napisać kod, który planujesz zatrudnić.

Wychodzę na kończynę.

Jako badacz z tytułem doktora już udowodniłeś wielu uznanym organizacjom swoją wartość i minimalne cechy jako badacza. Udało ci się obronić pracę magisterską przed komisją rówieśniczą i przekonałeś przynajmniej jedną recenzowaną publikację do opublikowania swojej pracy.

Z drugiej strony rozwój oprogramowania nie ma żadnych standardów kwalifikacji. Ludzie rutynowo zawyżają swoją bazę wiedzy. W rezultacie, wywiady programistyczne muszą wykonać całą pracę, jaką wykonują obrona doktorantów i wzajemna ocena w środowisku akademickim. Sprawiają, że udowadniasz, że naprawdę wiesz, o czym mówisz.

Zastanów się przez chwilę.

Gdybym próbował ubiegać się o to stanowisko badacza CS, nie sprawdziłbym mojego CV / CV. Po pierwsze, nie dostałbym się na rozmowę kwalifikacyjną. Dostałbym ustandaryzowany list „bez zaawansowanego stopnia”, który mówi mi, że nie miałem nawet kwalifikacji, by obejrzeć moje CV.

Moje pytania są następujące: „Dlaczego tak trudno jest uzyskać tytuł doktora?” I „Dlaczego potrzebuję doktoratu, aby być badaczem CS?” „Dlaczego tyle barier i przeszkód?”

Dlaczego ktokolwiek miałby się z tym pogodzić?

Jaki jest sens wykonywania całej tej pracy kursowej i drukowania badań w czasopismach i konferencjach? Dlaczego nie mogę po prostu przeprowadzić badań i zarabiać więcej niż za inżynierię?

Po co polegać na szkołach wyższych i publikacjach w celu ustalenia referencji? Dlaczego nie uczynić wywiadu badawczego bardziej podobnym do wywiadów SE, w których wszystko zależy od tego, co możesz teraz przypomnieć podczas wywiadu?

Mam teorię. Badania są zazwyczaj opłacane z dotacji, więc podaż gotówki jest wysoka. Mają wiadro pieniędzy do wydania i muszą po prostu znaleźć kogoś, na kogo je wydać. Niezależnie od tego, czy faktycznie osiągniesz coś na tym stanowisku, czy nie, firma / instytucja nie odnotuje straty netto, ponieważ i tak był to tylko rozliczony koszt. Zatrudnienie niewłaściwej osoby jest niewielkie. Najgorszym scenariuszem jest to, że wyrzucają wszystko, co zrobiłeś.

Z drugiej strony sukces lub porażka istniejących produktów spoczywa na barkach codziennych programistów. Zwłaszcza jeśli pracujesz nad rozwojem produktu, jesteś centrum zysków firmy. Dobrzy lub źli programiści mają ogromny wpływ, który znacznie przewyższa koszty ich pensji. Zły programista faktycznie powoduje szkody. Mogą cofnąć zespół, wprowadzić produkt na rynek itp. Konsekwencje zatrudnienia złego inżyniera SW są znacznie wyższe.

Nasza firma również „zadaje wiele trudnych pytań” i wyjaśnię dlaczego. Dbamy o to, czy naprawdę wiesz, w jaki sposób wykonuje się wirtualne wywołanie funkcji, ale nie dlatego, że jest to tak krytycznie wymagane dla zadania, które będziesz wykonywać.

Zamiast tego dbamy o to, ponieważ musimy wiedzieć, jak szybko można nauczyć się podstawowych rzeczy. Twierdzisz, że masz X lat doświadczenia? Dobrze, zadamy trudne pytania, aby dowiedzieć się, czy masz solidną wiedzę.

Nie wiesz, jak tworzone jest wirtualne wywołanie funkcji, ale wiesz wszystko na temat profilowania i optymalizacji? Świetnie, prawdopodobnie cię zatrudnimy - zdobyłeś solidną wiedzę w jednej dziedzinie, a więc na pewno zdobędziesz solidną wiedzę w innej dziedzinie.

Twierdzisz, że masz X-letnie doświadczenie w „opracowywaniu, debugowaniu i naprawianiu kodu C ++” i nie możesz wyjaśnić prostymi słowami, w jaki sposób wskaźnik wskazuje na obiekt? Przepraszamy, nie możemy cię zatrudnić - jeśli nie możesz tego zrobić, w jaki sposób wyjaśnisz trudniejsze problemy, kiedy będziemy musieli podejmować złożone decyzje techniczne?

Krótka odpowiedź: na rynku jest wiele osób, które twierdzą, że znają się na programowaniu, ale nie mogą programować.

Uwaga dodatkowa: Jestem zaskoczony, że nikt nie opublikował linku do eseju FizzBuzz .

Podejdę inną drogą i powiem, że problem może nie być tak duży, że wywiady z inżynierią oprogramowania są z natury trudniejsze, ale raczej, że różne sektory szukają różnych rzeczy, które pokazują się w ich stylu rozmowy.

Przeprowadziłem wywiady z dość szerokim zakresem sektorów (np. Firma typu start-up, mała firma, duża firma, wewnętrzny dział IT, firma programistyczna, organizacja badawcza) i wszystkie one mają inny sposób przeprowadzania wywiadów, który zwykle uważam za postępuj według następującego wzoru:

• Start-upy wydają się być związane z wiedząc, że można zacząć pisać kod teraz i może obsługiwać szybkim tempie środowiska. W związku z tym mają tendencję do martwienia się o to, ile wiesz z góry, ponieważ najwyraźniej nie chcą, abyś spędzał dużo czasu na szukaniu czegoś, co uznają za „podstawową” wiedzę. Przyznanie, że nie wiesz, że coś może nie być tak dobrą rzeczą w tym środowisku, jeśli oczekują tego od ciebie.
• Małe firmy zwykle szukają tych samych rzeczy, co start-upy, jeśli chodzi o to, ile wiesz, ale nie przejmują się tym, jak dobrze radzisz sobie w szybko zmieniających się środowiskach (zależy od pracy), a bardziej od tego, jakie umiejętności miękkie masz przynieś i jak dobrze będziesz pasować do firmy.
• Duże firmy i wewnętrzne działy IT wydają się być bardziej zainteresowane zapewnieniem określonego standardu wiedzy technicznej, ale nie są tak zaniepokojone, jeśli nie wiedzą wszystko od podstaw, ponieważ spodziewają się, że będą pewne czas poświęcony na przeszkolenie w zakresie oczekiwań firmy. Jest to zatem środowisko, w którym przyznanie się do czegoś nie wiesz, ale chęć uczenia się i studiowania może być postrzegane jako korzyść.
• W środowisku badawczym (tj. Z mojego doświadczenia wynika, że ​​naukowcy wspierają rozwój oprogramowania), zwykle martwią się, czy potrafisz pisać oprogramowanie, ale tym bardziej, jeśli jesteś gotów zrobić wszystko, co konieczne, aby upewnić się, że robią to, co robią. nie muszą trzymać cię za rękę, gdy próbujesz rozwiązać problem. Ponieważ jest to również środowisko badawcze, wydają się również zainteresowani tym, jak bardzo jesteś zainteresowany nauką nowych rzeczy.

Teraz zapomniałem wspomnieć o firmach programistycznych (np. Google, Microsoft), ponieważ mają one tendencję do robienia własnych rzeczy i zależnie od tego, jak dojrzała jest firma i dla jakiej grupy przeprowadzacie wywiady, szukają różnych rzeczy.

Pod koniec dnia i tak jak w przypadku większości rzeczy w życiu, wszystko zależy. Osobiście odkryłem, że niektóre firmy bardzo mocno koncentrują się na „wiedzy książkowej”, która może kosztować zdolność do rozwiązania problemów wyższego poziomu, podczas gdy inne firmy wydają się być bardzo zaniepokojone tym, jak dobrze radzisz sobie z problemami wyższego poziomu (tj. czy możesz zaprojektować schemat dla x ) i działać przy założeniu, że są gotowi zainwestować od trzech do sześciu miesięcy, aby w pełni przyspieszyć, zanim osiągniesz pełną produktywność.

Ponownie wywiad techniczny jest arbitralny i kapryśny.

Istnieje duża różnica między grillowaniem osoby na drobiazgach a sprawdzaniem, czy zna ona swój CS. Jak powiedziałem powyżej, mam ponad dekadę doświadczenia w C ++, ale zwykle bombarduję pytania dotyczące OOP / dziedziczenia. Czemu? Ponieważ po dodaniu obsługi szablonów używałem C ++ prawie wyłącznie do programowania ogólnego .

Przeprowadziłem wywiad z kilkoma firmami BigHouseHoldNameTech w Bay Area i Seattle, a jeden z najlepszych wywiadów dotyczył prawdziwych pytań, z którymi musieli sobie poradzić w pracy, dotyczących struktur danych i algorytmów [np .: Masz 300 miliardów punktów danych składający się z XYZ. Jak skutecznie przechowywać i wyszukiwać? ].

To w zasadzie pozwala dowiedzieć się, w jaki sposób kandydat może wkroczyć i pomóc w rozwiązaniu prawdziwych problemów, przed którymi stoisz. Absolutnie gorzej było także w przypadku innej firmy BigHouseHoldNameTech, ale zadali oni godziny niewiarygodnie tajemniczych pytań, które naprawdę powinieneś poszukać w instrukcji [ tj. Opisać główne różnice między płytką drukowaną w systemie Windows a Linuksem - i to nie było t dla pozycji poziomu jądra ]

Fundusze hedgingowe są dziwaczne z ich zamiarem torturowania ... spodziewaj się 8 godzin rozwiązywania problemów typu plecakowego na tablicy.

Jestem programistą (c / c ++) z ponad 20-letnim doświadczeniem w tej dziedzinie. Rodzaje wywiadów, które obecnie rutynowo obserwujemy (łamigłówki, wdrażanie struktur danych, algorytmy wyszukiwania itp. Na tablicy) nie zdarzały się zbyt często, z wyjątkiem newgrads. Jeśli dana osoba pracowała w renomowanej firmie przez rozsądny czas, był to uważany za dowód umiejętności pisania kodu. Teraz stało się bardzo szkolne i nie jestem pewien, dlaczego. Naprawdę, typowe rzeczy, o które proszą cię o kod, MOŻNA zapamiętać, więc robienie tego na tablicy naprawdę niczego nie dowodzi. W projekcie roboczym korzystałbyś z Internetu, aby coś zbadać, i nie pisałbyś od podstaw btrees lub list połączonych.

Myślę, że to kolejna moda na zarządzanie - podobnie jak scrum - z tym prawdopodobnie uruchomionym przez Google, Amazon i Microsoft. Wszyscy inni skopiowali tak samo, jak robili z oceną Jacka Welcha i szarpnięciem ... pamiętasz GE?

Jeśli jesteś kierownikiem ds. Rekrutacji i czytasz moje komentarze, POWINIENEŚ pytać kandydatów o to, jak mogliby rozwiązać niektóre problemy. Zamiast prosić ich o kodowanie tabeli skrótów, daj im problem dotyczący tabeli skrótów i zapytaj, jak by to rozwiązali.

Zgadzam się również z deweloperem powyżej tego postu, który powiedział: „daj im rzeczywisty problem, który firma musiała rozwiązać”!

„ale zwykle bombardowałem pytania dotyczące OOP / Dziedziczenia. Dlaczego? Ponieważ po dodaniu obsługi szablonów używałem C ++ prawie wyłącznie do programowania ogólnego”.

Zgadzam się również z powyższym. Kiedy pracujesz dla firmy, piszesz ICH kod. Nadal czasami mam problemy z zapamiętaniem wywołania C ++ przez składnię referencji, ponieważ starszy architekt w firmie, dla której pracowałem 15 lat, wolał używać wskaźników, a nie referencji. To był stary programista C. Więc tego wszyscy używaliśmy.