«Кандидат - это нечто большее, чем просто определение того, знает ли он, как сгладить многомерный массив, что такое цепочка прототипов или замыкание. Доступны ли они и полезны ли они другим? Могут ли они оставить гордость за дверью и делать то, что лучше всего для команды? … »
Я обсуждал со многими друзьями некоторые из их опыта личных личных собеседований. Некоторые прошли хорошо, некоторые испортились, а некоторые были просто смешными. Понимаете, иногда собеседование идет не так, как надо, и не всегда это вина кандидата. Этого человека можно считать творческим / визуальным типом, имеющим большой опыт в создании надежных элементов пользовательского интерфейса, которые можно использовать в веб-приложениях, но затем на собеседовании его спрашивают, как решить сложный алгоритм вокруг двоичных деревьев или большой буквы O на доске.
Этот вопрос - не всегда - может быть актуален для специалиста по обработке данных в таком месте, как Facebook или Google, но в большинстве случаев работа не требует такой сложности на повседневной основе. Эта работа, вероятно, включает в себя создание функций здравого смысла для существующего веб-приложения, которое применимо: прочное общение с заинтересованными сторонами, чистый, протестированный и хорошо организованный код, а также включение строгих веб-стандартов, касающихся доступности. В конце концов, они доставляют код без проблем и своевременно.
Эти качества очень важны для работы и обычно не выявляются во время собеседования. Интервьюеры больше заинтересованы в том, чтобы выставить кандидата глупым, найти пробелы в его знаниях или просто удовлетворить собственное чувство гордости. Образ мышления: «Я знаю это, но знает ли он?» Знаете что? Может быть, они не знают, и ничего не знать. Не все так делают.
«Люди, которые думают, что знают все, на самом деле раздражают тех из нас, кто знает, что мы не знаем»
Бьярне Страуструп
Компании также обладают собственными знаниями в предметной области. Это означает, что внутренне они знакомы со своей собственной терминологией, как все работает или работают, и привыкли к общим проблемам, с которыми они сталкиваются. Эти проблемы могут быть чрезвычайно простыми для внутреннего сотрудника, но для человека, приходящего извне, не так много, поэтому интервьюеры должны попытаться увидеть вещи с точки зрения собеседника. Интервьюер может рассказать о проблеме, с которой он сейчас сталкивается, и спросить кандидата, как мы будем ее решать. Скорее всего, в свете фар они будут похожи на оленей.
Я считаю, что лучше не выявлять слабые стороны, а вместо этого определять сильные стороны потенциального кандидата. Что у них есть, чего нам может не хватать? Есть ли у нас эксперт по CSS, который может упростить некоторые из наших правил? Была ли их предыдущая роль более ориентированной на маркетинг, что означает, что они знают Диспетчер тегов Google как свои пять пальцев? Кто-то, кто знает React на глубоком уровне, кто может определить проблемы с производительностью, которые мы никогда не рассматривали? Кому-то, кто обладает глубокими знаниями DevOps, которые могут помочь нам создать надежные конвейеры Jenkins для некоторых из наших пакетов? Кто-то, кто является сторонником 100% покрытия тестового кода и может обеспечить его соблюдение в разных командах?
Кандидат - это нечто большее, чем просто определение того, знает ли он, как сгладить многомерный массив, что такое цепочка прототипов или замыкание. Доступны ли они и полезны ли они другим? Могут ли они оставить гордость за дверью и делать то, что лучше всего для команды? Могут ли они объяснить заинтересованным сторонам технические требования простым языком? Держат ли они всех в курсе - на кого могут повлиять изменения, которые они планируют внести?
Если вы не видите в кандидате какой-либо потенциал и чувствуете, что у него нет технических знаний, тогда да, может быть, лучше не продолжать, но не исключайте кого-то только потому, что он не может решить проблему на доска. Проверьте качество их теста кода, то, как они столкнулись на собеседовании, проблемы, которые они решили на предыдущих должностях. Более широкая картина. Вы будете удивлены, узнав, как много талантливых людей в отрасли получают - и продолжают - получать отказ.
Посетите этот сайт, на котором показаны влиятельные люди, которым отказали. Кайл Симпсон, автор книги You don't know JS, был отвергнут крупной социальной сетью за незнание JavaScript. Его книги - бестселлеры и фантастические. Макс Хауэлл, создавший Homebrew, которым пользуются 90% сотрудников Google, получил отказ в Google за то, что не знал, как создать двоичное дерево на доске.
Если серьезно, то плохой процесс собеседования очень плохо отражается на компании. Если у них будет негативный опыт, они скормят Glassdoor пикантными подробностями. У некоторых из крупнейших и наиболее успешных компаний есть огромные недостатки в этих областях, и неправильно думать, что они должны оставить все как есть только потому, что у компании все хорошо. Всегда есть возможности для улучшения.
Этот совет - одна из многих тем, рассмотренных в
«Что теперь делают инженеры-программисты?»
С помощью этой книги мы познакомим вас с различными техническими ролями, процессом найма, должностями, которые существуют на карьерной лестнице, и пройдемся через множество востребованных технических языков, инструментов, библиотек и фреймворков, которые компании ищите у кандидатов сегодня.
Печать: https://www.amazon.co.uk/dp/1707231079
Kindle: https://www.amazon.co.uk/Software-engineers-do-what-now-ebook/dp/B08413XHS8
Leanpub: https://leanpub.com/softwareengineersdowhatnow
Google Play: https://books.google.co.uk/books/about?id=lijLDwAAQBAJ
Спасибо за чтение! P.S. если вы находитесь в положении, когда вы не можете позволить себе книгу, напишите мне через Twitter!
Шон Майкл Стоун.
Просматривайте другие сообщения, которые я написал, подписывайтесь на них и пишите мне в Twitter.
