Haskell
2019-07-10 22:37

Interview

Byłem dziś na rozmowie technicznej w pewnej firmie. Co ciekawe żeby dostać się na tę rozmowę musiałem najpierw odbyć rozmowę HR i techniczną (więc miałem w sumie dwie rozmowy techniczne) w firmie outsorucingowej.

Pythona, który jest głównym wymaganiem w ogłoszeniu używałem w pracy dwa lata temu, więc przed rozmową był mały stres, bo z pewnością przez te dwa lata trochę zapomniałem. Dodatkowo rozmowa miała być po angielsku (1,5h!!!), a ja nie używam języka w mowie na co dzień czego bardzo żałuję, więc stres x2.

Na początku lider zespołu zaczął pytać o to jak wyobrażam sobie swoją karierą skoro mam w CV taki szeroki zakres używanych technologii (mam 10+ lat doświadczenia) oraz przez wiele lat zajmowałem się programowaniem w bazach danych i czy jestem pewny, że chce się zajmować backendem. Pierwsza moja myśl WTF, przecież programowanie w bazie danych to jest backend. Ja tam piszę logikę biznesową, nikt nie dałby mi wielokrotności średniej krajowej za pisanie "SELECT * FROM" i robienie prostych raportów. Poza tym jeżeli mój profil nie pasuje do zespołu, to po co mnie zapraszają na rozmowę? Wielki minus dla rekrutującego, ale dobra, staram się trzymać nerwy na wodzy, choć stres już mam x3 i odpowiadam na pytanie zgodnie z prawdą, że tak chce się zajmować backendem i pisać w Pythonie.

Później lider zaczął sobie robić podśmiechujki na temat tego, że napisałem w CV, że w jednej z pierwszych firm kilkanaście lat temu używałem Perla, Firebase i Interbase. Drugi minus dla rekrutera. Może nie wyglądam staro, ale tak drogi rekruterze, mam już tyle lat, że używałem takich zapomnianych obecnie technologi.

Później było pytanie o to jak wyciągnąć dowolną liczbę najczęściej pojawiających się słów na liście. Ogólnie nie wiem czy pytanie było bardziej algorytmiczne czy bardziej Pythonowe, ponieważ w Pythonie można skorzystać z Counter i metody most_common. Ja przez ten stres trochę zabłądziłem z odpowiedzią. Zaproponowałem użycie słownika (hash table dla nie znających Pythona) w którym słowa byłyby kluczami, a wartością ilość wystąpień. Następnie chciałem posortować wartości ze słownika (można to zrobić sorted(d.items(), key=lambda x: x[1])) w ten sposób uzyskując x największych liczb i potem zwrócić słowa występujące częściej niż najmniejsza liczba z tych odnalezionych.

W trakcie odpowiadania na te pytanie stało się coś dziwnego. Temat zbłądził gdzieś na temat tego czy dane słowniku są posortowane. Zgodnie z wiedzą odpowiedziałem, że klucze w słowniku w Pythonie od wersji 3.7 są posortowane w kolejności w jakiej zostały wprowadzone. Lider po wygooglaniu odpowiedzi odpowiada na to, że nie można polegać na tym, że coś tak działa w danej wersji, a jutro może działać inaczej. Myślę sobie po raz kolejny WTF? Przecież to zostało zrobione intencjonalne, ktoś żeby ułatwić życie programistom zaimpelementował słownik tak aby klucze były posortowane w kolejności wprowadzania. To z całą pewnością nie zmieni się, it's a feature not a bug. Trzeci minus dla rekrutującego...

Następnie lider chciał chyba pochwalić się wiedzą z zakresu baz danych i zapytał mnie czy jak piszę te swoje SELECT * FROM to czy dostaję rekordy w określonej kolejności. Odpowiedziałem zgodnie ze swoją wiedzą, że jeżeli na tabeli jest indeks klastrowany, to dane są uporządkowane w bazie danych zgodnie z tym indeksem i baza zwróci je w takiej kolejności. Na to rekruter odpowiada, że się mylę i że dane są nieuporządkowane, bo inaczej (!) oznaczałoby to, że wstawienie jednego rekordu w środku tabeli oznaczałoby konieczność przesunięcia wszystkich rekordów. Aż mnie zamurowało, kolejny raz myślę sobie WTF? Czwarty minus dla rekrutującego.

Potem były inne pytania, choć powiem Wam, że już miałem w nosie jak odpowiadam i zastanawiałem się czy nie wyjść z tej rozmowy, bo to nie ma sensu. Nie chcę pracować z człowiekiem, który prowadzi rekrutację w taki sposób...

Na koniec były pytania z Linuksa, choć w ogłoszeniu nie było w ogóle mowy o tym, że wymagają jego znajomości. Piąty minus dla rekrutera, ponieważ w ogóle nie byłem przygotowany na te pytania, a gdybym wiedział o tym Linuxie to może bym coś sobie powtórzył lub stwierdził, że nie chcę iść na tą rekrutację, ponieważ nie zdążę się przygotować.

Ogólne wrażenia z tej rozmowy mam takie:

  • Im lepiej się przygotujesz tym mniejszy stres. Ja byłem słabo przygotowany po długiej przerwie z Pythonem oraz z powodu nieużywania angielskiego na co dzień i stresu było sporo. Gdybym przygotował się lepiej stresu byłoby mniej i z pewnością zrobiłbym lepsze wrażenie.
  • Interview jest jak randka. Zarówno ty musisz się spodobać rekruterom oraz (co dziwne dla desperatów) rekruterzy muszą zrobić dobre wrażenie na tobie, ponieważ będziesz z nimi na co dzień pracować. Ja chyba jednak nie chcę pracować w tej firmie, z pewnością nie w tym projekcie.
TurkucPodjadek

Brzmi nieprofesjonalnie, bo nie powinni Ci dawać znać czy dobrze odpowiadasz czy nie, co najwyżej delikatnie naprowadzać. Wykłócanie się jest słabe.

PS Dev z 10letnim doświadczeniem zaskoczony pytaniami o Linuksa, jak rozumiem do tej pory praca na apkach deployowanych na Windowsie? :P

Afish

jeżeli na tabeli jest indeks klastrowany, to dane są uporządkowane w bazie danych zgodnie z tym indeksem i baza zwróci je w takiej kolejności

Niekoniecznie. Mając fragmentację dane mogą nie być fizycznie posortowane na dysku (ale są posortowane logicznie zgodnie z indeksem klastrowym) i teraz jeżeli serwer zdecyduje czytać dane w kolejności „fizyczne”, to zwróci je nieposortowane, a jeżeli zdecyduje w kolejności „logicznej”, to będą. W przypadku SELECT * FROM prawdopodobnie poleci zgodnie z fizycznym ułożeniem, więc dane nie będą posortowane. To oczywiście zależy od serwera, standardu, optymalizacji, wersji (licencji) itp.

bo inaczej (!) oznaczałoby to, że wstawienie jednego rekordu w środku tabeli oznaczałoby konieczność przesunięcia wszystkich rekordów

Wszystkich nie, ale kilku na stronie tak. Znowu, zależy od serwera, implementacji itp.

Aryman1983

@TurkucPodjadek: zależy jakie to były pytania, bo OP nie napisał jak głęboko się zanurzyli.

Haskell

@TurkucPodjadek - uczestniczyłem już w niejednej rekrutacji, a nawet pracowałem w firmie gdzie pracowaliśmy na terminalu na Linuxie z użyciem VIM-a (praca zdalna, klient chciał kontrolować ile czasu programiści kodują) i co ciekawe nikt nigdy nie pytał o Linuxa. Pytań z Linuxa mieli przygotowanych 15, zadali około 5-6, z których na około połowę odpowiedziałem. Nie jestem zaskoczony, że o to pytali lub że tego wymagali, mają święte prawo. Zaskoczyło mnie tylko niemile, że nie wiedziałem, że będą o to pytać, ani nie wspomnieli w ogłoszeniu. Przed interview zawsze pytam czego będzie dotyczyć rozmowa.

Btw. wykłócania się nie było, po prostu rekruter powiedział, że nie mam racji, a ja nie riposotwałem tylko sobie myślałem WTF, co ja tu robię...

Haskell

@Afish - ja konkretnie wspomniałem którą bazę mam na myśli, o tym co to są strony i jak działają też wspomniałem. Powiedziałem, że jeżeli na tabeli jest indeks klastrowany, to dane są przechowywane w bazie w kolejności zgodnie z kluczem. O stronach wspomniałem gdy stwierdził, że wstawienie w środek tabeli spowoduje przesunięcie połowy rekordów, na co rekruter odpowiedział, że i tak dane nie są ułożone w kolejności...

Afish

to dane są przechowywane w bazie w kolejności zgodnie z kluczem

