Pytanie:
Jak rekrutujemy młodszych programistów w wieku, w którym wszyscy przygotowują się do rozmowy kwalifikacyjnej?
Indu
2018-12-28 00:33:57 UTC
view on stackexchange narkive permalink

Jako rekruterowi coraz trudniej jest zatrudnić dobrych programistów, ponieważ bardzo łatwo jest po prostu przygotować się do rozmowy kwalifikacyjnej, czytając którekolwiek z tych 14020 pytań do oprogramowania deweloperem! książki, które są obecnie niezwykle popularne.

Doszło do tego, że prawie nie możesz zadać pytania, jeśli kandydat nie zapoznał się już z przynajmniej wersją tego samego zadania, a zatem wie, z grubsza , jakie jest rozwiązanie.

Oczywiście, nie byłby to problem, gdyby wiedza o tych problemach była tym, czego szukamy ... z wyjątkiem tego, że nie tego szukamy. Nikogo nie obchodzi, czy wiesz, jak zastosować szybkie sortowanie do jakiegoś wymyślonego, zmyślonego przykładu. Nie chodzi o to, że wiesz , jak rozwiązać te problemy, chodzi o to, że możesz rozwiązać problem . Chcemy rozwiązań do rozwiązywania problemów , a nie osób zapamiętujących problemy .

Ponieważ kiedy już dostaniesz pracę, najprawdopodobniej nigdy więcej nie napotkasz żadnego z tych problemów z książki rozmów kwalifikacyjnych, więc to nie twoja zdolność zapamiętywania ich rozwiązań ma znaczenie; to Twoja umiejętność znalezienia rozwiązania na miejscu jest cenna. A jednak nie jest to już możliwe do przetestowania z powodu tych wszystkich zapamiętujących, które w kółko czytają pytania do wywiadu.

Jak rozwiązać ten problem? Ponieważ jestem szczerze zmęczony zatrudnianiem obiecujących programistów, którzy doskonale odpowiadają na każde pytanie podczas rozmowy kwalifikacyjnej, a kiedy faktycznie widzisz, jak kodują w prawdziwej sytuacji, zdajesz sobie sprawę, jak niewiele wiedzą.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/87662/discussion-on-question-by-indu-how-do-we-recruit-junior-software-developers-in-za).
23 odpowiedzi:
#1
+228
user1666620
2018-12-28 01:05:51 UTC
view on stackexchange narkive permalink

Zapewnij kandydatowi autentyczny test programistyczny podczas rozmowy kwalifikacyjnej - laptop podłączony do projektora z zepsutym projektem, z mieszaniną podstawowych i złożonych błędów, i poproś go o dodanie pewnych funkcji, ponownie od podstawowych do umiarkowanych złożony. Jest to coś, nad czym nikt nie może się naprawdę uczyć i faktycznie będzie to przykład ich umiejętności. Poproś pracowników technicznych, którzy rozmawiają z kandydatem, aby poznać jego osobowość i sposób, w jaki podchodzą do napotkanych problemów.

Podczas rozmowy kwalifikacyjnej na moje obecne stanowisko spędziłem 2 tygodnie na studiowaniu zasad programowania i wzorców projektowych , bazy danych itp. Udało mi się dobrze odpowiedzieć na wszystkie pytania teoretyczne i wydaje mi się, że trafiłem dobrze

Następnie wręczono mi laptopa, który był podłączony do projektora i pokazano rozwiązanie, które zawierało zepsutą stronę internetową ze zdefiniowaną liczbą błędów, które musiałem zdebugować i dodać kilka prostych funkcji. Chociaż nie byłem zbyt zaznajomiony z frameworkiem używanym przez firmę, byłem w stanie naprawić około połowę błędów, a następnie na podstawie tego, co widziałem, mogłem zgadnąć, jakie były przyczyny pozostałych błędów, i to wystarczyło, żebym wszedł do drzwi.

Cała sprawa, od pytań teoretycznych do sesji debugowania strony, trwała około 2 godzin.

Należy zauważyć, że to podejście, choć dostarcza wielu informacji, * wymaga * technicznie kompetentnego obserwatora, który oceni pracę respondenta.
@chrylis tylko pracownik HR-u jednorożca miałby techniczne know-how, aby zatrudnić kogoś bez konieczności posiadania osoby technicznej.Problem w tym, że PO mówi, że pytania dotyczące testów technicznych, które zadają, zostały już przygotowane.
Nie oznacza to, że większość działów HR i tak nie próbuje.
@chrylis w tym przypadku są kretynami i zasługują na każdego niekompetentnego jakiego dostaną
@chrylis Każde podejście będzie wymagało technicznie kompetentnego obserwatora.Po prostu nie ma żadnego sposobu, aby osoba nietechniczna oceniła umiejętności programowania, o ile mogłem powiedzieć.
Bądź _bardzo_ oczywisty w kodzie źródłowym, że to wszystko jest sztucznym źródłem.Nie chcesz, żeby ktoś myślał, że próbujesz uzyskać od niego dwie godziny darmowej pracy.
Zgadzam się z tą odpowiedzią.Chociaż nie było to związane z oprogramowaniem, kiedyś ubiegałem się o staż typu IT, gdzie dostałem konfigurację pulpitu z kilkoma rzeczami wyłączonymi / odłączonymi / nieprawidłowo skonfigurowanymi i uznałem, że taki test jest najbardziej odpowiedni dla tego, czym właściwie była pracaabout - rozwiązywanie problemów.Tak więc dopasowanie testu do rzeczywistej pracy ma duże znaczenie zarówno dla kandydata, jak i ankieterów
„ten proces wymaga obserwatora kompetentnego technicznie” ................ w przeciwieństwie do czego!?!?głosowanie nad tą kontrolą jakości jest * dziwniejsze niż kiedykolwiek *
@Fattie, zdziwiłbyś się, ile wywiadów technicznych przeprowadza się bez obecnego technicznie kompetentnego obserwatora, ponieważ ktoś pomyślał, że są zbyt drogie i możesz po prostu sprawić, by dział HR zadawał kilka gotowych pytań i czegoś się z tego nauczył.
Bardzo dobra odpowiedź.Dodam, że warto rozważyć posiadanie wielu scenariuszy o różnym stopniu trudności.Doświadczonych starszych rekrutów należy mierzyć inaczej niż rekrutów na poziomie podstawowym.
Przeprowadziłem wywiad z firmą, która zrobiła to za pomocą kodu wyszukiwania w swojej witrynie - kierownik wziął ich kod, wprowadził kilka błędów i przedstawił go, aby je znaleźć i naprawić.Pierwszym błędem, jaki znalazłem, nie był _nie_ ten, który wprowadził do testu.Mam pracę.
Po drugie, co powiedział @IanMacDonald.Poleciłbym kilku programistom zaprojektować mały przykładowy projekt przedstawiający Twój stos technologii i wprowadzić kilka celowych błędów.Pozwoli ci to ocenić umiejętności debugowania rozmówcy.Możesz również dodać testy jednostkowe, aby mogły zweryfikować poprawne rozwiązanie.
Alternatywnie do komentarza @IanMacDonald: zapłać kandydatowi.10 lub 15 dolarów za godzinę (wliczając czas podróży i cały okres przebywania kandydata na miejscu) to niewiele (dla firmy) i stłumi myśl, że dana osoba daje * bezpłatną * pracę.Dostają 100 $, naprawiasz kilka błędów, nikt nie jest nieszczęśliwy.Myślisz, że dostałeś dobrą ofertę, ponieważ to było około 2 godzin czasu na płacenie prawdziwemu deweloperowi, myślą, że dostali dobrą ofertę, ponieważ - chociaż cena była niska - liczyła się również ich podróż.
@Draco18s zakładał, że jest to niestandardowa strona internetowa lub aplikacja stworzona wyłącznie w celu przetestowania wydajności kandydatów, a to byłoby oczywiste z faktu, że ludzie obserwują Cię i rozmawiają z Tobą w środowisku prawie egzaminacyjnym.Każdy pomysł, że można to uznać za „pracę”, jest absurdalny, chyba że od kandydata oczekuje się zaangażowania w kontrolę źródła i pracuje w kodzie miłości, co byłoby całkiem oczywiste.
Taki test wymyśliłem lata temu i byłem zadowolony z zatrudnienia 95% kandydatów (w przeciwieństwie do ~ 40% przedtem).Istnieją również bariery, takie jak ekran telefonu z kilkoma gotowymi pytaniami na temat programowania oraz rozmowa kwalifikacyjna przed przyjściem kandydatów na test z programowania.Ten test pomaga wyeliminować osoby, które dobrze wyglądają na papierze, ale okazują się być pełne gówna.I to jest jak „Faceci w czerni” - tyle samo dotyczy tego, w jaki sposób kandydaci rozwiązują problemy, w jakiej kolejności itp., Jak naprawiania błędów i dodawania funkcji.Użyj kontroli źródła, aby łatwo zobaczyć ich zmiany!
@chrylis Nie wymaga to technicznie kompetentnego obserwatora.Przeprowadziliśmy taki 30-minutowy test, ale znacznie prostszy niż ten sugerowany w tej odpowiedzi, a 2/3 naszych kandydatów nie potrafiło napisać jednej funkcjonalnej linii kodu.Z reszty tylko jedna osoba mogła napisać coś nawet bliskiego kompletności funkcjonalnej, a skończyła to w 7 minut (i tylko z wcięciem i sformatowanym kodem).Myślę, że byłoby to bardzo oczywiste nawet dla kogoś, kto prawie nic nie wie o komputerach, które kandydaci zdali, a które zawiodły.
Jeśli kandydat ma problem z zrobieniem jakiegoś programu za darmo, nie zatrudniaj go.Kto potrzebuje ludzi z takim nastawieniem, w rzeczywistości dobrym sprawdzianem byłoby sprawdzenie, kto się sprzeciwia.W jednym z moich ulubionych wywiadów projektant zadał mi problem, który go irytował, a ja usiadłem i razem go rozwiązaliśmy, było naprawdę fajnie i pomogło mu rozwiązać problem, z którym się borykał.Nie skorzystałem z ich oferty, ponieważ oznaczałoby to pozostanie w Spokane ... ale to był mój wybór, byli naprawdę zdenerwowani, że nie podjąłem pracy (więc nie próbowali zdobyć darmowego programowania ani niczego takiego).
Jak można by uczynić to podejście skalowalnym?Wyobrażam sobie, że działa to dobrze, gdy jest używane oszczędnie, ale gdyby zaadoptowała to cała duża firma, czy nie wyszłoby ostatecznie słowo na temat konkretnych przykładów kodu, których używa firma?Jak zapewniłbyś sprawiedliwość, zakładając, że nie ma wystarczających zasobów, aby stworzyć inną wymyśloną aplikację dla każdego kandydata?
@ting05 utworzenie wielu błędów zajmuje tylko kilka minut.Nie potrzebujesz innej aplikacji dla każdego kandydata, tylko po jednej na każde stanowisko w bieżącym otwarciu.Jeśli kandydaci są racjonalnymi, samolubnymi aktorami, byliby szaleni, gdyby sabotowali samych siebie, mówiąc o teście.
Osobiście dałbym im zadanie do wykonania w swoim czasie i ufam, że to oni je wykonali.Obserwowanie, jak wykonują zadanie podczas oglądania, _bardzo_ denerwuje, a na tej podstawie nie udało mi się przeprowadzić wielu wywiadów.Nagle zapominam, jak tworzyć strony internetowe.Zwykle radzę sobie z presją, ale kiedy ktoś patrzy prosto na mnie, na nieznanej maszynie, z jakiegoś powodu nie mogę tego zrobić.Wiem, że jest to całkowicie osobisty problem, ale biorąc pod uwagę zadanie, które wykonuję w swoim czasie, jest o wiele lepsze, ponieważ wiem, że jestem kompetentnym programistą.
Jedna z najlepszych ocen przed rozmową kwalifikacyjną, jaką miałem (z jednej z „wielkiej czwórki”), obejmowała kod debugowania.Wystąpiło kilka problemów z jedną linijką w przypadku krótkich timerów, a następnie dodatkowe problemy z jedną linią w przypadku nieco dłuższych timerów.
@IanMacDonald dwie godziny darmowej pracy kandydata są warte ujemną kwotę.Marnujesz dwie godziny ankietera, który musi być wystarczająco kompetentny technicznie, aby samodzielnie rozwiązać problem i już zna domenę problemu.Nawet jeśli osoba przeprowadzająca rozmowę kwalifikacyjna nie jest obecna przez całe dwie godziny, przegląd rozwiązania wraz z formalnością i czasem przygotowania kandydata oznacza, że nie uzyskasz z tego żadnej wartości, jeśli spróbujesz w ten sposób uzyskać bezpłatne kodowanie.
Ta metoda jest wadliwa, ponieważ faworyzuje ludzi, którzy pracują według określonych metod.Liczy się wynik i jakość produktu końcowego, a nie sposób, w jaki się tam dostaniesz.
@user celem testu jest udowodnienie, że ludzie są w stanie zastosować wiedzę, którą posiadają, aby osiągnąć wyniki, a nie tylko odpowiedzieć na quiz.A czasami tak, metoda ma znaczenie - co wolisz, osoba, która wie, na czym polega problem i może wyjaśnić nie tylko, jak to naprawić, ale także dlaczego należy to zrobić w określony sposób, lub osoba, która musi wydać 30minut szukania rozwiązania?
@user1666620 problem polega na tym, że jeśli nie jest to problem z kodem niskiego poziomu, to wiele naprawiania błędów zależy od szczegółowej wiedzy o frameworku lub systemie, a będąc absolwentami, nie spodziewałbyś się, że to mają.
@user, a problem OP polegał na tym, że chcieli odfiltrować tych, którzy byli w stanie odpowiadać na quizy, ponieważ studiowali specjalnie dla nich, ale którzy są całkowicie niezdolni do wykonywania nawet prostych zadań programistycznych.
#2
+141
Alexander O'Mara
2018-12-28 05:18:42 UTC
view on stackexchange narkive permalink

kiedy już dostaniesz pracę, najprawdopodobniej już nigdy nie napotkasz żadnego z tych problemów z książki rozmów kwalifikacyjnych

Jeśli ich praca nie wymaga rozwiązywania tego rodzaju problemy, po co w ogóle je testować?

Dlaczego zamiast tego nie dać im prawdziwego problemu, z którym mogliby się spotkać w pracy?

To moja rekomendacja. Z pewnością będziesz mieć wiele przykładów rzeczywistych problemów w pracy do wyboru, aby znaleźć odpowiedni.

Wydaje się, że ta odpowiedź nie różni się znacząco od odpowiedzi [użytkownika1666620] (https://workplace.stackexchange.com/a/125407/16724).
W proponowanym rozwiązaniu są nieco podobne.Pomyślałem, że ważne jest, aby wyjaśnić, dlaczego ich obecna metoda nie testuje tego, czego faktycznie chcieli, i zasugerować, że nowe testy mogą być tak proste, jak wykorzystanie ostatnich wyzwań, przed którymi stanęli programiści, zamiast wymyślać nowe, wymyślone testy.
@jpmc26 Powiedziałbym, że ta odpowiedź jaśniej identyfikuje źródło problemu.PO wyraźnie zadaje niewłaściwe pytania.Jasne, ostatnia sugestia jest mniej więcej taka sama dla obu odpowiedzi, ale zatrzymuję się, aby zapytać PO „dlaczego zadajesz swoje obecne pytania?”to bardzo ważny dodatek.
Zgadzam się, OP napisał również: `` Oczywiście nie stanowiłoby to problemu, gdyby wiedza o tych problemach była tym, czego szukamy ... z wyjątkiem tego, że nie tego szukamy.` Co jeszcze bardziej dowodzi, że zadawane przez nich pytania są całkowicie bezcelowe
#3
+50
spickermann
2018-12-28 13:58:13 UTC
view on stackexchange narkive permalink

Mniej więcej rok temu zacząłem rozmawiać z kandydatami. Jest wiele tematów, które w branży są kontrowersyjne i na które nie ma tylko jednej poprawnej odpowiedzi. Odpowiedzi na pytania dotyczące tych tematów zwykle zaczynają się od „To zależy…” - na przykład:

  • Który framework jest najlepszy?
  • Jaką bazę danych preferujesz i dlaczego?
  • Czy określony wzorzec projektowy jest rzeczywiście przydatny?
  • Skoncentruj się na nowych funkcjach lub najpierw napraw błędy?

Najpierw pytam kandydatów o zdanie. Kiedy już zrozumieli, po prostu wybieram coś przeciwnego i sprzeciwiam się temu. Albo podaję przykład, w którym ich wybór nie byłby dobrą odpowiedzią i pytam ich, czy i jak chcą zmienić swoją odpowiedź za pomocą tego nowego przykładu / wymagania? Poniższa dyskusja wiele mi powie.

  • Czy do wywiadu zapamiętali tylko niektóre fakty, czy też rzeczywiście mają doświadczenie w tej dziedzinie i dobre przykłady, aby udowodnić swój punkt widzenia? Właściwie byłem bardzo zaskoczony, jak często ich argumenty brzmią: ponieważ zawsze robiłem to w ten sposób
  • Jak dobrze są w stanie przedstawić swoje argumenty i złożone szczegóły techniczne? Czy są dobrzy w nauczaniu?
  • Jak radzą sobie z oporem? Czy starają się przekonać, czy starają się zadowolić, czy też zaczynają być agresywni lub aroganccy? Czy są otwarci na naukę?

Zdaję sobie sprawę, że może to być bardzo stresujące dla kandydata. Dlatego należy to zrobić bardzo ostrożnie.

Jeszcze tylko jedna uwaga: pomijając aspekt stresowy, gdybym miał takie pytanie o coś, o czym faktycznie wiedziałem, że jest poprawna odpowiedź dla danej domeny, a ankieter z przekonaniem argumentował, że moja odpowiedź jestraczej mętny obraz kalibru firmy, chyba że było wyraźnie oczywiste, że ankieter tak naprawdę nie wierzył w to, o co się kłócili.
@Hammer pytania, które są tutaj zadawane, są konkretnie pytaniami, na temat których wiele osób ma różne (i ważne) opinie.Nawet w ramach określonej domeny nie ma czegoś takiego jak „powszechnie akceptowane najlepsze ramy”.I argumentowałbym, że jeśli ktoś nie radzi sobie z odrobiną stresu podczas rozmowy kwalifikacyjnej, może to wskazywać, jak poradzi sobie ze stresem w codziennych problemach w pracy.
Z pewnością powiedziałbym, że nie ma „najlepszego” w większości dziedzin, w wielu okolicznościach - po prostu nie we wszystkich.Nie zgadzam się z tą odpowiedzią, po prostu staram się ją wyjaśnić - chcę wyjaśnić, że ta technika zadziała tylko w przypadku pytań, które są wystarczająco niejasne, aby faktycznie mieć wiele poprawnych rozwiązań, a nawet wtedy, jeśli nie wybierzesznieopłacalna inna odpowiedź, o którą można się kłócić, chyba że jest oczywiste, że po prostu grasz w adwokata diabła.
@HammerN'Songs powinno być możliwe sformułowanie kontrargumentu w taki sposób, że jako ankieter nie jestem uważany za „wiem lepiej”, ponieważ w rzeczywistości nie mogę wiedzieć lepiej, jeśli nie mam praktycznego doświadczenia w tym konkretnym przypadkuw takim przypadku to, o czym wiedziałeś, że jest poprawne, może wcale nie było takie poprawne.
Podoba mi się ta odpowiedź.spróbuję włączyć to do wywiadów, które przeprowadzę w przyszłym tygodniu.
@KristenHammack Nie sądzę, aby na podstawie wywiadów oceniać czyjąś umiejętność radzenia sobie ze stresem w miejscu pracy.Znam wielu ludzi, którzy robią bałagan podczas wywiadów, ale kiedy coś uderza w fanów podczas rzeczywistej pracy, nie są one nawet fazowane i po prostu to naprawiają.Są bardzo różnymi „źródłami stresu” i nie można ich używać do przewidywania o sobie nawzajem.
@Onyz Ukończyłem na szczycie mojej klasy po stażu, który zaowocował ofertą, służyłem w wojsku, osobiście reagowałem na nagłe przypadki medyczne i całkowicie zbombardowałem moją pierwszą rozmowę kwalifikacyjną po ukończeniu studiów na pracę dla programistów, ponieważ pracowałemsię o wymyślonym pytaniu, które mi zadali.Wyobrażam sobie, że gdybyś porozmawiał z tym pierwszym ankieterą, prawdopodobnie powiedzieliby ci, że nie sądzili, że mam stopień naukowy.Mam tylko nadzieję, że nie wystawią tak strasznego popisu na moją uczelnię;)
Jeśli spierasz się o stanowisko, którego tak naprawdę nie zajmujesz, wydaje się, że stworzyłoby to precedens nieuczciwości między pracodawcą a pracownikiem.Może rozpocznij debatę słowami „pozwólcie mi zagrać adwokata diabła” lub coś w tym rodzaju.
To zdecydowanie najlepsza odpowiedź z jednego prostego powodu: starannie omija wszystkie książki i przeprowadza wywiady z bzdurami, które zanieczyszczają proces rekrutacji.Miałem zamiar napisać odpowiedź zasadniczo mówiącą „cóż, udziel im odpowiedniego * wywiadu * zamiast quizu z książki”, ale to robi to lepiej.
@various - Myślę, że źle zrozumiałeś Spickermanna.Nie chodzi o argumentowanie na absurdalne stanowisko, w które sam nie wierzysz.To bardziej jak „Ok, więc myślisz, że framework A jest najlepszy. Słyszałem, że ludzie mówią świetne rzeczy o frameworku B, zwłaszcza w (wybierz jedną rzecz, gdzie B jest lepsze niż A). Co na to powiesz?”- żadna przygotowana odpowiedź z książki go z tego nie wyciągnie, ale faktyczna wiedza w tej dziedzinie z łatwością to zrobi.
#4
+34
selbie
2018-12-28 01:59:10 UTC
view on stackexchange narkive permalink
  • Miej wielu ankieterów . W rozmowie kwalifikacyjnej powinni uczestniczyć Twoi najsilniejsi inżynierowie w zespole - na pewno chcą pracować z ludźmi lepiej niż z tymi, którzy mają problemy, prawda? Pozwól innym inżynierom przeprowadzić własny wywiad 1 na 1. Poproś innego inżyniera o wykonanie pierwszych ekranów telefonu.

  • Zadaj otwarte pytanie projektowe . dla problemu o średniej złożoności. Poproś kandydata o napisanie pliku nagłówkowego, oświadczeń klasowych, diagramów ramkowych itp. Czy kandydat zadaje wyjaśniające pytania? Gdy skończy z podstawowym projektem, wprowadź nowy wymóg, który zepsuje jego projekt. Czy jest w stanie się obracać? Wybierz jedną część jego projektu i zbadaj głębiej.

  • Zadaj pytanie, czy mają głębokie zrozumienie podstaw platformy . Kilka przykładów, które zadałem:

    • „W jaki sposób kompilator C ++ implementuje metody wirtualne?”
    • „Jak działają zamknięcia w JavaScript?”
    • „Wyjaśnij, kiedy kiedykolwiek chciałbyś używać UDP zamiast TCP”.
    • „Po wpisaniu www.foo.com w pasku adresu przeglądarki opowiedz mi o całej aktywności sieciowej i protokołach związanych z wyświetlaniem zawartości na ekranie.”
  • Poszukaj prawdziwego zainteresowania programowaniem . Dotyczy to bardziej kandydatów na studia i młodszych inżynierów, a mniej doświadczonych pracowników. Przykładowe pytania to „Opowiedz mi o programie, który napisałeś dla zabawy, a który nie był przeznaczony do pracy ani szkoły”. Dobry kandydat opowie Ci o aplikacji, stronie internetowej lub hackowaniu, które zrobił dla własnej przyjemności. Słabszy kandydat opowie ci tylko o programie, który napisał, aby wymyślić coś do pracy / szkoły.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/87709/discussion-on-answer-by-selbie-how-do-we-recruit-junior-software-developers-in-za).
#5
+24
JBH
2018-12-28 05:30:34 UTC
view on stackexchange narkive permalink

Większość swojego życia spędziłem jako inżynier elektryk, aw latach 90. wiele firm, z którymi rozmawiałem, przestało zadawać mi pytania dotyczące elektrotechniki. Było dla nich oczywiste, że między ukończeniem szkoły a wznowieniem pracy wiedziałem wystarczająco dużo o elektrotechnice, aby zaspokoić ich potrzeby. O co pytali?

Moja osobowość. Umiejętność pracy w zespole (i kierowania nim). Moje umiejętności interdyscyplinarne. Moja zdolność uczenia się.

Mówiąc bezlitośnie, umiejętności inżynierskie (zwłaszcza umiejętności programistyczne) to tuzin. Jest tak wielu zasadniczo kompetentnych ludzi, że nie ma nic o programowaniu lub inżynierii, o które warto zapytać (chyba że rozmawiasz z nowym absolwentem bez doświadczenia na stażu).

Ważne jest, aby upewnić się, że kandydat jest odpowiednie dla Twojego środowiska. Jak dobrze będą współpracować z istniejącymi osobowościami w Twojej firmie? Czy wnoszą do stołu więcej niż umiejętności potrzebne do podstawowej pracy? Jak szybko mogą przyspieszyć zmiany w kierunku firmy? technologia? czy standardy projektowe? Czy są chętni do pracy poza podstawową pracą, dostarczając (np.) Artykuły naukowe, prezentacje na konferencjach, patenty i inne działania „przynoszące zaszczyt firmie”? I czy mogą pokazać, że potrafią to wszystko zrobić?

Podsumowując, mogę podsumować komentarzem, który dawno temu przekazałem rekruterom Philips Semiconductor (jako pracownik). Mogę nauczyć 10-latkę łączenia kropek, jeśli chodzi o projektowanie mikroelektroniczne. Nauczenie ich, DLACZEGO łączysz te kropki, to inna sprawa. Dlatego nie możesz ocenić nowego pracownika na podstawie tego, jak dobrze łączą kropki. Musisz znaleźć sposoby, aby odkryć, jak dobrze wiedzą, DLACZEGO robią to, co robią. Tutaj właśnie wkracza praca zespołowa i zajęcia pozalekcyjne. Pokazują głębię zrozumienia.

_ „Jest tak wielu w zasadzie kompetentnych ludzi, że nie ma nic o programowaniu lub inżynierii, o które warto zapytać (chyba że przeprowadzasz rozmowę z nowym absolwentem bez stażu).” _ Nie zgadzam się.Przeprowadziłem wywiad z wieloma ludźmi, którzy świetnie wyglądali na papierze, ale nie potrafili odpowiedzieć nawet na kilka całkiem podstawowych pytań dotyczących podstawowych, powszechnych technologii.Nawet nie doszliśmy do formy, choć jest to oczywiście również ważne.Miło mi słyszeć, że kwalifikowałeś się na stanowiska, o które się ubiegałeś, ale zdecydowanie nie dotyczy to wszystkich kandydatów.
Racja, tak nie jest w przypadku oprogramowania.Prawie wszyscy „programiści” są ledwo kompetentni, mają klimat samouka i nie są w stanie nic zrobić.OP jest całkowicie poprawny, że ludzie ćwiczą, aby odpowiedzieć na „pytania typu wywiadu”, które można wyszukać online.Kontrola jakości dotyczy sposobu rozwiązania tego problemu.
A jeśli potrzebujesz wysoce kompetentnych ludzi, nie ma ich tylu, ilu potrzeba.
Myślę, że część rozdźwięku w tym miejscu polega na tym, że istnieje standardowa, skodyfikowana wiedza, którą mniej więcej tworzy EE.Nie dotyczy to programowania.Istnieje wiele problemów wynikających z braku bazy: dwóch identycznych kandydatów na papierze może mieć rzędy wielkości zbliżone do rzeczywistych umiejętności, kandydat może być prawdziwym geniuszem w jednej dyscyplinie, ale całkowicie ignorantem w innych, co może mieć kluczowe znaczenie dlaokreślonej pracy, itp. Nie możesz nawet użyć compsci jako podstawy: jest wielu kompetentnych front-endów, którzy nie rozumieją np.struktury danych lub jak działają kompilatory.
@JaredSmith O nie, EE są co najmniej tak zmienne jak programiści, liczba kandydatów, którzy nie mogą mi powiedzieć, jak wartość rezystora wpływa na wydajność szumów lub dlaczego zakładanie dekielków odsprzęgających jest przerażające i nie zaczynaj od dziwności, którą czasami słyszyszjeśli zadasz pytanie o linię transmisyjną.Rysunek zasilacza, rezystora i długiego kabla plus luneta daje ** naprawdę ** dziwne odpowiedzi.Wszystko to jest odpowiednikiem „napisz sortowanie bąbelkowe” w domenie EE.
@DanMills Jestem pewien, że masz rację, nie żeby ktoś kiedykolwiek używał sortowania bąbelkowego;)
@Lightness Races in Orbit: Ale rozwój oprogramowania jest na tyle zróżnicowany, że Twoje „podstawowe, powszechne technologie” mogą być czymś, czego nigdy nie miałem okazji użyć.(I na odwrót, oczywiście.)
Tytuł pytania określa „młodszych programistów”, więc nie mówią o osobach, które mają już CV.
@jamesqf W takim razie nie powinieneś ubiegać się o pracę, która wymaga znajomości z nimi.
Programista @KristenHammack Junior nie oznacza braku doświadczenia zawodowego.Nawet gdyby nie mieli żadnego doświadczenia zawodowego, musieliby przynajmniej uzyskać wykształcenie lub wyjaśnić, w jaki sposób zdobyli umiejętności programistyczne, co z pewnością obejmowałoby niektóre projekty programistyczne.Jak inaczej kandydat miałby wykazać się umiejętnościami i wiedzą, aby odnieść sukces w oferowanej pracy?
@Lightness Races in Orbit: Ale to, co mówi opublikowany opis stanowiska pracy i o co pytają ankieterzy, może być bardzo różne.I obie te rzeczy mogą nie mieć większego związku z tym, czego faktycznie wymaga praca :-(
@jamesqf Jeśli tak, system jest strasznie uszkodzony i powinieneś przebiec milę!
@Fattie Nie wszyscy hobbystowie-samoukowie są kompetentni, ale prawie wszyscy kompetentni programiści są samoukami.Katastrofy stworzone przez idiotów porządkujemy dyplomami wynajmowanymi przez idiotów, którzy zadają pytania do wywiadów znalezione w książkach.
@TheMerryMisanthrope - rzeczywiście, wszyscy naprawdę utalentowani programiści zaczynają, gdy mają 12 - 14 lat.Podobnie jak gitarzyści, w tym sensie są rzeczywiście samoukami.Nie możesz nauczyć się być Joe Walshem, albo urodziłeś się jako Joe Walsh, albo nie :) Szczęśliwego Nowego Roku !!
@LightnessRacesinOrbit i jeśli zadasz zbyt proste pytania, stracisz najlepsze.Mózg działa w taki sposób, że jeśli coś wykracza poza rozsądny zakres wyzwań, działa gorzej.
@Fattie wow, to odważne stwierdzenie.Nie wiedziałem, że programowanie istnieje, kiedy miałem 12 lat i to nie dlatego, że nie interesowałem się komputerami.Po prostu nie miałem kontaktu z tym światem, dopóki nie poszedłem na studia i nie wziąłem zajęć, które były wymagane na wszystkich kierunkach inżynierskich.W szkole średniej uczyłem się języków obcych, ponieważ to było oferowane.
#6
+19
Eric Lippert
2018-12-29 21:49:59 UTC
view on stackexchange narkive permalink

Podstawowy problem polega na tym, że nie używasz poprawnie problemów z kodowaniem jako techniki prowadzenia rozmowy kwalifikacyjnej. Wygląda na to, że Twoja technika rozmowy kwalifikacyjnej wygląda następująco:

  • Przedstaw problem
  • Czy kandydat pomyślnie rozwiązał problem? ZATRUDNIĆ. Jeśli nie, NIE WYNAJMUJ

Jak już zauważyłeś, ta technika prowadzenia rozmowy kwalifikacyjnej jest (1) bardzo łatwa do „gry” przez kandydatów i (2) daje sygnał niskiej jakości "o ich rzeczywistych umiejętnościach, które są istotne w pracy.

Oto jak udzielę wywiadu dotyczącego problemu z kodowaniem:

  • Przedstaw problem. Problem powinien być taki, który mógłby być łatwo rozwiązany przez każdego na tym stanowisku, powinien być odpowiedni dla danego stanowiska i nie powinien opierać się na żadnych „kulturowych” wiedza, umiejętności. W szczególności nie może wymagać wglądu w „chwilę aha” .

Na przykład podczas rozmowy kwalifikacyjnej na stanowisko, na które kandydat pisałby standardową bibliotekę język programowania, zapytałbym, jak zaimplementować jedną z łatwiejszych metod w tej bibliotece. Kiedy stanowisko zajmuje się projektowaniem narzędzi, które wykrywają defekty, umieszczałem jakiś legalny, ale błędny kod i prosiłem kandydata o znalezienie defektów i opisanie, dlaczego są defektami i jaka jest ich waga. Gdy stanowisko wymaga manipulowania drzewami parsowania w kompilatorze, pytałbym o wydobycie faktów o drzewach, na przykład o to, czy naruszona została właściwość balance. I tak dalej.

  • Upewnij się, że kandydat rozumie problem, korzystając z kilku prostych przykładów.

Te proste przykłady to przypadki testowe ; kandydat powinien to zauważyć, kiedy nadejdzie czas, aby uzasadnić swoje rozwiązanie.

  • Daj kandydatowi możliwość zadawania pytań wyjaśniających.

Jest to szczególnie ważne, jeśli problem jest w jakikolwiek sposób nieokreślony. „Czy przy obliczaniu daty musimy brać pod uwagę czas letni?” "Czy wiemy na pewno, że arytmetyka liczb całkowitych to 32-bitowe uzupełnienie do dwóch?" "Czy drzewo jest na tyle płytkie, że możemy napisać algorytm rekurencyjny inny niż ogon?" i tak dalej.

Jest to cenny sygnał o zdolności kandydata do przeanalizowania problemu, poinformowania o nim i rozwiązania niejednoznacznej sytuacji. To wszystko są cenne umiejętności zawodowe. Użyj tego sygnału .

  • Od czego ma zacząć, gdy kandydat będzie w stanie rozwiązać problem? Czy używają stylu „sterowanego testami”, w którym najpierw piszą przypadki testowe? Czy piszą wyraźny nagłówek funkcji, który opisuje żądane wejścia i wyjścia? Czy przestrzegają standardowych praktyk dotyczących nazywania? Jeśli używasz języka OO, czy kandydat przestrzega dobrych zasad projektowania OO? Krótko mówiąc, czy mogą skutecznie używać abstrakcji funkcji?

  • Jeśli funkcja ma przypadki błędów, które nie są wychwytywane przez system typów, czy kandydat używać sprawdzania poprawności, twierdzeń lub innych technik, aby zapewnić spełnienie warunków wstępnych?

  • Czy istnieją „łatwe do rozwiązania” przypadki, które można załatwić po sprawdzeniu błędów? Czy kandydat pisze kod do łatwych wyjść? Czy potrafią opisać, dlaczego dokonali takiego wyboru? Łatwe przypadki dają nam kompromis między złożonością kodu a wydajnością; w jakich okolicznościach taki kompromis jest uzasadniony?

  • Czy po napisaniu całej metody metoda jest zapisana jako poprawna, poprawna implementacja specyfikacji? Czy kandydat może Cię o tym przekonać ? Jeśli kod nie jest poprawny, czy starają się Cię przekonać, że jest poprawny? Czy mogą wykorzystać przypadki testowe, które już mają, aby udowodnić ich poprawność? Czy mogą wymyślić nowe przypadki testowe? Czy istnieją zapewnienia weryfikujące warunki końcowe? Pracuj z kandydatem, aż oboje przekonacie się, że kod jest poprawny, ponieważ jest poprawny.

  • Teraz mamy poprawną implementację. Jeszcze nie jesteśmy blisko ukończenia . Problem powinien być na tyle prosty, że wymyślenie poprawnej implementacji nie zajmie prawie całego wywiadu. Następne pytanie: przeanalizuj charakterystykę wydajności właśnie napisanego algorytmu. Jakie zasoby identyfikuje kandydat? Czy rozumieją, że wydajność dotyczy wymagań użytkownika, a nie samej szybkości? Czy potrafią dokonać kompromisów między przestrzenią a czasem? Czy rozumieją amortyzację w porównaniu z wynikami w najgorszym przypadku? Czy rozumieją przepustowość w porównaniu z czasem do pierwszego wyniku? Czy mogą opisać ci egzogenny wpływ na wydajność, taki jak presja zbierania w językach gc'd? Czy potrafią poprawnie podać asymptotyczną kolejność? Jakie modyfikacje mogą wprowadzić w kodzie, aby dostosować jego parametry wydajnościowe?

  • Teraz widzimy, jak głęboki jest zestaw narzędzi kandydata. Zmień opis problemu, aby był trudniejszy. „A jeśli te dwie daty mogą być w różnych strefach czasowych?” „A co by było, gdybyśmy uruchomili ten kod na maszynie, na której wskaźniki mogą mieć różne rozmiary?” „A co by było, gdybyśmy wiedzieli, że drzewo może być wysoce niezrównoważone po lewej stronie i nie moglibyśmy wykonać żadnej rekurencji po lewej stronie?” „A co, jeśli jesteśmy w środowisku o ograniczonej pamięci i nie możemy przydzielić dowolnie wielu obiektów?” i tak dalej. Wszystkie powyższe sytuacje napotkałem w pracy. Weź przykłady z rzeczywistych sytuacji, z którymi miałeś do czynienia . Uzyskaj dobry sygnał ze sposobu, w jaki kandydat sobie z nimi radzi.

W skrócie , Nie obchodzi mnie, czy kandydat widział już mój problem, ponieważ jego rozwiązanie jest najmniej interesującą rzeczą, jaką zamierza zrobić podczas rozmowy kwalifikacyjnej . Nie szukam możliwości stworzenia standardowego rozwiązania standardowego problemu; Zakładam, że to dostanę, a jeśli tego nie zrobię, będzie to łatwe „bez zatrudnienia”. Szukam umiejętności do projektowania, określania, wyjaśniania, wdrażania, testowania, uzasadniania, analizowania i rozszerzania rozwiązań.

Ile więc błędnych wariantów strncmp () (lub jej odpowiednika w jakimś innym języku lub podobnej, dość prostej, standardowej funkcji bibliotecznej) widziałeś?:-)
@aCVn: Raczej dużo.Kiedy pracowałem nad standardowym kodem biblioteki, zapytałem, jak zaimplementować uproszczoną wersję „ile dni jest między tymi dwiema datami?”funkcjonować.Okazuje się, że wielu kandydatów tak naprawdę nie wie, jak działa * odejmowanie *, a ci nie zostali zatrudnieni.
Między wierszami tej odpowiedzi jest to, że postawienie problemu i ocena odpowiedzi przez osobę przeprowadzającą rozmowę kwalifikacyjną powinno zająć co najmniej tyle samo wysiłku, co rozwiązanie problemu przez kandydata.I +1 za ostatnie zdanie.
@Blrfl to prawdziwy na wynos.To pytanie czyta mi bliżej: „Dlaczego nie otrzymuję wysokiej jakości kandydatów za pomocą procesu przesiewowego w puszkach” ... *, ponieważ korzystasz z procesu przesiewowego w puszkach. *
@EricLippert: To naprawdę świetne pytanie - wydaje się proste (filtr górnoprzepustowy), ale umożliwia różnego rodzaju interesujące rozmowy (TZ, reforma kalendarza gregoriańskiego itp.)
@Piskvor: Dokładnie tak.Jednak są pewne subtelności.Nie chcę mieć wywiadu, który jest sprawdzianem ciekawostek lub który stawia w niekorzystnej sytuacji osoby z różnych kultur.Każdy żyje w świecie, w którym istnieją strefy czasowe i czas letni, więc spodziewałbym się, że ludzie będą w stanie krytykować format daty na tej podstawie.Ale nie wiem, dlaczego Ukraińcy obchodzą Boże Narodzenie w inny dzień, nie jest czymś, o co chcę dzwonić w wywiadzie!
@EricLippert Jasne.Chodziło mi o to, że „wydaje się proste, ale jeśli * kiedykolwiek * dotknąłeś tematu, przynajmniej wiesz, że prostota jest zwodnicza”.
#7
+10
Fattie
2018-12-28 00:48:53 UTC
view on stackexchange narkive permalink

Tymczasowe płatne wersje próbne.

Witaj nowy użytkowniku, doszedłem do wniosku, że jedynym sposobem na znalezienie inżynierów oprogramowania jest znalezienie kogoś, kto zdaje się wiedzieć, o czym mówią w danej technologii,

  • Po prostu zapłać im za tygodniową lub dwutygodniową umowę na zlecenie. Właściwie poproś ich, aby wskoczyli i razem z prawdziwym zespołem wykonali prawdziwy projekt dotyczący Twojego produktu.

To staje się coraz bardziej powszechne.

Myślę, że to wszystko.

To jedyny sposób, aby wiedzieć.

Wszystko inne jest bezużyteczne, jak wskazuje OP.

Ilość czasu / pieniędzy, które wydasz na różne alternatywy ... równie dobrze możesz po prostu przeznaczyć je na projekt na tydzień.

(W zależności od Twojego stylu i projektu, możesz je zachować przez pewien czas (tydzień) lub jakieś „zadanie” za x $. Tak czy inaczej).

Jeśli będziesz konsekwentnie stosować to podejście, po roku lub dwóch okaże się, że pieniądze, które zmarnowałeś takie podejście było rzeczywiście znacznie mniejsze niż inne koszty poszukiwania i zatrudniania.

„Ponieważ jestem szczerze zmęczony zatrudnianiem obiecujących programistów, którzy doskonale odpowiadają na każde pytanie podczas rozmowy kwalifikacyjnej, i wtedy kiedy faktycznie widzisz, jak kodują w rzeczywistej sytuacji, zdajesz sobie sprawę, jak niewiele wiedzą. ”

Tymczasowe płatne wersje próbne.


Dalsze przemyślenia , treść tej kontroli jakości to

• Dla inżynierów oprogramowania, procesy rekrutacyjne zawodzą - w istocie często są „beznadziejne”. (Jednym z wierzchołków tego, a tym szczególnym podniesionym z frustracji przez OP, jest to, że pełni nadziei programiści po prostu „odgrywają” fazę „pytań technicznych”).

• Zwróć uwagę, że nawet „google- style "absurdalnie szczegółowe / rozbudowane procesy rekrutacyjne ............ często całkowicie kończą się niepowodzeniem. Programiści (w szczególności) często „po prostu nie wychodzą” bez względu na jak uważać procesy rekrutacyjne.

• Jak najbardziej w każdej branży lub zawodzie, ludzie czasami „nie wychodzą” nawet po starannej rekrutacji. Jednak jest to problem szczególnie dla inżynierów oprogramowania - jest notoryczny .

{Możesz zapytać - dlaczego? Dlaczego jest to szczególnie problem z programistami? Wiem dokładnie, dlaczego tak jest, a niektórzy ludzie mają na ten temat własne teorie, ale nie ma potrzeby zaczynać kolejnej kłótni!}


Jeszcze więcej myśli!

Ta odpowiedź ma wiele głosów przeciw i pozytywnych.

Najwyraźniej

  • dla wielu ludzi jest to całkowicie oczywisty pomysł

  • ale dla innych jest to dziwacznie szalone rzeczy .

W końcu odkładając na bok samo programowanie, w latach 90. jednym z kluczy do oszałamiającego sukcesu General Electric w tamtym czasie był schemat Jacka Welcha, w którym każdy menedżer po prostu zwolnił najgorsze 10 % ludzi każdego roku! (Swoją drogą, jego książka jest niesamowita.)

A ja wzdrygam się, pisząc frazę „ekonomia koncertów”, ale w „ekonomii koncertów” wszyscy jesteśmy na „próbie” - z dnia na dzień i na zawsze .

Odszukiwanie programistów jest niezwykle trudne.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/87618/discussion-on-answer-by-fattie-how-do-we-recruit-software-developers-in-an-wiek-w).
#8
+9
PeteCon
2018-12-28 00:48:13 UTC
view on stackexchange narkive permalink

Korzystaj z wywiadów na tablicy i zadawaj pytania związane z umiejętnościami i domeną biznesową, które Cię interesują. Poszukaj osób, z którymi możesz pracować, nawet jeśli nie są oni idealnymi osobami zawsze szkol odpowiednią osobę, jeśli ma potencjał. Poproś obecnych pracowników o rekomendacje (i zaoferuj opłatę za wyszukiwarkę)

Pete, obawiam się, że OP rzeczywiście mówi o problemach związanych z tablicami!
@Fattie - Tak - ale dobrą rzeczą w przypadku wywiadów na tablicy zamiast testów kodowania na wynos jest to, że można zmienić parametry w połowie pytania, aby wrzucić klucz do prac
Nie proś ludzi o kodowanie na tablicy!To okrutne!
Te wywiady na tablicach są dokładnie tym, dzięki czemu wydrukowano wiele książek.Jako programista lubię spędzać czas na uczeniu się swojej pracy i wykonywaniu jej, ale moim zadaniem * nie * jest pisanie programów na tablicy.
@Abigail Mam na myśli to, i oczywiście mogę mówić tylko w swoim imieniu, ale z pewnością nie może to być rzadkie, _nienawidzę_ pisania kodu na tablicy, ponieważ jest to naprawdę niewygodne i nie ma możliwości, aby moja ręka nadążała za moimi myślami.Daj mi już laptopa i projektor!Patrz, jak latają moje palce.
@Abigail Zgadzam się z lekkością co do kodu, to był mój punkt widzenia.Twój punkt widzenia dotyczący wyjaśniania procesów na białej tablicy jest jednak rzeczywiście uczciwy i prawdziwy.Ale na pewno nie * kodowanie *, nawet jeśli * może * pojawiać się czasami obok innych istotnych rzeczy.Dla mnie nie ma sensu ocenianie potencjalnego kandydata na podstawie jego umiejętności kodowania na tablicy (a raczej zdolności do improwizowania kodu na tablicy).
#9
+7
cdkMoose
2018-12-28 01:52:02 UTC
view on stackexchange narkive permalink

Po przejściu przez wystarczającą liczbę podstawowych pytań, aby pokazać, że mają minimalną (jak na moje potrzeby) umiejętność pisania kodu, przechodzę do trudniejszej części rozmowy, opartej na dwóch obszarach tematycznych, ich pracy i mojej.

Zapytaj o informacje na temat ostatniego projektu w ich obecnej pracy. Nawet w odniesieniu do umów o zachowaniu poufności i ograniczeń dotyczących własności intelektualnej powinni być w stanie wyjaśnić problem biznesowy, złożoność problemów i sposób, w jaki je przezwyciężyli. Jeśli nie potrafią wyjaśnić mi swojej pracy, abym mógł ją zrozumieć i ocenić, martwię się o to, jaki odniosą sukces.

Poproś ich, aby przygotowali projekt / rozwiązanie jednego z Twoich obecnych problemy. Oczekiwanie nie powinno być działającym rozwiązaniem, ale sposobem, w jaki podchodzą do problemu. Podaj wystarczającą ilość informacji, aby omówić problem na wysokim poziomie. Powinni zadawać dobre pytania, a Ty powinieneś udzielać dobrych odpowiedzi, aby mogli kontynuować. Powinni umieć nakreślić jakieś rozwiązanie. W końcu ich rozwiązanie może się nie udać, ale będziesz mógł zobaczyć, jak rozwiązują problem i czy powinni być w stanie pracować nad projektami, które będziesz mieć.

#10
+6
user53651
2018-12-28 04:18:01 UTC
view on stackexchange narkive permalink

Po prostu. Po prostu przeanalizujesz kandydatów na temat szczegółów wdrożenia i zmienisz ich wymagania, aby zobaczyć, jak zareagują. Niech wykorzystają to, co zapamiętali, jako klocki.

Szczerze mówiąc, problem z zapamiętywaniem nie jest problemem. Zapamiętywanie jest właściwie jedną z kluczowych technik, których szachiści używają do nauki gry. Zapamiętując algorytmy, Twoi kandydaci tworzą bibliotekę rozwiązań, na podstawie których mogą pracować. Oznacza to, że będą w stanie lepiej rozwiązywać problemy w przyszłości, jeśli wzorce i implementacja wzorców, których się uczą, są rzeczywiście przydatne.

To, co musisz przetestować, to ostatnia część. Zmieniając problem w czasie rzeczywistym, możesz zobaczyć, jak dobrze kandydat rzeczywiście rozumie, jak wykorzystać to, co zapamiętał. Oznacza to, że możesz zapytać ich o lepsze sposoby rozwiązania pytania, a nawet poprosić, aby ułożyli swoje rozwiązanie w przepływ pracy, aby zrobić coś zupełnie innego.

To, czego chcesz, to kogoś, kto potrafi rozwiązywać problemy. To, czego nie chcesz, to ktoś, kto rozwiązuje problemy tak, jak chcesz, aby zostały rozwiązane. Jeśli wszyscy zapamiętują rozwiązania, wszystko, co musisz zrobić, to przetestować ich umiejętność wykorzystania tego, co zapamiętali. Kiedy do tego dochodzi, wszyscy używają tego, co wiedzą, aby wyjaśnić to, czego nie wiedzą. Jeśli twoi programiści mogą używać wzorców, które już opanowali, do rozwiązywania problemów o rosnącej złożoności, byliby w stanie odwrócić listę połączoną, gdyby nigdy wcześniej nie widzieli, żeby ktokolwiek to robił.

Jako rekrutera, to jest tak daleko, jak można racjonalnie oczekiwać, bez prób uzyskania bezpłatnej pracy od swoich kandydatów.

To zabawne, że wspomniałeś o cofaniu połączonej listy.Spodziewam się, że na to pytanie narzeka OP.Osobiście idę jeszcze bardziej prosto.Pytam, jakich struktur danych użyli w swoim ulubionym języku, np.w Pythonie jest lista i deque.Chciałbym zapytać o różne charakterystyki wydajnościowe między nimi dla operacji.Mogą to zapamiętać, ale nie rozumieją, że lista jest obsługiwana przez tablicę, podczas gdy deque jest obsługiwana przez listę połączoną.Więc pomimo ich zdolności do odwracania połączonej listy, tak naprawdę nie rozumieją, dlaczego używasz połączonych list.
@Chan-HoSuh, który na pewno by mnie dostał.Od jakiegoś czasu piszę skrypty do pracy i nigdy nie musiałem używać do niczego powiązanej listy.Szczerze nie rozumiem, o co mi chodzi, zwłaszcza w Pythonie.Gdybym został poproszony o odwrócenie jednego w wywiadzie, prawdopodobnie powiedziałbym im, że na początku używają niewłaściwej struktury danych.Nie przekazałbym tego hahaha
Właściwie zacząłem myśleć któregoś dnia, dlaczego nie zaimplementujemy deque z tablicą bazową zamiast połączonej listy?Z tego bocznego wątku wynikło więc kilka ciekawych przemyśleń :)
@Chan-HoSuh Celem używania wyższego języka jest oderwanie się od szczegółów.To tak, jakby zapytać kierowcę ciężarówki, jak działa gaźnik ... na pewno niektórzy z nich będą wiedzieć i być może będą w stanie sprawdzić trochę więcej wydajności, ale nie dowiesz się zbyt wiele o ich prowadzeniu.Jeśli musisz szukać mężczyzny za zasłoną, prawdopodobnie używasz niewłaściwego narzędzia.
@TemporalWolf brzmi dobrze w teorii, nie tak bardzo w praktyce.Co robisz z kimś, kto w Pythonie nalega na poprzedzanie listy w pętli, tworząc algorytm O (n ^ 2) zamiast O (n)?Okazuje się, że musisz wiedzieć coś o tym, jak zaimplementowano listę w Pythonie, aby nie robić głupich rzeczy.A kiedy uczysz się więcej Pythona, odkrywasz więcej tych rzeczy.
@Chan-HoSuh Zapamiętywanie charakterystyk wydajności ** jest wystarczające, aby tego uniknąć.Nawet [czytanie dokumentacji] (https://docs.python.org/3/tutorial/datastructures.html#using-lists-as-queues) jest wystarczające, nie musisz nawet znać Big-O, dużomniej podstawowej implementacji.W każdym języku są pułapki, ale pytanie o ciekawostki językowe na ich temat wydaje się mało prawdopodobne, abyś wiedział, co rozumieją.
@TemporalWolf odkładając na bok ewentualne błędy w twojej analogii, ponieważ oczekuję, że profesjonalny kierowca ciężarówki byłby naprawdę dobry w samodzielnej naprawie w razie potrzeby ... jeśli chodzi o to, moje standardy są zbyt wysokie, aby zatrudnić twój typ kierowcy ciężarówkiprogramistą, to prawdopodobnie prawda.* Wolę * pracować z ludźmi, którzy starają się zrozumieć, a nie zapamiętać.Powyższe rzeczy są mniej więcej tak „algorytmiczne”, jak u mnie.Gdyby przyszło to popchnąć, byłbym szczęśliwy, gdyby ludzie wiedzieli tylko to, co twierdzą, że wiedzą, a pozornie często nie wiedzą.
@TemporalWolf Jak każdy system przeprowadzania wywiadów, który ktoś wymyśli, można powiedzieć, że można w niego grać.Więc tak, zapamiętywanie wystarczy, aby zagrać w rozmowę kwalifikacyjną.Szczerze mówiąc, nie wierzę, że wystarczy być dobrym programistą.Brak mistrzostwa pojawia się, gdy kontekst jest bardziej skomplikowany.Spodziewam się, że nawet młodsi programiści przynajmniej zastanowią się, dlaczego podstawowe struktury danych mają takie same parametry wydajności, jakie mają.To nie są pułapki językowe.Wspólne struktury danych są zwykle implementowane w bardzo podobny sposób w różnych językach, ponieważ podstawowa architektura komputera nie zmienia się.
@Chan-HoSuh Nie wyrażam się jasno. Obawiam się: nie sądzę, żeby to pytanie zawierało zrozumienie.Chodzi mi o to, że wiem, że deque jest zaimplementowana jako lista połączona, nie dodaje żadnych dodatkowych możliwości jej używania, w przeciwieństwie do świadomości, że działa podobnie do listy połączonej.Jeśli deque chodzi, zachowuje się i kwacze jak połączona lista, nie ma znaczenia, czy znajduje się ona pod spodem.Ma to (potencjalnie) znaczenie tylko wtedy, gdy nie zachowuje się jak jeden.Zdecydowanie warto wiedzieć, co znajduje się poniżej abstrakcji, ale głównie tam są one nieszczelne.
@TemporalWolf Nie ma sposobu, aby po prostu z interfejsu deque stwierdzić, jak odbywa się alokacja pamięci.Ktoś, kto rozumie, jak używać deque, może nadal nie zdawać sobie sprawy, że korzystanie z deque ma przewagę wydajnościową, nawet jeśli chcesz użyć interfejsu listy.
@Chan-HoSuh Nigdy nie pracowałem z deque i nigdy tego nie sprawdzałem, ale zakładam, że działa tak, jak wyobrażam sobie que lub stack.Myślę, że musisz poradzić sobie z pozycją na górze, zanim będziesz mógł zająć się pozycją poniżej, więc istnieją powody, dla których nie należy jej używać, na przykład brak możliwości odniesienia przez indeks.Dictty nie zezwalają na powtarzane klucze, chyba że chcesz, aby wartości miały inny rozmiar, a zestawy w ogóle nie zezwalają na powtarzające się wartości.
@Chan-HoSuh Masz również do czynienia z zewnętrznymi ograniczeniami.Często używam arcpy i chociaż chcę być efektywny, kiedy uruchamiam zapytanie aktualizacyjne, podstawową logiką, której używa Arcpy, jest po prostu śmieci;kursory aktualizacji to nieefektywne rzeczy, z których nie mogę wyjść bez narażania danych z mojej mapy.Czasami optymalizacja jest po prostu głupia;nadal nie powinieneś optymalizować przedwcześnie tylko dlatego, że możesz.
@Steve Chodziło mi o to, że * czasami * są powody, by przedkładać deque nad listę wyników.I nigdy nie powiedziałem, że należy zawsze „optymalizować przedwcześnie tylko dlatego, że jest to możliwe”.Chodzi mi o to, że poznanie kilku podstawowych szczegółów implementacji wspólnych struktur danych pozwala uzyskać dodatkowe informacje.
@Chan-HoSuh Sorta ... Jeśli naprawdę chcesz zrobić coś zwariowanego i wydajnego w Pythonie, musisz użyć cython / dowolnego kompilatora jit lub modułu napisanego w C i tak.Nie wątpię, że wiedzieć więcej, to wiedzieć więcej.Po prostu wątpię, czy jest to przydatne poza dokumentami i procesem rozmowy kwalifikacyjnej.Każdy, kogo znam, kto potrafi robić notacje Big O, i tak studiuje to przed rozmową.Dosłownie wychodzi, gdy zmieniają pracę.Resztę czasu po prostu odchodzą od znanego doświadczenia.
#11
+3
aw04
2018-12-28 23:11:35 UTC
view on stackexchange narkive permalink

Problem polega na tym, że nie testujesz pod kątem umiejętności, których szukasz.

Proces, którego użyłem zarówno jako ankieter, jak i osoba przeprowadzająca rozmowę kwalifikacyjną, działał dobrze:

  • Szybkie 15-minutowe badanie telefoniczne, aby dowiedzieć się, czy dana osoba jest kompetentna i czy ktoś, kogo mógłbyś zatrudnić.

  • Proste ćwiczenie z kodowania dla kandydat do ukończenia w swoim czasie . W tym miejscu możesz poczuć rzeczywiste umiejętności rozwiązywania problemów i kodowania. Ćwiczenie nie powinno zająć więcej niż kilka godzin i opcjonalnie możesz zapłacić im za ich czas.

  • Właściwa rozmowa techniczna, która obejmuje sprawdzenie kodowania i omówienie rozwiązania oraz proces podejmowania decyzji.

  • Większość (obecnie) wysoko ocenianych odpowiedzi na to pytanie sugeruje jakiś rodzaj kodowania na żywo jako część wywiadu. Zdecydowanie odradzam to, ponieważ nie jest to wcale reprezentatywne dla rzeczywistego scenariusza. Jest to nienaturalna sytuacja pod wysokim ciśnieniem, w której kandydat może zaoferować gorsze rozwiązanie niż w innym przypadku, bez dodatkowych korzyści.

    Po pierwsze, absolutnie się z tym zgadzam - jestem osobą, która robi się niesamowicie nerwowa i dosłownie staje się „głupia”, kiedy przedstawia się jej quiz / wywiad techniczny na miejscu.W każdej innej rozmowie kwalifikacyjnej, którą wykonuję w domu, generalnie wygrywam i zdaję.Wszystkie referencje od moich ludzi i osobiste opinie na temat moich wyników są pozytywne, co moim zdaniem świadczy o tym, że jestem dobrym pracownikiem / programistą.Moim skromnym zdaniem liczy się to w miejscu pracy, a nie znajomość wszystkich pułapek związanych z ćwiczeniem technicznym, na które nie masz wystarczająco dużo czasu.
    #12
    +3
    JonathanReez
    2018-12-28 10:36:02 UTC
    view on stackexchange narkive permalink

    Wydaje mi się, że źle rozumiesz powód, dla którego duże firmy zadają pytania algorytmom. Pisanie algorytmu szybkiego sortowania prawdopodobnie nie jest zbyt przydatną umiejętnością dla większości programistów. Podobnie, znalezienie najlepszego sposobu na przeanalizowanie 1 miliona znaków nie jest czymś, co ludzie rutynowo wykonują w pracy. Jednak wiedza, jak rozwiązać te problemy, jest świetnym sposobem na odfiltrowanie głupich kandydatów. Jeśli ktoś jest zbyt głupi do pracy, nie będzie w stanie spójnie odpowiedzieć na żadną z zagadek podczas rozmowy kwalifikacyjnej, często zadawanych podczas rozmów kwalifikacyjnych. Nawet jeśli zapamiętają wszystkie odpowiedzi, możesz łatwo złamać ich schemat, zadając nieco inną odmianę pytania lub dodając na miejscu dodatkowe pytanie. Natomiast dobry kandydat nie miałby problemów z przygotowaniem się do „testu” i zdałby znakomicie.

    Rozmowa kwalifikacyjna polega na odfiltrowaniu złych kandydatów, a nie na znalezieniu najlepszych kandydatów per se. Nie ma nic złego w przygotowaniu kogoś z wyprzedzeniem, ponieważ nie pomogłoby to komuś, kto nie jest przygotowany do pracy na odpowiednim poziomie.

    To prawda.„pytania techniczne podczas rozmowy kwalifikacyjnej” to tylko filtr.(tak jak „dość profesjonalne CV” jest filtrem).
    Myślę, że w pewnych środowiskach odfiltrowywanie „głupich” ludzi jest dobrym pomysłem, ale myślę, że jest wielu „głupich” programistów, którym mimo wszystko udaje się dostarczać wysokiej jakości kod.
    #13
    +3
    jamesqf
    2018-12-28 09:59:35 UTC
    view on stackexchange narkive permalink

    Umiejętność znalezienia rozwiązania na miejscu nie jest naprawdę świetną kwalifikacją, przynajmniej IMHO. Z pewnością wymyśliłem wiele natychmiastowych rozwiązań, które z perspektywy czasu nie były aż tak świetne, i czasami spędzałem tygodnie lub miesiące na szukaniu przyzwoitego rozwiązania naprawdę trudnego problemu. (Czasami rozwiązaniem jest po prostu pamiętanie, że widziałem coś podobnego gdzieś w przykładzie kodu ...)

    Nie mówisz, czy próbujesz zatrudnić nowych absolwentów, czy doświadczonych programistów, ale w obu Myślę, że naprawdę musisz znaleźć sposób, aby spojrzeć na to, co zrobili wcześniej. Czasami chodzi o przeglądanie opublikowanych artykułów (nawet jeśli dana osoba nie jest głównym autorem), czasami jest to osobiste zalecenie, a czasami po prostu poproszenie ich, aby pokazali Ci coś, z czego są dumni. FWIW, nie sądzę, żebym kiedykolwiek dostał pracę, o którą rozmawiałem, która nie miałaby co najmniej jednej z tych rzeczy.

    #14
    +3
    Edwin Buck
    2018-12-28 01:36:54 UTC
    view on stackexchange narkive permalink

    W pewnym sensie przygotowanie się do rozmowy kwalifikacyjnej jest dobrą rzeczą. Prawdopodobnie już prosisz, aby ludzie studiowali około czterech lat na uniwersytecie, aby przygotować się do rozmowy kwalifikacyjnej.

    Teraz, jeśli twój proces rozmowy kwalifikacyjnej jest oparty na scenariuszu, a scenariusz nie zawiera żadnych odmian, to jest to tylko kwestia czasu, zanim odpowiedzi zostaną zapamiętane w populacji. Rozwiązania obejmują:

    1. Jako pytania, które są generowane, ze zmiennymi polami, które wymagają pracy specyficznej dla tego zadania pytania.
    2. Zmieniaj zestaw pytań od czasu do czasu do czasu, aby zminimalizować czas potrzebny na zbudowanie puli odpowiedzi.
    3. Zmień całe podejście, dając im trywialny projekt ze specjalnie dodanymi błędami, prosząc ich o naprawienie i dodanie znanej funkcji.

    Rozważ również problem w szerszym sensie, jeśli prosisz o informacje podczas rozmowy kwalifikacyjnej, a informacje zostały zapamiętane, to powinien to być idealny kandydat, chyba że o to prosisz błędne informacje .

    Decydujesz, że informacje nie są tym, czego potrzebujesz, więc możesz być w stanie rozwiązać problem, prosząc o właściwy rodzaj informacji.

    #15
    +2
    Clockwork
    2018-12-28 15:38:37 UTC
    view on stackexchange narkive permalink

    Jako kandydat zauważyłem kilka rzeczy, które nadal można przetestować podczas rozmowy kwalifikacyjnej, nawet jeśli sam nie pracujesz w dziedzinie IT:

    • Pytania dotyczące zachowania

    Celem nie jest przybicie osoby, którą masz przed sobą, ale sprawdzenie, jakiego rodzaju może ona być. Daje to krótkie okno, czy mogą się nadawać do pracy w firmie.

    • Pytania dotyczące przeszłych doświadczeń

    [Czy mógłbyś] Opowiedz mi o sytuacji, kiedy ...

    W tym przypadku celem jest zachęcenie osoby do opowiedzenia więcej o swoim doświadczeniu w określonej sytuacji. Tego typu pytanie może potwierdzić ich umiejętności, a także samoocenę.

    Może to być przydatne, jeśli wiesz, że zespoły IT mają pewne sytuacje, z którymi trudno sobie poradzić (konieczność wykonywania wielu zadań w krótkim czasie, radzenie sobie ze zmęczonymi klientami itp.).

    • Pytanie oparte na rozwiązywaniu problemów

    Wspomniałeś, że szukasz rozwiązania do rozwiązywania problemów.

    Miałem kiedyś wywiad z firmą, w której ankieterzy nie zadawali żadnych pytań dotyczących programowania. Aby potwierdzić moje umiejętności rozwiązywania problemów, zamiast tego powiedzieli mi o sytuacji i powiedziano mi, żebym myślał głośno, aby mogli zobaczyć moje umiejętności rozwiązywania problemów w akcji. Na przykład:

    Mamy samolot z 50 miejscami siedzącymi i 50 pasażerami oczekującymi na wejście. Pierwsi dwaj pasażerowie zgubili karty, więc usiądą na przypadkowym miejscu. Następny pasażer usiądzie na swoim miejscu, jeśli może (jeśli nie jest już zajęty); w przeciwnym razie usiądą na przypadkowym miejscu. Jakie jest prawdopodobieństwo, że ostatni pasażer usiądzie na swoim miejscu?

    Celem nie jest znalezienie rozwiązania, ale pokazanie, jak rozwiązują problem.

    ~~~~~~~~~~

    W przypadku każdego z tych pytań pamiętaj, aby zanotować odpowiedź wnioskodawcy. W ten sposób możesz lepiej omówić je z kierownikiem działu IT.

    #16
    +2
    The Wandering Dev Manager
    2018-12-28 19:53:03 UTC
    view on stackexchange narkive permalink

    Myślę, że nie musisz zmieniać pytań, tylko jak i o co pytasz.

    Doszło do tego, że prawie nie możesz zadać pytania bez kandydata po wcześniejszym przestudiowaniu przynajmniej wersji tego samego zadania i dlatego wie z grubsza, jakie jest rozwiązanie.

    To nie jest rzecz o sumie zerowej, możesz czerpać korzyści z rozwiązania na całą rozmowę na własną rękę, jeśli chcesz, i uzyskaj głębokie zrozumienie umiejętności rozmówcy (zakładając, że jako ankieter masz własne umiejętności techniczne).

    Przedstawiasz pytanie, rozmówca tworzy rozwiązanie (może kod, może tablica). To jest początek:

    • Przedstaw mi sposób, w jaki to działa
    • Jakie czynniki skłoniły Cię do wybrania tego rozwiązania?
    • Czy są jakieś inne sposoby tego?
    • Dlaczego Twoje rozwiązanie jest lepsze od innych?
    • Czy są jakieś potencjalne korzyści w innych rozwiązaniach, których brakuje w Twoim rozwiązaniu? jakie scenariusze mogą to mieć zastosowanie?
    • Skoro właśnie to spisałeś, wszelkie refaktoryzacje, które chciałbyś teraz przeprowadzić, przejrzałeś to?
    • Jeśli tego nie zrobiłeś w tym sterowanym teście, jakie testy chciałbyś napisać / wykonać, aby upewnić się, że wszystko jest poprawne?
    • Czy zauważyłeś jakieś błędy?
    • Czy uważasz, że kod odpowiada jakości produkcyjnej? Czy inny programista mógłby go wesprzeć / zreformować bez transferu wiedzy od Ciebie? Co należałoby zmienić, aby mieć pewność, że intencja jest zrozumiała?

    Ktoś, kto zapamiętał algorytm lub wzorzec bez jego zrozumienia, nie będzie w stanie zagłębić się w szczegóły, ale dobry programista powinien być w stanie prowadzić dyskusje na te tematy, nawet jeśli ich surowe rozwiązanie nie było idealne (a zobaczenie, że ktoś odkrywa lepsze rozwiązanie podczas rozmowy z Tobą i jest przygotowany do tego, aby je wywołać, pokazuje dojrzałość w stosunku do recenzji kodu / projektu i refaktoryzacji, które są wysoce pożądane).

    #17
    +2
    displayName
    2018-12-29 01:24:49 UTC
    view on stackexchange narkive permalink

    Najlepszy wywiad, jakiego kiedykolwiek udzieliłem, był jednym z najprostszych, jakie udzieliłem, a także najlepszym, jakie moje umiejętności zostały zmierzone. Oto, jakie było jego 5 rund:

    1. Rozmowa telefoniczna z rekruterem: , który poprosił mnie o ustne wyjaśnienie odpowiedzi na prosty problem z kodowaniem. (Rekruter nie był specjalistą). Odpowiadając mu, pokazałem, że mogę wyjaśnić moje rozwiązanie osobom nietechnicznym, udowadniając, że istnieje prawdziwy związek między umiejętnościami wymienionymi w moim CV a praktycznością.

    2. Na miejscu 1: Jeden ze starszych programistów w firmie zademonstrował mi swój produkt. Zwrócił uwagę na pytania, które zadawałem podczas i po poznaniu ich produktu. To pomogło im dokładnie ocenić moje zainteresowanie tą domeną i sprawdzić, czy jestem naprawdę ciekawy.

    3. Na miejscu 2: kierownik techniczny z firmy przynieśli jeden ze swoich fragmentów kodu i zapytali mnie, co o tym sądzę. Kod miał podstawowe problemy - jak niestosowanie try-catch, niezamykanie zasobów, źle nazwane klasy i zmienne itp. Kod działał, ale nie został napisany odpowiedzialnie. Zaproponowane przeze mnie poprawki pokazały moje umiejętności projektowe. Jeśli ktoś nie jest odpowiedzialnym programistą, ten wywiad okazałby się najtrudniejszy. Specjalnie dla złodziei rozwiązań.

    4. Na miejscu 3: Starszy programista omówił ze mną projekt sortowania przez scalanie i po osiągnięciu prawidłowego projektu zapytał mnie zaimplementować w wybranym przez siebie języku. Dyskusja na temat projektu była relaksująca, ponieważ byłem pewien, że on i ja jesteśmy na tej samej stronie o tym, co zamierzamy wdrożyć.

    5. Na miejscu 4: silny> Inny starszy programista poprosił mnie o wyjaśnienie mu jednego z moich projektów. To pokazało, że w rzeczywistości rozumiem, co się robi w mojej obecnej pracy, zamiast robić krótkoterminowe i bezsensowne łatanie kodu.


    Wszystkie rundy były bardzo istotne i nigdzie nie czułem, że proszono mnie o zrobienie czegoś nieoczekiwanego, szczególnie na potrzeby tego wywiadu. Każde zadanie polegało na ocenie, jak dobrym jestem programistą, a nie na ilu odpowiedziach zapamiętałem.

    Nic dziwnego, że ta firma była bardzo wysoko oceniana w Glassdoor i miała bardzo niski współczynnik wyczerpania. Pracownicy nie pisali dużo o tym, co robili, ale wszyscy naprawdę zainwestowali w swoją firmę i swoją pracę.


    W mojej pracy właściwe rozwiązanie trudnych problemów pojawiło się po dyskusji między członkami zespołu . To właśnie chciałby zasymulować dobry wywiad. Zwykle samo zadawanie trudnych problemów podczas rozmowy kwalifikacyjnej nie jest pomocne.

    Nie jestem pewien, czy nazwałbym problemy „jak niestosowanie try-catch, niezamykanie zasobów, słabo nazwane klasy i zmienne itp.” * Problemy z projektowaniem *.W mojej książce byłyby to problemy z jakością kodu.Możesz mieć całkowicie czysty kod, który kropkuje wszystkie „i” i przecina wszystkie „t” na poziomie linii kodu aż do funkcji i klas, ale ogólny projekt systemu może być totalnym bałaganem, który nadal powodujekod kruchy.Na przykład * projekt * problem (przynajmniej w mojej książce), czy * cała * logika prezentacji jest wyraźnie oddzielona od * całej * logiki biznesowej?Dlaczego miałoby to być ważne lub pożądane?
    @aCVn: Masz rację.Pisząc odpowiedź, pomieszałem dwie myśli.Chciałem powiedzieć, że runda przeglądu kodu przetestowała moje rozumienie jakości kodu, a także projektowania oprogramowania.
    #18
    +2
    Kevin
    2018-12-29 02:28:05 UTC
    view on stackexchange narkive permalink

    Wiele osób odpowiedziało „Pytania nie odpowiadają potrzebom pracy” - i że rozwiązaniem jest zmiana pytań na takie, które dokładniej odzwierciedlają to, co jest potrzebne, aby wiedzieć, jak wykonać tę pracę.

    Przyjmę inny punkt widzenia: To prawdopodobnie ma wiele wspólnego z tym, że rekruterzy / ankieterzy nie poświęcają czasu na tworzenie własnych pytań.

    W naszej grupie, obecnie przeprowadzamy rozmowy z programistami .NET, a oto niektóre pytania z naszego procesu:

    • Mamy te dwie tabele SQL z tymi kolumnami. Napisz zapytanie, które zbiera dane X, filtrując w dół na podstawie Y, z narożnym przypadkiem Z, który jest obsługiwany w określony sposób.
    • Oto źle napisana 8-liniowa funkcja C #; Przejrzyj kod.
    • Napisz funkcję C #, która pobiera dane wejściowe z nazwy pliku i wyświetla liczbę bajtów przed pierwszym bajtem zerowym w tym pliku.

    Odpowiedzi na te pytania prawdopodobnie nie znajdziesz w „140 pytaniach do zapamiętania przed rozmową kwalifikacyjną” - ponieważ wymyśliliśmy pytania od zera. Nie skopiowaliśmy ich z innej firmy ani nie usunęliśmy ich z witryny „Dobre pytania do wywiadu”. Tak, to wymaga więcej pracy ... ale nie musimy się martwić, że ktoś ma już odpowiedź zapamiętaną

    #19
    +1
    Jay
    2018-12-28 09:25:09 UTC
    view on stackexchange narkive permalink

    Jeśli Twoi kandydaci są w stanie zaliczyć Twoje rozmowy kwalifikacyjne poprzez naukę, czy nie jest to silnym wskaźnikiem ich zdolności do studiowania i uczenia się? Jeśli zatrudniasz nowych absolwentów, to naprawdę najcenniejsza umiejętność do wynajęcia.

    Jeśli robi to doświadczony kandydat, oznacza to co najmniej dużą motywację do nauki przed rozmową kwalifikacyjną. Co oznacza, że ​​są bardzo zainteresowani pracą w Twojej firmie. Jest to również silny sygnał, że po ukończeniu college'u nie stracili zdolności uczenia się i szlifowania. Nadal powinieneś zadawać im pytania dotyczące ich doświadczenia zawodowego, osiągnięć i współpracy ze współpracownikami, aby lepiej zrozumieć ich ogólne umiejętności.

    Chcemy rozwiązać problemy, a nie problemy- zapamiętywacze.

    Bardzo niewiele osób może wymyślić algorytm szybkiego sortowania lub algorytmu wykrywania cyklu Floyda lub znaleźć najdłuższy rosnący ciąg w czasie wywiadu, jeśli nigdy nie badał rozwiązania. Osoby, które mogą raczej rozmawiać w Twojej firmie o regularne prace deweloperskie. Bez obrazy, jestem pewien, że to świetna firma, ale statystycznie większość twoich kandydatów nie będzie tego kalibru - ponieważ niewielu programistów na świecie jest.

    Z drugiej strony, jeśli twój kandydaci są w stanie zastosować rozwiązania problemów, które widzieli wcześniej, do odmian tego problemu lub związanych z nim problemów, jest to sygnał, że są dobrzy w dopasowywaniu wzorców i identyfikowaniu typu problemu, który mają. ponownie patrzę. I odwrotnie, jeśli nigdy wcześniej nie widzieli tego typu problemu, masz również sygnał, że wiedzą, jak znaleźć rozwiązanie i je zrozumieć - ponieważ w końcu studiowali i zdali Twój wywiad.

    Chodzi o to, że nie powinieneś mieć testu, który można rozwiązać, zapamiętując to, co można szybko sprawdzić, ponieważ takie zapamiętywanie nie jest użyteczną umiejętnością zawodową.Raczej powinieneś mieć test / pytanie, które wymaga takiego myślenia w pracy, w którym wyszukiwarka * nie może * pomóc, lub przynajmniej wymaga korzystania z niego w sprytny i pomysłowy sposób.
    Nie jest możliwe zapamiętanie rozwiązań tak wielu problemów programistycznych.Dopasowywanie wzorców do wcześniej widzianych rozwiązań nowych problemów to nie to samo, co zapamiętywanie odpowiedzi.Jeśli pytają o ciekawostki (jakie są argumenty metody foo w bibliotece Bar), to inna sprawa.
    #20
      0
    GrandMasterFlush
    2018-12-29 05:47:58 UTC
    view on stackexchange narkive permalink

    W ciągu ostatniego roku musiałem zatrudnić 5 programistów o różnych poziomach umiejętności i nie był to łatwy proces. Najlepszą metodą, jaką znaleźliśmy, było skorzystanie z testów programowania online w celu odfiltrowania słabszych kandydatów przed rozmową kwalifikacyjną.

    Wybraliśmy witrynę do testowania kodowania (CodinGame, chociaż dostępne są inne alternatywy) i poprosiliśmy kandydatów, aby usiedli test, zanim przeprowadziliśmy z nimi rozmowę kwalifikacyjną.

    Zalety:

    • Odfiltrowano kandydatów, którzy „dobrze wyglądają na papierze”, którzy nie spełnili swojego CV / CV.
    • Pozwoliło nam zobaczyć pracę kandydata - oferowaliśmy wywiady osobom, które nie uzyskały wysokich wyników na teście, ale przeglądając, co zrobili, aby rozwiązać problem, dało nam dobre wyobrażenie o ich umiejętnościach analitycznych.
    • Uważaliśmy, że kandydatów, którzy nie byli na tyle poważni, aby przeprowadzić 50-minutowy test online, nie warto przeprowadzać rozmowy kwalifikacyjnej. To ich odfiltrowało.
    • Mogliśmy ustawić testy na różnych poziomach umiejętności.

    Wady:

    • Niektórzy kandydaci, mając do czynienia z kilkoma rozmowami kwalifikacyjnymi, podążali ścieżką najmniejszego oporu i wybierali tych, na których nie było za test z kodowania.
    • Potrzebujesz kilku kandydatów, aby podejść do testu, aby uzyskać punkt odniesienia określający przyzwoity wynik.
    • Podjęcie testu wiąże się z kosztami.
    Tylko uwaga na temat testów kodowania, są one bardzo indywidualne.W rzeczywistości kodowanie to sport zespołowy.Dużo bardziej odkrywcze byłoby wprowadzenie grupy kandydatów, którzy pomyślnie przeszli test zespołowego kodowania, aby zobaczyć, jak współpracują.
    @DominicCerisano - To dobra uwaga.Jednak z własnego doświadczenia mieliśmy problemy z uzyskaniem wielu przyzwoitych CV i rekrutacji w ciągu kilku miesięcy.Realnie nie mogliśmy mieć jednocześnie wystarczającej liczby kandydatów, aby to zrobić.
    Jeśli rzadko przeprowadzasz rozmowę kwalifikacyjną, zastanów się nad zaangażowaniem części istniejącego zespołu do testu.Wrzuć kandydatowi paskudny błąd do niewrażliwego repozytorium i ścigaj go aż do scalenia. Inni mogą być tak pomocni lub przeszkadzający, jak chcą, coś w rodzaju scenariusza Kobashi-Maru.To, jak reagują na dynamikę zespołu, jest równie ważne, jak to, co wiedzą.
    #21
      0
    Harper - Reinstate Monica
    2018-12-30 02:53:42 UTC
    view on stackexchange narkive permalink

    Odwróć to: zrób z tego test dla graczy. Wybierz tych, którym się nie udało ...

    Za każdym razem, gdy masz dane, które są intensywnie hazardowane , stają się bezużyteczne.

    Ale jest gorzej. Doskonała wydajność metryki staje się flagą dla gracza .

    I to sprawia, że ​​jest lepiej :)

    Więc odwracasz to. Optymalizujesz te testy, aby zidentyfikować osoby, które nauczyły się dobrze testować. Nie czyń swojego testu odpornym na gracza - uczyń go jeszcze bardziej podatnym na ataki gracza, aby gracze poradzili sobie z nim wyjątkowo dobrze, a osoby, które nie zostały „wyszkolone w książkach z wywiadami”, nie. Uwzględnij także inne rozmowy kwalifikacyjne lub testy, do których nie mogą Cię przygotować książki szkoleniowe.

    Teraz zobaczysz wzór / sygnał . Zobaczysz kandydatów, którzy uzyskają naprawdę dobre wyniki w teście gracza, ale będą brali udział w innych rzeczach. To są gracze, nie zatrudniaj ich. I odwrotnie, widzisz kandydatów, którzy w teście dla graczy stosunkowo wypadają słabo, na przykład w 25-50 percentylu w porównaniu z innymi kandydatami. nie są niekompetentni, po prostu są atakowani przez graczy ... i radzą sobie dobrze w innych rzeczach. Zatrudnij ich.

    Nie, to nauka o danych.Dane robią to, czego chcą, a nie to, co zamierzasz ...
    To bardzo odważna sugestia.Warte spróbowania.
    Kłopot w tym, że ten pomysł pochodzi prosto z teorii gier, o czym gracz może już być świadomy.Równowaga Nasha prawdopodobnie nadal przebiegałaby na ich korzyść (jeśli wiedzą, że wiesz, że wiedzą, itp.)
    #22
      0
    Jay
    2018-12-31 11:11:22 UTC
    view on stackexchange narkive permalink

    Mówisz

    „To oczywiście nie byłby problem, gdybyśmy szukali wiedzy o tych problemach… z wyjątkiem tego, że nie tego szukamy dla. "..." Chcemy rozwiązać problemy, a nie zapamiętać. " .

    Właśnie odpowiedziałeś na swoje pytanie. Jeśli chcesz sprawdzić swoje umiejętności rozwiązywania problemów, poproś ich o wyjaśnienie swoich wcześniejszych projektów i szczegółową pracę. Zadawaj im pytania, takie jak dlaczego wybrali określoną platformę / język programowania. Zapytaj ich, jakie były wymagania i w jaki sposób zostały wdrożone itp. Takie pytania dadzą ci wyobrażenie o tym, z jakim złożonością radził sobie kandydat wcześniej. Niektórzy sugerowali, aby faktycznie przedstawić im rzeczywiste problemy z debugowaniem podczas rozmowy kwalifikacyjnej. Chociaż jest to dobre podejście, może być czasochłonne. Ponadto każdy błąd jest inny i nawet świetni programiści mają problemy, jeśli nie znają historii kodu. Myślę, że można połączyć wszystkie trzy podejścia, tj. Niektóre pytania z podręcznika + wcześniejsze projekty + rzeczywiste błędy.

    #23
      0
    user
    2019-01-02 18:45:47 UTC
    view on stackexchange narkive permalink

    Zamiast zadawać konkretne, przygotowane wcześniej pytania, poproś kandydata o przyniesienie próbek swojej pracy. Dla absolwentów może to być coś, co robili na kursie lub jako hobby.

    Następnie możesz o tym z nimi porozmawiać, poprosić o wyjaśnienie, czym się zajmuje i jakie są szczególnie interesujące. Dzięki temu procesowi uzyskasz znacznie więcej, niż zwykłe zadawanie pytań technicznych. Możesz zobaczyć, jak krytyczni są wobec własnej pracy i jak myślą o rozwiązywaniu problemów.

    Odciąża ich to również. Jeśli poprosisz ich o wykonanie zadań związanych z kodowaniem pod presją czasu i przy Tobie, mogą nie działać dobrze, a jest to bardzo sztuczne środowisko i coś, do czego prawdopodobnie nie są przyzwyczajeni.

    Możesz użyć tej dyskusji jako punktem wyjścia do rozmowy o rzeczach bardziej specyficznych dla pracy, ale absolwenci zwykle koncentrują się na zdolności myślenia i uczenia się.



    To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
    Loading...