[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 względem

[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

[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 i testy?
- mid: scheduler, obsłuż przerwanie z adc, wypluj na serial zmierzoną temperature?
-

[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 #!$%@? 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:

#!$%@?ą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

[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 do

[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 ;)