Eikö sinusta tunnu oudolta, että kun olet vaihtamassa työpaikkaa ja herää tarve läpäistä haastattelu, ensimmäinen asia, jonka ajattelet on "sinun pitää valmistautua haastatteluun". Ratkaise ongelmia HackerRankissa, lue Murtaudu koodaushaastatteluun, muista kuinka ArrayList toimii ja miten se eroaa LinkedLististä. Ai niin, he saattavat myös kysyä lajittelusta, ja olisi ilmeisesti epäammattimaista sanoa, että pikalajittelu olisi todennäköisesti paras valinta.
Mutta odota, ohjelmoit 8 tuntia päivässä, ratkaiset mielenkiintoisia ja ei-triviaaleja ongelmia, ja uudessa työssäsi teet saman asian plus tai miinus. Mutta siitä huolimatta haastattelun läpäisemiseksi sinun on jotenkin lisäksi valmistauduttava, ei edes hiottava päivittäisiä taitojasi, vaan opittava jotain, mitä et tarvinnut nykyisessä työssäsi ja tuskin tarvitset seuraavassa työssäsi. Vastaväitteeseesi, että tietojenkäsittely on veressämme, ja jos herätät meidät keskellä yötä, meidän on kirjoitettava silmät kiinni tyynyliinalle kävely puun leveydellä edes tajuihinsa palaamatta. vastaa, että jos saan töitä sirkuksesta, ja pääasia, että temppu olisi juuri tämä - niin ehkä kyllä, olen samaa mieltä. Tämä taito on testattava.
Mutta miksi testata taitoja, joilla ei ole merkitystä nykyisessä työssäsi? Vain koska siitä tuli muotia? Koska Google tekee tämän? Tai siksi, että tulevan tiiminvetäjäsi piti opetella kaikki lajittelumenetelmät ennen haastattelua ja nyt hän uskoo, että "jokaisen hyvän ohjelmoijan täytyy tietää ulkoa palindromin löytämisen toteutus merkkijonosta".
No, et ole Google (c). Mihin Googlella on varaa, tavallisilla yrityksillä ei ole. Google, analysoituaan työntekijöidensä tiedot, tuli siihen tulokseen, että olympiataustaiset insinöörit ovat hyviä käsittelemään sen erityistehtäviä. Suunnittelemalla valintaprosessiaan heillä on lisäksi varaa ottaa riski, että he eivät välttämättä palkkaa muutamia hyviä insinöörejä, koska he eivät pysty helposti selvittämään matemaattisia ongelmia. Mutta tämä ei ole heille ongelma, Googlessa on paljon ihmisiä, jotka haluavat työskennellä, paikka suljetaan.
Katsotaanpa nyt ulos ikkunasta, ja jos toimistosi edessä työskennelläksesi haluavat insinöörit eivät ole vielä pystyttäneet telttaleiriä ja kehittäjäsi etsivät useammin stackoverflow:sta, mitä seuraavan kevään huomautus on asennettava, luokitusalgoritmien monimutkaisuuden sijaan, sinun on ilmeisesti aika miettiä, pitäisikö sinun kopioida Google.
No, jos tällä kertaa Google epäonnistui eikä antanut vastausta, mitä sinun pitäisi tehdä? Tarkista tarkalleen, mitä kehittäjä tekee työssään. Mitä arvostat kehittäjissä?
Määritä kriteerit sille, kenet haluat palkata, ja kehitä testejä, jotka testaavat juuri nämä taidot.
ThoughtWorks
Mitä tekemistä ThoughtWorksilla on tämän kanssa? Täältä löysin esimerkin mallihaastattelusta itselleni. Keitä ThoughtWorks on? Lyhyesti sanottuna tämä on huippuluokan konsulttiyritys, jolla on toimipisteitä kaikkialla maailmassa Kiinasta, Singaporesta Amerikan mantereille ja joka on konsultoinut kehitysalaa noin 25 vuotta ja jolla on oma Science-divisioona, jota johtaa Martin. Fowler. Jos etsit luetteloa 10 kirjasta, jotka on luettava ohjelmistosuunnittelijalle, ehkä 2-3 niistä on ThoughtWorksin tyyppien kirjoittamia, kuten Martin Fowlerin Refactoring ja Building Microservices: Designing Fine-Grain Systems, Sam. Newman tai Building Evolutionary Architectures
Patrick Kua, Rebecca Parsons, Neal Ford.
Yrityksen liiketoiminta rakentuu melko kalliiden palvelujen tuottamiseen, mutta asiakas maksaa ilmiömäisestä laadusta, joka koostuu osaamisesta, sisäisistä standardeista ja tietysti ihmisistä. Siksi oikeiden ihmisten palkkaaminen on elintärkeää.
Millaiset ihmiset ovat oikeassa? Tietysti jokaiselle löytyy erilaisia. ThoughtWorks on määrittänyt, että kehittäjien liiketoimintamallinsa tärkeimmät kriteerit ovat:
- Kyky kehittyä pareittain. Se on kykyä, ei kokemusta tai taitoa. Kukaan ei odota, että 5 vuotta pariohjelmointia harjoittaneita ihmisiä tulee, mutta muiden mielipiteiden vastaanottaminen ja kuunteleminen on välttämätön taito.
- Kyky kirjoittaa testejä ja mieluiten harjoitella TDD:tä
- Ymmärrä SOLID ja OOP ja osaa soveltaa niitä.
- Esitä mielipiteesi. Konsulttina on työskenneltävä asiakkaan kehittäjien, muiden konsulttien kanssa, eikä siitä ole paljoakaan hyötyä, jos joku osaa tehdä jotain hyvin, mutta ei täysin pysty välittämään sitä muulle tiimille.
Nyt on tärkeää arvioida nämä hakijan erityistaidot. Ja tässä haluan puhua kokemuksestani haastattelusta ThoughtWorksissä. Sanon heti, että menin Singaporeen ja läpäisin, mutta rekrytointiprosessi on yhtenäinen eikä eroa paljon maittain.
Vaihe 0. HR
Kuten usein tapahtuu, 20 minuutin haastattelu HR:n kanssa. En ryhdy siihen, sanon vain, että en ole koskaan tavannut HR-henkilöä, joka voisi puhua 15 minuuttia yrityksen kehityskulttuurista, miksi he käyttävät TDD:tä, miksi pariohjelmointia. Yleensä HR:t kuivuvat tähän kysymykseen ja sanovat, että heidän prosessinsa on normaali: kehittäjät kehittävät, testaajat testaavat, johtajat ajavat.
Vaihe 1. Kuinka hyvä olet OOP:ssa, TDD?
1.5 tuntia ennen haastattelun alkua minulle lähetettiin tehtävä tehdä Mars Rover -simulaattori.
Mars-kulkijan tehtäväNASA laskee joukon robottikuljettajia Marsin tasangolle. Tämä omituisen suorakaiteen muotoinen tasango on kuljettajien navigoitava, jotta heidän kameransa voivat saada täydellisen kuvan ympäröivästä maastosta ja lähettää ne takaisin Maahan. Roverin sijainti ja sijainti esitetään x- ja y-koordinaattien yhdistelmällä ja kirjaimella, joka edustaa yhtä neljästä pääkompassipisteestä. Tasango on jaettu ruudukoksi navigoinnin yksinkertaistamiseksi. Esimerkkiasento voi olla 0, 0, N, mikä tarkoittaa, että rover on vasemmassa alakulmassa ja osoittaa pohjoiseen. NASA lähettää yksinkertaisen kirjainjonon ohjatakseen roveria. Mahdolliset kirjaimet ovat 'L', 'R' ja 'M'. "L" ja "R" saavat roverin pyörimään 90 astetta vasemmalle tai oikealle liikkumatta nykyisestä paikastaan. "M" tarkoittaa siirtymistä yhden ruudukon pisteen eteenpäin ja saman suunnan säilyttämistä.
Oletetaan, että suoraan pohjoiseen (x, y) oleva neliö on (x, y+1).
INPUT:
Ensimmäinen syöttörivi on tasangon oikean yläkulman koordinaatit, vasemman alakoordinaattien oletetaan olevan 0,0.
Loput syötteestä ovat tietoja, jotka liittyvät käyttöön otettuihin rovereihin. Jokaisella roverilla on kaksi tuloriviä. Ensimmäinen rivi kertoo mönkijän sijainnin, ja toinen rivi on sarja ohjeita, jotka kertovat kulkijalle, kuinka tasangolla tutkitaan. Sijainti koostuu kahdesta kokonaisluvusta ja yhdestä välilyönnillä erotetusta kirjaimesta, jotka vastaavat x- ja y-koordinaatteja ja mönkijän suuntaa.
Jokainen mönkijä valmistuu peräkkäin, mikä tarkoittaa, että toinen mönkijä ei aloita liikkumista ennen kuin ensimmäinen on lopettanut liikkeen.
LÄHTÖ:
Jokaisen roverin tulosteen tulee olla sen lopulliset koordinaatit ja suunta.
HUOM:
Täytä yllä olevat vaatimukset ja todista pölynimurin toimivuus kirjoittamalla sille yksikkötestejä.
Minkäänlaisen käyttöliittymän luominen on mahdotonta.
On suositeltavaa ratkaista ongelma noudattamalla TDD-lähestymistapaa (Test Driven Development).
Käytettävissä olevan lyhyen ajan kuluessa olemme enemmän huolissamme laadusta kuin täydellisyydestä.
*En voi julkaista minulle lähetettyä tehtävää, tämä on vanha tehtävä, joka annettiin useita vuosia sitten. Mutta usko minua, pohjimmiltaan kaikki pysyy ennallaan.
Erityisesti haluaisin kiinnittää huomiota arviointiperusteisiin. Kuinka monta kertaa olet törmännyt tarkastuksessa tilanteeseen, jossa ehdokkaalle tärkeät asiat jäävät täysin merkityksettömiksi ja päinvastoin. Kaikki eivät ajattele samalla tavalla kuin sinä, mutta monet voivat hyväksyä ja noudattaa arvojasi, jos ne on selkeästi ilmaistu. Arviointikriteerien perusteella on siis heti selvää, että tärkeimmät taidot tässä vaiheessa ovat
- TDD;
- Kyky käyttää OOP:ta ja kirjoittaa ylläpidettävää koodia;
- pariohjelmointikykyjä
Joten minua varoitettiin käyttämään ne 1.5 tuntia miettimään, kuinka aion tehdä tehtävän koodin kirjoittamisen sijaan. Kirjoitamme koodin yhdessä.
Kun saimme puhelimeen, kaverit kertoivat lyhyesti, keitä he ovat ja mitä he tekevät, ja tarjoutuivat kehittämään.
Koko haastattelun aikana minulla ei koskaan ollut tunnetta, että minua olisi haastateltu. On tunne, että kehität koodia tiimissä. Jos jäät jumiin jonnekin, he auttavat, neuvovat, keskustelevat, jopa riitelevät toistensa kanssa, miten se olisi parasta tehdä. Haastattelussa unohdin tarkistaa JUnit 5:ssä, että menetelmä heittää Poikkeuksen - tarjoutuivat jatkamaan kokeen kirjoittamista, kun yksi heistä googlasi miten se tehdään.
Kirjaimellisesti muutama tunti haastattelun jälkeen sain rakentavaa palautetta - mistä pidin ja mistä en. Minun tapauksessani minua kehuttiin siitä, että käytin Sealed-luokkia vaihtoehtona nollaobjektille; siitä, että ennen koodin kirjoittamista kirjoitin pseudokoodilla kuinka haluaisin ohjata roveria, ja näin sain luonnoksen luokista, ainakin niistä, jotka ovat mukana robotin API:ssa.
Vaihe 2: Kerro meille
Viikkoa ennen haastattelua minua pyydettiin valmistelemaan esitys mistä tahansa minua kiinnostavasta aiheesta. Muoto on yksinkertainen ja tuttu: 15 minuuttia esittelyä, 15 minuuttia kysymyksiin vastaamista.
Valitsin Uncle Bobin puhtaan arkkitehtuurin. Ja taas pari ihmistä haastatteli minua. Tämä oli ensimmäinen kokemukseni englanninkielisestä esittämisestä, ja ehkä jos olisin ollut stressaavassa tilanteessa, en olisi jaksanut. Mutta jälleen kerran, minulla ei ole koskaan ollut tunnetta, että olisin haastattelussa. Kaikki on tavalliseen tapaan - kerron heille, he kuuntelevat tarkasti. Perinteinenkään kysymys ja vastaus ei ollut haastattelun kaltainen, vaan oli selvää, että kysymyksiä ei pyydetty "uppoamaan", vaan niitä, jotka todella kiinnostivat esityksessäni.
Pari tuntia haastattelun jälkeen sain palautetta - esitys oli erittäin hyödyllinen ja he todella nauttivat kuuntelemisesta.
Vaihe 3. Tuotannon laatukoodi
Varoitettuani, että tämä oli teknisten haastattelujen viimeinen vaihe, minua pyydettiin tuomaan koodi kotona tuotantovalmiiseen tilaan, lähettämään koodi tarkastettavaksi ja ajoittamaan haastattelut, joissa tehtävän vaatimukset muuttuvat ja koodi vaatia muutosta. Tulevaisuudessa voin sanoa, että koodiarviointi suoritetaan sokeasti, arvioijat eivät tiedä paikkaa, johon ehdokas hakee, he eivät näe hänen CV:tä, he eivät näe edes hänen nimeään.
Puhelin soi, ja taas monitorin toisella puolella oli pari kaveria. Kaikki on sama kuin ensimmäisessä haastattelussa: tärkeintä ei ole unohtaa TDD:tä, kertoa mitä teet ja miksi. Jos et ole aiemmin harjoitellut TDD:tä, niin suosittelen aloittamaan sen heti, ei siksi, että se olisi yrityksissä tarpeellista, vaan koska se yksinkertaistaa merkittävästi elämääsi, vähentää stressitasosi halutessasi. Muistatko kuinka jouduit kiihkeästi etsimään debuggerilla virhettä, joka voidaan toistaa vain selaimen kautta, mutta jota et voi toistaa testeillä? Kuvittele nyt, että joudut saamaan tällaisen virheen haastattelun aikana - sinulle taataan pari harmaata hiusta. Mitä saamme TDD:llä? Muutimme koodia ja tajusimme yllättäen, että nyt testit ovat punaisia, mutta mikä on virhe, jota emme voi selvittää ensimmäisellä kerralla? Okei, sanomme haastattelijoille "Oops", paina Ctrl-Z ja aloitamme pienin askelin eteenpäin. Ja kyllä, sinun täytyy kehittää itsessäsi kykyä kehittyä käyttämällä TDD:tä, kykyä mennä kohti tavoitetta niin, että testit ovat pysyvästi vihreitä, eivätkä puoli päivää punaisia, koska "sinulla on paljon refaktorointia". Tämä on täsmälleen sama taito kuin ylläpidettävän koodin kirjoittaminen tai tuottavan koodin kirjoittaminen.
Joten se, kuinka hyvin koodiasi voidaan muuttaa, riippuu siitä, mitä suunnittelua olet ajatellut aluksi, kuinka yksinkertaista se on ja kuinka hyviä testisi ovat.
Haastattelun jälkeen sain palautetta muutaman tunnin sisällä. Tässä vaiheessa tajusin, että olin melkein läpi, ja enää oli hyvin vähän aikaa, ennen kuin "tapasin Fowlerin".
Vaihe 4. Finaali. Teknisiä kysymyksiä riittää. Haluamme tietää kuka olet!
Ollakseni rehellinen, olin hieman ymmälläni tästä kysymyksen muotoilusta. Kuinka voit ymmärtää, millainen ihminen olen tunnin keskustelussa? Ja vielä enemmän, kuinka voit ymmärtää tämän, kun puhun kieltä, joka ei ole äidinkieleni, ja suoraan sanottuna erittäin surkea ja kielen sidottu. Aiemmissa haastatteluissa minun oli henkilökohtaisesti helpompi puhua kuin vastata kysymyksiin, ja aksentti oli syyllinen. Ainakin yksi haastattelijoista oli aasialainen - ja heidän aksenttinsa on, sanotaanko, jossain määrin eurooppalaiselle korvalle ominaista. Siksi päätin omaksua ennakoivan lähestymistavan - valmistaa esityksen itsestäni ja tarjoudu haastattelun alussa puhumaan itsestäni tällä esityksellä. Jos he ovat samaa mieltä, niin minulle tulee ainakin vähemmän kysymyksiä; jos he hylkäävät tarjouksen, niin 3 tuntia elämästäni esittelyyn ei ole niin korkea hinta. Mutta mitä sinun pitäisi kirjoittaa esitykseen? Elämäkerta - Syntynyt siellä, tuolloin, kävi koulua, valmistui yliopistosta - mutta ketä kiinnostaa?
Jos Googletat hieman Thoughtworks-kulttuurista, löydät Martin Fowlerin artikkelin [https://martinfowler.com/bliki/ThreePillars.html], jossa kuvataan kolme pilaria: Kestävä liiketoiminta, ohjelmistojen erinomaisuus ja sosiaalinen oikeudenmukaisuus.
Oletetaan, että Software Excellence on jo tarkistettu puolestani. Kestävää liiketoimintaa ja sosiaalista oikeudenmukaisuutta on vielä näytettävä.
Lisäksi päätin keskittyä jälkimmäiseen.
Aluksi kerroin hänelle, miksi ThoughtWorks - Luin Martin Fowlerin blogia yliopistossa, mistä johtuu rakkauteni Clean-koodiin.
Projekteja voidaan myös esittää eri näkökulmista. Hän kehitti myös lääketieteen ohjelmistoja, jotka yksinkertaistivat potilaiden elämää ja jopa pelastivat huhujen mukaan yhden hengen. Kehitin myös ohjelmistoja pankeille, mikä helpotti myös kansalaisten elämää. Varsinkin jos tätä pankkia käyttää 70 % maan väestöstä. Tämä ei koske Sberbankia eikä edes Venäjää.
Haluatko tietää minusta? OK. Harrastukseni on valokuvaus, tavalla tai toisella olen pitänyt kameraa käsissäni noin 10 vuotta, on valokuvia, joita en ole kovin nolostunut esittelemään. Auttelin myös aikoinaan kissatarhaa: kuvasin kissoja, jotka tarvitsisivat pysyvän kodin. Ja hyvillä valokuvilla on paljon helpompi sijoittaa kissa. Kuvasin varmaan sata kissaa :)
Lopulta 80 % esityksestäni oli täynnä kissoja.
Heti esityksen jälkeen HR kirjoitti minulle, ettei hän vielä tiennyt haastattelun tuloksia, mutta koko toimisto oli jo vaikuttunut kissoista.
Lopulta jäin odottamaan palautetta – tyytyin kaikkiin ihmisenä.
Mutta loppukeskustelun aikana HR sanoi tahdikkaasti, että Social Justice on erittäin hyvä ja tarpeellinen, mutta kaikki projektit eivät ole sellaisia. Ja hän kysyi, pelottaako se minua. Yleisesti ottaen menin hieman yli laidan sosiaalisen oikeudenmukaisuuden kanssa, sitä tapahtuu :)
Koko
Tämän seurauksena olen työskennellyt Singaporessa Thoughtworksissa useita kuukausia ja huomaan, että täällä liian monet yritykset ottavat käyttöön Googlen "parhaita haastattelukäytäntöjä" käyttämällä lehtiä ja valkotaulua koodaamiseen, vaikka heillä on enemmän tietoa kuin Spring, Symfony, RubyOnRails (Alleviivaa tarpeelliset) ei vaadita työssä. Insinöörit pitävät viikon tauon ennen haastattelua "valmistautuakseen".
Thoughtworksissa ehdokkaalle asetettujen riittävien vaatimusten lisäksi seuraavat periaatteet ovat eturintamassa:
Haastattelun iloa. Lisäksi molemmille osapuolille. Todellakin, jos haluat saada parasta henkilökuntaa (ja kuka ei?), niin haastattelu ei ole markkinat, joissa valitaan orjia, vaan show, jossa sekä työnantaja että ehdokas arvioivat toisiaan. Ja jos ehdokas yhdistää miellyttäviä tunteita yritykseen, on todennäköistä, että hän valitsee tämän yrityksen
Useita haastattelijoita vähentämään ennakkoluuloja. Thoughtworksissa pariohjelmointi on de facto standardi. Ja jos tätä käytäntöä voidaan soveltaa muilla aloilla, TW yrittää tehdä niin. Kussakin vaiheessa haastattelun suorittaa 2 henkilöä. Näin ollen jokaista henkilöä arvioi vähintään 8 henkilöä, ja TW yrittää valita haastattelijat, joilla on eri tausta, eri suuntaiset (ei vain teknikot) ja sukupuolet.
Viime kädessä palkkauspäätös tehdään vähintään 8 henkilön mielipiteiden perusteella, eikä kenelläkään ole ratkaisevaa ääntä.
Ominaisuusperusteinen palkkaaminen Sen sijaan, että tehtäisiin päätös ehdokkaan mieltymysten tai inhojen perusteella, jokaiselle roolille ja jokaiselle vaiheelle kehitetään lomake, joka sisältää arvioitavat ominaisuudet. Samanaikaisesti arvioitaessa on erittäin suositeltavaa arvioida ei kokemusta tietystä taidosta, vaan kykyä soveltaa sitä. Jos ehdokas ei siis kyennyt soveltamaan mitään taitoja, kuten TDD:tä, mutta hän kuitenkin yrittää soveltaa niitä, kuuntelee neuvoja niiden oikeasta käytöstä, hänellä on kaikki mahdollisuudet läpäistä haastattelu.
Koulutustodistuksia ei vaadita TW ei vaadi tietojenkäsittelytieteen todistusta tai koulutusta. Vain taidot arvioidaan.
Tämä on ensimmäinen haastattelu ulkomaisten yritysten kanssa, johon minun ei tarvinnut valmistautua. Jokaisen vaiheen jälkeen en tuntenut oloani uupuneeksi, vaan päinvastoin, olin iloinen, että sain soveltaa parhaita käytäntöjä, että ihmiset monitorin toisella puolella arvostivat sitä ja soveltavat niitä joka päivä.
Muutaman kuukauden jälkeen voin sanoa, että odotukseni täyttyivät täysin. Miten ThoughtWorks eroaa tavallisesta yrityksestä? Tavallisesta yrityksestä löytyy hyviä kehittäjiä ja mukavia ihmisiä, mutta TW:ssä heidän keskittymiskykynsä on poissa listalta.
Jos olet kiinnostunut liittymään ThoughtWorksiin, voit katsoa avoimia työpaikkojamme
Suosittelen myös kiinnittämään huomiota mielenkiintoisiin avoimiin työpaikkoihin:
Johtava ohjelmistosuunnittelija: , , ,
Vanhempi ohjelmistosuunnittelija: , , ,
Ohjelmistoinsinööri: , ,
Vanhempi tietoinsinööri:
Laatuanalyytikko:
Infrastruktuuri: , ,
(Haluan rehellisesti varoittaa, että linkki on viittauslinkki, jos menet TW:hen, saan mukavan bonuksen). Valitse haluamasi toimisto, sinun ei tarvitse rajoittua Eurooppaan, loppujen lopuksi TW muuttaa sinut mielellään 2 vuoden välein toiseen maahan, koska... tämä on osa ThoughtWorks-politiikkaa, joten kulttuuri leviää ja homogenisoituu.
Voit vapaasti esittää kysymyksiä kommenteissa tai pyytää minulta suosituksia.
Jos aihe vaikuttaa kiinnostavalta, kirjoitan siitä millaista on työskennellä ThoughtWorksillä ja millaista elämä on Singaporessa.
Lähde: will.com