Senior Engineer в поисках работы. Как я прошел 15 технических собеседований и что я об этом думаю

Автор оригинала: Włodzimierz Rożkow
  • Перевод
Продолжение истории о том, как я проходил собеседования в разные компании на разные позиции. В этот раз закроем несколько вопросов и комментариев касательно первой части и продолжим говорить о тестовых заданиях и технических собеседованиях.

К моему удивлению, предыдущая статья о собеседованиях с рекрутерами и HR вызвала неожиданный интерес: более 100 000 просмотров по всем источникам. Я получил кучу положительного фидбека в личку, мне написали бывшие коллеги, которых я последний раз видел лет 5 назад; героини некоторых историй; парень, которому я несколько недель назад продавал системник через OLX (аналог Slando, — прим. пер.); барабанщик с которым мы в прошлом году играли метал в гараже, и, как это ни странно, довольно много рекрутеров, которые поинтересовались моими мыслями касательно тех или иных аспектов собеседований и найма. 250 человек зачем-то добавились ко мне в LinkedIn :).

Перед тем, как перейти к делу, отвечу на самые популярные вопросы и личных сообщений и комментариев.

Как договариваться о зарплате на собеседовании


Много комментариев касались денег. Я умышленно не уделял этому большого внимания, потому что торги — отдельная тема, однако комментаторы всё равно её затронули и указали на недостатки моей стратегии — например, сразу же называть цену. Вот две хорошие статьи, которые значительно детальнее и профессиональнее рассматривают этот вопрос:


Рекомендую прочитать перед поисками работы.

Несколько мыслей касательно рекрутинга


Я ни в коем случае не даю советов рекрутерам о том, как им делать их работу. Я не профессиональный рекрутер, и не знаю как работает их внутренняя кухня. Когда мне нужно было искать себе персонал (не только проводить технические собеседования, а именно искать и нанимать — полный цикл), то это были junior-позиции, соответственно, у меня не возникало особых трудностей.

В личных сообщениях у меня спрашивали, каким нужно делать первое сообщение о предложении поработать, чтобы оно выглядело привлекательно и заинтересовало специалиста, как обратить на себя внимание?

Мне кажется, что от рекрутера, к сожалению, ничего не зависит. Все, что может сделать рекрутер — найти как можно больше контактов специалистов нужного профиля и проспамить разослать им всем свое предложение. После этого нужно ждать и надеяться, что кто-нибудь из них или уже колеблется или в активном поиске работы. То есть, тут 20% работы с базой и 80% удачи. В сети много материалов о том, как правильно составлять вакансии и так далее, однако как по мне — ключевой фактор — это именно желание кандидата сменить работу.

Рекрутинг — это продажа вакансии кандидату. Чем быстрее вы это поймете и начнете прокачивать свои навыки продажника — тем лучше. Ой, я же говорил что не буду давать советы :)

Так же я убежден, что во время поисков работы кандидатам нужно браться за все вакансии, которые более-менее подходят, потому что на самом деле выяснить, о чем вакансия, можно только во время разговора с техническими специалистами. В своих поисках я практически не обращал внимания на то, что написано в вакансии, и выяснял нужные детали на этапе технического собеседования. Считаю, что этот способ есть наиболее правильный, потому что так значительно увеличиваются шансы найти крутой проект, который может прятаться за стандартным серым описанием. Мой опыт только однозначно подтверждает этот тезис. Ни одного раза в вакансии не было написано конкретно, что нужно будет делать. Только общие фразы вроде «кодить код, тестить тесты, деплоить деплоймент».

Наниматься в компанию или на проект


В наших реалиях — однозначно на проект.

Как выбирать себе тайтл


Я позиционировал себя как кандидат уровня Senior Software Engineer и выше — Team/Tech Lead, Principal Engineer, Software Architect, Project Manager, People/Group Manager и так далее. Именно это «выше» и имел ввиду под "+" в «Senior+».

Мне кажется, что тайтл ничего не значит. Важно лишь то, чем ты будешь заниматься на самом деле, а это можно выяснить только у того человека, с которым будешь работать.

Итак, дамы и господа, перейдем к техническим собеседованиям.

Этап второй. Технические собеседования


В этой части будет больше моего субъективного опыта и философии, нежели советов. Информации о том, что спрашивают на технических собеседованиях, и как к ним готовиться, в интернете полно.

disclaimer: автор не является турбоинженером-олимпиадником, поэтому некоторые решения или комментарии могут вызвать у соответствующих специалистов улыбку, баттхёрт, желание указать автору на его ошибки или низкую квалификацию. С удовольствием выслушаю конструктив.

Всего я прошел 15 технических собеседований, что, как по мне, не так уж и много. Я мог бы пройти значительно больше, но в среднем ожидал неделю от первого контакта с рекрутером до разговора с техническим специалистом. Это при том, что у меня практически не было ограничений по времени. Всего один раз мне назначили собеседование на время, на которое у меня уже было запланировано другое собеседование. Также замечу, что все компании или рекрутеры выходили на меня сами. Я не посылал CV ни в одну компанию первым. Это к вопросу что не сеньор ищет работу, а работа — сеньора.

Тестовые задания


Много компаний дают тестовые задания перед тем, как перейти к разговору, чтобы отсеять нерелевантных кандидатов. Несмотря на то, что многим не нравится вкладывать свое время в тестовые задания, особенно если они довольно объемные, я все-таки считаю, что это хорошая практика. Рассмотрим, какими могут быть тестовые задания.

«Сделайте проект с нуля (возможно, используя конкретную технологию) и выложите его на GitHub» — как по мне, наихудший вариант. Вы можете много времени потратить на бойлерплейт, на инфраструктуру вокруг решения, а интервьюера, как правило, будут интересовать несколько мелких деталей реализации, заложенных в условиях задачи. Хорошо, если у вас есть под рукой, например, шаблоны проектов и вы можете за 5 минут поднять сервер и быстро закодить что нужно. Иначе, придется все вспоминать и начинать с нуля. Также, плохо, если в задании есть условие использовать внешние зависимости, например, не-embedded базу данных.
Позиция DevOps Engineer. Мне прислали задание сделать Vagrant конфигурацию из нескольких виртуальных машин, среди которых должны были быть веб-сервера со статикой, балансер для них и Jenkins. Все это нужно было устанавливать и конфигурировать с помощью Chef. А теперь представьте — я никогда не использовал Vagrant, Chef и не настраивал те веб-сервера, которые требовались в задании. Я примерно понимаю как оно все работает, имел дело с похожими инструментами, но никогда не использовал конкретно эти.

Мне пришлось за ночь сесть, установить все это, собрать кучу граблей и в итоге все-таки выполнить задание. Основная сложность состояла в том, что у меня старый MacBook Pro 15-го года, который просто физически не успевал рестартовать контейнеры а так же в том, что я не имел опыта работы с Vagrant.

На суть задачи — разобраться как что устанавливать, — у меня ушло наверное с полчаса. Остальное время (7 с хвостиком часов) я потратил на установку всего инструментария, рестарты—ребуты, тыкание по конфигам в попытках понять, почему оно не работает и так далее.
То же самое задание на Docker Compose я бы сделал, наверное, за час, может даже меньше. Можно ли было не ограничивать кандидата инструментами? Мне кажется, что можно.

Было ли это задание полезно для меня? Однозначно да! Теперь я буду знать что от Vagrant и Chef нужно держаться подальше :)

