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

39

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?

stackoverflowuser2010
źródło
12
Mam zamiar zgadywać i powiedzieć, że przeprowadziłeś wywiad w Google?
Pemdas
2
@ Ethel: Jeśli spojrzysz na glassdoor.com, gdzie ludzie anonimowo publikują swoje pensje, możesz zauważyć, że stanowisko badacza płaci od 10 do 20 tysięcy dolarów rocznie więcej niż porównywalny inżynier SW (ta sama lokalizacja, to samo pole). Anegdotycznie wiem, że moja pensja jest o około 25 tys. USD wyższa niż w przypadku moich innych przyjaciół, którzy w tym samym czasie ukończyli studia CS MS w mojej szkole. I to nie tylko wynagrodzenie; Widziałem, że doktoranci mają wyższe ścieżki kariery niż te bez nich. Nie mam bezpośrednich dowodów, ale widziałem, że doktoranci łatwiej zatrudniają się na poziomach CTO / VP.
stackoverflowuser2010
3
To szalone, ale najwyraźniej nie obejmuje „prawdziwych” zawodów inżynieryjnych. Znam mnóstwo inżynierów budownictwa i są zszokowani tym, co powiedziałem im o niektórych moich wcześniejszych wywiadach ... wielu powiedziało właśnie to, co zrobiłeś: „dlaczego miałbyś to robić?”
czerwono-brud
3
@el fuser - To zależy od pracodawcy. Wszystkie wywiady z inżynierią elektryczną poprosiły mnie, abym spojrzał na kod PLC, napisał kod PLC i / lub zrobił coś ze schematami elektrycznymi. Z jednej strony pierwsze pytanie brzmiało: „Co to jest prawo Ohma?” To był odpowiednik testu fizzbuzz ... jeśli tylko wziąłeś 4 lata inżynierii elektrycznej i nie możesz tego zrobić poprawnie, wywiad się kończy.
Scott Whitlock,
1
Scott: „jeśli wziąłeś tylko 4 lata elektrotechniki i nie możesz tego zrobić dobrze, wywiad się skończył”. Obawiam się, że mogłem oblać kilka z nich, ponieważ śmiałem się lub byłem obrażony. Wydaje mi się, że pochodząc ze środowiska badawczego uznajesz podstawową kompetencję za pewnik.
Omega Centauri,

Odpowiedzi:

45

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ć.

Wyatt Barnett
źródło
2
na szczęście takie rzeczy jak github i bitbucket ułatwiają zobaczenie, co zrobiła ta osoba. może złagodzić (lub znacznie zmniejszyć) potrzebę zadawania pytań dotyczących należytej staranności.
helloandre
3
dokładnie w punkcie. bardzo trudno jest oddzielić dobro od niedoszłych programistów. nawet z kodem do wyświetlenia, przeczytanie go i zrozumienie do poziomu możliwości oceny autora zajęłoby dużo czasu. artykuły naukowe, OTOH, są napisane dla czytelników, naprawdę zajmuje tylko kilka godzin, aby naprawdę je zrozumieć, zwykle zły jest rozpoznawalny w ciągu kilku minut.
Javier
3
Kod do pokazania to sztuczka - skąd wiesz, że Joe Interviewee tak naprawdę napisał ten kod, nie zmuszając go do napisania kodu?
Wyatt Barnett
Mam opublikowany artykuł i książkę w drodze. Zwykle ekrany techniczne ulegają zwarciu, ponieważ moja wiedza jest dobrze udokumentowana, chcą się upewnić, że jestem tym Mike'em Brownem
Michael Brown
1
Menedżerowie techniczni bardzo obawiają się zatrudniania naprawdę inteligentnych i doświadczonych specjalistów - tych, którzy mogą wiedzieć coś lepszego niż oni, dlatego mogą argumentować za i przeciw rozwiązaniu, a nie tylko robotom piszącym kod. Ostatecznie zatrudnienie kogoś, kto może odwrócić połączoną listę w ciągu minuty zamiast zatrudnienia naprawdę inteligentnych inżynierów, oznacza stratę wszystkich tych, którzy osiągają zysk finansowy z produktu. Jak to ujął Bjarne Stroustrup: „Organizacja, która traktuje swoich programistów jak kretynów, wkrótce będzie miała programistów, którzy będą chcieli i będą mogli działać tylko jak kretyni”.
Leo Heinsaar,
30

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.

Ryan Michela
źródło
17

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?

S.Lott
źródło
Rozumiem, co mówisz. Właściwy rodzaj rozmowy kwalifikacyjnej powinien pasować do właściwego rodzaju pracy? Czy to poprawna interpretacja?
stackoverflowuser2010
5
@ stackoverflowuser2010: Nie. Po prostu narzekam, że świat akademicki jest o wiele trudniejszy do włamania niż świat inżynierii oprogramowania. Masz wywiad jako SE. W akademii nie mogłem nawet wejść do drzwi. Twoja perspektywa jest tak mocno wypaczona, że ​​nie widzisz różnic. Akademia jest o wiele trudniejsza.
S.Lott
6

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.

Scott Whitlock
źródło
4
+1 W rzeczywistości pieniądze wydane na badania są uzasadnione opublikowanymi artykułami, więc jeśli kandydat ma dobrą listę tych z przeszłości, są szanse, że może wyprodukować więcej, co najprawdopodobniej zaspokoi każdego, kto akurat jest sprawdzenie, na co wydano grant badawczy.
Péter Török
@ Péter Török: Tak !!! Fundusze, które udzielają dotacji, wymagają następnie złożenia raportu, a najważniejszą rzeczą, na którą patrzą, jest liczba opublikowanych prac.
sharptooth
5

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?

sharptooth
źródło
To uczciwe, ale czy rzucasz dość szeroką siatkę, wykonując element techniczny, czy skupiasz się na danym obszarze?
rjzii
@Rob Z: Staramy się zadawać bardzo proste pytania na temat C ++ - głównie o wskaźniki i rekurencję, udostępniamy fragmenty zawierające około pięciu wierszy dobrze sformatowanego kodu i pytamy o szczegóły na temat tego, co i jak robią. Z pewnością nigdy nie pytamy o wielokrotne dziedziczenie wirtualne i kolejność inicjalizacji klas podstawowych w przypadku dziedziczenia wirtualnego.
sharptooth
Dlaczego pytania dotyczące funkcji wirtualnych są tak popularne? Czasami wydaje się, że tylko tyle trzeba się uczyć ...
Jé Queue
@Xepoch: Sądzę, że są one bardzo proste, a znajomość ich wewnętrznej pracy dobrze wskazuje, czy zależy Ci na tym, co dzieje się w środku, czy po prostu wklejasz razem linie kodu.
sharptooth
Myślę, że miałem szczęście w mojej karierze. Rzadko widziałem koder do wycinania i wklejania. Znam koderów złych praktyk (łącznie ze mną), ale przynajmniej był to ich własny projekt :)
Jé Queue
5

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 .

Nikita Barsukov
źródło
To prawda, ale możesz dość szybko stwierdzić, czy ktoś może lub nie może programować na podstawie jednego lub dwóch problemów z tablicą. Problemy z tablicą to nie to samo, co zadawanie różnych pytań z podręcznika, które pojawiają się podczas niektórych wywiadów.
rjzii
3

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ść.

rjzii
źródło
2

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.

czerwony brud
źródło
2

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.

Gość
źródło