Ja podchodzę do kandydatów bardziej na luzie. Na pytanie o hobby zawsze odpowiadają "gry komputerowe". Wtedy pytam "jakie?" i obserwuję jak wychodzi im pot na czoło. Boją się przyznać że grają w jakieś chińskie bajki typu Girls und Panzer: Senshadō, kiwamemasu! Na ratunek przychodzi im moja sprytnie zastawiona pułapka. Za mną wisi plakat Half-Life, taka podprogowa sugestia, lep na słabe psychiki. Oni go zauważają i przychodzi olśnienie zmieszane z ulgą. Odpowiadają z satysfakcją "gram w half-life'a" chcąc zyskać punkty za wspólne zainteresowania. Wtedy ja z kamienna twarzą i oczyma zmrużonymi niczym Clint Eastwood w "Za garść dolarów" pytam: "jak najlepiej ominąć headcraba czającego się w rurze na mapie z urwiskiem?" Cisza. Oczy spuszczone. Wie, że się nie dostał. Prawdziwy gracz by wiedział. Zamykam notatnik i wychodzę w ciszy. Dzisiejsi programiści 40k, ech.
Komentarze (34)
@GrindFaterAnona - fajne byłyby to heheszki gdyby nie była to prawdziwa strategia zatrudniania przeze mnie ludzi
Wiadomo nie tak ekstremalna żeby pytać o szczegóły gry w którą się grało ponad 20 lat temu ale cenię sobie jak ktoś przyznaje się, że gra w gry (bo kto nie gra?) i potrafi rozwinąć temat - nie zawiodłem się jeszcze (za bardzo) na ludziach potrafiący rozmawiać o swoich pasjach z pasją
@lubieplackijohn - generalnie większość się wstydzi przyznać - tylko jedna osoba przyznała się do grania w gry mobilne - reszta dzieli się na dwa obozy: granie w nowoczesne gry (tu są podobozy: AAA vs Indie, PC vs Konsole) oraz granie w retro.
Ja przyjmuję wszytko bez spiny bo granie w gry to jest obecnie zwykła rozrywka i nie ma się co wstydzić (ale wygląda, że dalej ganie w gry nacechowane jest negatywnie).
@Ragnarokk - ja zatrudniam inżynierów szeroko pojętego Reliability więc oni muszą mieć umiejętności komunikacji na bardzo wysokim poziomie, gdyż są też odpowiedzialni za nietechniczne rzeczy jak nawiązywanie i utrzymywanie kontaktów z innymi zespołami - do tego pasja to podstawa i czasami można ją wydobyć na rozmowie jedynie przez zejście na luźniejsze tematy. Kolejna rzecz to ciekawi ludzie tworzą ciekawy i zazwyczaj zgrany zespół i są w stanie się dogadać
Już tu gdzieś pisałem, że czasem i mi zdarzy się popełnić błąd przy zatrudnianiu bo niektórzy ludzie potrafią nieźle ściemniać i pokazywać najlepszą wersję siebie (kiedy naprawdę tacy są tylko na rozmowach kwalifikacyjnych).
@pluszowy_zergling - ciężka i ciężko znaleźć ogarniętego SRE - ja miałem szczęście bo zacząłem wcześnie zanim termin SRE wszedł do powszechnej świadomości dzięki SRE Book od Google z 2016 roku. Reliability jara mnie niezmiennie od lat, ale jak ktoś się interesuje tematem to wie, że to jest przerzucanie ton gówna doprowadzone do poziomu sztuki
@koszotorobur robiłem szkolenia, bo sam też troszkę devopszę w projekcie, najgorzej te metryki ustalać, jak mamy produkty używane dość regularnie to jescze ujdzie, ale te proof of concept rzeczy, do których zachęcamy klientów to źródło problemów, wyśle taki 1 błędny request na miesiąc i od razu "budżet błędów hurr durr"
@pluszowy_zergling - ludzie wzięli pierwszą książkę zbyt dosłownie pomimo tego, że Google samo w niej mówiło by tego nie robić i dostosować implementację pod aplikacje, które zespół SRE będzie wspierać oraz firmę. Niby w drugiej książce starali się to lepiej wyjaśnić ale co zostało "zrozumiane" i poszło w świat po pierwszej (na przykład, że ten nieszczęsny budżet błędów jest w każdej implementacji Reliability potrzebny) to będziemy odkręcać przez dekady
Śmieszne jest to, że więcej czasu spędziłem w swojej karierze na wyjaśnianiu co robi SRE i dlaczego rzeczy są zaimplementowane tak a nie inaczej oraz dlaczego coś poszło nie tak (post mortems, RCAs) lub dlaczego komuś się wydawało, że coś nie działa (a tak naprawdę działało) niż na faktycznym implementowaniu monitoringu i alertów.
Temat rzeka ale jak zawsze powtarzam: nie ma jednej poprawnej implementacji SRE.
Zaloguj się aby komentować


