interjúzok és interjúztatok

 ( zp | 2019. március 20., szerda - 5:25 )

Sziasztok, régóta fent vagyok a HUP-on és nem szoktam írni, de az utóbbi pár hét elég stresszes volt, szóval arra gondoltam, hogy leírom, hogy miken gondolkodom, hátha kiderül, hogy valamivel nem vagyok egyedül. Elvileg a blog erre van.

Szóval pár hete elkezdtem újra munkát keresni. Egy viszonylag ismeretlen informatikai cégnél dolgozom vezető fejlesztői pozícióban, ami nagyon klassz és mindenki nagyon szeret és megbecsül, de van pár kulturális kérdés, amivel nem értek egyet és ezért úgy érzem, hogy elfogyott a levegő. Erről és a munkakeresésről is szeretnék majd írni.

De előbb lássuk az asztal másik oldalát: folyamatosan besegítek a céges felvételiben is, eddig pár tucat szóbeli szakmai interjún voltam és lassan körvonalazódik néhány tanulság. Felvételiztetni klassz dolog, mert sok új arcot és különböző hátteret lehet megismerni és mindig izgalmas, hogy mások szerint mik a lényeges szakmai szempontok. Ezeken is sokat gondolkodom mostanában, úgyhogy itt van Tíz Dolog Amire Figyelj Felvételi Közben.

1. Az interjún legyél ápolt és ne legyen hajléktalan szagod (nem röhög, pár napja volt ilyen is).

2. Legyél alázatos és ne viselkedj arrogánsan. Nagyon könnyű véletlenül is olyat kérdezni, amire nem tudod a választ és így könnyen nevetségessé válhat ha kiütközik a gőgös viselkedés. Az interjúztatónak is az a célja, hogy a maximumot kihozza belőled, miközben mindannyian jól érezzük magunkat, de ehhez segítened kell neki.

3. Általában már az interjú elején gyorsan kiderül, ha egy jelentkező jó lesz vagy sem. Ezután, ha jó lesz, akkor az interjút gyakran önkéntelenül is jobban elhúzzuk (plusz fél óra), de ha nem lesz jó, akkor gyorsan rövidre zárjuk a beszélgetést, hogy ne áltassuk egymást és ne pocsékoljuk egymás idejét.

4. Figyelj oda a helyesírásodra az önéletrajzban. Nekem mindig furcsa, amikor valaki öt év ELTE után az Eötvös Loránd Tudományegyetem nevét d helyett t-vel vagy hosszú ó-val írja. Szerintem ennyi idő alatt annyiszor látja az ember ezt a nevet, hogy be kell vésődnie a helyes leírásnak. Ha nem vésődött be, akkor lehet, hogy érdemes lenne még egy évre visszamenni, hátha.

5. Ha van szakmai házi feladat, akkor nagyon jó, ha visszajelzel emailen, hogy a feladatot megkaptad és majd dolgozol rajta. Innen tudjuk, hogy jó címre küldtük és nem fogunk fölöslegesen izgulni.

6. Ha van szakmai házi feladat, akkor a megoldás formázott kódot tartalmazzon, ne legyen benne automatikusan generált és véletlenül benne hagyott komment, ne legyen benne compiler warning, legyen hozzá valami egyszerű leírás és tesztesetek. Továbbá szerintem fölösleges egy fejlesztő cég számára a binárisokat is elküldeni, mert biztosan van ott szakember, aki tudja, hogyan kell lefordítani és futtatni a programot.

7. Egy szakmai kérdésre soha és semmilyen körülmények között ne válaszold azt, hogy nem tudod a választ, de igaziból nem is fontos a válasz, mert a napi munka során nem fog előjönni, de ha mégis előjönne, akkor rákeresel. Nem profi dolog.

8. Általában a szakmai kérdéseket nem túl eredetiek, ugyanarra a pozícióra gyakran különböző cégeknél is ugyanazok a kérdések szoktak előjönni, ezért érdemes előtte a neten rákeresni a gyakoribb megoldásokra. Ha nem tudod a választ valamire, semmi gond, de akkor ne említsd az interjún, hogy tegnap is kérdezték már.

9. Ha nem tudod a választ egy szakmai kérdésre, akkor nagyon jó, ha elkezdesz hangosan gondolkodni róla. Ne zárd le a kérdést annyival, hogy nem tudod.

