1.1 Az első napok – amit senki nem mond el előre
Áttekintő
Az első munkanapod előtt valószínűleg rengeteg mindent tudsz már: hogyan kell változókat deklarálni, mi az OOP, talán még egy-két framework-öt is ismersz. De valami hiányzik – és ezt az egyetem, a bootcamp, a YouTube tutorialok egyike sem tanítja meg neked.
Ez az alfejezet arról szól, ami az első héten valójában történni fog. Nem a kód oldaláról, hanem az emberi, szervezeti, és munkahelyi valóság oldaláról. Az a fejlesztő, aki erre fel van készülve, sokkal gyorsabban illeszkedik be, kevesebbet szenved, és hamarabb válik értékes csapattaggá.
Mit tanulsz meg ebben az alfejezetben:
- Miért sokkoló szinte minden junior fejlesztőnek az első hét
- Miben tér el élesen a valódi munkahely az egyetemi / bootcamp környezettől
- Mit érdemes az első héten megfigyelni, kérdezni – és mikor kell csendben maradni
- Hogyan kezeld az elvárásokat (a sajátodat és a munkáltatóét)
Miért számít ez az állásinterjún? A legtöbb behavioral interjú kérdés erre az időszakra vonatkozik: „Mesélj egy helyzetről, amikor új környezetbe kerültél." Ha tudod, mi vár rád, hitelesen tudod majd elmesélni, hogyan alkalmazkodtál.
Miért számít ez az első munkahelyen? Az első 90 nap meghatározza, hogy milyen fejlesztőnek ismer meg a csapat. Ez a benyomás nehezen változik – érdemes tudatosan alakítani.
Részletes leírás
A valóság-sokkról őszintén
Szinte minden junior fejlesztő ugyanazt mondja az első hetéről:
„Nem gondoltam, hogy ennyire más lesz."
Ez nem azért van, mert felkészületlen voltál. Hanem azért, mert az oktatási környezet és a valódi munkahely két teljesen különböző világ – és senki nem szokta előre elmondani, miben.
Nézzük meg pontosan, miben.
1. Az elvárások valósága
Az egyetemen / bootcampen:
- Van egy feladat, van egy megoldás, van egy határidő
- Ha kész vagy, „megfeleltél"
- A feladatot valaki előre megtervezte neked
- Az eredmény általában jól definiált
A valódi munkahelyen:
- A feladatnak gyakran nincs egyetlen „helyes" megoldása
- A „kész" definíciója változó és vitatható
- Senki nem tervezi meg előre, mit csinálsz holnap
- Az eredményt üzleti igény, technikai korlátok, csapatkonszenzus és néha véletlenek alakítják
Ez azt jelenti, hogy az első időszakban bizonytalanságban fogsz dolgozni – és ez teljesen normális. A tapasztalt fejlesztők is ezt csinálják, csak már nem félnek tőle.
Mit csinálj ilyenkor: Ne próbálj mindent azonnal megérteni. Az első héten a célod az, hogy térképet rajzolj – nem az, hogy már megismerd az összes utcát.
2. A ritmus különbsége
Az egyetemen / bootcampen:
- Projektek heteken-hónapokon át tartanak
- Az értékelés időpontja ismert
- A tempót te szabod meg
A valódi munkahelyen:
- Sprint-alapú fejlesztésnél 2 hetente zárulnak a ciklusok
- Naponta standup meeting – amit csináltál, látható a csapat előtt
- Párhuzamosan fut: kód írás, review-k, meetingek, adminisztráció
- Valaki mindig vár rád (vagy te vársz valakire)
Az első héten sok junior fejlesztő meglepődik, hogy mennyire kevés idő jut ténylegesen kódolásra. Ez nem hiba – ez a munkahely természete.
Mit csinálj ilyenkor: Ne lepődj meg, ha az első napokban szinte semmit nem kódolsz. Onboarding, gépbeállítás, hozzáférések, meetingek – ez is munka.
3. Az önállóság foka
Ez az egyik legnagyobb sokk.
Az egyetemen / bootcampen:
- Van egy tanár / mentor, aki segít
- Van megoldás a feladathoz (sokszor elérhető)
- A hibád következménye: rosszabb jegy
A valódi munkahelyen:
- A senior kollégáid elfoglaltak – nem ülnek melletted egész nap
- A hibád következménye: akadhat elromlott production, elégedetlen ügyfél, éjszakai riasztás
- Ugyanakkor elvárják, hogy önállóan próbálkozz, mielőtt kérdezel
Ez a kettősség – „legyél önálló, de kérdezz ha kell" – az egyik legnehezebb egyensúly junior fejlesztőként. Erre külön alfejezet foglalkozik (1.3), de már most fontos tudni: mindkét szélsőség probléma.
Ha soha nem kérdezel → napokig elakadsz, és a csapat sem tud segíteni.
Ha minden apróságra kérdezel → irritálod a kollégákat, és bizalmatlanságot keltesz.
Mit csinálj ilyenkor: Az arany szabály: 30-60 perc önálló próbálkozás, utána kérdezz – de strukturált kérdéssel. Erről bővebben a 1.3 alfejezetben.
4. A kódbázis valósága
Az oktatásban:
- Tiszta, frissen írt kód
- Te írtad, te érted
- Nincs „legacy" – minden logikus
A valódi munkahelyen:
- A kódbázis lehet 5-15 éves
- Tele van olyan döntésekkel, amiknek nem látod az okát
- Előfordulnak kommentek nélküli, rejtélyes megoldások
- Valaki egyszer valamiért így csinálta – és most senki nem emlékszik, miért
Ez nem a cég hozzá nem értése. Ez az iparág természete. Minden nagy kódbázis ilyen. A tapasztalt fejlesztők sem értik az összes részt – csak már nem ijednek meg tőle.
Mit csinálj ilyenkor: Ne akarj mindent megérteni az első héten. Fogadd el, hogy vannak ismeretlen területek – és fokozatosan térképezd fel őket. Tartsd meg a felfedezési naplódat (erről lejjebb).
5. A dokumentáció hiánya
Az oktatásban:
- Minden le van írva a feladatleírásban
- Ha valami nem egyértelmű, kérdezd a tanárt
A valódi munkahelyen:
- A dokumentáció általában részleges, elavult, vagy nem létezik
- A „dokumentáció" sokszor maga a kód
- A tudás fejekben van – „kérdezd meg XY-t, ő tudja"
Ez normális. Nem azt jelenti, hogy a cég rossz. Azt jelenti, hogy a fejlesztői munka egy élő, változó folyamat, és a dokumentáció mindig lemarad.
Mit csinálj ilyenkor: Az első hetedben: vezess onboarding naplót. Írj le mindent, amit megtanulsz – telepítési lépéseket, furcsaságokat, ki mire szakosodott. Egyrészt neked hasznos, másrészt egy idő után ezt felajánlhatod a csapatnak dokumentációként. Azonnal értékes taggá válsz tőle.
6. A csapat dinamika
Az oktatásban:
- Csapatmunka = projektfeladat + értékelés
- Mindenki egyforma szerepben van
A valódi munkahelyen:
- Különböző tapasztalati szintek, különböző felelősségek
- Vannak informális rangsorok, amik nem látszanak az org chartban
- Vannak régi konfliktusok, amiket nem ismersz
- Van, aki hangos és magabiztos, de nincs mindig igaza – és fordítva
Az első héten hallgatni és megfigyelni fontosabb, mint megszólalni. Nem azért, mert nincs értékes mondanivalód, hanem mert még nincs elég kontextusod ahhoz, hogy jól helyezd el a mondanivalódat.
Mit érdemes az első héten csinálni – konkrétan
Megfigyelni:
- Ki kivel kommunikál szívesen?
- Ki a technikai döntéshozó?
- Mi a csapat hangulata? (feszült? laza? lelkes?)
- Hogyan zajlanak a meetingek? Ki szól, ki hallgat?
- Mi az, amit mindenki frusztrálónak talál?
Kérdezni:
- „Mi a legfontosabb dolog, amit az első hónapban meg kell tanulnom?"
- „Mire lesz szükségem a napi munkához?" (hozzáférések, eszközök)
- „Kihez fordulhatok ha X típusú kérdésem van?"
- „Van valami, amit te tudnál, ami nekem az első hónapban sokat segítene?"
Nem csinálni:
- Ne adj javaslatot, hogy „ezt jobban is lehetne csinálni" – még nem látod a teljes képet
- Ne hasonlítsd hangosan a jelenlegi céget az előzőhöz / az iskolához
- Ne ígérj olyat, amiben nem vagy biztos
Életszerű példák
Példa 1: A „miért így van megírva?" csapda
Szituáció:
Dávid az első hetén nézi át a kódbázist. Talál egy helyet, ahol egy 200 soros if-else lánc van, komment nélkül, furcsán elnevezett változókkal. Hangosan megjegyzi a standupon: „Ezt teljesen újra kellene írni, ez olvashatatlan."
Mi történt:
A senior fejlesztő csendben megnéz Dávidra. Aztán megmagyarázza: ezt a részt 3 éve valaki megpróbálta refaktorálni, és 2 hetes productionban lévő hibaáradatot okozott. Azóta „nyúlj hozzá és meghalsz" zóna, amíg a refactor komoly tesztkörnyezettel nincs alátámasztva.
Mit tanulunk:
Minden furcsaság mögött valószínűleg van egy történet. Kérdezz, mielőtt ítélkezel.
Példa 2: Az önállósági csapda
Szituáció:
Anna az első napján kap egy feladatot: „Nézd meg, miért lassú ez az API endpoint." Senki nem mondja el, hogyan csinálja. Anna egész nap próbálkozik, de nem mer kérdezni, mert „nem akar buta lenni". Estére semmit nem talált, és rosszul érzi magát.
Mi történt:
A feladat teljesen normális junior feladat volt, de elvárta, hogy Anna ismerje a cég saját logging rendszerét, amit senki nem mutatott meg neki. Egy 10 perces kérdéssel megkaphatta volna a szükséges kontextust.
Mit tanulunk:
Nem kérdezni nem bátorság – kár. Kérdezni nem gyengeség – hatékonyság.
Példa 3: Az onboarding napló ereje
Szituáció:
Péter az első napjától vezet egy privát .md fájlt a gépén: „mit kellett telepíteni", „mi volt zavaros a setupban", „ki mivel foglalkozik". A 3. héten egy új kolléga csatlakozik a csapathoz. Péter megosztja az onboarding naplóját. A csapatvezető megkéri, hogy formalizálják és tegyék fel a wiki-re.
Mi történt:
Péter az első hónapban értékes dokumentációt produkált – nem azzal, hogy nagy kódot írt, hanem azzal, hogy feljegyezte, amit megtanult.
Mit tanulunk:
Az onboarding napló nemcsak neked hasznos – a csapatnak is érték.
Példa 4: A „miért nem kaptam feladatot?" pánik
Szituáció:
Zsófia az első napján vár, hogy feladatot kapjon. Délután 3-ig senki nem szól hozzá. Pánikba esik: „Nem kellek ide?"
Mi valójában történt:
A csapatvezető éppen egy kritikus buggal volt elfoglalva. Zsófia onboarding-ja „holnapra" csúszott. Senki nem kommunikálta ezt.
Mit tanulunk:
Az első napon az „üresjárat" normális. Ilyenkor kérdezd meg nyugodtan: „Mit tudok most csinálni, amíg megkapom az első feladatot?" – és keress visszajelzést proaktívan.
Gyakorlati feladat
„Az első heted" forgatókönyv
Az alábbi szituációkra írj rövid választ (2-5 mondat): mit tennél, és miért? Nincs egyetlen helyes megoldás – a gondolkodásmód számít.
Szituáció A:
Hétfő reggel 9 óra, első munkanapod. Leülsz a gépedhez, a csapatvezető azt mondja: „Telepíts fel mindent, aztán nézd át a kódbázist, én egy meetingen vagyok egész délelőtt." Nem adott több instrukciót. Mit csinálsz?
Szituáció B:
Megkaptad az első „igazi" feladatodat: egy kisebb bugfixet. Elkezded, de 45 perc után teljesen elakadsz – nem érted, hogyan épül fel az adott modul. Mit csinálsz? Mit nem csinálsz?
Szituáció C:
A standupon a csapatvezető megkérdezi: „Hogyan haladtál tegnap?" Te tegnap főleg dokumentációt olvastál és próbáltál mindent megérteni, de nem írtál egyetlen sor kódot sem. Mit mondasz?
Szituáció D:
Észreveszed, hogy a kódbázisban van egy rész, ahol szerinted jobb megoldás létezne. Egy kolléga éppen mellette ül. Megszólítod?
Javaslatok a feladathoz:
Szituáció A: Kezdd el felírni, mit kell telepíteni (onboarding napló!). Ha valami nem egyértelmű a setupban, jelöld meg kérdőjelekkel. Ha valóban elakadsz, várj a csapatvezetőre, vagy kérdezz egy másik kollégától – de ne töltsd az egész délelőttöt passzívan.
Szituáció B: 45 perc után kérdezz – de strukturált kérdéssel: „Ennél a modulnál akadtam el, ezt és ezt próbáltam, de nem értem, hogyan kapcsolódik X és Y. Tudsz 5 percet szánni rá?" Ne kérdezz anélkül, hogy megmutasd, mit próbáltál már.
Szituáció C: Mondd el őszintén: „Tegnap főleg az onboardingra és a kódbázis megismerésére fókuszáltam, kódot nem írtam, de megértettem X és Y részt." Ez nem szégyen – ez munka. Senki nem vár az első héten production-ready kódot.
Szituáció D: Az első héten: valószínűleg nem. Tegyél fel egy kérdést inkább: „Érdekesnek találom ezt a részt – van valami oka, hogy így lett megvalósítva?" Kérdés formájában sokkal jobban fogadják, mint javaslatként.
Tesztfeladatok
1. kérdés (Igaz/Hamis)
„Az első héten a legfontosabb az, hogy minél több kódot írj, hogy megmutasd az értékedet."
A) Igaz
B) Hamis
Helyes válasz: B – Hamis
Magyarázat: Az első héten a legfontosabb a beilleszkedés, a kontextus megszerzése és a csapat megismerése. Az értéket nem kódsorok mennyiségével mérik, hanem azzal, hogyan illeszkedsz be a csapatba és hogyan haladod meg az elvárásokat fokozatosan. A kódolásra hamarosan lesz idő.
2. kérdés (Feleletválasztós)
Az első napod délelőttjén a csapatvezető egész nap meetingen van, nem kaptál konkrét feladatot. Mit tegyél?
A) Ülj és várd, amíg valaki megszólít – nem akarod zavarni senkit
B) Kezdd el önállóan feltérképezni a kódbázist, vezess onboarding naplót, és ha elakadsz, kérdezz egy elérhetőbb kollégától
C) Menj haza – nincs feladatod, nincs értelme maradni
D) Azonnal küldj emailt a csapatvezetőnek, hogy nincs mit csinálnod
Helyes válasz: B
Magyarázat: Az önálló kezdeményezés és az onboarding napló vezetése értékes tevékenység. Az A válasz passzív – az üresjáratot proaktívan kell kezelni. A C és D túlreagálás.
3. kérdés (Feleletválasztós)
A kódbázisban találsz egy furcsán megírt részt, amit nem értesz. Mi az első lépésed?
A) Azonnal refaktorálod, mert láthatóan rossz kód
B) Feljegyzed az onboarding naplódba, és megkérdezed a kontextust egy kollégatól
C) Jelented a csapatvezetőnek, hogy problémát találtál
D) Figyelmen kívül hagyod – nem a te dolgod
Helyes válasz: B
Magyarázat: Minden furcsaság mögött lehet egy szándékos döntés, amelynek kontextusa nem látható a kódból. Kérdezz, mielőtt ítélkezel. Refaktorálni – különösen az első héten – kockázatos és elhamarkodott.
4. kérdés (Igaz/Hamis)
„Ha az első héten nem kérdezek, azzal megmutatom, hogy önálló és kompetens vagyok."
A) Igaz
B) Hamis
Helyes válasz: B – Hamis
Magyarázat: A soha-nem-kérdező fejlesztő nem tűnik kompetensebbnek – éppen ellenkezőleg. Napokig elakadhat, és a csapat sem tud segíteni rajta. A jó kérdés (megfelelő időben, megfelelő kontextussal) a kompetencia jele, nem a gyengeségé.
5. kérdés (Párosítás)
Párosítsd össze a szituációt a legjobb reakcióval:
| Szituáció | Reakció |
|---|---|
| A) Nem értesz egy feladatot | 1. Hallgatsz és figyelsz |
| B) Furcsán megírt kódot találsz | 2. Kérdezed a kontextust |
| C) Senior kolléga technikai döntést hoz, amivel nem értesz egyet | 3. 30-60 perc próbálkozás után strukturált kérdést teszel fel |
| D) Első meetingen mindenki vitatkozik egy technikai témáról | 4. Feljegyzel és megkérdezed a hátteret |
Helyes párosítás: A–3, B–4, C–2, D–1
Magyarázat:
- A feladatnál előbb próbálkozz önállóan, csak aztán kérdezz (A–3)
- Furcsa kódnál ne ítélkezz, kérdezd a háttértörténetet (B–4)
- Ha nem értesz egyet, kérdezd meg az okot – ez nem vitatkozás, hanem tanulás (C–2)
- Első meetinget inkább figyelj, mint szólj hozzá (D–1)
6. kérdés (Feleletválasztós)
A standupon a csapatvezető megkérdezi: „Mi blokkolja a haladásodat?" Az igazság az, hogy tegnap egész nap elakadtál, és lényegében semmit nem haladtál. Mit mondasz?
A) „Semmi, minden megy, holnapra kész lesz"
B) „Elakadtam X-nél, próbáltam Y és Z megoldást, de nem sikerült – segítségre lenne szükségem"
C) „Nem tudom, egyszerűen nem ment"
D) „Túl sok volt a meeting, ezért nem tudtam haladni"
Helyes válasz: B
Magyarázat: Az A hazugság – és hamar kiderül. A C és D nem ad elég információt, és a C passzív. A B pontos, strukturált, és lehetőséget ad a csapatnak, hogy segítsen. A jó blocker-kommunikáció egyik legfontosabb junior készség.
7. kérdés (Igaz/Hamis)
„Az onboarding napló vezetése felesleges adminisztrációs teher, amit senki nem vár el egy junior fejlesztőtől."
A) Igaz
B) Hamis
Helyes válasz: B – Hamis
Magyarázat: Az onboarding napló az egyik leghasznosabb dolog, amit az első héten csinálhatsz. Neked megkönnyíti a beilleszkedést, a csapatnak pedig értékes dokumentációvá válhat. Senki nem kéri tőled – de mindenki hálás lesz érte.
8. kérdés (Feleletválasztós)
Mi a legfontosabb különbség az oktatási és a valódi munkakörnyezet között junior fejlesztő szemszögéből?
A) Az oktatásban csak könnyű feladatok vannak, a valódi munkahelyen nehezek
B) Az oktatásban mindig van egy „helyes" megoldás és definiált elvárás; a valódi munkában a bizonytalanság, az önállóság és az emberi dinamika is részei a munkának
C) A valódi munkahely mindig stresszesebb, az oktatás mindig könnyebb
D) Az oktatásban nem kell csapatban dolgozni, a munkahelyen igen
Helyes válasz: B
Magyarázat: A lényegi különbség nem a nehézségi fokozatban van (A és C leegyszerűsítő), hanem abban, hogy a valódi munkában a feladatok nem jól definiáltak, a megoldás nem egyértelmű, és az emberi, szervezeti kontextus is a munka része. A D sem általánosan igaz.
9. kérdés (Szituációs)
Egy senior kollégád megkér, hogy „nézz át egy modult, hogy képben legyél". 2 óra után teljesen elveszve érzed magad – a modul hatalmas, nem érted a kontextust, és nem tudod, mit keressen a szemed. Mit csinálsz?
A) Folytatod a nézelődést, hátha egyszer csak értelme lesz
B) Visszamész a kollegához és megkérdezed: „Mire fókuszáljak a modulban? Mi a legfontosabb rész az én feladatom szempontjából?"
C) Jelented a csapatvezetőnek, hogy a feladat nem volt elég egyértelmű
D) Abbahagyod, mert ha a senior nem adott több instrukciót, valószínűleg nem is fontos
Helyes válasz: B
Magyarázat: A strukturált visszakérdezés produktív – fókuszt ad, és nem terheli feleslegesen a kollégát. Az A időpazarló. A C túlreagálás. A D helytelen feltételezés.
10. kérdés (Igaz/Hamis)
„Ha az első héten javaslatot teszel, hogy valamit másképp kellene csinálni, az megmutatja, hogy értékes és kezdeményező vagy."
A) Igaz
B) Általában hamis – az első héten még nincs elég kontextusod ahhoz, hogy jól helyezd el a javaslatot
Helyes válasz: B
Magyarázat: A kezdeményezőkészség értékes, de az első héten még hiányzik a kontextus. Ami kívülről rossz megoldásnak tűnik, lehet, hogy van mögötte egy jó oka. Kérdés formájában (pl. „Miért így van megvalósítva?") ugyanazt a kíváncsiságot fejezed ki – de nem keltesz felesleges feszültséget.
First Job Readiness Program – 1. fejezet: Munkahelyi soft skills fejlesztőknek
1.1 Az első napok – amit senki nem mond el előre