Tíz jó kérdés állásinterjúra, junior fejlesztő kiválasztáshoz?
Alapvetően adatfeldolgozás területen készítünk egyszerű programokat. Alapvetően R-et használunk, de sokszor az adatelőkészítéshez python, C, perl szokott előjönni (perl azért mert az egyik idősebb kolléga csak abban hajlandó R-en kívül dolgozni, ne kérdezzétek miért, ez így marad. Őt nem már lehet meggyőzni, de már csak 5,5 hónap utána nyugdíjba megy).
Jövő héten kezdünk megint meghallgatni bő egy tucat innen-onnan jött junior fejlesztőt. És kezdünk kifogyni a jó kérdeskből.
Olyan kérdéseket szeretünk, amely gondolkodtató, nyelv független, és azt méri le, hogy mennyire van képben az alapokkal (mind matematika, mind a programozás). Pl. az ilyen kérdés, hogy "bármilyen segédeszköz /számológép, számítógép stb./ használata nélkül, mond meg ha egy szög sinusza 0,8 mennyi a cosinusza".
Ötleteket előre is köszi.
"Hogy a szögfüggvények miért kellenek az adatfeldolgozáshoz, azt nem értem - vagy csak korreláció, hogy ha a mateknak azt a részét tudja, akkor mást is tud?" Azt egy angol nyelvű tesztben találtuk /most nagyrészt azt használjuk, de egyrészt régi, másrészt már mi is unjuk már/, és igen, koreláció, hogy mennyire és hogyan esik neki egy ilyen látszólag megoldhatatlan feladatnak. Pl. rájön-e arra, hogy trigonometrikus pitagorasz tétel, és rájön-e arra, hogy egész értékekkel lehet számolni, és így fejben számolható az egész. Nem magunktól találtuk ki ezt sem.
10: Igen ez a nehéz, juniornál. A magasabb szinteken már picit más. Ott kezdődik, hogy nem akarunk olyat elvárni amit nem tudhat. Viszont azt kéne mérni, hogy mennyire fogja gyorsan megtanulni azt amire itt ténylegesen szükség van.
És igen, ne a kitalálható dolgok legyenek. És pont ez a baj pl. a sort-tal is, mert nagyon sok helyen azt kérdezik, és általában azt már tudják (bemagolták). Ugyanúgy amit Te is írtál, hogy "rákamuzhat". Ami már a CV-ben is látszik, hogy kb. a 80% bullshit, és ez a baj a junior "referencia munkákkal" pl. amit esetleg hoz bemutatni, meg leszedjük a gitről vagy akárhonnan. Mert nagy részéről nem lehet tuni, hogy 1./ mennyiben saját munka (egyetemi beadandók pont ugyanez a kategória, mert simán megirathatta a haverral, nálunk is gyakori volt, hogy néhány írtuk meg az évfolyam többi részének a beadandóját, de volt, hogy az enyémt is más írta meg, mert éppen kifuttatom az időből) 2./ nem lehet tudni, hogy 1 nap, 1 hét 1 év alatt készült el (pl. itt volt egy olyan kérdés, hogy egy kb. 2 éve, hogy ha 2 nap alatt meg tudok írni egy bejelentkezést akkor az már jó?)? És pont azért mert juniort keresünk most. Az sem járható, hogy adunk neki valami nagyobb feladatot mert el fog rajta vérezni, mert nem tud(hat)ja megoldani (ld. pl. jó nagy dataframe R-ben és tisztítsa meg a zöldségtől). A nagy részük azt sem tudja mi az az R majd megtanulja, ha meg van benne a képesség, és megvan hozzá az alap. Meg olyat se akarunk kérdezni amit egyszer tőlem kérdeztek, hogy az x86 procinál melyik regiszter hanyadik bitje a carry? Ott a kézikönyvben, ha kell megnézem, ha gyakran kell egy idő után ha nem akarnám akkor is megjegyzem.
válasza: válasza:Szerintem megoldani pontos feladatokat nincs sok értelme
most mondok egy példát
van 9 labdám 8 ugyanolyan súlyú 1 nehezebb és van egy mérlegem ami nem mutat számot csak hogy egyenlő-e vagy sem 2 mérésből mondd meg melyik a nehezebb labda
Tök jó felismeri a bináris keresést 3 értékkel de egy válasza van szóval sokat nem tudsz meg róla mint jelentkező
Szerintem a nyitottvégű kérdések sokkal előnyösebbek ahol több jó válasz is van és kihozod belőle hogy beszéljen a tárgyról "butíts le" néhány valós dolgot amit kéne csinálniuk (vedd ki belőle a nyelvi dolgokat), nehéz példát erre mondani mert nem tudom pontosan milyen adatfeldolgozásról van szó ezért maradok a keresés típusoknál ahelyett hogy bináris keresés adsz neki egy táblázatot soronként egy adat és megkérdezed hogy mi alapján keresne rá x dologra hogyan? miért? és elég hamar megtudod melyik is érti a keresések lényegét és melyik nem
Remélem érthető mire próbálok mutatni
válasza: válasza:Én rengeteget felvételiztettem az elmúlt években bioinformatika vonalra, ahol a fő profil adatelemzés, adatmodellezés és fejlesztés. Nálunk a nyelv kizárólag Python-PySpark. Ami bejött:
- Legyen valami kódolási feladat, ami valóban életszerű. Ami kicsiben hasonlít a munkára, amit majd el kell végezni. Ezt a feladatot kiküldjük kb 10-15 jelentkezőnek. Van rá egy hetük. Nyelv szabadon választott.
- Nekünk van egy publikus data productunk, amin alapult a feladat. Ezzel azt is le tudtuk mérni, hogy a jelentkező mennyire van tisztában velünk, tudja-e, hogy hova jön, van-e domain ismerete (de ezek nem feltétlenül szükségesek a megoldáshoz). A probléma olyan szokott lenni, hogy a feldolgozandó adatszett mérete miatt már számít az is, hogy miképpen implementálja a megoldást.
- Használ-e verziókezelést? (ez mostanában már teljesen alap, meg is követeljük, hogy verziókezelőt használjon a feladat beküldésénél)
- Ajánljuk, hogy írjon teszteket. Ezt is megnézzük, hogy van-e? Értelmes teszteket ír-e? Valóban lefed vele edge-case-eket, vagy csak arra megy, hogy nagy legyen a coverage. Sokat elmond arról, hogy mennyire értette meg a feladatot és az adatokat.
- Persze a feladatmegoldásnál bármilyen nyelvet használhat, a csapatban meglehetősen diverz a szakértelem, ez nem jelent problémát, de tudja, hogy Python-ra kell váltani. Ha jó kódot ír R-ban, vagy Perl-ben, nem lesz gond a Pythonnal.
- Használ-e dedikált adatfeldolgozó megoldásokat, pl. pandas, PySpark, tidyverse, dplyr vagy csak for loop-okkal szerencsétlenkedik.
- Használ-e többszálúsítást pl. PySpark, pandarallel, multithreading.
- A megoldással szállít-e normális dokumentációt, rendesen le van-e írva a szükséges környezet. Esetleg van-e konténerizáció. A munka igényessége, mégha nem is tökéletes a megoldás, sokat elmond arról, hogy milyen hozzáállást várhatunk később.
- Mennyire olvasható, logikus-e a kód. Aztán el tudja-e magyarázni az interjún, hogy mit miért csinált. De alapvetően az interjún tényleg csak minimálisan jön elő a kódolási feladat. Elismerjük, esetleg egy-két kérdés, főleg, ha valamit hibázott.
- Rendkívül sokat mond, ha arról faggatjátok, hogy az eddigi pályája során (akár hobbi projecteknél) mi volt a legnehezebb dolog, mi okozott problémát, és azt hogyan oldotta meg. Ebből rengeteget lehet tanulni az emberről. Most volt egy gyakornokunk, aki egyáltalán nem volt képes önállóan problémát megoldani, őt ezzel a kérdéssel ki tudtuk volna szűrni, de nála ez valahogy kimaradt.
- Adatfeldolgozásnál az egyik legfontosabb dolog, ha a jelentkező precíz, alapos. Ezt leginkább úgy tudjátok lemérni, hogy mondtok pár problémát, amivel ti találkoztatok, érdemes lehet megkérdezni, hogy egy ilyen-olyan esetben ő mire gyanakodna, hogy állna neki megoldani a problémát, mit ellenőrizne.
- Érdemes megkérdezni, hogy volt-e valami hobbi projectje, erről szívesen beszélnek az emberek, mert otthon érzik magukat a témában. Ebből is nagyon sokat lehet leszűrni: vannak-e önálló ötletei, külső nyomás nélkül hogyan tud komplex problémát lebontani managelni, mennyire kitartó, meddig jut vele.
- Mi algoritmusokat sose kérdeztünk, semmi értelme. Se a backend, se a frontend felvételin nincs ilyen nálunk, mert senki nem hisz abban, hogy ez egy jó szűrő lenne.
Nekem az a tapasztalatom, hogy a legfontosabb skill a lelkesedés, kitartás és precízió és, hogy könnyű-e vele szót érteni. Ha jól szót tudtok érteni az interjún, és látszik a jelentkezőn, hogy lelkes és motivált, akkor jól fogtok vele járni, hiába vannak hiányosságok. Azokat pótolni lehet. Mondok egy példát: az egyik legjobban sikerül recruit egy fiatal, frissen végzett gyógyszerész csaj volt. Nem volt professzionális fejlesztői tapasztalata, de volt egy csomó Coursera certificate-e, nagyon jó volt vele az interjú, szép olvasható, de meglehetősen alap beadandót írt. Látszott, hogy viszonylag rövid idő alatt tanult meg egy csomó mindent, és arra fogadtunk, hogy ez a fejlődés tartani fog. Évtizedes tapasztalattal rendelkező bioinformatikusokat, adatelemzőket megelőzve került be a csapatba. Fél évvel később már rendkívül jó minőségű spark kódot írt, önállóan járt utána bugoknak több ezer soros kódbázisban, és mellette folyamatosan újabb technológiákat tanul javasol a csapatnak.
"bármilyen segédeszköz /számológép, számítógép stb./ használata nélkül, mond meg ha egy szög sinusza 0,8 mennyi a cosinusza"
Nem mondom, hogy feltétlenül hülyeség ez a kérdés, mert ha ez egy életszerű probléma a mindennapi munka során, akkor releváns lehet. Ha nem, akkor dobjátok azonnal.
"Ajánlj fel neki 1 napos fizetett próba napot."
Jézusom, mi ez a baromság? Kinek van erre ideje?
válasza:"Jézusom, mi ez a baromság? Kinek van erre ideje?"
nekem xD(ha nem látok a csapatból 2-3 embert az állásinterjún, és van egy biztos melóm, akkor....)
Amúgy meg valid amit írsz, ebből szerintem a leggyengébb 15-30 % nagy valószínűleg ki fog esni. Ez alapján a szűrés valami rendszer szerint történik nálatok. (egy rossz rendszer is többet ér, mintha random csinálnánk a dolgokat)
Az önálló munkavégzést meg tényleg szűrni kell állásinterjún, jó lehet rá ,ha az előző projektből a legnehezebb task-ra kérdezel rá, hogy az illető ezt hogyan oldotta volna meg. Minél nehezebb annál jobb, lehet majd látni rajta, hogy be pánikol vagy megpróbálja elvinni a dolgokat addig ameddig lehet, illetve tud-e visszakérdezni.
válasza:@16 "Amúgy meg valid amit írsz, ebből szerintem a leggyengébb 15-30 % nagy valószínűleg ki fog esni."
ÁÁÁÁÁ, nagyon szelektívek vagyunk. Kapunk kb. 80-100 CV-t. HR nem is látja őket, mi fogunk velük dolgozni, mi nézzük át őket. A kb 15 legjobbnak kiküldjük a kódolási feladatot, visszaküldi mondjuk 10, ebből szóbeli interjúra kiválasztunk 5öt, és az esetek kb. harmadában nem veszünk fel senkit. Az állást újra kiírjuk. Nagyon sokat fektetünk az munkatársakba, nagyon-nagyot buknánk, ha rossz ember jönne csapatba.
válasza:Szerintem programozásnál alapból fontosabb hogy legyen az embernek problémamegoldási skillje, azt mérni hogy mit magolt be sztem fölösleges.
Én a helyetelben adnék egy adott problémát és megkérdezném hogy milyen módon oldaná meg.
Pl saját függvénnyel (azaz nem egy random könyvtár függvényével)hogyan szednéd ki az NaN adatokat egy adattábla/mátrixból. Hogyan kezelnéd ezeket a sorokat? Mitől függ hogy hogyan kezeled ezeket a sorokat?
Én ha matematikai kérdéseket tennék fel akkor nem kérdezgetnék random sin/cos kérdéseket, én is adatokkal dolgozom és baromira nem érdekel hogy mi az eredménye, ott van a google.
Sztem sokkal fontosabb hogy tudja azt az illető hogy mit mire használsz, pl mit csinál egy deriválás, mit csinál egy integrálás, mi az hogy szórás, mi az hogy variancia, ezeket mire lehet használni.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!