O tym mówię, fizycznie nie muszą być w kolejności zgodnie z kluczem. Może zawiodła komunikacja i źle się zrozumieliśmy (albo zrozumieliście z rekruterem), ogólnie to brzmi mi na typowe pytanie „na uwalenie”.

Haskell

Powiedziałem, że konkretnie w SQL server są przechowywane zgodnie z kluczem, tak przynajmniej twierdzi dokumentacja, nawet sprawdzałem po rozmowie :) "The only time the data rows in a table are stored in sorted order is when the table contains a clustered index."

cerrato

Fajnie, że piszesz z dystansem do siebie, umiesz przyznać się, że czegoś nie wiedziałeś, że się stresowałeś, że nie do końca czujesz się pewnie ze swoim angielskim itp. Wiele osób by nie było w stanie tego zrobić i albo by te kwestie przemilczały, albo trochę ściemniały (zwłaszcza, że online można być praktycznie kimkolwiek, ciężko taką ściemę wyczuć).

Afish

@Haskell: No właśnie nie. Dokumentacji nie przytoczę, bo tam trudno znajduje się takie rzeczy, ale w SQL Server 2012 Internals możesz o tym poczytać, albo tutaj: https://www.red-gate.com/simp[...]/effective-clustered-indexes/ (szukaj Reduction in clustered index fragmentation). Dane nie muszą być uporządkowane na dysku, jeżeli jest spora fragmentacja.

Panczo

Strasznie nie lubię określenia klastrowany, zdecydowanie bardziej odpowiada mi: grupujący....

Shalom

Pierwsza moja myśl WTF, przecież programowanie w bazie danych to jest backend

Ale bardzo mocno różniący się od backendu po stronie aplikacji, więc pytanie było dość zasadne.

Przecież to zostało zrobione intencjonalne, ktoś żeby ułatwić życie programistom zaimpelementował słownik tak aby klucze były posortowane w kolejności wprowadzania.

Ale do niedawna był to tylko szczegół konkretnej implementacji interpretera a nie wymóg specyfikacji. I faktycznie przed py3.7 nie należało na tym polegać, bo inny interpreter nie musiał tego tak implementować. Możliwe że rekruter nie wiedział że zostało to teraz umieszczone w specyfikacji.

jeżeli na tabeli jest indeks klastrowany, to dane są uporządkowane w bazie danych zgodnie z tym indeksem

Ale to nie znaczy ze zostaną w takiej kolejonści zwrócone! Pewnie tak, bo optymalizator raczej uzna to za najlepsze rozwiązanie, ale nie jest to w żaden sposób jasno określone. Optymalizator kosztowy może z takich czy innych powodów zachować się inaczej. O czym specjalista od baz danych powinien wiedzieć. To jak z tym pythonem -> jest różnica między empirycznymi doświadczeniami a specyfikacją.

Na koniec były pytania z Linuksa, choć w ogłoszeniu nie było w ogóle mowy o tym, że wymagają jego znajomości

Równie dobrze mógłbyś rantować ze nie było nic o obsłudze myszki. Faktem jest że praktycznie wszystkie aplikacje serwerowe stoją na linuxach i trudno wyobrazić sobie klepanie backendu bez podstawowej znajomości.

Afish

@Shalom:

Optymalizator kosztowy może z takich czy innych powodów zachować się inaczej. O czym specjalista od baz danych powinien wiedzieć.

Tam był podany SELECT *, więc zgodnie z tą logiką specjalista tym bardziej powinien wiedzieć, co się stanie fizycznie.

Haskell

@Shalom - to nie była rekrutacja na specjalistę od baz danych, ale dobrze wiedzieć, że nie nadaje się do tego czym zajmuje się parę ładnych lat :)

Panczo

Ale to nie znaczy ze zostaną w takiej kolejonści zwrócone!

@Shalom jakie masz doświadczenie z MSSQL? Bo @Haskell wyraźnie zaznaczył, że mówi o tym silniku i tam zawsze jak występuje clustered index to dane zwracane są w tej kolejności.

Afish

@Haskell: O tym mówię, to zachowanie jest opisane w dokumentacji, ale nie na pierwszej stronie odnośnie indeksu. Nie mam niestety lepszego źródła, a szybkie googlowanie nie pomogło niestety.

Shalom

MSSQL? Bo @Haskell wyraźnie zaznaczył, że mówi o tym silniku

@Panczo Gdzie? Ja nigdzie tej informacji nie widzę. Ba, wygląda że pytanie zadane przez rekrutera było ogólne.

Panczo

@Shalom zakładam że pytasz mnie wolajac @Afish ;)
@Haskell doprecyzował w komentarzu:

Powiedziałem, że konkretnie w SQL server są przechowywane zgodnie z kluczem, tak przynajmniej twierdzi dokumentacja, nawet sprawdzałem po rozmowie "The only time the data rows in a table are stored in sorted order is when the table contains a clustered index."

Wiem, że można odpowiednimi hintami (TABLOCK) "zmusić" SQL Server do zwrócenia danych w fizycznym porządku na dysku (niezgodnym z clustered index) i teoretycznie optymalizator sam w jakiś szczególnych przypadkach może nalozyc blokadę na cala tabelę, ja osobiście z SQL Serverem pracuje od wersji 7.0 i taki przypadek nie wystąpił. Jednak posiłkuje się wiedzę lepszych ode mnie, i wszyscy mówia, że 99.99% będzie to kolejność indeksu, ten 0.01% może wystąpić, ale nik w praktyce tego nie widział.
Co do zasady zgoda, zgodnie z teorią kolejność, jeśli nie jest wymuszona (order by) "nie istnieje" i nie można jej zakładać, ale omawiamy przypdek konkretnego produktu, kontretnego producenta...

Afish

@Panczo: Ktoś widział ten 0,01%, tutaj gość to pokazuje: https://www.red-gate.com/simp[...]/effective-clustered-indexes/

Osobną kwestią jest, czy to pytanie ma sens.

Haskell

Jak widać pytanie ma sens, można pokazać pozostałym 6 osobom uczestniczonym w interview, że ten oto człowiek nie wie co robi, nawet w swojej dotychczasowej pracy polegającej na pisaniu SELECT *, bo nie wie co mu zwróci :)

Panczo

@Afish gdzie w tym artykule jest o kolejności zwracania rekordów? nie neguje że zapis fizyczny różni się od logicznego, ale nie o tym jest dyskusja...

Afish

@Panczo: https://docs.microsoft.com/en[...]eference?view=sql-server-2017
The Clustered Index Scan operator scans the clustered index specified in the Argument column of the query execution plan. When an optional WHERE:() predicate is present, only those rows that satisfy the predicate are returned. If the Argument column contains the ORDERED clause, the query processor has requested that the output of the rows be returned in the order in which the clustered index has sorted it. If the ORDERED clause is not present, the storage engine scans the index in the optimal way, without necessarily sorting the output. Clustered Index Scan is a logical and physical operator.

Jak nie ma ordered, to poleci fizycznie po danych i przy fragmentacji będzie nie po kolei.

Panczo

@Afish ja znam dokumentacje, ja wiem, że clustered index nie gwarantuje kolejności, powiem więcej nawet używam order by jak chce mieć pewność co do koleności zwracanych danych ;)
Pisze o praktyce pracy z SQL Server.
Z czasów przed dostępem do row_number() indeks grupująy był "gwarantem" przenumerowania danych w odpiwedniej kolejności (mam na myśli małpkowanie). I tak dokumentacja swoje, praktyka swoje.
Żeby nie przeciągać, zgadzam się z Tobą :)

Haskell

@Afish - bardzo dziękuję za tego linka, teraz będę mógł udzielić bardziej precyzyjnej odpowiedzi. Wiele osób mówi, że wina leży zawsze po obu stronach, stąd to też dla mnie znak, że muszę inaczej formułować odpowiedzi.

Powiedziałem, że rekordy w SQL Server są posortowane wg klucza gdy mamy indeks klastrowany, ale oczywiście miałem na myśli również to, że w pozostałych przypadkach nie są. Gdybym sformułował odpowiedź inaczej i powiedział, że rekordy są nieposortowane, ale są pewne wyjątki, to zapewne rekruter odebrałby moją odpowiedź zupełnie inaczej.

Podobnie z odpowiedzią na kolejność w słowniku (hash table). Gdybym powiedział, że dane w słowniku nie są posortowane, a jako ciekawostkę wspomniał, że w 3.7 są posortowane wg kolejności wprowadzania, to prawdopodobnie również wtedy rekruter odebrałby moją odpowiedź inaczej.

Niestety stres i konieczność odpowiadania w języku angielskim sprawiły, że odpowiedziałem tak, a nie inaczej.

WhiteLightning

@Haskell: pochwalisz sie pytaniami z Linuxa?

Haskell

Pytania były raczej łatwe, np. 1. Jaką mamy dostępną przestrzeń adresową na 32 bitowym systemie. 2. Co oznacza podany krótki kod w Bashu (był m.in. wc z parametrem l). 3. Było pytanie o przydzielanie praw do plików wrx. 4. Jak sprawdzić który proces używa pliku. 5. Jak ustawić i zsynchronizować datę 6. Jak sprawdzić obciążenie procka.

Pozostałych niestety nie pamiętam, mieli ich w sumie kilkanaście.

komuher

W sumie to slownik jest juz posortowany od 3.6 a od "pre 3.7" jest to juz standard jezyka czyli kolega musial byc sporo wstecz od aktualnych wersji pythona. Co do rekrutacji to w sumie nic nowego sam mialem rozmowy na których osoby które mnie rekrutowały nie mialy pojęcia o czym mówią :D

LukeJL

@TurkucPodjadek: Brzmi nieprofesjonalnie, bo nie powinni Ci dawać znać czy dobrze odpowiadasz czy nie, co najwyżej delikatnie naprowadzać. Wykłócanie się jest słabe. - takie coś byłoby właśnie słabe. Najgorsze rekrutacje to takie, w których nie dostajesz feedbacku na żywo i myślisz, że dobrze ci idzie - a potem się okazuje, że nie. I nawet nie wiesz co spieprzyłeś, że cię nie przyjęli. Wykłócanie się jest słabe. - wykłócanie się owszem nic nie da, jeśli rozmawiasz z gburem i ignorantem, jednak jak rozmawiasz z normalnym człowiekiem, który gdzieś się machnął, to akurat zwróceniem uwagi, że "to tak nie jest" możesz zaplusować wiedzą i sprawić, że ktoś przyzna ci rację i powie, że się machnął i że dobrze, że zwracasz na takie rzeczy uwagę.

cmd

@Haskell: Współczuję żenujących pytań i rekrutacji, a po pytaniu odnośnie sortowania słowników grzecznie wstał i wyszedł po takiej reakcji rekrutera. Też miałem uderzać na to ogłoszenie ale po zapoznaniu się z opiniami znajomych znajomych odpuściłem sobie. Ogólnie ta rekru do Nielsena to trwa non stop chyba na to stanowisko, teraz nie dziwię się dlaczego.

yarel

@Haskell: za tymi 32-bitami kryło się coś więcej, w rodzaju Physical Address Extension?

Haskell

@LukeJL: Pełna zgoda. Ja też wolę otrzymać feedback na gorąco, jeżeli odpowiadam, że nie wiem, bądź moja odpowiedź była zła/niepełna. Takie rozmowy są bardzo cenne, ponieważ możesz łatwo się zorientować co potrafisz, a co jest jeszcze do poprawy.

TomRZ

Dlatego właśnie pracuję solo jak freelancer w domciu w kapciach, nie lubię różnych kierowników i innych dupków nad sobą, moim szefem jest klient i nikt więcej.

TurkucPodjadek

@LukeJL: obszerny feedback można dać po rozmowie, nic temu nie przeszkadza, a na rozmowie lepiej nie zgrywać pajaca, bo można ośmieszyć firmę do której się kogoś rekrutuje. Poza tym, doskonale wiesz co spiepszyłeś, będąc kandydatem oczywiście, pytanie jest tylko na ile to „spiepszone” jest ważne dla firmy.

Haskell

@TurkucPodjadek: feedback po rozmowie też jest spoko, ważne żeby był. Najgorsze są rekrutacje gdzie marnujesz kilka godzin, albo piszesz jakieś zadanie domowe, a później cisza.

LukeJL

@TurkucPodjadek dobra, tylko czemu zwrócenie uwagi błąd ma być "zgrywaniem pajaca"? Jeśli ja się udaję na rozmowę jako kandydat i się pomylę/źle zrobię, to jeśli osoba rekrutująca zwróci mi uwagę np. "mylisz się, false == 0 będzie równe true w JavaScript, a nie false, jak powiedziałeś", to czy osobnik rekrutujący mnie wyjdzie wtedy na pajaca, bo mi zwrócił uwagę na mój błąd? Więc rekruter powinien udawać, że robię dobrze, żebym nie pomyślał o nim źle? Dziwne. Wg mnie kultura braku feedbacku jest szkodliwa i należy z tym walczyć. Feedback po rozmowie też jest ok, jeśli jest rzetelny. Niestety firmy często piszą fejkowy feedback, gdzie albo wciskają tanią bajerę, że doceniaja twoje umiejętności, bla, bla, bla, ale że koniec końców wybrali innego kandydata bo wydawał się fajniejszy. Ew. zdarzało mi się, że taki mejlowy feedback był kompletnie WTF, gdzie widać było, że wynikło jakieś nieporozumienie, które można było wcześniej sprostować.

