Comments 62
Я обычно во главу угла ставлю вопрос по опыту предыдущему. Обычно, если человек значет, что и зачем он делал, и отвечает не "ну менеджмент сказал, я сделал", то я уже верю, что с задачами он справится)
Если остается время, могу погонять и по рантайму, и по другим языкам, но обычно оговариваю, что это не относится к рабочим задачам, а скорее понять глубину и ширину кругозора в профессии.
У меня не всегда получается из опыта понять, какая реально квалификация. Точнее получается понять адекватность, примерный опыт и масштаб решаемых задач. А навык "писать читаемый код" или "ненаоверинжинирить", к сожалению, нет
Поэтому я стараюсь идти через кейсы (в зависимости от грейда): прошу решить какую-то реальную задачу \ проблему \ отрефакторить кусок (около)боевого кода на собеседовании. А там можно углубляться до бесконечности
Видно и как человек взаимодействует с требованиями \ людьми. И как пишет production-ready код. И насколько хватает кругозора в своем стеке. Видно насмотренность и навык срезать углы для экономии ресурсов (что тоже важно)
Но и уходит у меня в среднем ~2 часа (два собеса на человека, если на первом не было понятно, что нет метча)
если человек значет, что и зачем он делал, и отвечает не "ну менеджмент сказал, я сделал"
Я тот человек, который делает, как сказали. Иногда я не знаю, зачем заказчику это надо, да и менеджер может не знать. Просто, сказали делать — я делаю. Иногда просят странные или сложные вещи. Если "сказали — сделал", значит человек справится с тем, что ему скажут. А если начнёт рассуждать "им это на самом деле не нужно", хотя он сам не в курсе, чем в данный момент занимается бизнес, то может даже и не сделать. В конце концов, какая разница, зачем им это, если они платят деньги? Даже если я сделаю, а им это не пригодится, мне с того какая печаль? Моё дело — за квартиру заплатить, еды купить.
Если что, никогда не претендовал на senior-должность. 10 лет как "чернорабочий", только справляюсь, может быть, быстрее, а может быть и нет. Не с кем сравнивать.
Синьор для позиции Y должен дружить с разными подходами к кэшированию, быть в состоянии настроить шардирование или оптимизировать реплику MySQL на чтение. Но без разницы, если не слышал про бинарное дерево и чем отличается LinkedHashMap от TreeHashMap.
До сих пор такой подход для меня выглядит странным. А если сеньор знает, например, не MySQL а PostgreSQL? Или мидл знает фреймфорк Б вместо А?
Так собес идет на конкретную позицию, где нужны конкретные знания. Это нормально. Хотя, как по мне, еслм человек что-то не знает, но он способен это изучить за пару дней, ну ладно, за неделю, то он уже подходит. Все знать в принципе невозможно, важнее то, насколько человек умеет быстро и качественно погружаться в тему, а не просто набор скилов.
А если через 3 месяца выяснится, что вместо/вместе с MySQL нужна монга/кассандра/etc., начинать искать нового сеньёра?
Я об этом, собственно и сказал, умение быстро и качественно усваивать новую информацию намного важнее. Если человек может за разумный срок разобраться с какой-то сложной темой, то он хороший и ценный специалист. Все равно знать абсолютно все невозможно в принципе, да и не нужно это.
умение быстро и качественно усваивать новую информацию намного важнее
А вы это говорите с позиции того, кто принимает решение о найме, или это мнение того, кого нанимают?
Я очень часто вижу такое в комментариях и постах, но почти никогда не сталкивался при поиске работы. Только один раз, на нынешнем месте, и это скорее исключение, обычно без совпадения по конкретным скиллам тебя отфильтруют еще на стадии резюме.
Оно, в принципе, и понятно - как это умение доказать? Ну и такой разобравшийся все равно скорее всего проиграет тому, кто в теме уже не один год.
С позиции нанимаемого.
У меня было несколько случаев, когда меня нанимали на работу с моими околонулевыми знаниями по требуемой теме, и я вполне успешно все осваивал и работал.
Бывает что "разобравшихся" просто дефицит на рынке труда, и нанимают тех кто разберется в процессе. А выигрывает тот кто в теме только на начальном этапе, чаще всего нагнать не так уж сложно, мало есть тем, которые прямо вот реально надо учить многие годы и хватает несколько месяцев что-бы сравняться с теми кто годами уже в теме.
ЗЫ разумеется, несколько месяцев при условии уже имеющегося бекграунда, когда человек не совсем уж нулевой специалист.
Зависит от конкретной позиции
Если нужен синьор и стек +- сходится, но работал с MySQL, а не PostgreSQL — это не проблема. Разумеется, при условии, что скилл SQL проверен и с ним всё ок. Ну и для проекта некритично в какой-то специфической фичей иметь набиты шишки (типа PostGIS)
Для примера с миддлами и фреймворками — уже вопрос. Если брать ту же Java, там фреймворк - это отдельный мир и от миддла ожидается хорошее знание своего фреймворка. На NodeJS \ Go - не принципиально, фреймворки +- одинаковые (не считая NestJS) и за пару дней разница учится
Я очень удивился, что мне не задавали вопросы про хардкорную техничку, которая не используется в работе.
По моему мнению довольно глупый подход. Ну если компания крудошлеперов нанимает то да. В противном случае, надеяться что вам попадется тот самый разраб маминой подруги который и конкретно ваш стэк знает хорошо и вообще умный и красавчик - глупо. Намного умнее брать как раз бодрых и опытных разрабов с инженерным складом ума и хорошей фундаментальной подготовкой и опытом. Разобраться в конкретном стеке хорошему разработчику не так сложно а вот человеку который просто подошел под конкретные нужды чему-то быстро потом научиться уже не так просто.
нельзя давать то, что сам не понимаешь или не встречал в работе. Например, мне были нужны алгоритмы только 1 раз в жизни под специфический проект с трейдингом.
Если даю алгоритмы (изредка это действительно нужно
Забавно. Вы пишете что нельзя то что встречал в работе и что алгоритмы встречали только раз. Но дальше пишете что алгоритмы всё-таки даете. Значит всетаки можно?
они всегда разобраны с моей стороны, я знаю какие решения даже в теории возможны и в любой момент я готов подсказать / обсудить нюансы.
И опять таки. Вот научились Вы решать хорошо алгоритмы на тему связанных списков условно и даете всем их и судите о умении в алгоритмов по тому что сами умеете а вдруг ваш собеседник свои вариации октоберевьев писал и ему нафиг не нужны были Ваши связанные списки. Разве это правильный подход?
пишете что алгоритмы всё-таки даете
Вот научились Вы решать хорошо алгоритмы на тему связанных списков условно и даете всем их и судите о умении в алгоритмов
Я как раз говорю, что по алгоритмам судить не нужно и проверять только в специфических кейсах. У меня как раз был специфический кейс с трейдингом, где алгоритмы действительно было нужно знать. Причём требовался разработчик, который с этим дружит сильнее, чем я. И раз проект дал такие требования, я со своей стороны подготовился к проверке кандидатов на соответствие этому требованию.
Это как раз единственный проект, где я проверял алгоритмы и они были реально нужны.
В остальных случаях — так делать не нужно. Алгоритмы не особо влияют на навык решать задачи бизнеса или писать чистый код :)
Хотя уверен, что существуют проекты, где нужно хорошо разбираться в связных списках, устройстве разных маппов и т.д. Кстати, на проектах с многопточкой я проверял, что человек что-то слышал о thread safety. Обычно этого более, чем хватало для решения наших задач
Правило 8. Не только ты собеседуешь, но и кандидат - тебя. Поменьше пафоса, не надо думать что ты как интервьюер в особом "привилегированном" положении.
Было бы побольше таких собеседований в таком ключе - я бы не плевался от каждого из них и пробовал бы дальше искать работу даже на нынешнем дохлом рынке.
Мне не понятно — что там можно спрашивать о работе карты хэшей? Обычный двоично упорядоченный или связный список ключей из хешей контента, хранящегося в ассоциированных контейнерах. Что же ещё?
Людям сложно понять что такое хэш, каждый второй раз слышу о существовании хэширования без коллизий или ещё какие-то легенды о том как реализовать хэш для своего объекта
Людям сложно понять что такое хэш
Результат выполнения необратимой функции от содержимого. В качестве примера такой функции можно привести детерминанту матрицы, которая есть в программе средней общеобразовательной школы.
Результат выполнения необратимой функции от содержимого
Односторонняя функция для хэша вообще говоря необязательна.
Она скорее подразумевается неявно, потому что задача хеша — превратить ввод произвольной длины в вывод фиксированной, воспроизводимо. И если ввод не помещается в вывод, то математику не обманешь, и не влезшие биты информации придется выкинуть
Односторонняя функция для хэша вообще говоря необязательна.
В противном случае, это была бы не хэш-функция, а функция сжатия, скремблирования или шифрования с возможностью восстановления исходного аргумента из результата функции.
Мне кажется вы путаете односторонние функции с неинъективными, что не одно и то же. Из значений односторонней функции вы не можете восстановить аргументы никогда в идеале. К хэш-функции такого требования не предъявляется.
Да просто определения в вики почитайте.
Из значений односторонней функции вы не можете восстановить аргументы никогда в идеале. К хэш-функции такого требования не предъявляется.
Вы ошибаетесь. К хэш-функциям, в том числе, предъявляется требование невосстановимости аргумента функции. В противном случае хеш-функции нельзя было бы использовать по их прямому предназначению — для проверки криптографических операций, таких как сравнение переданного и сохранённого хэшированных паролей или проверки цифровых подписей.
противном случае хеш-функции нельзя было бы использовать по их прямому предназначению — для проверки криптографических операций
По-моему, вы опять путаете, в этот раз просто хэш-функцию с криптографически стойким хэшем. Это отдельный подкласс, и вот для него действительно необходим максимально затруднённый поиск прообраза.
Это спор об определениях, и пока они не на вашей стороне – поэтому, простите, на этом всё.
https://ru.wikipedia.org/wiki/Криптографическая_хеш-функция
Результат выполнения необратимой функции от содержимого.
Ну нет же. Особенность хеш-функции это то что она фиксирует область допустимых значений результата функции не фиксируя область аргумента. Все остальное вытекает из этого.
Из-за этого и обязательные коллизии(принцип Дирихле) и невозможность существования обратной функции просто по определению функции - нельзя одному аргументу ставить в соответствие два результата(если не обобщать до многозначных функций).
В качестве примера такой функции можно привести детерминанту матрицы, которая есть в программе средней общеобразовательной школы.
Определители матриц не проходят в программе средней общеобразовательной школы. Это первый курс университета, линейная алгебра.
И он не является примером хеш-функции потому что множество всех определителей бесконечно. Так же как и не является хеш-функцией
hash(to_hash) => rand() * to_hash
Если честно, прочитал ваше определение и ничего не понял. Пришлось смотреть в википедии хеш-функцию, чтобы догадаться, что значит "фиксирует область" - видимо, вы подразумевали конечность множества. Тогда всё понятно становится.
видимо, вы подразумевали конечность множества
Ну почти. Не просто конечность, если мы будем возвращать 'a', 'abcd', '100' для разных результатов это тоже ведь конечное множество, а скорее то что все результаты должны быть фиксированной длинны.
Формализовать это и не скатиться в "возвращает битовую строку фиксированной длинны" я очевидно не осилил и получился вот такой кракозябр.
Особенность хеш-функции это то что она фиксирует область допустимых значений
Эта "особенность" - свойство не только хэш-функций. В блоке E-EDID байт контрольной суммы 128-байтного фрагмента имеет значение, являющееся остатком от целочисленного деления суммы всех байт фрагмента на 256, тем самым определяя область значения от 0 до 255, но это значение не является хэшем, а потому это не "особенность". Особенностью хэш-функции — одним из основных её свойств является равномерность распределения её значений при внесении минимальных изменений в аргумент.
почему это не является? Является. Хорошая ли это хеш-функция? Не очень.
Потому что основное требование, предъявляемое к хэш-функции, а именно равномерность распределения её значений, не соблюдено. Более того, этот байт в E-EDID предназначен для облегчённой проверки корректности передачи данных, а не для условно уникального представления содержимого блока данных в системе. Другое предназначение.
Контрольная сумма тоже своего рода хеш-функция
Потому что основное требование, предъявляемое к хэш-функции, а именно равномерность распределения её значений, не соблюдено
Потому что такого требования к определению хеш-функции нет. Единственное требование - конечность множества результата функции в виду того что он должен быть представлен фиксированной битовой строкой. return 42 это вполне себе хеш-функция.
Равномерность распределения это возможное требование к выбору хеш-функции для некого практического использования но даже если она этому условию не удовлетворяет то хеш-функцией она от этого быть не перестанет.
Что же ещё?
Вообще-то реализаций хеш-таблиц много, и у каждой свои плюсы и минусы. Поиски оптимальных алгоритмов хеширования и поиска ячейки идут до сих пор.
Как-то, несколько лет назад, я присутствовал на одной конференции от одной известной IT компании в РФ, которая заходила к нам в город с открытием филиала, и от их регионального управленца, знающего "множество языков программирования", услышал за 5 минут две фразы-
первая - "Сейчас решают софт. скилы, если придут два кандидата у одного будут харды хорошие но плохие софты, а у второго наоборот, то возьмем второго."
вторая - "Не ну если к нам придет вчерашний таксист, который прошел курсы и что-то там для себя поделал,с хорошими софтами, но без опыта и с так себе хардами, мы его конечно вряд-ли возьмем". Кстати по итогу команду для этого филиала набрали всех с опытом , даже джунов с опытом только брали.
Все любят говорить про то как "важен человек - опыт это наживное","главное софт скилы , харды дело наживное" , но как дело доходит до найма, все эти громкие заявления уходят в небытие, ну или до следующей конференции.
Тут важно не обобщать, т.к. софт скиллы - понятие абстрактное
Условно коммуникабельность или навык расположить всех к себе - да как бы пофиг. Таксисту важнее
А вот навык аргументировать "почему нужно сделать так, как говорю я и это сэкономить 70% времени" или заранее предупреждать о проблемах / срывах сроков, предлагая альтернативные пути решения - это уже очень желательные скиллы для Senior+ позиций
По пунктам 6-7 могу сказать что фидбек надо тоже уметь давать, причем так чтобы не выстрелить себе в ногу. Можно словить негативный PR если собеседуемый пойдет по профильным чатам делиться опытом.
Я однажды, после двух техсобесов, получил отказ со словами "ты отличный разраб, видя твой код прямо сразу можно брать без собеседования. Но на сисдизайне некоторые твои решения были нестандартными и тимлид боится брать на себя риски по найму тебя". Причем в чем конкретно заключалась нестандартность решений сообщать уже не стали.
С моей стороны, из-за недостатка конкретной информации, мысли о произошедшем варьировались от "у ребят все совсем плохо с процессами если они боятся что в разработку уйдет неподходящее решение" до "тимлид что-то себе в голове придумал и решил что я буду конфликтным сотрудником или не подстроюсь под существующие процессы и решения". Но все знакомые разработчики с кем я говорил сошлись на мнении что тимлид странный и наверное это даже к лучшему что они решили не продолжать разговор.
С другой стороны в райффайзене, к примеру, мне предоставили исчерпывающую информацию что им не понравилось и какие есть рекомендации примерно как в скриншоте в посте. Вот за такое я был благодарен.
А как вы за пару часов проверяете такое качество как "ответственность"?
Косвенно через общение про предыдущий опыт и через тон, как человек подходит к решению задач. Но глобально - это не задача собеседования, а испытательного срока.
Это и за 10 мин проверяется. Когда человек рассказывает про прошлый опыт в пассивном залоге - он безответственный. Когда рефлексирует по поводу собственной роли, оценивает свои действия и их последствия - скорее всего ответственный
В целом да, на собесах много неадеквата, и здорово что тебе попался тот кто проводил собеседование предварительно подумав над тем как его проводить. Это хороший пример!
Я считаю, что если наниматель не может на любой вопрос из интервью рассказать, зачем он его всё-таки задал, то этого вопроса в интервью быть не должно. И всякие "ну все так делают, в интернете пишут, в гугле тоже так" не катят, вопрос должен быть осмыслен.
В то же время, ты пишешь: "мне не задавали вопросы про хардкорную техничку, которая не используется в работе. ... Проверялись реально те навыки, которые у меня были и которые были бы полезны проекту"
При этом, на фидбеке тебе пишут что ты должен вызубрить TLS, как устроен TCP, якобы потому что "senior должен это знать", а также выучить "Window functions" и CTE так как "это полезные штуки".
Не потому что используется, а так, потому что наниматель решил что сеньор должен хранить в голове всю эту чепуху. Косяк-с.
Чем это отличается от вопросов про "уровни изоляции транзакций"?
P.S. Вакансию очень круто написали, респект.
Как раз в фидбеке нет "вызубить", а предложение "где ещё можно расширить свои знания". На вакансию-то меня позвали
Причём тут я с фидбеком согласен, в шифровании \ криптографии я пару раз в жизни решал свои задачи хуже, чем мог бы, из-за непонимания даже базовых вещей
Про CTE вообще я конкретно на собесе не вспомнил и не применил к конкретному кейсу. Сейчас я такие подзапросы использую стабильно пару раз в неделю, это очень полезная штука
Я тоже провел больше 100 собеседований за последние пару лет, и пришел к следующим выводам, особенно касающиеся стороны найма.
Для позиций начиная с middle не обязателен жёсткий тест на хард скиллы. Он может быть опционально представлен в виде отдельного этапа, но точно не должен играть ключевую роль. Достаточно просто взять задачу из вашего проекта и полтора часа в произвольной форме позаниматься парным проектированием вместе с кандидатом. По тому решению, которые выбрали вы, он сможет оценить ваши компетенции и подходы к работе. По тем вариантам, которые предлагает кандидат, сразу станет понятно, с чем он работал, о чем знает хорошо, о чем слышал. Если есть сомнения, что кандидат приукрашивает опыт - необходимо просто задать какой-то уточняющий вопрос, требующий знаний по теме. Можно начать с вопросов по софт скилл части , например "приходит к Вам бизнес и говорит, хочу такую-то фичу за 2 недели" (максимально приближено к тому, как происходит в компании), Ваши действия? Вопросы могут быть по инженерной части - какой бы язык ты выбрал, какой фреймворк, какую базу, как бы разрабатывал, как тестировал, как разворачивал, как мониторить. И соответственно это все переплетается - умеет ли кандидат адаптироваться и с точки зрения софт скиллов (вычленить самое важное, грамотно оценить и донести бизнесу риски) и с точки зрения хардов (выбрать решение позволяющее быстро выйти на рынок с четким пониманием компромиссов в долгосрочной перспективе).
Важно быть гибким. Не зацикливаться на собственных решениях. Да, у вас уже может быть ваше собственное решение этой задачи, но оно должно служить просто ориентиром для направления диалога. Нужно внимательно следить за ходом мысли кандидата, возможно он предлагает хорошее альтернативное решение (не только техническое, но и бизнесовое), а вам как раз не хватает свежего взгляда в команде.
Надо просто признать, что не существует формулы успешного найма; невозможно спроектировать процесс так, чтобы он стабильно выдавал максимально подходящих кандидатов. Нужно уметь вовремя остановится на удовлетворительном результате.
Прособеседовал примерно 30 кандидатов, не могу найти действенной стратегии. Поэтому попробую покритиковать.
Достаточно просто взять задачу из вашего проекта и полтора часа в произвольной форме позаниматься парным проектированием вместе с кандидатом.
Хорошо когда можно только на тех часть потратить столько усилий и времени.
Минусы - под стрессом собеседования люди глупее и поверхностнее чем они есть на самом деле. Коме того, в реальной жизни никто не проектирует в подобных условиях и полтора часа слишком мало. В действительности на задачу которую нужно проектировать уходит минимум спринт. Поэтому если кандидату только на осознание задачи и изучение кода надо два часа, это вообще не проблема.
И того - преимущество будет отдано быстрому кандидату, который хорош в рилтайме и под стрессом но не обязательно самому толковому.
Можно начать с вопросов по софт скилл части , например "приходит к Вам бизнес и говорит, хочу такую-то фичу за 2 недели" (максимально приближено к тому, как происходит в компании), Ваши действия?
И соответственно это все переплетается - умеет ли кандидат адаптироваться и с точки зрения софт скиллов (вычленить самое важное, грамотно оценить и донести бизнесу риски) и с точки зрения хардов (выбрать решение позволяющее быстро выйти на рынок с четким пониманием компромиссов в долгосрочной перспективе).
Так можно проверить, что кандидат работает в точности с таким бизнесом как ваш. Поясню. Кандидат мог работать над монстром в 10 млн строк кода, который пишется 15 лет. Кандидат мог работать с гос-заказчиком где все непонятно, и сложная политика (включая откаты). Кандидат мог работать в области моделирования, автоматизации, делать инновационный высоко-интеллектуальный продукт. Кандидат мог писать продукт в стартапе, который пишется с оглядкой на одного первого заказчика с расчетом сделать его нишевым. Во всех этих случаях кандидат или не имеет связи с бизнесом (для этого есть PM и аналитики) или подобные требования бизнеса вообще воспринимаются как нечто опциональное, как информацию а не обязательный повод к действиям.
Вы по умолчанию предполагаете, что кандидат работал на рынке приложений, которые не сложные, типовые, пишутся быстро с нуля под требования конкретного заказчика. Но по моему опыту это даже не 10% рынка. Я за 30 лет не работал ни в одном подобном проекте.
Надо просто признать, что не существует формулы успешного найма; невозможно спроектировать процесс так, чтобы он стабильно выдавал максимально подходящих кандидатов. Нужно уметь вовремя остановится на удовлетворительном результате.
Вот здесь не поспоришь.
В итоге у меня пока получается только старая унылая схема: задаем технические вопросы и если это джуниор, проверяем что умеет писать код, а если мидл и выше, то ориентируемся на рассказы об опыте. А в проверке софоскилов полагаемся на мнение менеджера и HR.
Расчет здесь такой, что кандидат ходил по собесам и знает примерно какие вопросы задают на собеседованиях. Поэтому, знать ответы на них для сильного специалиста вообще не проблема - поготовился неделю и все ответил. Кроме того, часть вопросов он может знать потому что сталкивался ежедневно.
Минус здесь тот, что можно нарваться на кандидата который выучил весь материал, но не имеет реального успешного опыта программирования или способностей к программированию. Хотя обычно по тому как человек отвечает чувствуется - это заученные ответы или собственный опыт и глубокое понимание.
Я вообще пришел к выводу, что задавать типичные вопросы - это хорошо.
Во-первых, если человек не может ответить на то что на каждом заборе написано - это очень подозрительно. Но таких много. Можно уточнить что-то смежное чтобы развеять сомнения.
Во-вторых, для человека хоть и скучно, но комфортно отвечать на такие вопросы, он будет меньше стрессовать если всё началось предсказуемо. Дальше исходя из его ответов можно раскрутивать маховик в глубину и разбираться он просто вызубрил или реально понимает. В конце концов попросить порассуждать.
В-третьих, даже на типичные вопросы в интернете много заблуждений и сразу видно как далеко человек копал
Коме того, в реальной жизни никто не проектирует в подобных условиях и полтора часа слишком мало.
Например в моей, я надеюсь достаточно реальной жизни, именно так и проектируют. Если вы чувствуете, что полтора часа слишком мало и вы не уверены - проявите гибкость, предложите кандидату еще одну сессию (если конечно у вас уже нет нескольких кандидатов, в которых вы персонально более уверены, тут уже се ля ви).
Вы по умолчанию предполагаете, что кандидат работал на рынке приложений, которые не сложные, типовые, пишутся быстро с нуля под требования конкретного заказчика.
Я такого не предполагал :) Я вообще за то, чобы меньше предполагать.
Кандидат мог писать продукт в стартапе, который пишется с оглядкой на одного первого заказчика с расчетом сделать его нишевым.
Если кандидат не упомянул это в резюме или на этапе представления, то необходимо об этом необходимо спросить, с чем работал, в чем специфика, ценность бизнеса компании, в которой работал. Как оценивает свой вклад (в зависимости от позиции). Какие самые сложные задачи решал за последние полгода-год. Позадавать вопросы, попросить продемонстрировать концептуальное решение (если нет NDA), попросить проанализировать решение и какие были альтернативы (в зависимости от позиции). Потом уже предлагаете перейти к этапу совместного проектирования. Не хватило времени, но чувствуете, что кандидат перспективный - предложите ему дополнительную сессию.
В итоге у меня пока получается только старая унылая схема: задаем технические вопросы и если это джуниор, проверяем что умеет писать код, а если мидл и выше, то ориентируемся на рассказы об опыте.
Безусловно, можно и чаще всего нужно добавить тест технинических навыков как отдельный этап. В идеале передать эту задачу на аутсорс, чтобы специалисты подготовили и поддерживали актуальный и разноплановый набор тестов и практических задач по необходимым технологиям для вашей позиции, а также проводили проверку знаний. Затем ваша команда сможет проскринить ответы кандидата, проанализировать критичны ли какие-то пробелы для вас и так далее. Однако стоит помнить, что фактор чисто кодирования и технологического интервью не должен быть решающим. И такого рода тесты кандидат в идеале должен проходить без подготовки, как есть, так как он должен понимать, что этот этап хоть и является важным, но не является определяющим, и можно будет проявить себя на следующем этапе.
В общем, что посеешь, то и пожнешь. Если настроен жесткий процесс фильтрации кандидатов по определенному алгоритму, то в итоге будут получены люди, которые просто тренируются прохождению этого алгоритма, а на деле могут оказаться посредственными сотрудниками, из которых 50% могут быть уволены без однозначно негативных последствий для бизнеса. Если же процесс найма будет более гибким и индивидуальным, то, хотя это потребует больше ресурсов и времени, возрастут шансы найти действительно качественного кандидата с реальным импактом.
P.S. Некоторое время назад я проходил собеседование в Т-Банк на позицию ведущего инженера. На этапе проектирования системы я предложил альтернативное бизнес-решение и соответствующее техническое решение, которое значительно снижало время, сложность и стоимость разработки и поддержки (в случае с стораджем — в 1000 раз). Однако интервьюер был в каком-то роботоподобном трансе и настаивал на возвращении к исходному предлагаемому подходу. В итоге я принял предложение от другой компании, где как раз проходило гибкое интервью в формате диалога. Полет нормальный.
С корпорациями уже не работает индивидуальный подход (за исключением редких команд), когда разработчиков нужно нанимать сотнями и тысячами. Тут уже в силу вступает к стремлению "среднему адекватному значению"
Когда проверяются и +- универсальные навыки, и терпеливость кандидата, и подходящий склад ума
Для такой задачи 3-5+ раундов собеседований, скорее всего, в самый раз (не зря же так делают все топовые компании)
С одной стороны, единичные бриллианты отлетают. С другой стороны, есть в среднем по палате нормальные разработчики, каждый из которых выполняет функцию своего винтика
Например в моей, я надеюсь достаточно реальной жизни, именно так и проектируют.
Вот, получается, всю жизнь проработав программистом я программирования и не видел. Потому что у меня нет даже предположений о чем вы говорите. Соответственно, я подвергаю ненужным страданиям много людей которых мне дают собеседовать, не касаясь самой ценной части их опыта.
Вот мой типичный опыт, чтобы было понятно о чем речь:
1. Монолит на десяток миллиона строк кода для автоматизации управления и моделирования. Моя задача (как программиста, лида и PM) - добавить в него модуль, позволяющий продукту занять новую нишу в отрасли. По архитектуре этот модуь тривиален - просто десктопное приложение с несколькими пользователями. Сложности: алгоритмы моделирования и управления в связвке с концепциями как пользователь должен отражать ситуацию в базе должнны работать как умный "автопилот", заменяющий человека-диспетчера и одновременно представлять человеку ясную картину происходящего. Разрабатывали 6 лет.
2.Монолит примерно на миллион строк кода. Нужно встроить портал, транслирующий некий самописанный DDL в стандартный. Архитектура опять простейшая и обусловлена существующим фремйворком. Разрабатывался пол года.
3.Продукт собирает информацию с сотен тысяч устройств. Есть замысел переделать эту функцию на событийно ориентированную платформу. Архитектура задумана давно и не сложна. Сложность - бизнес логика заложенная в алгоритмах обработки информации. Разрабатывался до POC пол года.
4.Система отображения информации на видеостены. Архитектура опять простейшая - десктоп приложение и клиент-сервераная часть для вывода. Сложность - нужен гибкий графический редактор, нужно понять как всем этим смогут пользоваться, много модулей на C++, фреймворки для выовда видео, OpenGL и прочее. Продукт создавался год.
5.Система на основе компьютерного зрения...
И так далее.
Во всех этих ситуациях разработка требовала месяцы или годы, а архитекрута по сути могла быть сочинена за 5 минут по ее сложности, хотя можно было без проблем над ней думать и месяц, если хотелось. А интересы бизнеса изучались очень долго и сложно. В какой ситуации программисты могут сетсть и что-то проектировать как на собесе, да еще с каким-то учетом интересов бизнеса я не представляю.
Не представляю, потому что явно пропустил все места, где такое происходит.
Могу только предполагать. Допустим, речь о неких масштабируемых системах массового обслуживания (котоых я не писал) спроектированных на микросервисах (ктоторых тоже едва касался). И дальше начинаем обсуждать проблемы связанные с тем это обслуживание массовое и проблемы вытекающие из микросервисной архитектуры. Тогда можно представить людей, которые садястя и что-то проектируют. Но это догадка пальцем в небо.
В какой ситуации программисты могут сетсть и что-то проектировать как на собесе, да еще с каким-то учетом интересов бизнеса я не представляю.
То, что вы описываете о монолитах-гигантах и связанных с ними сложностях, вполне понятно. Детали размещения каждой DLL не имеют значения в разрезе интервью, как и нюансы работы графического редактора и фреймворка на C++. Эти нюансы невозможно учесть ни за 5 минут, ни за полтора часа, а некоторые из них могут потребовать даже полтора года.
Важно уметь выделять важное. Чем более узконаправленного специалиста вы нанимаете, тем более специализированными и глубокими становятся вопросы. Если у вас уже все сделано, а нормальный редактор на C++ так и не был написан, тогда нужно искать человека с конкретным опытом в C++ и в обработке видео.
Продукт собирает информацию с сотен тысяч устройств. Есть замысел переделать эту функцию на событийно ориентированную платформу. Архитектура задумана давно и не сложна.
Событийно-ориентированная архитектура и фраза "не сложна" не совсем сочетаются. Это отличная возможность обсудить с кандидатом его опыт работы с EDA. Также стоит поговорить о масштабируемости базы данных, идемпотентности, конкурентности, целостности и согласованности данных, обработке ошибок и механизмах DLQ. Очевидно, что на таком уровне также необходимо настраивать масштабируемый compute. Перед этим можно предложить спроектировать API для загрузки данных, а также обсудить реализацию аналитики этих данных (отчеты и тд). Здесь есть широкий простор для диалога.
Система отображения информации на видеостены.
Здесь я мало знаком с предметом, поэтому просто пофантазирую на тему. Как видео попадает на десктопное приложение? Загружается из интернета? Что делать при проблемах с сетью? Если видео несколько, нужен какой-то механизм буферизации и предзагрузки следующего видео. Как защитить исходники? Выдавать каждому клиенту какой-то ключ или сертификат? Есть ли какой-то CDN? Как настроить обновление десктопного приложения? Стоит обсудить разные бизнес-флоу, не только те, которые используются у вас (вы же проводили какой-то анализ перед тем, как остановиться на решении, и почему-то выбрали именно такой подход?). Возможно, в связи со всеми этими сложностями и нестабильностями вы решили обновлять ПО и загружать новые видео банально вручную с флешки. Тоже вариант.
Сложность - нужен гибкий графический редактор...
Можно обсудить с кандидатом, что нужны видео разной длины, разных форматов экранов и т.д. Необходимо спроектировать API для CMS, базы данных для хранения метаданных, blob-хранилища и т.д.
Опять же, я просто накидываю опции.
Также стоит поговорить о масштабируемости базы данных, идемпотентности, конкурентности, целостности и согласованности данных, обработке ошибок и механизмах DLQ.
Там был Orleans grain и все нюансы архитектуры скорее обусловлены заложенными в нем решениями. Предполагалось что он все держит в памяти, база на чтение нужна только на момент пуска системы в нее постепенно дописываются собранные данные. Отчеты строятся по текущей ситуации в основоном и не по базе а по греинам. Проблемы с конкурентностью в базе там быть не могло, потому что каждый греин работает со своими данными. Но был один кейз, когда работа с базой шла в обход грейна, и там потребовалась одна оптимистичная блокировка. API полностью зависит от бизнес-логики, в целом это просто вызов методов греинов, но не зная специфики задачи и отрасли врядли что-то можно обсуждать. Ну и самое интересное, что это был только POC, а до вопросов масштабирования скорее всего или добрались бы позже или обошлись мощным сервером. И конечно, нюансы архитектуры (даже эти простые) рождались месяцы а не формировались в режмиме - сели и нарисовали. И того, получается работал, но такого что можно обсудить в стандартном формате на собесе нет.
Как видео попадает на десктопное приложение? Загружается из интернета? Что делать при проблемах с сетью? Если видео несколько, нужен какой-то механизм буферизации и предзагрузки следующего видео. Как защитить исходники? Выдавать каждому клиенту какой-то ключ или сертификат? Есть ли какой-то CDN? Как настроить обновление десктопного приложения?
Вообще ничего подобного. Женщина приходит к компу на котором и интернета то нет, и загружает видео с флэшки, которое ей принес еще кто-то. Буферизация простая - конечный девайс загружает все видео, которые упомянуты к себе на диск и начинает их гонять по кругу. Десктопное приложение обновляется путем заключения договора, коммандировки, переписывания новой версии с обучением женщины на месте. Ни о каких защитах никто не слышал и знать не знает.
Можно обсудить с кандидатом, что нужны видео разной длины, разных форматов экранов и т.д. Необходимо спроектировать API для CMS, базы данных для хранения метаданных, blob-хранилища и т.д.
Кандидат был занять борьбой с депенденси хелом библиотеки и ее багами, при попытаках запустить все на одноплатнике, методами рендеринга текста, а так же дизайн паттернами для отмены и повтороного применения дейсвий в редакторе и прочими стандартными для редакторов проблемами.
Слово "метаданные" в этом контексте он никогда не слышал, и будет в когнитивном диссонансе, почему теперь "метаданными" называют просто табличку со ссылками на файлы. Блоб-хранилища, это опять таки скорее о системах массового обслуживания.
Спасибо за ваше подробное сообщения, я немного начинаю понимать о чем речь. В такого рода IT о котором вы говорите я еще не работал.
Здесь, что характерно, люди часто работая в IT бизнесе построенном на определенных (пускай современных и новомодных) тенденциях верят, что IT абсолютно везде одинаковое. Но на самом деле это одинаковое IT - это только вершина айсберга. Помимо приложений, похожих на твиттер или банкинг, есть игры, софт для управления технологическими процессами, для диспетчерского управления, САПР, софт для самых разных целей, вроде обнаружения уязвимостей, автоматического развертывания и так далее.
Если начать искать работу в Linkedin, то скорее попадешь на что-то из этого списка, чем на что-то стандартное для веб-разработки.
Соответственно, при проведении собеседований очень важно не рассматривать опыт кандидата в проекции на собственный опыт. Если конечно не стоит задача найти специалиста с абсолютно релевантными для типичного современного web-проекта навыками.
Я абсолютно согласен, что айти разное. Я скорее предлагаю варианты, как можно построить интервью в формате диалога и пытаюсь подсветить, что это возможно в любом направлении айти. Я убежден, что всегда можно выделить несколько областей в системе, которые можно обсудить в течении полутора часов. В конечном итоге цель это понять, на одной ли вы волне с кандидатом, достаточно ли он компетентен хотя бы в теории, и будет ли Вам комфортно с ним работать, как с коллегой.
Комфортно ли вам будет работать с человеком, с которым вы хотите обсудить как лучше решить проблему конкуретной обработки в этой части системы, а он говорит "ну, я не знаю...я с таким не работал...я бы спросил кого-нибудь другого.". Или наоборот слишком радикален: "да я вообще против оптимистичного локинга, всегда работал с пессимистичным и нормально было".
Что-то более ощутимое и реальное можно узнать только из опыта работы с человеком, или найма путем реферальной программы, получением отзывов с предыдущих мест работы или наличием достижений, которые говорят сами за себя.
Вы просто не подходите под условную позицию, о которой идет речь в статье. Причем именно ваш опыт мне ближе, но в большинстве случаев рынку нужны именно кандидаты под такие позиции.
Как человек, которому периодически требуются сотрудники (в основном на доработку), я понимаю, что проще самому накидать всю архитектуру, чем нанимать кого-то, кто будет её моделировать с нуля. На поиск разработчика под полную разработку я потрачу больше времени, чем на передачу доработки уже собранного MVP.
Я передаю доработки мидлам, а сам сажусь за связку железа с софтом — это куда интереснее, чем "бизнес-процессы", которые в большинстве своем давно стандартизированы. За редким исключением, когда начинают лепить очередной велосипед.
Поэтому гораздо проще отбирать кандидатов на доработку с меньшими скиллами. В итоге продукт выходит на рынок за 3–4 месяца, а не за год-полтора, из которых 3–4 месяца уходит только на поиск подходящего кандидата.
Просто у многих стоит задача "поработать", а у меня — "чтобы работало".
Здесь логика такая, что если человек знает все что нужно для позиции и имеет релевантный опыт для позиции, то он точно уже работает в подобном проекте. А если он там работает, то значит чтобы его взять надо предложить ему зарплату прилично выше той что у него есть, иначе зачем ему это все. Но такая ситуация скорее небольшая часть вакансий, чем правило. За всю мою карьеру я ни разу не получал задач в которых я уже имею опыт. Все и всегда делается в первый раз. И я не вижу вокруг себя людей, у которых было бы по-дургому. Людей с улицы берус в CRUD приложение. Люди из CRUD идут пилить какого-нибуль CRM монстра, а выростая переходят вдруг в банки или вообще ировую индустрию.
Поэтому собеседования так трудно проводить.
И я не вижу вокруг себя людей, у которых было бы по-дургому.
Давайте познакомимся. Я годами делаю то, в чём имею опыт :)
"Годами" не звучит как слишком долго. Как я писал выше, однажды я делал одну задачу 6 лет, но потом нашел работу которая требует вообще других скилов. Вы меняете работу и на новой работе все похоже на старую? Это большая удача если так получается, я считаю.
Один раз за 12 лет менял работу. На старую не похоже, потому что скиллов требуется ещё меньше :) В вакансии было примерно то, что я умею, но оказалось, что не настолько сложно. Деградирую помаленьку. Но я пытаюсь изредка что-то для себя делать, что-то читать, чтобы в будущем найти что-то хотя бы под прежний уровень умений.
Задачи у меня обычно меньше, чем на месяц, если не отвлекаться на другие. Большинство — на один-два дня, но бывают более комплексные.
Один раз в жизни я делал бэкенд сайта на Симфони для чего-то там связанного с АвтоВАЗом, конфигуратор комплектации автомобиля, сравнение комплектаций, админка, ещё что-то всякое. Всё это писалось после начала работы каких-то фрилансеров (как раз был 2014-й, а фрилансеры были из Украины), а я вообще не был знаком с Симфони. Короче, мы вдвоём работали и потратили что-то около года. А сайт не запустили. Это самое масштабное, чем я занимался.
Второе по сложности — это в 2016 на незнакомом мне MODX делал сайт для формирования 3-НДФЛ декларации. Пришлось ковыряться в налоговом кодексе, сделали тогда не все возможные разделы, но многое. Месяца три ушло. Потом я постепенно ушёл в фронтендеры, так как компания стала пересаживаться с PHP на Python и мои знания PHP стали не нужны.
Хочу с Вами работать
Мои 7 правил при собеседовании разработчиков