Потрачено времени — 8 часов.
К сожалению, больше историй про этот тип задач у меня нет, потому что тестовых в целом давали не так уж и много :(

«Вот ссылка на сайт с тестами — пройдите их» — очень классный вариант. В чем суть? Есть SaaS, которые позволяют конфигурировать набор практических и теоретических вопросов, и для решения предоставляют REPL и редактор кода прямо в браузере, а так же дают возможность запустить верификационные тесты. Дальше вы просто идете по заданиям, исправляете существующий или пишете свой код, запускаете его и смотрите результаты. Сами тесты от вас спрятаны, вы видите только результат (passed/failed) и короткое описание теста, которое одновременно может быть подсказкой. Почему этот вариант нравится мне больше всего? Потому что есть однозначный критерий качества выполнения задания, и кандидат точно знает, сколько балов он набрал, работает ли его решения и так далее. Мне лично даже интересно было проходить эти задания. Единственное, я не вижу смысла в теоретических вопросах вроде «что будет, если выполнить этот код» — они легко гуглятся.
Позиция Ruby Software Engineer. Мне присылают ссылку на сайт TestDome, естественно, на кастомный тест. Я кликаю, попадаю в собственно тесты. Мне дают 2.5 часа на прохождение всего набора, по 5-20 минут на каждый вопрос. На самом деле, мне очень понравилось, я давно уже не проходил такие штуки. Особенно пришелся по душе TDD-подход: закодил, запустил, посмотрел что упало, кодишь дальше. Прошел с большим удовольствием.

Сами задачи были довольно простыми: исправить код (Ruby/JS/CSS/HTML), написать валидаторы (Ruby), реализовать структуры данных (Ruby), ничего особенного. Однако тот факт, что сразу же можно проверить, работает ли решение, очень помогает.

Я справился с заданием на 93/100 балов всего за час. К сожалению, этот результат совсем мне не помог в дальнейшем.

TDD помогает в решении, не нужно тратить время на подъем инфраструктуры, репл прямо в браузере — короче говоря, очень круто. Ради такого можно было и месяц подождать — в итоге я получил свою порцию допамина (отлично справился с заданием) и адреналина (часики тикают, времени все меньше!).

Потрачено времени — 1 час.
Также, большим преимуществом этого типа заданий является то, что их проверка автоматизирована. Все мы знаем как интервьюеры «любят» проверять задания, а тут за них все делает машина — очень удобно, как минимум что ничего не нужно выкачивать код и собирать его. Возможно, буду использовать этот метод при найме в будущем.

«Вот репозиторий, там задание, присылайте Pull Request с решением» — такой вариант мне не попадался, но его использовали мои коллеги. Мне он не очень нравится, потому что можно посмотреть, как выполняли задание другие кандидаты (если они были).

Недостатки такого способа очевидны: проверяющему нужно выкачивать код, собирать, смотреть что там, это долго и скучно. Конечно, можно поверхностно посмотреть код в браузере, однако зачем тогда нужно было задание? Давайте тогда на псевдокоде писать.

«Вот репозиторий, там код, отрефакторите его насколько можете» — вариация предыдущего. Это уже лучше, потому что тут с самого начала создаются рамки, в которых можно работать. Недостатки те же: непонятно, когда нужно остановиться. Как говорил Егор Бугаенко, любая программа содержит бесконечное количество ошибок, и исправлять их тоже можно бесконечно.

Авторы задания наверняка имели что-то в голове, когда создавали его, одного мы скорее всего так и не узнаем, что именно для них было главным. Если бы задание имело четкий критерий, тогда это было бы круто. Например, «есть код, он на таком вот железе выдает вот такое результат по быстродействию, отрефакторите, чтобы работало в два раза быстрее». Без критериев работать сложно. В реальной жизни, в реальной работе, мы всегда имеем рамки и ищем оптимальное решение, руководствуясь этими рамками и здравым смыслом. Основная работа разработчика — как раз прочувствовать этот баланс и подобрать соответствующее решение.

К моему огромному сожалению, никто больше не давал тестовых заданий, поэтому выборка у меня совсем маленькая. Разве что могу вспомнить те тестовые, которые я делал много лет тому назад. Все они были первого типа — нужно было сделать проект. Интересно, что я их выполнял в те времена, когда GitHub еще не был таким популярным и нужно было пересылать решение в zip-архиве почтой :)

Мои рекомендации по тестовым заданиям?

  1. Не нравится — не делайте. Если задание, например, заверстать целый сайт или написать круд — ну его в баню. Задания должны быть короткими и сфокусированными на создании контекста для последующей дискуссии, а не просто тестом на то, как вы умеете делать скаффолдинг.
  2. Если задание первого типа — добавьте в репозиторий readme, где в деталях опишите инструкцию для запуска, короткую аннотацию о том, почему вы сделали такое решение, какие в нем есть недостатки, что вам понравилось или не понравилось, как бы вы решили задание, если бы у вас было больше времени, и так далее. Не знаю, помогает ли это реально, но, как интервьюер, я бы однозначно отметил такое документирование решения.
  3. Пишите нормально, но не стоит тратить кучу времени на вылизывание деталей. Как по мне, достаточно просто перечислить в readme все, что вы бы улучшили, если бы это был боевой код.
  4. Обязательно подумайте, какие вопросы к вам могут возникнуть по реализации и почитайте дополнительно документацию о том API, которое вы использовали. Допустим, я давно не работал с concurrency. Я уже давно не практиковался в этом, поэтому после решения я быстро прошелся по всем связанным темам, вспомнил все типовые задания и был готов к разговору.

Что ж, тестовое, вы, надеюсь, успешно выполнили, передали эту информацию рекрутеру, и через неопределенное время вас пригласят поговорить лично.

Техническое собеседование. Интро


Начнем с того, что сейчас уже достаточно редко приглашают в офис на собеседования. В офис меня позвали только несколько раз — для интервью на позиции Solution Architect, Tech Lead и один раз — на менеджерскую должность. Все остальные собеседования проходили по Skype, Zoom, Hangouts. Как и на предыдущем собеседовании с рекрутером, рекомендации те же — хорошая камера, хорошая гарнитура, хороший интернет. К этому так же добавлю условие шарить экран. Поэтому убедитесь, что у вас нет открытых рабочих проектов (если это важно) и других персональных вещей, которые не нужно показывать людям на том конце. Держите под рукой чистый браузер без табов и REPL для кодинга на всякий случай (IDE или repl.it).

Из всех способов связи мне больше всего нравится Zoom. Собственно, его и использовали чаще всего.
Важный совет касательно правильного общения в телеконференциях: заведите привычку не говорить и не печатать на клавиатуре, когда говорит другой человек, и разговаривать по гарнитуре, а не, например, через внешний микрофон ноутбука и внешние колонки.

Почему это важно? Чаще всего с вами будут разговаривать двое людей, соответственно, они не будут использовать гарнитуру. Когда вы говорите, то на их стороне софт включает шумодав, который не дает появиться эффекту обратной связи (фон, свист, эхо). Когда включается шумодав, то их микрофон практически ничего не будет ловить, поэтому вы не будете слышать, что вам говорят.

Когда вы печатаете на клавиатуре, то это создает шум, который передается на другую сторону и тоже включает шумодав. В результате этого фразы обрываются, и создается впечатление плохой связи. Поэтому, всегда нужно ждать, пока люди не закончат разговор. Иначе вы просто не услышите, что они хотели сказать (кроме случаев, когда собеседники тоже используют гарнтируру). Как это ни странно, много людей не знают про эти механизмы. Также полезно отключать (мьютить) микрофон на то время, пока вы не разговариваете, чтобы к людям не прорывались звуки из вашей комнаты. Я воспитан годами работы в энтерпрайзе, где эти правила знает каждый, поэтому для меня все это очевидно, но я видел немало ситуаций когда люди не соблюдали этих элементарных правил и грешили на плохой интернет.
Если все ок, прошли пинги туда-сюда, то начнется разговор. Часто интервьюеры сами предлагают план разговора. Бывает, что у них нет плана, однако как минимум одна тема будет актуальной всегда: «Расскажите о себе и о своём опыте».

Перед собеседованием еще раз пройдитесь по вакансии, обратите внимание на требования, которые предъявляются к кандидату и подготовьте спич. Я проходил собеседования на Tech Lead, DevOps/SRE, Ruby/Java Software Engineer и в каждом случае рассказывал разные вещи, которые, как мне кажется, заинтересовали бы интервьюера больше. Старайтесь не углубляться в детали, а предоставлять ту информацию, которая создаст вектор для дальнейшей дискуссии. Не стоит детально говорить о том, что вы делали 5 лет назад (если конечно это не было чем-то экстраординарным).