czysteskarpety

Bolesne to, że tracisz praktycznie cały dzień na takie pierdoły, a jak kilka etapów (co zwykle obowiązkowe) to i kilka dni :|

LukeJL

Poza tym, doskonale wiesz co spiepszyłeś, będąc kandydatem oczywiście, @TurkucPodjadek nie zawsze, kiedyś myślałem, że mi dobrze poszło, bo np. na pytanie o to jak działa HTTP, po prostu powiedziałem jak działa, że są żądania z klienta do serwera, i że nagłówki itp. i całą wiedzę przelałem gościowi, który mnie pytał o to. No i ucieszony, że łatwe pytanie - a słyszę nagle szok i gościu do mnie z tekstem "a czy używał Pan tego kiedyś w praktyce?". No nie kurde, nauczyłem się definicji na pamięć i powtarzam, kurczę, nie wiem co on miał w głowie :D Aczkolwiek to pokazuje, że czasem to, co jednej stronie się wydaje ok, druga strona odbiera inaczej (bo gość zrozumiał pewnie, że za dużo wiem na ten temat, że się pewnie wykułem definicji - więc zamiast na plus, to było na minus chyba). I to na żywo zdarzają się takie nieporozumienia, a co dopiero jak feedback jest dopiero po rozmowie...

TurkucPodjadek

@LukeJL: znaczy się, zmieniło by Ci coś, że dostaniesz nierzetelny feedback od razu czy telefonicznie po paru dniach? Na miejscu byś się bił czy co? Bo wydaje mi się, że nie chciałbyś pracować w firmie, w której ocenią Cie negatywnie za zbyt obszerną wiedzę.

nohtyp

@Haskell Im lepiej się przygotujesz tym mniejszy stres - Odnośnie stresu i rozmów to lepiej chodzić na rozmowy właśnie, gdy nie musisz. Wtedy nie trzeba się starać, bo i tak jest dobrze. A co do samej rekuratacji to dostałeś pytania jak pod juniora, tzn ja na juniora miałem trudniejsze pytania np opisanie wewnętrznej implementacji słownika, wpływu na fragmentację, pytania o współbieżność i izolacje w bazach itp. Ostatecznie nie wiem czemu bijesz pianę. Rynek Cię zweryfikował, to pewnie boli, ale jednocześnie motywuje do działania. Powodzenia!

axelbest

@nohtyp: powiedz mi chociaż że na tego juniora miałeś stawkę przynajmniej 6k. Widziałem firmy w których na regulara wystarczyło umieć pisać left joiny

nohtyp

@axelbest ja też takie firmy widziałem, ale nie chciałem w takich firmach pracować. Trzeba się szanować.

Haskell

@nohtyp: Po pierwsze nie muszę chodzić na rozmowy, ponieważ mam pracę i nie jest najgorsza, ale to wcale nie powoduje, że stresu w ogóle nie ma. Po drugie nie miałem zamiaru tym wpisem bić żadnej piany, chciałem tylko przedstawić swoje wrażenia po rozmowie. Napisałem o swoim stresie, o tym co mi nie poszło, o tym co nie poszło rekruterom. Może komuś się przyda to co napisałem i nie popełni takich błędów jakie popełniłem ja (słabe przygotowanie, stres). Może przeczyta to ktoś rekrutujący i dojdzie do jakiejś refleksji.

Afish

@Haskell: A prowadzisz rekrutacje u siebie w firmie? Moim zdaniem to bardzo pomaga potem przy chodzeniu na rozmowy.

Haskell

@Afish: Nie, nie miałem okazji rekrutować u siebie ludzi. Jeżeli będę miał okazję to chętnie usiądę po drugiej stronie.

LukeJL

