Avagy jó interjú kérdések is léteznek

Az egyik ismerősöm olyan cégnél járt műszaki interjún, ahol igencsak ismerték a dörgést, és a standard bölcs kérdéseken kívül (milyen állat lennél, mi a 3 legrosszabb tulajdonságod, stb) értelmeset is tudtak kérdezni.

Még mielőtt belevágnék, egy fontos dolog: műszaki pozícióra SEM elég műszakilag jónak lenni. Egyéb készségek is vannak, amelyek a 21. században elengedhetetlenek egy fontos munka elvégzéséhez. Pl. soft skillek, kommunikáció, multikultúrális tapasztalat.

Szóval akkor a kérdések:

Kérdés: Mi a különbség a taktikai és a stratégia fejlesztő között?
Válasz: A taktikai fejlesztés gyakorlatilag a napi problémák kezelése, azaz hibajavitás, illetve kisebb változáskérelmek. A fejlesztőnek képesnek kell lennie egy nem általa irt, már létező kódhoz úgy hozzányúlni, hogy az működőképes maradjon. Minden azonnal kell.
A stratégiai fejlesztés az maga a projekt munka: metodológia követése, dokumentáció, alapos tervezés és minőségi kivitelezés.

Kérdés: Mi a különbség a rendszer és a termék között? Mitől lesz a termék termék?
Válasz: A termék attól termék, hogy piaci igényt elégit ki (pl. dokumentum kezelés), azaz alapvetően több ügyfél által is használható. Általában rendszerfejlesztésnél egy adott ügyfél igényei alapján szaladunk (hiszen ő fizeti a fejlesztést), és ez nem lesz termék.

Kérdés: Hogyan érhetsz el nagyfokú ügyfél elégedettséget?
Válasz: Ha azt szállítjuk le, amit akart, úgy ahogy akarta, akkor amikorra kellett, annyiért amennyiért kellett. Illetve arra törekszünk, hogy ennél jobbak legyünk.
A kérdést sokféleképpen meg lehet válaszolni, a megfogalmazás rávilágít a jelölt hátterére és tudására. Például egy programozó arra gondol, hogy a kód határidőre jó minőségben elkészüljön, és átmenjen a teszten.

Kérdés: Hogyan vonnád be jobban a projektbe az ügyfelet? Hogyan tennéd érdekeltté a projektben?
Válasz: Fogós kérdés, és műszaki tudás nem elég a megválaszolásához.
Eleve ott kezdődik a probléma, hogy mikor fordulhat elő az a paradox helyzet, amikor az ügyfél (aki megrendelte a projektet) nem érdekelt abban a projektben, amit megrendelt.
Több esetben is előfordulhat ilyen: például a projektben résztvevők nem értenek egyet a menedzsmenttel, aki megrendelte a munkát. Vagy ha az ügyfélnek fontos a projekt, de amúgy nem ér rá vele foglalkozni, mert más dolga van.
A részvétel úgy fokozható, ha egyrészt teljes transzparenciát biztosítunk (státusz meeting-ek, reportok), másrészt pedig az egyes fázisokat az ügyfél jóváhagyásához kötjük. Nem azért kell a tervdokumentumot aláíratni az ügyféllel, mert műszakilag hozzászólna a benne lévőkhöz, hanem hogy érezze a dolog komolyságát.

Kérdés: Mi teszi sikeressé a fejlesztést?
Válasz: Nincs egyetlen jó válasz. Jó csapat, szakemberek, jó manager, jó szervezés, jó kommunikáció, a metodológia követése, gyors reagálás, hosszú tervezés (ez utóbbi kettő ellentmondás, de mégis jó válasz), stb stb
A jelölt tapasztalatainak felmérésére jó a kérdés. Például a jelölt olyan projektben vett részt, ahol a végén vita volt az ügyfél és a vállalkozó között a követelményekről, ekkor a jelölt bizonyára a siker zálogának a jó specifikációt látja.

Kérdés: Mi teszi sikeressé a (software fejlesztési) innovációt? Mi volt az eddigi legsikeresebb innovációja és mi tette sikeressé?
Válasz: Újabb nyitott kérdés - az innováció alatt bármit érthetünk. Az innovációt a sok-sok szorgos munka teszi sikeressé.
A jelöltnek erre a kérdésre illik kapásból mondania valamilyen innovációs projektet, amiben részt vett vagy látott, szóval amolyan „elég tapasztalt vagy-e" jellegű kérdés.

Kérdés: Hogyan javíthatod a minőséget?
Válasz: Trükkös kérdés, azt próbálja meg felderíteni, a jelölt milyen beosztásban gondolkodik. Egy fejlesztő teljesen másképp javíthatja a minőséget, mint egy tesztelő, egy rendszerszervező, egy alsó vezető vagy egy középvezető. Az is kérdés, hogy ügyfél vagy vállalkozó oldalon ülünk-e: ügyfél oldalon a magas standard-ek számonkérése, míg vállalkozó oldalon a standard-ok teljesítése a fontosabb.

Kérdés: Hogyan motiválnád a beosztottakat?
Válasz: Újabb beugratós kérdés. Minden ember más, mindenkit másképp kell motiválni. Aztán vannak olyan beosztások, ahol nem is kell motiválni a beosztottakat (pl. egy risk managertől azt a választ várnám, hogy „vagy megszokik, vagy megszökik")
Ha mindenképpen motivációs módszert kell mondani, akkor arra elég sok létezik, meg kell néhányat említeni. Alapvetően kétféle van: a beosztottban azt erősítjük, hogy jó neki itt dolgozni (pl fizetés, jó csapat, elismertség, pozitív visszacsatolás, önmegvalósítás), illetve hogy jót tesz a karrierjének (training, tanulási lehetőség, jól mutat az önéletrajzban, külföldi kiküldetés).

Kérdés: Mit tennél, ha valamelyik programozó nem úgy teljesít, ahogy elvárható pl. rendre nem csinál unit test-eket?
Válasz: A managerek nagykönyve erre az esetre azt írja, hogy le kell ülni beszélgetni a programozóval, és meghallgatni amit mond. Feltehetőleg ki fogja bökni, hogy mi a baja, vagy legalábbis az önérzete javul és jobban fog koncentrálni.
(A placebohatás itt is működik)

Kérdés: Mit teszel, ha valakivel nem tudsz együtt dolgozni?
Válasz: Az emberek különbözőek, simán előfordul, hogy valakivel nem vagy egy hullámhosszon. Csakhogy az informatika csapatmunka, tehát lehet hogy nem szimpi az illető, de együtt kell tudni vele dolgozni (főleg ha mondjuk ő az ügyfél). Szóval nincs olyan, hogy valakivel ne tudnál együtt dolgozni.
Tipikus olyan kérdés, amire van egy jó válasz, megtanulod és kész.