10. Tisztában vagyunk vele, hogy olyan nincsen, hogy valaki úgy ahogy bejött az ajtón, tökéletesen megfelel egy pozícióra. Ezért sokszor kevésbé fontosak a konkrét ismert technológiák vagy a releváns tapasztalat. Helyette arra vagyunk kíváncsiak, hogy a jelölt tud logikusan és jól strukturáltan gondolkodni, kommunikálni, tud tanulni és motivált.

Kihagytam valami fontosat?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Teljesen jó!

(Ha már helyesírás: "kiüzközik", "bennehagyott")

--
trey @ gépház

köszönöm!

Nem tudom == Most nem tudom a választ != Soha nem is fogom tudni

Számomra a profinak nem gáz azt mondania: nem tudom

Ha interjúznék ezután csak annyit mondanék: Nagyon jó! De hogyan állnál hozzá?
(net, kolléga, etc...)

Én biztosan nem a jelenlegi tudáshalmazzal akarnék operálni (folyamatosan inflálódik), hanem a hozzáállással és a tanulási vágy meglétével. Amúgy szerintem jobb egy olyan kolléga akinek nőnie kell a feladathoz és ezt érzi is, mint aki fölényesen oldja meg, mert ez utóbbi hamar tovább fog állni.

Egyetértek, ha valamire nincs "konzerv" válasz, az nagyon izgalmas, mert rávezetéssel el lehet kezdeni együtt gondolkodni a megoldásról és ebből több minden kiderül, mintha csak pár kulcsszavat benyögött volna a jelentkező.

Itt inkább egy sokkal konkrétabb jelenségről van szó: többször előfordult már velem, hogy valaki az interjún meg akart győzni arról, hogy fölösleges tudást kérdezek, mert a gyakorlatban nincs szükség ilyen a tudásra, ezzel csak az elefánttoronyban ülő unatkozó tudósok szórakoztatják egymást unalmukban.

Például pár napja senior Java fejlesztő interjún rákérdeztem, hogy a fontosabb adatszerkezeteknél milyen futásidőkre kell számítani (aszimptotikus komplexitás, de nekem konyhanyelven is jó). Azért nem fogadtam el a választ, mert aznap délelőtt egy nagy adatfájl betöltését egy junior fejlesztőnk ötvenszeresére gyorsította a megfelelő adatszerkezetek használatával.

Az egyetemeken szerintem két féle ember van jelen a hallgatók között: "papír kell->megúszom" vs. "tanulni jöttem"
Az egyik kollégámnak mondtam pár éve, hogy MSc sok munkahelyre azért kell, mert BSc-nél még nem tudhatja a munkáltató, hogy komolyan gondoltad-e vagy csak anyu kedvéért csináltad meg. Amúgy azt gondolom, hogy a tananyagból való felkérdezés mutathatja, hogy felfogta-e anno vagy csak bemagolta a szakmát vizsgára.

"egy nagy adatfájl betöltését egy junior fejlesztőnk ötvenszeresére gyorsította a megfelelő adatszerkezetek használatával"

Ezek szerint nem a HW fogta, hanem a hibás kód. Gondolom a hibás kód is nálatok keletkezett. :)
(Ha ez exponenciális robbanás, akkor az 50 szeres szorzó csak explicit megadott n-re igaz, ahol O(g(n)). Erről volt szó?)

Az MSc/BSc magyarázat jó, így még nem hallottam :-)

Természetesen a hibás kód is a miénk volt, bár hibás helyett inkább azt mondanám, hogy eredetileg más céllal készült.

Igen, egy konkrét adatfájlról van szó, egyébként nem is kell exponenciális robbanás, ami távolról hasonlít az O(n)=n^2 függyvényre, az sokszor már régen rossz :D

> Az egyik kollégámnak mondtam pár éve, hogy MSc sok munkahelyre azért kell, mert BSc-nél még nem tudhatja a munkáltató, hogy komolyan gondoltad-e vagy csak anyu kedvéért csináltad meg

Ez jo, csak nem igaz. :)

En BSc-t vegeztem, de mivel az MSc-n ugyanazok az orak voltak ugyanazokkal a tanarokkal, igy skippeltem, elmentem helyette dolgozni. Majd kitalaltam, hogy jo lenne megtanulni valami ujat, ugyhogy elmentem egy szakiranyu tovabbkepzesi szakra. Ez egy evig tartott, de nem MSc diplomat ad, hanem valami papirfecnit, ezert a szakdogat pl mar nem irtam meg, hiaba van meg az osszes targyam.

Pont te szoktad emlegetni, milyen ertekes az ember ideje, ezek utan kicsit furcsa az idezett mondatod.