Я говорил, например, такое: «8 лет работал в энтерпрайз-конторе, в основном с Java. Дальше пошел в стартап, там занимался инфраструктурой. Последние два года пишу в основном на Rails». Все, у интервьюеров есть достаточно информации, и они будут раскручивать разговор в том ключе, который их интересует.

А вот теперь неожиданный факт.

Ваше резюме никто не читает


Честно говоря, это оказалось для меня большим открытием. Ну хорошо, рекрутеры не читают профиль в LinkedIn, потому что он может быть не обновлен, HR обладает навыком просматривать CV по диагонали, и выделять для себя основное. А вот люди, которые проводят техническое собеседование, уж точно не будут читать ваше резюме. Ни одного, подчеркну, ни одного раза я не почувствовал, чтобы люди хотя бы одним глазом глянули на то, что я там понаписывал. Я подозреваю, что, как правило, они узнавали о том, что нужно проводить техническое собеседование за день до собственно самого собеседования, и решали почитать CV за 5 минут до звонка, а там уже как-то будет.
Поймите меня правильно: я не нарцисс или балерина «кружите меня, кружите». Я знаю, что у меня есть много слабых сторон (как со стороны технаря, так и со стороны менеджера). Я не ожидаю, что интервьюеры будут на меня смотреть, как обезьяны на Обелиск.

Я не требую, чтобы мне пели дифирамбы и высказывали уважение с первых минут разговора.

Я всего лишь ожидаю от людей профессиональной подготовки, тем более, что она занимает всего 10 минут. Перечитать CV, возможно посмотреть ссылки, которые там есть, подготовить примерный список вопросов и сократить общее время разговора.

Лично я всегда читал CV перед собеседованием и продумывал, что меня будет интересовать в разговоре с кандидатом. К сожалению, нормальное резюме у нас почти никто не умеет готовить, так что задача непростая.
И снова выскажу свое неудовольствие таким отношением. Я и вы, если вы уже сеньор-помидор, являетесь специалистами относительно серьезного уровня в своей сфере (напомню, у меня это формошлёпство и круды). Таких как мы, не очень много на рынке, поэтому, пожалуйста, проявите уважение, ознакомьтесь с тем, что я делал. Я же прочитал про вашу компанию, проект, клиента. Я ожидаю, что ко мне будут относиться, как к человеку. Почему происходит обратное?

Вы никому не нужны


А вот это меня уязвляет больше всего. В 80% случаев я имел дело с сердитыми, заспанными, уставшими интровертами, которые явно не были заинтересованы в том, что бы кого-нибудь нанимать. Это были технически грамотные люди и хорошие специалисты, но почему-то у них совсем не было желания собственно нанять себе коллегу, не было желания взять себе в команду хорошего инженера который им поможет.

Я убежден, что это были люди, на которых просто повесили обязанность проводить собеседования. Несколько раз мне говорили, что нужный человек был в отпуске, или не успел приехать, или занят, или еще что-нибудь. У них и так куча своих дел, проблемы на проде, не успеваем спринт, митинги с клиентом, а тут опять очередной кандидат приперся, что с ним делать, а? Из этого следует проблема: интервьюеры не рассматривают вас как человека, с которым им нужно будет работать, а просто пытаются оценить, нормальный вы или нет с их точки зрения. Достаточно частой была ситуация, когда «ой тимлид сейчас занят, поэтому собеседование будет проводить другой человек».

У меня было всего несколько разговоров с инженерами, по которым было видно что да, им реально нужны люди, они хотят нанять хорошего специалиста, у них есть план на меня и так далее. А поэтому переходим к следующему пункту.

Вы не будете разговаривать со своим будущим боссом или тимлидом


Это следствие из предыдущего. Я глубоко убеждён, что вы должны говорить с тем, кому вы потом будете подчиняться, формально или неформально. Во всех организациях есть какая-нибудь иерархия, будь это Scrum-команда или кровавый энтерпрайз. Везде есть человек, который будет присматривать за вами (как минимум на старте).

К сожалению, вы ничего не сможете с этим сделать. Егор Бугаенко в своем посте «Why I Don’t Talk to Google Recruiters» очень хорошо описал эту ситуацию. Если вы будете требовать разговора со своим будущим боссом — вы просто не попадете ни на какое собеседование.

Мне кажется, что сейчас это одна из самых больших проблем найма у нас. Возможно, это продиктовано спецификой проектов — аутсорс, где люди что-то делают на потоке. Возможно, в целом плохой культурой общения и мизантропичной ментальностью, я не знаю.
В англоязычных блогах часто пишут, что найм является одним из ключевых направлений, жизненно необходимых для построения успешной компании. Я думаю что нашим компаниям понадобится еще много времени, чтобы прийти к этому и сформировать правильную культуру. А пока что приходится аутсорсить это заказчикам.
Немного из прошлого опыта. Когда я нанимался на текущую работу, то разговаривал непосредственно с CTO и CEO. Я должен был бы быть первым инженером в стартапе, поэтому и отношение ко мне было очень скрупулезным и серьезным. В результате мы отлично сработались, да и собеседование было одним из лучших, которые я проходил. Мы обсуждали не только технические детали, но и первые шаги и планы на несколько месяцев вперед.
Даже если собеседование проводить будет не ваш непосредственный руководитель, обязательно требуйте долива пива после отстоя общения с ним перед тем, как принимать предложение (конечно, если удастся пройти все этапы).
Пока что все, материалов и мыслей много, опять вышел лонгрид, как бы я не старался. В следующей части продолжим рассматривать тему и перейдем к конкретным вопросам и методикам, которые применяют на технических собеседованиях.
Поделиться публикацией

Комментарии 105

    +1

    А что вы думаете о практике задач на написание программ при помощи шариковой ручки и листа бумаги при прохождении технического интервью? Интересно было бы почитать об этом в вашей следующей статье о конкретных методиках.

      0
      А что вы думаете о практике задач на написание программ при помощи шариковой ручки и листа бумаги при прохождении технического интервью?

      Сам так делал очень много раз! Заставлял людей на собесах писать физзбазз )))

      Сейчас я больше за repl.it. Подробнее в следующей статье.
        +2
        Если мне предложат писать код ручкой на бумажке, то я соглашусь только с условием, что на рабочем месте я также буду писать код ручкой на бумажке после найма. А скорее всего, я пошлю такое предложение далеко.
          0
          А скорее всего, я пошлю такое предложение далеко.

          У меня за все время только один такой жесткий кандидат попался. Все остальные без проблем решали на бумажке и на доске )))
          Но больше я такого практиковать не буду, ведь есть repl.it.
            0
            Я может не откажусь, но про себя сочту технического специалиста от компании весьма странным человеком, занимающимся какими-то своими мат. теориями за счет компании. Это одна из родовых болезней IT — ученые (теоретический склад ума) в продакшн. Побочными последствиями идут самописные костыли, экзотические языки и фреймворки, три переезда в год с платформы на платформу, с языка на язык, с базы на базу (найдя гипотетическое преимущество, а проще говоря интересно поиграться). Но в то же время такой подход «гарантирует» успешность, ведь у нас парное программирование и прочие золотые пули, наиболее модные в этом году.

            Далее постараюсь понять — он там один такой или другие такие же.
            –3
            А скорее всего, я пошлю такое предложение далеко.

            Вот и прекрасно. Так хорошо отсеиваются неадекватные истерички.
              +6
              Согласен, что это прекрасно. Я тоже не хочу работать на компанию, где людей ценят не по реальному опыту, а по коду на бумажке. Безусловно, написать обход в глубину какой-нибудь существенно полезнее, чем обсудить подводные камни использования какого-нибудь ORM или архитектуры БД для микросервисов.

              Помню у нас в одной компании работал чувак, который писал свой DI, говорил что с нами работать неинтересно ибо уровень слабоват, ушёл в Люксофт и напоследок оставил API, в котором для добавления нового события в календарь нужно было передавать весь массив событий. А если не передать, то все удалялось из базы, включая те события, которые уже состоялись. Очень эффективно было гонять массивы из сотен событий на UI и обратно, пока не переписали. Зато он знал принципы SOLID
                +5
                Какую-то внутренне-противоречивую фигню вы сказали: «надо на собеседовании узнавать про архитектуру, но знать архитектуру — это плохо»

                Я тоже не хочу работать на компанию, где людей ценят не по реальному опыту, а по коду на бумажке
                Реальный опыт, написанный в резюме — это обычно просто ложь. Очевидно, вы провели слишком мало собеседований, чтобы понять, что по «реальному опыту» можно нанять только очень клевого вруна.

                Безусловно, написать обход в глубину какой-нибудь существенно полезнее
                Физбаз написать очень полезно. Если у человека такая каша в голове, что он Физбаз написать не может, то пусть он хоть 100 книг про ОРМ напамять заучил. Будет приходить, расставлять пальцы — какой он крутой архитектор, знает как правильно архитектуру БД для микросервисов писать. А потом начнёт писать код, а ты за ним переделывать, потому что багов дикая тьма, а как их исправить — хз. Как-то, к сожалению, купился я на «реальный опыт» и «сладкие речи». Больше такую херню брать не буду.

                Помню у нас в одной компании работал чувак, который писал свой DI, говорил что с нами работать неинтересно ибо уровень слабоват, ушёл в Люксофт и напоследок оставил API, в котором для добавления нового события в календарь нужно было передавать весь массив событий
                Да, очевидно, что он был прав. Его команда была настолько слаба, что какие-то базовые проебы в API заметила только после ухода человека. Очевидно, что он был единственным, кто работал, а остальные ходили, да смузи пили, да архитектуру БД для микросервисов обсуждали.
                  +2
                  Вы ведёте себе весьма токсично, при этом мне кажется, что сами плаваете в теме.

                  Каким боком физзбазз, обходы дерева, бинарные деревья относятся к архитектуре?
                  И вообще, часто ли вы пишете балансировку деревьев в своей повседневной работе? Знаете ли вы, какой алгоритм сортировки используется в вашем языке/
                  фреймворке?

                  Я не говорю, что я сильно верю тому, что написано в резюме. Но поверьте, мне достаточно пяти минут, чтобы определить, насколько плотно человек использовал NHibernate. И если он скажет мне, у меня все было окей и не было проблем, вот тут я пойму, что он не знает о нем ничего, а если расскажет про сложности и проблемы, то будет понятно, что он хотя бы с ним сталкивался.

                  По поводу горе-разработчика DI, то проблема лишь была в том, что он один писал этот проект и никто его не ревьювил. Но для меня такое апи это все равно что не знать таблицу умножения. Это полное непонимание бизнес процессов, целостности данных и перформанса. Пусть он хоть всего Кнута мне перескажет — я не возьму его на работу. Ибо зазубрить можно все, а научить использовать голову — нет.

                  Я решал на собеседованиях задачки про фитильки, про монетки, рассказывал про бинарные деревья, отвечал про 15 паттернов проектирования, писал код на бумажке — все это не имеет никакого отношения к реальному найму на реальную работу.
                    +1
                    обходы дерева

                    Собственно я начал про деревья, так вот, у нас в работе реально было много древовидных (не бинарных и не красно-черных) структур данных и обход (десяток строчек кода) просто показывал может ли кандидат работать с таким и сможет ли моделировать эти самые деревья под разные требования.

                    Когда я давал задачу то я сразу же говорил кандидату что это не просто тест на знание школьных алгоритмов, а необходимость в работе. Более того, я всегда заворачивал задачу в бизнес контекст, например «сделайте пожалуйста структуру классов которая будет работать как абстракция для категорий продуктов, категории могут быть бесконечной вложенности». И дальше просил, например, «как вы будете отдавать данные о категориях на фронтенд чтобы он мог построить дерево, как в типичном интернет магазине».

                    Сортировки и балансировки я не спрашивал, это уже к фаангам.
                      +3
                      Большинство проверок знания что вы хотите дать на бумаге, легко определить словами. Меня на собесах даже sql спрашивали словами, внезапно, челове слушал как я рассуждаю и им этого хватало. Не нужно бумаги, не нужно тестов, в большинстве случаев хватает внимательности и правильных вопросов.
                        –1
                        Не нужно бумаги

                        верно, бумаги не нужно если есть repl.it )))
                        –2
                        Довольно странная бизнес-задача хранить категории продуктов в памяти. Я бы решил её использованием графовой субд, одним простым sql запросом и тривиальным маппингом структур. Зачем тут «обход дерева» ума не приложу.
                          +1
                          Я бы решил её

                          Вы бросились решать даже не узнав ограничений и других условий — не буду же я полностью все перечислять.
                          Довольно странная бизнес-задача хранить категории продуктов в памяти.

                          Это лишь пример как дать задачу не об абстрактных деревьях, а о конкретной бизнес потребности (где нужны деревья). В реальной работе это были не совсем категории, но объекты имели вложенность, и да, нужно было этим всем оперировать в памяти, и нет, графовую субд использовать было нельзя, и нет, простой sql запрос годится только для доставания скелета, но не для всей обвязки, да и работал бы он очень медленно для наших требований.
                          Зачем тут «обход дерева» ума не приложу.

                          Конечно не приложите, я ведь не буду тут весь продукт описывать )))

                          В итоге кандидаты так или иначе приходили к древовидной структуре. Были конечно весельчаки которые предлагали на каждый уровень вложенности добавлять еще один класс, их мы не нанимали )))
                            0
                            Вы бросились решать даже не узнав ограничений и других условий

                            Обожаю таких "экзаменаторов", которые сначала не договаривают условия, а потом вменяют в вину, что ты что-то не уточнил.


                            не буду же я полностью все перечислять.

                            А стоило бы.


                            графовую субд использовать было нельзя

                            Есть хоть одна причина этого не делать?


                            простой sql запрос годится только для доставания скелета, но не для всей обвязки

                            Про fetch plan вы не слышали?


                            работал бы он очень медленно для наших требований

                            Требования в студию.


                            я ведь не буду тут весь продукт описывать

                            То есть вы даёте задания, для понимая которых нужно описывать весь продукт?

                              +1
                              Обожаю таких «экзаменаторов», которые сначала не договаривают условия


                              Ишь какой дерзкий )))

                              Я вообще-то тут давал не конкретную задачу которую нужно решать а дал пример, как можно из деревьев сделать что-то менее абстрактное и более приземленное чтобы люди не думали что им дают алгоритмические задачи от балды.

                              Про fetch plan вы не слышали?

                              конечно не слышал )))

                              То есть вы даёте задания, для понимая которых нужно описывать весь продукт?

                              Когда я говорил про невозможность использования графовых баз, я имел ввиду уже требования реального продукта а не ограничения задания. Если бы мне кандидат сказал что для моделирования графов он был взял какой-нибудь neo4j, ну что ж… наверное я бы такому кандидату отказал с занесением в личное дело «любитель ищ пушки по воробьям» )))

                              Шутка ))) Если бы кандидат сказал про neo4j то я бы спросил у него давно ли он смотрел их багтрекер )))
                                –2
                                как можно из деревьев сделать что-то менее абстрактное и более приземленное

                                А получился ещё более оторванный от реальности каталог товаров, хранящийся в оперативке.


                                конечно не слышал )))

                                Тогда почитайте и не говорите глупостей.


                                невозможность использования графовых баз, я имел ввиду уже требования реального продукта

                                Это вам бизнес такие требования ставит? Может он от вас ещё и конкретный кодестайл требует?


                                Если бы кандидат сказал про neo4j

                                Это единственная графовая субд, что вы знаете?

                                  0
                                  Может он от вас ещё и конкретный кодестайл требует?

                                  прикинь, в больших компаниях часто есть кодестайл )))
                                  Это вам бизнес такие требования ставит?

                                  Ага, а еще в больших компаниях часто есть фиксированный стек технологий и нельзя просто так начать писать на .NET в конторе где почти все написано на Java )))
                                    0
                                    Раз вы такой большой знаток «больших компаний», то наверняка знаете, что в них много разных проектов, написанных на разных стеках, в разных стилях. Во многом потому, что технологии выбираются под требования, а не наоборот.
                                      +2
                                      Дядь, я тебе рассказал про то, зачем нужны были деревья на собесах в одной конкретно взятой компании а ты мне тут втираешь какую-то дичь ))) астанавись )))
                          0

                          На узлы дерева надо смотреть как на контроллеры, если мы говорим про архитектуру приложения. В эти узлы могут пробрасываться как список функций, так и датапровайдеры или темплейты. Если система работает асинхронно, то продолжение её работы происходит в подписанном на это асинхронное событие узле. При этом сам узел может иметь свою собственную иерархию. Но коммуникация с помощью событий чревата их потерями. Лучше делать явный проброс нужных компонент и отслеживать последовательность их синхронной обработки. Рассказы про многообразия структур оставьте для тех кто не видит закомерности в рутинных операциях и готов многократно их повторять. Почему бы не заниматься рутинным трудом если он оплачивается? Про балансировки на фронтенде я бы тоже послушал. Вопрос не в том как решить задачу в общем виде, а как решить её технологично. Чтобы решить её технологично нужны фреймворки, которые не дадут или ограничат написание плохокода. Я не пишу резюме. Я даю ссылки на свои коментарии на хабре и смотрю на реакцию и вопросы. Если есть общее видение, то можно и посотрудничать.

                          +4
                          Каким боком физзбазз, обходы дерева, бинарные деревья относятся к архитектуре?
                          Никаким. Найдёте, где я утверждал обратное? Или придумываете ошибочные аргументы, а потом сами же с ними спорите?

                          И если он скажет мне, у меня все было окей и не было проблем, вот тут я пойму, что он не знает о нем ничего, а если расскажет про сложности и проблемы, то будет понятно, что он хотя бы с ним сталкивался.
                          Вы недооцениваете мощь тех, кто умеет врать. Он вполне может пересказывать возмущения своего лида. А сам мог никогда и не задумываться над реальными проблемами.

                          писал код на бумажке — все это не имеет никакого отношения к реальному найму на реальную работу.

                          Видите ли, ваша проблема, что вы мыслите очень… сухо. Для вас код на бумажке — это «ну вот пришел человек, написал код на бумажке, я его проверил и нифига полезного с этого кода не получил».

                          Суть в том, что я не даю написать код на бумажке, а потом проверяю. Представьте, что мы занимаемся с человеком парным программированием на бумажке.

                          Может, это специфика вашей области такая. Подозреваю, что простые CRUD-задачи и не требуют живого захвата от кодинга. Там может подойти и поверхностный разговор, навык программирования не очень важен, важнее количество крудов, которые ты написал. Я написал очень мало и, увы, больше писать не хочу. Даже несмотря на то, что платят больше.

                          И, кстати, я не отрицал общение на тему архитектуры. Просто у меня комплексное собеседование. Я общаюсь и о архитектуре, и код на листочке пишу, и спрашиваю о тех хобби, которые человек описал в резюме, спрашиваю, в какие игры он играет.

                          У нас в геймдеве каждая фича может разительно отличаться друг от друга. Знаете, бывают ситуации когда всё сделал клёво, правильно, но выглядит оно стрёмно. На архитектуру, которую вы придумывали с командой и на которую игра отлично ложилась годами плохо ложится новая фича. Нужен порядок анимаций, который противоречит логике, потому что смотрится он значительно класнее. Ты идешь с командой в планерку, берете маркеры и начинаете рисовать. Вы даже отрываете код и рисуете поверх кода.

                          Видите ли, те зануды, которые придираются к листочку на собеседовании — никогда не будут это делать. Они будут нудить, что все до них — идиоты, что надо переписать архитектуру, что нужен вообще другой фреймворк. Они будут искать виноватых. Они забывают, что они в команде и думают, что они — главные звёздочки. Им плевать, что игра уже несколько лет как запущена и в неё играют тысячи людей прям сейчас. Что это всё отлично работало. А люди, которые пишут на листочке код — идут и ищут решение вместе.

                          Я никогда не считал свой код идеальным. И собеседования у меня тоже не идеальны. Я нанимал ужасных людей и, уверен, пропустил хороших. Но я уверен, что если у человека настолько корона упирается в потолок, что он откажется писать со мной код на листочке, то такой человек не нужен ни в одной команде, в которой я бы хотел работать.
                +7
                Разработчики зачастую пишут похожий код ежедневно.
                Сисадмины и девопсы часто решают разовые задачи по настройке чего-либо, и в силах этого не могут помнить наизусть все косвенные вещи, которые им пришлось применить.

                Поэтому практические задачи с ручкой сильно ограничены, и придираться или не придираться к мелочам в синтаксисе — вопрос на миллион.
                  0
                  Разработчики зачастую пишут похожий код ежедневно.

                  Таких разработчиков называют кодерами.

                    +2
                    Таких разработчиков называют кодерами.

                    Главное что деньги они получают такие же, как и «разработчики» )))
                      0
                      Порой даже бОльшие, что меня поражает. Самый джек-пот — это Angular+Redux+Rx с жёсткими гайдлайнами по выносу чуть ли не каждой функции в отдельный файл. Вот уж где на одну строчку полезного кода — сотня копипасты.
                      +1
                      >> Таких разработчиков называют кодерами.

                      Месье архитект — пишет код раз в месяц? У нас как-то был такой, архитектор ПО (по институтсткой специальности, сразу из института), заявивший что его дело архитектуру рисовать, а не руки пачкать реальным кодом. Чем весьма позабавил и начальство, и коллектив.
                        –1

                        Месье каждый день пишет разный код.

                          0
                          А кодер — один и тот же переписывает, раз за разом?

                          Такое разнообразие возможно только в небольшом проекте. Иначе неизбежно будет специализация.

                          Кодер/разработчик/инженер вообще натянуто. В проекте в одно лицо будет «инженером», в большом проекте «кодером». В большом проекте и главный архитектор будет рисовать почти одно и тоже каждый день.
                            0
                            А кодер — один и тот же переписывает, раз за разом?

                            https://habr.com/post/434864/#comment_19572650


                            Такое разнообразие возможно только в небольшом проекте. Иначе неизбежно будет специализация.

                            Специализация — это свой небольшой проект в общем большом. Так что размер не имеет значения.


                            В большом проекте и главный архитектор будет рисовать почти одно и тоже каждый день.

                            Гнать такого архитектора, он впустую ест хлеб.

                    +2
                    Если говорить о каких-то мелочах на пару-тройку строк, то нормально, но если надо писать какую-то функцию на чёрт знает сколько строк или полноценное решение тестовой задачи, то абсолютно неадекватно. Это говорит о том, что вместо того, чтобы заниматься процессом приёма человека на решение проблем бизнеса, собеседующий просто играет в «я экзаменатор, а ты сдаёшь экзамен».
                      +3
                      Когда я чувствую такой подход «я экзаменатор, а ты сдаёшь экзамен», то я переключаюсь в такой же режим. Я сообщаю «экзаменатору», что хочу работать в сильной команде, поэтому устраиваю ему ответный опрос с требованием решать уже мои задачки. Если отказывается, то я ему говорю, что нам не по пути и мы прощаемся
                      +2
                      Я не автор, но у меня встречный вопрос — а что вы хотите проверить этим? У каждого теста должна быть цель и ожидаемые результаты.

                      В общем случае это похоже на тест либо знаний, если вы просите олимпиадника реализовать известный алгоритм, либо на умение быстро искать решение в сжатые сроки при определённом уровне стресса. Данный тест скорей всего не имеет значение в 95% ситуаций, которые возникнут у кандидата на новом месте работы.
                        +3

                        Базовые знания Computer Science. Может ли человек написать цикл, решить такую задачу как ФизБаз и умеет ли в основы программирования.


                        Моя практика десятков собеседований на сеньйоров в известную компанию, с людьми, которые имеют хорошее резюме показывает, что больше половины серьезно врут в своих резюме и не умеют программировать даже на уровне миддла.


                        Они не могут написать ФизБаз, серьезно

                          +2
                          что больше половины серьезно врут в своих резюме и не умеют программировать даже на уровне миддла.

                          Да, есть такое, подтверждаю! Не скажу за половину, но я видел достаточно людей с 10+ годами опыта которые не могут такое написать.
                            +1
                            Только вчера узнал про ФизБаз :) Решил пофизбаззить.
                            Написал код
                            Здесь подсветка синтаксиса есть
                            BITS 32
                            global _start

                            section .data

                            fizz db "Fizz"
                            fizz_len equ $-fizz

                            buzz db "Buzz"
                            buzz_len equ $-buzz

                            fizzbuzz_len equ $-fizz

                            separator db 0x20
                            newline db 0xa

                            section .text
                            _start:
                            mov eax, 100; natural integer number
                            call fizzbuzz

                            ;exit
                            mov eax, 1
                            xor ebx, ebx
                            int 0x80

                            fizzbuzz:
                            push ebp
                            mov ebp, eax
                            mov esi, 1
                            push 0

                            fb_loop:
                            mov [esp], byte 0
                            mov eax, esi
                            mov ebx, 3
                            xor edx, edx
                            div ebx
                            test edx, edx
                            jnz next_1
                            mov [esp], byte 1

                            mov ecx, fizz
                            mov edx, fizz_len
                            call print_string

                            next_1:

                            mov eax, esi
                            mov ebx, 5
                            xor edx, edx
                            div ebx
                            test edx, edx
                            jnz next_2
                            mov [esp], byte 1

                            mov ecx, buzz
                            mov edx, buzz_len
                            call print_string

                            next_2:

                            mov eax, [esp]
                            test eax, eax
                            jnz next_3

                            mov eax, esi
                            call print_number

                            next_3:

                            mov ecx, separator
                            call print_symbol

                            inc esi
                            cmp esi, ebp
                            jng fb_loop

                            mov ecx, newline
                            call print_symbol

                            pop eax
                            pop ebp
                            ret

                            print_symbol:
                            mov edx, 1 ; length of the string
                            print_string:
                            mov eax, 4 ; system call number (sys_write)
                            mov ebx, 1 ; file descriptor (stdout)
                            int 0x80
                            ret

                            print_number:
                            mov ecx, esp
                            sub esp, 12 ; reserve space for the number string, for base-2 it takes 33 bytes with new line, aligned by 4 bytes it takes 36 bytes.

                            mov edi, 0
                            mov ebx, 10 ; base-10

                            print_loop:
                            xor edx, edx
                            div ebx
                            add dl, '0'
                            dec ecx
                            inc edi
                            mov [ecx],dl
                            test eax, eax
                            jnz print_loop

                            mov edx, edi ; length of the string
                            call print_string

                            add esp, 12 ; release space for the number string
                            ret

                            Можно без деления решить.
                            Странно, что кто-то такое решить не может, ну зато писать резюме умеют.)

                            PS. С новым годом всех!
                              +1
                              Суть fizzbuzz в том, что многие слишком уверены в себе, и написав свой вариант позволяют себе его отправить даже ни разу не запустив на выполнение для проверки.

                              Так собственно и отсеиваются совсем неадекватные.
                                +1
                                Я думал это решается непосредственно на интервью, задачка на пару минут. Или вы о моем коде говорите? Свой запускал, работает.)
                                  +1
                                  Суть fizzbuzz в том, что многие слишком уверены в себе, и написав свой вариант позволяют себе его отправить даже ни разу не запустив на выполнение для проверки.
                                  Неа. Суть в том, что даже её некоторые кандидаты не могут написать
                                0
                                значит вы просто не умеете читать резюме и отсеивать мутных кандидатов
                                  +3
                                  О! Вполне возможно. Рад, что у нас в комментариях есть гуру, который никогда не ошибается и сейчас всех научит, как отделить зёрна от плевел
                                    0
                                    Содержание 90% от всех резюме (спасибо hh.ru за наше счастливое детство):
                                    Иванов Иван Иваныч, столько-то лет, такой-то город, (не) готов к переезду

                                    20хх-20хх — ООО «Вектор», программист. Обязанности: программы программировал.
                                    <n похожих строчек>

                                    Навыки: git, github, программирование, баззворды.

                                    О себе: трудолюбивый, целеустремленный, нацеленный на результат.

                                    Сопроводительное письмо: хочу у вас работать, потому что вы классные.

                                    Чтоб по такому составить хоть сколько-то правдивое и полное мнение о кандидате — нужно быть Вангой 110lvl.
                                      –2
                                      Не надо быть вангой. Когда я отбирал кандидатов, чтобы пригласить на собеседование (.NET), я обращал внимание на 4 вещи:
                                      1. Предыдущее место работы. Мир .NET довольно узок, я примерно представляю где какой уровень разработки
                                      2. Ключевые слова с упоминанием IoC, DDD, TDD, SOLID. Если они есть, то человек, скорее всего, задумывался над проектированием.
                                      3. Сертификаты MS. Если человек их реально сдавал, то, скорее всего, он был мотивирован упорядочить свои знания.
                                      4. Образование. Если человек закончил топовый технические вуз, то вероятность того, что он что-то умеет программировать весьма высока.

                                      Комбинация из этих фильтров позволяла мне беседовать с кандидатами, у которых не было проблем с физбазом.

                                      Вот вашего Ивана Иваныча я бы позвал только если в ключевых словах были нужные + ( топовый вуз или МСовские серты ). Как-то так.
                                        +2
                                        Ключевые слова с упоминанием IoC, DDD, TDD, SOLID. Если они есть, то человек, скорее всего, задумывался над проектированием.

                                        После ваших слов я задумался, а не добавить ли мне это в мой Linkedin профайл. Раньше мне бы и в голову не пришло, что кто-то подобное там выискивает. Т.к. сам я строку с "SOLID, IoC, TDD, BDD" трактовал бы как "на работе я работу работаю". И увидев это в резюме подумал бы, что кандидат любит звучные баззворды и играет в SEO.


                                        А если вам попадается вакансия, где паттерны\подходы\whatever не перечислены, то получается кандидат отфильтровывается "комбинацией фильтров" и его резюме к вам на стол не попадает?

                                          –3
                                          Работу вы работаете с помощью инструментов — IoC, DDD, TDD, SOLID тоже инструменты. В резюме вы перечисляете чем занимались и какие инструменты использовали. На собеседовании вы, в том числе, обсуждаете как выбирали инструменты, как ими реально пользовались, степень владения ими.

                                          Эти признаки для меня имеют разные веса. Известное мне место работы + крутой вуз, вероятно, гарантируют беседу. А только лишь ключевые слова без всего остального — скорее всего нет.

                                          Это вещи которые важны мне. Другим людям, может, алгоритмы важны или доскональное знание языка, например.
                                            0
                                            Крутой вуз имеет настолько большую вероятность хороших умений?
                                              0
                                              Диплом крутого вуза говорит мне, что либо у человека хорошо варит голова, либо он умеет крутиться. Выяснить я смогу во время беседы. Хорошие «умения» не столь важны, как хорошо варящая голова
                                                0
                                                Хоть я с этим тоже не очень согласен, но я хотел указать на другое, что вы отсеете своим фильтром людей, у которых возможно есть «умения» лучше, чем у человека из крутого вуза или с сертификатом.
                                                  –1
                                                  Совершенно точно. Но у меня нет времени искать иголки в сене и вряд ли у кого-то, кто проводит собеседования, оно есть.

                                                  К тому же, у человека без вуза и сертов есть еще опции крутого предыдущего места работы и правильных ключевых слов.
                                                    +2

                                                    Складывается ощущение, что к вам синьоры-помидоры толпами идут, гроздьями сыпятся, лица друг другу в фойе разбивают, что ты такие фильтры ставите. Правда что-ли?

                                                      –1
                                                      В том месте, где я проводил собеседования, были конкурентные условия труда, некоторый бренд, белая рыночная зп и почти не было текучки. Могли себе позволить нанимать неспеша по полгода.

                                                      В текущем месте требования, думаю, еще жестче. Но теперь это не моя работа :)

                                                      В целом, коллективы и там, и тут состояли из выпускников МГУ, МФТИ, МИФИ и Бауманки.
                                                        0
                                                        Когда называют эти 4 названия в одном ряду, у меня закрадывается сомнение, что называет их человек, причастный к ним.
                                                          0

                                                          Причастен к одному из, но право ваше

                                                            0
                                                            Тогда приношу свои извинения, что усомнился. Обычно так пишут кадровики, а участники называют 1 или 2, но не все. Слишком разные они имхо.
                                                              0
                                                              Разные, но работать и думать головой заставляют во всех — именно в этом и конечная ценность
                                                          0
                                                          С ужасом представляю холиворы в коридорах между кадрами из разных альма-матер.
                                                            0

                                                            Через 5-10 лет после выпуска всем пофиг

                                                              0
                                                              Не всем.
                                                                0

                                                                Ну мои соболезнования этим не всем :)

                                                                  +2
                                                                  Не, ну мне в университете хватило не то что срачей «МГУ против Бауманки», но даже «мехмат против ВМК» и даже «механики против математиков».

                                                                  Но вообще, если по теме, я никакой особой корреляции между уровнем программиста и высшим образованием не нашел за годы своего опыта, а анекдотических контрпримеров хватает и в одну, и в другую стороны.

                                                                  Сам из-за своей этой деформации (я мехмат бросил на середине) я никогда в графу образования на собесах не смотрю, ко мне вроде тоже уже не смотрят, благо в резюме есть чего еще почитать, но главный принцип обиженного отечественным высшим — если меня не берут, потому что не подхожу образованием, то и мне вряд ли понравится на таких ребят работать.
                                            0
                                            2. Ключевые слова с упоминанием IoC, DDD, TDD, SOLID. Если они есть, то человек, скорее всего, задумывался над проектированием.

                                            А потом, на собеседовании:
                                            — Что такое SOLID?
                                            — Я не знаю
                                            — Ну у вас в резюме ведь написано
                                            — Все пишут — вот и я написал.

                                            пс. это реальный диалог с собеседования
                                              0
                                              Ну, так первый барьер HR, а они по ключевым словам ищут, вот и получается так.)
                                              PS. SOLID — объемная фигура :))
                                                0
                                                Тогда уж твердая фигура…
                                                +1
                                                Ну, так первый барьер HR, а они по ключевым словам ищут, вот и получается так.)
                                                Ну да, взять этот барьер ложью, чтобы потом облажаться на собеседовании — это гениальное решение.

                                                Мне откровенно непонятно вот что. Человек пишет у себя в резюме такие вещи как SOLID, Design Patterns, TDD. Неужели так сложно почитать и понять, что это? Неужели так сложно выучить 5 примеров разных паттернов? Если уж написал, что знаешь их.

                                                Насколько наплевательское должно быть отношение, чтобы даже не почитать, что там у тебя написано в резюме?

                                                PS. SOLID — объемная фигура :))

                                                Стиль границы в css =)
                                                  +1
                                                  Ну да, взять этот барьер ложью, чтобы потом облажаться на собеседовании — это гениальное решение.
                                                  На хабре читал, что резюме иногда вообще не смотрят,)(т.е. тоже наплевательское отношение) вот на это и расчитывают, либо отболтаться как-нибудь, поразив своими «софт скиллами»,)
                                                  Стиль границы в css =)
                                                  Смазка для ПО, чтобы Rust не досаждал (солидол) :)
                                  0
                                  спасибо за полезную статью.
                                  Кстати у автора есть телеграмм канал: t.me/full_of_hatred
                                    +1
                                    А замечали ли вы корреляцию в зависимости возраста собеседующего?
                                      +1
                                      корреляция чего с чем?
                                      Корреляция это не зависимость.
                                        +1
                                        Зависимость возраста собеседущего (и как следствие, его опыта) от «разумности» самого собеседования, вопросов и задач на нем
                                        0
                                        Скорее нет, чем да, потому что я довольно плох в определении возраста по внешности.
                                        +1
                                        Спасибо за статью.
                                        хотелось бы узнать мысли по поводу следующих пунктов.
                                        — есть ли в смысл в собеседованиях с алго задачами? в случае, если первые этапы такие, а далее уже обсуждение и решение более реальных задач?
                                        — лучше ли проводить в какой-то онлайн доке (кодерпад тот же), или же вайтборд/бумажка?
                                        — есть ли место для онлайн интервью? все этапы онлайн (если релокейт, к примеру) — нормально?
                                        — нужно ли искать максимум и лимит кандидата на собеседовании, или же смотреть четко в границах проекта (и/или технологий)?

                                        На самом деле интересно обсудить тему тех собеседований, так как в принципе в Европе (и постсовке) спрашивают что попало, и процесс часто отличается. За океаном же наоборот — есть стандартизированный подход к интервью, и даже книжки написаны :)
                                          0
                                          есть ли в смысл в собеседованиях с алго задачами? в случае, если первые этапы такие, а далее уже обсуждение и решение более реальных задач?

                                          да, если эти знания нужны в работе. вот у меня на предыдущей работе была целая куча древовидных структур данных, поэтому я просил кандидатов обойти дерево.
                                          лучше ли проводить в какой-то онлайн доке (кодерпад тот же), или же вайтборд/бумажка?

                                          код однозначно в кодерпаде/repl.it (последний добавил многопользовательский режим недавно, так что в кодерпаде нет смысла больше), архитектуру на бумажке
                                          есть ли место для онлайн интервью? все этапы онлайн (если релокейт, к примеру) — нормально?

                                          я там в статье писал что у меня почти все собесы были онлайн ))) смысла в офис ходить щас нет как мне кажется.
                                          нужно ли искать максимум и лимит кандидата на собеседовании, или же смотреть четко в границах проекта (и/или технологий)?

                                          в зависимости от позиции. я бы смотрел на общий уровень и не обращал внимания на незнание каких-то конкретных вещей.

                                          На самом деле интересно обсудить тему тех собеседований

                                          еще две статьи на очереди )))
                                          +3
                                          Унылый интервьюер — подарок свыше. Частенько, работать будете с тем же руководителем, который его напряг делать то от чего он не в восторге. Остается узнать о проекте и если пребывание на интервью было для него меньшим из зол то в случае успеха просите заградительный миллион (ну вы поняли).
                                            +4
                                            «Ваше резюме никто не читает» — как человек, проведший более 100 собеседований, и подходящий к процессу с большой отдачей, могу вам сказать, что это частично оправдано. Многие толковые люди не умеют их составлять, многие бестолковые спецы в них привирают. Образование не коррелирует с тех. грамотностью. Прошлые работодатели не коррелируют тоже (доводилось вам работать с идиотами? а компания в резюме будет одна и та-же). По итогам, оптимальная стратегия — просто сверка ключевых слов, и то, самого высшего уровня. Более реально что-то понять только в беседе — вот там настоящее собеседование.

                                            По опыту, могу выделить только 3 позитивных маркера в резюме:
                                            — Ссылка на свой блог или Github (Github это вообще джекпот, особенно если кандидат пишет тесты);
                                            — Общая структурированность — визуальная и информационная (единообразный шрифт и отступы в параграфах, форматирование подчёркивает структуру и ключевую информацию);
                                            — Краткость (кем бы вы там ни были, резюме должно влезть в 2 страницы). Идеал не про «Нечего больше добавить», а про «Нечего больше выкинуть».
                                              +4
                                              Кто-то говорит, что гитхаб вообще не смотрят.)
                                                +3

                                                Я всегда переходил по всем ссылкам в резюме. Мне с этим человеком работать.


                                                Однажды он в качестве хобби указал участие в группе — я послушал музыку этой группы.

                                                  +1
                                                  Может это от размера компании зависит, когда уделяют внимание деталям, а когда нет?
                                                    +3
                                                    Думаю, что зависит от человека.
                                                  0
                                                  У меня ни разу гитхаб не спросили )))
                                                    +1
                                                    Пародокс. Кому это джекпот, а кому и не надо вовсе.
                                                      +1

                                                      На одной из работ мне сказали что так здорово что у меня есть гитхаб и статья на хабре, а потом оказалось что ни гитхаб ни статью никто не читал :)
                                                      Впрочем, оно же сработало!

                                                        +1
                                                        Наверное все-таки кто-то читал и смотрел. Только это был один человек, который вам просто не говорил об этом.)
                                                  +1

                                                  Я провел тоже больше сотни. Иногда было по интервью каждый день, в течение двух недель.
                                                  Всегда читаю резюме.


                                                  Если файнал интервью (у нас их два), то подготовка к нему не меньше 30 минут, а желательно час.

                                                  +1

                                                  Ок, я как бы из параллельной реальности (embedded и вообще hardware). Но позволю не согласиться с двумя важными пунктами:


                                                  • нам очень важно с кем работать, поэтому большое значение уделяет team fit,
                                                  • у нас всегда есть план по поводу того чем будет заниматься человек,
                                                  • босс всегда присутствует, и даже босс босса если кандидат хороший.
                                                    Большую проблему представляет то что нам нужен типа "exceptional talent". Поэтому если кандидату не повезло ответить на какой-то глупый вопрос, то начинаются трудности, потому что на обсуждении возникают реплики "оу, он не знает X или Y, как же нам его брать"
                                                    0
                                                    Ок, я как бы из параллельной реальности (embedded и вообще hardware). Но позволю не согласиться с двумя важными пунктами

                                                    Конечно есть софтверные компании, которые тоже это делают, просто они мне не попались — выборка маленькая.

                                                    Ну а ваша компания скорее всего тоже исключение, вот походите в десяток других хардверных контор и расскажите нам, там так же как у вас, или «как везде».
                                                    +1
                                                    А как автор относится к тому, что собеседующий на том конце Скайпа отключил свою камеру и общается только голосом (реальный случай)? Тоже отключитть свою камеру, послать его лесом, етс?
                                                      0
                                                      А как автор относится к тому, что собеседующий на том конце Скайпа отключил свою камеру и общается только голосом (реальный случай)?

                                                      Нормально, может человеку некомфортно. Странно только что он это сделал без предупреждения и посреди разговора?
                                                      Тоже отключитть свою камеру, послать его лесом, етс?

                                                      Я обычно перед собеседованием уточнял нужна камера или нет. Так и вам советую поступать.
                                                        +1
                                                        Странно только что он это сделал без предупреждения и посреди разговора?

                                                        Сразу начал разговор с выключенной камерой.
                                                          0
                                                          Тогда просто спросить нужна ли камера и все :) Это же ему виднее. HR обычно требуют камеру, тогда как разработчики — нет.
                                                        +2
                                                        Я бы просто отключил камеру без всяких уточнений — очевидно он просто находится в месте, где не очень удобно с видео, тч вы вполне вправе сделать то же самое.
                                                          0
                                                          Если интернет плохой — то отключение камеры делает хотя бы звук нормальным.
                                                          Но лучше объяснить причину, конечно.
                                                          +1

                                                          Я имел ввиду, что с выключенной камерой начал разговор руководитель из компании, т. е. будущий начальник, а не тот, кто устраивается на работу.

                                                            +1
                                                            Лично я вижу некоторое противоречие в утверждении «вы ни кому не нужны» и рекомендации выполнять тестовое задание. Скорее всего его будут смотреть так же как и резюме. Рекомендую не выполнять тестовые задания в случае позиционирования как сеньера.

                                                            С тем, что по описанию вакансии невозможно понять что-то о конторе не соглашусь. На самом деле по тому как составлено описание уже можно рассмотреть уровень конторы и наличие адекватных специалистов в ней. А так же на сколько эти специалисты заинтересованы в вакансии.
                                                              +1
                                                              «Сделайте проект с нуля (возможно, используя конкретную технологию) и выложите его на GitHub» — как по мне, наихудший вариант.

                                                              Как по мне — это оптимальный вариант узнать способности кандидата на позицию разработчика. В нашей компании так и поступаем. Когда решение задании готово, один из senior разработчиков проверяет работу кандидата.
                                                                0
                                                                Как по мне — это оптимальный вариант узнать способности кандидата на позицию разработчика.

                                                                Оптимальный вариант это взять его на день поработать в паре над какими-то багами. Задание человек может сделать не сам. Кроме того, объемные задания сокращают вам воронку.
                                                                  +1
                                                                  Наверное, такое возможно в небольшой компании, но в средних и больших компаниях непросто взять человека и допустить его к закрытым исходникам.

                                                                  Что плохого в том, что кандидат дома, в спокойной обстановке, потратит пару часов своего времени на программирование задания?
                                                                    0
                                                                    взять человека и допустить его к закрытым исходникам

                                                                    зачем допускать, парное программирование же
                                                                      +1
                                                                      Для парного программирования оба должны быть хорошо знакомы с внутренними механизмами разрабатыемой системы. Иначе один из них будет выглядеть дураком, который на самом деле таким может и не является. А просвещать человека во внутренние процессы той или иной системы, который может оказаться просто проходимцем — не очень разумно.
                                                                        0
                                                                        Для парного программирования оба должны быть хорошо знакомы с внутренними механизмами разрабатыемой системы.

                                                                        Так в том то и дело что именно в такой задаче очень легко понять человек вообще сможет работать у вас в конторе или нет ) Не обязательно делать большую штуку, достаточно мелкого бага.
                                                                        Некоторые западные компании такой подход практикуют и проповедуют, например, Basecamp.
                                                                +1
                                                                --Ваше резюме никто не читает

                                                                Категорически несогласен — на всех очных собеседованиях на руках были мои резюме из HR, а в Амазоне тимлид даже спросил почему я не принес полное резюме. Обычно выкладываю за последние 10 лет только (от масшатбов иcполненых проектов в СССР обычно у людей челюсть отвисает) — был неготов к такому повороту.

                                                                --Вы не будете разговаривать со своим будущим боссом или тимлидом

                                                                Категорически несогласен — И в маленьких и больших компаниях обязательна встреча и с тем и с другим — и это не менялось за последние 20 лет собеседований.
                                                                  0
                                                                  Категорически несогласен

                                                                  отлично! можете тоже пройти полтора десятка собесов и написать по этому поводу опровержение )))
                                                                  И в маленьких и больших компаниях обязательна встреча и с тем и с другим

                                                                  формально да, на практике вас вряд ли будет собеседовать ваш будущий босс.
                                                                  0
                                                                  Вы не будете разговаривать со своим будущим боссом или тимлидом

                                                                  Я конечно не знаю, как дела обстоят в России, но за весь мой рекрутерский опыт в Канаде такого не было и быть не могло. Другое дело, что первое интервью может быть с технарями коллегами, если непосредственный начальник не силен в технических вопросах и не может оценить навыки кандидата. Но в конце концов интервью с менеджером будет и он\она будет сам принимать решение.

                                                                  Бывают еще компании с матричной структурой (чаще всего консалтинговые), это когда всех нанятых гуртом записывают под одного менеджера, который их никогда и не видит, а работают эти сотрудники непосредственно на проектах, для которых их наняли. Ну тогда конечно с формальным менеджером, на которого их записали, они не встречаются, т.к. его мнение никому не нужно. Но с лидом или менеджером проекта, на котором они будут работать, они обязательно интервьюируются.
                                                                    0
                                                                    в России

                                                                    В Украине ваще-т, автор оттудаво. И там в основном аутсорс-аутстаф, в России все-таки поболее продуктовых контор.
                                                                    0
                                                                    Важный совет касательно правильного общения в телеконференциях: заведите привычку не говорить и не печатать на клавиатуре, когда говорит другой человек, и разговаривать по гарнитуре, а не, например, через внешний микрофон ноутбука и внешние колонки.

                                                                    Очень дельный совет. Гарнитура обязательна, ну или по крайней мере говорить в телефон а не на спикере. И ждать окончания фразы, чтобы свою вставить.

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое