Какая-то «не здоровая пьянка» пошла последнее время на хабре про собеседования. Люди, хватит уже, нет ничего страшного и особенного в собеседованиях, я уже несколько лет провожу их с IT-шниками, и в 95% случаев это адекватные и приятные люди. Потому хочу поделиться с вами «дзеном» о том, как лучше проводить именно техническое собеседование, да и вообще оценивать навыки тех. специалистов, так как вопрос оценки компетентности технического специалиста может быть довольно сложным, особенно если вы не хотите проводить собеседование на 3 часа к ряду. С данной моделью вы вполне можете уложить тех. собеседование в 40-50 минут (а то и быстрее) и быть уверенным в решении на 80-90%. Если про оценку эмоционального интеллекта, базовой мотивации и просто уровня адекватности, информации довольно много, то вот про то, как эффективно оценивать технические навыки специалиста, зачастую, «кто в лес, кто по дрова». Данная статья может быть также полезна и тем, кто просто хочет эффективно расти как специалист, потому как именно их знания и рассматриваются.
Как это бывает
В большинстве случаев для проведения оценки приглашают другого специалиста с высокой степенью технической компетенции, который, как правило, ничего не понимает в кадровых вопросах и методологиях сбора информации о личности человека, и просто начинается лобовой допрос «кто больше знает». Некоторые интервьюверы просто имеют чеклист вопросов. Также многие используют практику тестового задания, которое требуется выполнить до назначения очного собеседования. В общем, кто как может, тот так и решает задачу.В целом, такой подход бывает эффективен, но он имеет ряд недостатков:
1. Существует вероятность, что в собеседующий технический специалист может воспринять несоответствие опыта соискателя его собственному, как отсутствие опыта вообще. Например, могут быть заданы довольно узко-практические вопросы, с которыми соискатель не сталкивался на практике, что может быть истолковано как «Да как же можно такое не знать, это же так просто». А специалист от кадров, никогда не сможет это распознать в силу специфики контекста.
2. Даже если будут заданы открытые вопросы вида «А какие задачи вам приходилось решать?», опять же, несоответствие опыта может быть истолковано как «Он нам не подходит, потому что он не делал то, чем мы занимаемся уже несколько лет».
3. Отдельные технические специалисты, особенно уже с довольно большим опытом, мало признают тот факт, что незнание конкретных инструментов не является зачастую большим препятствием. Например, если человек не работал с GIT, но хорошо знает CVS, это значительно сокращает порог входа в обладание инструментом.
4. Также может иметь место проблема, когда соискатель обладает большим практическим опытом и хорошо отвечает на вопросы по конкретным решениям, но когда его берут на работу, внезапно, выясняется что он допускает довольно типичные ошибки в областях, с которыми он до этого не работал. Про таких людей складывается впечатление, что они «тупят на ровном месте» или «активно копипастят код» из своих предыдущих проектов.
5. Порой попадается специалист, который производит впечатление новичка и его резюме показывает малый практический опыт, но важно понять «выстрелит ли он». Потому что если выстрелит, вы можете малыми вложениями получить хорошую «звезду» в команду. И не понятно как это распознать максимально точно.
Это лишь несколько сценариев, с которыми регулярно сталкиваются при подборе новых технических специалистов. Интервьювирование технического специалиста схоже с задачей, когда у вас есть огромная картина, которая скрыта за поворачивающимися клетками, которые вы переворачиваете одну за другой. И ваша задача угадать всю картину целиком, при условии что ваше время ограничено, а число возможных картин огромно.
Чтобы с большей вероятностью отсеивать приведенные негативные сценарии, а также проводить собеседования технических специалистов эффективнее, можно использовать специальную модель сбора информации.
Классификация знаний
Для начала нужно определиться с классификацией знаний. Для этого их надо разбить на 3 вида:
1. Фундаментальные – это базовые знания в конкретной области. Например, это может быть вопрос «Какие основные виды запросов в SQL вы знаете?».
2. Прикладные – это навык решения конкретных задач. Например, это могут быть задачи на правильное написание SQL запросов для конкретных примеров.
3. Инструментальные – это знания о том, как применять конкретные инструменты. Например, в чем различие между innodb и myisam хранилищами?
Фундаментальные знания необходимы для того, чтобы на их основе понимать как лучше решать практические задачи. Практические задачи формируют прикладные знания, то есть понимание того, как и что лучше делать. С пониманием того, что отдельные задачи лучше решать при помощи конкретных инструментов, развиваются и инструментальные знания. Часто, человек начинает с какой-то небольшой практики, потом изучает «почему это работает именно так», потом пытается сделать что-то схожее, и потом уже оттачивает свое мастерство при помощи инструментов.Например, точно также человек развивает навык владения языком: сперва просто пытается повторить за родителями отдельные слова; потом учит алфавит; потом пишет сочинения, статьи или деловые письма; и иногда использует для этого справочники и словари.
Когда что-то пошло не так
Так как «академическое образование» в области ИТ все еще довольно слабо, большинство специалистов во многом являются самоучками. Это создает определенные отклонения, которые хорошо можно понять на данной модели если гипертрофировать одну из областей знаний. Приведу классические портреты кандидатов и их объяснение:
1. Всезнайка – имеет значительный объем фундаментальных знаний, например приобретенных в рамках каких-либо курсов и чтения книг/статей, однако, практических навыков их применения не имеет, что его никак не смущает. Даже если вы начнете его спрашивать какие-то практические задачи, вы всегда услышите массу знаний о том как это на самом деле должно работать, как устроены отдельные части, но собрать все вместе для решения задачи, без ваших подсказок, такому кандидату будет довольно сложно. Довольно частая ситуация если спрашивать кандидата про мало используемые паттерны ООП: услышите описание паттерна, когда его применяют на каком-нибудь академическом примере, но встраивание в живую задачу будет идти «со скрипом».
2. Stackoverflow-разработчик – обычно, такие разработчики довольно активно рассказывают про свой опыт, про то какие задачи и как им удавалось решать, но при попытке ответить на вопрос «А как сделать…?» из неизвестной им практической области, вы услышите или попытку «притянуть за уши» другое решение, или же ответ в стиле «Да это гуглится за 5 минут, я уже такое где-то видел». Подобные разработчики часто стараются притянуть какие-то готовые решения, которые они уже делали, аргументируя это как «Зачем делать 2 раза?», либо же просто копипастят код из интернета и других проектов. При вопросах «А почему это работает именно так?» или «А как это можно сделать по-другому?» часто могут теряться и пытаться перевести тему.
3. Tools&Frameworks-разработчик. Есть старый анекдот: «Как начать делать сайт в 1995 году? Открыть блокнот и начать писать код. Как начать делать сайт в 2015 году? Скачать и установить composer, framework, cms-extension, bootstrap, jquery, bower, less, поставить IDE, начать писать код». Вот примерно тоже самое для подобного рода специалистов. Большая часть прикладного опыта таких специалистов связана исключено с конкретным инструментом. Такое понятие как «bitrix головного мозга» вполне конкретно характеризует этот случай. Для таких кандидатов очень сложно даются задания по «нативному» коду, потому как без инструмента для них это практически невозможная задача.Данные примеры приведены для случаев, когда одна из областей знаний занимает ведущую позицию, а так как ощущение «превосходства» в этой области зарождает чувство собственного «величия», то специалист старается удержаться за нее всеми возможностями («каждый хочет быть крутым»). Например, Stackoverflow-разработчик, при попытке выяснения фундаментальных знаний, до последнего будет аргументировать к тому, что «да мне это и не нужно знать, я такое уже сто раз делал и все и так работало».
Как работает эффективное развитие
Самым эффективным же сценарием развития знаний является именно баланс между областями. Достигать его можно разными способами, но нельзя допускать именно «перекоса». Например, вы захотели сделать домашнюю страничку и ничего в этом не понимаете (все с этого начинали): скачали wordpress (взяли «инструмент»); загуглили как все настроить и сделали свой первый блог с несколькими статьями (приобрели прикладные знания); а теперь разберитесь как и почему это работает, например как устроена база и кеш, какова архитектура движка и т.п. (приобретите фундаментальные знания). Дальше можно уже и посмотреть какие еще инструменты и как могут решать эту задачу, либо написать свой инструмент. Если же остановиться только на первом или втором шаге, то можно легко попасть в одну из категорий специалистов, приведенных выше, а вы, я уверен, явно не этого желаете: )Как оценивать знания
Исходя из этой модели можно точно также, и довольно легко, «прощупывать» технических специалистов на предмет их стратегии обучения и того, насколько их текущие знания позволяют им эффективно решать задачи. Стратегия интервьюирования следующая: задав вопрос по интересующей вас технической области в любую область знаний, двигайтесь не «горизонтально», в пределах области знаний, а «вертикально», в смежный вид знаний.Спросили про фундаментальные знания, потом спросите какие задачи человек при помощи них решал, или поставьте практическую задачу, в которой эти знания потребуются, а потом уточните какие инструменты есть чтобы использовать эти знания и лучше решать практические задачи.
Например: Что такое составные b-tree индексы и как они работают? А можете привести пример, когда могут потребоваться такие индексы или когда наоборот они будут неуместны? А как понять, что данные индексы работают эффективно и что вообще можно для этого использовать?
Если вы услышите исчерпывающие ответы на все эти вопросы, значит специалист действительно постарался сформировать уверенные знания в этой области, приобрести все уровни знаний. Теперь из этого нужно сделать правильные выводы. Это будет либо свидетельствовать о том, что у специалиста был огромный ворох задач, связанных с индексами, либо что у него есть хорошая стратегия обучения (что не исключает первое). Чтобы определить есть ли эта стратегия, достаточно прощупать еще несколько областей, в которых кандидат может быть не так сильно подкован, часто это можно увидеть из резюме.
Сильные и перспективные кандидаты, показывают что даже при отсутствии знаний они понимают чего им не хватает и выбирают эффективный подход по компенсированию недостатка знаний. Если проверив несколько областей подобным образом вы заметите что кандидат имеет эффективную стратегию обучения, то вам лишь останется только проверить обязательные для вас фундаментальные знания. Ведь обладая ими и правильной стратегией обучения кандидат, с высокой долей вероятности, сможет решить новые для него задачи максимально эффективно.
Эффективная стратегия обучения – это стратегия восполнения знаний в какой-либо области по всем видам (фундаментальным, прикладным, инструментальным): что-то попробовать, понять как и почему оно работает, сделать подобное, изучить инструменты чтобы делать еще лучше.
Типичные ошибки при оценке
Многие склонны переоценивать важность прикладных знаний по отношению к остальным областям, а именно, что люди с большим опытом выполнения задач являются хорошими специалистами, но это совершенно не так. Если практика не подкреплена фундаментальными знаниями, или специалист никогда не расширял свой инструментарий, то эффективность такого специалиста может быть очень низка. Ищите тех, кто умеет развивать каждую из областей. Они – лучшие, даже если и не имеют гигантского опыта за плечами.
Часто можно встретить тестовые задания, которые узко сфокусированы только на фундаментальных вопросах, вроде языковых конструкций, типичных ошибок при использовании «не интуитивно понятного поведения», вопросов про паттерны ООП и т.п. Как вы уже могли понять из приведенной выше модели, так вы не определите «теоретиков», и к тому же фундаментальные знания прекрасно гуглятся. Так что эффективность таких тестов относительно мала.
Также существует распространенное мнение, что важно «понять как человек думает». Несомненно, это «красивая» фраза, но она очень субъективна, и, как следствие, сложно исходя из таких оценок быть уверенным в результате. К тому же, тут можно попасть в ловушку субъективной оценки «он думает не так как я». Однако, если вы видите что человек умеет эффективно формировать свои знания и решать задачи, то не важно как именно он это делает, ведь главное это результат.
Практические рекомендации
Тестовое задание
Если вы даете привлекательные условия сотрудничества и поток кандидатов достаточно высок, то составьте тестовое задание. Включите в него несколько вопросов не из одного вида знаний, а из разных. По ответам на эти вопросы вы сможете увидеть примерную картину того, что является сильными и слабыми сторонами кандидата.
На что обращать внимание
Есть несколько моментов, на которые стоит также обращать внимание при собеседовании. Они больше относятся к кадровой составляющей, однако, проявляются именно во время технического собеседования.
Пытливость ума. Насколько кандидат старается решить задачу, если не знает решения «с ходу». Ищет ли альтернативные пути, анализирует ли подсказки, спрашивает и анализирует ли предложенное решение. Слабые кандидаты «пропускают мимо» все, что не смогли понять.
Здравая самоуверенность. Насколько кандидат допускает что может чего-то не знать. В силу воспитания, иногда, люди имеют комплексы касательно собственных знаний («краснодипломники» и т.п.). Иногда, такие люди в резко категоричной форме выдают решения и не признают альтернативных мнений, если таковые говорят об отсутствии каких-то знаний у кандидата.
Стремление к саморазвитию. Самые лучшие кандидаты — это которые стремятся развиваться как специалисты, либо же стремятся «сделать мир лучше» через создание какой-то пользы. Слабые кандидаты считают что они уже «у потолка знаний» и просто хотят зарабатывать на этом как можно больше. Также бывают и кандидаты, которые считают что их должен развивать работодатель, а не они сами себя, потому как именно работодатель ставит задачи.
Стратегия интервьюирования
Предварительно, до собеседования, составьте список ключевых областей, в которых вам требуется опыт от специалиста. Хорошо, если их будет не менее 10. Например: PHP + паттерны ООП; SQL + оптимизация запросов; архитектура высоконагруженных проектов; работа с кешом и т.п.
В каждой из ключевых областей составьте минимум по 5 вопросов для каждого вида знаний, итого минимум по 15 вопросов на каждую область. Это сделать лучше для того, чтобы не придумывать вопросы на ходу. Желательно, чтобы такие вопросы обеспечивали между собой вертикальную связанность.
Например:
Область: архитектура высоконагруженных проектов.
Фундаментальные вопросы: Какие основные параметры важно учитывать при проектировании высоконагруженных систем? Какие типовые архитектурные решения вы знаете? В чем отличие горизонтального и вертикального масштабирования?
Прикладные вопросы: Если пользователи могут загружать файлы, то каким образом лучше решить вопрос их горизонтального масштабирования на отдачу? Если имеется страница с высоким RPM, и информационным блоком, который имеет длительное время генерации, то каким образом можно ускорить отдачу страницы? Если в проекте в результате роста нагрузки узким местом стала единственная база данных, то каким образом лучше подойти к этому вопросу?
Инструментальные вопросы: Какие инструменты можно использовать для балансирования нагрузки HTTP траффика? Какие кеширующие сервера вы знаете и в чем их отличия? Каким образом можно измерять производительность приложения при больших нагрузках?
Начните с любого из вопросов на свое усмотрение. Последовательно задавайте вопросы из каждого типа знаний в выбранной области (вертикально). Если вы видите что кандидат уверенно владеет теорией, практикой и инструментами, значит вы можете быть в значительной степени уверенным, что и смежные практические задачи он также сможет уверенно решить.По мере получения ответов на вопросы, перебирая области, вы сформируете картину того, как распределены знания кандидата. Например, вы можете осознать значительный недостаток теоретических знаний, либо же пробелы в знании инструментов. Исходя из этого вы сможете сделать вывод о том, насколько эффективна стратегия обучения кандидата и его текущие знания в целом. Как правило, стратегия обучения едина для всех областей, то есть очень редко встречаются кандидаты, которые в одной области отлично знают теорию, а в другой только решали практические задачи и даже не пытались задаться вопросом «А как оно работает?».
Ну а далее, уже в зависимости от требований вакансии, вам будет гораздо легче принять решение. Ищете джуниора? Убедитесь что не только пытается решать практические задачи, но и восполняет фундаментальные знания, а также ищет и изучает новые инструменты. Ищите миддла? Убедитесь что его навыки имеют «корни» в каждом виде знаний и он понимает куда двигаться дальше, чтобы заполнять пробелы. Ищите сениора? Убедитесь что он отлично владеет фундаментальными знаниями и умеет эффективно «собрать» любую практическую задачу с фундаментальными обоснованиями и соответствующими инструментами.
Если же вы заметили какие-то пробелы в требуемых знаниях, и они не являются для вас принципиальными, но все же важны, то обязательно запишите это и проработайте на испытательном сроке план по восполнению этих пробелов, использовав это при проведении аттестации. Это позволит вам увеличивать эффективность своих сотрудников методично и осознанно. Однако, вопрос обучения и развития сотрудников это уже совсем другая и очень большая история.
Где еще можно использовать модель
Приведенная модель, на самом деле, может быть использована не только для технических специалистов, но и вообще для любой профессии. Разница будет лишь в том, насколько полно реализованы отдельные виды знаний в этих областях. Возьмем, для примера, дворника: Какие критерии чистоты вы знаете? Если вам нужно убрать за один день 10 домов, как это лучше сделать? Для каких поверхностей какие средства для уборки лучше использовать?
В качестве заключения
Недавно я решил собрать свои заметки по вопросам на собеседования для PHP-разработчиков и выложить их в открытый доступ (проект «на коленке», так что не обессудьте). Там, конечно, не все, но хватит для того, чтобы собрать мысли вместе и настроиться на проведение собеседования. Вы можете посмотреть вопросы по ссылке:
pagerton.com/hr/question/all
Если будут позитивные отклики, то буду развивать проект по мере возможности, хотелось туда еще скинуть ссылки по хорошим курсам для разработчиков, так что буду признателен за обратную связь.
Надеюсь, эта модель сможет быть полезна и вам. Не только как собеседующим, но и как собеседуемым, потому как понимание своих сильных и слабых сторон поможет вам эффективнее развиваться.
Желаю вам быть лучшими, и работать с лучшими.
P.S.: Первоисточник я. Знания, опыт и модель — мои. Ссылки «скинь оригинал» и «где пруфы, Билли», не просить: )
Комментарии (77)
daiver19
27.05.2016 13:1615 (или даже больше?) вопросов — это жесть какая-то, особенно если вопросы «ни о чем» в духе «Какие основные параметры важно учитывать при проектировании высоконагруженных систем?». Имхо, лучше иметь задание, которое затронет большинство нужных областей, чем заполнять анкетку.
evgenyl
27.05.2016 13:18«Иметь под рукой», не значит «Задать обязательно все». Не путайте подготовку и проведение. Часто бывает что уже по первому вопросу видно насколько хорошо кандидат разбирается в области и дальнейшие вопросы отпадают.
Не знаю как образом отрытый вопрос вы считаете «ни о чем», он имеет вполне конкретный и развернутый ответ.
С тестовыми заданиями многие не готовы иметь дело, особенно если речь идет о senior-level разработчиках, им просто это не нужно.daiver19
27.05.2016 13:29+2А если не видно по первому вопросу?
Как оценивать «открытый» вопрос? Любой человек с более-менее подвешенным языком может наговорить достаточно на подобный вопрос и чем шире вопрос, тем больше можно наговорить и тем сложнее это оценить. В моем примере, что такое вообще «высоконагруженная система»? Особенно забавно это видеть в контексте PHP разработчиков.
По поводу тестовых заданий, речь идет о собеседовании, если это неясно. Или senior-level разработчик развернется и уйдет, если его не спрашивать по опроснику? :)oxidmod
27.05.2016 13:34Badoo достаточно высоконагруженную систему пилят?)
daiver19
27.05.2016 13:42Наверное. Идея в том, что вопрос «Как бы вы спроектировали сайт знакомств для миллионов людей» уже лучше, чем абстрактный вопрос про «высоконагруженную систему».
oxidmod
27.05.2016 13:48я имеел ввиду ваш выпад в сторону PHP разработчиков, а не тематическую направленность разработки Badoo
daiver19
27.05.2016 14:01+1Я не очень понял, при чем здесь Badoo вообще. Речь о том, что понятие «высоконагруженной системы» зависит от конторы, которая проводит собеседование и для PHP средний уровень это явно не Badoo. Считайте, что меня просто коробит от всех этих buzz-words.
evgenyl
27.05.2016 14:57Какой бы «подвешенный язык» не был, технические вопросы есть технические вопросы, это не рассуждения «о смысле жизни», то что вы говорите или работает или нет.
К сожалению, ваши утверждения больше склоняют меня ко мнению, что вы не совсем ориентируютесь в том, о чем говорите. В частности в том, как проводить собеседования и оценивать технических кандидатов.
Bellicus
27.05.2016 16:37+1Опираясь, так сказать на итоговый список вопросов, приведенный в статье, возникает, у меня, некий глобальный вопрос. А на сколько вообще корректно использовать в собеседовании канцеляризмы?
Ну например, специалист-самоучка, обладающий опытом, смекалкой, тягой к знаниям, но при этом абсолютный ноль в определениях, а в узконаправленных уж и подавно. Нет, он знает конечно, например, про вертикальное и горизонтальное масштабирование, но он просто не в курсе что из них что. Главное работает, а у себя на деревне они называли это проще (или вообще на пальцах объясняли).
Nadoedalo
27.05.2016 16:49+1Именно так. Когда провожу тех. интервью специалистов(фронт) даю пару задач в зависимости от уровня:
— базовая на то что бы понять что человек вообще умеет писать код, например — реализация поля со спец правилами ввода(типа даты)
— конкретная, знания, которые непосредственно необходимы в работе. Вроде общей понимании концепции MV*, без которой сложно было-бы включить человека в команду. Классический пример — TODO app
Плюс на собеседовании прошу прочитать какой-нибудь кусок кода и рассказать как он работает(или хотя бы что делает) + знакомлю со структурой проекта, показываю где-чего находится, прошу найти и рассказать как работает какой-нибудь модуль.
В основном этого хватает что бы отсеять людей которые либо не владеют необходимыми технологиями, либо не могут обучаться. Правда был один «умный» джун который к собеседованию подготовился хорошо и даже устроился на low-junior но при этом реально _никакие_ задачи делать не мог и по сути это был мой факап. Зато по этой методике мы получили очень хорошего middle с которым было очень приятно работать, к сожалению не смогли взять его в штат(иностранец).
Имхо, на данный момент нет смысла спрашивать у людей знание фреймворков или проект-специфичных хаков, ибо развелось их слишком много. Нужно понимать сколько у человека опыта в разработке, обладает ли он хотя бы смежными навыками в интересующей области + есть ли желание учиться. Всё остальное — тлен и суета сует.
askbow
27.05.2016 23:22+4Ну например, специалист-самоучка, обладающий опытом, смекалкой, тягой к знаниям, но при этом
ни разу не читавший технической литературы в данной области? Т.е. здесь мы рассматриваем специалиста, обладающего опытом и тягой к знаниям, который не сталкивался с распространённой в индустрии терминологией в процессе получения опыта и / или удовлетворения тяги к знаниям. Однако, я уверен, встретив незнакомый термин, такой человек непременно постарается выяснить, о чём речь (следствие тяги к знаниям). И, в результате, овладеет термином.
А на сколько вообще корректно использовать в собеседовании канцеляризмы?
в каждой деревне — свой говор, однако стандарт языка на некоторой территории обычно один, что позволяет людям из разных деревень понимать друг друга. Именно потому, что кандидат может быть «воспитан» в совершенно иной среде, не похожей на нашутусовкукомпанию, на мой взгляд необходимо придерживаться (в рамках разумного — во всём надо знать меру) какого-то внешнего общепринятого стандарта. Например, где-то говорят «рутер», где-то «маршрутер», а ещё где-то — «раутер», но большинству, надеюсь, будет понятно «маршрутизатор».
BaDP1nG
27.05.2016 16:49-6Тут нет типа разработчика, к которому я, к сожалению, должен отнести и себя. Речь о том, разработчике, который считает, что «свой велосипед — удобней». Помню, надо было мне написать работу с веб-сокетами под iOS. Взял ли я socketIO? Щаз, я взял протокол rfc 6455, wireshark и пошёл пилить свой велосипед. Нет, я только за различные фреймворки и способы упрощения деятельности, но толи это профессиональная деформация от детской «любви» к Ассемблеру, толи просто нелюбовь к «шут его знает, как оно именно там работает», но часто хочется сделать своё решение, дабы глубже понять способ реализации.
CodeRush
27.05.2016 19:33Даже в области работы с железом и прошивками сложность решений такова, что подобная стратегия — пустая трада времени специалиста и денег компании. Если вы этим занимаесь дома в качестве хобби — прекрасно, но если вы вместо использования готовых, оттестированных, качественных решений предпочитаете собственный велосипед, который нужно сначала весь написать, затем отладить, а затем поддерживать (причем чаще всего силами других специалистов) — вы либо гениальный разработчик, либо кошмарный велостроитель.
Повторное использование отлаженного кода — одна из целей любого программирования начиная с процедурного, т.е. с 60 годов прошлого века, и желание «все взять и переписать» нужно у новичков купировать сразу же, иначе никакой пользы они не принесут. Понятно, что случаи бывают разные, и иногда решений либо нет совсем, либо они не устраивают по каким-то объективным причинам, но «не понимаю, как устроено» и «я уверен, что могу написать лучше» — причины весьма плохие.BaDP1nG
27.05.2016 23:12Так я и отнес данный тип к отрицательным примерам, разве нет? Просто по себе знаю, что такой подход имеет место быть.
foxmuldercp
27.05.2016 23:37Про взять и переписать — для новичков — могу очень сильно не согласиться прямо на своём примере:
мне на тот момент было 28 — Админ со стажем игр и макросов в слове и деле/лексиконе с конца 80х. В школе — бейсик и переставленный с нуля Лантастик, в 28 старший администратор офисной инфраструктуры одного мелкого опсоса страны — около 400 рабочих станций, домен, виртуализация и все такое.
Так вот, я где-то в эпоху народ.ру заклялся не писать веб сайты, а теперь о главном:
Разобрался с повершеллом, написал статью тут. Разобрался весьма глубоко с башем — написал вторую статью тут.
Догнался c# -> asp.net mvc (маленькая домашняя веббухгалтерия на трёх калек, писалась около 2х лет по вечерам — хотел уйти в программисты).
Сейчас на опыте этого всего работая третий год хостмастером на хостинг проектах пишу свою панель управления хостингом на rails, написав небольшой блогодвижок — расширил штатное руководство по вхождению в рельсы, и по ещё двум рельсовым книгам — небольшой онлайн магазинчик и тикетную систему.
В программисты меня таки не берут пока — возрастом не вышел, реальной практики нет. Так что пишу панель для себя и своих проектов, которыми управляюCodeRush
28.05.2016 08:57Ключевые слова в вашем комментарии — «для себя и своих проектов». В этом случае хороши любые средства, и любое программирование, хоть велосипедов, хоть нет — на пользу. А вот на деньги компании стоит заниматься решением задач, а не написанием своего кода на каждый чих. Если эти задачи можно решить вообще без кода — лучше решать их именно так, ибо у ненаписанного кода нулевые затраты на сопровождение, а если нельзя — стоит в любом случае рассмотреть использование готовых решений, прежде чем бросаться писать собственное.
foxmuldercp
29.05.2016 13:53«свои проекты» в данном случае уже работающие хостинг площадки, в данном случае, так что польза двойная. Да, готовые решения в виде десятка готовых, популярных, платных и не очень, панелей управления хостингами я уже рассмотрел, успешно использовал, собрал отрицательный опыт их использования в продакшене и идеи из них в одну корзинку и пишу своё решение.
niko1aev
27.05.2016 22:23Спасибо за инструмент с вопросами.
Идея для развития:
Сделать сбоку по тегам. Например требуется middle frontend разработчик: выбрал тег M, выбрал то, что нужно для Frontend разработчика. Распечатал, пошел на собеседование.
С учетом того, что инструмент шикарный и туда можно будет добавить языки, специализации, платформы идея с фильтрацией по тегам кажется разумной!evgenyl
30.05.2016 11:08Спасибо.
Да, была такая идея.
Хочу посмотреть будет ли востребовано и если какую-то обратную связь получу, то допилю такую фишку.
Zluk_Skovorodkin
28.05.2016 17:35Недавно довольно много ходил по собеседованиям. В некоторых фирмах давали тесты на 5 страницах. Где-то задавали узкоспециализированные вопросы, присутствующие только в их организации.Только в одной-двух организациях участники со стороны организации понимали, что я — другой человек из другой организации со своим подходом к работе и знаниям. Такие люди дают общие задачи и уже я в свою очередь, используя знания и накопленный опыт, рассказываю, как решил бы эту задачу. Такие вопросы позволяют человеку показать свои размышления, свою логику, опыт, которые он имеет.
Yago
28.05.2016 17:36+1Посчастливилось побывать на собеседовании у Жени. Это было одним из лучших собеседований в моей жизни. Человек горит своим делом и умеет докапываться до сути. В целом, вопросы были адекватные и без воды. Большая часть с вышеприведенного ресурса.
Спасибо за статью. Год назад я бы иначе подошел к собеседованиям юниоров, если бы прочел что-то подобное.
Artem_Manaenko
28.05.2016 22:06Классная статья, со всем согласен.
И меня очень пугает тенденция: специалисты заваливаются на фундаментальных вещах. Примерно половина моих кандидатов валилась на базовых принципах ООП (собес Java). Примерно 80% кандидатов никогда не слышали про индекс баз данных. Ну и в таком духе.
Чем дальше — тем больше Framework- и Stakeoverflow разработчиков. И что примечательно: это кандидаты 22-27 лет. У старших ситуация с «фундаментом» лучше, как правило.evgenyl
30.05.2016 11:06+1Вы правы. Часто встречаю эту ситуацию именно у молодых разработчиков, либо у кандидатов 25-35 лет, которые «меняют область»/«хотят уйти в IT», то есть раньше были продажниками, страховщиками и т.п.
Не так часто встречается у нас пока хорошая культура разработки и саморазвития.
SemperFi
вставлю свои 5 копеек — несколько лет был «специалистом с высокой степенью технической компетенции», собеседующим людей после HR-а, причем были всплески, когда приходилось собеседовать по 100-150 человек в месяц (надо было набрать команду на направление).
хорошо показал себя следующий практический опыт — выдать собеседуемому гражданину набор из 2-3 текущих небольших задач, собеседник сам выбирает срок исполнения, к сроку предоставляет проработанные решения. позволяет как оценить кандидата, сопоставив его решения и решения существующих специалистов, так и оценить своих специалистов, ну и — почерпнуть что либо новое(это, откровенно, редкость) =)
у зам.ген.дира была «гениальная» идея построить часть пресейл-процесса на этой основе, слава богу, ответственность он на себя не взял, и идея загнулась.
evgenyl
Некоторых пугает такой подход. Можно даже услышать фразы «Это же ваша текущая работа? Вы мне заплатите за нее?». Все же иногда попадаются недобросовестные работодатели, хотя чаще это все же паранойя со стороны кандидата.
SemperFi
Я отвечал — «Нет, не заплатим, так как работа дублируется, и фактом ее проведения мы просто осуществляем срез и сравнение ваших знаний, не получая какой либо коммерческой выгоды.» Если человек продолжал придерживаться ранее высказанной точки зрения — ну что ж, нам нужны другие люди, а вам пусть повезет в дальнейшем поиске, всего хорошего =)
Bringoff
То есть, вы давали, по сути, даже не одно, а 2-3 неоплачиваемых тестовых задания?
А какое дело человеку до того, что работа дублируется? От этого ему совсем не легче и не быстрее эту работу выполнять.
SemperFi
секретный ингредиент — это косвенная проверка, основанная на личном выборе человека — мотивирован ли человек у нас работать, или нет. Будет ли он сотрудничать с коллегами, или нет.
Можно не согласиться на выполнение заданий, в этом нет никакой проблемы.
Тем не менее, статистика показывает, что профессионал сделает 2-3 несложных задания в срок и качественно, и в дальнейшей совместной работе будет минимум проблем.
Temirkhan
Ключевое слово здесь профессионал. Мне кажется, профессионалы, в том смысле, в котором это слово понимаю я, «не ищут» работу.
SemperFi
вам кажется =) была относительно недавно вакансия с функционалом «инженер-оператор мейнфрейма». оператор мейнфрейма «по умолчанию» профессионал высокого класса(с фундаментальными знаниями «железа» Hi-End класса), тем не менее на вакансию было весьма немалое количество кандидатов — кризос.
Bringoff
Вы так уверены в исключительности своей компании? :) Обычно человек, ищущий работу, мотивирован работать не в конкретном месте (если только вы не в google собеседования проводите таким образом), а просто там, где ему подойдут условия и зарплата. То, что контора начинает общение со мной словами: "Вот вам 3 неоплачиваемых, никому не нужных таска, покажите, что вы умеете, а иначе нам не по пути", меня бы такое отношение не очень-то и прельстило. Хотя, с тем, что нам не по пути, я бы согласился :)
SemperFi
=) вас — немало вероятно. Как вы думаете, оклад 5-10к $/мес + премии кого то могут прельстить?
Bringoff
Вооружившись калькуляторомполучаем 250-500$ за рабочий день. Допустим, у человека на ваши 2-3 задачи уйдет даже пускай полный рабочий день (может, и больше, возьмем по минимуму). У людей, претендующих на такие суммы, в поиске работы, как правило, проблем нет. Что еще вы такого предлагаете, что они побегут делать у вас неоплачиваемые тестовые задания?SemperFi
ничего необычного, в целом — оклад, премия, корпоративный английский, все в белую, нормальная ДМС, обучение за рубежом.
FoxCanFly
Вы предлагаете сумму намного выше рынка, и при этом предлагаете делать рабочие задачи в качестве теста? Что еще подумает собеседуемый кроме «а, лохов ищут, заманивая цифрами»?
SemperFi
мы предлагаем медиану или чуть выше, если хотим быстрее закрыть.
«а, лохов ищут, заманивая цифрами» — глупость какая то, зачем? нам надо закрыть вакансию.
zagayevskiy
Где территориально находитесь?
SemperFi
пусть будет Сити
zagayevskiy
Что значит «пусть будет» и что такое «Сити»? Просто интересно, если зп $10к в России — то это очень много. А если в штатах — то это уже маловато.
SemperFi
Россия, конечно.
https://ru.wikipedia.org/wiki/Москва-Сити
120 000$ в год в США — это аппер мидл класс, кстати. зависит от штата, в целом, но — очень и очень неплохо.
zagayevskiy
Спасибо за ссылочку, вы так добры.
SemperFi
к вашим услугам
0xd34df00d
120k pre-tax в США — это, гм, таки маловато. «Очень и очень неплохо» — это где-то в полтора раза больше.
SemperFi
есть ньюансы — в штатах обычно считают на домохозяйство, объем налогов в каждом штате разный, но в целом соглашусь, мне надо было писать корректнее — 120к после налогов и в одно лицо.
0xd34df00d
Ну, не меньше 20%, и то в Техасе, где я зажарился в феврале, а что там летом — подумать страшно.
Имеется в виду, конечно же, в одно лицо. Вы же платить будете работнику за то, что он делает, а не за красивые глаза его супруга? :)
120k post-tax на одного человека — это уже и для какого-нибудь Нью-Йорка неплохо.
SemperFi
немного запутался, уточню — я работаю не в сша.
если говорить про сша — то, кроме собсно денежного вознаграждения компания может предоставлять medicare на всю семью, если она есть — тут я затрудняюсь корректно посчитать.
техас разный, хотя по личным ощущениям, в оклахоме и аризоне намного жарче, чем в техасе где нить в Хьюстоне. я был в Амарилло, Остине и Хьюстоне, в Хьюстоне было комфортнее, чем в остальных.
VenomBlood
И где-то здесь ошибка. Даже senior разработчики в россии не получают $5-10K в месяц + премии в среднем. Это очень узкий сегмент где такие зарплаты являются действительно «медианой или чуть выше». Обычно связано с ML, чем-то очень низкоуровневым или другими специфичными областями с высоким порогом входа. Читая статью:
Возникает еще большее непонимание, для PHP единственной должностью для которой озвученная зарплата будет медианой будет какой-либо архитектор на очень крупном высоконагруженном проекте, но таких пересчитать просто по пальцам и ни одного такого я не знаю в «Москва-Сити». Но даже если такая есть — то специалистов подобного уровня много не нужно, да и отбирают их обычно не с улицы как вы описали.
Вывод из этого простой — где-то вы лукавите. А может давно не выглядывали в окно и в кэше остался курс доллара в 30 рублей.
SemperFi
=) это ваш личный, и ошибочный вывод, что я веду речь про PHP, или автор ведет речь только про PHP.
Автор обобщает опыт бесед с некими ИТ-специалистами (очевидно, СПО/ППО+разработка), и только в заключении акцентируется конкретно на PHP, причем конкретно в опроснике вопросы не только про PHP (я себе несколько общесистемных переписал, спасибо автору за это).
Далее, доллар у нас в расчетах по 68, в начале недели был по 70, а те вакансии, о которых я размышлял, были связаны или с hi-end железом (где то там вверху проскакивал мейнфрейм), либо с Oracle/Java — прям ща на хедхантере висит несколько десятков вакансий с окладом от 200 000 RUR.
VenomBlood
70*5 = 350.
70*10 = 700.
200 < 350.
Математика не сошлась, причем не сошлась в 2-3 раза. Еще вопросы?
Кроме того уж точно математика не сошлась на слове «медианная зарплата», обычно в одной команде людей с такой ЗП мало и подобное обращение на собеседованиях он не особо любят. Терпеть это будут больше те кто знает что столько не стоит но надеется проскочить.
SemperFi
=)) ну какие могут быть вопросы при столь безупречной логике?
только вопрос — это вакансии моей конторы?
ах нет, про премию 4-6-8-12 окладов в год хороший вопрос… нет, мелко
или… мм… ну вопрос про несколько десятков вакансий с hh.ru — «Oracle/Java Architect» или даже «Senior Java developer» с окладом в USD от 5к?
нет, все меркнет перед безупречной логикой и математикой, Аристотель вертится в гробу как центрифуга.
VenomBlood
Речь шла $5K — $10K + бонусы, т.е. вариант 200 тысяч рублей + бонусы не рассматривается как заведомо противоречащий вашим же словам.
Чьи вакансии — тоже не важно, вы тут утверждали про вышеобозначенные суммы.
Что в остатке — да, есть очень редкие вакансии на реальные $5K и еще крайне более редкие, можно сказать штучные — на $10K под которые такие вопросы хоть как то могут быть актуальны. Но люди, имеющие достаточно квалификации под подобные вакансии — не будут выслушивать ваши «2-3 тестовых задания», даже интервью в крупные западные компании готовые обеспечить переезд и платить больше — не занимают столько времени сколько вы хотите. В сухом остатке вопрос Bringoff по поводу уверенности в исключительности вашей компании раз ставити такие условия все еще открыт. Собственно я уже сказал вам кто в большинстве случаев готов унижаться на подобные вакансии — те, кто этих денег в других местах не получит, т.е. те кто стоит дешевле. Поздравляю с переплатой.
Кроме того возникают сомнения потому что по разговору вы показываете будто вы таких людей чуть ли не пачками нанимаете. Так вот люди подобной квалификации пачками даже свободные на рынке труда не ходят, не то что в одну компанию не нанимаются. Несколько человек такого уровня в год — уже успех. Массово можно нанимать опять же только тех кто стоит дешевле — тут да.
SemperFi
Унижение — намеренное поведение человека, целью или результатом которого является падение у унижаемого чувства собственного достоинства и его достоинства в глазах других людей.
отсюда можно сделать четыре вывода:
1 — результат опытной экспресс-проверки всего технологического стека кандидата не вызовет у него унижения при нормальной самооценке;
2 — результат опытной экспресс-проверки всего технологического стека кандидата вызовет у него чувство унижения в случае завышенной самооценки;
3 — результат опытной экспресс-проверки всего технологического стека кандидата вызовет у него чувство подъема в случае заниженной самооценки. Заниженная самооценка тоже весьма не хорошо в дальнейшем;
4 — Одинаковые условия для всех кандидатов явно не имеют цели и намерения унизить кандидата. Близкий пример — ВУЗ — условия приема для всех одинаковые, но кто то поступает в МГУ, МФТИ, или Стэнфорд, а кто то — нет.
Получается, что приемная комиссия унижает всех, кто не поступил? Очевидно, что нет, так как это не является целью приемной комиссии.
Последующие выводы — если брать кандидата №1 без теста — компания условно ничего не теряет, кандидата №2 — переплачивает, кандидата №3 — сложный случай, обычно сначала приобретает, а потом переплачивает.
вот такая логика.
VenomBlood
Вы путаете форму и содержание. Проверка знаний — это нормально, но то как проводится эта проверка — это разнится. 12 часовое стресс-интервью с 20 людьми без еды и отдыха — это способ проверки знаний, но очевидно — очень паршивый. 3 тестовых задания — получше но все еще паршивый.
Реальность в том что вариант #1 просто посмотрит на необходимость тратить кучу своего времени на какие-то тесты какой-то сомнительной компании и пойдет в другую. Ведь если человек действительно стоит $5K — $10K — то это ОН выбирает компанию, а не компания выбирает его. Поэтому в результате в выборке прошедших тест будет больше тех кто просто проскочил потому что повезло чем тех кто действительно стоит этих денег.
kuftachev
По-моему, «2-3 тестовых задания» можно свести к объяснению того, как специалист их бы решал с оценкой хода решения. Без кода, а именно на уровне понимания процесса. Но тогда это в тот же час технического интервью и уложиться.
VenomBlood
К слову, на hh.ru специально зашел, в москве по направлению «разработка» вакансий с оплатой хотябы $5K — 8 штук. 15 результатов, 1 из них ошибка в диапазоне, 2 — связаны с высокоуровневым управлением а не разработкой и 4 по факту вакансии в другие страны. Хотя учитывая что одна из вакансий значится как «От 260К» можно вполне смело сказать что 7. И это без сужения поиска на Java/Oracle или что-то еще.
Dmitry_4
Да тут никто меньше миллиона не получает, чего мелочиться-то
YemSalat
Не понимаю за что вас минусуют, совет хороший. Человек проводяший интервью уже хорошо знаком с текущими тасками, ему легко будет их проверить.
Опрашиваему вообше нет разницы текуший это таск или просто задача из головы, что это меняет?
SemperFi
судя по профилям, оппоненты в основном молодые люди не старше 1991 г.р., то есть скорее всего — начало карьеры, линейные сотрудники или фрилансеры, скорее всего без опыта управления коллективом, скорее всего с завышенными ожиданиями. Видимо, какие то мои слова вызывают у них когнитивный диссонанс, а минусование — агрессивная компенсаторная реакция =)
VenomBlood
Странно что ни одна крупная компания в которой я собеседовался не имела такого дурного подхода с 2-3 недоплачиваемыми тестовыми заданиями. Но у вас видимо просто опыта больше, куда там интернациональным компаниям до вашей шаражки. Слишком большое у вас самомнение.
SemperFi
а вы можете назвать те самые «крупные компании, в которые вы собеседовались»?
VenomBlood
Amazon, Google, Facebook, Microsoft, LinkedIn например. За остальными крупными типа Apple, SpaceX, Intel — тоже не замечено подобного. Видимо просто опыта мало у этих компаний. Им бы вас нанять…
SemperFi
я бы рискнул предположить, что до этого этапа вы просто не дошли =)
VenomBlood
Зря рискуете. Предположение не верное. Но забавляет ваше желание хоть как то отмыться.
raidhon
В чем тут секретный ингредиент?
Выполнить 3 тестовых задания бесплатно, при том что нормальная почасовая ставка профессионала 30$ — 50$ в час!
Уже на этой стадии вы показали что ваша компания считает людей за безликие механизмы, не требующих уважения.
Профессионал к вам не попадет, так как у него в контактном листе skype будет несколько десятков предложений с заказами, а работой он завален на два года вперед.
И не нужно никуда ходить, выполнять идиотские задания ( причем ещё и бесплатные ) для третьесортной корпорации.
Что ваша компания может предложить ему?
Все что ему нужно, проснуться утром, заварить свежий кофе, подойти к компьютеру и начать работать!
0xd34df00d
Аргх, ну вот опять классическое заблуждение.
Человек не мотивирован работать у вас. Человек мотивирован работать за деньги. Человек может быть мотивирован решать интересные задачи. Человек может быть мотивирован расти как специалист. Вы как компания ему можете быть интересны только с точки зрения предоставления этих возможностей.
И человек мотивирован сотрудничать с коллегами ровно постольку, поскольку это позволяет решать рабочие задачи, делать проекты и так далее. Если у вас коллеги — чудаки, то хорошие специалисты у вас надолго не задержатся в любом случае.
Stas911
Имхо, подобный подход имеет смысл, если человек ищет работу в области, где он ранее не работал или имеет пробелы в знаниях (ну, например, сисадмин решил пойти в программеры). Тогда это позволит обеим сторонам убедиться, что человеку подходит данная работа (и его не уволят на испытательном сроке)
exfizik
Никогда не понимал такой аргументации. Это же тестовое задание, а не оплачиваемая работа, на каком основании оно должно оплачиваться?
С точки зрения работодателя, если хочется сделать задание не сферическим конём в вакууме, то оно будет как-то, возможно даже близко, связано с текущей работой. Но я вот не могу себе представить, что какой-либо работодатель будет использовать результаты такого теста в текущих продуктах, для извлечения прибыли.
Evgeny42
А потом вы удивляетесь, почему люди спрашивают об оплате такой работы, и в целом относятся с недоверием.
SemperFi
люди, присваивающие себе любой результат чужого труда, и люди, требующие оплаты вперед любого своего труда — это две стороны одного маразма.
=))
но «жадные дети», конечно, так не считают. бизнес — это чаще всего бартер — ты мне, я — тебе. но у «жадных детей» нет предложений, например, оплатить труд «специалиста с высокой степенью технической компетенции», который их собеседует 1-2 часа, как это можно объяснить? =))
Evgeny42
Ну и бред.
Во-первых, никто не требует оплаты вперед, а просто оговаривают, сколько им за такую работу заплатят. И вообще предоплата это совершенно нормальная практика, и даже полезная, ибо позволяет избегать мошенников.
Так это же ваша компания заинтересована в найме грамотного человека, и все расходы естественно на вашей компании. Точно так же, как ваша компания заинтересована проверить человека дав ему ТЗ, результат работы которого вы еще можете присвоить себе. Судя по тому что вы пишете.
Сотрудник же заинтересован, чтобы его не обманули. И если бы не было технического собеседования и тестового задания, то он был бы только рад.
SemperFi
компания заинтересована в том, чтобы найти специалиста, на котором она заработает больше, чем потратит на него — это бизнес, а не благотворительность. кроме его квалификации, в этом уравнении есть еще достаточно большое количество переменных.
Evgeny42
Это никак не противоречит тому, что я говорю. Если вы даете тестовые задания из реальных задач, то будьте готовы к тому, что люди попросят за это деньги и отнесутся с недоверием. Потому что деньги зарабатываете и время тратите не только вы.
SemperFi
без проблем, зачтём кандидату в зп или в премию, тут по договоренности, давайте обсудим =)
Evgeny42
Не снимает подозрений, потому что никаких гарантий, что это не мошенничество. Да и что обсуждать, если тебя заранее считают «жадным ребенком»?
YemSalat
> Сотрудник же заинтересован, чтобы его не обманули. И если бы не было технического собеседования и тестового задания, то он был бы только рад.
Мне кажется что в первую очередь он заинтересован получить работу, а «обманули» и т.д. — это уже детали.
Evgeny42
Ну тогда уж, человек в первую очередь заинтересован в обеспечении своих физиологических потребностей и своей безопасности. А то что он на работу ходит и т.д. — это уже делали.