"sok munkahelyre azért kell" && "nem tudhatja a munkáltató"
Nem magamról beszéltem. Sok más cégről. Vegyiparban nagyon sok helyen msc nélkül nem állnak szóba veled. Nálunk nincs ilyen kitétel. Én azt nézem szereti-e amit csinál és alkalmas-e rá.

A ráfordított idő meg érdekes dolog. Többségében nézem, hogy megtérül-e kivéve ha jusforfun is csinálnám a dolgot. Gondolhatod, hogy UTP kábel krimpelés és behúzás egy veszteséges dolog részemről, ha én csinálom, de mégis megteszem, mert megnyugtat a munka monoton volta.

Igen, csak ez nem a Magyar Vegyipari Portal hiába volt MVP rövidítése az MS-nek. :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Gondolom vegyiparban is ugy van, hogy a vegyesznek inkabb kell diploma, mint mondjuk annak, aki a ceges levelezest uzemelteti :)

"Például pár napja senior Java fejlesztő interjún rákérdeztem, hogy a fontosabb adatszerkezeteknél milyen futásidőkre kell számítani."

Hogy nekem mennyire tud rángatózni a szemem ettől! (Mármint amikor önjelölt "senior" kollégák közlik, hogy ez lényegtelen, mert majd az X library konténerei – rosszabb esetben "a futtatókörnyezet" v. "a fordító" – majd azt "tudják". :D) Azért is veszélyes ez, mert általában az ilyen hozzáállású kolléga írja az N mélységig egymásba ágyazott ciklushalmot (akkor is, ha nagyságrendekkel lassabb lehet úgy a megoldás) és hasonlókat. :)

A megoldas egyszeru - beszelni kell vele es ramutatni hogy a sajat magad altal irt az sokkal jobb - olcsobb, hibamentesebb, konnyebben karbantarthatobb - ha elmesz a cegtol :P

Komolyra forditva a szot. X library valoszinuleg kovet valamilyen standard-ot, jobban karban lehet tartani a megoldast ami azt hasznalja. Ha elmesz apai szulesi szabadsagra akkor is. Masreszt mivel jobban elterjedt ezert valoszinuleg jobban tesztelt.

Tobbmillio soros kodban latom az onjelolt geniuszok megoldasait es azok bugjait :D
Mikor valaki a standard megoldas es par tiz sor helyett tobb szaz soros megoldasaban akarja megvaltani a vilagot akkor az mar jelzes hogy az valoszinuleg hemzseg a hibaktol es nehezen karbantarthato.

Egy nagy termekben a karbantarthatosag a legfontosabb, optimalizacionak kevesebb a prioritasa. Ha tenyleg lassu a megoldas akkor a profilozas azt ugy is kihozza es ki lehet cserelni.

Masreszt ahogy irtam. Csapatmunka. Kommunikacio. Beszelni kell vele ha egy megoldas nem jo, es abbol mindenki tanul.

En nem szegyellek hibat veteni egy uj teruleten es megbeszelni azokat. Az nagy gaz amikor valaki ujbol es ujbol elkoveti ugyanazokat a hibakat. (es persze a csapatot es a fejlesztesi modszert minositi hogy a review rendszer nem fogta meg, illetve a csapat tagok nem kommunikalnak egymassal)

Komolyra forditva a szot. X library valoszinuleg kovet valamilyen standard-ot, jobban karban lehet tartani a megoldast ami azt hasznalja.

Én konkrétan a Java Collections Framework-ben implementált fontosabb adatszerkezeteket szoktam kérdezni (konkrétabban: különbség a HashMap és TreeMap között, ArrayList és LinkedList között, stb). Meglepően sok problémát okoz, pedig a nyelv része több mint húsz éve.

Maradjunk abban, hogy nem a nyelv része, hanem a standard library része ;)

Bocs, félreérthető voltam, mert pongyolán fogalmaztam! :)

Nyilvánvalóan nincs értelme saját megoldásokat gányolni ezekhez, teljesen jó az X library konténereinek a használata, ezt én is maximálisan támogatom. Arra akartam célozni, amikor az illetőnek fogalma sincs, hogy az egyes konténerek milyen "vállalásokat" biztosítanak az egyes műveletek futásidejére, tárigényére vonatkozóan, mondván, hogy "majd a konténer tudja, hogy hogyan kell az adatokat kezelni, hogy optimális legyen". Ami, persze, igaz is – feltéve, hogy "jó" konténert választottál a use case-edhez. :)

Tehát az én általam említett (természetesen csak teoretikusan létező ;) ) kollégának eleve fogalma sincs arról, hogy mi az az "aszimptotikus viselkedés", és hogy eleve az alapján választasz konténert, hogy jellemzően milyen műveleteket akarsz a benne tárolt adatokon végezni.

