2.6 Technikai interjú felkészülés (nem LeetCode grinding)

Áttekintő

A technikai interjú az a pillanat, amikor a legtöbb junior fejlesztő beengedi a pánikot. Nem azért, mert nem tudják a választ – hanem mert nem tudják, mit várnak el tőlük valójában.

Spoiler: a legtöbb junior állásra nem bináris fa inverziót kell fejből megírnod. Az interjúztatók döntő többsége nem LeetCode-feladattal szűri a juniorokat. Amit keresnek az más: azt akarják látni, hogyan gondolkodol, hogyan kommunikálsz nyomás alatt, és képes vagy-e bevallani, ha valamit nem tudsz.

Ez az alfejezet nem azt tanítja meg, hogyan oldj meg 500 algoritmikus feladatot. Azt tanítja meg, hogyan viselkedj egy valódi technikai interjún – és miért fog ez fontosabb lenni, mint bármilyen algoritmus-tudás.

Részletes leírás

Milyen típusú technikai kérdéseket tesznek fel junioroknak?

Felejtsük el a mítoszt, hogy minden tech interjú egy FAANG-szintű algoritmus-maraton. A valóság sokkal prózaibb – és sokkal közelebb van ahhoz, amit már tudsz.

Jellemző junior technikai interjú kérdéstípusok:

1. Konceptuális kérdések (tudod-e, mi ez?)

Mi a különbség a GET és POST között?
Mi az OOP és mik az alappillérei?
Mit jelent a „null pointer"?
Mi az a verziókezelés és mire való?

Ezekre nincs „trap" – vagy tudod, vagy nem. Ha nem tudod, mondd meg becsületesen (erről később).

2. Kódolvasás (érted, amit látsz?) Kapsz egy kódrészletet és megkérdezik: mi ez csinál? Mi a hiba benne? Hogyan lehetne jobb?

Ez nem arról szól, hogy minden szintaxist fejből tudj – hanem hogy képes vagy-e logikusan nyomon követni egy kódot.

3. Mini feladatok (csináld meg, miközben figyellek) Nem egy összetett algoritmus. Inkább:

Írj egy függvényt, ami megfordít egy stringet
Hogyan ellenőriznéd, hogy egy szám prím?
Nézd meg ezt a kódot – mi a probléma?

4. Szituációs / problémamegoldó kérdések

Hogyan debuggolnád, ha egy API nem tér vissza adatot?
Ha egy oldal lassan tölt, hol kezded a vizsgálatot?
Hogyan szerveznéd meg a Git branch-eket egy csapatban?

Ezek a kérdések nem egyetlen helyes választ várnak – a gondolkodásod folyamatát nézik.

A technikai interjú három fő formátuma

Live coding (legelterjedtebb)

Valós időben kódolsz – vagy megosztott képernyőn, vagy egy online platformon (pl. CoderPad, HackerRank, Replit). Az interjúztató ott van és figyel.

Mit tesztelnek valójában? Nem a hibátlan megoldást. Azt, hogy hogyan kommunikálsz, kérsz-e segítséget ha elakadtál, és hogyan kezeled a nyomást.

Tipp: Mindig mondj hangosan mindent, amit csinálsz. „Most egy tömböt hozok létre, mert..." Ez mutatja, hogy gondolkodsz.

Take-home feladat (egyre népszerűbb)

Kapsz egy feladatot (általában 2-8 óra elvégzéséhez), amit otthon, saját tempódban végzel el. Majd visszaküldöd és megbeszélitek.

Mit tesztelnek valójában? A kód minőségét: olvasható-e, van-e README, kezeled-e a hibákat, írtál-e teszteket? A live codingtól eltérően itt az idő megvan – elvárnak magasabb minőséget.

Tipp: Írj README-t. Mindig. Egy mondatban magyarázd el, mit csináltál és hogyan futtatható. Ez önmagában kiemel a mezőnyből.

Whiteboard / elméleti interjú

Papíron, táblán vagy szóban fejted ki a gondolataidat – kód nélkül vagy vázlatos álkóddal. Klasszikusabb cégek használják.

Mit tesztelnek valójában? A logikai gondolkodásodat és a kommunikációdat. A szintaxis itt egyáltalán nem számít.

Tipp: Ha valamit nem tudsz pontosan, mondd el az elvét: „Nem emlékszem a pontos szintaxisra, de az elvem az, hogy..." Ez jobb, mint a csend.

Hogyan gondolkodj hangosan?

Ez az egyetlen legfontosabb technikai interjú készség, amit fejleszthetsz – és a legritkábban tanítják.

Miért számít? Az interjúztató nem a telepatiád képességét méri. Ha csendben gondolkozol, nem tudja követni a folyamatodat. Ha hangosan gondolkozol, látja, hogy szisztematikusan közelítesz a problémához – még ha a végeredmény nem is tökéletes.

Hangos gondolkodás lépései:

Értelmezd a feladatot hangosan

„Tehát arra kérnek, hogy... Jól értem? Van-e valamilyen korlát, amit figyelembe kell vennem?"

Sorolj fel példákat

„Ha a bemenet ez, akkor a kimenet ennek kellene lennie. Nézzük: 5-re... 0-ra... mi a helyzet negatív számokkal?"

Mondj el egy megközelítést, mielőtt kódolsz

„Az első ötletem egy egyszerű ciklus lenne, ami végigmegy az elemeken. Ez O(n) lenne. Ha gyorsabb kell, lehetne rendezni előtte, de az O(n log n)."

Kommentáld a kódolást

„Most definiálok egy változót az eredmény tárolásához... Ez azért kell, mert..."

Ellenőrizd hangosan

„Nézzük meg a saját példámon: ha 5-öt adok be... igen, 120-at ad vissza. Az jó. Mi a helyzet 0-val?"

Mit tegyél, ha nem tudod a választ?

Ez az a pillanat, ahol a legtöbb junior tönkreteszi az interjúját – nem azért, mert nem tudja a választ, hanem azért, ahogy kezeli a helyzetet.

Amit NE csinálj:

Ne hallgass és ne remélj, hogy valahogy megoldódik magától
Ne találj ki valamit, ami valószínűleg nem igaz
Ne mondj egyszerűen „nem tudom"-t és hagyd annyiban

Amit IGEN csinálj:

1. Ismerd be őszintén, majd mutasd meg, hogyan közelítenéd meg

„Ezt a konkrét dolgot nem ismerem részletesen, de próbáljuk meg logikával felépíteni. Ha jól értem az elvét, akkor..."

2. Mondj el rokon tudást

„Pontosan ezt nem tudom, de a hasonló X koncepcióban az Y úgy működik, hogy... Valószínűleg ez is hasonló elveket követ."

3. Kérdezz vissza intelligensen

„Nem volt még szükségem erre a konkrét eszközre, de kíváncsi vagyok – ebben a kontextusban mire szokták használni?"

Miért működik ez? Az interjúztató nem omniszcienciát vár. Azt nézi, hogyan viselkedsz nyomás alatt, és hogyan gondolkodol ismeretlen problémán. Egy becsületes „nem tudom, de így közelíteném meg" sokszor jobb benyomást kelt, mint egy magabiztosan elmondott téves válasz.

Mire figyelnek az interjúztatók valójában?

Megkérdeztem sok embert, aki juniorokat interjúztat. A válaszok meglepően egységesek:

1. Tanulóképesség jelei Nem azt kérdezik, tudod-e már. Azt kérdezik, meg tudnád-e tanulni. Aki a kérdésekre nyitottan reagál, kérdez vissza, és mutatja, hogy érti az összefüggéseket – az jelzi, hogy fejleszthető.

2. Kommunikáció nyomás alatt Hogyan viselkedsz, ha nem tudod a választ? Pánikba esel? Vagy nyugodtan, strukturáltan közelítesz? Ez a munkahelyi stresszhelyzetekben mutatott viselkedés előjele.

3. Kóddal való viszony, nem szintaxis-tudás Nem az számít, hogy fejből tudod-e minden metódus nevét. Az számít, hogy értesz-e egy kódrészletet, azonosítod-e a problémát, és logikusan gondolkozol-e a megoldásról.

4. Kulturális illeszkedés jelei „Meg tudunk-e dolgozni ezzel a személlyel?" Az interjúztató csapatba gondolkodik. Udvarias vagy? Nyitott a visszajelzésre? Kérdezel?

5. Önismeret A junior, aki tudja, mit nem tud, sokkal értékesebb, mint aki mindent tud (de valójában nem). „Ezt eddig nem csináltam, de szívesen megtanulom" – ez erős válasz.

A leggyakoribb technikai interjú hibák

Hiba #1: Fejest ugrás a kódolásba kérdezés nélkül Soha ne kezdj el kódolni, amíg nem tisztáztad a feladatot. Kérdezz rá az edge case-ekre, a korlátozásokra, a várható kimenetre.

Hiba #2: Csend Gondolkodj hangosan. Ha csend van, az interjúztató nem tudja, hogy gondolkodsz-e vagy elveszett vagy.

Hiba #3: A „tökéletes megoldásra" várni Mondj el egy működő megoldást először, majd javítsd. Egy lassabb, de működő megoldás jobb, mint egy soha el nem készülő tökéletes.

Hiba #4: Nem ellenőrizni a kódot Kódolás után mindig futtasd végig fejben a saját példádon. „Ha ezt adom be, ezt kapom vissza – ez jó?"

Hiba #5: Nem kérdezni Az interjúztató nem az ellenfeled. Ha elakadsz, kérhetsz egy kis segítséget: „Erre a részre van valami tipp, amibe kapaszkodhatok?"

Életszerű példák

Példa 1: A live coding szituáció

Feladat: „Írj egy függvényt, ami megadja, hogy egy szám prím-e."

Rossz megközelítés: A jelölt csendben gondolkodik 3 percig, majd elkezd gépelni. Nem mondja el, mit csinál. Befejezi, visszanéz a képernyőre, de nem teszteli. Az interjúztató nem tudja, mi volt az gondolati folyamat.

Jó megközelítés:

„Oké, prímszám: csak 1-gyel és önmagával osztható. Szóval végig kell mennem az összes számon 2-től n-1-ig és megnézni, hogy osztható-e valamelyikkel.

Várom – ha n = 4, akkor 4/2 = 2, tehát nem prím. Ha n = 7, 7/2 nem egész, 7/3 nem egész, 7/4, 7/5, 7/6 – egyik sem. Tehát prím. Jó.

Most kódban: [gépel] Egy ciklus 2-től n-1-ig. Ha n % i == 0, return false. Ha végigment, return true.

Tegyük próbára: n = 2... a ciklus el sem indul, return true – jó. n = 1... ez prím-e? Technikailag nem – kellene egy ellenőrzés az elején."

Ez a megközelítés sokkal több pozitív jelet küld, mint egy csendben írt tökéletes megoldás.

Példa 2: A „nem tudom" helyzet

Kérdés: „Mit tudsz a Redis-ről?"

Rossz válasz: Csend, vállvonás, „nem ismerem".

Közepes válasz: „Redis egy cache rendszer."

Jó válasz:

„Redissel részletesen még nem dolgoztam, de annyit tudok, hogy in-memory adattároló, tehát nagyon gyors. Általában cache-elésre és session kezelésre szokták használni. Ha jól értelmezem, azért hasznos, mert az adatbázis-hívásokat csökkenti, ha ugyanazokat az adatokat újra meg újra kellene lekérdezni. Ez jó irány?"

Ez mutatja, hogy még ismeretlen területen is logikusan tudsz gondolkodni és kapcsolódni meglévő tudásodhoz.

Példa 3: A take-home feladat értékelése

Két jelölt ugyanolyan működő megoldást ad be, de:

Jelölt A:

Kód működik
Nincs README
Változónevek: a, b, x, tmp
Nincs hibakezelés
Nincs teszt

Jelölt B:

Kód ugyanolyan szinten működik
README megmagyarázza a feladatot és a futtatást
Érthető változónevek
Kezeli a hiányos bemenet esetét
Van 3 egyszerű teszt

Ki kap visszahívást? Jelölt B – majdnem biztosan. Nem a kód bonyolultságától függ, hanem a professzionalizmus jeleitől.

Gyakorlati feladat: „Gondolkodj hangosan" gyakorlat

Ez a feladat egyedül is elvégezhető – de sokkal hatékonyabb, ha van valakit, aki hallgat (barát, mentor, kolléga, vagy akár egy képzeletbeli interjúztató).

A feladat

Vegyél egy egyszerű programozási feladatot (pl. az alábbiakból egyet), és mondd hangosan végig az egész gondolkodási folyamatodat a legelső pillanattól a végeredményig. Nem az a cél, hogy gyorsan megoldd – a cél, hogy ne legyen csend.

Javasolt feladatok (válassz egyet):

Írj egy függvényt, ami visszaadja egy lista elemeinek összegét anélkül, hogy beépített sum() / reduce() funkciót használnál.

Adott egy szöveg. Számolja meg, hány szó van benne. (Tipp: mire figyelj? Mi van, ha több szóköz van egymás után?)

Adott egy egész szám. Döntsd el, hogy páros vagy páratlan – de a % operátor és az osztás használata nélkül.

A folyamat, amit hangosan végig kell mondanod:

1. Feladat értelmezése (30 mp)

„Mit kér pontosan?"
„Mi a bemenet? Mi a kimenet?"
„Van-e különleges eset, amire figyelnem kell?"

2. Példák meghatározása (30 mp)

„Ha ezt adom be, ennek kellene kijönnie."
„Mi a helyzet üres bemenetnél? Negatív számnál? Null értéknél?"

3. Megközelítés (1-2 perc)

„Az első ötletem..."
„Ennek az előnye / hátránya..."
„Egy egyszerűbb megoldás lenne..."

4. Kódolás, hangos kommentárral

Minden sorhoz mondd el, mit és miért írsz

5. Ellenőrzés

Futtasd végig fejben a saját példádat
„Ha ezt adom be... igen, ez a jó eredmény."
„Mi a helyzet az edge case-szel?"

Értékelési szempontok:

Kérd meg a hallgatót (vagy értékeld magad visszajátszáskor):

[ ] Volt-e legalább 30 másodperces csend gondolkodásközben?
[ ] Kérdezte-e a feladat pontosítását mielőtt kódolni kezdett?
[ ] Mondott-e hangosan legalább egy edge case-t?
[ ] Ellenőrizte-e a kódot a megoldás után?
[ ] Ha elakadt – kért segítséget helyett a csendbe burkolózott?

Tesztfeladatok

1. kérdés

Interjún megkapsz egy feladatot: „Írj egy függvényt, ami megad minden páros számot 1 és N között." Mit teszel legelőször?

a) Elkezded gépelni a megoldást
b) Megkérdezed: „Az N-t bele kell-e számítani, ha páros?"
c) Megkérdezed, hogy melyik programozási nyelvet preferálják
d) Elmondod, hogy ezt már csináltad régebben

Helyes válasz: b

Magyarázat: Mielőtt kódolni kezdesz, mindig tisztázd a feladatot. Az N befoglalása vagy kizárása megváltoztatja a megoldást – és ha nem kérdezel, majd rosszul implementálod, az rosszabb benyomást kelt, mint egy egyszerű kérdés.

2. kérdés

Az interjúztatók által leginkább értékelt junior tulajdonság melyik az alábbiak közül?

a) Mindent tud fejből, nincs szüksége dokumentációra
b) Gyorsan kódol, keveset kommunikál
c) Becsületesen jelzi, ha valamit nem tud, és logikusan közelít az ismeretlen problémákhoz
d) Soha nem követ el hibát a kódolásban

Helyes válasz: c

Magyarázat: Seniorrá válni éveket vesz igénybe – az interjúztató ezt tudja. Ami számít: tanulható-e a jelölt, kommunikál-e jól, és őszinte-e. A c) választ leíró személy sokkal értékesebb csapattag lesz, mint egy „mindent tud" illúziót mutató jelölt.

3. kérdés

Melyik válasz a legjobb, ha az interjún olyan kérdést tesznek fel, amire nem tudod a pontos választ?

a) „Sajnos ezt nem tudom." (és csend)
b) Valószínűnek látszó választ adsz, bár nem vagy benne biztos
c) „Ezt pontosan nem ismerem, de az elvem az lenne, hogy... Közel járok?"
d) Kérsz egy percet és okostelefonon utánanézel

Helyes válasz: c

Magyarázat: Az a) túl rövid – nem mutat próbálkozást. A b) kockázatos – ha téved, az interjúztató tudja, és az elveszített bizalom rosszabb, mint az őszinte nem-tudom. A d) nem reális lehetőség. A c) mutatja az önismeretet ÉS a gondolkodási folyamatot.

4. kérdés

Live coding interjún a jelölt megoldja a feladatot, de az egész idő alatt csendben dolgozik. Mit jelent ez az interjúztató számára legvalószínűbben?

a) A jelölt nagyon koncentrált, ami pozitív jel
b) A jelölt nem tud kommunikálni munka közben, ami csapatmunkában problémás lehet
c) A jelölt bizonytalan és zavarba jönne, ha hangosan kellene gondolkodnia
d) A megoldás helyessége miatt nem számít a kommunikáció

Helyes válasz: b

Magyarázat: A csapatmunkában a kommunikáció a fejlesztő munkájának szerves része. Pair programming, code review, standup – mindenhol szükség van arra, hogy gondolataidat meg tudd osztani. A csendben dolgozó jelölt ezt a képességét nem demonstrálja.

5. kérdés

Take-home feladatnál melyik a legfontosabb különbség egy „jó" és egy „kiemelkedő" megoldás között (feltéve, hogy mindkettő működik)?

a) A kiemelkedő megoldás 2x gyorsabb algoritmust használ
b) A kiemelkedő megoldás több programozási nyelv funkcióit alkalmazza
c) A kiemelkedő megoldás olvasható kódot, README-t, hibakezelést és teszteket tartalmaz
d) A kiemelkedő megoldás nem használ könyvtárakat, mindent saját maga implementál

Helyes válasz: c

Magyarázat: Take-home feladatnál az időd megvan – az interjúztató production-minőséget vár. A README, hibakezelés és tesztek pontosan azok a dolgok, amik egy tutoriál-kódot production-ready kóddá tesznek. Ez mutatja, hogy tudod, mi a különbség.

6. kérdés

Melyik live coding magatartás a legrosszabb?

a) Lassan kódolsz, de minden lépést megmagyarázol
b) Kérsz segítséget, ha 5 perc után sem jut eszedbe semmi
c) Csendben gondolkodsz 10 percig, majd közlöd, hogy nem tudod
d) Elmondasz egy megközelítést, ami utólag nem a leghatékonyabb

Helyes válasz: c

Magyarázat: 10 perc csend után egy „nem tudom" a legrosszabb eredmény: sem a gondolkodásodat nem látta az interjúztató, sem a kérdezési képességedet. Az a), b), d) mind mutat valamit értékeset: strukturált gondolkodást, önismeretet, megközelítési készséget.

7. kérdés

Az interjúztató megkérdezi: „Hogyan debuggolnád, ha egy API-hívásod 404-et ad vissza?" Melyik válasz a legjobb?

a) „Megnézném az API dokumentációját."
b) „Valószínűleg a szerver hibája."
c) „Először ellenőrzöm, hogy a URL helyes-e. Ha igen, megnézem, hogy az endpoint létezik-e a dokumentációban. Ha az is stimmel, megnézem, hogy autentikáció szükséges-e és megvan-e. Végül megnézem a szerver-oldali logokat, ha hozzáférek."
d) „404 mindig azt jelenti, hogy az endpoint nem létezik."

Helyes válasz: c

Magyarázat: A c) mutatja a szisztematikus gondolkodást – lépésről lépésre haladva, az egyszerűbbtől a bonyolultabb felé. Az a) túl általános. A b) helytelen feltételezés (a 404 lehet kliensoldali hiba is). A d) egyszerűsítés – 404 lehet autentikációs probléma is bizonyos rendszerekben.

8. kérdés

Whiteboard interjún arra kérnek, hogy vázold fel egy webshop checkout folyamatát. Nem emlékszel pontosan, hogyan működik a fizetési gateway integráció. Mit teszel?

a) Kihagyod a fizetési részt és csak a többi lépést rajzolod fel
b) Megrajzolod a teljes folyamatot, beleértve a fizetési gateway-t, és jelzed: „Ezt a részt általánosítottam, a konkrét integrációt utána kellene néznem"
c) Bevallod, hogy nem tudsz whiteboard interjút csinálni
d) Biztosan rajzolod meg a fizetési gateway-t, bár valójában találgatsz

Helyes válasz: b

Magyarázat: A whiteboard interjún a gondolkodási folyamat és a big-picture látás számít. A b) megmutatja, hogy értesz a rendszer egészéhez, és önismereted van: tudod, hol van a tudásod határa. Ez sokkal erősebb jel, mint az a) (hiányos) vagy a d) (megtévesztő).

9. kérdés

Melyik állítás igaz a junior technikai interjúra?

a) Az interjúztatók elvárják, hogy fejből tudj minden adatstruktúrát és algoritmust
b) A legtöbb junior interjún LeetCode hard szintű feladatokat adnak
c) Ha nem oldod meg tökéletesen a feladatot, biztosan nem vesznek fel
d) A gondolkodási folyamat és a kommunikáció általában fontosabb, mint a tökéletes megoldás

Helyes válasz: d

Magyarázat: A junior szintű technikai interjúk alapvetően különböznek a senior vagy FAANG-típusú interjúktól. A legtöbb cég nem algoritmust méri junioroknál, hanem alapvető logikát, tanulóképességet és kommunikációt. Egy strukturáltan elmagyarázott helytelen megoldás sokszor jobb eredményt hoz, mint egy csendben megírt helyes megoldás.

10. kérdés

Az interjún megkérsz téged, hogy optimalizáld a megoldásodat. Azt mondod: „A jelenlegi megoldásom O(n²). Lehetne O(n log n)-re hozni rendezéssel, de én ezt a verziót hoznám be produkcióba, mert N várhatóan kicsi és az olvashatóság fontosabb." Mi az interjúztató valószínű reakciója?

a) Negatív – soha nem szabad elfogadni egy rosszabb komplexitású megoldást
b) Pozitív – mutatja, hogy trade-off-okban gondolkodsz, nem csak absztrakt algoritmusokban
c) Semleges – ők csak a megoldás helyességét nézik
d) Negatív – nem szabad megemlíteni a Big O notációt, ha nem kérdezik

Helyes válasz: b

Magyarázat: A „premature optimization is evil" elv a valódi fejlesztői gondolkodás alapja. Aki trade-off-okban gondolkodik – mi az előny, mi a hátrány, mikor éri meg – az azt mutatja, hogy valódi fejlesztői szemlélete van, nem csak elméleti tudása. Ez pontosan az, amit a legtöbb cég keres junioroknál.