Nem tűnik furcsának, hogy amikor munkahelyet szeretne váltani, és interjút kell tennie, elsőként azt gondolja: „fel kell készülni az interjúra”? Megoldani feladatokat a HackerRank-en, olvasni a Crack the Coding Interview-t, memorizálni, hogyan működik az ArrayList, és miben különbözik a LinkedList-től. Ja, és valószínűleg a rendezési algoritmusokról is kérdezhetnek, és nyilvánvalóan nem lenne szakmai, ha azt mondaná, hogy a quick sort valószínűleg a legjobb választás.
De álljon meg, hiszen napi 8 órában programozik, érdekes és nem triviális feladatokat old meg, és az új munkahelyén is nagyságrendileg ugyanazt fogja csinálni. Mégis, az interjúhoz valamilyen módon plusz felkészülés szükséges, nem is a napi készségek csiszolásával, hanem azzal, hogy megtanuljunk olyan dolgokat, amelyekre sem a jelenlegi munkahelyén, sem aligha lesz szüksége a következőnél. Azokkal az érvekkel, hogy a számítástechnika a vénánkban van, és ha éjjel felébresztenek, akkor is képesek vagyunk álomba merülve megírni a fa szélességi bejárását úgy, hogy közben eszméletünket sem veszítjük, azt válaszolom, hogy ha cirkuszba fognék menni, és a fő trükköm éppen ez lenne — akkor talán igen, egyetértek. El kell végezni ezt a készséget.
De miért kellene ellenőrizni a jelenlegi munkahelyhez nem kapcsolódó készségeket? Csak azért, mert divatos lett? Mert a Google így csinálja? Vagy mert a jövőbeli csapatvezetőjének meg kellett tanulnia az összes rendezési módszert az interjú előtt, és most úgy véli, hogy „minden jó programozónak tudnia kell a fejében a palindromok megtalálásának implementációját”.
Nos, ön nem a Google (c). Amit a Google megengedhet magának, azt a normál cégek nem tudják. A Google, elemezve alkalmazottai adatait, arra jutott, hogy éppen azok a mérnökök, akiknek olimpiai múltja van, képesek jól foglalkozni a konkrét feladataikkal. Sőt, az előválasztási folyamat kialakításakor jogosan be tudják építeni azt a kockázatot, hogy esetleg nem hiresztelnek fel néhány jó mérnököt azért, mert nem tudnak olyan könnyedén megoldani matematikai feladatokat. De számukra ez nem probléma, sokan akarnak a Google-nál dolgozni, a pozíció hamarosan betöltődik.
Most már nézzünk ki az ablakon, és ha még mindig mérnökök vannak az irodád előtt, akik nálad szeretnének dolgozni, és a fejlesztőid inkább a stackoverflow-n keresnek újabb spring annotációkat, mint a rangsorolási algoritmus finomságait, akkor valószínűleg itt az ideje elgondolkodni azon, hogy érdemes-e másolni a Google-t.
Jól van, ha most a Google nem adott választ, mit tegyünk? Ellenőrizzük pontosan azt, amit a fejlesztő a munkájában tesz. Mit értékelsz a fejlesztőkben?
Határozd meg a kritériumokat, hogy kit szeretnél alkalmazni, és készíts teszteket, amelyek pontosan ezeket a készségeket ellenőrzik.
ThoughtWorks
Mi köze ThoughtWorks-nek ehhez? Éppen itt találtam egy példaértékű interjút. Kik azok a ThoughtWorks? Röviden: egy high-end tanácsadó cég, amely az egész világon rendelkezik irodákkal, Kínától Szingapúron át az amerikai kontinensekig, és körülbelül 25 éve foglalkozik fejlesztési tanácsadással, illetve van saját tudományos részlegük, amelyet Martin Fowler vezet. Ha keresel egy listát 10 könyvről, amelyeket a szoftvermérnököknek el kell olvasniuk, valószínűleg 2-3 közülük a ThoughtWorks embereitől származik, mint például a Martin Fowler által írt Refactoring és a Sam Newman által írt Building Microservices: Designing Fine-Grained Systems.
Patrick Kua, Rebecca Parsons, Neal Ford.
A cég üzleti modellje a meglehetősen drága szolgáltatások nyújtására épül, de az ügyfél a fenomenális minőségért fizet, amely a szakértelmen, a belső standardokon és természetesen az embereken alapul. Ezért itt életbevágóan fontos, hogy a megfelelő embereket alkalmazzuk.
Mik azok a megfelelő emberek? Természetesen mindenki számára mást jelentenek. A ThoughtWorks megállapította, hogy az ő üzleti modelljük szerint a fejlesztők számára a legfontosabb kritériumok a következők:
- A páros programozásra való képesség. Pontosabban képesség, nem tapasztalat vagy tudás. Senki sem várja, hogy olyan emberek jöjjenek, akik már öt éve gyakorolják a páros programozást. De nyitottnak lenni mások véleményére és tudni hallgatni – ez egy szükséges készség.
- A tesztírás képessége, és az ideális az, ha TDD-t gyakorol.
- A SOLID és az OOP megértése és alkalmazása.
- A véleményed prezentálása. Tanácsadóként a megrendelő fejlesztőivel, más tanácsadókkal kell együttműködnöd, és nem sok haszna van annak, ha valaki jól csinál valamit, de teljesen képtelen azt a csapat többi tagjának átadni.
Most fontos, hogy értékeljük ezeket a készségeket a jelöltnél. Itt szeretném megosztani a ThoughtWorks-nél tett interjúm tapasztalatait. Elmondom, hogy Szingapúrban voltam, és minden sikerült, de a toborzási folyamat egységes és nem fog jelentősen eltérni az országok között.
0. szakasz. HR
Ahogy gyakran lenni szokott, egy 20 perces interjút tartottam a HR-rel. Erről nem fogok részletesen beszélni, csak annyit, hogy soha nem találkoztam még olyan HR szakemberrel, aki 15 percig mesélt volna a vállalat fejlesztési kultúrájáról, arról, hogy miért alkalmaznak TDD-t és miért páros programozást. Általában ez a kérdés elhallgattatja a HR-eket, akik csak annyit mondanak, hogy náluk a folyamat normális: a fejlesztők fejlesztenek, a tesztelők tesztelnek, a menedzserek irányítanak.
1. szakasz. Mennyire vagy jó OOP-ban, TDD-ben?
Másfél órával az interjú kezdete előtt küldtek egy feladatot, hogy készítsek egy Mars Rover szimulátort.
Mars rover feladatEgy robotfelfedezőkből álló csapatot telepít a NASA egy Mars-i fennsíkra. Ezt a fennsíkot, amely különösen téglalap alakú, a rovernek kell navigálnia, hogy az fedélzeti kameráik teljes képet kapjanak a környező terepről, amit vissza tudnak küldeni a Földre. A rover pozícióját és helyét az x és y koordináták kombinációja, valamint egy betű, amely az északi, déli, keleti vagy nyugati irányok egyikét jelöli, képviseli. A fennsík egy hálóra van felosztva a navigáció egyszerűsítése érdekében. Egy példa pozíció lehet: 0, 0, É, ami azt jelenti, hogy a rover a bal alsó sarokban van és észak felé néz. A rover irányításához a NASA egyszerű betűsorokat küld. A lehetséges betűk az 'L', 'R' és 'M'. Az 'L' és 'R' 90 fokkal balra vagy jobbra forgatja a rovert, anélkül hogy az aktuális helyéről mozdulna. Az 'M' azt jelenti, hogy egy rácspontot előre mozdul, és megtartja a jelenlegi irányát.
Feltételezve, hogy az (x, y) koordinátáktól északra lévő négyzet (x, y+1).
BEMENET:
A bemenet első sora a fennsík jobb felső koordinátáit tartalmazza, a bal alsó koordináták 0,0-nak tekintendők.
A fennmaradó bemenet az üzemelésre kijelölt roverekkel kapcsolatos információkat tartalmaz. Minden rover két bemeneti sorral rendelkezik. Az első sor a rover pozícióját, a második sor pedig utasításokat tartalmaz, amelyek megmondják a rovernek, hogyan felfedezze a fennsíkot. A pozíciót két egész szám és egy betű alkotja, amelyek szóközökkel el vannak választva, amelyek az x és y koordinátákra, valamint a rover tájolására vonatkoznak.
Minden rover sorozatosan ér véget, ami azt jelenti, hogy a második rover nem kezd el mozogni, amíg az első be nem fejezte a mozgását.
KIMENET:
Minden rover kimenete az utolsó koordinátái és tájolása legyen.
MEGJEGYZÉSEK:
Egyszerűen valósítsd meg a fent említett követelményeket, és bizonyítsd be, hogy a porszívó működik, unit tesztek írásával.
Bármilyen felhasználói felület létrehozása nem áll szándékomban.
A probléma megoldása a TDD (Tesztvezérelt Fejlesztés) megközelítés követésével preferált.
Az elérhető rövid idő alatt inkább a minőségre, mint a teljességre vagyunk érzékenyek.
*Nem tudom megosztani a feladatot, amit kaptam, ez egy régi feladat, amit néhány évvel ezelőtt adtak. De hidd el, alapvetően minden úgy maradt.
Külön szeretnék figyelmet fordítani az értékelési kritériumokra. Hányszor találkoztál már azzal a helyzettel, amikor a jelölt számára fontos dolgok teljesen irrelevánsak az értékelés során, és fordítva. Nem mindenki gondolkodik ugyanúgy, mint te, de sokan átvehetik az értékeidet és követhetik azokat, ha világosan leírják őket. Tehát az értékelési kritériumok alapján az öszszes másik készség mellett a legfontosabbak közé tartozik, hogy
- TDD;
- a OOP használatának képessége és fenntartható kód írása;
- a páros programozási képességek;
Tehát figyelmeztettek, hogy ezt az 1,5 órát arra fordítsam, hogy megfontoljam, hogyan fogom végrehajtani a feladatot, nem pedig a kód írására. A kódot majd együtt írjuk.
Amikor telefonáltunk, a srácok röviden elmondták, kik ők és mivel foglalkoznak, majd felajánlották, hogy kezdjük el a fejlesztést.
Interjúm során egyszer sem volt olyan érzésem, mintha interjún lennék. Olyan érzésem volt, mintha csapatban programoznánk. Ha valahol elakadok, ők segítenek, tanácsolnak, megvitatják, még vitatkoznak is egymással, hogy mi a legjobb megoldás. Az interjú során elfelejtettem, hogyan lehet ellenőrizni, hogy egy metódus kivált-e kivételt a JUnit 5-ben - ők azt javasolták, hogy folytassam a teszt írását, amíg az egyikük Google-özik, hogy hogyan kell ezt megtenni.
A közelmúltban, néhány órával az interjú után konstruktív visszajelzést kaptam - hogy mi tetszett és mi nem. Az én esetemben dicsértek a Sealed osztályok használatával, mint null objektum alternatívájával; amiért a kód írása előtt elmondtam, hogyan szeretném irányítani a rover-t, így kaptam egy vázlatot az osztályokról, legalábbis azok közül, amelyek az API-ban érintettek.
2. lépés. Mondd el nekünk,
Egy héttel az interjú előtt kértek, hogy készítsek egy bemutatót bármilyen számomra érdekes témában. A formátum egyszerű és megszokott: 15 perc bemutató, 15 perc kérdésekre válasz.
A Clean Architecture-t választottam Uncle Bobtól. Ismét egy pár ember interjúztatott. Ez volt az első tapasztalatom angol nyelvű prezentálásban, és valószínűleg, ha stresszes helyzetbe kerültem volna — nem boldogultam volna. De ismétlem, egyszer sem éreztem, hogy interjún vagyok. Minden mint mindig — mesélek, ők figyelmesen hallgatnak. Még a hagyományos kérdés-válasz szekció sem tűnt interjúra, látszott, hogy a kérdéseket nem azért teszik fel, hogy „elnyomjanak”, hanem valóban érdekli őket, amit a prezentációmban mondtam.
Két órával az interjú után megkaptam a visszajelzést — a prezentáció nagyon hasznos volt, és őszintén élvezték a hallgatását.
3. lépés. Production minőségű kód.
Figyelmeztetve, hogy ez a technikai interjúk utolsó lépése, megkértek, hogy otthon készítsem el a kódot production-ready állapotba, majd küldjem el a kódot felülvizsgálatra, és ütemezzek interjút, amely során a feladat követelményei meg fognak változni, és a kód módosításra szorul. Előre kell mondanom, hogy a kód felülvizsgálatát vakon végzik, a felülvizsgá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.
Hívás, és újra pár srác a monitor másik oldalán. Minden úgy, mint az első interjún: a legfontosabb, hogy ne felejtsd el a TDD-vel foglalkozni, és mesélj arról, mit csinálsz és miért. Ha korábban nem gyakoroltad a TDD-t, azt javaslom, hogy azonnal kezdj bele, nem azért, mert szükséges vállalatoknál, hanem mert jelentősen megkönnyíti az életedet, csökkenti a stresszszintedet, ha úgy tetszik. Emlékszel, milyen nehéz volt görcsösen keresni a debuggerekkel a hibát, amely csak a böngészőn keresztül reprodukálható, a tesztekkel viszont nem tudod megjeleníteni? Most képzeld el, hogy ilyen hibát kell nyomoznod egy interjú során - pár ősz hajszál már biztosított. Mit is ad nekünk a TDD? Megváltoztattad a kódot és váratlanul szembesültél vele, hogy a tesztek pirosak, és az, hogy mi a hiba, nem derül ki elsőre? Rendben, mondjuk az interjúztatóknak „Ups”, megnyomjuk a Ctrl-Z-t és kis lépésekkel elkezdünk előre haladni. És igen, a TDD alkalmazásának képességét magadban kell fejlesztened, el kell sajátítanod azt a képességet, hogy a cél felé haladj úgy, hogy a tesztjeid folyamatosan zöldek legyenek, ne pedig pirosak napokig, mert „nagy refaktorálás van”. Ez pontosan olyan készség, mint a karbantartható vagy a teljesítményorientált kód írásának képessége.
Tehát, hogy mennyire jól módosítható a kódod, az attól függ, hogy milyen tervezést vittél véghez az elején, mennyire egyszerű és hogy mennyire jók a tesztjeid.
Az interjú után néhány órával megkaptam a visszajelzést. Ezen a ponton rájöttem, hogy gyakorlatilag átmentem, és már csak egy kis idő van hátra a „Fowler-rel való találkozásig”.
4. szakasz. Finálé. Elég technikai kérdés. Tudni akarjuk, ki vagy!
Őszintén szólva, ez a kérdésfelvetés kissé zavarba hozott. Hogyan lehet megérteni, hogy milyen ember vagyok egy óra beszélgetés alapján? Főleg, hogy nem az anyanyelvemen beszélek, és, nyíltan szólva, meglehetősen rosszul és dadogva. Az előző interjúkon nekem könnyebb volt mesélni, mint válaszolni a kérdésekre, és ennek oka a kiejtésem. Legalább az egyik interjúztató ázsiai volt — az ő akcentusuk, hogy is mondjam, meglehetősen sajátos az európai fülnek. Ezért úgy döntöttem, hogy proaktív megközelítést alkalmazok — készítek egy bemutatót magamról, és az interjú elején felajánlom, hogy ezzel a bemutatóval meséljek magamról. Ha elfogadják — legalább kevesebb kérdés lesz hozzám, ha pedig elutasítják az ajánlatot — hát, három órám az életemből, amit a bemutatóra költöttem — nem olyan magas ár. De mit is írjak a bemutatóban? Életrajzot — Születtem ott és akkor, iskolába jártam, befejeztem az egyetemet — kinek érdekes ez?
Ha egy kicsit utánanézünk a Thoughtworks kultúrájának, találhatunk egy cikket Martin Fowler-tól [https://martinfowler.com/bliki/ThreePillars.html], amelyben három pillér szerepel: Fenntartható üzlet, Szoftveres kiválóság, és Társadalmi igazságosság.
Tegyük fel, hogy a Szoftveres kiválóságot már ellenőrizték nálam. Maradt a Fenntartható üzlet és a Társadalmi igazságosság bemutatása.
Ezen belül a hangsúlyt az utóbbira szeretném helyezni.
Először is elmondtam, miért a ThoughtWorks — már az egyetemen olvastam Martin Fowler blogját, így született a szeretetem a Tiszta kód iránt.
A projekteket különböző szögből is be lehet mutatni. Fejlesztettem már orvosi szoftvert, amely megkönnyítette a betegek életét, és a hírek szerint még egy életet is megmentett. Fejlesztettem már bankoknak szoftvert is, ami szintén egyfajta könnyítést jelentett a polgárok számára. Különösen, ha az adott bankot az ország lakosságának 70%-a használja. Nem a Sberbankról és nem is Oroszországról beszélek.
Szeretnél többet tudni rólam? Rendben. A hobbim a fényképezés, valamilyen módon 10 éve fényképezőgépet tartok a kezemben, vannak fényképeim, amiket nem szégyellem megmutatni. Egy időben segítettem egy macskamenhelynek: fényképeztem a macskákat, akiknek állandó otthonra volt szükségük. Jó fényképekkel sokkal könnyebb gazdára találni egy macskát. Valószínűleg körülbelül száz macska fényképezésével végeztem 🙂
Végső soron a bemutatóm 80%-a macskákkal volt tele.
A közvetlenül a bemutató után az HR írt, hogy még nem tudja a felvételi eredményeket, de az egész irodát lenyűgözték a macskák.
Végül megkaptam a visszajelzést - mindenki elégedett volt velem, mint emberrel.
De az HR a végső beszélgetés során diszkréten megemlítette, hogy a társadalmi igazságosság nagyon fontos és szükséges, de nem minden projekt ilyen. Kérdezte, hogy ez nem ijeszt-e meg. Összességében egy kicsit túlzásba vittem a társadalmi igazságosságot, ez előfordul 🙂
Result
Ennek eredményeként már több hónapja dolgozom Szingapúrban a Thoughtworks-nél, és látom, hogy itt is sok cég a Google „legjobb felvételi gyakorlatain” okulva használ papírokat és táblát a kódoláshoz, miközben a munkában nem igényelnek tudást a Spring-en, Symfony-n, RubyOnRails-en (a szükséges dolgokat kiemelni). Az mérnökök egy hét szabadságot vesznek ki a felvételi előtt, hogy „felkészüljenek”.
A Thoughtworks-nél a megfelelő követelmények mellett a következő elvek állnak középpontban:
Az interjúzás öröme. Az mindkét fél számára. Valóban, ha a legjobb szakembereket szeretné kapni (ki nem szeretné?), akkor az interjú nem egy piac, ahol rabszolgákat választanak, hanem egy olyan bemutató, ahol a munkaadó és a jelölt értékelik egymást. És ha a jelölt pozitív érzelmeket társít a céggel, nagy valószínűséggel ezt a céget választja.
Több interjúzó a torzítás csökkentése érdekében. A Thoughtworks-nél a páros programozás a de facto szabvány. Ha ezt a gyakorlatot más területeken is alkalmazni tudják, a TW igyekszik ezt megvalósítani. Minden szakaszban két ember tartja az interjút. Így minden egyes embert legalább 8 ember értékel, és a TW igyekszik változatos háttérrel rendelkező, különböző irányú (nem csak technikai) és nemű interjúzókat választani.
Végül a döntés a munkába vételről legalább 8 ember véleménye alapján fog megszületni, és senkinek sincs döntő szava.
Tulajdonság-alapú toborzás Ahelyett, hogy a jelölt 'tetszik/nem tetszik' alapján döntsünk, minden szerepre és minden szakaszra kidolgoztunk egy űrlapot, amely tartalmazza az értékelt attribútumokat. Az értékelés során erősen ajánlott, hogy ne a konkrét készség tapasztalatát, hanem a képességet értékeljük ennek alkalmazására. Így tehát, ha a jelöltnek nem volt lehetősége alkalmazni bizonyos skilleket, mint például a TDD-t, de mindezek mellett próbálja azt használni, és figyelembe veszi a helyes használatra vonatkozó tanácsokat – akkor van rá esélye, hogy átmegy az interjún.
Nem szükségesek oktatási bizonyítványok A TW nem követeli meg a jelölttől, hogy kötelező oklevelekkel vagy számítástechnikai végzettséggel rendelkezzen. Csak a képességeket értékeljük.
Ez az első interjú, amelyet külföldi cégeknél tettem, amire nem kellett készülni. Minden szakasz után nem éreztem magam úgy, mint egy kifacsart citrom, éppen ellenkezőleg, örültem, hogy alkalmazhatom a legjobb gyakorlatokat, hogy az emberek a képernyő másik oldalán értékelik ezt, és minden nap alkalmazzák őket.
Néhány hónap elteltével elmondhatom, hogy a várakozások teljes mértékben teljesültek. Miben különbözik a ThoughtWorks egy hagyományos cégtől? Egy hagyományos cégnél találhatsz jó fejlesztőket és kedves embereket, de a TW-nél a koncentrációjuk kiemelkedő.
Ha csatlakozni szeretnél a ThoughtWorks-hoz, a nyitott pozíciókat itt tudod megnézni
Javaslom, hogy figyelmedbe ajánljam az érdekes állásokat:
Lead Software Engineer: , , ,
Senior Software Engineer: , , ,
Software Engineer: , ,
Senior Data Engineer:
Quality Analyst:
Infrastrukturált: , ,
(Szeretném őszintén figyelmeztetni, hogy a link referral, ha bekerülsz a TW-hoz, jutalmat kapok). Válaszd ki a kedvenc irodádat, nem szükséges csak Európában korlátozódnod, végül is, a TW minden 2. évben boldogan átköltöztet más országba, hiszen ez a ThoughtWorks politikájának része, így a kultúra elterjed és homogenizálódik.
Ne habozz kérdezni a megjegyzésekben, vagy kérj meg, hogy ajánljalak.
Ha a téma érdekesnek tűnt, írok arról, milyen dolgozni a ThoughtWorks-nál és milyen itt élni Szingapúrban.
Forrás: habr.com
