Nem tűnik furcsának számodra, hogy amikor munkahelyet váltasz, és felmerül az igény, hogy átmenj egy interjún, az első dolog, amire gondolsz, hogy „fel kell készülnöd az interjúra”. Oldja meg a HackerRank problémáit, olvassa el a kódolási interjú feltörését, jegyezze meg, hogyan működik az ArrayList, és miben különbözik a LinkedListtől. Igen, kérdezhetnek a válogatásról is, és nyilvánvalóan nem lenne szakszerű azt mondani, hogy a gyors válogatás lenne a legjobb választás.
De várj, napi 8 órát programozsz, érdekes és nem triviális problémákat oldasz meg, és az új munkahelyeden ugyanezt fogod csinálni, plusz-mínusz. Mindazonáltal ahhoz, hogy átmenjen egy interjún, valahogyan fel kell készülnie, még csak nem is csiszolnia kell napi készségeit, hanem meg kell tanulnia valamit, amire a jelenlegi munkahelyén nem volt szüksége, és valószínűleg nem lesz szüksége a következőre. Arra az ellenvetésedre, hogy a számítástechnika a vérünkben van, és ha felébresztesz minket az éjszaka közepén, kötelesek vagyunk csukott szemmel egy párnahuzaton írni egy sétát egy fa szélességében anélkül, hogy eszmélethez térnénk, azt fogom válaszolni, hogy ha kapok munkát a cirkuszban, és a lényeg, hogy a trükk pontosan ez lenne - akkor talán igen, egyetértek. Ezt a képességet tesztelni kell.
De miért teszteli azokat a készségeket, amelyek irrelevánsak a jelenlegi munkája szempontjából? Csak mert divat lett? Mert a Google csinálja ezt? Vagy azért, mert a leendő csapatvezetőnek meg kellett tanulnia az összes válogatási módszert az interjú előtt, és most úgy gondolja, hogy „minden jó programozónak fejből kell tudnia a palindrom megtalálásának megvalósítását egy karakterláncban”.
Nos, te nem vagy a Google (c). Amit a Google megengedhet magának, azt a hétköznapi cégek nem. A Google az alkalmazottak adatait elemezve arra a következtetésre jutott, hogy az olimpiai háttérrel rendelkező mérnökök jól megbirkóznak konkrét feladataival. Sőt, a kiválasztási folyamat megtervezésével megengedhetik maguknak, hogy vállalják azt a kockázatot, hogy esetleg nem vesznek fel néhány jó mérnököt, mert nem tudják könnyen megoldani a matematikai feladatokat. De ez nekik nem probléma, sokan vannak, akik a Google-nál szeretnének dolgozni, az állás megszűnik.
Most nézzünk ki az ablakon, és ha az irodája előtt még nem állítottak fel sátortábort az Önnél dolgozni akaró mérnökök, és a fejlesztői gyakrabban keresik a stackoverflow-t, hogy mit kell telepíteni a következő tavaszi annotációra, a rangsorolási algoritmusok bonyolultsága helyett, úgy tűnik, itt az ideje, hogy elgondolkodjon azon, hogy lemásolja-e a Google-t.
Nos, ha ezúttal a Google kudarcot vallott, és nem adott választ, mit kell tennie? Ellenőrizze, hogy a fejlesztő pontosan mit fog tenni a munkahelyén. Mit értékelsz a fejlesztőkben?
Határozzon meg kritériumokat arra vonatkozóan, hogy kit szeretne felvenni, és dolgozzon ki teszteket, amelyek pontosan ezeket a készségeket tesztelik.
ThoughtWorks
Mi köze ehhez a ThoughtWorks-nek? Itt találtam példát egy modellinterjúra magamnak. Kik azok a ThoughtWorks-ek? Röviden, ez egy csúcskategóriás tanácsadó cég, amely Kínától, Szingapúrtól az amerikai kontinensekig a világ minden táján irodákkal rendelkezik, és mintegy 25 éve tanácsad a fejlesztés területén, saját Science részleggel rendelkezik, melynek vezetője Martin. Madarász. Ha 10 kötelező könyvet keresel egy szoftvermérnök számára, akkor ezek közül 2-3-at a ThoughtWorks srácai írnak majd, mint például a Refactoring by Martin Fowler és a Building Microservices: Designing Fine-Grained Systems by Sam. Newman vagy Building Evolutionary Architectures
szerző: Patrick Kua, Rebecca Parsons, Neal Ford.
A cég tevékenysége meglehetősen drága szolgáltatások nyújtására épül, de a megrendelő fizet a fenomenális minőségért, ami szakértelemből, belső normákból és természetesen emberekből áll. Ezért itt létfontosságú a megfelelő emberek alkalmazása.
Milyen embereknek van igazuk? Természetesen mindenki számára más. A ThoughtWorks megállapította, hogy a fejlesztői üzleti modelljük legfontosabb kritériumai a következők:
- Párban fejlődő képesség. Ez képesség, nem tapasztalat vagy készség. Senki sem számít arra, hogy olyanok is eljönnek, akik 5 éve gyakorolják a páros programozást, de a mások véleményére való fogékonyság és meghallgatás elengedhetetlen készség.
- Képes teszteket írni, és ideális esetben gyakorolni a TDD-t
- Értse a SOLID-ot és az OOP-t, és tudja alkalmazni őket.
- Mutassa be véleményét. Tanácsadóként együtt kell működni az ügyfél fejlesztőivel, más tanácsadókkal, és nem sok haszna van annak, ha az ember tud valamit jól csinálni, de azt teljesen képtelen átadni a csapat többi tagjának.
Most fontos, hogy értékeljük ezeket a készségeket a jelöltben. És itt a ThoughtWorks interjúval kapcsolatos tapasztalataimról szeretnék beszélni. Azonnal elmondom, hogy Szingapúrba mentem, és sikeresen átmentem, de a toborzási folyamat egységes, és nem nagyon fog különbözni országonként.
0. szakasz. HR
Ahogy az lenni szokott, egy 20 perces interjú a HR-rel. Nem részletezem, csak annyit, hogy még nem találkoztam olyan HR-essel, aki 15 percet tudott volna beszélni a cég fejlesztési kultúrájáról, miért használnak TDD-t, miért páros programozást. Általában a HR-esek elhervadnak ebben a kérdésben, és azt mondják, hogy a folyamat normális: a fejlesztők fejlesztenek, a tesztelők tesztelnek, a vezetők vezetnek.
1. szakasz. Mennyire vagy jó az OOP, TDD-ben?
1.5 órával az interjú kezdete előtt kaptam egy feladatot, hogy készítsek egy Mars Rover szimulátort.
Marsjáró küldetésA NASA egy csapat robotjárót leszáll a Mars egyik fennsíkra. Ezen a furcsa téglalap alakú fennsíkon a rovereknek kell navigálniuk, hogy fedélzeti kameráik teljes képet kapjanak a környező terepre, hogy visszaküldjék a Földre. A rover helyzetét és elhelyezkedését x és y koordináták kombinációja, valamint a négy fő iránytű egyikét képviselő betű jelzi. A fennsík egy rácsra van osztva a navigáció egyszerűsítése érdekében. Példahelyzet lehet 0, 0, N, ami azt jelenti, hogy a rover a bal alsó sarokban van és észak felé néz. Egy rover irányításához a NASA egy egyszerű betűsort küld. A lehetséges betűk az 'L', 'R' és 'M'. Az „L” és „R” 90 fokkal balra vagy jobbra forog a rover, anélkül, hogy elmozdulna az aktuális helyéről. Az „M” azt jelenti, hogy egy rácsponttal előre kell lépni, és ugyanazt a címsort tartani.
Tegyük fel, hogy az (x, y)-tól közvetlenül északra eső négyzet (x, y+1).
BEMENET:
Az első beviteli sor a fennsík jobb felső koordinátái, a bal alsó koordinátákat 0,0-nak feltételezzük.
A bemenet többi része a telepített roverekre vonatkozó információ. Minden rovernek két bemeneti sora van. Az első sor a rover helyzetét adja meg, a második sor pedig egy utasítássorozat, amely elmondja a rovernek, hogyan fedezze fel a fennsíkot. A pozíció két egész számból és egy szóközzel elválasztott betűből áll, amelyek megfelelnek az x és y koordinátáknak és a rover irányának.
Minden rover szekvenciálisan elkészül, ami azt jelenti, hogy a második rover addig nem kezd el mozogni, amíg az első be nem fejezi a mozgást.
OUTPUT:
Az egyes rover kimenetének a végső koordinátáit és irányát kell megadnia.
MEGJEGYZÉSEK:
Egyszerűen hajtsa végre a fenti követelményeket, és egységtesztek megírásával igazolja, hogy a porszívó működik.
A felhasználói felület bármilyen formájának létrehozása nem tartozik a hatáskörébe.
Előnyben részesítjük a probléma megoldását a TDD (Test Driven Development) megközelítéssel.
A rendelkezésre álló rövid időn belül inkább a minőségre törekszünk, mint a teljességre.
*Nem tudom közzétenni a nekem küldött feladatot, ez egy régi, több éve adott feladat. De hidd el, alapvetően minden marad a régiben.
Külön szeretném felhívni a figyelmet az értékelési szempontokra. Hányszor találkozott már olyan helyzettel, amikor egy jelölt számára fontos dolgok teljesen lényegtelenek az audit során és fordítva. Nem mindenki gondolkodik ugyanúgy, mint te, de sokan el tudják fogadni és követni tudják az értékeidet, ha egyértelműen megfogalmazzák. Az értékelési szempontokból tehát azonnal kiderül, hogy ebben a szakaszban a legfontosabb készségek
- TDD;
- OOP használatának és karbantartható kód írásának képessége;
- páros programozási képességek
Ezért figyelmeztettek, hogy azt a 1.5 órát arra kell gondolnom, hogyan fogom elvégezni a feladatot, ahelyett, hogy kódot írnék. Együtt írjuk meg a kódot.
Amikor telefonáltunk, a srácok röviden elmondták, kik ők és mit csinálnak, és felajánlották, hogy elkezdjük a fejlesztést.
Az egész interjú alatt egyszer sem volt olyan érzésem, hogy interjút készítenek. Van egy olyan érzés, hogy egy csapatban fejleszti a kódot. Ha elakadsz valahol, segítenek, tanácsot adnak, megbeszélnek, még vitatkoznak is egymással, hogyan lehetne a legjobban csinálni. Az interjún elfelejtettem, hogyan kell ellenőrizni a JUnit 5-ben, hogy egy metódus kivételt ad-e, felajánlották, hogy folytatják a tesztírást, miközben egyikük guglizott, hogyan kell csinálni.
Szó szerint néhány órával az interjú után konstruktív visszajelzést kaptam – mi tetszett és mi nem. Az én esetemben dicséretet kaptam, amiért a Sealed osztályokat használtam a null objektum alternatívájaként; azért, mert a kód megírása előtt pszeudokódban leírtam, hogyan szeretném irányítani a rovert, és így kaptam egy vázlatot az osztályokról, legalábbis azokról, amelyek részt vesznek a robot API-jában.
2. lépés: Mondja el nekünk
Egy héttel az interjú előtt felkértek, hogy készítsek egy prezentációt bármilyen témában, amely érdekel. A formátum egyszerű és ismerős: 15 perc prezentáció, 15 perc kérdések megválaszolása.
A Tiszta építészetet választottam Bob bácsitól. És ismét interjút készítettem pár emberrel. Ez volt az első élményem az angol nyelvű előadással, és talán ha stresszes helyzetbe kerültem volna, nem tudtam volna megbirkózni. De még egyszer sem volt olyan érzésem, hogy egy interjún vagyok. Minden a szokásos módon zajlik – mondom nekik, figyelmesen hallgatnak. Még a hagyományos kérdezz-felelek szekció sem volt olyan, mint egy interjú, egyértelmű volt, hogy a kérdéseket nem „süllyeszteni” tették fel, hanem azokat, amelyek igazán érdekelték őket az előadásomban.
Néhány órával az interjú után visszajelzést kaptam - az előadás nagyon hasznos volt, és nagyon élvezték hallgatni.
3. szakasz. Termelési minőségi kód
Figyelmeztetve, hogy ez a technikai interjúk utolsó szakasza, megkértek, hogy otthon hozzam gyártáskész állapotba a kódot, majd küldjem el a kódot felülvizsgálatra, és ütemezzem be az interjúkat, amelyeknél a feladat követelményei megváltoznak, és a kód módosítást igényelnek. Előre tekintve elmondhatom, hogy a kódellenőrzés vakon zajlik, a bírálók nem tudják, hogy a jelölt milyen pozícióra pályázik, nem látják az önéletrajzát, még a nevét sem látják.
Megszólalt a telefon, és megint volt pár srác a monitor másik oldalán. Minden ugyanaz, mint az első interjún: a legfontosabb, hogy ne feledkezz meg a TDD-ről, mondd el, mit csinálsz és miért. Ha még nem gyakoroltad a TDD-t, akkor azt javaslom, hogy azonnal kezdd el, de nem azért, mert a cégeknél ez szükséges, hanem azért, mert jelentősen leegyszerűsíti az életed, csökkenti a stresszszinted, ha úgy tetszik. Emlékszel, hogyan kellett eszeveszetten keresgélni egy hibakeresővel egy olyan hibát, amely csak a böngészőn keresztül reprodukálható, de tesztekkel nem? Most képzelje el, hogy el kell kapnia egy ilyen hibát egy interjú során - garantáltan néhány ősz hajszál lesz. Mit kapunk a TDD-vel? Megváltoztattuk a kódot, és váratlanul rájöttünk, hogy most pirosak a tesztek, de mi az a hiba, amit nem tudunk először kideríteni? Rendben, azt mondjuk a kérdezőbiztosoknak, hogy „Hoppá”, nyomjuk meg a Ctrl-Z billentyűket, és kis lépésekkel kezdünk előre haladni. És igen, ki kell fejlesztened magadban a fejlődési képességet a TDD használatával, azt a képességet, hogy a cél felé haladj, hogy a tesztjeid tartósan zöldek legyenek, és ne fél napig pirosak legyenek, mert "nagyon sok a refaktorálásod". Ez pontosan ugyanaz a készség, mint karbantartható kód írása vagy produktív kód írása.
Tehát az, hogy mennyire jól módosítható a kód, attól függ, hogy milyen tervezésre gondolsz először, mennyire egyszerű, és mennyire jók a tesztek.
Az interjú után néhány órán belül visszajelzést kaptam. Ebben a szakaszban rájöttem, hogy már majdnem túl vagyok, és már nagyon kevés volt hátra, amíg „találkoztam Fowlerrel”.
4. szakasz. Döntő. Elég a technikai kérdésekből. Tudni akarjuk, ki vagy!
Hogy őszinte legyek, kissé meglepett a kérdés ilyen megfogalmazása. Hogyan lehet megérteni, milyen ember vagyok egyórás beszélgetés alatt? És még inkább, hogyan lehet ezt megérteni, amikor olyan nyelven beszélek, amely nem az anyanyelvem, és őszintén szólva, nagyon silány és nyelves. A korábbi interjúk során nekem személy szerint könnyebb volt beszélni, mint kérdésekre válaszolni, és az akcentus volt a hibás. A kérdezőbiztosok közül legalább az egyik ázsiai volt – és az akcentusuk, mondjuk úgy, valamennyire az európai fülre jellemző. Ezért úgy döntöttem, hogy proaktív megközelítést alkalmazok – készítek egy prezentációt magamról, és az interjú elején felajánlom, hogy ezzel az előadással magamról beszélek. Ha beleegyeznek, akkor legalább kevesebb kérdés merül fel bennem, ha visszautasítják az ajánlatot, hát nem olyan nagy ár az életemből egy prezentációra fordított 3 óra. De mit írjon az előadásába? Életrajz - Ott született, akkoriban, iskolába járt, egyetemet végzett - de kit érdekel?
Ha a Google-ben egy kicsit a Thoughtworks kultúrájáról, talál egy cikket Martin Fowlertől [https://martinfowler.com/bliki/ThreePillars.html], amely leírja a 3 pillért: Fenntartható üzlet, szoftverek kiválósága és társadalmi igazságosság.
Tegyük fel, hogy a Software Excellence-t már ellenőrizték nálam. Marad a Fenntartható üzlet és a társadalmi igazságosság bemutatása.
Sőt, úgy döntöttem, hogy az utóbbira koncentrálok.
Először is elmondtam neki, hogy miért a ThoughtWorks – még a főiskolán olvastam Martin Fowler blogját, ezért szeretem a Clean kódot.
A projektek különböző szemszögekből is bemutathatók. Olyan szoftvereket is kifejlesztett az orvostudomány számára, amelyek leegyszerűsítették a betegek életét, sőt a pletykák szerint egy életet is megmentettek. A bankok számára is fejlesztettem szoftvert, ami szintén megkönnyítette az állampolgárok életét. Főleg, ha ezt a bankot az ország lakosságának 70%-a használja. Ez nem a Sberbankról és még csak nem is Oroszországról szól.
Akarsz tudni rólam? RENDBEN. Hobbim a fotózás, így vagy úgy, vagy 10 éve tartok a kezemben egy fényképezőgépet, vannak fényképek, amiket nem szégyellem megmutatni. Valamint egy időben egy macskamenhelynek is segítettem: olyan macskákat fotóztam, akiknek állandó otthonra volt szükségük. És jó fényképekkel sokkal könnyebb elhelyezni egy macskát. Valószínűleg száz macskát fotóztam :)
Végül az előadásom 80%-a macskákkal volt tele.
A prezentáció után azonnal azt írta nekem a HR, hogy még nem tudja az interjú eredményét, de már az egész iroda le volt nyűgözve a macskáktól.
Végül a visszajelzésekre vártam – emberként mindenkit elégedett voltam.
De az utolsó beszélgetés során a HR tapintatosan azt mondta, hogy a társadalmi igazságosság nagyon jó és szükséges, de nem minden projekt ilyen. És megkérdezte, hogy nem félek-e tőle. Általában egy kicsit túlzásba vittem a társadalmi igazságosságot, előfordul :)
Teljes
Ennek eredményeként több hónapja dolgozom Szingapúrban, a Thoughtworks-nél, és úgy látom, hogy itt túl sok cég alkalmazza a Google „best interjúk gyakorlatát”, leveleket és Whiteboardot használ a kódoláshoz, annak ellenére, hogy több tudással rendelkezik, mint a tavasz. Symfony, RubyOnRails (Húzd alá, ami szükséges) nem kötelező a munkában. A mérnökök egy hét szünetet tartanak az interjú előtt, hogy „felkészüljenek”.
A Thoughtworks-nél a jelölttel szemben támasztott megfelelő követelmények mellett a következő elvek állnak az élen:
Az interjú öröme. Ráadásul mindkét félnek. Valóban, ha a legjobb személyzetet szeretné megszerezni (és ki nem?), akkor az interjú nem egy piac, ahol rabszolgákat választanak, hanem egy műsor, ahol a munkaadó és a jelölt értékeli egymást. És ha egy jelölt kellemes érzelmeket társít egy céghez, akkor valószínűleg ezt a céget fogja választani
Több kérdező az elfogultság enyhítésére. A Thoughtworks-nél a páros programozás a de facto szabvány. És ha ez a gyakorlat más területeken is alkalmazható, a TW megpróbálja ezt megtenni. Az interjút minden szakaszban 2 fő végzi. Így minden személyt legalább 8 ember értékel, és a TW különböző hátterű, eltérő irányzatú (nem csak technikusok) és nemű kérdezőbiztosokat próbál kiválasztani.
Végső soron legalább 8 fő véleménye alapján születik meg a felvételi döntés, és senkinek nincs döntő szavazata.
Tulajdonság alapú felvétel Ahelyett, hogy a jelölt tetszése vagy nemtetszése alapján döntene, minden szerephez és minden szakaszhoz egy űrlapot dolgoznak ki, amely tartalmazza az értékelendő tulajdonságokat. Ugyanakkor az értékelés során erősen ajánlott nem egy bizonyos készségben szerzett tapasztalatot, hanem annak alkalmazási képességét értékelni. Így, ha egy jelölt nem volt képes alkalmazni semmilyen készséget, például a TDD-t, de ennek ellenére megpróbálja alkalmazni, meghallgatja a helyes alkalmazási tanácsokat, akkor minden esélye megvan az interjún.
Végzettségi bizonyítvány nem szükséges A TW nem igényel számítástechnikai bizonyítványt vagy oktatást. Csak a képességeket értékelik.
Ez az első olyan külföldi cégekkel készült interjú, amelyre nem kellett felkészülnem. Egy-egy szakasz után nem éreztem magam kimerültnek, ellenkezőleg, örültem, hogy alkalmazhattam a legjobb gyakorlatokat, hogy a monitor túloldalán lévők értékelték és alkalmazzák minden nap.
Több hónap után elmondhatom, hogy az elvárásaim teljes mértékben beváltottak. Miben különbözik a ThoughtWorks egy hagyományos cégtől? Egy rendes társaságban lehet találni jó fejlesztőket és kedves embereket, de a TW-ben a koncentrációjuk lemaradt a listáról.
Ha érdekel a ThoughtWorks-hez való csatlakozás, megtekintheti nyitott pozícióinkat
Azt is javaslom, hogy figyeljen az érdekes állásokra:
Vezető szoftvermérnök: , , ,
Vezető szoftvermérnök: , , ,
Szoftvermérnök: , ,
Vezető adatmérnök:
Minőségi elemző:
Infrastruktúra: , ,
(Őszintén figyelmeztetlek, hogy a link egy ajánló link, ha a TW-re mész, kapok egy szép bónuszt). Válassz egy neked tetsző irodát, nem kell Európára korlátozódnod, elvégre 2 évente a TW szívesen költöztet másik országba, mert... ez a ThoughtWorks politikájának része, így a kultúra elterjedt és homogenizálódik.
Nyugodtan tegyen fel kérdéseket a megjegyzésekben, vagy kérjen ajánlásokat.
Ha érdekesnek tűnik a téma, akkor írok arról, milyen a ThoughtWorksnél dolgozni, és milyen az élet Szingapúrban.
Forrás: will.com