🚀 go-pugleaf

On 09/05/2020 09:38, Piotrek wrote:
> Czego się wymaga od takich ludzi na starcie?

Wiedzy ogólnej, czasami wybitnej. mikrokod to kolejny rodzaj assembler 
wiec jesli mistrz pisał coś na kilku cpu to sobie poradzi o ile tylko 
rozumie abstrakcyjnie asm. A BIOS to taki normalny program, o ile nie 
piszesz bezpośrednio sterowników urządzeń niczym się to nie rózni od 
pisania normalnego kodu.

Trudno nazwać to jakimiś hiper-niszami, ot, robota dla troche 
zdolniejszych, może z zacięciek hackerskim. Na pęczki takich.

> W klasycznych przypadkach przebiega to standardowo:

Jest cała masa opracowań pokazujących, że to "standardowo" jest do bani.

> Jak jednak ma się sprawa z bardzo niszowymi stanowiskami?
> Chodzi mi o przypadek, gdy umiejętności potrzebne do pracy
> są niemożliwe do zdobycia poza firmą, do której kandydat
> aplikuje. Czego wtedy wymaga się od takich ludzi?

Oczywiście tego, żeby umieli się nauczyć.

> Co muszą mieć w CV, żeby w ogóle zostali wzięci pod uwagę?

Coś, co przekona pracodawcę, że umie się uczyć. No i powiedzmy, że jeśli stanowisko jednak jest jakoś związane z programowaniem, to fajnie, jakby z CV wynikało, że kandydat umie programować.

Prawdziwy problem jest gdzie indziej. Skoro już z góry zakładasz, że na jakimś stanowisku wiedzę można zdobyć tylko na tym stanowisku, to jednocześnie powinieneś zauważyć, że taka wiedza jest "nietransferowalna" poza to stanowisko. Tych zjawisk nie da się rozdzielić, one są z natury zawsze razem.
Dla pracodawcy oznacza to, że trudno znaleźć kandydata, który od razu to umie.
Ale dla kandydata oznacza to, że po dłuższym czasie pracy na tym stanowisku, nie będzie mógł znaleźć pracy gdzie indziej. Bo czym się pochwali "na mieście"? Że umie robić coś, czego nikt nie potrzebuje robić? Kandydaci omijają nisze właśnie przez to, że nie da się zaplanować kariery na dwa ruchy do przodu.

Więc wracając na punkt widzenia rekrutującego, trzeba znaleźć kandydata nie tylko takiego, który umie się nauczyć, ale też takiego, który potencjalnie będzie chciał grać na długim dystansie. Czyli dokładamy wymaganie predyspozycji psychicznych - to nie może być cwaniak skaczący z kwiatka na kwiatek tylko dlatego, że mu jakiś headhunter zaproponował darmowe kanapki w biurze albo dodatkowy karnet na siłkę (wiem, zamknięte teraz). Również z tego powodu, że inwestycja w jego niszową wiedzę, trwająca potencjalnie ileś miesięcy, musi się kiedyś zwrócić.
Czyli szukasz kandydata stabilnego psychicznie. Najlepiej takiego, który etap "wyszumienia" ma już za sobą. Albo tego etapu nie potrzebuje, bo takie jednostki też bywają.

> Z marszu
> przychodzą mi do głowy dwa tego typu stanowiska:
> 
> - programista mikrokodu procesora
[...]
> - programista piszący BIOS
[...]

Dorzuć branże regulowane, typu lotnictwo, pociągi, jakaś medycyna albo samochody, itd. I oczywiście ekosystemy o charakterze antykwaryjnym typu system bankowy w COBOLu albo PL/1. No i stanowiska typu "ściśle tajne".

-- 
Maciej Sobczak * http://www.inspirel.com

Piotrek <pilarp@poczta.onet.pl> wrote:

