Zadania podczas interview o prace

0

Co sądzicie o zadaniach podczas interview? Czy warto aplikować na takie ogłoszenia, które wymagają rozwiązywania zadan podczas interview?

1

Jak ktoś ma zero doświadczenia to jak inaczej sensownie sprawdzić czy ktoś cokolwiek umie? Można się śmiać lub nie wierzyć, ale FizzBuzz jest już wystarczająco wysoką poprzeczką, żeby odsiać sporo kandydatów.

1

@Descendant: Nie warto, chyba, że ktoś nie ma wyboru

5

Zadania na rozmowie złe, algorytmy złe, zadania domowe złe, rozmowa techniczna zła, co jest dobre? Link do githuba i oferta, jak to w reklamach bootcampów przedstawiają?

7

Nie do końca rozumiem pytanie. A w jaki sposób chcesz rekrutować programistę jeśli nie patrząc jak rozwiązuje jakiś problem? Peer-programming na interview to jedna z lepszych opcji.

0

@Shalom: Na podstawie Github, oraz jakiegos zadnia, które trzeba odesłac w 1-2 dni. Wiele osób rozwiązuje problemy na podstawie dokumentacji np.

0

@Descendant no i jaką masz pewność że ten ktoś sam zrobił to zadanie a nie kupił rozwiązanie? :)

0

@Shalom: No to w takim wypadku rozwiązaniem jest miesięczny okres próbny i osoba jest szybko weryfikowana podczas realnych zadań.

0
Descendant napisał(a):

Co sądzicie o zadaniach podczas interview? Czy warto aplikować na takie ogłoszenia, które wymagają rozwiązywania zadan podczas interview?

Nie wiem gdzie aplikujesz, ale Google i reszta FAANg, na Wall Street i w podobne miejsca to chyba obowiązkowy etap.
Piszę "chyba" bo nie wiem jak przebiega rekrutacja ludzi których taki Google samo wyszukuje i zaprasza do pracy (są tacy mistrzowie)

Więc nie dziw się, że i w Polsce z tym się spotykasz.

BTW, skąd wiesz od razu, że tu, tam i konkretnie tam

wymagają rozwiązywania zadan podczas interview
?

6

Ja jestem fanem niewyszukanych algorytmów lub innego zadania do napisania na miejscu. Od razu widać czy ktoś kuma z jednej strony, z drugiej nie ma dawania zadania domowego na kilka dni.
Generalnie unikam firm które tego typu zadań nie robią. Pamiętaj im niżej poprzeczka tym słabszy poziom ludzi, ergo bardziej syfny kod/dizajn.
Inna sprawa że wiele osób po prostu wciska kit podczas rekrutacji, prosto w żywe oczy. Zawsze więc warto zweryfikować to co jest w CV jakimś pytaniem czy kawałkiem kodu.
Przykład: każdy kto mówi że zna JS powinien być w stanie wyrzeźbić dziedziczenie Animal -> Cat, Dog bez mrugnięcia okiem.
Tak samo Javoviec powinien umieć napisać na zawołanie klona unix'owego wc.

1

Czy warto aplikować na takie ogłoszenia, które wymagają rozwiązywania zadan podczas interview?

Nie, jeżeli nie umiesz programować lub jesteś słaby psychicznie.

Remedium: competitive programming, zapisz się na Karate.

0

Są sensowne, żeby zobaczyć czy ktos ogarnia własny język i umie coś programować. Natomiast opierać rekrutacje tylko na zadankach z leetcode to tak średnio myślę.

No chyba, ze ktoś będzie pracował w miejscu gdzie algorytmika ma duże znaczenie, więc to co innego.

1
null null napisał(a):

Zadania na rozmowie złe, algorytmy złe, zadania domowe złe, rozmowa techniczna zła, co jest dobre? Link do githuba i oferta, jak to w reklamach bootcampów przedstawiają?

Chyba najlepsze jest wspólne kodzenie na żywo
Wspólne czytanie kodu, to jest chyba kluczowe przy utrzymaniu a tego jest najwięcej.
Algo, zadania itd to wiesz, bywa że pierwszy i ostatni raz używa się tego podczas rekrutacji.
Jak dla mnie jest to mega wkurzające bo z algo to średnio i szybko szybko ulatuje. Mam kompleks na tym punkcie ale jak było coś konkretnego z algo do roboty to był zewnetrzny team. My byliśmy od bugów. Nawet jakby się chciało coś porobić to nie, nie dopchasz się.

Ogólnie rozmowy to temat rzeka.
Mnie w rozmowach najbardziej irytuje że wymagają Hgw czego a w codziennej pracy to for i if wystarczy. A, ważniejsze od pisania jest czytanie i odnalezienie się w kodzie.

2
Shalom napisał(a):

@Descendant no i jaką masz pewność że ten ktoś sam zrobił to zadanie a nie kupił rozwiązanie? :)

Bardzo łatwo to sprawdzić podczas następnego etapu. Kandydat dostaje wówczas do wprowadzenia małą, ale kluczową zmianę. Jeśli nie wie nawet gdzie zacząć, to można podejrzewać, że to jednak nie on stworzył pierwotną wersję.

0