A komment többi részével egyetértek. :)

"Például pár napja senior Java fejlesztő interjún rákérdeztem, hogy a fontosabb adatszerkezeteknél milyen futásidőkre kell számítani"

Meglepodnek ha nalunk levo fejlesztok tudnak a valaszt minden fontosabb futasidore. (Majd csinalok egy kis hazi felmerest :D) Pedig nem kis ceg vagyunk, mondhatni a vilag meretuek a termekeinket
masok eleg futuriszikusnak mondanak.

Az ok egyszeru, elobb a reszvenyes termeket akar latni a penzebol. Aztan lehet optimalizalni a dolgot. En is ennek a hive vagyok, az evolucios fejlesztesnek, nem egybol mindent bele rakni es szenne optimalizalni. Mert abbol nem lesz termek. Tobbet er ha elsosorban koncepcioban, termekben tudunk gondolgozni es hogyan epitjuk fel hosszutavon.

"mert aznap délelőtt egy nagy adatfájl betöltését egy junior fejlesztőnk ötvenszeresére gyorsította a megfelelő adatszerkezetek használatával."

Ez egy termeszetes evolucios fejlesztesi lepes volt. Lehet, ha egyaltalan nem lett volna kifejlesztve az a funkcio akkor termek es ceg sem lenne ... valahogy az az erzesem hogy M.o-n sokan csak feketen-feheren tudnak gondolkozni. Ha nem tokeletes akkor nem kell sehogysem.

Guglizni pedig nagyon olcso. Library-kat hasznalni is, ahelyett hogy feltalalnank a kereket (tele hibaval) ujra es ujra. Kerdezni masokat pedig er es nem ciki, ahogy tanulni sem.

Persze a terulet mas, komplett hardver, szoftver, szolgaltatas szoval sokretu. Van aki az opengl-hez ert, masok magas vagy alacsony szintu halozati technologiahoz ertenek. Megint masok robotikahoz, es matekhoz vagy linuxhoz. Az emberek pedig inkabb specializalodtak.

Es nincs ketsegem hogy a tobbi vilagmeretu konkurencianal sem mennek mashogy a dolgok :) ismerve azok termekeinek elonyeit es problemait.

Visszaterve az interjura. Nem az a lenyeg hogy mit nem tudsz, hanem hogyan vagy kepes hozzajarulni egy termek/szolgaltatas kifejlesztesehez mert amit nem tudsz es fontos azt pillanatok alatt meg lehet tanulni.

Mi eloszor piacot szereztunk, majd ahogy nott a ceg, a feladatkor, nott a komplexitas, ugy neztuk/nezzuk at a termeket/termekeket es optimalizalunk. Inkabb tartom fontosabbnak hogy az egyen mennyire kompatibilis a csapattal, ceggel, mennyire tud egyuttmukodni es milyen otletei vannak jobba tenni a termeket.

Az ok egyszeru, elobb a reszvenyes termeket akar latni a penzebol.

Az a probléma ezzel az érveléssel, hogy egy fejlesztési folyamat tetszőleges részén való spórolást meg lehet indokolni vele. Például sokszor láttam olyat, hogy azért nem írnak teszeket, mert nincs rá idő. Érdekes módon a kiadás előtt random felbukkanó hibák keresésére mindig sikerült időt szakítani :-)

Az ok egyszeru, elobb a reszvenyes termeket akar latni a penzebol. Aztan lehet optimalizalni a dolgot. En is ennek a hive vagyok, az evolucios fejlesztesnek, nem egybol mindent bele rakni es szenne optimalizalni. Mert abbol nem lesz termek. Tobbet er ha elsosorban koncepcioban, termekben tudunk gondolgozni es hogyan epitjuk fel hosszutavon.

Szerintem itt a kulcsszó a "senior". Azért egy seniortól – SZVSZ – talán elvárható, hogy a főbb adattípusok esetén nagyjából tudjon legalább futásidőt mondani a fontosabb műveletekre. (Legalább annyit, hogy konstans, lineáris, logaritmikus, a pontos képletek teljesen feleslegesek.) Pláne, ha direkt ez a kérdés, nem pedig arról van szó, hogy "gyorsan üssük össze a prototípust, ami kevés adatra működik, aztán majd optimalizálunk". Továbbá előbb-utóbb valakinek valószínűleg meg kell majd csinálnia azt az optimalizálást, aki jó eséllyel pont a szóban forgó senior kolléga lesz. :)

Ez egy termeszetes evolucios fejlesztesi lepes volt. Lehet, ha egyaltalan nem lett volna kifejlesztve az a funkcio akkor termek es ceg sem lenne ... valahogy az az erzesem hogy M.o-n sokan csak feketen-feheren tudnak gondolkozni. Ha nem tokeletes akkor nem kell sehogysem.

Ebben viszont egyetértek. Sajnos én magam is gyakran esek abba a csapdába, hogy "túl hamar" akarok "túl jó" megoldást készíteni (főleg szakmai vonalon, de máshol is), pedig szívtam már sokszor emiatt. Pedig pont én vagyok az, aki általában próbálja meggyőzni az ismerőseit az élet más területein a "folyamatos fejlődés" szépségeire. Szóval erről leszokni sem egyszerű. :)

Es nincs ketsegem hogy a tobbi vilagmeretu konkurencianal sem mennek mashogy a dolgok :) ismerve azok termekeinek elonyeit es problemait.

Friss diplomásként meg voltam róla győződve, hogy nem lehet mindenhol igénytelen a folyamatkezelés, a fejlesztés, a szaktudás, az időtervezés stb. Azóta láttam ezt-azt, és már rég nincsenek illúzióim (nagy cégeket is beleértve). :D

Visszaterve az interjura. Nem az a lenyeg hogy mit nem tudsz, hanem hogyan vagy kepes hozzajarulni egy termek/szolgaltatas kifejlesztesehez mert amit nem tudsz es fontos azt pillanatok alatt meg lehet tanulni.

Én ezt annyival kiegészíteném, hogy a legtöbb pozíció esetén fontos, hogy mennyire tanulóképes az illető, illetve mennyire jó problémamegoldó (függetlenül attól, hogy mit tud aktuálisan). Szerintem öntökönlövés fejlesztőnek felvenni olyat, aki ugyan "képes hozzájárulni a termék/szolgáltatás kifejlesztéséhez" (mert pl. csodaszép user guide-ot tud faragni vagy profi módon tud copy-paste-elni), de a célterületen egyszerűen azt sem tudja, hogy hova nyúljon, ha hibaüzenetet lát. (A "pillanatok alatt meg lehet tanulni" nem mindenki számára igaz.)

ahogy a rendes tesztelesre ugy az optimalizalasra sincs ido. ahogy elkeszult a termek N-edik ficsorje, az ugyfel/reszvenyes/manager mar lepni is akar a N+1-re, mert "az hozza a penzt", es te/mi hiaba tudjuk hogy az optimaliazalas is es a teszteles is hoz penzt, ok ezt nem veszik figyelembe. az evolucios folyamat meg kimerul abban hogy eddig N ficsor volt, most N+1. :(

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Naja, voltam egy cégnél egyszer interjún, 3 körös interjú lett volna, első körben HR-es, második körben szakmai, harmadikban meg még egy szakami lett volna. Második kör után sajnálattal közölték, hogy igazából senior ez meg az kellett volna nekik. Eleve úgy mentem oda, hogy ezt meg azt tudom, többit megtanulnám, mint ahogy tettem az akkori helyemen ezzel meg azzal meg amazzal, mikor szóba került az interjún másrészt a CV-mből is egyértelműen kiderült, hogy nem sokat dolgoztam a kért technológiákkal. Akkor meg minek a hercehurca? Ha konkrét ember kell, akkor nulladik körben el lehet dönteni, ne húzzuk egymás idejét.

(Mondjuk végül nem bántam, hogy nem mentem oda.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ilyenem nekem is volt. Aztan utolso utani kornel ugyanez lett a vege. :)

Kimaradt a nulladik pont: a pénz. Senki nem fog szivességből dolgozni, ha az ajánlott, és az elvárt pénz között akkora szakadék van, h abból nem lesz kompromisszum, akkor már eleve a továbbiakban fölösleges rabolni egymás idejét.

Lsd. még: "Az volna a legnagyobb üzlet, ha embereket vásárolnék annyiért, amennyit érnek, és eladhatnám őket annyiért, amennyire tartják magukat." M.Gy.

Ehhez a részhez valószínűleg még tapasztalatlan vagyok, mert eddig nem igazán találkoztam olyan helyzettel, hogy csak a pénzzel lett volna gond. Azt ide számítod, amikor valakinek a fizetési igénye már másik sávba tartozik, mint ami a tudása alapján reálisnak tűnik?

Akár ezt is. De az idővel rájön, hogy úgysem fog menni a dolog. :)