@TurkucPodjadek chodzi mi o to, że po fakcie wszystko można sobie nagiąć do własnych celów, szczególnie jak wchodzi w grę interakcja z osobami trzecimi. Moja rekrutacja sprzed kilku lat, o której kiedyś tu pisałem (gdzie mi chcieli potrącić z pensji z komputer i biurko) już na żywo było absurdalna i widziałem już, że mam do czynienia z burakami i że wątpię, żebym chciał tam pracować, ale po rozmowie nakłamali mojemu pośrednikowi za moimi plecami. To dopełniło czarę goryczy, bo jeśli już w czasie rekrutacji takie rzeczy się dzieją, to strach pomyśleć co będzie potem (podkładanie świni w pracy i robienie jakichś intryg za plecami?). Poza tym rozmawiając nie twarzą w twarz łatwiej jest po prostu urwać kontakt - więc na żywo jest większa szansa, że jakikolwiek feedback się uzyska - bo jest to czesto sytuacja "now or never".

nohtyp

@Haskell Wg mnie taki post nie jest wartościowy, ponieważ wprost piszesz o którą firme chodzi, przedstawiasz swoją wersję, punktujesz minusy jakie Twoim zdaniem popełnili. Możliwe, że rozmowa potoczyłaby się lepiej dla Ciebie, gdyby zadali Ci pytania z innej pułki, np. wymagające kombinowania niż znajomości specyfikacji stosowanych narzędzi. No, ale to oni rekrutują więc mają prawo do pytań. Natomiast postawa, gdzie publicznie piszesz co Ci się nie podobało w trakcie rozmowy jest po prostu mało profesjonalna.

LukeJL

@TurkucPodjadek poza tym na żywo(wszystko jedno teraz czy w realu, telefonicznie, czy videofonicznie) masz szansę skorygować. Np. mówię rzecz X, która nudzi odbiorcę, to mając feedback typu "może nie mów już o X, bo nie ma znaczenia w tym momencie, a powiedz o Y" mogę przestać mówić o X, a zacząć mówić o Y". Natomiast bez feedbacku to mówię o X, myślę, że dobrze wypadam, a potem po rozmowie np. cisza i się ktoś już nie odzywa. Wtedy mogę się dopiero domyslać, że nie potrzebnie mówiłem o X. Anyway, nie kumam filozofii wg której rekrutacja na programistę ma wyglądać jak spotkanie u psychiatry (jedna osoba mówi, a druga tylko zadaje pytania, słucha, i zapisuje w notatniku")

Haskell

@nohtyp: Półki pisze się przez o z kreską. Nazwę firmy mógłbym w sumie usunąć, bo nie jest to bardzo istotna informacja. Nie widzę jednak nic złego w tym, że dziele się swoimi wrażeniami z innymi.

nohtyp

@LukeJL jejuu.. ale analizujesz :) Wiesz, czasem najbardziej możliwe, są te najprostsze sytuacje. Zobacz, możliwe, że na rozmowie mogłeś wypaść świetnie, ale ktoś za Tobą w kolejcebył po prostu tańszy i tyle. Jaki feedback miałby Ci wtedy wysłać rekruter? "Wszystko jest dobrze, ale cena nam JUŻ nie pasuje?" Jakby nie patrzeć taki mail to również absurd, bo mógłbyś to czytać jako próbę zaniżenia Towjej pracy - to też absurd, nie? :)

Silv

@Haskell: dzielenie się wrażeniami w wąskim gronie znajomych nie ma wielkiego wpływu (kilka osób), za to dzielenie się wrażeniami na forum internetowym ma większy wpływ (kilkaset... kilka tysięcy osób). Myślę, że @nohtyp pije do tej różnicy (która może wydawać się subtelna z punktu widzenia programisty, nie przeczę). Dla firmy, w której rekrutowałeś, czasem nawet dla rekrutera(ów), może robić różnicę, czy mówi się o nich negatywnie w niewielkim, czy w większym gronie.

nohtyp

@Silv Haskell chciał być sprytny, tzn liczył na to, że uda mu się wysmarować firmę, a tym czasem dał popis godny gimbazy. Jakby nie patrzeć plus dla tej firmy, że potafią odbić takich [CIACH!].

Shalom

@nohtyp: no no, bez takich proszę!

Haskell

@Silv: Ok masz rację, niepotrzebnie wymieniłem nazwę firmy.

LukeJL

forum upada. Już ktoś kogoś nazywa głąbem. Wczoraj ktoś inny nazwał kogoś fanatycznym błaznem i cholernym ignorantem...

Silv

@LukeJL: w tym sensie nasze forum upadałoby kilka razy w miesiącu...

LukeJL