Zadania typu leetcode, algorytmiczne mają to do siebie, że niektóre problemy najlepiej się 'wyuczyć' - jak drugi raz zobaczysz coś podobnego to wiesz od razu co robić - w przeciwnym wypadku musisz kombinować a wiadomo jak jest pod presją stresu na rozmowie. Ostatnio jak prowadzę rozmowy to wolę dać coś w stylu "masz tutaj dokumentację API, przygotowany przeze mnie token, napisz program który pobierze X informację". I potem rozwijam w zależności jak idzie kandydatowi - np. odpowiednio przerobić informację, wyświetlić, zapisać. Mam też w pogotowiu własne przygotowane środowisko + remote control. Ale nawet jak zadaje się bardzo proste lub trudne pytania to jedno widać od razu - czy ktoś faktycznie cokolwiek tworzy w danym języku. Wiele osób ma problem z najprostszymi pętlami (mimo bujnego CV). A porządny senior od razu pisze zgodnie z przyjętymi konwencjami, dobrze zastosuje dany język (wraz z jego paragmatami) itp. Więc nawet jeżeli nie będzie w stanie rozwiązać zadania - np. przez stres - to bardziej uznam fakt, że było widać że pracuje z danymi technologiami a nie wpisał ich na pałę do CV.

A samą rozmową nie da się dobrze wybrać - widziałem kandydatów co odpowiadali idealnie na każde pytanie teoretyczne ale totalnie wysiadali przy najdrobniejszych zadaniach, albo na pytaniach "z doświadczenia". A zadania do domu wymagają więcej czasu od sprawdzającego na porządne przeanalizowanie rozwiązania.

2

Stara śpiewka. Jeśli świadomie planujesz karierę, a nie jesteś skoczkiem, to poświęcenie tych 3-4h na pochwalenie się umiejętnościami to nie powinien być absolutnie żaden problem. Pair programming podczas interview? Bajka rozwiązanie

2

Wszystkim nie dogodzisz, kodowanie na rekrutacji musi być. Przypominała mi się jeszcze pewna anegdota. Pewnego razu kolega zadał takie pytanie na rekrutacji (odtwarzam z pamięci):

Programista wydzielił kod odpowiedzialny za pobieranie czasu do osobnego obiektu, korzystając z wzorca singleton:

// pseudo-java
singleton class TimeProvider {
  static DateTime currentTime() {
     return DateTime.now();
  }
}

Jakie zalety ma takie rozwiązanie w stosunku do "zahardkodowania" odwołań do DateTime.now w kodzie aplikacji?

Osobiście uważam że pytanie to jest z kategorii tych "z d**y". Ale bardziej zaniepokoił mnie fakt że odpowiedź na to pytanie znajdowała się w książce którą gościowi sam poleciłem kilka miesięcy wcześniej!
Widać więc że nawet bez kodzenia (tu była tylko rozmowa), można dawać bardzo ezoteryczne czy podchwytliwe pytania. Zdrowego rozsądku jednak nic nie zastąpi, nie ważne jaka by ta rekrutacja nie była.

Dla tych co się zastanawiają jak jest oczekiwana odpowiedź:

Singleton można w prosty sposób zmodyfikować tak żeby był testowalny, np:

// psuedo-java
singleton TimeProvider {
  @VisibleForTesting
  static void setTimeOverride(DateTime time) {
   timeoverride = time;
 }

static void reset() { timeoverride.reset(); }

  static DateTime currentTime() {
     return timeoverride.isSet ? timeoverride.get : DateTime.now();
  }

  thread-static timeoverride;
}

Osobiście jak by mi takie pytanie zadano to bym wyszedł, singletonów nie znoszę. No ale kolega mógł się popisać elokwencją i podbudować swoje ego (które jak wiadomo nigdy nie jest za duże).

2
0xmarcin napisał(a):

Osobiście uważam że pytanie to jest z kategorii tych "z d**y".

To są najważniejsze pytania na rekrutacji.
Te zwykłe są nieistotne, bo pokażą tyko, że kandydat mniej lub bardziej zna temat.

Liczą się te cudaczne, bo u kandydata wywołują poczcie braku wiedzy, zaniżają jego wewnętrzną wartość i samoocenę.
Przykład: nawet po wielu miesiącach pamięta, że czegoś dziwnego nie wiedział i dyskutuje o tym z kolegami.
I w końcu pozwalają podsumować rekrutację:

  • Ale tego z tamtej książki Pan nie znał, więc możemy panu zaproponować 30% mniej od dolnych widełek w pierwotnej propozycji.
  • Niestety, tego nie wiedziałem. Zgadzam się na 30% mniej od minimalnej pierwotnej propozycji.
1

Taka rekrutacja jest najlepsza bo weryfikuje czy ktoś umie programować, umie też czytać kod innych osób i nie zajmuje tyle czasu.
A ja mam wrażenie że niektórzy by chcieli dostać 15k bo powiedzą że znają dżawe springa i hajbernejta.

0

Wszystkie firmy w bay area na ostatni etap zapraszają kandydatów na wieloetapową trwającą ok.7 godzinną rekrutację, składającą się z kilku bloków po 30-1.5h. Zazwyczaj transportują cię na swój koszt do swojego biura, ale akutalnie robią to zdalnie.

Etapy w przypadku Frontend Deva wyglądają mniej więcej tak:

  • programowanie i algorytmy
  • product i smak techniczny
  • znajomość JS
  • pragmatyczne programowanie UI
  • projektowanie i architektura oprogramowania
  • lunch i trochę czasu dla siebie (podczas lunchu dostajesz feedback
  • spotkanie z managerem ds. rekrutacji

1 użytkowników online, w tym zalogowanych: 0, gości: 1