[Oo-oO]

Mirki #programowanie #programista15k #pytanie jak robicie rekrutacje (lub gdybyście chcieli być rekrutowani, to jak) w #embedded?
Powiedzmy żeby było trudniej - język jest nietypowy, powiedzmy jakiś Zig, Go, Rust, Haskell czy cokolwiek co nie jest C/C++.

- Test wyboru? Niby można ale nie ma pewności czy ktoś rozwiązuje go sam.
- Rozmowa techniczna - spoko, ale premiuje osoby wygadane, introwertycy mają handcap.
- Zadanko do zrobienia "w domu na ~5 minut~ / godzinka dwie" ( ͡° ͜ʖ ͡°) - niespecjalnie.

Oczywiście wiele zależy też od tego jaką chcecie mieć kompozycję w zespole, czy ekstrawertyków czy introwertyków, czy miks

W sumie zastanawiam się nad zebraniem plusów i minusów każdego rozwiązania:

1. Test: +zdalny +szybki -niejednoznaczny -potencjalni oszuści -pytania niełatwo dobrać (zwłaszcza skalujące się z poziomem)
2. Interview: +łatwiej dynamicznie skalować trudność pytań -czas -potencjalny stres dla kandydata -promowanie wygadanych ludzi
3. Zadanko: -trudno opracować zadanie dla embedded do zrobienia w krótkim czasie

#pracait

[pan_bogus]

@Oo-oO: jeśli ktoś ma problem z rozmową techniczną to niekoniecznie jest introwertykiem tylko po prostu ma problem z komunikacją. Komunikacja jest konieczna w pracy programisty więc tym bardziej rozmowa jest zalecana

[kickli]

@Oo-oO: Teraz jak tak pomyślałem to chyba nawet nie pytam o jezyk - pomimo, że zawsze uczestniczę w rozmowach na java deva - tylko znajomość konkretnych konceptów. Jakieś transakcje, kolekcje itp w zależności od poziomu. No i zadanie z algorytmiki którego nawet nie musi implementować tylko aby opowiedział jak by to zrobił.
Da się wyczuć czy ktoś jest introwertykiem czy po prostu się nie zna. Ja akurat sprawdzam tylko pod

[relationbrewingarea]

- Rozmowa techniczna - spoko, ale premiuje osoby wygadane, introwertycy mają handcap.

@Oo-oO: to też jest "handicap" w późniejszej pracy.

[Oo-oO]

@pan_bogus: nie bierzmy od razu tylko skrajności pod uwagę. W przypadku kandydata 1. uśmiechniętego, odpowiadającego dobrze na pytania i kandydata poważnego - również dobrze odpowiadającego na pytania, dość często podświadomie można się skłaniać ku pierwszemu.

@kickli zgadza się, w wysokopoziomowym programowaniu mam wrażenie że jest łatwiej - można klepać algorytmy jeśli ktoś lubi - choć niezupełnie ma to przełożenie na faktyczną późniejszą pracę, można pytać o kolekcje - co imho powinno być podstawą, dobrym pytaniem dla juniora, ale pytaniem które powinno przynajmniej zdziwić seniora z wiedzą odpowiadającą stażowi.

Nie zrozumieliśmy się dlaczego podkreśliłem język - ale jeśli nie znasz specyfiki embedded to jasna sprawa czemu się nie zrozumieliśmy - pytania na interview o sam język, składnie czy bóg wie co, to jest jedna rzecz, również ok, ujdzie na stanowisko juniora. Miałem natomiast na myśli to, że w embedded stety albo niestety prym wiodą C/C++, spokojnie większość rynku, dlatego jest kilka koncepcji jeśli chodzi o rekrutacje w tych językach, mnie bardziej ciekawi podejście w

[zarowka12]

Komunikacja jest konieczna w pracy programisty więc tym bardziej rozmowa jest zalecana

@pan_bogus: komunikacja przez jirę albo gerrita

[Oo-oO]

Ja rozumiem że niektórzy mogą preferować właśnie też dodawanie dodatkowych punktów za, brak mi słowa, pozytywizm? ;)
Czy to dobre podejście czy złe, to myślę kwestia indywidualna i całego "culture fit", jak dana osoba pasuje do zespołu.

Natomiast to podejście zbliża się też nieco myśleniem o innych preferencjach, przykładowo ktoś może być skłonny premiować kobiety (lub odwrotnie), w przypadku zbliżonych kompetencji technicznych - jeśli zespół składa się głównie z facetów. O ile

[pan_bogus]

komunikacja przez jirę albo gerrita

@zarowka12: to chyba tylko wtedy jak pracujesz w jakimś outsourcingu albo software housie i masz project managera która ogarnia resztę roboty

[card_man]

@Oo-oO: homework wydaje sie byc najlepszym zadaniem i potem rozmowa na temat tego jak to zostało zrobione czy kandydat to napisał i czy wie o co chodzi w ogóle.

[Oo-oO]

Zapomniałem o 4 podejściu:
- pair programming na rzeczywistym kodzie w firmie - sprawdza się do pewnego stopnia, ale imho tylko dla seniorów, i to takich którzy już ten język programowania znają.

@card_man: co rozumiesz przez homework w przypadku embedded? Dla różnych stanowisk junior/mid/senior, w jakim czasie?

- junior: zamrugaj diodami, napisz cośtam, zrób kilka commitów

[masz_fajne_donice]

@Oo-oO: Życie to nie test. Warto zarówno sprawdzić wiedzę - np poprosić o zaprogramowanie czegoś patrząc tej osobie na ręce(nikt tego nie lubi xd) ale także pogadać zwyczajnie o tym co robiła jakie miała projekty jak się w nich współpracowała itd. Jak ktoś nie umie opowiadać o swojej pracy to c---a się nadaje.

[WyjmijKija]

@Oo-oO: rozmowa techniczna. Introwertycy mają trudnej, ale to ich problem nie mój

[Boska_Klaudia]

@pan_bogus: komunikacja przez jirę albo gerrita

@zarowka12: tylko nie gerrit

[Oo-oO]

Kurde liczyłem że card_man coś odpowie, serio nie umiem sobie wyobrazić rozsądnego czasowo i przekrojowego zadania. Tzn umiem sobie wyobrazić cząstkowe, sprawdzające wiedzę z różnych zagadnień projektu. Może należałoby wybrać jakieś 2-3 najistotniejsze i tylko je sprawdzać :hmm:

Abstrahując, gerrit był swego czasu dość przyjemny ;) teraz w dobie gh/gl (bb chyba już raczej padł) i przeforsowywania ich rozwiązań czeka nas pewnie w dłuższej perspektywie czasu jakiś monopol

[morsisko]

@Oo-oO: Na wszystkich rozmowach z embedded, w których uczestniczyłem, zawsze była tylko i wyłącznie rozmowa techniczna. Dodatkowo jak masz pytania z pogranicza elektroniki i programowania (pytanie o jakieś własności SPI, I2C, Bluetooth, PWMy, analizę sygnałów i tak dalej) to ciężko mi sobie wyobrazić, żeby sprawdzić wiedzę z takiego obszaru za pomocą zadania domowego

[Oo-oO]

@morsisko: a widzisz, a ja miałem już w życiu i test (swoją drogą nie najgorszy), pair programming, zadanie domowe - np jedna firma dała mi swój prototyp i chyba miesiąc czasu na zrobienie małego proof of concept, już dobrze nie pamiętam; ale mam wrażenie że było to płatne. Inna chciała jeden prosty programik do napisania, a później mieliśmy dyskusję na temat co napisałem i czy wyłapałem wszystkie warunki brzegowe itd.

Powiem szczerze, czasem nawet w rozmowie trudno sprawdzić te rzeczy; musisz polegać na swojej wiedzy i przede wszystkim na umiejętności czytania ludzi. Nie każda odpowiedź której się spodziewasz musi być poprawną, lub może inaczej - nie każda której się nie spodziewasz/oczekujesz musi być niepoprawną; zwłaszcza w pytaniach otwartych typu "co może pójść nie tak" czy "dlaczego to rozwiązanie może być problematyczne".

Takich typowych o własności protokołów staram się unikać, bo przecież to są rzeczy które łatwo można sprawdzić w necie, a po co ktoś ma pamiętać który protokół jak robi arbitraż lub czy go w ogóle nie ma. O ile może to są rzeczy które się po jakimś czasie zapamiętuje, to czy faktycznie chcemy sobie zaśmiecać pamięć takimi

[card_man]

@Oo-oO: generalnie to jest embedded więc trochę szeroka działka, pytanie co chcesz sprawdzać. Ja kiedyś miałem do napisania prosty serwer http który miał obsługiwać jakieś podstawowe requesty, niby do wykonania w kilka godzin, ale mi to chyba zajęło trochę dłużej, z drugiej strony to dobrze się bawiłem. Ciężko wymyślić zadanie który nie zajmie zbyt dużo czasu, z drugiej strony pokazuje też determinację i chęć do zdobycia pracy.

[Oo-oO]

@card_man: ha, to że trudno wymyślić sensowne zadanie to już wiem ;) zgadzam się do tej dwoistości - na wykopie panuje przekonanie że za każde zadanie firma powinna płacić ;) cóż, ja mam nieco inne zdanie, choć trudno znaleźć złoty środek, przykładowo zadanie które obiektywnie zajmuje 8h zdecydowanie by mnie zdziwiło.

Co do zadań, jakie możnaby zrobić to pisałem w poście wyżej. Mógłby być prosty klient mqtt, jakiś mock calla

[AnonimoweLwiatko]

część kandydatów będzie miała już swój sprzęt, niektórzy nawet rozbudowany warsztat, oscyloskopy, analizatory logiczne itd

@Oo-oO: Co? xd

[AnonimoweLwiatko]

@Oo-oO: Jeśli chodzi o zadanie to do 2h, w formie calla i luźnego programowania + ewentualnego tłumaczenia sposobu myślenia/rozwiązywania problemu. W ciszy, dając się kandydatowi wykazać. Z góry ustalić co ma pokazywać na ekranie, z czego może korzystać etc. Więcej niż 1,5-2h za friko programować nikt poza juniorem nie powinien, zwłaszcza rozwiązywać jakieś skomplikowane cyrki. Proste zadania sprawdzające umiejętność tworzenia rozwiązania problemu, optymalizacji, składni itp.

[Oo-oO]

@AnonimoweLwiatko: mówisz o sprzęcie? Są ludzie którym ta robota sprawia frajdę i kupują sobie dla siebie, inni pracują na b2b więc również inwestują w sprzęt, skąd to zaskoczenie? :)
Zadanie, na 2h mówisz. No ok, a jakieś konkrety? Tak dość ogólnikowo napisałeś, zadanie sprawdzające składnię... rozumiem że chodzi ci o składnię języka. Wyobraź sobie że rekrutujesz do swojego zespołu ;)