Egy rovid es ide szamolom a par orat csak a nagyon nagy eltereseket tudod felmerni.
Amennyiben interjuztatokent ezt ott azonnal eldontod 1 v. 0 szinten akkor sajnos az a rossz hir, hogy te csinalod rosszul.
Alapeset, hogy egy interjun, sosem teljesitunk maximumot, nem szabad.

Szerettem csinalni, de neha megremitett amit lattam, es nagyon jol kimerhetted, n+10 utan, hogy mi lehet az erteked a piacon.
Ez sem biztos, mivel sajat boromon tapasztaltam, hogy a felvetelizteto meg HR korben jelezte, hogy atirta az igenyemet realisra. Itt eloszor megijedtem. Majd szepen elmondta, hogy ez ugy +25% es ezt adja tovabb a vezetosegnek, mert az keves a ceg atlaghoz amit meglottem.
Az utolso ket esetben feltoltak amit kertem.

Kesobb volt, hogy jelentkezonek en is szoltam, hogy egy ilyen alacsony igennyel nem fogjak komolyan venni.

Rengeteg apro trukk van meg amivel nem tudatosan tudod befolyasolni a masik oldalt.
Erdemes olvasni ilyen teruletrol cikkeket. Kifizetodhet.

Szia, ez izgalmasan hangzik és úgy tűnik, hogy hamarosan hasznosítanom kell ezt a tudást a gyakorlatban is. Ha lesz erre időd, nagyon hasznos lenne, ha mutatnál egy konkrét cikket, ami mentén el tudok indulni.

Rettentoen nagy tema, kulon teruletek foglalkoznak olyan aprosagokkal, hogy a jelolt hord e karorat, milyet, mekkorat, milyen szinut, etc...
Kiserletek es tanulmanyok tomkelege van akar csak ebben a temaban, feluletesen megkarcolni is fel elet.
Meg bele se gondolni, hogy a mozgas, hanghordozas, beszed stilus, testtartas es egyeb reakciok is mind mind rengeteget arulnak el kulon es egyutt. Lehet himihuminak tartani, de a legnagyobb reszet nem unatkozo bolcsesz bukszak, hanem a hires/hirhedt hirszerzo szervezetek dolgoztak ki es alkalmaztak, majd kesobb kozkincs lett egy resze.

Ha ilyet hordok akkor mit allapitanak meg?

Erre rápacsáltál, mert ismerem.
Egyébként miért adnál érte annyit amennyit, amikor ugyanezt keleti készítésben töredékéért megkaphatod.
Ez ellene megy az elvemnek, hogy szart csakis olcsón és inkább egy "Nem baj ha szar, ha legalább drága legyen." :D
Beleszarós nemtörődömség vagabond lazacsávó műmájer.
Esetleg fogyatékos aki képtelen volt megtanulni a normált leolvasni.

Egyik sem pozitívum, ha nem előadóművészt vagy frontend sales dumaművész életcsászárát keresel.

"Beleszarós nemtörődömség vagabond lazacsávó műmájer.
Esetleg fogyatékos aki képtelen volt megtanulni a normált leolvasni."

Koszonjuk akkor ki is dobhatod a konyvet amibol ezt tanultad :)

Tobb even keresztul dolgoztam governance pozicioban es az egyik fo problemam sokszor visszakoszon ma is:
A szakmamban perfekcionista vagyok de tudom moderalni magam ha az adott projekt ezt kivanja.

Tehat sikerult mindent eltalalni vagy ez is valami fingreszelos tudomany lehet a HR osztalyon.

Mod:
Az elso oram egy fedeles zsebora volt ugy 6 eves koromban :P

Hogy nem vagy pontos. :)

Azt vagod ,hogy ez egy divatcucc es semmi koze a pontossagomhoz meg itt svajcban sem.

Meetingre az outlook szerint megyek/logolok be lehet rajtam trey fele csillios ora is nem szamit ha a megbeszeles a windows timeserver alapjan kezdodik :D

Az nem tesz téged pontossá, hogy hol vagy.

Kerlek fejtsd ki bovebben mire gondolsz.

racionalisan probalsz olyan dolgot megmagyarazni, amit az allatvilag (including az emberiseg minden egyes tagja, kivetel nelkul) tudat alatt, osztonbol csinal kb. azota, amiota van elet a bolygon

mindenki tudja, hogy van a telefonodon ora, attol meg kialakul rolad egy kep meg egy foto alapjan is, nem is kell eloben odamenni

"semmi koze a pontossagomhoz meg itt svajcban sem"

