HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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.

Címkék: it interjú kérdések management

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr825211251

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Ismeretlen_112949 2009.09.25. 08:18:36

Hűha. Jót akartam és elrontottam, mert hagytam kalandozni az egeret a csillagok felett. Szóval. Nagyon tetszik a bejegyzés! Az előbbiek miatt 5 db csillagot szerettem volna adni, de mivel elügyetlenkedtem csak 3 lett belőle. :-( Ha valakinek módjában áll javítani, kérem tegye meg. Köszönöm.

Ismeretlen_6808 2009.09.26. 06:55:12

felet javítottam

attilak 2009.10.10. 21:52:15

> Kérdés: Hogyan vonnád be jobban a projektbe az ügyfelet? Hogyan tennéd érdekeltté a projektben? Esetleg kifejezett feladatokat kaphat az ugyfel a projektbol, vagy/es embereket delegalhat a kivitelezo csapatba. (es itt most elsosorban nem a specifikalasra gondolok)

attilak 2009.10.10. 22:02:34

Talaltam egy bejegyzest ahol a taktikai es strategiai fejleszto kozti kulonbseg jol reszletesen van taglalva: "Generally speaking, application development can be a slow process, it can involve long periods of analysis, design, implementation, testing, review etc with each stage done by different people and possibly different teams. These teams are usually setup to work on one project at a time and as such if they're currently working on a project the business may have to wait until this project has been delivered before the development team will even look at the new requirement. This is where Tactical developers come in. They are often experienced developers who have had exposure to all the stages of the development life cycle and are also at ease with the terminology and function of the business area for which they work. They can quickly develop an application which does the job the business requires until such a time that the application becomes an integral part of the business and a more robust version of the application is required. Generally, once a Tactical application is adopted by the business, incremental updates are made as they become necessary and if done properly the application will become more robust as updates are made to it and issues are identified by the business users. However, the theory goes that once a Tactical solution has been developed, and as it becomes more important to the business the process of redeveloping the Tactical application into a Strategic application should take place..." Forras: http://blog.radconsultant.com/