На волне последних обсуждений темы собеседований, хочу задать аудитории Хабра вопрос: вы помните, как писали в резюме: "коммуникабельный, инициативный, быстро обучаюсь"?
Я — помню, и помню, что страшно гордился тем, как я хорош. Помню, как я читал эти слова в резюме кандидата, когда первый раз в жизни оказался в роли нанимающего менеджера. Много думал, после чего уже не так собой гордился.
Итак, меня зовут Алексей, я QA Lead одной из команд в Plesk. Хочу поговорить о том, как увеличить пользу от технического собеседования, или что означают софт скиллы, и как они проявляют себя в реальной жизни.
Добро пожаловать под кат.
Про типовой технический собес
Давайте начнем с того, для чего вообще нужно техническое собеседование.
Самая распространенная версия — для оценки технических навыков. И с этим сразу же начинаются проблемы. Если вы ищете не совсем начинающего джуна, то требуемый объем знаний и опыта практически невозможно полноценно оценить за час-полтора. Но как-то это сделать нужно, поэтому собеседование превращается в некоторое подобие экзамена с быстрыми короткими вопросами-ответами. Думаю, мало кому в принципе нравилось сдавать экзамены, а если ещё и экзаменатор вдруг решит на тебе отыграться за невкусный утренний кофе?
Наверняка, каждый хоть раз попадал в подобную ситуацию. Экзамен казался приемлемым в годы учебы, но во взрослой жизни это уже не выглядит, как что-то нормальное. А ведь ожидается, что люди, сидящие по разные стороны стола на собесе, должны будут каким-то образом потом вместе работать.
Но есть в этом и что-то хорошее для кандидата: если на собеседовании ты встречаешь въедливого и придирчивого садиста-экзаменатора, который в перспективе должен стать твоим руководителем, принять решение не в пользу этой компании очень легко.
Что можно получить в итоге такого собеседования? Какое впечатление сложится об испытуемом и о таком экзаменаторе?
С одной стороны, вы скорее всего увидите агрессивного и необщительного человека с нервным тиком; с другой стороны, вас будут считать садистом-маньяком с манией величия. Психотерапевты, прием которых включен в программу медицинского страхования, на этом моменте радостно потирают руки.
Допустим, каким-то чудом вы смогли договориться и найти того самого, кто пойдет дальше технического собеседования — на HR интервью. Не знаю точно, что там происходит, но вердикт HR-а для неподготовленного человека выглядит, как краткое описание тяговой лошади:
в меру весел,
морально неустойчив,
есть задел на лидерские качества,
при должном стимулировании обучаем,
зубы целые,
взгляд загадочен.
Что с этим делать, как это должно помочь принять решение о найме, а главное, как эти качества будут проявлять себя в процессе работы - вопросы остаются открытыми.
Думаю, основную идею вы уловили — собеседование в виде экзамена не помогает ни компании, ни кандидату.
А какие есть скрытые резервы в техническом собесе?
Допустим, вы ищете инженера с опытом администрирования Linux, и вам будет достаточно следующих умений:
работать в консоли (команды навигации, работа с файлами);
уметь обращаться с логами;
менять настройки стандартных системных сервисов.
Теперь представим, что к вам на собеседование пришел кандидат, который утверждает, что все это умеет. Естественно, вы хотите это проверить и задаете вопросы, начиная с самых базовых. Какие это могут быть вопросы?
Про стандартные консольные команды навигации и работы с файлами (cd, mkdir, cp, mv …. плюс дежурная шутка про то, как выйти из vi);
Про то, где находятся логи разных сервисов (syslog, error_log/error.log ….);
Про то, где находятся файлы конфигураций разных сервисов (httpd.conf/apache2.conf, php.ini, my.cnf и т.д.).
Таким образом, мы узнаем, что у кандидата есть, как минимум, теоретические знания по каждому пункту. В то же время, не факт, что знания подкреплены практикой, и он умеет ими пользоваться в реальных задачах. В каких-то случаях этого будет достаточно, но чаще мы ожидаем от кандидата знаний, подкрепленных практическим опытом.
Для связи теории и практики можно пойти другим, более прикладным путем. Попробуем дать задачку, решение которой так или иначе продемонстрирует нужные знания:
Пользователи вашего проекта на PHP жалуются, что не могут загрузить файлик размера больше двух мегабайт. Расскажите пошагово, как будете исследовать проблему и чинить её?
В ответ есть вероятность услышать что-то вроде:
Включу нужные опции в секции Error handling and logging файла конфига php.ini, там же посмотрю опцию error_log, чтобы найти, где хранятся логи.
В логе найду ошибку о том, что The uploaded file exceeds the upload_max_filesize directive in php.ini, после чего поправлю соответствующую опцию в php.ini, задав нужный разумный предел.
Таким образом, кандидат продемонстрировал, что кроме знания отдельных вопросов, умеет решать и более комплексные задачи.
Казалось бы, это то, что надо! Но…
А вдруг можно ещё лучше?
Давайте зададим кандидату вопрос в следующем ключе:
Расскажите о ситуации из вашего опыта, когда вам понадобилось исследовать проблему и удалось исправить её, поменяв настройки системных сервисов.
Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?
Пофантазируем, какой рассказ мы могли бы получить в ответ.
Проблема: Из отдела маркетинга пожаловались, что они не могут разместить на корпоративном сайте pdf с бренд-буком через стандартную форму загрузки файлов. Из-за этого приходится разбивать pdf на отдельные картинки и загружать их по одной.
Задача: Понять причину проблемы с загрузкой файлов в формате pdf, предложить способ её решения.
Решение: Путем курения логов наш кандидат выяснил, что виноват не формат файла, а его размер. Поразбирался в настройках php.ini и пришел к решению установить директивы upload_max_filesize = 20M и post_max_size = 20M. Это решило проблему. Поправленные настройки кандидат добавил в инструкции по деплою и настройке продакшн сервера.
Таким ответом кандидат не только показал необходимые знания и умения, но и он продемонстрировал похвальное небезразличие к проблемам смежных отделов.
Мы можем сделать вывод, что он способен самостоятельно найти и починить проблему, и, как вишенка на тортике, кандидат проявил заботу о коллегах, т.к. сохранил ценную информацию в документации. А это позволит коллегам решить аналогичную проблему в будущем.
Это ли не чудо?
В то же время, кто-то может справедливо заметить, что без спроса менять что-то на продакшн сервере — это сомнительная инициатива. В некоторых ситуациях это даже может быть засчитано за безответственность.
Таким образом, помимо подтверждения технических навыков, мы коснулись и софт скиллов кандидата. Тот самый фидбек от HRов “отзывчив, инициативен, проактивен” обретает смысл и вполне реальные очертания. Становится намного проще ответить на вопрос:
Хотите ли вы, чтобы человек с таким набором знаний, умений и качеств работал с вами в команде?
А теперь давайте разберем, как мы это добились.
Модель STAR(AR)
Напомню, вопрос кандидату звучал как:
Расскажите о ситуации из вашего опыта, когда вам понадобилось исследовать проблему и удалось исправить её, поменяв настройки системных сервисов.
Что это была за ситуация? Как сформулировали задачу? Как вы действовали и какой результат получили?
Для вопроса мы использовали модель STAR(AR). Эта модель состоит из четырех (либо пяти) важных составляющих:
Situation (ситуация).
Task (задача).
Actions (действия).
Results (результаты).
Alternative Results (альтернативные результаты).
Схема позволяет как задать четкий вопрос, так и предлагает структуру, которая помогает кандидату дать ответ по существу.
Но и это ещё не все! Незаметные глазу нюансы — вопрос, обращенный к реальному опыту с большей вероятностью покажет, как кандидат привык действовать в реальной жизни. А это как раз то, с чем вы столкнетесь, когда (и если) он перейдет из категории “кандидат” в категорию “коллега”.
Дополнительный приятный бонус скрывается в пункте Alternative Results. Вопрос “как бы вы поступили в такой же ситуации сейчас?” может показать, чему кандидат научился с тех пор, как рассказанная ситуация случилась в его жизни. А это уже намекнет вам на способность переосмысливать свой опыт, учиться и делать выводы, даже если изначальное решение было неоптимальным, а то и вовсе неправильным.
Давайте представим, как наш кандидат мог бы ответить на этот вопрос, пусть это будет:
Сейчас я бы установил директиву post_max_size = 60M, т.к. сама форма загрузки позволяла загружать до 3 файлов одновременно.
Готово, вы восхитительны! Похоже, что наш кандидат нам подходит.
Что все это дает нам на практике?
Не теряя в качестве оценки технических навыков мы приобретаем возможность узнать кандидата ближе именно с позиции личностных качеств. В примерах мы рассмотрели преимущественно положительные качества, реальность же полна разочарований. Поэтому я советую продумывать свои вопросы таким образом, чтобы иметь возможность в ответах найти паттерны поведения, которые вы хотели бы видеть у своего будущего коллеги (или наоборот — не хотели бы).
Даже если кандидат в своем ответе не покажет паттерн в явном виде, из ответа вы получаете больше контекста об опыте кандидата. А это позволяет задать нужные вам уточняющие вопросы.
Бонусный уровень
Потренировавшись находить маркеры поведения в ответах на технические вопросы, вы сможете целенаправленно задавать вопросы, направленные на те или иные софт скиллы кандидата. Стоит упомянуть, что не стоит доверять или разочаровываться первым же ответом. В идеале каждый замеченный вами паттерн должен быть проверен как минимум дважды. Т.е. вопросов, раскрывающих то или иное поведение стоит заготовить больше, чтобы дать возможность кандидату закрепить свой успех в ваших глазах.
Все это даст вам качественную всестороннюю оценку, а значит уменьшит вероятность ошибки, когда грамотный с технической точки зрения специалист не подходит в вашу команду просто потому, что вы ожидали от него одних качеств, а получили совсем другие.
А как вы оцениваете софт скиллы? Какие техники или методы используете для этого?
hellamps
оно да, но вопросы про php, аплоад и 20 мб — мы сейчас в 2021 или 2005?
HappyGroundhog
Что не так с вопросом? В дистрибутивах PHP это значение всё еще неизменно низкое для реальной жизни) А в реальности придется еще и в конфиг nginx сходить иногда… Да и статья не о значении upload_max_filesize ;)
hellamps
нынче чтоб файлик залить достаточно юзеру полиси в s3 выдать разовое и залить напрямую в ближайший к нему локейшн. у того де амазона 5 терабайт макс размер и 5 гигабайт на разовый put.
и не надо думать ни про свой балансер, ни про таймауты коннекшеннов, ни на место под временный файл, ни куда этот файл лить потом.
Но проще минус поставить, это да :) ведь у каждого на исповеди своц php в шкафу
avokhmianin Автор
Все же зависит от предметной области :)
Наша тестовая инфраструктура уже в амазоне и там да, свою нюансы и спецэффекты. В то же время проекты команды напрямую связаны с шаред хостингом, в котором проблемы 2005 года все ещё могут быть актуальны для конечных пользователей и которые мы, в том числе, решаем в своих проектах за счет автоматизации взаимодействия между пользователем и системой, где расположен хостинг.
В данном случае считаю, что конкретный пример не имеет значения, намеренно избегал любого контекста. Пример из области настройки системы — показался мне наиболее общим для широкой общественности, который удобно будет разложить на простые и понятные этапы.
Но идея интересная, можно на досуге подумать, какой бы показательный пример можно было выбрать для оценки знаний в области инфраструктуры амазона.
HappyGroundhog
Минус вам ставят за «авторитетную категоричность». Поэтому когда я на собеседовании слышу «винда масдай» или «Ubuntu хрень» я быстренько его заканчиваю и расстаюсь. Нормальный специалист спросит критичные условия и на их основе сделает осознанный выбор дистриба и оси, учитывая корпоративные политики и историю. Удивлю, но в 2021 я и DOS встречал в некоторых критичных системах и они еще лет 10 проработают после. А как старый безопасник, вообще много лет провел с системами отвязанными от интернета «воздушным зазором». S3, бакеты, угу… Что впрочем не мешает мне иметь MCSE по Azure с Linux и не выносить поспешных суждений)
hellamps
я шучу про минус :)
что касаемо самой идеи статьи — тут есть такая проблема, что во-первых, про свои фейлы никто не расскажет, а про победы — это тоже никак не проверить. Я, лично, предпочитаю свой вопрос, вместо опыта.(если, конечно, цель не нанять именно ради этого опыта). А то можно нанять "рассказчика", а не инженера.
Я пару раз пробовал особую методику — предлагал прособеседовать меня и рассказать потом впечатление о мне, как кандидате.
Это совершенно ломает стереотип соискателя о собеседовании, но не работает с некоторыми типами психики, к сожалению.
amarao
… и я обычно про фейлы рассказываю. Потому что если компания недакеватна, лучше это отфильтровать на самом входе, чем второй раз возиться со сменой работы.
hellamps
про фейлы очень осторожно надо рассказывать, я только про личные проекты расскажу. Всё-таки про своих работодателей лучше или хорошее или ничего.
amarao
При достаточной истории можно рассказывать без указания на лица и компании.
amarao
Я, например, очень opinionated в выборе технологий. Я могу использовать неприятную мне технологию, если очень нужно, но в жизни я пропихиваю красивые технологии и стараюсь закопать некрасивые. Более того, стек технологий в компании, в которую я собеседуюсь, matters. Потому что если всё время соглашаться с тем, что сейчас нравится работодателю, так и останешься админом 1С и AD.
HappyGroundhog
Мне кажется, так поступают все зрелые специалисты) Собеседоваться невзирая на стек и условия это «работа за еду». Иногда бывает необходимо, но лучше всё же по любви. Главное еще в процессе «сделать красиво» подходить к процессу разумно, чтобы в итоге не получить франкенштейна после 3 админов, каждый из которых начинал менять всё на свое любимое) Но в зрелой компании это маловероятно, а у маленьких зачастую просто такая судьба…
amarao
В крупных компаниях либо зоопарк, либо фашизм. Один человек не может охватить всё, и либо каждая команда сама себе стек держит, либо всех железной уздой в указанный стек вгоняют. В одном случае имеется диверсификация и внутренняя технологическая конкуренция (ценой усложнения), в другом — бонусы унификации за счёт людей, из которых не получилось выковать гвозди.
hellamps
думаю, в крупных всегда «зоопарк» с примесью фашизма в отдельно взятой области.
Если мы о продуктовых компаниях.
Но есть же еще интеграторы-аутсорсеры-прочее. Там ты стек не выбираешь, сегодня одно, а завтра — новый клиент, со своим «особенным» зоопарком
amarao
Ну тут всё просто. Либо у интегратора отряд многоруких шив (сказали делать на vmware c docker swarm, делаем на docker swarm, сказали писать на powershell и salt, пишем на чём сказали. Да хоть HANA c 1C), либо зоопарк специалистов в каждой технологии.
В целом, интеграторо-аусорсный бизнес мне выглядит слегка непривлекательным. Его используют с какой целью? В 99% для удешевления стоимости владения инфраструктурой. (Да, бывают исключения, когда, например, IBM привлекают за большие деньги спасать неудавшийся уход с банковской системы, но это исключения).
Соответственно, интегратор оказывается в ценовом цейтноте, что неприятно транслируется в запас эксперименты, исследования и внутреннее качество.
hellamps
я думаю, по разному используют:
Но со стороны работника-специалиста, не стремящегося в менеджмент, но стремящегося улучшать собственные скиллы — я согласен, сомнительное удовольствие.
0xd34df00d
Интересно. Очень часто встречаюсь с обратным мнением — что настоящему профессионалу и специалисту должно быть все равно, с каким стеком работать.
HappyGroundhog
Не вижу противоречий, скорее наоборот. Настоящему профессионалу действительно без разницы с чем работать, он обычно уже владеет многим или быстро разберется. Но он же как раз уже и может позволить себе выбирать инструмент/стек, с которым бы он хотел работать.
sentyaev
Это довольно редкий кейс. Может сработать если вас берут хотя-бы техлидом на новый проект и вы обладаете большой экспертизой.
В стартапах обычно выбирает СТО исходя из необходимой скорости разработки, наличия разработчиков на рынке и бюджета.
А в больших компаниях обычно есть 3-4 стека на выбор, с заготовленными темплейтами.
HappyGroundhog
Здесь речь не о выборе стека внутри компании, а о том, что если вам интересно амазоновское облако, то вы будете искать компании/команды где плотно работают с ним. Мне вот сейчас интересна продуктовая разработка в области waf, ids, soc и я и ищу соответствующую компанию. Хотя меня с руками оторвут в царство закрытого легаси, но я туда больше не хочу.
hellamps
настоящему профессионалу и специалисту не то чтоб все равно, имхо. Он может. Но не всегда станет :)
sentyaev
Это зависит от того каким специалистом вы хотите быть.
С одной стороны можно изучить вдоль и поперек, например Spring, или какой нибудь Laravel.
С другой сторны можно независимо от технологии развиваться в знании какой-нибудь предметной области, напримр Логистики или Финтек.
С третей можно… да много этих сторон, и безопсность, и производительность, и архитектура, и т.д.
А главное, что любой из этих специалистов, будет востребован.
Win08
Я правильно понял, что вопрос именно про 20Мб? У нас вообще 10 ;) Этого достаточно для 99,999% документов, а льют их у нас от 4 000 до 14 000 в сутки. Да, пару раз в год бывают проблемы, решаем в индивидуальном порядке.