Vai jums šķiet dīvaini, ka, kad gatavojaties mainīt darbu un ir nepieciešams iziet interviju, pirmkārt, jūs domājat: „jāgatavošos intervijai”? Jāatrisina uzdevumi HackerRank, jāizlasa Crack the Coding Interview, jāiemācās, kā darbojas ArrayList un kā tā atšķiras no LinkedList. Ak jā, vēl var vaicāt par šķirošanas algoritmiem, un noteikti būtu neprofesionāli teikt, ka quick sort, visticamāk, būs labākais risinājums.
Bet pagaidiet, jūs taču programmējat 8 stundas dienā, risināt interesantus un netradicionālus uzdevumus, un jaunajā darba vietā darīsiet vairāk vai mazāk to pašu. Bet tomēr, lai izietu interviju, ir jāgatavojas, pat neattīrot ikdienas prasmes, bet iemācoties to, kas jums nebija nepieciešams ne pašreizējā darba vietā, ne visticamāk būs nepieciešams nākamajā. Uz jūsu iebildumiem, ka datorzinātne mums ir asinīs, un, ja jūs pamodināsiet mūs vidū naktī, mēs varam rakstīt algoritmu, kad esam aizvēruši acis uz spilvena pat nenākot prātā, es atbildēšu, ka, ja es dotos strādāt cirkā un mans galvenais triks būtu tieši tas — tad, iespējams, es piekristu. Šo prasmi vajadzētu pārbaudīt.
Bet kāpēc pārbaudīt ar pašreizējo darbu nesaistītas prasmes? Tikai tāpēc, ka tas ir kļuvis moderns? Tāpēc ka tā dara Google? Vai tāpēc, ka jūsu nākamajam komandas vadītājam bija jāiemācās visi šķirošanas metodes, pirms viņš iziet interviju un tagad viņš uzskata, ka „katram labam programmētājam jāzin no galvas, kā implementēt palindromu atrašanu tekstā”.
Tātad, jūs neesat Google (c). Ko Google var atļauties, parastas kompānijas nevar. Google, analizējot savu darbinieku datus, nāca pie secinājuma, ka tieši viņam, tieši viņa uzdevumiem, vislabāk ir strādāt inženieriem ar olimpisko pagātni. Vairāk nekā tas, veidojot atlases procesu, viņi var atļauties ieviest risku, ka viņi varētu nenomāt dažus labus inženierus, jo viņi nepārvalda matemātikas uzdevumu atrisināšanu tik viegli. Bet viņiem tas nav traģiski, vēloties strādāt Google ir daudz, un vakance tiks aizpildīta.
Tagad palūkosimies pa logu, un ja pirms jūsu biroja vēl ir inženieri, kuri vēlas pie jums strādāt, un jūsu izstrādātāji biežāk meklē, kādu jaunu Spring anotāciju vajadzētu ievietot stackoverflow, nevis algu rangēšanas algoritmu nianses, tad, acīmredzot, ir laiks pārdomāt, vai ir vērts kopēt Google.
Ja šoreiz Google ir pievīlis un nav sniedzis atbildi, ko darīt? Pārbaudiet tieši to, ko izstrādātājs darīs darbā. Ko jūs vērtējat izstrādātājos?
Izveidojiet kritērijus, kādus kandidātus jūs vēlaties nolīgt, un izstrādājiet testus, kas pārbauda tieši šīs prasmes.
ThoughtWorks
Kāda saistība šeit ir ar ThoughtWorks? Man tieši šeit ir atrasts paraugs izciliem intervijām. Kas ir ThoughtWorks? Īsumā, tā ir augstas klases konsultāciju kompānija ar birojiem visā pasaulē, sākot no Ķīnas un Singapūras līdz Amerikas kontinentam, kas konsultē programmatūras izstrādē ap 25 gadus. Tai ir savs zinātnes departaments, kuru vada Marts Fowler. Ja jūs meklēsiet sarakstu ar 10 grāmatām, kuras ir jānolas, lai būtu programmatūras inženieris, tad, iespējams, 2-3 no tām būs uzrakstījuši cilvēki no ThoughtWorks, piemēram, Refactoring by Martin Fowler un Building Microservices: Designing Fine-Grained Systems by Sam Newman vai Building Evolutionary Architectures.
autori: Patrick Kua, Rebecca Parsons, Neal Ford.
Uzņēmuma bizness balstās uz visai dārgu pakalpojumu sniegšanu, taču klients maksā par fenomenālu kvalitāti, kas veidojas no ekspertīzes, iekšējiem standartiem un, protams, cilvēkiem. Tāpēc ir būtiski piesaistīt pareizos cilvēkus.
Kas tad ir tie pareizie cilvēki? Protams, katram ir savs viedoklis. ThoughtWorks ir noteikuši, ka viņu biznesa modelim ir svarīgākās prasmes izstrādātājiem:
- Spēja strādāt pāros. Tieši spēja, nevis pieredze vai prasmes. Neviens negaida, ka pie jums nāks cilvēki, kuri jau piecus gadus praktizē pāru programmēšanu. Bet būt atsaucīgam uz citu viedokļiem, pratīt klausīties – tā ir nepieciešama prasme.
- Spēja rakstīt testus, un ideālā gadījumā praktizēt TDD.
- Izprast SOLID un OOP un spēt tās pielietot.
- Prezentēt savu viedokli. Konsultantam nākas strādāt ar pasūtītāja izstrādātājiem, ar citiem konsultantiem, un nav daudz jēgas, ja cilvēks prot kaut ko darīt labi, bet ir pilnīgi nespējīgs to nodot pārējiem komandas locekļiem.
Tagad ir svarīgi novērtēt tieši šīs prasmes kandidātā. Un šeit gribu pastāstīt par savu pieredzi intervijā uzņēmumā ThoughtWorks. Jāsaka uzreiz, ka es tikos Singapūrā un man izdevās tikt cauri, bet atlases process ir standardizēts un būtiski neatšķiras no valsts uz valsti.
Posms 0. HR
Kā tas bieži gadās, 20 minūšu intervija ar HR. Par to neapstāsies, tikai teikšu, ka nekad iepriekš nebiju saskāries ar HR, kurš varētu 15 minūtes stāstīt par uzņēmuma izstrādes kultūru, kāpēc viņi izmanto TDD un kāpēc pāra programmēšana. Parasti šajā brīdī HR atslābst un stāsta, ka viņiem process ir parasts: izstrādātāji izstrādā, testētāji testē, menedžeri spiež uz priekšu.
Posms 1. Cik tu esi labs OOP, TDD?
Pusstundas 1.5 pirms intervijas man atsūtīja uzdevumu izveidot Mars Rover simulāciju.
Uzdevums Mars RoverNASA plāno nolaist robotu rovers uz sastāvdaļas uz Marsa platības. Šai platībai, kas ir dīvaini taisnstūrveida, jābūt navigētai ar roveriem, lai to uz uzbūvētiem kamerām varētu iegūt pilnīgu apkārtējo ainavu, ko nosūtīt atpakaļ uz Zemi. Rovera pozīciju un atrašanās vietu attēlo x un y koordinātu kombinācija un burts, kas apzīmē vienu no četrām galvenajām virziena punktiem. Platība ir dalīta tīklā, lai vienkāršotu navigāciju. Piemēram, pozīcija varētu būt 0, 0, Z, kas nozīmē, ka rovers atrodas apakšējā kreisajā stūrī un ir vērsts uz Ziemeļiem. Lai kontrolētu rovers, NASA nosūta vienkāršu burtu virkni. Iespējamie burti ir 'L', 'R' un 'M'. 'L' un 'R' liek roveram pagriezties pa 90 grādiem pa kreisi vai pa labi attiecīgi, nekustoties no pašreizējās vietas. 'M' nozīmē pārvietoties uz priekšu par vienu tīkla punktu un saglabāt to pašu virzienu.
Pieņem, ka laukums tieši ziemeļus no (x, y) ir (x, y+1).
IEVADS:
Pirmajā ievades līnijā ir augšējā labā koordināta platībai, apakšējā kreisā koordināta tiek uzskatīta par 0,0.
Pārējā ievades informācija attiecas uz roveriem, kas ir izvietoti. Katram roveram ir divas ievades līnijas. Pirmajā līnijā tiek sniegta roveras pozīcija, un otrajā līnijā ir instrukciju virkne, kas stāsta rovers kā izpētīt platformu. Pozīcija sastāv no diviem veseliem skaitļiem un burta, kas atdalīti ar atstarpēm, attiecīgi norādot x un y koordinātas un roveras orientāciju.
Katrs rovers tiks pabeigts secīgi, kas nozīmē, ka otrais rovers nepārvietosies, līdz pirmais būs pabeidzis pārvietoties.
IZVADS:
Izvade katram roveram būtu tā pēdējā koordināta un virziens.
PIEZĪMES:
Vienkārši īstenojiet iepriekš minētās prasības un pierādiet, ka putekļu sūcējs darbojas, rakstot tam vienību testus.
Jebkādas lietotāja saskarnes izveide ir ārpus ietvara.
Problēmas risināšana, sekojot TDD (test driven development) pieejai, būs vēlama.
Īsajā laikā, kas ir pieejams, mēs vairāk uztraucamies par kvalitāti nekā pilnīgumu.
*Es nevaru ievietot uzdevumu, ko man nosūtīja, tas ir vecs uzdevums, kas tika dots pirms dažiem gadiem. Bet ticiet man, principiāli viss palicis tāds pats.
At first, I would like to draw attention to the evaluation criteria. How many times have you encountered situations where things important to the candidate are completely irrelevant during the assessment and vice versa? Not everyone thinks the same way you do, but many can adopt your values and follow them if they are clearly outlined. Thus, from the evaluation criteria, it is immediately clear that the most important skills at this stage are
- TDD;
- The ability to use OOP and write maintainable code;
- The ability to program in pairs
So, I was warned to spend these 1.5 hours thinking about how I'm going to approach the task rather than writing code. We will write the code together.
When we connected, the guys briefly introduced themselves and what they do and suggested starting the development.
Throughout the entire interview, I never had the feeling that I was at an interview. It feels like you are developing code as part of a team. If you get stuck somewhere, they help, advise, discuss, even argue among themselves about the best way to do it. During the interview, I forgot how to check in JUnit 5 whether a method throws an Exception — they suggested continuing to write the test while one of them Googled how to do it.
Literally a few hours after the interview, I received constructive feedback — what was liked and what was not. In my case, I was praised for using Sealed classes as an alternative to null objects; for writing pseudo-code before writing the actual code on how I would like to control the rover, which allowed me to sketch out the classes, at least those involved in the robot's API.
Stage 2. Tell us
A week before the interview, I was asked to prepare a presentation on any topic that interests me. The format is simple and familiar: 15 minutes for the presentation, 15 minutes for questions.
Es izvēlējos Clean Architecture by Uncle Bob. Un atkal mani intervēja divi cilvēki. Tā bija mana pirmā pieredze prezentēšanā angļu valodā, un, iespējams, ja es būtu stresa situācijā, es neizturētu. Bet, atkal, man nekad nebija sajūtas, ka esmu intervijā. Viss kā parasti — es stāstu, viņi uzmanīgi klausās. Pat tradicionālā jautājumu un atbilžu sesija nebija līdzīga intervijai; bija redzams, ka jautājumus uzdod nevis, lai “nogremdētu”, bet tādus, kas viņus patiešām interesēja manā prezentācijā.
Pāris stundas pēc intervijas saņēmu atsauksmi — prezentācija bija ļoti noderīga un viņi guva patiesu prieku no klausīšanās.
3. posms. Ražošanas kvalitātes kods
Brīdināju, ka tas ir pēdējais tehnisko interviju posms, un man tika lūgts mājās sagatavot kodu ražošanas gatavībā, pēc tam atsūtīt kodu uz revīziju un noteikt interviju, kurā uzdevuma prasības mainīsies un kods prasīs modifikācijas. Paskatoties uz priekšu, varu teikt, ka kods tiek pārskatīts akli; recenzenti nezina ne pozīciju, uz kuru pretendē kandidāts, ne redz viņa CV, pat nezina viņa vārdu.
Saruna, un atkal pāris pušu pie datora ekrāna. Viss ir kā pirmajā intervijā: galvenais ir neaizmirst par TDD, stāstīt, ko tu dari un kāpēc. Ja iepriekš neesi praktizējis TDD, tad es ieteiktu uzsākt to nekavējoties, nevis tāpēc, ka tas ir nepieciešams uzņēmumos, bet gan tāpēc, ka tas ievērojami atvieglo tavu dzīvi, samazinot stresa līmeni, ja vēlies. Atceries, kā nācās nervozi meklēt kļūdu, kuru var reproducēt tikai pārlūkā, bet tests to nedara? Tagad iedomājies, ka tev jāatrod šāda kļūda intervijas laikā — pāris pelēku matu būs garantēti. Ko mums sniedz TDD? Tu maini kodu un pēkšņi saproti, ka tagad testi ir sarkani, bet nevari saprast, kur ir kļūda? Labi, sakām intervētājiem “Ups”, nospiežam Ctrl-Z un sākam soļot uz priekšu maziem solīšiem. Un jā, prasme izstrādāt, izmantojot TDD, ir jāattīsta, spēja virzīties uz mērķi tā, lai testi pastāvīgi būtu zaļi, nevis sarkani pusdienu laikā, jo “tev ir liels refaktors”. Tas ir tieši tāds pats prasmes komplekts kā spēja rakstīt uzturamu kodu vai efektīvu kodu.
Tātad, cik labi tavs kods pakļaujas izmaiņām, ir atkarīgs no tā, kādu dizainu tu sākotnēji esi iecerējis, cik tas ir vienkāršs un cik labi ir tavi testi.
Pēc intervijas es saņēmu atsauksmes pēc dažām stundām. Šajā posmā es sapratu, ka es praktiski esmu izturējis un palicis pavisam nedaudz līdz “tikties ar Fauleri”.
Posms 4. Fināls. Pietiekami tehniski jautājumi. Mēs gribam zināt, kas tu esi!
Godīgi sakot, šāda jautājuma izvirzīšana mani nedaudz mulsināja. Kā var saprast, kas es esmu, tikai pēc vienas sarunas stundas? Un vēl jo vairāk, kā to var saprast, kad es runāju valodā, kas nav dzimtā, un, atklāti sakot, pavisam slikti un neveikli. Iepriekšējās intervijās man bija vieglāk stāstīt par sevi, nekā atbildēt uz jautājumiem, un tam par iemeslu bija akcents. Vismaz viens no intervētājiem bija aziāts — to akcents, nu, teiksim tā, ir diezgan specifisks eiropiešu ausīm. Tādēļ es nolēmu izmantot proaktīvu pieeju — sagatavot prezentāciju par sevi un intervijas sākumā piedāvāt stāstīt par sevi ar šo prezentāciju. Ja viņi piekritīs — tad vismaz man būs mazāk jautājumu, ja noraidīs piedāvājumu — nu ko, 3 stundu mans dzīves laiks, kas veltīts prezentācijai, nav tik liela cena. Bet ko rakstīt prezentācijā? Biogrāfiju — Piedzimis tajā un tajā, tajā un tajā gadā, gājis skolā, pabeidzis universitāti — nu, kam tas interesē?
Ja nedaudz pacenšas izpētīt Thoughtworks kultūru, var atrast Martina Faulera rakstu [https://martinfowler.com/bliki/ThreePillars.html], kurā aprakstīti 3 pīlāri: Ilgtspējīga biznesa, programmatūras izcilība un sociālā taisnīgums.
Pieņemsim, ka programmatūras izcilību jau ir pārbaudījuši. Paliek pierādīt ilgtspējīgu biznesu un sociālo taisnīgumu.
Tādēļ es nolēmu koncentrēties uz pēdējo.
Sāku ar to, kāpēc ThoughtWorks — vēl studiju laikā lasīju Martina Faulera blogu, un tādēļ man ir mīlestība uz Clean code.
Projektus var pasniegt no dažādiem skatpunktiem. Es izstrādāju programmatūru medicīnai, kas atvieglo pacientu dzīvi, un pat, pēc baumām, izglāba vienu dzīvību. Es izstrādāju arī programmatūru bankām, kas ir savā ziņā atvieglojums iedzīvotājiem. It īpaši, ja šo banku izmanto apmēram 70% valsts iedzīvotāju. Runas nav par Sberbank, un pat ne par Krieviju.
Vēlaties uzzināt par mani? Labi. Mans hobijs ir fotografēšana, vismaz jau kādus 10 gadus turu fotoaparātu rokās, man ir fotogrāfijas, kuras nav kauns parādīt. Tāpat kādu laiku es palīdzēju kaķu patversmei: fotografēju kaķus, kuriem nepieciešama pastāvīga māja. Un ar labām fotogrāfijām ir krietni vieglāk atrast kaķim jaunas mājas. Varbūt esmu nofotografējis ap simtu kaķu 🙂
Galu galā, 80% no prezentācijas man bija aizpildīts ar kaķiem.
Uzreiz pēc prezentācijas man uzrakstīja HR, ka viņš vēl nezina intervijas rezultātus, bet visi birojs jau ir ietekmēti no kaķiem.
Galu galā es sagaidīju atgriezenisko saiti - es apmierināju visus kā personību.
Bet HR finālā sarunā taktiski pastāstīja, ka Sociālā taisnīgums ir ļoti labi un vajadzīgs, bet ne visi projekti ir tādi. Un viņš jautāja, vai tas mani nebaida. Kopumā, es nedaudz pārspīlēju ar Sociālo taisnīgumu, tā gadās 🙂
Rezultāts
Kā rezultātā, es jau vairākus mēnešus strādāju Singapūrā uzņēmumā Thoughtworks, redzu, ka arī šeit daudz uzņēmumu pārņem “labākās interviju prakses” no Google, izmantojot papīra lapas un Whiteboard kodēšanai, neskatoties uz to, ka darbos nav nepieciešamas zināšanas tālāk par Spring, Symfony, RubyOnRails (vajadzīgo uzsvērt). Inženieri ņem nedēļu atvaļinājumu pirms intervijas, lai “sagatavotos”.
Thoughtworks gadījumā, papildus adekvātām prasībām pret kandidātu, tiek izvirzīti šādi principi:
Intervijas prieks. Savukārt abām pusēm. Patiesi, ja vēlaties iegūt vislabākos darbiniekus (bet kurš gan to nevēlas?), tad intervija - tas nav tirgus, kur izvēlas vergu, bet drīzāk skatīšanās, kur darba devējs un kandidāts vērtē viens otru. Un, ja kandidātam ar uzņēmumu saistās patīkamas emocijas - ir visai iespējams, ka viņš izvēlēsies tieši šo uzņēmumu.
Daudzveidīgi intervētāji, lai mazinātu aizspriedumus. Thoughtworks partnerprogramēšana ir de facto standarts. Un, ja šo praksi var piemērot citās jomās, TW cenšas to darīt. Katram solim interviju veikts diviem cilvēkiem. Tādējādi katru cilvēku vērtē vismaz 8 cilvēki, un TW cenšas izvēlēties intervētājus ar dažādu fona, dažādām jomām (ne tikai tehniskiem) un dzimumiem.
Galu galā lēmums par pieņemšanu darbā tiks pieņemts, balstoties uz vismaz 8 cilvēku viedokļa, un nevienam nav tiesību uzticēt galīgo balsošanu.
Atribūtu balstīta pieņemšana Vietā tam, lai pieņemtu lēmumu, pamatojoties uz kandidāta „patīk / nepatīk”, katrai lomai un katram posmam ir izstrādāta veidlapa, kas iekļauj vērtējamās īpašības. Pie tam, vērtējot, tiek ļoti ieteikts vērtēt nevis pieredzi noteiktā prasmē, bet spēju to piemērot. Tādējādi, ja kandidātam nebija iespēju pielietot kādas prasmes, piemēram, TDD, bet viņš tomēr cenšas to pielietot, klausās padomus par pareizu izmantošanu – viņam ir visas iespējas iziet interviju.
Izglītības sertifikāti nav nepieciešami. TW neprasa no kandidāta obligātus sertifikātus vai izglītību datorzinātnēs. Tiek vērtētas tikai prasmes.
Šī ir pirmā intervija, uz kuru es devos foreign companies, pie kuras man nebija jāsagatavojas. Pēc katra posma es nejutos kā izspiests citrons, bet tieši pretēji, es biju priecīgs, ka varu piemērot labākās prakses, ka cilvēki pie monitora to novērtē un arī katru dienu tās pielieto.
Pēc dažiem mēnešiem varu teikt, ka gaidīšanas ir pilnībā pamatotas. Ar ko ThoughtWorks atšķiras no parastās kompānijas? Parastā kompānijā jūs varat atrast labus izstrādātājus un patīkamus cilvēkus, bet TW koncentrācija ir ievērojami augstāka.
Ja vēlaties pievienoties ThoughtWorks, atvērtās vakances var apskatīt
Tāpat iesaku pievērst uzmanību interesantām vakancēm:
Vadošais programmatūras inženieris: , , ,
Vecākais programmatūras inženieris: , , ,
Programmatūras inženieris: , ,
Vecākais datu inženieris:
Kvalitātes analīzi:
Infrastruktūra: , ,
(Es gribu godīgi brīdināt, ka saite ir atsaucīga, ja jūs iziesiet uz TW, tad es saņemšu patīkamu bonusu). Izvēlieties biroju, kas jums patīk, nav obligāti ierobežoties tikai ar Eiropu, galu galā, ik pēc 2 gadiem TW būs priecīgs pārvietot jūs uz citu valsti, jo tā ir ThoughtWorks politika, tādējādi kultūra tiek izplatīta un izlīdzināta.
Nešaubieties uzdot jautājumus komentāros vai lūgt mani jūs ieteikt.
Ja tēma izrādījās interesanta, es uzrakstīšu par to, kā ir strādāt ThoughtWorks un kā ir dzīvot Singapūrā.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish