Рассекая просторы vc.ru, уже несколько раз натыкался на материалы о найме программистов и не без интереса читал их, ведь я сам программист, и мне любопытно было узнать, как нас оценивают на собеседованиях.
Мои впечатления? Я в печали... Почти все материалы, на мой взгляд, напоминают «вредные советы».
В особенности «порадовала» последняя прочитанная статья: «25 классических вопросов, которые HR-ы задают программистам на собеседованиях» ( ссылка ), после прочтения которой и возникло желание написать данный материал.
Сразу оговорюсь, вся статья — это сугубо личное мнение, однако нашедшее поддержку в лице друзей и коллег программистов.
Итак...
Первая встреча, собеседование без тех специалиста
HR-ы, не обманывайте себя. Вы никогда не поймёте на сколько хорош программист…
Разве что только когда сможете воткнуть электроды ему в ухо и запустить end-to-end теститрование. Но пока таких технологий нет, всё что Вы можете оценить — это адекватность и, хотя бы отчасти, мотивацию человека сидящего перед Вами.
И поверьте, этого достаточно.
Ведь Ваша задача найти человека, который сможет влиться в коллектив, плодотворно в нём работать и чтобы его работа вознаграждалась тем способом, который он ожидает, и который может обеспечить Ваша компания(деньги, признание, интересные проекты и т.д.).
Все попытки спрашивать какие то технические нюансы будут выглядеть неуместно и беспомощно. Лично меня очень сильно раздражает, когда меня спрашиваю о том, в чем сами не разбираются. Хочется просто встать и уйти.
Что ещё можно спросить на первом этапе? Зависит от специфики вакансии.
Если Вам нужен опытный человек — спрашивайте об опыте, узнавайте какие задачи он решал, какие трудности преодолевал.
Если Вам нужен человек, которого можно обучить, дайте ему пару логических задачек, проверьте живость ума.
Собранной на первом этапе информации хватит чтобы отсеять 80% - 90% кандидатов.
Часть вторая. Собеседование с тех специалистом
НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ!
Пожалуйста, великие гуру найма и технари, любящие спрашивать теорию, объясните мне в комментариях в чем смысл Ваших вопросов?
По моему, если ответ на Ваш вопрос лежит по первой ссылке в гугле, то спрашивать его не имеет смысла. Разве что Вы ищите человека на закрытый объект, где нет доступа в интернет. Но в остальных случая — Я считаю теоретические вопросы пустой тратой времени, которая ничем Вам, как работодателю, не поможет.
Я лично знаю несколько человек, которые учились со мной на программистов. У них от зубов отскакивали все теоретические выкладки, но когда дело доходило до реального программирования — ничего путного они сделать не могли.
Также негодование вызывают вопросы, которые возможно и касаются будущей работы, но разобраться в которых не составляет труда. Например «юнит-тесты». Чтобы научиться писать юнит-тесты уйдёт от силы минут 10.
Прошу обратить внимание, более сложные тесты уже относятся к вопросам об опыте, о которых далее.
Что же, по моему, нужно спрашивать у кандидата?
Спрашивайте технические нюансы из их предыдущего опыта, особенно те, которые пересекаются с будущей работой.
По тому, как человек рассказывает, будет понятно:
- Реально ли он разбирается в вопросе или просто придумал эти пункты для набивания себе цены.
- На сколько его опыт и знания подходят для текущей вакансии.
- Сможет ли он справиться с будущей работой.
- Сможет ли он научиться, если не имеет подобного опыта.
И, как мне кажется, этого достаточно, чтобы сделать финальный выбор.
Больше о человеке Вы сможете узнать только на испытательном сроке.
Для дискуссий приглашаю в комментарии.
Надеюсь данный материал будет хоть кому-то полезен, спасибо за внимание.
Немного мыслей:
1. Теория. Нужна, так или иначе.
- Ну очень глупо доверять веб-разработку человеку, не понимающему HTTP
- Как брать человека в команду на проект без понимания SOLID?
- Как брать специалиста, который не умеет думать? Спрашивать "Справитесь ли вы?" Серьезно?!
Но справедливости ради расскажу такой случай. Я относительно молодой спец-т, всего полтора года. Собеседовался в Рамблер и мне в реалтайме дали задание по 5 пыхе на англ языке -- это все ладно, но задания были чисто по синтаксису, точнее его потаенным местам. Так как я развивался и работал только в 2017-18 годах (эпоха 7 пыхи), то конечно я больше заморочен на ООП, СОЛИДЕ и архитектуре, нежели на синтаксисе языка... крч не очень удачно прошел его :(
2. Тестовые задания
Ну я отказываюсь уже... Но опять же -- дело каждого, тут разные мнения.
3. Ну и удачи вам с инженерами, которые за 10 минут научатся писать юнит-тесты :) Посмотрел бы я, как на его кривой код пишется кривой тест :)
...
А вообще почему это у вас вызывает боль?
Я почти без глубокого опыта после собеседований получаю много предложений. Потому что многим, как вы подметили, важен не уровень, а как человек вольется и на собеседовании часто такое и происходит -- молодые специалисты и кадровики видят хорошего парня и берут его, или у вас не так? Завязывайте со своей оценкой "эти HR -- сплошные ТП".
Сейчас с работой (в Москве) точно нет проблем прогером, а вот найти крутой проект и крутую команду -- есть (это прямо боль :)
...
К проблеме бы я отнес вот какой момент -- не очень тщательно прорабатывают кандидатов и приходится по телефону выяснять все ли так, как в вакансии, кого ищут и как все работает,
а то зовут на бекенд, а на собесе JS фреймворки всплывает на 70% работы
- Ну очень глупо доверять веб-разработку человеку, не понимающему HTTP
- Как брать человека в команду на проект без понимания SOLID?
- Как брать специалиста, который не умеет думать? Спрашивать "Справитесь ли вы?" Серьезно?!
Ну например фронтэндеру не обязательно понимать HTTP.
У него есть готовые либы, которые делают запросы на сервер и получают оттуда данные в заранее определённом виде. Поверх этих данных он пишешь фронтэнд.
А принципы и понимание работы самого фронтэнда уже больше относятся к опыту.
По поводу SOLID и ООП в целом - функциональщики негодуют... А если серьезно, в реальных проектах все эти принципы и модели далеко не всегда применимы. К тому же в каждой компании есть свои правила написания кода, некоторые по моделям, некоторые нет.
Про спрашивать у соискателя там вроде не было, но даже вопрос в лоб чем плох? Может он сам поймет что не потянет и откажется...
2. Тестовые заданияНи разу не делал. Жалко время терять. Хотите посмотреть мой код, вот вам гитхаб.
3. Ну и удачи вам с инженерами, которые за 10 минут научатся писать юнит-тесты :) Посмотрел бы я, как на его кривой код пишется кривой тест :)Красота кода делается с помощью линтеров. А по второму - методология TDD - сначала тест, к нему код. Ну и тимлид или старший программист или кто там ещё должны ввести новых разрабов в курс дела, как и что пишется. Везде свои нюансы.
По TDD согласен, но TDD разработка тянет много чего кроме "можно научиться Юнит-тест писать за 10 минут", я об этом
По поводу фронтендер без HTTP, функциональщик без SOLID -- это уже узкие нюансы... понятное дело я говорил про SOLID для ООП, HTTP для веб бека :)
Но все так или иначе увязано с теорией, я еще про БД промолчал...
Я имел ввиду такой пример: в своё время меня на мидла брали, Я ни сном ни духом о тестах, просто опыта подходящего не было, не нужны они были.
Меня начали спрашивать про эти тесты, рассказывать как они важны и т.д.
Затем когда пришло время написать эти самые тесты - открыл маленькую статейку, за 5 минут прочитал, за вторые 5 минут написал тест.
Вопрос - зачем меня про них спрашивали? То что Я их не знал никак не сказалось на решении о принятии на работу. Научиться их писать не тяжело. Зачем тратить и своё и чужое время на такие вопросы? На многих собеседованиях бывал и вот такие не значительные не важные вопросы занимают много времени и отодвигают от сути.
Чтобы написать один тест нужно не больше 5 минут. Но чтобы научиться писать код с тестами нужно много практики, изменить свой подход к написанию кода. Писать более компактные единицы кода, уменьшать зависимости между ними, и т.д. Это делается не за 5 минут. Тестирование в основном не про тесты, а про написание кода, который легко ими покрывается.
Тут уже опыт очень важен. Мне кажется с годами просто вырабатывается чувство вкуса и ты уже даже без тестов пишешь код, на который можно без труда накатить тест при необходимости.
Именно, и это не гуглится.
Прошу обратить внимание, более сложные тесты уже относятся к вопросам об опыте, о которых далее.
Я не знаю что такое «более сложные тесты». Иногда даже простые тесты не напишешь для лапшиобразного кода.
Научиться их писать не тяжело. Зачем тратить и своё и чужое время на такие вопросы?В том-то и дело, что научиться их писать долго и тяжело. Вы кстати практически согласились с этим в следующем комментарии.
То, что вас по итогу взяли, не отменяет важность этого вопроса. Может остальные кандидаты были хуже, а позицию срочно нужно было закрыть.
Лапшеобразного кода не будет, если есть опыт, а важность опыта Я подчеркнул...
Опыт значит важен, а вопросы на его выявление - нет. А как тогда оценить опыт? Чем вопросы про тесты не вопрос про опыт, например?
Понимание важности тестов приходит или с опытом, или при попадании в правильную команду, что тоже ценно.
Прочитайте пожалуйста статью ещё раз.
Я советую спрашивать о технической реализации задач из их опыта.
Как Я понял по последним Вашим комментариям Вам просто охота поспорить?
То что мы друг друга не понимаем, это нормально. Не нормально обвинять кого-то в том, что он хочет просто поспорить.
Затем когда пришло время написать эти самые тесты - открыл маленькую статейку, за 5 минут прочитал, за вторые 5 минут написал тест.Это вы написали выше. И вам тут не один человек пишет, что умение писать тесты развивается на за 5 минут в гугле. Это долгий процесс. Поэтому этот вопрос очень важен и показателен. А то, что вас в итоге взяли не говорит ни о чем, кроме как, что даже без этого умения вас сочли наилучшем вариантом в тот момент.
Умение писать тесты не равно умение писать хороший код.
Умение писать хороший код позволит за 5 минут научиться писать тесты поверх этого кода или вообще начинать писать сначала тесты, а потом код.
Так понятно?
Я не знаю что такое "хороший код" для вас. Это субъективный критерий. Для меня это в том числе и код, который легко покрывается тестами. То есть нельзя писать хороший код, если ты не умеешь в тестирование.
Да не особо и субъективный, есть общие правила и во многих компаниях они схожи.
До того как начал писать тесты писал хороший код, потому что следовал общепринятым правилам. Как Я понял что хороший? Во первых потому что был написан по правилам, во вторых потому что он прекрасно покрылся тестами, когда Я решил это сделать.
А откуда эти правила по вашему взялись? Просто следовать этим правилам, не понимая зачем и откуда они - это карго-культ. Слепое следование правилам не гарантирует правильного результата. Я видел много случаев когда люди следуют правилам, но в итоге выходит плохой код. А ваше утверждение по поводу качества вашего кода я не могу проверить. Свой код всегда хороший.
Это вопрос не только об умениях написать 10 строк кода, но и о подходах и их понимании. Повод поговорить о том, как вообще контролировать качество своего кода, когда тесты важны, а когда мешают, есть ли понимание разницы между разными типами тестов. Как написать тест, который действительно тестирует, а не просто для галочки.
Вопрос про тесты вполне на уровень мидла.
То есть в Вашей команде нет каких то принятых "правил хорошего кода"?
Или новому человеку невозможно объяснить как пишутся приложения именно в Вашей компании?
Адекватный человек поймет например концепцию TDD сразу прочитав о ней, плюс какое-то время чтобы привыкнуть так писать код.
Я считаю что главное чтобы у человека был живой ум и способность к обучению + определенный опыт в зависимости от вакансии. А остальные вещи он постигнет в ходе работы.
"правила хорошего кода" - это только одна из частей контроля качества.
Адекватный человек пойметВы никогда не знаете, что и как человек поймет. А разговор о тестах, это разговор об уровне понимания. Такой способ начать разговор на тему качества. Например, можно задать вопрос: "Что такое плохой юнит-тест". По ответам станет понятно, насколько человек вообще задавался вопросами качества, какие он исповедует принципы.
А остальные вещи он постигнет в ходе работы.Есть довольно много мест, где команда ждет, что человек сразу будет делать правильно без надзора и лишних объяснений. Проще задать лишний десяток вопросов на собеседовании, чем потом исправлять код или еще хуже - последствия.
То что команда ждёт не значит что не нужно проверять новый код...
Человек может знать как надо правильно, но сознательно не делать этого и дополнительные вопросы на собеседовании не решат этого.
А предотвращать плохой исход просто: спрашиваете о технической реализации задач из опыта, спрашиваете почему так, а не эдак и сразу понятно как такой человек думает и решает задачи. И, на мой взгляд, это эффективнее чем просто тупо вопрос о тестах с неба.
Вопрос про тесты - это как раз "о технической реализации задач из опыта". Задачи контроля качества кода. Если про тесты не смог ответить, о чем дальше говорить? Просто ставим галочку "в этом месте слабовато" и идем дальше.
Ну вот Вы и пропустили программиста который реализовал разные проекты в которых не было потребности в тестах, но для себя Вы внесли только что в тестах слабовато.
Вы реально не понимаете разницы?
Для себя я вынес, что в контроле качества слабовато, идем по остальным темам, которые пойдут отдельными пунктами. А там посмотрим, что по балансу.
Вы реально не понимаете разницы?Какой разницы? не понял...
Дедукция и индукция.
Многозначительно.
Иии?
Вот разница в подходах. Какой вариант лучше выбирайте сами.
понять концепцию - не значит научиться применять её. для этого собтсвенно и нужен практичсекий опыт. в частности, это то, что отлдичает джуна от мида - теоретичсеких знаний-то полно, а вот опыта их применения...
И? Ты дублируешь мои слова про опыт.
приличный программист может научиться чему угодно - дай только время. однако не все компании могут позволить себе ждать и потому проверяют на интервью, есть ли у вас опыт работы например с TDD. есть - пллюс балл, нет - минус балл. но это только один из вопросов
я на яндексовском интервью тоже в каких-о вопросах сильно лажал и даже дал обещание что подтяну их. но по сумме баллов взяли. НО - из 3-4 команд, которые мной изначально инетерсоваись, 1-2 отвалились именно из-за лажи в этих вопросах
И? Выбирай по опыту.
Я говорю не выбирать по опыту?
Вы вообще читали саму статью?
и пара-па-пам -- у вас есть опыт тестирования? Тот, который годами (по вашим словам) ? ПОтому что годами и 10 минут -- разные величины, и годы и 10 минут -- сроки из ваших цитат, но критика на вопрос определенная
Прочитайте пожалуйста статью, а затем лезьте в комментарии.
Комментарий удален модератором
Ну а при найме бывает по другому?
Специалисты которые всё знают в работе не нуждаются.
Приходится выбирать из тех кто ищет.
это не означает "тестирование знаь не нужно", это означает "на вашем уровне его знать не нужно". представьте, уровеь вырастет и вы пойдёте в гугл. и что тогда?
Ну так Я не говорю что знать не нужно.
А что вы тогда говорите?
Все ответы Выше
а теперь порчти какую-нибудь книжку про тестирование или TDD. мнение сразу изменится на противоположное. а "я в этом разбираюсь и считаю что не нужно" - это извини позиция джуна
Извиняюсь, это откуда? К чему вопрос?
я ошибся, "не" пропустил. речь была о том, что ты сначал разберись в нём хорошо, а потом уже говори что тестирование/TDD можно изучить за два дня. а позиция "я в этом не рабираюсь и оно не нужно" - некорректна
Хз, но обычно под тестированием/не тестированием кода скрывается некая гигиена в работе...
Так что нервничать из-за теста -- такое себе, не думаю, что из-за этого принимали решение...
Если человек мне на вопрос про тесты сразу скажет про TDD, это отличный повод поговорить на тему какие проблемы были когда он это внедрял на проекте, обсудить почему у нас TDD не выстрелило и как это исправить итд.
Тоесть сам по себе вопрос про тесты на собесе отличный - он даёт много тем для разговора о реальном опыте человека)
Кек.
Не согласны?
Не согласен.
В целом, всё, конечно, сильно зависит от того, что вы понимаете под "фронтендером".
Если это кодманки способный по доке на API и псдшке наверстать формочек - то, конечно, ему ничего кроме ссылки на доку по ангуляру\реакту знать не обязательно.
Но, в моём понимании, да. Полноценному фронтендеру необходимо знать как работают те вещи, которые он использует в своей работе.
Пример из жизни.
Фронт на реакте редаксе графкл на аполо клиенте.
Где здесь нужно знание HTTP?
Второй пример.
Фронтовикам дайют JSON-ки с данными, которые к ним будут прилетать.
Они вокруг них строят интерфейс и всю возможную логику. Отдают бекэндерам, те встраивают общение с сервером.
Где здесь фронту нужно знание HTTP?
А если бэкэнд отвечает что запрос с фронтэнда кривой, то что будет делать фронтэндер? Идти к бэкэндеру или сможет сам посмотреть в http запрос и понять на чьей строне баг?
Я просто оставлю это здесь.
Вроде по русски написано.
Оу май. Какая дичь. Я думал это как-то криво сформулировано, но оказывается на самом деле бэкендеры интегрируют http запросы во фронтенд. Скажите где это такое? Не хотелось бы попасть туда.
Поверьте, туда Вы при всем желании не попадете. Отбор очень строгий, ограниченый и как раз по всем критериям, которые Я советовал избегать.
Спасибо, что оценили мои возможности по фотографии.
Я оценил Вас по Вашим комментариям
и при этом не удалось найти людей со знанием http? да ладно, здесь все свои...
При чём тут найти, прочитай комментарии с самого начала.
Гугл подсказывает: https://www.linkedin.com/in/kolkonikz/
Это, в целом, многое объясняет.
Ахах, вот ссылка:
https://www.linkedin.com/in/kolomeitsev/
От того Я пароль забыл.
Ну и данные не обновлял уже 3 года
Что там тебе понятно?
Что вы пилите сайтики под ключ и вам не нужна теория computer science.
Да, у меня есть веб студия, которая пишет сайтики.
Что тебе это говорит? Или ты считаешь что человек должен работать только в одном месте? Или ты считаешь что подработок не должно быть?
Фронту нужно знание HTTP в тот момент, когда результаты его работы отдаются через HTTP и\или имеют в себе хотя бы один вызов оного.
Функция возвращает JSX код, который рендерится в HTML. Как он попадает к конечному клиенту глубоко плевать и без этого знания он прекрасно проживет и может написать прекрасный код.
Ok, вам плевать. Рад, что мы работаем над разными продуктами. :)
Мне не плевать, плевать фронтендеру в конкретном примере.
Не надо выдирать слова из контекста и переходить на личности.
Но если мы о личном, то Я тоже рад что мы не трудимся в одной команде. Такой зануда свёл бы меня с ума своим бубнением и нытьем.
вот именно здесь - не нужно. а другие работают напрямую с сервером и им может быть нужно
Ну а другие - это другой случай не относящийся к данному примеру.
к данному проекту, хотите сказать? а что будет, когда этот проект кончится и команда перейдёт к другому? фронтэндер без знания http моджет быть джуном, корого ставят на какие-то узкие участки работы, но думаю для получения лычек мида ему придётся всё же ознакомиться с
У них в компании работа так построена, по данному возможно никогда не будет это во первых, а во вторых Я не говорю что не нужно знать, Я говорю что без этого можно работать, а когда придет время, узнать не проблема.
ну ведь то что в одной компании так построили процесс, не означает что вебдем такое знать не должен? есть станд. набор знаний? если в каокй-то компанни скажем лямбды запретят - они из этого набора не исчезнут
И?
напомню - речь у нас шла о том, что должен зхнать фронт-эндер. и ваш аршмумент аналогичен словам "лямбды знать не нужно, поскольку в копмпании XX их вообще использовать запретили"
Нет, речь шла о том что чтобы нанять фронтэндера можно не спрашивать на собеседовании знает ли он HTTP
ага. а поскольку всегда можно найти контору, где не используют ту или иную практику (те же TDD), то на собеседованиях можно не спрашивать вообще ничего. та-да!
Ну если Вы меня так поняли, Ваше право.
Но почему то Я уверен что Вы никакого отношения к найму вообще не имеете.
Комментарий недоступен
Они будут так делать, если это будет в тех задании или правилах компании. И это возвращает нас к менеджменту и контролю над новыми сотрудникам.
кк контролю над джунами, опять же. если у вас более опытный разработчик - то за ним не надо ходить как нянька
Если у тебя в компании нанимают разработчика, который будет самым старшим сразу, без проверки, передачи дел и введения в курс - удачи...
не самым старшим, а отвечать за свой участок работ - это нверно и есть основное отличие мида от джуна. и проверять его конечно нужно (это называется code review), но это никак не означает, что он может ничего не знать
вообще такое впечталение что у вас есть джуны, плюс наблюдающий за ними вы - и вы думаете что везде точно такая же конфигурация с бепомощными джунами и одним чуть ли не лидом
Вы делаете какие то ничем не обоснованные выводы с потолка.
Зачем то мне по код ревью говорите, хотя Я о нем уже в комментариях писал.
Покажите мне, где Я советую нанимать человека без проверки опыта?