Hivatalos: Semmire sem jók a "táblás" fejlesztői állásinterjúk

Hivatalos: Semmire sem jók a "táblás" fejlesztői állásinterjúk
2020-07-21T08:18:13+02:00
2020-08-12T18:01:01+02:00
2022-10-17T13:55:35+02:00
  • Ez.

    Meg az is, hogyha egy terméknek sok felhasználója van (vagy nagy cégek a vevők), és főleg ha a napi működéshez használják, az sosem lesz sétagalopp. Én az egész karrierem során olyan termékeken dolgoztam, aminek vagy millios felhasználói bázisa volt, vagy kevés, de nagy, globális cégek használták. Ott a legkisebb hiba, leállás, időre nem elkészülés azonnal problémát okoz az ügyfeleknek.

    A stressztűrő nekem azt jelenti, hogy valaki jól, konstruktívan, kezeli ezeket a szituációkat. Jól egyensúlyoz a tech debt  vs. új feture-ökkel, képes megértetni a managementtel, hogy hol kell befektetni, ha bedől valami azt hatékonyan megoldja, stb.
    Mutasd a teljes hozzászólást!
  • Arról nem is szólva, hogy ha egy melóhely stresszes, ott valahol a menedzsment elSZúrt, nem kicsit, de nagyon. Ilyen helyre fel lehet venni ugyan "stressztűrő" embereket, de a dolognak akkor is elég csúnya vége lesz code quality szempontból, annak pedig hosszabb távon a megrendelő sem fog nagyon örülni.

    Ugyan, ez senkit nem érdekel. Szerintem az van, hogy a többség nem gonosz és nem szekálni akarja embertársait, hanem sok kicsi lépéssel egy folyamatosan változó közösség összerak egy nagyon bonyolult építményt. Ott aztán már nehéz tervezni a managementnek is. Mert az emberi teljesítőképességen túl van. Elég, ha normál emberi erőfeszítésnél több kellene hozzá.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Nekem az mondjuk új, h a PM-nek bármilyen tevőleges hatalma vagy befolyása legyen, az a PO/SO, nem?
    Mutasd a teljes hozzászólást!
  • A vegen persze lehet igy. De a folyamat, amig eljut oda, h akkor lapokat kell teriteni, addigra van, h mar jo par jo szakember elhagyja a hajot. Szoval itt arra akarok kilyukadni, h felelos vezetoket kene felvenni, csakhogy sok esetben a cegen beluli belsos elolepesi fazissal kerulnek olyan emberek pozicioba, akik alkalmatlanok.
    Mutasd a teljes hozzászólást!
  • Nálunk kért véleményt a felső vezetés a projekt menedzserről, és amikor az katasztrofális volt, akkor bizony repült az illető. Mondjuk ilyen csak kétszer volt, mert azért nálunk felvételkor erősen szűrik a vezetőket is. Az egyik repülős csávó amúgy nem volt rossz fej, csak nagyon más területről jött. A másikat viszont nem tudom ki vehette fel...
    De a helyzet az, hogy olcsóbb keresni egy új PM-et mint 10 új programozót, pláne ha a betanulási idő is van vagy két hónap, és közben elég gyakori hogy az illető úgy dönt, hogy inkább máshol keresi a boldogulást. Ráadásul a projekt szempontjából is sokkal kevésbé fáj.
    Mutasd a teljes hozzászólást!
  • Oke, de ettol fuggetlenul ezt bizonyitani is tudni kell. Nekem ilyen teren nem jok a tapasztalataim multi teren.
    Mutasd a teljes hozzászólást!
  • Azokon a helyeken már a menedzser is csak erőforrás. És ha a HR költség a hülye főnök miatt durván megemelkedik, akkor szívfájdalom nélkül kirúgják. Nekem már két főnököm is kénytelen volt új kihívások elé nézni, pedig nem is az a fél csapat elmegy miatta kategória voltak, csak nem igazán illeszkedtek a vállalati kultúrába.
    Mutasd a teljes hozzászólást!
  • Ha eleg nagy a ceg, akkor hiaba van felremenedzselve, nem fog kihullani. Egy meret felett ez mar annyira nem szamit. A fejleszto pedig tobb esetben csak eroforras.
    Persze, te, mint fejleszto donhetsz ugy, h lepsz tovabb, csak abban nem vagyok biztos, h a kovetkezo helyeden nem hasonlot, vagy epp pont ugyanazt fogod tapasztalni.
    Mutasd a teljes hozzászólást!
  • Már nagyon régóta sokkal nagyobb az igény a JÓ fejlesztőre mint a hülye főnökre, tehát nem kell ott maradni komolytalan helyen. (Sőt, minél könnyebben forgolódnának minél többen, annál hamarabb hullanának ki a félremenedzselt cégek a piacról.) Ha meg gond van az alkupozícióval, akkor önfejlesztés a megoldás, aztán majd nem lesz.
    Mutasd a teljes hozzászólást!
  • Alapvetően nem ezek a stresszforrások, hanem amikor a 3 fős cég vezetője tegnapelőttre vállalja be a Halálcsillag lefejlesztését, vagy amikor 10 ember dolgozik egy 5 négyzetméteres openofficeban és félóránként bejön a főnök és megkérdezi hogy miért nincs még kész  Halálcsillag.
    Mutasd a teljes hozzászólást!
  • Off: én finoman szólva se vagyok nagy híve a projektmenedzsmentnek, mivel az én területemen maximum arra jó, h formálisan is kiderüljön h senki nem tud semmit a projekt elején, utólag meg szintén felesleges okoskodni.

    Ettől függetlenül a dolog szükségességét átérzem a pénzügyi tervezés szempontjából, de ott meg mindig vannak lehetőségek a kockázat áthárítására. A sor végén persze (fölfelé!!!) mindig lesz valaki akinek jól jött volna ha előre tud tervezni, de arra meg azt mondom, h a jó ügyfélnek tudnia kell h miért 6 hónap és nem 2, amelyik meg nem tudja, ott legalább már az árajánlatnál kiderül, h nem egy ligában játszotok, és nem kell tovább menni.

    On: de, pont ez volt a lényeg a mondandómban, h teljesítménykényszeres személyiségek ragyogóan tudnak önerőből is stresszelni. ÉS nem baj ha látod az interjún mit művelnek olyankor.
    Mutasd a teljes hozzászólást!
  • Sok mindenen lehet stresszelni, de az mindig a cég, vagy a menedzsment hibája?

    Mondjuk arra kérnek hogy egy gomb legyen keretes és piros, majd holnap úgy döntenek hogy mégis inkább sárga és keret nélküli.  Ezen nyilván lehet stresszelni, de ez a munkám, hogy csináljam meg. Ezért fizetnek. Én inkább csak akkor szoktam böngészni az állásajánlatok között, amikor felmerül az a kérdés ezek után, hogy a 2 hónapra tervezett projekt, hogyan húzódhatott el 4-6 hónapig és máskor jobb lenne ha jobban fel tudnám mérni. És amikor ugyanezzel az emberrel  készítem a projektet, akkor nyilván belekalkulálom őt is. és már eleve 6 hónapra tervezek. És akkor jön a menedzsment hogy de hát mi tart ezen 6 hónapig? Á, semmi, legyen csak 2.
    Mutasd a teljes hozzászólást!
  • Ezzel nem teljesen értek egyet, nem minden projekt jól tervezhető, vagy egyáltalán "csak" fejlesztési jellegű. Ha K+F-et csinálsz, akkor az kapásból egy elég jelentős stresszforrás, h be fognak-e egyáltalán jönni az ötleteid, vagy sem. Ez attól függetlenül is így van, h egyébként szemét e a főnököd, vagy kimondotta rágja-e a füledet az ügyfél már, vagy még csak a saját elvárásaidhoz képest teljesítesz alul.

    Ugyanígy legitim stresszforrás a változáskezelés. Attól még, h emberileg normális légkörben van lekezelve, attól még az eddigi terveket gyökeresen keresztülhúzó változás sem annyira vidám dolog, főleg ha egyébként lelkes voltál valamire és vártad, h oda jussatok. (Igen, van olyan, h tényleg jó egy projekt, és motiváltak az emberek.)

    Alapvetően úgy tudnám ezt egyszerűsíteni, h nem csak olyan stressz van, amikor rosszul volt az emberi oldal menedzselve, hanem olyan is van, ami valahol a lelkesedésből fakad.

    A projekt menedzsment módszerek próbálnák elkenegetni a stresszt, amiből már láttam működő verziót, h tényleg senki sem stresszelt, de mivel lelke sincs a dolognak, valójában pontosan amiatt nem stresszeltek, mert nem is érdekelt senkit, h mit csinálnak... Az meg nem professzionalizmus, hanem kiégési tünet.
    Mutasd a teljes hozzászólást!
  • Arról nem is szólva, hogy ha egy melóhely stresszes, ott valahol a menedzsment elSZúrt, nem kicsit, de nagyon. Ilyen helyre fel lehet venni ugyan "stressztűrő" embereket, de a dolognak akkor is elég csúnya vége lesz code quality szempontból, annak pedig hosszabb távon a megrendelő sem fog nagyon örülni.
    Mutasd a teljes hozzászólást!
  • Azzal, aki tündérország teljes nyugalmában nagyon gyönyörű dolgokat tud alkotni, aztán utána heti szinten tudod nézegetni a pusztuló mentális egészségét éles munkakörnyezetben, nem biztos, hogy a legjobb választás együtt dolgozni.

    Szerintem meg a ma divatos processek elidegenítő, sorozatgyártott emberekre és feladatokra kitalált hozzáállása helyett lehet az egyéni képességek, erősségek és gyengeségek mentén feladatokat osztani és választani. Einstein a Szabadalmi Hivatal nyugalmában és csendjében alkotta meg a relativitáselméletet. Az esetleg igaz lehet, hogy egy stresszes, hajtós munkahelyre nem tündérország fejlesztőit kell felvenni. De jó esetben az illetőnek lesz annyi önismerete is, hogy el tudja dönteni, neki mi a jó. De ahhoz az kell, hogy ne hazudd fejlesztésnek a devopsot, ne mondd azt, hogy nincs túlóra, amikor van. Ne mondd, hogy érdekes a feladat, ha egy gány kódbázist kell supportálni. Ne mondd, hogy sok érdekes project lesz, amikor azok még csak távoli tervben vannak. Ne mondd, hogy támogató, stabil csapat van, ha a fele lecserélődött az elmúlt fél évben.

    Ezért tökéletes kérdés egy interjún a munkáltató felé az (amikor előjönnek, hogy van-e még kérdésed), hogy mondják meg, konkrétan milyen jellegű feladatok várnak az elkövetkezendő 3 hónapban (mondja el a backlogot projectnév, meg konkrét osztályok, meg egyebek nélkül). Aztán adjon őszinte becslést 6 nónapra. Az emberek többsége nem szeret hazudni szemtől szemben. De ha olyan kérdéseket teszel fel, amire gumiválasz adható, akkor nyilván szépíteni fogja. Ugyanígy, meg kell kérdezni, hogy mennyi és milyen módon van a support. On-call, hétvége, etc.
    Mutasd a teljes hozzászólást!
  • Úgy lehet tesztelni, hogy fogsz egy szimpatikus open-source projectet, aminek a minősége, mérete és egyéb paraméterei hasonlóak ahhoz, amin dolgozni kéne majd, és abból adsz egy offline feladatot. Cserébe ez effort a cég és a jelölt részéről is. Ha egyéb szempontból megoldható, akkor ezt saját kódbázissal is lehet akár.
    Mutasd a teljes hozzászólást!
  • Csak rosszat. Annyira jól szerintem ezt nem is biztos hogy lehet tesztelni, mert ez kb. arról szól, hogy mennyire gyorsan tudsz valamit megtalálni / megjavítani egy sok ezer soros katyvaszban. Ráadásul a hogyan javítod meg is szempont lehet, mert az egésznek a végén jobban kellene hogy kinézzen mint előtte, azaz ne keresztbe hekkelje az illető a fix-szel a cuccot, mert ha ezt az életben is gyakorolni fogja, akkor fél év múlva ki lehet dobni az egész kódbázist. Na most, ha ezt úgy oldod meg, hogy nesze Pistike, itt egy 200 soros agyonbonyolított kód és van 2 perced hogy kijavítsd, azzal pont nem a fenti folyamatot modellezed.
    Mutasd a teljes hozzászólást!
  • Én voltam olyan helyen, ahol egy teljesen valós problémát mutattak meg, mielőtt a céget, munkakörnyezetet, terméket megmutattá és beszélgettünk. Kíváncsiak voltak, hogy  miként kezdeném el a probléma forrását megtalálni, ha sikerült, akkor milyen megoldást választanék a javításhoz, kiket vonnák be ha szükséges. Szimpatikus volt ez a megközelítés, mert nem volt olyan érzésem, hogy itt most vizsgáztani akarnak, vagy fussak versenyt az idővel...stb.
    Mutasd a teljes hozzászólást!
  • szerintetek mivel lehet reálisan jósolni a munkára való alkalmasságot?

    Mérnökinfo, progmat diploma és mellé önéletrajz., eddigi munkák. Szerintem jó kiindulási alap, a próbaidőn meg eldől ért-e hozzá. Szóval pont ugyanúgy, mint bármely más szakma esetében.
    Mutasd a teljes hozzászólást!
  • Egyik se baj. Ezek nem kódírási képességet felmérő feladatok, hanem kollaborációs, kommunikációs és egyéb képességeket mérő szituációs feladatok, a jelölt számára elvileg valamennyire hazai terepen. És emiatt pont a senoritással emelkedik ennek az információtartalma. Egy senior/lead/architect kollégánál a táblás rész sokkal fontosabb, mert az a feladatainak jelentős része lesz, hogy a fejében lévő fogalmakat, architektúrát hogyan tudja érthetően elmagyarázni másoknak, illetve az azon szükséges változtatásokkal kapcsolatban hogy kommunikál másokkal, hogy jut konszenzusra stb. Ez már inkább a rajzolgatós feladat. A táblánál kódolás ugyanez kicsiben, egyszerűbben, illetve jobban a struktúrált gondolkodásra fókuszálva. Ha az interjúvezető nem ismeri fel/tudja, hogy miről szól ez a feladat és kihívást jelentő programozási problémát akar megoldatni táblánál, az viszont nem vezet sehova.
    Mutasd a teljes hozzászólást!
  • Ez a kódganéztatás ez nagyon jó (milyen gyorsan igazodik ki nagy, lehetőleg ocsmány kódban), amit írsz, én ezt leginkább debugolós teszt feladat formájában tudnám elképzelni, te láttál már erre jó példát?
    Mutasd a teljes hozzászólást!
  • Itt most specifikusan arra gondolsz, amikor (minimum) pszeudokódot iratnak a táblán, vagy szerinted en bloc ha már rajzolgatásba torkollik az interjú, akkor baj van?
    Mutasd a teljes hozzászólást!
  • offsite módon, hogy ne legyen stressz

    Köszönöm, igazából ez pontosan az a része amire felkaptam a fejemet már a cikkben is, ezért (is) kérdeztem be. Igazából itt látok értékválasztási kérdést is, hogy miből indulunk ki, hogy a "valóságban" amit csinálni kell az mennyire lesz stresszes. Az én eddigi tapasztalatom az, hogy eléggé, de nyilván van eltérés a karrierutakban. Én eleve úgy lennék vele, hogy az nem baj ha a stressz alatti, rosszabb teljesítményt mérjük, csak legyen fair a dolog és mindenkinél azt mérjük. Azzal, aki tündérország teljes nyugalmában nagyon gyönyörű dolgokat tud alkotni, aztán utána heti szinten tudod nézegetni a pusztuló mentális egészségét éles munkakörnyezetben, nem biztos, hogy a legjobb választás együtt dolgozni.
    Mutasd a teljes hozzászólást!
  • Pontosan. De ezek a táblás játékok csak a legalján érdekesek.
    Mutasd a teljes hozzászólást!
  • magyarán szint (pályakezdőtől "guru"-ig) ill. feladatfüggő, milyen interjú a célravezető
    Mutasd a teljes hozzászólást!
  • Attól függ. Ha juniort keresel pincebétébe minimálbér + okosba kombóval, 7x24 órás munkaidőbe, akkor jók ezek a tesztek. Picit feljebb viszont már nem az lesz a lényeg, hogy a Pistike 15 másodperc alatt hány szintaktikus hibát talál a 300 soros kódban, hanem az hogy mennyire van barátságban az illető az olyan dolgokkal mint Pl. DI konténerek, mapperek, ORM megoldások. És persze az sem árt, ha látott korábbi technológiákat is, mert van néha hogy a legkorszerűbb többrétegű megoldásoknál hatékonyabb egy jól irányzott SQL parancs. És a pénz hosszú távon sokkal inkább ezeken megy el egy projektnél mint azon, hogy Pistike 300 vagy 500 sort kódol le egy nap.
    Ehhez pedig elsősorban beszélgetni kell, méghozzá olyan polgárnak aki ért is a dologhoz. És persze egy HR-en ez a legszűkebb keresztmetszet. Mert az a csávó aki 10 perc beszélgetés után tökéletesen tisztában van az aspiráns képességeivel, ritkán ér rá 10 percre ezzel foglalkozni, viszont a Mucika a HR-en azon túl sok mindenhez nem ért, hogy szépen tud mosolyogni az illetőre.

    Aztán én azt is mérném valahogy, hogy az illető mennyi idő alatt igazodik ki egy nagyobb kódbázisban. Mert hogy ez egy nagyobb project esetén ez fogja igazán meghatározni a fejlesztési sebességedet. Az ugyanis egy idő után ritkán fog előfordulni, hogy csak a saját, frissen fejlesztett kódodat kell nézegetni,  pláne ha agilisban nyomjátok, márpedig manapság kb. mindenki ezt teszi.
    Erre megint nem a legjobbak a szintetikus tesztek.

    Aztán az is egy fontos szempont lehet, hogy az illetőnek legyen fogalma az aktuális technológiáról amit hasztáltok. De erre megint a beszélgetés a legjobb.

    Szóval, én ha ez lenne a feladatom, akkor először is az alapján döntenék hogy kit keresek. Ha juniort, akkor jók az online tesztek, ha senior-t akkor először is önéletrajz, aztán elbeszélgetnék az illetővel, és ha Ok de csak is akkor, egy fél napos próbafeladat - nem űrtechnológia, de egy komplett feladat nulláról megírva, amiből látni lehet hogy hogy csinál ő meg egy projektet. Fokozottan igaz az elbeszélgetős rész a team leaderrel, ugyanis már a seniornak is dolga az is hogy a juniorokat segítse, a TTL-nek pedig az egész csapatot kell támogatnia, ő már kódot alig ír, nála az ilyen online tesztek már végképp irrelevánsak.
    Mutasd a teljes hozzászólást!
  • Szóbeli, írásbeli tesztek, beszélgetés és programozási feladat megoldása offsite módon, hogy ne legyen stressz. (Igen, lehet olyan feladatot adni, ami nem minősül próbamunkának. Leírták érthetően, a jogi állásfoglalásra mutató linket javaslom elolvasni.)
    Mutasd a teljes hozzászólást!
  • Oké, vegyünk két példát, amit itt is írtatok, meg szoktak rajta panaszkodni, h nem életszerű: online időre kódolós teszt, illetve táblás agyzsigerelés. A próbamunkát meg én zárnám ki. Szóval, ha ezekkel nem, akkor szerintetek mivel lehet reálisan jósolni a munkára való alkalmasságot?
    Mutasd a teljes hozzászólást!
  • Az idézett link nem teljesen pontos. Ezt érdemes elolvasni a témában: The Truth About Value Types
    A saját dokumentációjukat is hibáztatja :)

    Ettől még azt érdemes tudni, hogy kerülhet a stackre (vagy regiszterbe, a lényeg hogy nem heapre), és ezt érdemes figyelembe venni a kód írásánál. Pl azzal, hogy elkerülöd a boxingot mindenhol, ahol lehet. Illetve hogy lokálissá konvertálható value type-ot nem tárolsz fieldként. Kikötött runtimenál, konkrét esetben lehet csak arról beszélni, hogy mi hová kerül. Bizonyos helyeken ezzel viszont kell is foglalkozni valóban.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd