Egy korábbi cikkünkben már írtunk arról, hogy milyen soft skill-ek kellenek a sikeres fejlesztői interjúhoz. Most viszont inkább a szakmai részre fektetjük a hangsúlyt. Azokra a hibákra szeretném felhívni a figyelmet, amelyekkel interjúztatóként találkoztam és amelyeket leggyakrabban elkövetnek a fejlesztők az interjúk során.

Megnézünk néhány valós példát, amelyet hozzánk jelentkező fejlesztők produkáltak. Az Innonic felvételi folyamata során többször is kell a jelentkezőknek programozni. Van, hogy teljesen önállóan. Van, hogy az interjúztatóval közösen oldanak meg egy feladatot. Mindkét változatra fogunk példát nézni.

Még mielőtt belekezdünk, szeretném leszögezni, hogy a cél nem az, hogy viccet csináljunk a jelöltekből. Sokkal inkább segítséget szeretnék nyújtani, hogy jobb lehess a következő interjúdon és te már ne kövesd el ezeket a hibákat. Illetve Te is jobban megértsd, hogy miket figyelnek a cégek egy-egy kódolási feladat során.

Otthoni teszt feladat

Az interjú egyik legfontosabb lépése a kódolás. Már egy egyszerű kódolási feladat is sokat segít abban, hogy jobban megértsük a fejlesztő gondolkodásmódját és tapasztalati szintjét.

A legelső programozási feladat, amivel a jelentkezők szembesülnek egy otthoni teendő. Mi ugyanis hiszünk abban, hogy a jelöltek jobban tudnak otthon, nyugodt körülmények között a feladatra koncentrálni, mint az interjú alatt. Így a határidő is lehet nagyobb, de a feladatok is összetettebbek.

Nézzük, mi is volt pontosan a feladat:

Írj egy programot, ami megfordítja a betűket az input mondat szavaiban. Minden sor legalább egy szót tartalmaz. Minden szó legalább egy karakterből áll és csak az angol ABC kis betűit tartalmazza.

A sorokat a stdin-ről kell beolvasni és stdout-re kell a kimenetet megjeleníteni.

Input:

word1 word2 word3

another sentence

Output:

1drow 2drow 3drow

rehtona ecnetnes

Szerintem egyetérthetünk abban, hogy ez nem egy különösebben nehéz feladat. Egy senior fejlesztő kb. 5 perc alatt meg tudja oldani. Nézzük meg, hogy milyen megoldások születtek a jelöltektől és miket lehet ezekből leszűrni.

1. példa: Senior fejlesztő

Az első példa legyen egy helyes megoldás. Az első bíztató jel az volt, hogy már 3 perc alatt sikerült megoldania a jelöltnek.

Vessünk egy pillantást a kódra:

Ezt a kódot könnyű megérteni, csupán csak egy pár sor, a változó nevek is beszédesek. Okosan is használja a beépített függvényeket. Természetesen ez nem azt jelenti, hogy azonnal fel kell venni a jelöltet, de az látszik, hogy megvan az alap kódolási tudása és ismeri a PHP programozási nyelvet.

2. példa: Junior fejlesztő

Ez a megoldás már kicsit komplexebb, de még mindig érthető. A változó nevek és függvény nevek itt is beszédesek. Junior fejlesztők általában hosszabb kódot írnak, mivel nem ismerik a beépített függvényeket.

3. példa: A több nem mindig jobb

A következő példa az egyik legemlékezetesebb interjú életem során. A jelöltnek érdekes gondolkodása volt, ami a kódján meg is látszódik.

Első ránézésre mondhatnád, hogy nincs semmi gond ezzel a kóddal. Szépen formázott és dokumentált. Könnyen olvasható és rendezett.

De emlékezz, hogy a korábbi példákban ugyanezt a problémát pár sorban megoldották.

Másodszor, miért OO? Ez a tipikus példája annak, amikor procedurális programozást OO mögé rejtenek. Nincs semmi előnye az osztályok használatának. Nem is OO a kód, nincs öröklődés, nincs egységbe zárás és a single responsibility elv alapján csak a reverseSentences-nek kellene publikusnak lennie.

Harmadszor, ez egy nagyon lassú megoldás. Sokkal lassabban fut le, mint a korábbi megoldások.

4. példa: Nem tudom mi az a STDIN

Másik gyakori hiba, hogy a jelöltek nem tudják mi az STDIN és egyszerűen csak kihagyják ezt és beleégetnek egy teszt szöveget a kódba.

Habár a logika helyes és szinte minden rendben van leszámítva azt, hogy “elfelejtette” a STDIN-t használni.

A tapasztalat az, hogy ilyen esetben a fejlesztő híján van az alapvető operációs rendszerek ismeretének és elvéreznek az interjú későbbi szakaszában. Ez általában annak köszönhető, hogy nincs meg a megfelelő tapasztalatuk és nem magabiztosak a Linux/Unix rendszerekben. Ami elengedhetetlen egy web fejlesztő számára, hiszen a kódok 99% ilyen rendszereken fut.

5. példa: Nem tudom megoldani

Sajnos számos olyan eset is van, amikor senior fejlesztőn akár egy ilyen egyszerű kódolási feladat is kifog, és kb. ilyen “megoldást” produkálnak.

Természetesen megértem, hogy a példa nem gyakorlatias. Valószínűleg soha nem kell ilyen működést éles környezetben programozni. Azt is tudjuk, hogy az interjú stresszes és nem tudják a jelöltek a 100%-os formájukat hozni. Azonban, aki ilyen feladatokat nem tud megoldani, nem tud tovább jutni az interjún. Ha valaki fejlesztői interjúra készül, akkor szükséges a gyakorlás, hogy az ilyen nem ideális körülmények között is a lehető legjobb formáját tudja nyújtani. Javaslom még a papíron való programozás gyakorlását is, habár nálunk gépen kell programozni, de sok cég még mindig elvárja a jelöltektől, hogy papíron vagy táblán programozzanak az interjú során.

Pair coding az interjúztatóval

Az interjú másik fontos része, amikor az interjúztatóval közösen kell megoldani egy feladatot. Ez sokkal inkább egy párbeszéd, mint csak kódolás. Ez a feladat segít megérteni a jelentkező gondolkodás módját.

Nézzük meg az erre használt teszt feladat egyikét:

Írj egy függvényt, amely paraméterül kap egy tömböt és a visszatérési értéke a tömb elemei duplikációk nélkül.

Azaz egy array unique függvényt kell írni.

A feladat megoldása itt sem különösebben bonyolult, viszont a kereszt kérdéseken sokan elvéreznek.

1. példa: Nem tudom mi az időkomplexitás

Ez az egyik leggyakoribb hiányosság. Az időkomplexitás fogalma egy fejlesztő számára elengedhetetlen. Enélkül nem tudod megmondani, hogy a két kód közül melyik a gyorsabb:

Persze ki lehet mérni a kódot teszt adatokkal, de egy fejlesztő, aki ránézésre meg tudja ezt mondani, sokkal hatékonyabb tud lenni.

Ez egyike annak a ritka dolgoknak, amit egyetemen tanítanak, de a munka során is nap mint nap használni fogod.

Egyébként a helyes megoldás az arrayUnique1, mert annak az idő komplexitás O(n), míg az arrayUnique2-nek O(n^2).

2. példa: Biztonságos kód írása

A biztonságos kód írásának fontossága nem lehet kérdés senki számára. Azonban mégis sok olyan jelölttel találkozunk, akik az alapokat sem ismerik. SQL injection, CSRF, XSS a leggyakoribb sebezhetőségek. Ezek ismerete nélkülözhetetlen.

Gyakori kérdés nálunk a biztonságos jelszó tárolása vagy jelszó emlékeztető hash generálása.

Nézzünk az utóbbira egy példát:

A fenti kód egy függvényből lett kiemelve. Első ránézésre itt is minden rendben van. SHA256 egy biztonságos hash, sokkal jobb alternatíva mint a már elavult MD5. Kezelve van az esetleges duplikálódó hash is. A probléma a microtime().rand(1000,9999) résznél van. A microtime egyáltalán nem random, nagyon jól kiszámítható, hogy milyen értékeket vehet fel. A rand(1000,9999) pedig túl kicsi intervallum. Ez jelentősen megkönnyiti a brute force támadás lehetőségét.

A helyes megoldás így néz ki:

Ez semmilyen támpontot nem ad az esetleges támadónak és kénytelen 2^256-on lehetőséget végigpróbálni.

Összefoglaló

Ahogy látható, nagyon sok mindenre kell odafigyelni a kódolási feladat során. Mint azt már említettem, az interjú egy stresszes helyzet, ahol a jelöltek nem tudnak 100%-os teljesítményt produkálni. Ezt figyelembe véve, nem is várunk el hibátlan feladatmegoldást. Teljesen természetes, hogy az interjú során hibákat vét egy jelölt vagy nem tud valamit. Ezért is született ez a cikk, hogy mások hibájából tanulva segítsen téged a felkészülésben.

Ha úgy érzed, hogy készen állsz az állásinterjúnkra, akkor nézd meg nyitott pozícióinkat és küldd el önéletrajzod!

Ha még többet szeretnél tanulni karrierépítésről, és arról, hogy hogyan nyerheted el álmaid pozícióját, olvasd el ingyenesen letölthető tanulmányunkat, amiből megtanulod a sikeres állásinterjú minden fortélyát.