> Chodzi mi o przypadek, gdy umiejętności potrzebne do pracy
> są niemożliwe do zdobycia poza firmą, do której kandydat
> aplikuje. Czego wtedy wymaga się od takich ludzi?

Mam podobny przypadek -- nie to, że umiejętności nie są do zdobycia, ale 
to pewna nisza. Jak szukaliśmy ludzi to wymagałem po prostu myślenia i 
wiedzy ogólnej -- wolę kogoś myślącego spoza branży, niż niemyślącego z 
branży. Myślący zawsze może tę specjalistyczną wiedzę zdobyć.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

W dniu sobota, 9 maja 2020 09:38:08 UTC+2 użytkownik Piotrek napisał:
> W klasycznych przypadkach przebiega to standardowo:
> analiza CV, w razie akceptacji zaproszenie na
> rozmowę lub kilka rozmów, jakieś testy znajomości
> języka/technologii i/lub analiza poprzednich "dokonań".
> Jak jednak ma się sprawa z bardzo niszowymi stanowiskami?
> Chodzi mi o przypadek, gdy umiejętności potrzebne do pracy
> są niemożliwe do zdobycia poza firmą, do której kandydat
> aplikuje. Czego wtedy wymaga się od takich ludzi?
> Co muszą mieć w CV, żeby w ogóle zostali wzięci pod uwagę?
> Czy w takim przypadku zakłada się po prostu, że znają oni
> jakiś trzon, kanon wiedzy programistycznej i mają być
> ogólnie kumaci (zaliczyć jakieś testy predyspozycji),
> a potem ich się "ukształtuje" już w pracy? Z marszu
> przychodzą mi do głowy dwa tego typu stanowiska:
> 
> - programista mikrokodu procesora (brak ogólnodostępnych
> źródeł wiedzy na ten temat, zwykły śmiertelnik nie zejdzie
> poniżej poziomu asemblera, wewnętrzna specyfikacja CPU to
> tajemnica firmowa)
> 
> - programista piszący BIOS (to już może ciut mniej niszowe, bo
> istnieją opensource'owe BIOSy, ale jednak niszowe skoro komercyjne
> BIOSy pisze raptem kilka-kilkanaście firm na całym świecie)
> 
> Czego się wymaga od takich ludzi na starcie?

wogole jesli robota jest uznawana za trudna ja bym moze sasugerowal zatrudnienie dwu ludzi, jesli beda miec jaka taka synergie i beda pracowac nad tym samym to moga miec o wiele latwiej niz programowac samemu

ale to zalezy tez od wielu rzeczy, moim zdaniem jednak ta synergia w pracy jest istotna, czesto inni ludzie moga przeszkadzac komus nowo zatrudnionemu a czasem moga pomagac ito moze stanowic znaczna roznice

wogole bym przstrzegal przed pochopnym ocenianiem ludzi bo czasem mozna ocenic kogos przez pryzmat tej nisprzyjajacej synargii (wogole sam jesli chodzi o firmy jestem zwolenikiem programowania w parach przeynajmniej przez jakies pierwsze miesiace czy rok..ale nie jestem tez specjalista w tym temacie)

W dniu wtorek, 12 maja 2020 12:03:23 UTC+2 użytkownik fir napisał:
> W dniu sobota, 9 maja 2020 09:38:08 UTC+2 użytkownik Piotrek napisał:
> > W klasycznych przypadkach przebiega to standardowo:
> > analiza CV, w razie akceptacji zaproszenie na
> > rozmowę lub kilka rozmów, jakieś testy znajomości
> > języka/technologii i/lub analiza poprzednich "dokonań".
> > Jak jednak ma się sprawa z bardzo niszowymi stanowiskami?
> > Chodzi mi o przypadek, gdy umiejętności potrzebne do pracy
> > są niemożliwe do zdobycia poza firmą, do której kandydat
> > aplikuje. Czego wtedy wymaga się od takich ludzi?
> > Co muszą mieć w CV, żeby w ogóle zostali wzięci pod uwagę?
> > Czy w takim przypadku zakłada się po prostu, że znają oni
> > jakiś trzon, kanon wiedzy programistycznej i mają być
> > ogólnie kumaci (zaliczyć jakieś testy predyspozycji),
> > a potem ich się "ukształtuje" już w pracy? Z marszu
> > przychodzą mi do głowy dwa tego typu stanowiska:
> > 
> > - programista mikrokodu procesora (brak ogólnodostępnych
> > źródeł wiedzy na ten temat, zwykły śmiertelnik nie zejdzie
> > poniżej poziomu asemblera, wewnętrzna specyfikacja CPU to
> > tajemnica firmowa)
> > 
> > - programista piszący BIOS (to już może ciut mniej niszowe, bo
> > istnieją opensource'owe BIOSy, ale jednak niszowe skoro komercyjne
> > BIOSy pisze raptem kilka-kilkanaście firm na całym świecie)
> > 
> > Czego się wymaga od takich ludzi na starcie?
> 
> wogole jesli robota jest uznawana za trudna ja bym moze sasugerowal zatrudnienie dwu ludzi, jesli beda miec jaka taka synergie i beda pracowac nad tym samym to moga miec o wiele latwiej niz programowac samemu
> 
> ale to zalezy tez od wielu rzeczy, moim zdaniem jednak ta synergia w pracy jest istotna, czesto inni ludzie moga przeszkadzac komus nowo zatrudnionemu a czasem moga pomagac ito moze stanowic znaczna roznice
> 
> wogole bym przstrzegal przed pochopnym ocenianiem ludzi bo czasem mozna ocenic kogos przez pryzmat tej nisprzyjajacej synargii (wogole sam jesli chodzi o firmy jestem zwolenikiem programowania w parach przeynajmniej przez jakies pierwsze miesiace czy rok..ale nie jestem tez specjalista w tym temacie)

wogole jak wspominam swoje doswiadczenie w firmach (obecnie nie pracje w firmie ze wzgledu na przewlekle i dosyc powazne problemy zdrowotne) to o ile pamietam wygladao to tak ze w pierwszej bylo to programowanie w parach (nie koniecznie nad tym samym kodem j anp kodowalem w c++ a kmple w javie ale wspolpaca byla scisla) i dobrze to wspominam, w drugiej nie bylo tej konsultacji wcale (i wspominam to zle) w trzeciej znowu byla czesciowa synergia (i znowu lepiej to wspominam) pozniej znowu nie a pozniej tak srednio

ta scisla synergai w kodowaniu z kims z kim sie mozesz dobrze dogadac jest wazna,
bo to nie tyle nawet chodzi o to ze ktos wprowadzi cie w techniczne problemy ale
o to ze mozna jakby lepiej sie poczuc, a programowanie w firmach ogolenie jes stresujace bo niesttsy firmy maja podejscie przeciwne zdrowemu i naturalnemu

(dla mnie w kodowani natruralne jest np kodowanie zrywami, np dwa tygodnie ostrej napierdalanki po cym  tygodnie odpoczywania by sie zregenerowac...stala lupanina po 8 h na dzien wypala i nie jest korzystna

fir <profesor.fir@gmail.com> wrote:

> wogole jesli robota jest uznawana za trudna ja bym moze sasugerowal 
> zatrudnienie dwu ludzi, jesli beda miec jaka taka synergie i beda 
> pracowac nad tym samym to moga miec o wiele latwiej niz programowac 
> samemu

Raczej zatrudniałbym specjalistów. Jeden niech umie pisać a drugi niech 
umie czytać. Myśleć nie musi żaden, to nie sprzyja pracy w korporacji.

https://www.flickr.com/photos/versesane/3086128569

A poważnie -- myślę, że pull requesty i przeglądy kodu niech dobrze się 
sprawdzają.

> ta scisla synergai w kodowaniu z kims z kim sie mozesz dobrze dogadac 
> jest wazna, bo to nie tyle nawet chodzi o to ze ktos wprowadzi cie w 
> techniczne problemy ale o to ze mozna jakby lepiej sie poczuc,

Tak to jest łatwo i przyjemnie. Gorzej, jeśli nie możesz się dogadać, a 
musisz współpracować. Jest taka książka (nie czytałem):

https://www.empik.com/otoczeni-przez-idiotow-erikson-thomas,p1145327649,ksiazka-p

> programowanie w firmach ogolenie jes stresujace bo niesttsy firmy maja 
> podejscie przeciwne zdrowemu i naturalnemu

I z tym niestety się zgodzę. Natomiast musimy pamiętać, że przychodzimy 
tam zarabiać pieniądze. Od hobby mamy wolny czas. Fajnie, jeśli praca 
jakoś zazębia się z tym, co (i w jaki sposób) lubimy robić, ale nie będzie 
się zazębiała zawsze i w każdym obszarze.

Oczywiście nie można też popadać w paranoję i w gonitwie za pieniądzem 
doprowadzić się do skraju wytrzymałości. Musi być równowaga.

Btw, ja jestem typowym nocnym markiem. Taki mam chronotyp, od zawsze. 
Idealna dla mnie pora to noc. Nie znajdę raczej firmy, w której będę mógł 
pracować na etat, współpracując na żywo z innymi, i robić to w nocy. Nawet 
jeśli wszyscy inni też mają taki chronotyp, to standardem jest praca w 
dzień. Chore, ale tak jest. Może kiedyś się to zmieni.

https://www.youtube.com/watch?v=eANk3-vRpCM

(da się oglądać, jeśli odfiltruje się momenty, w których pani próbowała 
być na siłę zabawna)

> (dla mnie w kodowani natruralne jest np kodowanie zrywami, np dwa 
> tygodnie ostrej napierdalanki po cym tygodnie odpoczywania by sie 
> zregenerowac...stala lupanina po 8 h na dzien wypala i nie jest 
> korzystna

Mi z kolei praca po X godzin dziennie daje pewien rytm, ale tak jak 
mówisz, każdy ma inny "styl". Chyba tylko praca na zlecenie, gdzie 
dostajesz jakiś projekt do zrobienia i określony czas na jego wykonanie, 
mogłaby się w to wpisać. Wtedy kodujesz, kiedy chcesz, byle tylko zmieścić 
się w czasie.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

W dniu wtorek, 12 maja 2020 16:49:52 UTC+2 użytkownik Queequeg napisał:
> fir <profesor.fir@gmail.com> wrote:
> 
> > wogole jesli robota jest uznawana za trudna ja bym moze sasugerowal 
> > zatrudnienie dwu ludzi, jesli beda miec jaka taka synergie i beda 
> > pracowac nad tym samym to moga miec o wiele latwiej niz programowac 
> > samemu
> 
> Raczej zatrudniałbym specjalistów. Jeden niech umie pisać a drugi niech 
> umie czytać. Myśleć nie musi żaden, to nie sprzyja pracy w korporacji.
> 
> https://www.flickr.com/photos/versesane/3086128569
> 
> A poważnie -- myślę, że pull requesty i przeglądy kodu niech dobrze się 
> sprawdzają.
> 
> > ta scisla synergai w kodowaniu z kims z kim sie mozesz dobrze dogadac 
> > jest wazna, bo to nie tyle nawet chodzi o to ze ktos wprowadzi cie w 
> > techniczne problemy ale o to ze mozna jakby lepiej sie poczuc,
> 
> Tak to jest łatwo i przyjemnie. Gorzej, jeśli nie możesz się dogadać, a 
> musisz współpracować. Jest taka książka (nie czytałem):
> 
> https://www.empik.com/otoczeni-przez-idiotow-erikson-thomas,p1145327649,ksiazka-p
> 
> > programowanie w firmach ogolenie jes stresujace bo niesttsy firmy maja 
> > podejscie przeciwne zdrowemu i naturalnemu
> 
> I z tym niestety się zgodzę. Natomiast musimy pamiętać, że przychodzimy 
> tam zarabiać pieniądze. Od hobby mamy wolny czas. Fajnie, jeśli praca 
> jakoś zazębia się z tym, co (i w jaki sposób) lubimy robić, ale nie będzie 
> się zazębiała zawsze i w każdym obszarze.
> 
> Oczywiście nie można też popadać w paranoję i w gonitwie za pieniądzem 
> doprowadzić się do skraju wytrzymałości. Musi być równowaga.
> 
> Btw, ja jestem typowym nocnym markiem. Taki mam chronotyp, od zawsze. 
> Idealna dla mnie pora to noc. Nie znajdę raczej firmy, w której będę mógł 
> pracować na etat, współpracując na żywo z innymi, i robić to w nocy. Nawet 
> jeśli wszyscy inni też mają taki chronotyp, to standardem jest praca w 
> dzień. Chore, ale tak jest. Może kiedyś się to zmieni.
> 
> https://www.youtube.com/watch?v=eANk3-vRpCM
> 
> (da się oglądać, jeśli odfiltruje się momenty, w których pani próbowała 
> być na siłę zabawna)
> 
> > (dla mnie w kodowani natruralne jest np kodowanie zrywami, np dwa 
> > tygodnie ostrej napierdalanki po cym tygodnie odpoczywania by sie 
> > zregenerowac...stala lupanina po 8 h na dzien wypala i nie jest 
> > korzystna
> 
> Mi z kolei praca po X godzin dziennie daje pewien rytm, ale tak jak 
> mówisz, każdy ma inny "styl". Chyba tylko praca na zlecenie, gdzie 
> dostajesz jakiś projekt do zrobienia i określony czas na jego wykonanie, 
> mogłaby się w to wpisać. Wtedy kodujesz, kiedy chcesz, byle tylko zmieścić 
> się w czasie.
> 
mozna sie zmusic do lupaniny dzien w dzien po 8 h bez odpoczynkua le poprostu efekty takiej lupaniny sa gorsze niz praca 'zgodna z naturą' (przez pierwszy czy 2gi miesiac w takiej firmie mysle mozna byc jeszcze dosyc wydajnym (o ile to z kolei si enie pokrywa z nieznajomoscia kodu czy api/jezyka do wroboty nad czyms ie przyszlo) ale pozniej wydajnosc spada ze zmeczenia

ale moja wydajnosc i tak jak mierzylem jest dosyc spora (w tych okresach o ktorych mowilem gdy jestem jako tako wypoczety, jest to prawie zawsze 300 linijek na dzien, 9k linijek na miesiac.. moim zdaniem jest to duzo)

fir <profesor.fir@gmail.com> wrote:

> mozna sie zmusic do lupaniny dzien w dzien po 8 h bez odpoczynkua le 
> poprostu efekty takiej lupaniny sa gorsze niz praca 'zgodna z naturą' 
> (przez pierwszy czy 2gi miesiac w takiej firmie mysle mozna byc jeszcze 
> dosyc wydajnym (o ile to z kolei si enie pokrywa z nieznajomoscia kodu 
> czy api/jezyka do wroboty nad czyms ie przyszlo) ale pozniej wydajnosc 
> spada ze zmeczenia

W moim przypadku praca zgodna z naturą to byłaby praca w nocy. Niestety 
firmy są nastawione wyłącznie pod ranne ptaszki.

-- 
Chodnikiem biegnie przerażona kobieta, a za nią groźnie sapiąc wielki
mężczyzna. W końcu ona nie ma już sił. Staje, odwraca się do niego
i krzyczy:
- Poddaję się, niech mnie pan gwałci, tylko nie zabija !
- Gwałć się pani sama, ja się śpieszę na pociąg !