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?

do góry

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.

do góry

> 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

do góry

Piotrek <p...@p...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

do góry

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)

do góry

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

do góry

fir <p...@g...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

do góry

W dniu wtorek, 12 maja 2020 16:49:52 UTC+2 użytkownik Queequeg napisał:
> fir <p...@g...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)

do góry

fir <p...@g...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 !

do góry