+1
Nekem életem legnagyobb részében vagy nem volt órám vagy zsebórám volt.
Érdekes, hogy ennek ellenére mindig pontos voltam.
Sokan nem tudják, hogy a telefonokon is van óra, a számítógépeken is, vannak nyilvános órák, sőt még a rádióban is bemondják időnként, ...
Szóval ez vicc a pontosság tekintetében.

+1, gyulolom az orat, egyszeruen idegesit a csuklomon, nem birom elviselni.
A telefonom mutatja az idot, az eleg nekem, a divat meg nem erdekel.

Nagyon egy irányból nézed a dolgokat.
Persze vannak elképzelésem a pénzről is, de látván az összes álláshirdetést, egy interjún én kérdeznék először: Mi a f.-t kell csinálni.
Mert a "fiatalos csapat", az "elvárt skill-ek", stbstb. alapján ritkán derül ki, hogy senior java programozóként a padlót kell-e felmosni, vagy uránrudakat szállítani kisteherautóval. ;)

Ugyanarra a munkára, itt, Londonban, pl. sok cég ajánl mondjuk 60-80 ezer fontot. Van kevés, akik 100, 120 ezret ajánlanak. És van szintén nem sok, de a 100-as ajánlatoknál azért jóval több, akik mondjuk 25, 32 meg hasonló fizetéssel hirdetnek.

És ugyanazt a tudást várják el, nem az van, hogy az egyik tapasztalt a másik meg junior. Mindegyik helyen elvárják az sok év tapasztalatot meg felsorolják, hogy mit még. Nincs olyan különbség, ami megmagyarázná az eltérő díjazást.

Na én pl. nem szokam jelentkezni a 25-ös meg 32-es ajánlatokra.

Viszont van úgy, hogy a) nem írják bele, az ember jelentkezik, aztán kiderül, hogy ja, valójában én a 2 vagy 3-szorosát gondoltam.
b) megkérdik, mi a fizetési igényed, végigtolnak 3-4-5 kör interjút, és a végén azt mondják, hogy OK, felvennének, de valójában ők a fizetési igényednél 10-20 ezerrel kevesebbre gondoltak. És nem azért, mert úgy találják, hogy nem vagy elég senior, csak mert nekik ez illik az üzleti modelljükbe.

"Ne vágd rá rögtön valamire, hogy nem tudod."
Dehogyem. Egy mérnök számára elemi fontosságú dolog annak bevallása, hogy nem tud valamit. Nincs ezzel semmi baj, senki nem tudhat mindent. Sokkal jobb dolog bevallani valamiről, hogy nem tudod, mintha azt mondaná, hogy tudja, majd besül vele. Ha valaki valamit nem tud, mondja meg egyenesen, ne kerteljen.

Ettől még el lehet vele beszélgetni egy problémáról, sőt! Az a jó, ha azt mondja, hogy nem tudja. Ekkor elkezdhetitek körbejárni a problémát, és megnézni, hogy hogyan tudná megoldani. Ebből jobban le lehet mérni a problémamegoldó képességet, mint abból, hogy azt szondázod, hogy milyen tényanyagot ismer a jelentkező.

+1

Engem is az érdekelne, hogy egy számára ismeretlen dologgal mit kezd.

+1
Egyből ki lehet szúrni ha linkel a jelentkező.

Én itt juniorokkal foglalkozom, feljönnek néha olyan alapvető vagy összetettebb fogalmak amiket nem ismernek. Ahelyett, hogy beismernék, hogy nem tudják inkább próbálnak úgy tenni mintha tudnák. És nem, nem rágugliznak csendben hanem elkezdenek tippelgetni. Rabolva ezzel a saját és az én időmet is.

Az "annak bevallása" számomra valami büntetőjogi kategóriára hajaz. ;)

Ha valaki valamit nem tud - persze nem az, aki mindent nem tud ;) - az akár egy biztos tudásról is árulkodhat. Hiszen pontosan tudja, mi az, amit nem tud.

Ennek a fordítottja, amikor valaminek a megismerés közben felmerül a kérdés: Tudsz-e már kérdezni?
Ugye, amikor még az ismeretek begyűjtésének a kezdeténél tartasz, akkor nem tudsz még kérdezni.
Tehát még azt sem tudod, hogy mit nem tudsz.

Klasszikus módszer megmondani egyenesen, hogy nem tudom, DE így is így próbálnám meg, bár ez ezértazért nem jó megoldás mégsem... és ha látják, hogy logikusan gondolkozol a témában az felér egy helyes válasszal, mert látszik benned a potenciál arra, hogy képes vagy boldogulni. És itt is ugyanúgy kiszűrhető az ha valaki kamuzik és csak megjátsza az egészet.

