Не ви ли се струва странно, че когато решите да смените работата си и се налага да преминете интервю, първо си мислите "трябва да се подготвя за интервюто". Решавате задачи в 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 книги, които е задължително да прочетете за софтуерни инженери, вероятно 2-3 от тях ще бъдат написани от хората от ThoughtWorks, като например Refactoring от Мартин Фаулер и Building Microservices: Designing Fine-Grained Systems от Sam Newman или Building Evolutionary Architectures.
от Patrick Kua, Rebecca Parsons, Neal Ford.
Бизнесът на компанията е основан на предоставянето на доста скъпи услуги, но клиентът плаща за феноменално качество, което се състои от експертиза, вътрешни стандарти и, разбира се, от хора. Поради това е изключително важно да се наемат правилните хора.
Кои са правилните хора? Разбира се, всеки има свои критерии. 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. Финал. Достатъчно технически въпроси. Искаме да знаем кой си!
Честно казано, такава постановка на въпроса ме изненада. Как може да се разбере какъв човек съм за един час разговор? И още повече, как може да го разбера, когато говоря на език, който не е мой, и, откровено казано, доста несигурно и неясно. На предишните интервюта ми беше по-лесно да разказвам, отколкото да отговарям на въпросите, и всичко това е заради акцента. Поне един от интервюаторите беше азиатец — а техният акцент е, да кажем, малко специфичен за европейското ухо. Затова реших да подходя проактивно — да подготвя презентация за себе си и в началото на интервюто да предложа да говоря за себе си с тази презентация. Ако се съгласят — поне ще има по-малко въпроси към мен, ако отхвърлят предложението — какво да се прави, 3 часа от живота ми, прекарани в подготовка на презентация — не е толкова висока цена. Но какво да напиша в презентацията? Биография — роден съм там и тогава, тръгнах на училище, завърших университета — на кого му е интересно това?
Ако малко погуглите за културата на Thoughtworks, можете да намерите статия на Мартин Фаулър [https://martinfowler.com/bliki/ThreePillars.html], в която се описват 3 Pillars: Устойчив бизнес, Софт в отличен вид и Социална справедливост.
Да предположим, че Софт в отличен вид вече ми е проверен. Остава да покажа Устойчив бизнес и Социална справедливост.
Затова реших да се съсредоточа върху последното.
Първо обясних защо ThoughtWorks — още в университета четях блога на Мартин Фаулър, оттам и любовта ми към Clean code.
Проектите могат да се представят от различни ъгли. Разработвах софтуер за медицина, който улесняваше живота на пациентите и дори, по слухове, спасил един живот. Работих и върху софтуер за банки, също вид улеснение за гражданите. Особено ако тази банка се ползва от около 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
