Не ви ли се струва странно, че когато ви предстои смяна на работата и възникне необходимостта да преминете интервю, първото нещо, което си мислите е „трябва да се подготвите за интервюто“. Решете проблеми в HackerRank, прочетете Crack the coding intervju, запомнете как работи ArrayList и как се различава от LinkedList. О, да, може също да попитат за сортирането и очевидно би било непрофесионално да се каже, че бързото сортиране най-вероятно би било най-добрият избор.
Но чакайте, вие програмирате по 8 часа на ден, решавате интересни и нетривиални задачи и на новата си работа ще правите същото, плюс или минус. Но въпреки това, за да преминете интервю, трябва по някакъв начин да се подготвите допълнително, дори да не усъвършенствате ежедневните си умения, а да научите нещо, което не ви е необходимо на текущата ви работа и е малко вероятно да ви трябва на следващата. На вашите възражения, че информатиката е в кръвта ни и ако ни събудите посред нощ, сме длъжни да напишем със затворени очи върху калъфка за възглавница разходка около дървото, без дори да дойдем в съзнание, аз ще отговоря, че ако си намеря работа в цирка и основното ми нещо, номерът ще бъде точно това - тогава може би да, съгласен съм. Това умение трябва да бъде изпробвано.
Но защо да тествате умения, които не са от значение за настоящата ви работа? Само защото стана модерно? Защото Google прави това? Или защото вашият бъдещ ръководител на екип трябваше да научи всички методи за сортиране преди интервюто и сега той вярва, че „всеки добър програмист трябва да знае наизуст изпълнението на намирането на палиндром в низ“.
Е, вие не сте Google (c). Това, което Google може да си позволи, обикновените компании не могат. Google, след като анализира данните на своите служители, стигна до извода, че инженерите с опит в олимпиадата са добри в справянето със специфичните задачи. Освен това, като проектират своя процес на подбор, те могат да си позволят да поемат риска да не наемат няколко добри инженери, защото не могат лесно да решават математически задачи. Но това не е проблем за тях, има много хора, които искат да работят в Google, позицията ще бъде затворена.
Сега нека погледнем през прозореца и ако пред вашия офис инженерите, които искат да работят за вас, все още не са разположили палатков лагер и вашите разработчици по-често търсят в stackoverflow каква следваща пролетна анотация трябва да бъде инсталирана, отколкото тънкостите на алгоритмите за класиране, тогава очевидно е време да помислите дали трябва да копирате Google.
Е, ако този път Google се провали и не даде отговор, какво трябва да направите? Проверете какво точно ще направи разработчикът на работа. Какво цените в разработчиците?
Направете критерии за това кого искате да наемете и разработете тестове, които проверяват точно тези умения.
ThoughtWorks
Какво общо има ThoughtWorks с това? Тук намерих пример за моделно интервю за себе си. Кои са ThoughtWorks? Накратко, това е High-End консултантска компания с офиси по целия свят, от Китай, Сингапур до американските континенти, която консултира в областта на разработката от около 25 години, има собствен научен отдел, ръководен от Мартин Фаулър. Ако търсите списък с 10 задължителни книги за софтуерен инженер, тогава може би 2-3 от тях ще бъдат написани от момчетата от ThoughtWorks, като Refactoring от Martin Fowler и Building Microservices: Designing Fine-Grained Systems от Sam Нюман или изграждане на еволюционни архитектури
от Патрик Куа, Ребека Парсънс, Нийл Форд.
Бизнесът на компанията се основава на предоставянето на доста скъпи услуги, но клиентът плаща за феноменално качество, което се състои от опит, вътрешни стандарти и, разбира се, хора. Следователно наемането на правилните хора е жизненоважно тук.
Какви хора са прави? Разбира се, за всеки има различни. ThoughtWorks определи, че най-важните критерии за техния бизнес модел на разработчици са:
- Способност за развитие по двойки. Това е способност, а не опит или умение. Никой не очаква, че ще дойдат хора, които практикуват програмиране по двойки от 5 години.Но да възприемаш мнението на другите хора и да можеш да слушаш е необходимо умение.
- Възможност за писане на тестове и в идеалния случай практикуване на TDD
- Разбирайте SOLID и ООП и можете да ги прилагате.
- Представете вашето мнение. Като консултант трябва да работиш с разработчиците на клиента, с други консултанти и няма голяма полза, ако човек знае как да направи нещо добре, но е напълно неспособен да го предаде на останалите от екипа.
Сега е важно да оцените тези конкретни умения на кандидата. И тук искам да говоря за опита си от интервюиране в ThoughtWorks. Веднага ще кажа, че отидох в Сингапур и преминах, но процесът на набиране е унифициран и няма да се различава много в различните държави.
Етап 0. HR
Както често се случва, 20-минутно интервю с HR. Няма да се спирам на това, просто ще кажа, че никога не съм срещал HR човек, който може да говори 15 минути за културата на развитие в компанията, защо използват TDD, защо програмиране по двойки. Обикновено HR-ите не отговарят на този въпрос и казват, че техният процес е нормален: разработчиците разработват, тестерите тестват, мениджърите управляват.
Етап 1. Колко добър сте в OOP, TDD?
1.5 часа преди началото на интервюто ми изпратиха задача да направя симулатор на Mars Rover.
Мисия на марсоходаОтряд роботизирани роувъри трябва да бъдат кацнати от НАСА на плато на Марс. Това плато, което е любопитно правоъгълно, трябва да се навигира от марсоходите, така че техните бордови камери да могат да получат пълен изглед на околния терен, за да го изпратят обратно на Земята. Позицията и местоположението на марсохода се представят чрез комбинация от координати x и y и буква, представляваща една от четирите основни точки на компаса. Платото е разделено на мрежа за опростяване на навигацията. Примерна позиция може да бъде 0, 0, N, което означава, че марсоходът е в долния ляв ъгъл и е обърнат на север. За да управлява марсоход, НАСА изпраща обикновен низ от букви. Възможните букви са 'L', 'R' и 'M'. „L“ и „R“ карат марсохода да се върти съответно на 90 градуса наляво или надясно, без да се мести от текущото си място. „M“ означава преместване напред с една точка на мрежата и запазване на същата посока.
Да приемем, че квадратът директно на север от (x, y) е (x, y+1).
ВХОД:
Първият ред за въвеждане е горните десни координати на платото, долните леви координати се приемат за 0,0.
Останалата част от въведените данни е информация, отнасяща се до марсоходите, които са били разположени. Всеки марсоход има два реда за въвеждане. Първият ред дава позицията на марсохода, а вторият ред е поредица от инструкции, казващи на марсохода как да изследва платото. Позицията се състои от две цели числа и буква, разделени с интервали, съответстващи на координатите x и y и ориентацията на марсохода.
Всеки роувър ще бъде завършен последователно, което означава, че вторият роувър няма да започне да се движи, докато първият не приключи движението.
ИЗХОД:
Резултатът за всеки марсоход трябва да бъде неговите крайни координати и курс.
ЗАБЕЛЕЖКИ:
Просто изпълнете изискванията по-горе и докажете, че една прахосмукачка работи, като напишете тестове за единици за нея.
Създаването на каквато и да е форма на потребителски интерфейс е извън обхвата.
Решаването на проблема чрез следване на TDD (Test Driven Development) подход ще бъде за предпочитане.
В краткото налично време ние сме по-загрижени за качеството, отколкото за пълнотата.
*Не мога да публикувам задачата, която ми беше изпратена, това е стара задача, дадена преди няколко години. Но повярвайте ми, фундаментално всичко остава същото.
Особено искам да обърна внимание на критериите за оценка. Колко пъти сте се сблъсквали със ситуация, в която нещата, които са важни за даден кандидат, са напълно маловажни по време на одита и обратното. Не всеки мисли по същия начин като вас, но мнозина могат да приемат и следват вашите ценности, ако са ясно заявени. И така, от критериите за оценка веднага става ясно, че най-важните умения на този етап са
- TDD;
- Възможност за използване на ООП и писане на поддържаем код;
- способности за програмиране по двойки
И така, бях предупреден да прекарам тези 1.5 часа в мислене как ще изпълня задачата, вместо да пиша код. Ще напишем кода заедно.
Когато се свързахме по телефона, момчетата ни казаха накратко кои са и какво правят и предложиха да започнем разработка.
По време на цялото интервю нито веднъж не съм имал чувството, че ме интервюират. Има чувството, че разработвате код в екип. Ако закъсате някъде, помагат, съветват, обсъждат, дори спорят помежду си как е най-добре да го направите. На интервюто забравих как да проверя в JUnit 5 дали даден метод хвърля Exception - предложиха да продължа да пиша теста, докато един от тях гугъл как се прави.
Буквално няколко часа след интервюто получих градивна обратна връзка - какво ми харесва и какво не. В моя случай ме похвалиха за използването на запечатани класове като алтернатива на нулевия обект; за факта, че преди да напиша кода, написах в псевдокод как бих искал да управлявам марсохода и по този начин получих скица на класовете, поне тези, които участват в API на робота.
Стъпка 2: Кажете ни
Седмица преди интервюто ме помолиха да подготвя презентация по всяка тема, която ме интересува. Форматът е прост и познат: 15 минути презентация, 15 минути отговаряне на въпроси.
Избрах Чиста архитектура от чичо Боб. И отново бях интервюиран от двама души. Това беше първият ми опит с презентиране на английски език и може би, ако бях в стресова ситуация, нямаше да мога да се справя. Но отново, нито веднъж не съм имал чувството, че съм на интервю. Всичко е както обикновено - казвам им, те слушат внимателно. Дори традиционната сесия с въпроси и отговори не беше като интервю; беше ясно, че въпросите не се задават, за да „потънат“, а тези, които наистина ги интересуват в моята презентация.
Няколко часа след интервюто получих обратна връзка - презентацията беше много полезна и те наистина се забавляваха да слушат.
Етап 3. Код за качество на продукцията
След като ме предупредиха, че това е последният етап от техническите интервюта, ме помолиха да доведа кода у дома до състояние, готово за производство, след което да изпратя кода за преглед и да насроча интервюта, на които изискванията за задачата ще се променят и кодът ще изискват модификация. Занапред мога да кажа, че прегледът на кода се извършва на сляпо, рецензентите не знаят позицията, за която кандидатства кандидатът, не виждат CV-то му, дори не виждат името му.
Телефонът иззвъня и от другата страна на монитора отново имаше двама момчета. Всичко е същото като при първото интервю: основното е да не забравяте за TDD, да кажете какво правите и защо. Ако не сте практикували TDD преди, тогава препоръчвам да започнете да го правите веднага, не защото е необходимо в компаниите, а защото значително опростява живота ви, намалява нивото на стрес, ако искате. Помните ли как трябваше трескаво да търсите с дебъгер грешка, която може да бъде възпроизведена само през браузъра, но не можете да я възпроизведете с тестове? Сега си представете, че ще трябва да хванете такава грешка по време на интервю - гарантирани са ви няколко сиви коси. Какво получаваме с TDD? Променихме кода и неочаквано разбрахме, че сега тестовете са червени, но каква е грешката, която не можем да разберем от първия път? Добре, казваме „Ами сега“ на интервюиращите, натискаме Ctrl-Z и започваме да правим малки стъпки напред. И да, трябва да развиете способността да се развивате с помощта на TDD в себе си, способността да вървите към целта, така че вашите тестове да са постоянно зелени, а не червени за половин ден, защото „имате много рефакторинг“. Това е точно същото умение като писането на поддържаем код или писането на продуктивен код.
Така че колко добре може да бъде променен вашият код зависи от това какъв дизайн имате предвид като начало, колко прост е той и колко добри са вашите тестове.
След интервюто получих обратна връзка в рамките на няколко часа. На този етап разбрах, че почти съм приключил и остава много малко, докато „срещна Фаулър“.
Етап 4. Финал. Стига технически въпроси. Искаме да знаем кой си!
Честно казано, бях малко озадачен от тази постановка на въпроса. Как можете да разберете какъв човек съм в един час разговор? И още повече, как можете да разберете това, когато говоря език, който не е родният ми език и, честно казано, много скапан и езиков. В предишни интервюта на мен лично ми беше по-лесно да говоря, отколкото да отговарям на въпроси, и акцентът беше виновен. Поне един от интервюиращите беше азиатец - и техният акцент, добре, нека просто кажем, е донякъде специфичен за европейското ухо. Затова реших да подходя проактивно – да подготвя презентация за себе си и в началото на интервюто да предложа да говоря за себе си с тази презентация. Ако се съгласят, тогава поне ще има по-малко въпроси за мен, ако отхвърлят офертата, добре, 3 часа от живота ми, прекарани в презентация, не са толкова висока цена. Но какво трябва да напишете в презентацията си? Биография - Роден там, по това време, ходил на училище, завършил университет - но на кого му пука?
Ако потърсите малко в Google за културата на Thoughtworks, ще намерите статия от Мартин Фаулър [https://martinfowler.com/bliki/ThreePillars.html], която описва 3-те стълба: устойчив бизнес, софтуерни постижения и социална справедливост.
Да приемем, че софтуерното съвършенство вече е проверено за мен. Остава да покажем Устойчив бизнес и социална справедливост.
Освен това реших да се спра на последното.
Като начало му казах защо 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 и какъв е животът в Сингапур.
Източник: www.habr.com