Не ви ли се струва странно, че когато възнамерявате да смените работното си място и трябва да преминете интервю, първото нещо, за което мислите, е: "трябва да се подготвя за интервюто"? Решавате задачи в HackerRank, четете Crack the Coding Interview, запаметявате как работи ArrayList и с какво се различава от LinkedList. Ах да, могат да ви питат и за сортировки, и определено би било непрофесионално да кажете, че quick sort вероятно е най-добрият избор.
Но изчакайте, вие програмирате 8 часа на ден, решавате интересни и нетривиални задачи, а на новото работно място ще правите плюс-минус същото. Независимо от това, за да преминете интервюто, е необходимо допълнително да се подготвяте, дори не да усъвършенствате ежедневните си умения, а да научите неща, които не ви трябват на настоящото място и вероятно няма да ви трябват и на следващото. На вашите възражения, че компютърните науки са в нашата кръв и че, ако ни събудите посред нощ, бихме могли да напишем обход на дърво в ширина с затворени очи, дори без да сме напълно наясно с това, ще отговоря, че ако отивам на работа в цирка и основният ми трик е точно това – тогава да, съгласен съм. Трябва да проверите този умение.
Но защо да проверявате нерелевантни на текущата работа умения? Само защото това е станало модно? Защото Google прави така? Или защото вашият бъдещ тимлидер е трябвало да научи всички методи за сортировка, преди да премине интервюто и сега смята, че "всеки добър програмист трябва да знае наизуст реализацията на проверка на палиндром в стринг".
Така че, вие не сте Google (с). Какво може да си позволи Google, обикновените компании не могат. Google, анализирайки данните на своите работници, стигна до извода, че именно неговите задачи се изпълняват добре от инженери с олимпиадно минало. Освен това, изграждайки процеса на подбор, те могат да си позволят да приемат риска, че може да не наемат няколко добри инженери, защото не могат толкова лесно да решават математически задачи. Но за тях това не е проблем, желаещите да работят в Google са много, позицията ще се запълни.
Сега нека погледнем през прозореца и ако пред офиса ви все още има инженери, желаещи да работят за вас, които не са разпънали палатъчен лагер, а вашите разработчици по-често търсят в stackoverflow коя нова Спринг анотация трябва да инсталират, а не тънкостите на алгоритмите за класиране, то явно е време да помислите дали е разумно да копирате Google.
Добре, ако този път Google ви е подвел и не е дал отговор, какво да правите? Проверете точно това, което разработчикът ще прави на работа. Какво цените в разработчиците?
Определете критериите за това кого искате да наемете и разработете тестове, които проверяват именно тези умения.
ThoughtWorks
Какво общо има ThoughtWorks? Именно тук открих пример за образцово интервю. Какви са ThoughtWorks? Накратко, това е High-End консултантска компания с офиси по целия свят, от Китай, Сингапур до Американските континенти, която се занимава с консултации в сферата на разработването вече около 25 години, разполага със собствено научно подразделение, ръководено от Мартин Фаулър. Ако потърсите списък от 10 книги, които трябва да прочетете за Software Engineer, вероятно 2-3 от тях ще бъдат написани от хора от ThoughtWorks, като например Refactoring от Мартин Фаулър и Building Microservices: Designing Fine-Grained Systems от Сам Нюман или Building Evolutionary Architectures
от Патрик Куа, Ребека Парсънс, Нийл Форд.
Бизнесът на компанията се състои в предоставянето на достатъчно скъпи услуги, но клиентът плаща за феноменалното качество, което произтича от експертизата, вътрешните стандарти и, разбира се, хората. Поради това е жизненоважно да се наемат правилните хора.
Кои са правилните хора? Разбира се, те са различни за всеки. ThoughtWorks определи, че за тяхната бизнес модел най-важните критерии за разработчиците са:
- Способността за парно програмиране. Именно способността, а не опит или умение. Никой не очаква да дойдат хора, които практика при Pair programming от 5 години. Но да бъдеш отворен за чуждо мнение, да умееш да слушаш - това е необходима умение.
- Умението да пишат тестове, а в идеалния случай да практикуват TDD.
- Да разбират SOLID и ООП и да умеят да ги прилагат.
- Да представят мнението си. Консултантът трябва да работи с разработчиците на клиента, с други консултанти и не е особено полезно, ако човек умее нещо да прави добре, но е напълно неспособен да го обясни на другите членове на екипа.
Сега е важно да се оценят именно тези умения у кандидата. И тук искам да споделя опита си от интервюто в ThoughtWorks. Ще кажа веднага, че преминах интервюто в Сингапур и минах, но процесът на наемане е унифициран и няма да се различава много от страна на страна.
Етап 0. HR
Както често се случва, 20-минутно интервю с HR. Няма да се спирам на него, ще кажа само, че никога преди не бях срещал HR, който да може 15 минути да разказва за културата на разработване в компанията, защо прилагат TDD, защо е двойното програмиране. Обикновено на този въпрос HR-ите се отпуска и разказват, че процесът им е обикновен: разработчиците разработват, тестерите тестват, мениджърите натискат.
Етап 1. Колко добър си в ООП, TDD?
1.5 часа преди началото на интервюто ми изпратиха задача да направя симулатор на Mars Rover.
Задача Mars roverОтряд от роботизирани роувъри трябва да бъде приземен от NASA на плато на Марс. Това плато, което е интересно правоъгълно, трябва да бъде навигирано от роувърите, за да могат техните вградени камери да получат пълен изглед на околния терен и да го изпратят обратно на Земята. Позицията и местоположението на роувъра се представят с комбинация от x и y координати и буква, представляваща една от четирите основни посоки на компаса. Платото е разделено на решетка за опростяване на навигацията. Например позицията може да е 0, 0, N, което означава, че роувърът се намира в долния ляв ъгъл и е завъртян на север. За да контролира роувъра, NASA изпраща прост низ от букви. Възможните букви са 'L', 'R' и 'M'. 'L' и 'R' карат роувъра да се завърти на 90 градуса наляво или надясно съответно, без да се движи от текущото си място. 'M' означава да се движи напред с една решетка, запазвайки същата посока.
Приемете, че квадратът непосредствено на север от (x, y) е (x, y+1).
ВХОД:
Първият ред на входа е горният десен координат на платото, долният ляв координат се предполага, че е 0,0.
Останалата част от входа е информация, отнасяща се до роувърите, които са били разположени. Всеки роувър има два реда вход. Първият ред дава позицията на роувъра, а вторият ред е серия от инструкции, казващи на роувъра как да проучи платото. Позицията се състои от две цели числа и буква, разделени с интервали, съответстващи на x и y координатите и ориентацията на роувъра.
Всеки роувър ще бъде завършен последователно, което означава, че вторият роувър няма да започне да се движи, докато първият не е завършил движението си.
ИЗХОД:
Изходът за всеки роувър трябва да бъде неговите окончателни координати и посока.
ЗАБЕЛЕЖКИ:
Просто изпълнете изискванията по-горе и докажете, че прахосмукачката работи, като напишете единични тестове за нея.
Създаването на каквато и да е форма на потребителски интерфейс е извън обхвата.
Решаването на проблема чрез следване на подхода на TDD (развитие, ръководено от тестове) ще бъде предпочитано.
В краткото време, налично, повече се интересуваме от качеството, отколкото от пълнотата.
*Не мога да публикувам задачата, която ми изпратиха, това е стара задача, която се е давала преди няколко години. Но повярвайте, принципно всичко е останало същото.
Отделно искам да обърна внимание на критериите за оценка. Колко пъти ви се е налагало да се сблъскате със ситуация, в която важни за кандидата неща, съвсем не са важни при проверката и обратно. Не всички мислят като вас, но много могат да приемат вашите ценности и да ги следват, ако са ясно формулирани. И така, от критериите за оценка е видно, че най-важните умения в този етап са
- TDD;
- Умение за използване на ООП и писане на поддържан код;
- способност за парно програмиране
И така, уведомиха ме, че трябва да прекарам тези 1,5 часа, размишлявайки как ще извърша задачата, а не в написването на код. Кодът ще пишем заедно.
Когато се свързахме, момчетата кратко разказаха кои са те и с какво се занимават и предложиха да започнем разработката.
През всичкото време на интервюто, не ми се е налагало дори веднъж да имам чувството, че съм на интервю. Има усещане, че разработваш код в екип. Ако застряваш някъде — те помагат, дават съвети, обсъждат и дори спорят помежду си как е най-добре да се направи. На интервюто забравих как в JUnit 5 да проверя, че методът избутва Exception — те предложиха да продължа с писането на теста, докато един от тях гуглеше как да го направи.
Буквално няколко часа след интервюто получих конструктивна обратна връзка — какво им е харесало и какво не. В моя случай похвалиха употребата на Sealed класове като алтернатива на null-обект; за това, че преди да напиша кода, писах псевдокод как искам да управлявам ровера, и по този начин получих скица на класовете, поне на тези, които са задействани в API на робота.
Етап 2. Разкажи ни
Седмица преди интервюто, ме помолиха да подготвя презентация по всяка тема, която е интересна за мен. Форматът е прост и познат: 15 минути презентация, 15 минути въпроси и отговори.
Избрах Clean Architecture от Uncle Bob. И отново ме интервюираха двама души. Това беше моят първи опит за презентация на английски, и вероятно, ако бях в стресова ситуация — нямаше да се справя. Но отново, никога не съм имал чувството, че съм на интервю. Всичко е както обикновено — аз разказвам, те внимателно слушат. Дори традиционната сесия с въпроси и отговори не беше подобна на интервю, личеше си, че зададените въпроси не са с цел да "потопят", а са тези, които наистина ги интересуваха в моята презентация.
Часове след интервюто получих обратна връзка — презентацията беше много полезна и те получиха искрено удоволствие от слушането.
Етап 3. Код с производствено качество
След като предупредиха, че това е последният етап от техническите интервюта, ме помолиха да подготвя кода вкъщи до производствено готово състояние, след което да изпратя кода за ревю и да назнача интервю, на което изискванията към задачата ще се променят и кодът ще изисква модификация. Напред в бъдещето, мога да кажа, че ревюто на кода се провежда сляпо, ревюерите не знаят нито позицията, за която кандидатства лицето, нито виждат CV-то му, дори не виждат името му.
Обаждане, и отново купчина мъже по другата страна на екрана. Всичко като на първото интервю: важно е да не забравяте за TDD, да разказвате какво правите и защо. Ако преди не сте практикували TDD, препоръчвам ви незабавно да започнете, не защото е нужно във фирмите, а защото значително улеснява живота ви, намалява нивото на стреса, ако искате. Помните как се опитвахте да намерите грешка с дебъгера, която се появява само в браузъра, а с тестовете не можете да я възпроизведете? Сега си представете, че трябва да ловите такава грешка по време на интервю — няколко сиви косми са ви осигурени. Какво ни осигурява TDD? Променили сме кода и изведнъж осъзнаваме, че тестовете са червени, а не можем да разберем каква е грешката от първия път? Окей, казваме на интервюиращите "Упс", натискаме Ctrl-Z и започваме да вървим малки крачки напред. И да, умението да разработвате с TDD трябва да се развива, умението да вървите към целта така, че тестовете ви постоянно да са зелени, а не червени половин ден, само защото "имате голям рефакторинг". Това е точно такава способност, като умението да пишете поддържан код или производителен код.
И така, колко добре кодът ви може да се променя зависи от дизайна, който първоначално сте заложили, колко е прост и от качеството на вашите тестове.
След интервюто получих обратна връзка след няколко часа. На този етап разбрах, че почти съм минал и остава съвсем малко до "срещата с Фаулър".
Етап 4. Финал. Достатъчно технически въпроси. Искаме да знаем кой сте!
Честно казано, така формулировка на въпроса малко ме обърка. Как може да се разбере какъв човек съм само за един час разговор? И особено как може това да се разбере, когато говоря на език, който не ми е роден, да не говорим, че откровено казано, го говоря доста зле и непохватно. На предишните интервюта на мен ми беше по-лесно да разказвам, отколкото да отговарям на въпроси, и всичко е заради акцента. Най-малкото един от интервюиращите беше азиатец — а техният акцент, да кажем, е малко специфичен за европейското ухо. Затова реших да приложа проактивен подход — да подготвя презентация за себе си и в началото на интервюто да предложа да се запознаят с нея. Ако се съгласят — поне ще имам по-малко въпроси към мен, а ако отхвърлят предложението — какво да се прави, три часа от живота ми, прекарани в подготовка на презентацията, не е толкова висока цена. Но какво да пиша в презентацията? Биография — Роден съм тук-там, тогава-онзид, влязох в училище, завърших университета, — на кого му е интересно?
Ако потърсите малко информация за културата на Thoughtworks, можете да намерите статия на Мартин Фаулър [https://martinfowler.com/bliki/ThreePillars.html], в която се описват 3 Pillars: Устойчив бизнес, Софтуерно качество и Социална справедливост.
Предположим, че Софтверното качество вече е проверено при мен. Остава да покажа Устойчив бизнес и Социална справедливост.
Притом реших да акцентирам на последното.
Първо разказах защо ThoughtWorks е важна — още в университета четях блога на Мартин Фаулър, оттам и любовта ми към чистия код.
Проектите също могат да се представят от различни гледни точки. Разработвал съм софтуер за медицината, който улеснява живота на пациентите и дори по слухове е спасил един живот. Разработвал съм и софтуер за банки, също в известен смисъл улесняващи живота на гражданите. Особено ако тази банка се използва от около 70% от населението на страната. Не става въпрос за Сбербанк и дори не за Русия.
Искате ли да научите повече за мен? Добре. Моето хоби е фотографията, по един или друг начин държа фотоапарат в ръцете си от около 10 години, имам снимки, които не е много срамно да покажа. Също така, известно време помагах на приют за котки: фотографирах котки, които имат нужда от постоянен дом. А с хубави снимки е много по-лесно да намериш дом за котка. Вероятно съм заснел около сто котки 🙂
В крайна сметка, 80% от презентацията ми беше запълнена с котки.
Веднага след презентацията, HR ми написа, че все още не знае резултатите от интервюто, но офисът вече е впечатлен от котките.
В крайна сметка получих обратна връзка - удовлетворих всички като личност.
Но HR по време на финалния разговор деликатно спомена, че Социалната справедливост е много добра и необходима, но не всички проекти са такива. И ме попита не ме ли плаши това. В общи линии, малко прекалих със Социалната справедливост, случва се 🙂
Резюме
В резултат, вече няколко месеца работя в Сингапур в Thoughtworks и виждам, че много компании тук усвояват "най-добрите практики за интервю" от Google, използвайки листчета и бяла дъска за кодиране, въпреки че познания над Spring, Symfony и RubyOnRails (където е необходимо да се подчертае) не се изискват на работа. Инженерите взимат седмична почивка преди интервюто, за да се "подготвят".
В Thoughtworks, освен адекватните изисквания към кандидатите, основополагаещи принципи са:
Удоволствието от интервюто. И за двете страни. Всъщност, ако искате да привлечете най-добрите кадри (а кой не иска?), интервюто не е пазар, където се избират роби, а оглед на взаимната оценка между работодателя и кандидата. И ако на кандидата свързването с компанията предизвиква приятни емоции, е съвсем вероятно, че той ще избере именно тази компания.
Множествени интервюиращи, за да се намали предвзетостта. В Thoughtworks парното програмиране е стандарт по подразбиране. И ако тази практика може да се приложи в други сфери, TW се опитва да го направи. На всеки етап от интервюто участват 2 човека. Така всеки кандидат се оценява от минимум 8 души, а TW се опитва да подбира интервюиращите с различен бекграунд, от различни направления (не само техничари) и пол.
В крайна сметка решението за наемане ще бъде взето на базата на мнението на най-малко 8 души, и никой няма право на решаващ глас.
Наемане на базата на атрибути Вместо това, за да вземете решение на база "харесва ми/не ми харесва" на кандидата, е разработена форма за всяка роля и за всеки етап, включваща оценяемите атрибути. При оценяването се препоръчва да се оценява не опитът в определен умение, а способността да се прилага. Така, ако кандидатът не е имал възможността да прилага определени умения, като TDD, но все пак се опитва да ги приложи и слуша съвети за правилна употреба — той има всички шансове да премине интервюто.
Сертификати за образование не са задължителни TW не изисква от кандидата задължителни сертификати или образование в компютърните науки. Оценяват се само уменията.
Това е първото интервю, на което не ми се наложи да се подготвям, откакто минах през чуждестранни компании. След всеки етап не се чувствах изцеден като лимон, а обратно, радвах се, че мога да прилагам най-добрите практики, че хората от другата страна на монитора ценят това и също така го прилагат всеки ден.
След няколко месеца мога да кажа, че очакванията бяха изпълнени напълно. С какво ThoughtWorks се различава от обикновената компания? В обикновената компания ще намерите добри разработчици и приятни хора, но в TW концентрацията им е изключителна.
Ако искате да се присъедините към ThoughtWorks, отворените позиции могат да се видят
Също така предлагам да обърнете внимание на интересни позиции:
Водещ софтуерен инженер: , , ,
Старши софтуерен инженер: , , ,
Софтуерен инженер: , ,
Старши инженер по данни:
Качество аналитик:
Инфраструктура: , ,
(Искам честно да предупредя, че линкът е реферален, ако преминете в TW, аз ще получа приятен бонус). Избирайте офис по душа, не е необходимо да се ограничавате само в Европа, в крайна сметка, на всеки 2 години TW ще е щастлив да ви премести в друга страна, тъй като това е част от политиката на ThoughtWorks, така културата се разпространява и усреднява.
Не се колебайте да задавате въпроси в коментарите или да ме помолите да ви препоръчам.
Ако темата ви се струва интересна, ще напиша как работи в ThoughtWorks и как се живее в Сингапур.
Източник: habr.com
