Lyk dit nie vir jou vreemd dat wanneer jy op die punt staan om van werk te verander en die behoefte ontstaan om 'n onderhoud te slaag, die eerste ding wat jy dink is "jy moet voorberei vir die onderhoud." Los probleme op op HackerRank, lees Crack the coding interview, memoriseer hoe ArrayList werk en hoe dit van LinkedList verskil. O ja, hulle vra dalk ook oor sortering, en dit sal natuurlik onprofessioneel wees om te sê dat vinnige sorteer heel waarskynlik die beste keuse sal wees.
Maar wag, jy programmeer 8 uur per dag, los interessante en nie-onbelangrike probleme op, en by jou nuwe werk sal jy dieselfde ding doen, plus of minus. Maar nietemin, om 'n onderhoud te slaag, moet jy op een of ander manier addisioneel voorberei, nie eers jou daaglikse vaardighede slyp nie, maar iets leer wat jy nie by jou huidige werk nodig gehad het nie en waarskynlik nie by jou volgende een nodig sal hê nie. Op jou besware dat rekenaarwetenskap in ons bloed is, en as jy ons in die middel van die nag wakker maak, is ons verplig om met toe oë op 'n kussingsloop 'n wandeling om die breedte van 'n boom te skryf sonder om eers weer by te kom, ek sal antwoord dat as ek 'n werk in die sirkus kry, en my belangrikste ding sal die truuk presies dit wees - dan miskien ja, ek stem saam. Hierdie vaardigheid moet getoets word.
Maar hoekom toets vaardighede wat irrelevant is vir jou huidige werk? Net omdat dit mode geword het? Omdat Google dit doen? Of omdat jou toekomstige spanleier al die sorteermetodes voor die onderhoud moes leer en nou glo hy dat "elke goeie programmeerder uit die kop moet weet wat die implementering van die vind van 'n palindroom in 'n tou is."
Wel, jy is nie Google nie (c). Wat Google kan bekostig, kan gewone maatskappye nie. Google het die data van sy werknemers ontleed en tot die gevolgtrekking gekom dat ingenieurs met 'n Olimpiade-agtergrond goed is om sy spesifieke take te hanteer. Deur hul keuringsproses te ontwerp, kan hulle boonop bekostig om die risiko te neem dat hulle dalk nie 'n paar goeie ingenieurs aanstel nie omdat hulle nie maklik wiskundeprobleme kan oplos nie. Maar dit is nie vir hulle 'n probleem nie, daar is baie mense wat by Google wil werk, die pos sal gesluit word.
Kom ons kyk nou by die venster uit, en as die ingenieurs wat vir jou wil werk nog nie 'n tentkamp opgeslaan het voor jou kantoor nie, en jou ontwikkelaars kyk meer gereeld op stapeloorvloei vir watter volgende Lente-aantekening geïnstalleer moet word, eerder as die ingewikkeldhede van rangorde-algoritmes, dan is dit blykbaar tyd dat jy dink of jy Google moet kopieer.
Wel, as Google hierdie keer misluk het en nie 'n antwoord verskaf het nie, wat moet jy doen? Kyk presies wat die ontwikkelaar by die werk sal doen. Wat waardeer jy by ontwikkelaars?
Maak kriteria vir wie jy wil aanstel en ontwikkel toetse wat presies hierdie vaardighede toets.
ThoughtWorks
Wat het ThoughtWorks hiermee te doen? Dit is waar ek vir myself 'n voorbeeld van 'n modelonderhoud gekry het. Wie is ThoughtWorks? Kortom, dit is 'n hoë-end konsultasiemaatskappy met kantore regoor die wêreld, van China, Singapoer tot die Amerikaanse vastelande, wat al sowat 25 jaar konsulteer op die gebied van ontwikkeling, het sy eie Wetenskap-afdeling, onder leiding van Martin Fowler. As jy soek na 'n lys van 10 moet-lees boeke vir 'n sagteware-ingenieur, dan sal miskien 2-3 van hulle geskryf word deur die ouens van ThoughtWorks, soos Refactoring Deur Martin Fowler en Building Microservices: Designing Fine-Grained Systems deur Sam Newman of Building Evolutionary Architectures
deur Patrick Kua, Rebecca Parsons, Neal Ford.
Die maatskappy se besigheid is gebou op die verskaffing van redelik duur dienste, maar die kliënt betaal vir fenomenale gehalte, wat bestaan uit kundigheid, interne standaarde en natuurlik mense. Daarom is die aanstelling van die regte mense hier noodsaaklik.
Watter soort mense is reg? Natuurlik is daar verskillendes vir almal. ThoughtWorks het vasgestel dat die belangrikste kriteria vir hul ontwikkelaarbesigheidsmodel is:
- Vermoë om in pare te ontwikkel. Dit is vermoë, nie ervaring of vaardigheid nie. Niemand verwag dat mense wat al vir 5 jaar Paar-programmering beoefen sal kom nie. Maar om ontvanklik vir ander mense se opinies en om te kan luister is 'n noodsaaklike vaardigheid.
- Vermoë om toetse te skryf, en ideaal om TDD te oefen
- SOLID en OOP verstaan en in staat wees om dit toe te pas.
- Gee jou mening. As 'n konsultant moet jy saam met die kliënt se ontwikkelaars, met ander konsultante, en daar is nie veel voordeel as 'n persoon weet hoe om iets goed te doen, maar heeltemal nie in staat is om dit aan die res van die span oor te dra nie.
Nou is dit belangrik om hierdie spesifieke vaardighede by die kandidaat te evalueer. En hier wil ek praat oor my ervaring van onderhoudvoering by ThoughtWorks. Ek sal dadelik sê dat ek na Singapoer gegaan het en geslaag het, maar die werwingsproses is verenig en sal nie veel van land tot land verskil nie.
Stadium 0. HR
Soos dikwels gebeur, 'n 20-minute onderhoud met HR. Ek sal nie daaroor uitwei nie, ek sal net sê dat ek nog nooit 'n HR-persoon ontmoet het wat vir 15 minute kon praat oor die ontwikkelingskultuur in die maatskappy, hoekom hulle TDD gebruik, hoekom paarprogrammering nie. Gewoonlik verwelk HR'e hierdie vraag en sê dat hul proses normaal is: ontwikkelaars ontwikkel, toetsers toets, bestuurders bestuur.
Fase 1. Hoe goed is jy by OOP, TDD?
1.5 uur voor die aanvang van die onderhoud is ek 'n taak gestuur om 'n Mars Rover-simulator te maak.
Mars Rover missieNASA sal 'n groep robot-rovers op 'n plato op Mars laat land. Hierdie plato, wat eienaardig reghoekig is, moet deur die rovers navigeer word sodat hul kameras aan boord 'n volledige uitsig van die omliggende terrein kan kry om terug na die aarde te stuur. 'n Rover se posisie en ligging word voorgestel deur 'n kombinasie van x- en y-koördinate en 'n letter wat een van die vier kardinale kompaspunte verteenwoordig. Die plato is opgedeel in 'n rooster om navigasie te vereenvoudig. 'n Voorbeeldposisie kan 0, 0, N wees, wat beteken dat die rover in die onderste linkerhoek is en na Noord kyk. Om 'n rover te beheer, stuur NASA 'n eenvoudige string letters. Die moontlike letters is 'L', 'R' en 'M'. 'L' en 'R' laat die rover onderskeidelik 90 grade links of regs draai, sonder om van sy huidige plek af te beweeg. 'M' beteken beweeg een roosterpunt vorentoe en handhaaf dieselfde opskrif.
Aanvaar dat die vierkant direk noord vanaf (x, y) (x, y+1) is.
INSET:
Die eerste lyn van invoer is die boonste regterkantse koördinate van die plato, die onderste linkerkoördinate word aanvaar as 0,0.
Die res van die insette is inligting met betrekking tot die rovers wat ontplooi is. Elke rover het twee lyne van invoer. Die eerste reël gee die rover se posisie, en die tweede reël is 'n reeks instruksies wat die rover vertel hoe om die plato te verken. Die posisie bestaan uit twee heelgetalle en 'n letter geskei deur spasies, wat ooreenstem met die x- en y-koördinate en die rover se oriëntasie.
Elke rover sal opeenvolgend voltooi word, wat beteken dat die tweede rover nie sal begin beweeg voordat die eerste een klaar beweeg het nie.
afvoer:
Die uitset vir elke rover moet sy finale koördinate en opskrif wees.
AANTEKENINGE:
Implementeer eenvoudig die vereistes hierbo en bewys 'n stofsuier werk deur eenheidstoetse daarvoor te skryf.
Die skep van enige vorm van gebruikerskoppelvlak is buite omvang.
Dit sal voorkeur geniet om die probleem op te los deur 'n TDD (Toetsgedrewe Ontwikkeling) benadering te volg.
In die kort tyd wat beskikbaar is, is ons meer bekommerd oor kwaliteit as volledigheid.
*Ek kan nie die werkopdrag plaas wat aan my gestuur is nie, dit is 'n ou werkopdrag wat etlike jare gelede gegee is. Maar glo my, fundamenteel bly alles dieselfde.
Ek wil veral die aandag vestig op die evalueringskriteria. Hoeveel keer het jy 'n situasie teëgekom waar dinge wat vir 'n kandidaat belangrik is, heeltemal onbelangrik is tydens die oudit en omgekeerd. Nie almal dink dieselfde as jy nie, maar baie kan jou waardes aanvaar en volg as dit duidelik gestel word. Dus, uit die evalueringskriteria is dit onmiddellik duidelik dat die belangrikste vaardighede op hierdie stadium is
- TDD;
- Vermoë om OOP te gebruik en onderhoubare kode te skryf;
- paar programmeringsvermoëns
So, ek is gewaarsku om daardie 1.5 uur te spandeer om te dink oor hoe ek die taak gaan doen, eerder as om kode te skryf. Ons sal die kode saam skryf.
Toe ons oor die telefoon kom, het die ouens kortliks vir ons gesê wie hulle is en wat hulle doen en aangebied om met ontwikkeling te begin.
Gedurende die hele onderhoud het ek nooit een keer die gevoel gehad dat daar met my onderhoude gevoer word nie. Daar is 'n gevoel dat jy kode in 'n span ontwikkel. As jy iewers vashaak, help hulle, adviseer, bespreek, stry selfs met mekaar oor hoe om dit die beste te doen. By die onderhoud het ek vergeet hoe om in JUnit 5 na te gaan dat 'n metode 'n Uitsondering gooi - hulle het aangebied om voort te gaan om die toets te skryf, terwyl een van hulle besig was om te google hoe om dit te doen.
Letterlik 'n paar uur na die onderhoud het ek konstruktiewe terugvoer ontvang - waarvan ek gehou het en waarvan ek nie. In my geval is ek geprys omdat ek Sealed-klasse as alternatief vir die nul-objek gebruik het; vir die feit dat ek voor die skryf van die kode in pseudokode geskryf het hoe ek graag die rover wil beheer, en so 'n skets van die klasse ontvang het, ten minste dié wat by die robot se API betrokke is.
Stap 2: Vertel ons
’n Week voor die onderhoud is ek gevra om ’n aanbieding voor te berei oor enige onderwerp wat my interesseer. Die formaat is eenvoudig en bekend: 15 minute aanbieding, 15 minute om vrae te beantwoord.
Ek het Clean Architecture deur Uncle Bob gekies. En weer is ek deur 'n paar mense ondervra. Dit was my eerste ervaring om in Engels aan te bied, en miskien, as ek in 'n stresvolle situasie was, sou ek dit nie kon hanteer nie. Maar weereens, ek het nooit een keer die gevoel gehad dat ek by 'n onderhoud was nie. Alles is soos gewoonlik – ek sê vir hulle, hulle luister mooi. Selfs die tradisionele vraag-en-antwoordsessie was nie soos 'n onderhoud nie; dit was duidelik dat die vrae nie gevra is om te “sink” nie, maar diegene wat hulle werklik in my aanbieding geïnteresseerd het.
'n Paar uur na die onderhoud het ek terugvoer ontvang - die aanbieding was baie nuttig en hulle het dit regtig geniet om te luister.
Fase 3. Produksie Kwaliteit Kode
Nadat ek gewaarsku het dat dit die laaste stadium van tegniese onderhoude is, is ek gevra om die kode by die huis na 'n produksiegereed toestand te bring, dan die kode vir hersiening te stuur en onderhoude te skeduleer waartydens die vereistes vir die taak sou verander en die kode sou verandering vereis. As ek vorentoe kyk, kan ek sê dat die kode-hersiening blindelings uitgevoer word, die beoordelaars ken nie die pos waarvoor die kandidaat aansoek doen nie, hulle sien nie sy CV nie, hulle sien nie eers sy naam nie.
Die telefoon lui, en weer was daar 'n paar ouens aan die ander kant van die monitor. Alles is dieselfde as by die eerste onderhoud: die belangrikste ding is om nie van TDD te vergeet nie, vertel wat jy doen en hoekom. As jy nog nie voorheen TDD beoefen het nie, beveel ek aan om dit dadelik te doen, nie omdat dit nodig is in maatskappye nie, maar omdat dit jou lewe aansienlik vereenvoudig, jou stresvlak verminder as jy wil. Onthou jy hoe jy woes met 'n ontfouter moes soek vir 'n fout wat slegs deur die blaaier gereproduseer kan word, maar jy kan dit nie met toetse reproduseer nie? Stel jou nou voor dat jy so 'n fout tydens 'n onderhoud sal moet vang - jy is verseker 'n paar grys hare. Wat kry ons met TDD? Ons het die kode verander en onverwags besef dat die toetse nou rooi is, maar wat is die fout wat ons nie die eerste keer kan uitvind nie? Goed, ons sê "Oeps" vir die onderhoudvoerders, druk Ctrl-Z en begin klein treetjies vorentoe neem. En ja, jy moet die vermoë ontwikkel om met behulp van TDD in jouself te ontwikkel, die vermoë om na die doel te gaan sodat jou toetse permanent groen is, en nie rooi vir 'n halwe dag nie, want "jy het baie herfaktorering." Dit is presies dieselfde vaardigheid as om onderhoubare kode te skryf, of om produktiewe kode te skryf.
Dus, hoe goed jou kode verander kan word, hang af van watter ontwerp jy in gedagte het om mee te begin, hoe eenvoudig dit is en hoe goed jou toetse is.
Ná die onderhoud het ek binne 'n paar uur terugvoer ontvang. Op hierdie stadium het ek besef dat ek amper deur was en daar was baie min oor totdat ek "Fowler ontmoet het."
Fase 4. Finale. Genoeg tegniese vrae. Ons wil weet wie jy is!
Om eerlik te wees, was ek ietwat verbaas oor hierdie formulering van die vraag. Hoe kan jy verstaan watter soort mens ek is in een uur se gesprek? En meer nog, hoe kan jy dit verstaan as ek 'n taal praat wat nie my moedertaal is nie, en, eerlik gesproke, baie gemeen en tongvol is. In vorige onderhoude was dit vir my persoonlik makliker om te praat eerder as om vrae te beantwoord, en die aksent was te blameer. Ten minste een van die onderhoudvoerders was Asiaties – en hul aksent, wel, kom ons sê net, is ietwat spesifiek vir die Europese oor. Daarom het ek besluit om 'n proaktiewe benadering te volg - berei 'n aanbieding oor myself voor en bied aan die begin van die onderhoud aan om met hierdie aanbieding oor myself te praat. As hulle saamstem, sal daar ten minste minder vrae vir my wees; as hulle die aanbod verwerp, wel, 3 ure van my lewe wat aan 'n aanbieding spandeer word, is nie so 'n hoë prys nie. Maar wat moet jy in jou aanbieding skryf? Biografie - Daar gebore, op daardie tydstip, het skool gegaan, aan die universiteit gegradueer - maar wie gee om?
As jy 'n bietjie Google oor die Thoughtworks-kultuur, sal jy 'n artikel deur Martin Fowler vind [https://martinfowler.com/bliki/ThreePillars.html] wat die 3 pilare beskryf: Volhoubare besigheid, sagteware-uitnemendheid en sosiale geregtigheid.
Kom ons neem aan dat Software Excellence reeds vir my nagegaan is. Dit bly om volhoubare besigheid en sosiale geregtigheid te toon.
Boonop het ek besluit om op laasgenoemde te fokus.
Om mee te begin, het ek hom vertel hoekom ThoughtWorks - ek het Martin Fowler se blog gelees op universiteit, vandaar my liefde vir Clean code.
Projekte kan ook vanuit verskillende hoeke aangebied word. Hy het ook sagteware vir medisyne ontwikkel wat die lewens van pasiënte vereenvoudig het, en selfs, volgens gerugte, een lewe gered het. Ek het ook sagteware vir banke ontwikkel, wat ook die lewe vir burgers makliker gemaak het. Veral as dié bank deur 70% van die land se bevolking gebruik word. Dit gaan nie oor Sberbank nie en nie eers oor Rusland nie.
Wil jy van my weet? OK. My stokperdjie is fotografie, op een of ander manier hou ek al vir so 10 jaar 'n kamera in my hande, daar is foto's wat ek nie te skaam is om te wys nie. Ek het ook op 'n tyd 'n katskuiling gehelp: ek het katte gefotografeer wat 'n permanente huis nodig gehad het. En met goeie foto's is dit baie makliker om 'n kat te plaas. Ek het seker honderd katte afgeneem :)
Op die ou end was 80% van my aanbieding gevul met katte.
Onmiddellik na die aanbieding het HR vir my geskryf dat hy nog nie die resultate van die onderhoud ken nie, maar die hele kantoor was reeds beïndruk met die katte.
Uiteindelik het ek gewag vir terugvoer – ek het almal as mens tevrede gestel.
Maar tydens die laaste gesprek het HR taktvol gesê dat sosiale geregtigheid baie goed en nodig is, maar nie alle projekte is so nie. En hy het gevra of dit my bang maak. Oor die algemeen het ek 'n bietjie oorboord gegaan met Social Justice, dit gebeur :)
Totale
Gevolglik werk ek nou al 'n paar maande in Singapoer by Thoughtworks, en ek sien dat hier te veel maatskappye "beste onderhoudspraktyke" van Google aanneem, deur blare en witbord vir kodering te gebruik, al het hulle meer kennis as Spring, Symfony, RubyOnRails (Onderstreep wat nodig is) word nie in die werk vereis nie. Ingenieurs neem 'n week af voor 'n onderhoud om "voor te berei."
By Thoughtworks is, benewens voldoende vereistes vir die kandidaat, die volgende beginsels op die voorgrond:
Vreugde van onderhoudvoering. Boonop vir beide kante. Inderdaad, as jy die beste personeel wil kry (en wie nie?), dan is 'n onderhoud nie 'n mark waar slawe gekies word nie, maar 'n vertoning waar beide die werkgewer en die kandidaat mekaar evalueer. En as 'n kandidaat aangename emosies met 'n maatskappy assosieer, is dit waarskynlik dat hy hierdie spesifieke maatskappy sal kies
Veelvuldige onderhoudvoerders om vooroordeel te versag. By Thoughtworks is paarprogrammering die de facto standaard. En as hierdie praktyk op ander gebiede toegepas kan word, probeer TW om dit te doen. In elke stadium word die onderhoud deur 2 mense gevoer. Elke persoon word dus deur ten minste 8 mense geassesseer, en TW probeer onderhoudvoerders kies met verskillende agtergronde, verskillende rigtings (nie net tegnologieë nie) en geslag.
Uiteindelik sal die aanstellingsbesluit geneem word op grond van die menings van ten minste 8 mense, en niemand het 'n beslissende stem nie.
Eienskap-gebaseerde verhuring In plaas daarvan om 'n besluit te neem op grond van 'n kandidaat se voor- of afkeure, word 'n vorm vir elke rol en elke stadium ontwikkel wat die eienskappe insluit wat geassesseer word. Terselfdertyd, wanneer assessering, word dit sterk aanbeveel om nie ervaring in 'n sekere vaardigheid te evalueer nie, maar die vermoë om dit toe te pas. As 'n kandidaat dus nie enige vaardighede, soos TDD, kon toepas nie, maar hy probeer dit nogtans toepas, luister na raad oor hoe om dit reg te gebruik, het hy alle kans om die onderhoud te slaag.
Onderwyssertifikate nie nodig nie TW vereis geen sertifisering of opleiding in Rekenaarwetenskap nie. Slegs vaardighede word geassesseer.
Dit is die eerste onderhoud wat ek met buitelandse maatskappye gehad het waarvoor ek nie hoef voor te berei nie. Ná elke stadium het ek nie uitgeput gevoel nie, maar inteendeel, ek was bly dat ek die beste praktyke kon toepas, dat mense aan die ander kant van die monitor dit waardeer en elke dag toegepas het.
Na 'n paar maande kan ek sê dat my verwagtinge ten volle nagekom is. Hoe verskil ThoughtWorks van 'n gewone maatskappy? In 'n gereelde maatskappy kan jy goeie ontwikkelaars en gawe mense vind, maar in TW is hul konsentrasie van die kaarte af.
As jy belangstel om by ThoughtWorks aan te sluit, kan jy ons oop posisies bekyk
Ek stel ook voor dat u aandag gee aan interessante vakatures:
Hoof sagteware-ingenieur: , , ,
Senior sagteware-ingenieur: , , ,
Sagteware ingeneur: , ,
Senior Data Ingenieur:
Kwaliteit ontleder:
Infrastruktuur: , ,
(Ek wil jou eerlik waarsku dat die skakel 'n verwysingsskakel is, as jy na TW gaan, sal ek 'n lekker bonus ontvang). Kies 'n kantoor waarvan u hou, u hoef uself nie tot Europa te beperk nie, immers elke 2 jaar sal TW u graag na 'n ander land verskuif, want ... Dit is deel van die ThoughtWorks-beleid, dus word die kultuur versprei en gehomogeniseer.
Vra gerus vrae in die kommentaar of vra my vir aanbevelings.
As die onderwerp interessant lyk, sal ek skryf oor hoe dit is om by ThoughtWorks te werk en hoe die lewe in Singapoer is.
Bron: will.com