@Silv to niedługo zamienimy się w Kafeterię albo Filmweb. Tam interakcja zwykle polega na wyzwiskach.

Haskell

@nohtyp: spoko nie mam urazy za wyzwiska. Pisząc ten wpis wiedziałem, że to jest broń obosieczna i będę oceniany.

Silv

@LukeJL: coś w tym jest (aczkolwiek nie wiem z autopsji, jak jest na wspomnianych stronach). Toteż ja tego nie pochwalam. Jestem przeciwny. Ale co z tego?

thock

Skoro już o tym mowa, to muszę przyznać, że nawet chciałem się wypowiedzieć w temacie postu, ale widząc styl dyskusji w komentarzach poczułem zażenowanie i dałem sobie spokój. Tej maniery nie znoszę u polskich programistów (ale nie tylko polskich), i wg mnie jest ona główną przyczyną, że mimo posiadanej wiedzy, ich produkty jednak ostatecznie nie powalają jakością.

Afish

@Haskell: > Powiedziałem, że rekordy w SQL Server są posortowane wg klucza gdy mamy indeks klastrowany, ale oczywiście miałem na myśli również to, że w pozostałych przypadkach nie są.

No to odpowiedziałeś źle i wpadłeś w pułapkę, nie ma się co przejmować, bo wiele osób zadaje takie pytania, żeby pokazać swoją wyższość nad kandydatem.

Cr0w

@Haskell czemu chcesz wrocic do python'a?

vpiotr

Przed pójściem na rozmowę polecam się wyluzować. Np. oglądając to: https://binged.it/30w3aiF

amd

@Haskell: a miałeś w CV w umiejętnościach Linux, jeśli tak to zupełnie nie rozumiem oburzenia

WeiXiao

No cóż, trzeba otrzeć łezki, wrócić do manuala i zaorać inną rekrutację ;)

Haskell

@amd: nie, nie napisałem w CV, że znam Linuxa. Mają święte prawo pytać o co żywnie im się podoba, ale ja przed rozmową dostałem zakres tematów czego będzie dotyczyć rozmowa i nie było tam Linuxa.

Haskell

@WeiXiao: to nie płacz, bardziej chęć podzielenia się wrażeniami. Biorąc pod uwagę moje przygotowanie + stres to było do przewidzenia, że rozmowa nie pójdzie jak z płatka :)

vpiotr

Swoja droga pytania techniczne z Linuksa maja chyba tylko sens pogladowy, chyba malo jest ludzi ktorzy maja wykutego man-a na blache.

amd

Nie no jeśli w CV nie było Linuxa, to na mój gust mogą cie zapytać ale nie ma nic złego w tym że powiesz ze jesteś nie przygotowany z tego i tyle.

czysteskarpety

Uwielbiam jak w takich wątkach wychodzi typowe polactwo, aby dosrać autorowi :D

tdudzik

Tak swoją drogą nie rozumiem jaki cel ma przychodzenie na rozmowę z listą pytań, na które odpowiedź można znaleźć w ciągu sekundy w Google (typu jakiej komendy użyjesz do zrobienia X). Rozmowa ma na celu znalezienie odpowiedniego kandydata do pracy, a nie wydaje mi się, żeby brak wiedzy jakiej komendy/metody/klasy użyć do zrobienia czegoś oznaczał, że ktoś sie nie nadaje. Dlatego ja wolę rozmowy w stylu Google i reszta, bo pomimo że nie są idealne to dają większe szanse na znalezienie odpowiedniej osoby niż przepytywanie kogoś z języka czy frameworka.

Haskell

@tdudzik - ta rozmowa na której byłem to bardziej przypominała egzamin ustny na studiach, ponieważ było trochę z algorytmiki, złożoność obliczeniowa, struktury danych. Pytania z Linuxa na poziomie przedmiotu systemy operacyjne. Do tego były dwa zadania algorytmiczne oraz kilka pytań z Pythona przypominających zadania z OCPJP czyli czy ten kod się wykona i co zwróci. Rekrutacja typowo nastawiona na pozyskiwanie studentów i absolwentów studiów Informatycznych.

Spine

Po 10 latach w IT po co jeszcze pracujesz? Przecież możesz żyć z odsetek :D

getcontext

rekruterzy i head huntersy, to jedna z najgorszych rzeczy, jaka mogła przytrafić się IT..

Spine

Jeszcze testerzy :D

getcontext

testerzy, którzy przeistaczają się w dev'a - nie może być gorzej