Persze ez függ attól is, hogy junior vagy senior poziba keresnek. Szerintem ezt egy senior már kevésbé engedheti meg magának. De ha tévednék fixme.

Szerintem tévedsz, mert az IT bármely részhalmaza lassan már kimeríthetetlen tudást tartalmaz egy emberöltő alatt.

sziasztok, itt utólag módosítottam a 9. pontot erre: Ne zárd le a kérdést annyival, hogy nem tudod.

itt az a lényeg, hogy sokszor kaptam már olyan választ, hogy nem tudom. Ilyenkor nehéz kapcsolódni vagy folytatni a beszélgetést úgy, hogy ne érezze magát senki butának.

Akkor a helyes válasz:
- Nem tudom. Hogyan kell? :)

* Nem tudom. De így is így kezdenék neki.

Ez ugyanaz. Én úgy kezdek neki, hogy megkérdezem. :P

Szerintem nem problema, ha a jelolt azt valaszolja, hogy nem tudja, sot. Igazabol ott kezdodik a lenyeg, hogy ezutan mit tesz. Ugysem feltetlenul arra vagyok kivancsi, amit esetleg mar bemagolt/fejbol tud, hanem hogy olyan esetben, amikor nincs keznel a konzerv megoldas, hogyan all neki a problemanak.

sub

+1

Hát visszagondolva sajnálom én, mint felvételiző, hogy raboltam a felvételiztetők idejét egyszer.
Az interjú első 15 percében teljesen világossá vált számomra az, hogy nem fogom elfogadni az ajánlatukat bármennyit is fizetnek, mert a szakmai tudásuk a béka feneke alatt van és nem én akarok lenni az orákulum aki az egész csapatot felhúzza, mert egyelőre én jobbak, tapasztaltabbak közé vágyódom vagy ami rosszabb nem akartam egy olyan csapatba kerülni ahol a régmúlt eljárásokat követik és tűzzel-vassal irtanak minden újító, innovatív ötletet.
Szóval kb 10-15p után általánosságban kezdtünk el beszélgetni, hogy mit hogyan csinálnék én és milyen lehetőségek lennének a munka felgyorsítására, a folyamatok átszervezésére. Nem borítottam rájuk az asztalt, mert 1-2 napot még aludni akartam rá, de másnap délelőtt már megüzentem, hogy nem érdekel a pozíció.

Azóta nem hallottam felőlük, remélem nem vették zokon hanem inkább megfogadták ezeket.

7.: Ennek az is feltetele, hogy ne kerdezz olyat, amire ez a valasz.
Mondjuk egy adott nyelven egy konkret fuggveny parameterezesere szerintem tokeletes valasz a "fingom sincs, rakeresek", nem is varnek mast. Foleg, ha az illeto nem Java-only, hanem 5-10 nyelvet mar hasznalt aktivan. Csak hogy teszteld magadat: szeretned megkapni egy string egy darabkajat adott karaktertol adott hosszon keresztul. Mondjuk valassz ki 5 nyelvet, es add meg a fuggveny nevet, hogy tenyleg fuggveny-e, vagy a string class metodusa, illetve hogy a lezarasnal az index inkluziv-e, es a darabszam vagy az utolso index kell-e neki. (jo, ez persze elojon, az a resze nem igaz)

A masik resze a dolognak: elektronikabol meg szoktak tanitani ellenallasok szigma-delta kapcsolasanak atalakitasat. Apunak (villanymernok) a gyakorlatban sose kellett, ugy ment nyugdijba. Ennek ellenere sok helyen vizsgakerdes, mert konnyu ellenorizni (es mert aki tanitja, annak sokszor nincs gyakorlati tapasztalata).

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

ezek béna kérdések \-:

Ketsegtelen. Interjuztatni nem egyszeru, ezt is meg kell tanulni, es amig nem tudsz, addig lehet, hogy hulyeseget is kerdezel.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Jó, hát aki függvényreferenciát kérdez interjún, az igazából mire kiváncsi?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mondjuk ennyire nem, csak hasonlo hulyeseget mar kerdeztek tolem regen. A reszletekre mar nem emlekszem, de valami ket teljesen ossze nem tartozo dolgot akart velem union all-lal osszerakatni egy sql lekerdezesben.
Szerintem olyankor jonnek elo ilyenek, amikor a kerdezonek nincs rutinja, es 5 perccel korabban szoltak neki, hogy ugorjon mar be.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin