Ĉu ne ŝajnas strange al vi, ke kiam vi estas ŝanĝonta laborpostenon kaj aperas la bezono pasigi intervjuon, la unua afero, kiun vi pensas, estas "vi devas prepari por la intervjuo." Solvu problemojn en HackerRank, legu Kraku la kodan intervjuon, parkerigu kiel funkcias ArrayList kaj kiel ĝi diferencas de LinkedList. Ho jes, ili ankaŭ povus demandi pri ordigo, kaj evidente estus neprofesie diri, ke rapida ordigo plej verŝajne estus la plej bona elekto.
Sed atendu, vi planas 8 horojn tage, solvas interesajn kaj ne-bagalajn problemojn, kaj ĉe via nova laboro vi faros la saman, plus aŭ minus. Sed tamen, por trapasi intervjuon, vi devas iel aldone prepari, eĉ ne perfektigi viajn ĉiutagajn kapablojn, sed lerni ion, kion vi ne bezonis ĉe via nuna laboro kaj verŝajne ne bezonos ĉe via venonta. Al viaj obĵetoj, ke komputiko estas en nia sango, kaj se vi vekas nin en la mezo de la nokto, ni estas devigataj skribi kun la okuloj fermitaj sur kapkuseno promenadon ĉirkaŭ la larĝo de arbo sen eĉ rekonsciiĝi, mi respondos, ke se mi ricevos laboron en la cirko, kaj mia ĉefa afero la lertaĵo estus ĝuste ĉi tio – tiam eble jes, mi konsentas. Ĉi tiu kapablo devas esti provita.
Sed kial testi kapablojn, kiuj estas senrilataj al via nuna laboro? Nur ĉar ĝi fariĝis modo? Ĉar Guglo faras tion? Aŭ ĉar via estonta teamestro devis lerni ĉiujn ordigmetodojn antaŭ la intervjuo kaj nun li kredas ke "ĉiu bona programisto devas parkere scii la efektivigon de trovado de palindromo en ŝnuro."
Nu, vi ne estas Guglo (c). Kion Guglo povas pagi, ordinaraj kompanioj ne povas. Google, analizinte la datumojn de siaj dungitoj, venis al la konkludo, ke inĝenieroj kun olimpika fono kapablas trakti ĝiajn specifajn taskojn. Plie, projektante sian elektan procezon, ili povas permesi al ili riski, ke ili eble ne dungas kelkajn bonajn inĝenierojn ĉar ili ne povas facile rompi matematikajn problemojn. Sed ĉi tio ne estas problemo por ili, estas multaj homoj, kiuj volas labori ĉe Google, la posteno estos fermita.
Nun ni rigardu tra la fenestro, kaj se antaŭ via oficejo la inĝenieroj, kiuj volas labori por vi, ankoraŭ ne starigis tendon, kaj viaj programistoj pli ofte serĉas sur stackoverflow, kian sekvan Printempan komentarion necesas instali, prefere ol la komplikaĵoj de ranking algoritmoj, tiam, ŝajne, Estas tempo por vi pripensi ĉu vi devus kopii Guglon.
Nu, se ĉi-foje Guglo malsukcesis kaj ne donis respondon, kion vi faru? Kontrolu ĝuste kion la programisto faros en la laboro. Kion vi taksas ĉe programistoj?
Faru kriteriojn por kiu vi volas dungi kaj evoluigi testojn kiuj testas ĝuste ĉi tiujn kapablojn.
ThoughtWorks
Kion rilatas ThoughtWorks al ĉi tio? Ĝuste ĉi tie mi trovis ekzemplon de ekzempla intervjuo por mi mem. Kiuj estas ThoughtWorks? Resume, ĉi tio estas Altnivela konsulta kompanio kun oficejoj en la tuta mondo, de Ĉinio, Singapuro ĝis la amerikaj kontinentoj, kiu konsultas en la kampo de disvolviĝo de ĉirkaŭ 25 jaroj, havas sian propran Sciencan divizion, estratan de Martin. Fowler. Se vi serĉas liston de 10 nepre legindaj libroj por Programaro-Inĝeniero, tiam eble 2-3 el ili estos skribitaj de la uloj de ThoughtWorks, kiel Refactoring By Martin Fowler kaj Building Microservices: Designing Fine-Grained Systems de Sam Newman aŭ Building Evolutionary Architectures
de Patrick Kua, Rebecca Parsons, Neal Ford.
La komerco de la firmao estas konstruita sur provizado de sufiĉe multekostaj servoj, sed la kliento pagas por fenomena kvalito, kiu konsistas el kompetenteco, internaj normoj kaj, kompreneble, homoj. Tial, dungi la ĝustajn homojn estas esenca ĉi tie.
Kiaj homoj pravas? Kompreneble, estas malsamaj por ĉiuj. ThoughtWorks determinis, ke la plej gravaj kriterioj por sia programista komercmodelo estas:
- Kapablo disvolvi en paroj. Ĝi estas kapablo, ne sperto aŭ lerteco. Neniu atendas, ke venos homoj, kiuj praktikas Parprogramadon dum 5 jaroj.Sed esti akceptema al la opinioj de aliaj homoj kaj povi aŭskulti estas necesa kapablo.
- Kapablo skribi testojn, kaj ideale praktiki TDD
- Komprenu SOLID kaj OOP kaj povu apliki ilin.
- Prezentu vian opinion. Kiel konsultisto, vi devas labori kun la programistoj de la kliento, kun aliaj konsultistoj, kaj ne estas multe da utilo se homo scias kiel fari ion bone, sed tute ne kapablas transdoni ĝin al la resto de la teamo.
Nun gravas taksi ĉi tiujn apartajn kapablojn en la kandidato. Kaj ĉi tie mi volas paroli pri mia sperto de intervjuado ĉe ThoughtWorks. Mi tuj diros, ke mi iris al Singapuro kaj pasis, sed la varba procezo estas unuigita kaj ne multe diferencos de lando al lando.
Etapo 0. HR
Kiel ofte okazas, 20-minuta intervjuo kun HR. Mi ne traktos ĝin, mi nur diros, ke mi neniam renkontis HR-personon, kiu povus paroli dum 15 minutoj pri la disvolva kulturo en la kompanio, kial ili uzas TDD, kial parprogramado. Kutime, HR-oj velkas pri ĉi tiu demando kaj diras, ke ilia procezo estas normala: programistoj disvolvas, testistoj testas, administrantoj veturas.
Etapo 1. Kiom bona vi estas ĉe OOP, TDD?
1.5 horojn antaŭ la komenco de la intervjuo, oni sendis al mi taskon fari simulilon de Mars Rover.
Misio de marsa esplorveturiloTaĉmento de robotaj esplorveturiloj estas surteriĝota de NASA sur altebenaĵon sur Marso. Ĉi tiu altebenaĵo, kiu estas kurioze rektangula, devas esti navigita de la esplorveturiloj por ke iliaj surŝipaj fotiloj povu akiri kompletan vidon de la ĉirkaŭa tereno por sendi reen al la Tero. La pozicio kaj loko de esplorveturilo estas reprezentitaj per kombinaĵo de x kaj y-koordinatoj kaj letero reprezentanta unu el la kvar kardinalaj kompaspunktoj. La altebenaĵo estas dividita supren en kradon por simpligi navigacion. Ekzempla pozicio povus esti 0, 0, N, kio signifas, ke la esplorveturilo estas en la malsupra maldekstra angulo kaj turniĝas al Nordo. Por kontroli esplorveturilon, NASA sendas simplan ŝnuron da leteroj. La eblaj literoj estas 'L', 'R' kaj 'M'. "L" kaj "R" igas la esplorveturilon turni 90 gradojn maldekstren aŭ dekstren respektive, sen moviĝado de ĝia nuna loko. "M" signifas antaŭeniri unu kradpunkton, kaj konservi la saman titolon.
Supozu ke la kvadrato rekte Norda de (x, y) estas (x, y+1).
ENIGO:
La unua linio de enigo estas la supra-dekstraj koordinatoj de la altebenaĵo, la malsupra-maldekstraj koordinatoj estas supozitaj esti 0,0.
La resto de la enigo estas informoj pri la esplorveturiloj kiuj estis deplojitaj. Ĉiu esplorveturilo havas du liniojn de enigo. La unua linio donas la pozicion de la esplorveturilo, kaj la dua linio estas serio de instrukcioj rakontantaj al la esplorveturilo kiel esplori la altebenaĵon. La pozicio konsistas el du entjeroj kaj litero apartigitaj per spacoj, egalrilatante al la x kaj y-koordinatoj kaj la orientiĝo de la esplorveturilo.
Ĉiu esplorveturilo estos finita sinsekve, kio signifas, ke la dua esplorveturilo ne komencos moviĝi ĝis la unua finiĝos.
EKZAMENO:
La eligo por ĉiu esplorveturilo devus esti ĝiaj finaj koordinatoj kaj titolo.
NOTOJ:
Simple efektivigu la suprajn postulojn kaj pruvu, ke polvosuĉilo funkcias skribante unutestojn por ĝi.
Krei ajnan formon de uzantinterfaco estas ekstere de amplekso.
Solvi la problemon sekvante TDD (Test Driven Development) aliron estos preferita.
En la mallonga tempo disponebla, ni pli zorgas pri kvalito ol kompleteco.
*Mi ne povas afiŝi la taskon kiu estis sendita al mi, ĉi tio estas malnova tasko kiu estis donita antaŭ pluraj jaroj. Sed kredu min, esence ĉio restas sama.
Mi precipe ŝatus atentigi pri la pritaksaj kriterioj. Kiom da fojoj vi renkontis situacion, kie aferoj, kiuj estas gravaj por kandidato, estas tute negravaj dum la revizio kaj inverse. Ne ĉiuj pensas same kiel vi, sed multaj povas akcepti kaj sekvi viajn valorojn se ili estas klare dirite. Do, el la taksaj kriterioj estas tuj klare, ke la plej gravaj kapabloj en ĉi tiu etapo estas
- TDD;
- Kapablo uzi OOP kaj skribi konserveblan kodon;
- paraj programaj kapabloj
Do, mi estis avertita pasigi tiujn 1.5 horojn pensante pri kiel mi faros la taskon, prefere ol skribi kodon. Ni skribos la kodon kune.
Kiam ni telefonis, la infanoj mallonge diris al ni, kiuj ili estas kaj kion ili faras, kaj proponis komenci disvolviĝon.
Dum la tuta intervjuo, mi neniam havis la senton, ke mi estas intervjuita. Estas sento, ke vi disvolvas kodon en teamo. Se vi blokiĝas ie, ili helpas, konsilas, diskutas, eĉ diskutas unu kun la alia pri kiel plej bone fari ĝin. Ĉe la intervjuo, mi forgesis kiel kontroli en JUnit 5 ke metodo ĵetas Escepton - ili proponis daŭrigi verki la teston, dum unu el ili guglos kiel fari ĝin.
Laŭvorte kelkajn horojn post la intervjuo, mi ricevis konstruivan reagojn - kion mi ŝatis kaj kion mi ne ŝatis. En mia kazo, mi estis laŭdita pro uzado de Sigelitaj klasoj kiel alternativo al la nula objekto; pro tio, ke antaŭ skribi la kodon, mi skribis pseŭdokode kiel mi ŝatus regi la rover, kaj tiel ricevis skizon de la klasoj, almenaŭ tiuj, kiuj estas implikitaj en la API de la roboto.
Paŝo 2: Diru al ni
Semajnon antaŭ la intervjuo, mi estis petita prepari prezenton pri iu ajn temo, kiu interesas min. La formato estas simpla kaj konata: 15 minutoj prezento, 15 minutoj respondante demandojn.
Mi elektis Puran Arkitekturon de Onklo Bob. Kaj denove mi estis intervjuita de paro da homoj. Ĉi tio estis mia unua sperto de prezentado en la angla, kaj, eble, se mi estus estinta en streĉa situacio, mi ne estus povinta elteni. Sed denove, mi neniam havis la senton, ke mi estas ĉe intervjuo. Ĉio estas kiel kutime – mi diras al ili, ili atente aŭskultas. Eĉ la tradicia demando-respondo-sesio ne estis kiel intervjuo; estis klare, ke la demandoj ne estis petitaj "mallevi", sed tiuj kiuj vere interesis ilin en mia prezento.
Kelkajn horojn post la intervjuo, mi ricevis komentojn - la prezento estis tre utila kaj ili vere ĝuis aŭskulti.
Etapo 3. Kodo de Kvalito de Produktado
Avertinte, ke ĉi tio estas la lasta etapo de teknikaj intervjuoj, mi estis petita alporti la kodon hejme al produktadpreta stato, tiam sendi la kodon por revizio kaj plani intervjuojn ĉe kiuj la postuloj por la tasko ŝanĝiĝus kaj la kodo estus. postulas modifon. Rigardante antaŭen, mi povas diri, ke la koda revizio estas farita blinde, la recenzistoj ne scias la postenon, por kiu la kandidato kandidatiĝas, ili ne vidas lian CV, ili eĉ ne vidas lian nomon.
La telefono sonoris, kaj denove estis paro da uloj aliflanke de la ekrano. Ĉio estas sama kiel ĉe la unua intervjuo: la ĉefa afero estas ne forgesi pri TDD, rakontu, kion vi faras kaj kial. Se vi ne praktikis TDD antaŭe, tiam mi rekomendas komenci ĝin tuj, ne ĉar ĝi estas necesa en kompanioj, sed ĉar ĝi signife simpligas vian vivon, reduktas vian streĉan nivelon se vi ŝatas. Memoru, kiel vi devis freneze serĉi per erarserĉilo eraron, kiu nur reprodukteblas per la retumilo, sed vi ne povas reprodukti ĝin per testoj? Nun imagu, ke vi devos kapti tian eraron dum intervjuo - vi estas garantiitaj kelkaj grizaj haroj. Kion ni ricevas kun TDD? Ni ŝanĝis la kodon kaj neatendite rimarkis, ke nun la testoj estas ruĝaj, sed kia estas la eraro, kiun ni ne povas eltrovi la unuan fojon? Bone, ni diras "Oops" al la intervjuantoj, premu Ctrl-Z kaj komencu fari malgrandajn paŝojn antaŭen. Kaj jes, vi devas evoluigi la kapablon disvolvi uzante TDD en vi mem, la kapablon iri al la celo por ke viaj testoj estu konstante verdaj, kaj ne ruĝaj dum duontago, ĉar "vi havas multan refaktoradon." Ĉi tio estas ĝuste la sama kapablo kiel skribi konserveblan kodon, aŭ skribi produktivan kodon.
Do, kiom bone via kodo povas esti ŝanĝita dependas de kia dezajno vi havas en menso por komenci, kiom simpla ĝi estas, kaj kiom bonaj estas viaj testoj.
Post la intervjuo, mi ricevis sugestojn ene de kelkaj horoj. En ĉi tiu etapo, mi rimarkis, ke mi preskaŭ trapasis kaj restis tre malmulte ĝis mi "renkontis Fowler".
Etapo 4. Finalo. Sufiĉe teknikaj demandoj. Ni volas scii, kiu vi estas!
Verdire, mi estis iom konfuzita de ĉi tiu formulo de la demando. Kiel vi povas kompreni kia homo mi estas en unu horo da konversacio? Kaj eĉ pli, kiel vi povas kompreni ĉi tion, kiam mi parolas lingvon kiu ne estas mia gepatra lingvo, kaj, sincere parolante, tre aĉa kaj lang-ligita. En antaŭaj intervjuoj, estis pli facile por mi persone paroli prefere ol respondi demandojn, kaj la akcento estis kulpa. Almenaŭ unu el la intervjuantoj estis azia – kaj ilia akcento, nu, ni nur diru, estas iom specifa por la eŭropa orelo. Tial, mi decidis preni iniciateman aliron - preparu prezenton pri mi kaj komence de la intervjuo ofertu paroli pri mi per ĉi tiu prezento. Se ili konsentas, tiam almenaŭ estos malpli da demandoj por mi; se ili malakceptas la oferton, nu, 3 horoj de mia vivo pasigitaj por prezentado ne estas tiom alta prezo. Sed kion vi skribu en via prezento? Biografio - Naskita tie, tiutempe, iris al lernejo, diplomiĝis de universitato - sed kiu zorgas?
Se vi Google iomete pri la kulturo de Thoughtworks, vi trovos artikolon de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] kiu priskribas la 3 Kolonojn: Daŭrigebla Komerco, Programaro-Plejboneco kaj Socia Justeco.
Ni supozu, ke Software Excellence jam estis kontrolita por mi. Restas montri Daŭrigebla Komerco kaj Socia Justeco.
Cetere, mi decidis koncentriĝi pri ĉi-lasta.
Komence, mi diris al li kial ThoughtWorks - mi legis la blogon de Martin Fowler reen en la universitato, tial mia amo por Pura kodo.
Projektoj ankaŭ povas esti prezentitaj de malsamaj anguloj. Li ankaŭ evoluigis programaron por medicino kiu simpligis la vivojn de pacientoj, kaj eĉ, laŭ onidiroj, savis unu vivon. Mi ankaŭ evoluigis programaron por bankoj, kiu ankaŭ faciligis la vivon al civitanoj. Precipe se ĉi tiu banko estas uzata de 70% de la loĝantaro de la lando. Ĉi tio ne temas pri Sberbank kaj eĉ ne pri Rusio.
Ĉu vi volas scii pri mi? BONE. Mia ŝatokupo estas fotado, iel aŭ alie mi tenas fotilon en miaj manoj dum ĉirkaŭ 10 jaroj, estas fotoj, kiujn mi ne tro embarasas montri. Ankaŭ, iam, mi helpis katŝirmejon: mi fotis katojn kiuj bezonis konstantan hejmon. Kaj kun bonaj fotoj estas multe pli facile meti katon. Mi verŝajne fotis cent katojn :)
En la fino, 80% de mia prezento estis plenigita de katoj.
Tuj post la prezento, HR skribis al mi, ke li ankoraŭ ne konis la rezultojn de la intervjuo, sed la tuta oficejo jam estis impresita pri la katoj.
Finfine, mi atendis reagojn - mi kontentigis ĉiujn kiel homon.
Sed dum la fina konversacio, HR takte diris, ke Socia Justeco estas tre bona kaj necesa, sed ne ĉiuj projektoj estas tiaj. Kaj li demandis, ĉu tio timigis min. Ĝenerale, mi iom ekstermis kun Socia Justeco, okazas :)
La rezulto
Kiel rezulto, mi laboras en Singapuro ĉe Thoughtworks jam de pluraj monatoj, kaj mi vidas, ke ĉi tie tro multaj kompanioj adoptas "plej bonajn intervjuajn praktikojn" de Guglo, uzante foliojn kaj Blanktabulon por kodigo, malgraŭ havi pli da scio ol Printempo, Symfony, RubyOnRails (Substreku kio estas necesa) ne estas bezonata en la laboro. Inĝenieroj prenas semajnon libere antaŭ intervjuo por "prepari".
Ĉe Thoughtworks, krom taŭgaj postuloj por la kandidato, la sekvaj principoj estas ĉe la avangardo:
Ĝojo de Intervjuado. Krome, por ambaŭ flankoj. Efektive, se vi volas akiri la plej bonan dungitaron (kaj kiu ne?), tiam intervjuo ne estas merkato, kie oni elektas sklavojn, sed spektaklo, kie kaj la dunganto kaj la kandidato taksas unu la alian. Kaj se kandidato asocias agrablajn emociojn kun kompanio, verŝajne li elektos ĉi tiun apartan kompanion
Multoblaj intervjuantoj por mildigi biason. Ĉe Thoughtworks, parprogramado estas la fakta normo. Kaj se ĉi tiu praktiko povas esti aplikita al aliaj areoj, TW provas fari tion. En ĉiu etapo, la intervjuo estas farita de 2 homoj. Tiel, ĉiu persono estas taksita de almenaŭ 8 homoj, kaj TW provas elekti intervjuantojn kun malsamaj fonoj, malsamaj direktoj (ne nur teknikistoj) kaj sekso.
Finfine, la dunga decido estos farita surbaze de la opinioj de almenaŭ 8 homoj, kaj neniu havas decidan voĉon.
Atribut-bazita dungado Anstataŭ fari decidon bazitan sur la ŝatoj aŭ malŝatoj de kandidato, formo estas evoluigita por ĉiu rolo kaj ĉiu stadio kiu inkludas la atributojn estantajn taksitaj. Samtempe, kiam oni taksas, estas tre rekomendinde taksi ne sperton pri certa kapablo, sed la kapablon apliki ĝin. Tiel, se kandidato ne povis apliki ajnajn kapablojn, kiel TDD, sed tamen li provas apliki ilin, aŭskultas konsilojn pri kiel uzi ilin ĝuste, li havas ĉiujn ŝancojn pasi la intervjuon.
Edukaj Atestiloj ne necesas TW ne postulas ajnan atestadon aŭ edukadon pri Komputado. Nur kapabloj estas taksitaj.
Jen la unua intervjuo, kiun mi havis kun eksterlandaj kompanioj, por kiuj mi ne devis prepariĝi. Post ĉiu etapo, mi ne sentis min elĉerpita, sed male, mi ĝojis, ke mi povas apliki la plej bonajn praktikojn, ke homoj ĉe la alia flanko de la monitoro aprezis ĝin kaj aplikis ilin ĉiutage.
Post kelkaj monatoj, mi povas diri, ke miaj atendoj plene plenumis. Kiel ThoughtWorks diferencas de kutima kompanio? En kutima kompanio vi povas trovi bonajn programistojn kaj simpatiajn homojn, sed en TW ilia koncentriĝo estas ekster la furorlisto.
Se vi interesiĝas aliĝi al ThoughtWorks, vi povas vidi niajn malfermitajn postenojn
Mi ankaŭ proponas atenti interesajn vakantaĵojn:
Ĉefa Programaro-Inĝeniero: , , ,
Altranga Programaro-Inĝeniero: , , ,
Programaro Inĝeniero: , ,
Altranga Datuma Inĝeniero:
Kvalita Analizisto:
Infrastrukturo: , ,
(Mi ŝatus honeste averti vin, ke la ligilo estas referenca ligilo, se vi iros al TW, mi ricevos belan gratifikon). Elektu oficejon, kiun vi ŝatas, vi ne devas limigi vin al Eŭropo, finfine, ĉiujn 2 jarojn TW volonte translokos vin al alia lando, ĉar... Ĉi tio estas parto de la politiko de ThoughtWorks, do la kulturo estas disvastigita kaj homogenigita.
Bonvolu demandi demandojn en la komentoj aŭ peti al mi rekomendojn.
Se la temo ŝajnas interesa, mi skribos pri kia estas labori ĉe ThoughtWorks kaj kia estas la vivo en Singapuro.
fonto: www.habr.com