Комментарии 278
Перед каждым собеседованием заново учу, как работает хешмапа, чтобы уже через две недели успешно эту информацию забыть…
Может надо не учить, а просто один раз понять? Я понимаю, какие-то нетривиальные алгоритмы именно учить, но идея о том, что каждому объекту поставить в соответствие целое число, числа обрезать до размера массива и сложить объекты в массив, каким-то образом разрулив естественным образом возникшие коллизии, кажется лежащей на поверхности. Что здесь учить-то?
Я, наверное, сейчас сравню не сравнимое, но в официальных экзаменах по Java (OCA и OCP), сдача которых автоматически делает Вас признанным со стороны Oracle специалистом, отсутствует 90% кейсов, которые спрашивают на типовых собеседованиях. В том числе и внутреннее устройство HashMap.

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

А эти задачки вообще-то не для того, чтобы вы вспомнили алгоритм. Наоборот, они рассчитаны на то, что вы не помните, и будете его придумывать. Это задачки на тему «умеете ли вы программировать», а не «заучили ли вы наизусть Кнута»

Задачки на программирование, спору нет. Но как они отражают повседневные задачи? И что значит уметь программировать? Т.е. выучили вы Кнута, окончили универ, но не смогли отсортировать список с двумя стеками за 10 мин, тупо из-за волнения, все вы не программист, вы уборщик, или дворник?

А они априори должны отражать? Откуда у кандидатов уверенность, что собеседование и прочее должно как-то отражать то, что предстоит в еждневной рутине и периодических авралах? )

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

А мне нравится позиция "нанимаем мы человека, а не функцию".

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

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

А мне нравится позиция "нанимаем мы человека, а не функцию".

Никто собственно и не забывает, что нанимается в первую очередь человек. Будь то тест или задание на доске или просто беседа, этого будет недостаточно для раскрытия потенциала кандидата.

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

А как насчет случаев, что человек не рассказал про алгоритмы, а как джун-бекендер может работать. Вы осознанно их отсеиваете? Нет нехватки кадров?

Да, вполне осознанно. Нехватки нет, хотя вакансии не быстро закрываем.


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

Закрыть вакансию не проблема, особенно если к примеру вы FAANG (ну или около). С другой стороны куча маленьких и средних компаний. Готов ли я потрать пару месяцев на подготовку к интервью в Гугл как обезьянка переворачивая деревья на каком нибудь leetcode? Да, пожалуй. Готов ли я потрать пару месяцев подготовки для "Рога & Копыта", сомневаюсь. А вот мой знакомый готов, только для него единственная мотивация — деньги, а для меня сам продукт. Кого вы возьмете? Моего знакомого который прочитал пару-тройку книг "кряканья на интервью".

Да не надо тратить время на подготовку к нашему интервью. Скорее всего возьмем вашего знакомого. если не выявим ваши мотивации

Но как они отражают повседневные задачи?

Да очень просто, на самом деле. Более конкретные повседневные задачи вида «распарсить входную строку, выделив из неё нужные данные», «реализовать операцию Undo для формы», «отображать список из N последних документов, с которыми работал пользователь» и тому подобные — все они решаются с помощью тех же скиллов и участка мозга, которыми вы будете сортировать список на собеседовании. И вы скорее всего не найдёте по ним готовых сниппетов на SO конкретно для вашего приложения.
Т.е. выучили вы Кнута, окончили универ, но не смогли отсортировать список с двумя стеками за 10 мин, тупо из-за волнения, все вы не программист, вы уборщик, или дворник?

А как другие профессии справляются? Водителю: «давайте проедемся по городу, хочу посмотреть на вашу манеру вождения» — «Ой, нет, я волнуюсь, могу из-за этого в аварию попасть». Причём речь не про то, что он там должен именно за 10 минут под психологическим давлением, можно и сказать, что дескать, щас я сосредоточусь, а то начинаю волноваться, когда пишу под наблюдением. Это абсолютно нормально. И если программисту так страшно на собеседовании, что он логично думать перестаёт, ну пусть валерианку пьёт, что ли, или к психологу сходит. Как-то надо же учиться выживать в этом мире, где иногда приходится разговаривать с живыми людьми.
Странно, почему тогда так часто пишут про волнения на собеседованиях? И более интересный вопрос, почему тогда не пишут, что от волнения на собеседованиях спасает валерьянка и поход к психологу?

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

Потому что те, кто волнуется не пьют валерьянку и не ходят к психологу. Мне вот и в голову не могло прийти что это может помочь. )) Перестал волноваться на собесах, изменив своё отношение к ним. Хотя иногда даёт сбои. Например, дали простенькую задачу, дали макбук (без мыши!) и оставили одного. Наверное, хотели как лучше, как раз чтобы не волновался, а там, блин, ctrl+c/v не работает и на тачпаде нет правой кнопки мыши — самое позорное моё собеседование за почти 30 лет. Вот купил себе макбук про М1 чтобы больше в таких ситуациях не волноваться, пишу с него ))

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

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

А где я говорил про "волнение"? Разве так распереживаться, что забыть свою повседневную работу, это "волнение"? Мы все волнуемся, и я в том числе, и перед экзаменом, и на собеседовании. Но мы же как то их сдаём :)

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

А как повседневная работа связанна с реализацией water trapping алгоритма, на коленке за 20 мин? Я то говорю именно что про волнение, а не про паническую атаку, которая сама по себе, кстати не является чем то негативным или психически нестабильным.

Упавший прод и бизнес, кричащий про потери денег и репутации вроде более волнующий )

Упавший прод ...

Как много воспоминаний это нам навеивает, эх. Позвольте поделиться с вами одним из них. У нас был в конторе Дайта Сайентист, мозгище, так сказать, он когда меня собеседовал, завалил буквально задачками типа как найти два пропущенных числа в неотсортированной последовательности чисел, за один проход без сортировки и желательно за память O(1) (я про формулу то знал, но с применением напутал) так что сговорились на O(n) по всем фронтам.


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

  • в повседневной работе надо логически рассуждать так же как и при реализации алгоритма
  • повседневную работу можно разбить на участки по 20 минут
повседневную работу можно разбить на участки по 20 минут

Каждые 20 мин в течение рабочего дня вы стоите перед доской и на вас пристально смотрят несколько человек оценивая каждый ваш вздох?


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

Каждые 20 мин в течение рабочего дня вы стоите перед доской и на вас пристально смотрят несколько человек оценивая каждый ваш вздох?

Нет. И что? Вопрос был "как связана" а не "чем отличается". Разумеется собеседование отличается от работы.


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

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


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


Разумеется, как и любой способ измерения он не точный и дает ложноположительные и ложноотрицательные результаты.

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

Речь идет о навыках, а не 100% совпадающих задачах.


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

Про то и речь, только разница в подходах.

все они решаются с помощью тех же скиллов и участка мозга,

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


Водителю: «давайте проедемся по городу, хочу посмотреть на вашу манеру вождения» — «Ой, нет, я волнуюсь, могу из-за этого в аварию попасть».

В том то и дело, если олдскульный подход переводить в плоскость вождения, то вас каждый раз просят заехать на автодром, и управлять тс под углом в ~55,578 градусов, переключаясь между 1 и 2 передачами локтем правой руки и между 2 и 3 передачами левой рукой, выруливая исключительно подбородком. Все это для того что бы понять как вы будете водить в городских условиях. Обожаю этот термин, Problem Solving Skills.

Я ничего не слышал про отдельные участки мозга ответственные за отображения элементов списков

А за логическое мышление — слышали? Вот это оно самое. Зубрить и соображать, это разные области мозга.
В том то и дело, если олдскульный подход переводить в плоскость вождения, то вас каждый раз просят заехать на автодром, и управлять тс под углом в ~55,578 градусов, переключаясь между 1 и 2 передачами локтем правой руки и между 2 и 3 передачами левой рукой, выруливая исключительно подбородком

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

Я про то что работу мозга нужно рассматривать только в своей целостности, а не по зонам. Кстати с логическим мышлением не все так тривиально.


Ой, всё. Вас послушать, так можно подумать, отсортировать несчастный список — это не детская задачка

Когда вы попадаете под снежный завал, небольшой, метр с кепкой, что может быть проще, выбраться из него. Снег рыхлый, сверху убрали и вы на свободе, это же тривиально, это даже не к бабке ходить, список сортировать. А нет, многие так под снегом и остаются, копают вниз или в бок(куда лицо смотрит), вместо того что бы копать вверх, с логикой конечно у них никак, нужно было им к психологу ходить и пустырник пить. Тут метод дедовский есть, нужно лицо освободить и плюнуть, для определения верха и низа и потом копать. Я про то, что для многих собеседование это стресс(давайте, смейтесь, показывайте пальцем, как мы это умеем, ха мднь волнуется перед собеседованием). В стрессовых ситуациях ваше логическое мышление работает не так как вы этого хотите.

Я про то, что для многих собеседование это стресс

Ну стресс, ну ок. Вопрос в другом — ради чего на собеседовании избегать каких-либо вопросов/задач по существу для собеседуемого? Стресс — это вообще ни разу не повод. Собеседование как раз для того и существует, чтобы работодатель выяснил скиллы кандидата, кандидат выяснил условия работы. Если кандидат в таком стрессе, что не в состоянии показать свои скиллы (и бьюсь об заклад, что в таком состоянии он тем более не сможет задать крайне важные вопросы уже работодателю со своей стороны), кто ему виноват, кроме него самого? Пусть решает эту проблему, это в его личных интересах.
Собеседование как раз для того и существует, чтобы работодатель выяснил скиллы кандидата, кандидат выяснил условия работы.

И автор, и я считаем (видимо) что упражнения/тестовые задания(я в принципе не против оных) на собеседованиях, ни коим образом не помогают выяснить скиллы кандидата, а уж тем более кандидату выяснить условия работы. Только и всего.

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

Ну вот видите, мне так не кажется.

Вы прям спрашивает сортировку списка? Я думаю чуть посложнее, например над чем я не справился, реализовать структуру односвязный список(Python) и развернуть её. На словах кажется просто, на деле и бумаге у меня не вышло. Но вообще вопрос в другом: «Почему Алгоритмы?» (Спойлер: потому что гугл это ввёл по своим причинам, а все обезьянничают и сейчас на ходу придумывают объяснения как эти задачи показывают умение думать, видно как программист мыслит и и прочие общие фразы) Почему например не задачки по высшей математике, по мат. логике например? Тоже ведь логику показывают и с программирование перекликаются.
А потом на работу приходишь и алгоритмические задачи никому не нужны, а больше нужно умение написать «чистый код», продумать архитектуру, разбираться в куче софта(docker, очереди, бд и т.п.)
Я думаю чуть посложнее, например над чем я не справился, реализовать структуру односвязный список(Python) и развернуть её. На словах кажется просто, на деле и бумаге у меня не вышло.

Ну блин, даже не знаю, что вам сказать. Или будьте спокойнее, или качайте соображалку. Развернуть односвязный список — задача ещё проще, чем отсортировать.
Почему например не задачки по высшей математике, по мат. логике например?

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

Мне в 99% процентах случаев они тоже не нужны. Но если бы я не умел составлять алгоритмы в 1% случаев, многим моим проектам была бы крышка.

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

Касательно вождения — мне недавно после 15 лет активного стажа в весьма нетепличных сибирских условиях пришлось сдать экзамен повторно, в Германии. Ощущения при подготовке и сдаче радикально отличаются от обычной езды и прямо очень похожи на то, что чувствуешь на собеседованиях. Сдал только со второго раза, разница с практической ездой огромная.

Вы именно про вождение или про теорию? Фактор языка и другой страны накладывается, тем более что теория не тестами идет как в России.

Вождение, да. Теория-то как раз именно тестами, там делать нечего. Из языка на экзамене нужен совсем уж минимум. Именно что требования отличаются от того, что при обычной езде. Например, надо головой вертеть на очень большой градус: это мало того, что чисто физиологически просто незачем (достаточно чуть повернуть и перевести взгляд), так еще и опасно, обзор вперед пропадает. А требование нужно для того, чтобы экзаменатор с заднего сиденья видел, что ты голову поворачиваешь. Ну и много приколов по манере езды, сейчас уже не вспомню, но смысл в том, что даже местные так не ездят в жизни.

С другой стороны, когда поймешь систему, всё легко: на мотоцикле я потом город сдал вообще без проблем, переживал только за площадку (ну, там вполне объяснимо, полностью новая деятельность).

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

Вертеть надо, кто ж спорит, только нафига её как у совы выворачивать-то — до такой степени, что уже не видно, что впереди происходит? Чуть повернул, взгляд перевёл, и всё прекрасно видно.
Водителю: «давайте проедемся по городу, хочу посмотреть на вашу манеру вождения» — «Ой, нет, я волнуюсь, могу из-за этого в аварию попасть».
А это не совсем корректное сравнение. Для вождения нужен навык, для решения алгоритмических задач, которые ранее никогда не встречались (а такие и стремятся ведь давать), нужен интеллект. IQ очень сильно подвержен стрессу и падает соответственно. Если вы делаете на это поправку в лив кодинге, то в принципе всё нормально) Если не делаете или делаете слишком небольшую, то вы дополнительно выбираете личности с определённым складом характера, «толстокожие» так сказать. Или опытных в собеседованиях)

Любое собеседование будет отбирать по чему-то дополнительному. Если не хочется отбирать, то надо рандомно приглашать на работу всех жителей Земли и проверять их.

Но почему компания должна нанимать таких? Я сам (да и на самом деле не только каждый, но и все) в такой ситуации находился на 90% интервью — не смог что-то решить или на что-то ответить. В остальных 10% офер был. какая разница почему не ответил?

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

Это собственно и есть процесс найма. Если вы уж так волнуетесь, что вообще все забывате, то наверно надо куда-то в другую облать двигаться (фриланс или свой проект или opensource) или как-то решать эту проблему чтоб не вылетало из головы.
Вопрос не бинарный «смогла/не смогла» вообще хоть что-то сделать. Я говорю лишь о поправке на стресс. К примеру, вчера мне понадобилось 10 минут на размышления, как сделать один алгоритм и структуру по сортировке особых строк с линейными гарантиями времени и памяти, и потом ещё более получаса на хитрую реализацию. На собеседовании из-за снижения IQ из-за стресса мне бы это не удалось сделать за адекватное время. Но кое-как удалось бы написать такую сортировку строк с сильно худшими гарантиями, более «в лоб».

Если вы ожидаете, что IQ не падает на собеседовании, то вы либо отбираете кандидатов с подготовкой и большим опытом в прохождении собеседований, для которых это нормальный режим функционирования, либо специфичных «толстокожих» людей, которым это собеседование «по барабану».
Про скидку на волнение я написал. Задачек типа «как в Гугле» я не даю и сам не люблю делать. Но вот задачки уровня fizzbuzz, переворота строки или нахождения максимума (просто! без всяких подвохов) — это, извинете, вынь да полож. На интервью для сениоров я никогда не спрашиваю ничего сложнее уровня джуниоров, но только потом начинаю вводить дополнительные условия и «а что если». Но в этот момент кода уже не прошу — просто рассуждения.
Тогда всё отлично, да я и против сортировки строк не возражаю! Просто такие задачи бы вызывали подозрение в bullshitовости компании, если это не на позицию Dream Job. С hype-driven-development и прочим.

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

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

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

Тут дело не в" понять", понять можно все что угодно, ну если мозги еще остались. Работодатель действительно иногда выглядит так, что его самого хочется "отсобеседовать". Какого "фаллоса" я должен помнить про "пузерьковую сортировку", если она гуглится за 1минуту, а последним проектом у меня была задача по созданию биллинга для виртуальных сред?

А кто сказал, что вы должны? Пока вы кандидат, то ещё ничего не должны работодателю потенциальному.

а потом люди не могут ответить на собеседование, в чем будет проблема если написать
public int hashCode() {
        return 9;
}

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

Следующий уровень злодейства:


public int hashCode() {
    return (new Random()).nextInt(1000);
}

Ваш ход.

Это ещё очень синтетически. А как вам мутабельный объект в качестве ключа?

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

Ух :) я уже за сердце схватился, на питоне такие фокусы точно не прокатят, а вот за Java не был уверен, вопрос-ловушка.

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

Вот интересный вопрос на stackoverflow на эту тему:
ru.stackoverflow.com/questions/930894/Кастомные-ключи-в-словаре

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

Думаете, это однозначно? Этот код компилируется С компилятором:


#define public long
public int hashCode() {
        return 9;
}

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

Этот код компилируется С компилятором:

Нет, код из сообщения выше не компилируется в С. Вы #define-хак используете переименовав слово public в long.

Если приглашают на позицию java разработчика, то логично, что не про с++ будут спрашивать…

В том и дело, что в вашем комментарии с кодом не было ничего про ява и ява-разработчика, просто предложен код — который я успешно скомпилировал как С код, добавив простой дефайн. Значит, это валидный С код, не так ли. В свое время были популярны подобные головоломки, вот вам и вариант того, что не так в вашем коде — дефайна не хватало. А можно и не только на С ваш код запустить:)

Более того, дефайн добавлять не обязательно: многие компиляторы поддерживают вещи вроде -Dpublic=long.

Это же Java?
Погуглил про метод hashCode() и его отличие от equals()

Моя версия ответа: проблем не будет, будет некоторое падение производительности метода equals() в данном объекте. Если объект активно не сравнивается, то падение производительности может быть ниже статистической погрешности измерений.

Верный ответ? :)
Это же Java?

да


Погуглил про метод hashCode() и его отличие от equals()

я прекрасно знаю как работает equals и hashCode


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

до тех пора пока вы его не положите в HashSet, Hash* etc… а если у вас миллионы таких объектов, то это оч сильно повлияет на производительность, что для той же хешмапы увеличит стоимость get с O(1) до O(log(N))


Верный ответ? :)

если не хотите закончить как Parler (я о количестве железа), то нет

стоимость get с O(1) до O(N)

Вообще, если не брать совсем уж устаревшие версии Java то c O(1) до O(log(N)), потому что для таких случаев довольно быстро будет строиться бинарное дерево.
НЛО прилетело и опубликовало эту надпись здесь
Если хэш одинаков, а ключи несравнимы, то на основе чего дерево строить?

На основе System.identityHashCode (это hashCode по умолчанию), то есть банально в качестве хешкода будет использоваться указатель на объект в памяти.

P.S. Вообще-то, код HashMap'ы и т.п. классов легко можно увидеть в той же IDEA, если вам любопытно как все там устроенно. И код там относительно простой.
НЛО прилетело и опубликовало эту надпись здесь
O(N) не будет, будет O (logN), при миллионе объектов будет дерево а не лист
Очень надменным выглядит ваше утверждение про «я прекрасно знаю как работает equals и hashCode», и немного неуместным на фоне ошибки оценки сложности.
В контексте моего ответа, сложность O(log(N)) потому я говорил о большом количестве данных, но по факту сложность O(N) тоже правильная, ибо она может быть когда у всех объектов в бакете один хешкод(как раз обсуждаемый кейс) и не достаточно много объектов что бы использовать TreeNode
и немного неуместным на фоне ошибки оценки сложности.
я уже признал выше что мне нужно было более точно расписать.

П.с (если упарыватся) В теории возможна ситуация когда у вас много маленьких (в которых не много объектов) хешмап в которых миллионы объектов и тогда у каждой сложность O(N)

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

я прекрасно знаю как работает equals и hashCode

Наверное потому, что вы Java dev/были им недавно или просто для себя пишете на Java? :)
А я узнал о наличии функции hashCode в процессе гугления.

до тех пора пока вы его не положите в HashSet, Hash* etc… а если у вас миллионы таких объектов, то это оч сильно повлияет на производительность, что для той же хешмапы увеличит стоимость get с O(1) до O(log(N))

Вам изнутри Java мира, конечно, виднее, но...:
1. Миллионы объектов в сортированной мапе — это уже далеко не уровень Java junior и для такого подхода должны быть какие-то свои очень специфические причины
2. Класть сложные объекты (да, знаю, что в Java всё объект, включая String) в мапу, которая будет их сортировать (ок, раскладывать по хэшам, но от этого не легче) — уже плохой признак.
3. Осознанно ломать сортировку в объекте, который потом будешь сортировать… ну это уже очевидный выстрел себе в ногу.

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

А нормальные люди сначала погуглят (или покопаются в памяти) и вдумчиво выберут тип списка.
Если у вас много объектов и по ним поиск (.Get(obj)) не требуется, то выберут какой-нибудь LinkedList, если нужен доступ по понятному ключу, то это будет какой-нибудь HashMap<int,Obj> или HashMap<string,Obj>

Как итог (и моё Imho человека не из мира Java) — даже если разработчик сходу не может дать ответ, то вариант «хз, дайте пару минут погуглить по функции hashCode() » может быть вполне адекватным.
выберут какой-нибудь LinkedList,

В это-то и проблема. LinkedList настолько плохая структура, что её лучше не использовать почти никогда.

«хз, дайте пару минут погуглить по функции hashCode() » может быть вполне адекватным.

Из мира Java это примерно как профессиональный водитель будет гуглить правило проезда равнозначного перекрестка, так как на правильном использовании hashCode и equals построенно практически все в языке.
LinkedList настолько плохая структура, что половина коллекций в Java использует его в той или иной степени.
Плохому танцору…
LinkedList настолько плохая структура, что половина коллекций в Java использует его в той или иной степени.
плохо что вы не видите в этом проблемы
половина коллекций в Java

Сможете перечислить эту самую половину коллекций?

На самом деле, сейчас проверил нашел только одну такую коллекцию — LinkedHashMap. Ну и LinkedHashSet как простая обертка над LinkedHashMap. LinkedHashMap использует аналог LinkedList исторически, так как появилась в 4 версии Java до того как поняли что производительность LinkedList не очень, потом просто не стали вводить какой-нибудь ArrayHashMap, чтобы не усложнять язык.

Плохому танцору…

Это не мое мнение, а официальное Oracle.

But you pay a big price in performance. Positional access requires linear-time in a LinkedList and constant-time in an ArrayList. Furthermore, the constant factor for LinkedList is much worse. If you think you want to use a LinkedList, measure the performance of your application with both LinkedList and ArrayList before making your choice; ArrayList is usually faster.


В целом вполне четко сказано, лучше всегда используйте ArrayList, если все-таки решите использовать LinkedList, померьте сначала производительность, почти гарантировано реализация с ArrayList будет быстрее.

P.S. В стороних библиотеках коллекций, есть лучше реализацию списка с частыми вставками, например TreeList от apache commons.

P.P.S. Подробнее о коллекциях я писал тут.
Сможете перечислить эту самую половину коллекций?

Linked*
HashMap(Ок, там не совсем он, но очень похож, ну и в Java 8 добавлен авто переключатель на дерево).
Плюс все, что реализует очереди, стаки и тд…

Плюс любой функционал туда-сюда, типа истории действий, тоже так или иначе будет основан на Linked List
Linked*

В пакете java.util; их ровно 3, те что я перечислил сам LinkedList, LinkedHashSet и LinkedHashMap.

HashMap(Ок, там не совсем он, но очень похож, ну и в Java 8 добавлен авто переключатель на дерево).

Там совсем не он и дерево и двухнаправленный список это две большие разницы. Вот совсем.

Плюс все, что реализует очереди, стаки и тд…

Как же вы плохо знаете коллекции.

Открываем интерфейс Queue и видим реализации:
— ArrayBlockingQueue, ArrayDeque — на основе массива
— PriorityQueue, PriorityBlockingQueue, DelayQueue — на основе кучи (по сути тоже массива),
— LinkedList, LinkedBlockingQueue — на основе двухсвязного списка, причем практически все это просто многопоточные реализации LinkedList.

То есть не все и даже не половина.

P.S. По сути, двуноправленный список используется только в LinkedList и всех его многопоточных реализациях, LinkedHashMap (и его обертке LinkedHashSet), а так же во множестве устаревших коллекций, которые давно объявленны deprecated (именно из-за производительности).
Я так то говорю за структуру данных, а не за реализацию LinkedList в java.util
Бинарная куча — это массив? Ну здрасте.
Вы можете получить доступ к крайним элементам ветки в кучи по индексу?
Вы можете получить доступ к любому элементу куче без необходимости пройти от корня?
Какой это массив? Это и есть в некотором смысле связные списки, только со ссылкой не на один следующий элемент, а на два.
Бинарная куча — это массив? Ну здрасте.

Если откроете PriorityQueue, то обнаружите там массив в качестве хранения и ArrayDeque внутри для организации очереди. Ничего похожего на LinkedList там нет.
Нет, если натягивать, то ArrayList это тот же LinkedList только ноды хранятся в одном месте, но это уже совсем сову на глобус получится.
Ладно, ваша взяла =)
Надо освежить внутреннее устройство коллекций.
В целом вполне четко сказано, лучше всегда используйте ArrayList

В приведённом Вами отрывке этого не сказано (отрывок вполне разумный).
Ростелеком не парится — в тестовых заданиях предлагает прислать 3 работающих программы.
Ну вот только что очередной соискатель позиции разработчика на Java завалил практическую часть. Про SOLID он понимаешь знает, про DI и Spring рассказал вполне толково, опыт работы есть, а FizzBuzz (на своей стороне, собеседовали в Skype) написать в IDEA не смог. И даже не попытался посмотреть, чего это среда разработки там подсвечивает некоторые строчки и говорит, что логическое условие всегда истинно. И следующий тест примерно такого же уровня сложности тоже завалил. Тесты, если что, оформлены как static функции класса, на каждую есть юнит тест, который и проверяет правильность решения.
И как без практического теста нанимать в условиях тотальной удалёнки? Т.е. как отличать человека, который умеет писать код и синтезировать простенький алгоритм в голове от того, который просто хорошо подготовился к собеседованию и имеет рядом собой бумажки или вкладки браузера с ответами на типовые вопросы?

Можно попросить человека поделится ссылками на код который он писал в рамках каких то опенсорс проектов. Если человек не участвовал в написании опенсорс проектов то в моих глазах это вцелом минус, но если очень надо можно попросить его выполнить несложное тестовое задание. Как вы сами сказали человек знает про SOLID и у него есть опыт работы, т.е. крайне маловероятно что он не может написать FizzBuzz или посмотреть на подсказки в IDE — это может даже джун. Но при этом весьма вероятно что человек волнуется и изза этого не может решить даже простейшие задачи. Зато в спокойной обстановке легко с этим справится

На ваше пожелание очень просится статья про «Почему вы не должны соглашаться на собеседование по коду написанному в рамках opensource проектов».

Могли бы вы более детально раскрыть свою мысль про опенсорс проекты? Из моего опыта:


1) Опенсорс проекты как правило имеют лучшее качество кода. Соответственно человек который в них участвовал как правило имеет более высокие навыки чем человек который писал закрытый код
2) Участие в опенсорс проектах предполагает следование определенному принятому флоу разработки как правило включая в себя техническое общение и процесс код ревью.
3) Моральный аспект — участие в опенсорс проектах показывает что человек стремится развиваться и в том числе развивать экосистему разработки.


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


Мое ИМХО что как раз участие в опенсорс является отличным (хотя и не единственным) критерием зрелости специалиста

Открыл соответствующий МР. Из моих выводов:
1) Вы принимали участие в достаточно сложных проектах. Это говорит о том что вы можете разбираться в большой кодовой базе и вносить в нее изменения.
2) Данный реквест по максимуму сохраняет обратную совместимость. Тоже плюс вам
3) Реквест был на ревью длительно время (около 6 месяцев вроде). Это говорит о вашем терпении и способности вести нудные технические дискуссии с индусами на англ. языке.


Из того что мне не понравилось сходу:
1) Реквест очень большой по обьему. Посмотрел что там большая часть диффа это изменения xml тестов. Я бы обязательно спросил почему нельзя было сделать его меньше и вмерджить частями.
2) В реквесте много комитов "Merge from master" и как минимум один фикс комит после ошибочного мерджа. Тут я бы спросил почему сделано именно так. Либо вы не умеете пользоваться git rebase и тогда это серьезный минус в моих глазах. Либо же это может быть политикой конкретного репозитория.


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

Ну я пока не настолько заинтересован Вас нанимать, чтобы вчитываться в детали :) тем более я давно не пишу на обоих этих языках.

Ок, тогда по вашим пунктам:
1) пожалуй, да.
2) так быстро вы это проверить не можете. Скорее всего судите по комментариям, а это не показатель того, что совместимость действительно сохранилась.
3) Индус там был один, и никаких долгих и нудных дискуссии. Вся переписка могла бы быть сделана только с помощью переводчика.

Итого из всего PR вы по сути смогли однозначно определить лишь 1 пункт.

Возможно, если бы вы прошлись по коду, то нашли бы ещё что-то интересное. Но у меня есть обоснованные сомнения, что вы бы по этому коду смогли понять, насколько хорошо я программирую вообще, или конкретно на C++/C#. Впрочем этого мы не узнаем.
Самый главный вывод следующий: по представленному опенсорс проекту потенциальный работодатель не смог определить язык, на котором программирует соискатель)
подвох тут ещё и в том, что С++ я не знаю и на первом же вопросе о нём погорю.

Контр-чтож: мне мой гитхаб вполне помогает трудоустроиться, от скипанья технических интервью до того, что стоило начать много и всерьёз писать в новой области ( https://github.com/0xd34df00d/refinedt например), как начали предлагать пообщаться о работе на смежные темы.

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


Другое, когда мы берём какого-то рандомного человека, который делал непонятно что, непонятно сам ли он это делал, и какой ценой он это сделал.


Для вас, как для соискателя, да полезно иметь опенсорс портфолио. Так же как и полезно ходить на тусовки и выступать на конференциях. Но для работодателя в общем случае наличие какого-то опенсорса у соискателя мало о чем говорит.

Мне до публичности очень и очень далеко, увы. Или не увы.


Но для работодателя в общем случае наличие какого-то опенсорса у соискателя мало о чем говорит.

Про общий случай я ничего не могу сказать. Могу лишь повториться, что, например, в том же фаанге мне скипали phone screening, в не-фаанге скипали иногда техническое интервью целиком (максимум обсуждая то, чего у меня в опенсорсе нет — распределённые системы там всякие, которые я делал на одной прошлой работе, но не в опенсорсе).


На конференциях я не выступаю, но знаю немало случаев, когда людям в найме помогали доклады на достаточно хороших конфах. Так что всё это вполне помогает, ИМХО.

Ещё раз, вам, как соискателю это помогает, это я не оспариваю. И даже мой пример можно подать в хороше свете. Я говорю о том, что опенсорс должен рассматриваться чуть достовернее тестового задания на дом (я против тестовых заданий).

Я не понимаю, почему.


Ну, то есть, да, если вы рассматриваете опенсорс как бинарный признак, то да, конечно (может, человек там нафоркал чужих реп и запятые на точки поменял, при очень беглом взгляде вы этого не заметите). Но если вы смотрите, что человек делает, примеры кода какие-то, и всё такое, то это, ИМХО, становится куда достовернее тестового задания. Особенно если профиль давнишний и не с эпизодическими коммитами.

Особенно если профиль давнишний и не с эпизодическими коммитами.

Знаете, мне недавно карма за ответ на  SO прилетела. Так вот, я его не понимаю. Я не понимаю свой ответ на SO, которым писал сам, и который мне лайкают… А по нему можно тоже предположить, что я знаком с темой.


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

Давно уже не программист, но как часто участвующий в собеседованиях на принимающей стороне сразу вижу проблемы:
1) единицы опенсорс проектов имеют качественный код. Это или что-то очень популярное, или раскрученное. Попасть туда, как правило, гораздо сложнее, чем в крутую компанию обычным сотрудником. Остальное же — дикость, костыли, и отсутствие контроля. Либо же какие-то самоделки, используемые 3 калеками, включая собеседуемого, его собаку и попугайчика.
2) Только в том случае, если проект раскручен и имеет большой бэкграунд и стабильную команду, постоянно над ним работающую. Попасть туда для джуна — почти нереально, так как большинству активных программистов в проекте опытнее и умнее его.
3) Либо потому что ему было скучно, или заставили в универе, например. Да, такое тоже бывыает.

В итоге, чтобы адекватно оценить опыт участия кандидата — надо изучить эти опенсорс-проекты, и вычленить его вклад туда, и опять же оценить этот вклад. Гораздо проще и экономнее по времени это выяснить на собеседовании, задав нужные вопросы.

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

Конечно нужно, в этом же и смысл. Вы можете легко открыть комиты этого человека и посмотреть что именно он делал. Посмотреть качество именно его реквестов. Если опенсорс проект состоит из дикости и костылей, и человек только увеличивал количество дикости и костылей, конечно такой разработчик вам не нужен.


Гораздо проще и экономнее по времени это выяснить на собеседовании, задав нужные вопросы.

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


С другой стороны, если это состоявшийся специалист, с большой долей вероятности он в опенсорсах не участвует по одной простой причине — ему за это не платят.

Тут думаю у каждого свой собственный опыт. Мне например нравятся мои текущие/прошлые места работы именно потому что там в рамках рабочего времени можно вносить вклад в том числе в опенсорс. Т.е. у нас либо часть проекта имеет открытый код (в последнем проекте 90% кода открыто) либо же можно тратить время на улучшения опенсорсных библиотек используемых на проекте

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

А вариант "В опенсорсе всё устраивает, не возникало необходимости контрибьютить"?

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

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


  1. Больше свободного времени на практику и изучение чего-то нового.
  2. Больше интереса к программированию.
  3. Больше качественных идей.

Выглядит разумно и справедливо.


Так же, это тревожный звоночек, что человек зациклен на одной деятельности, занимаясь одним и тем же на работе и дома — он может выгореть или сорваться в самый неподходящий момент.

Выгореть можно и без этого.


Да и вообще, пишу свою хобби-ерунду в опенсорс систематически, много и давно, полёт нормальный.

В итоге, чтобы адекватно оценить опыт участия кандидата — надо изучить эти опенсорс-проекты, и вычленить его вклад туда, и опять же оценить этот вклад. Гораздо проще и экономнее по времени это выяснить на собеседовании, задав нужные вопросы.
а в чем проблема посмотреть его коммиты/пул реквесты? Ведь проект то открытый. Это с рабочим кодом в 99,99% ответ будет — у нас NDA ничего не могу показать
Могу прокомментировать за себя.
Я jsник с примерно 10ю годами опыта в проектах совершенно разного масштаба. То есть вроде не совсем зеленый. Но любовь опенсорса некотоырми работодателями по прежнему вызывает у меня непонимание.

И вот почему:

1. Тезис «опенсорс имеет лучшее качество кода» кажется мне крайне сомнительным, если прямо не сказать ложным. Может быть в вашей экосистеме это не так, но в js громадное количество опенсорса из грязи и палок. В котором грязи больше чем палок :)

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

Да, есть много примеров опенсорс библиотек с хорошим качеством, но самые лучшие образцы кода мне попадались именно в энтерпрайзе.

2). Со вторым вашим тезисом я также не согласен. Кажется Вы выбираете лучшие опенсорс проекты а не типичные опенсорс проекты. В хороших закрытых проектах с техническим общением и код ревью тоже все в порядке.

3). С этим я согласен.
Но есть некоторая проблема — некоторые соискатели прохавали это и пытаются хакнуть этот показатель. С виду крутой гитхаб, а как посмотришь повнимательнее — коммиты в популярные пакеты состоят из исправления опечаток в документации.

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

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

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


В хороших закрытых проектах с техническим общением и код ревью тоже все в порядке.

Возможно, но вы об этом не узнаете пока не спросите. В опенсорсных проектах это сразу видно глазами.


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


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

Да, я согласен что опенсорс хорош тем что можно посмотреть/показать живой код.
Это — неоспоримое преимущество опенсорса как для нанимателя так и для нормального соискателя. Уровень легче оценить.

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

Требования опенсорса рождают проблему для нанимателя. Эта проблема — bias в сторону тех кому есть что показать. То есть мы скорее наймем среднего кандидата коммитящего в опенсорс и не наймем отличного не делающего этого.
Если это делается осознанно и вписывается в стратегию найма компании — отлично. Но к сожалению это не всегда так.

Нередки случаи когда bias в сторону опенсорса рождается из за недостаточных коммуникативных компетенций ответственного за найм. Ну то есть поручили найм инженеру который не хочет во все эти ваши софтскилз. В результате человека нанять не могут очень долго.

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


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

Ну то есть у вас на мой взгляд здравый подход к опенсорсу на собеседованиях.

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

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

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

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

Кажется в маленьких компаниях умение писать код в стрессовых условиях даже более востребовано.
То есть вы реально хотите осудить почему именно такое решение было принято лет 10 назад в коде к проекту о существовании которого человек забыл уже лет 8 как? А что если ответ будет «не помню» или «дурак был»?

Мне вот абсолютно нечего показывть поскольку мне явно контрактом запрещено прграммировать на себя (ну на самом деле надо разрешение на open source contribution брать, но это все равно что запрет). А вот программировать на бумажке совсем не обломно — я всегда уболтаю интервьювера что синтаксис не важен, а параметры «вот примерно такие, но точно не помню». Если настаивают, ну что-ж, это значит контора весьма низкого уровня. Но такого еще не было. Было что требовали гораздо сильнее математику чем я могу, но это нормально.
ответ будет «не помню» или «дурак был»

Честный ответ это уже весьма неплохо, но обычно стараемся выбрать более свежую тему а не код 10-ти летней давности.


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


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


А вот программировать на бумажке совсем не обломно — я всегда уболтаю интервьювера что синтаксис не важен, а параметры «вот примерно такие, но точно не помню».

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

Про fizzbuzz можно много про что поговорить. Вот навскидку: представьте что у вас не два условия а два миллиарда. Что делать? Представьте что каждое условие выполняется 10 секунд, а вам надо обработать поток входных чисел со скоростью 100500 в секунду. Как решать? Как все поменять если результат надо в базу писать, а не на консоль? Вариантов море! Я интервью тоже провожу, да :)

Обсуждение реальных задач тоже работает до определенного уровня. Если до уровня кода — то я например окажусь обсуждать ибо под NDA. А выше уровнем, ну так все та-же проблема отделить болтунов.

Я обычно на две части делю интервью. Быстрый тест чтобы совсем деревянных отсеять. Это вообще не программисты. Это те, кто тот-же fizzbuzz написать не могут. И вторая часть разговор по теме. там тоже есть код, но ни синтаксис ни даже ошибки в алгоритме не особо влияют если человек может объяснить что он собственно хотел. Ну и вопросы потом от кандидата, но это стандарт.
Вот навскидку: представьте что у вас не два условия а два миллиарда.

Ну если честно ваш пример усложнения выглядит немного высосанным из пальца...


Вопрос который мне реально нравится и который тоже можно долго обсуждать это например "что происходит когда вы вбиваете в адресную строку https://google.com"


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

Это почему это? Вполне рабочий пример — я про вычислительные гриды поговорить хочу. В конце концов мы именно этим и занимаемся. А пример про google.com мне ничего не даст — не web технологии. Хотя поговорить можно. На самом деле без разницы про что. Надо понять понимает человек то, что говорит или «подготовился к интервью». Кроме того еще паралеьно софт скиллз оценивается.

Помню как-то начал отвечать на такой вопрос с чего-то вроде "нажатие клавиши H замыкает пересечение двух линий"

ну на самом деле надо разрешение на open source contribution брать, но это все равно что запрет

Ух, знакомая тема, сочувствую. Я из-за этого уволился из одной компании и не принял вкусный оффер из другой.

  1. Тезис «опенсорс имеет лучшее качество кода» кажется мне крайне сомнительным, если прямо не сказать ложным.

Значит ли это, что весь ваш код лучше кода PostgreSQL, SQLite, Haproxy, etc? И djb ни в какое сравнение с вами не идет? Покажите же свой код, чтобы развеять все сомнения.

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

А вот коммиты в средней руки опенсорс — вообще ничего не гарантируют.

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

Мне это интересно как с кандидатской стороны, так и с собеседующей. Вы будете высматривать характерные (крупные) коммиты с кодом? Среди коммитов и комментариев на текущей работе (у нас, например, всякие унылые SDK, API и доки все в паблике) и среди прочих Contribution activity (не вижу там никаких фильтров). Или рассчитываете на то, что разработчик достаточно активен в опенсорсе, поэтому его коммиты легко видны?

Ок, давайте на примерах. Разработчик на дебиан/убунту через год-другой обзаводится своим репозиторием пакетов, поскольку то бэкпорт нужен, а то и вообще нужного пакета нет. К имеющимся пакетам периодически приходится слать патчи, ибо то эскулайт криво соберут (примерно так с 2005 по 2015 в дебиане все пакеты эскулайт точно были собраны через одно место), то веб-сервер вообще не работающий окажется (аол сервер годами в пакетах был поломан, потому что мантейнер не знал, как его вообще проверить). И да, обычно это обсуждается в рассылке соответствующих проектов, прежде чем мантейнеру дебиана изменения предлагать и/или свой пакет делать.
На маке — да все то же самое, только пакеты Homebrew.
Далее, для питонистов бывает нужно портировать себе пакеты Анаконда, а они собираются древним GCC (8м, если правильно помню) и, соответственно, OpenMP и OpenMPI требуют собранные тем же древним GCC и их нужно собрать и без конфликтов к нормальным системным установить… правильно, и тут нужен свой репозиторий пакетов.
И это мы еще программировать не начали — только подготовили среду для работы:) Начинаем данные готовить, для прототипа эскулайт идеальная база, закидываем туда — а оно на четырех гигабайтах данных в одном сценарии падает (реально падало, правда давно, там пачка багов была, но они мало кому мешали), а на сотне гигабайт там индексы тормозят (тоже реальный случай, пришлось сжатие индексов добавлять и долго убеждать апстрим, что им это тоже надо). Ладно, данные готовы, поставим какой-нибудь веб-сервер и Haproxy — ой, а в нем нужной директивы нет, надо патч автору послать.
В общем, к моменту написания хоть открытого, хоть закрытого кода, у разработчика уже есть свои репозитории пакетов, обсуждения в нескольких рассылках, пачка разосланных патчей в разные проекты. Имхо все проекты, рассчитанные на порядка 10 лет продакшена, примерно так начинаются — иначе нереально все это годами на множестве серверов поддерживать потом. Ну пусть у вас будут докер-пакеты вместо дебиановских пакетов, суть не меняется.

Мне кажется, вы описываете свою жизнь, а не установленный процесс поиска разработчика на проект. Давайте вёрнемся к нашим баранам. К примеру, проект — бэкенд к какому-нибудь обычному API для интернетов, с лучшими практиками, но без особой специфики. Я прихожу на собеседование, и что видят собеседующие в моём профиле Github за 2020 год:
Среди коммитов и комментариев на текущей работе (у нас, например, всякие унылые SDK, API и доки все в паблике) и среди прочих Contribution activity (не вижу там никаких фильтров).
Я примерно так смотрю профили Github и Gitlab, ну иногда получается что-то увидеть и вычленить что-то говорящее о разработчике, в своём собственном — не очень. Кстати, у многих разработчиков профиль полон ещё чем-то вроде «X commits to a private repository». Предыдущие годы смотреть, разумеется, вовсе не проще.

Профиль в Github тяжело анализировать, в общем, много бесполезного мусора, а удобную фильтрацию не завезли. Только если кандидата заранее просить показать свои выдающиеся коммиты.
Из моего опыта:

А вот из моего опыта: десять программистов в нашей небольшой компании. Отличные парни и как профессионалы, и просто как люди. Все разные, у кого-то семья, кто-то музыкант, кто-то учит китайский и т.д. У девяти из них нет ни одного вклада в опенсурсные проекты.
ИМХО, условие участия в опенсурсных проектах круто сужает ваш поиск специалистов до относительно небольшой группы преимущественно одиноких гиков, у которых хобби совпадает с профессией. Зачем?
Просто это очень натянутый критерий, как и пожалуй большая часть того, про что пишут в статьях о рекрутинге. Да, если человек покажет свои коммиты где нибудь в библиотеках фреймворках, которые мы используем, это повод к нему присмотреться, но отсутствие такового не стоит считать за минус. Слишком много возможных ситуаций, когда хороший спец просто не имеет возможности (либо желания) что либо контрибьютить. Можно даже придумать ситуации, когда вклад в opensource скорее в минус кандидату должен быть.

1) или у человека навык писать код необходимого для проекта качества, а где по факту выше в закрытом или открытом у него было, никто не знает кроме имеющих доступ к закрытому


3) или чисто практический аспект: используемая на работе либа содержала багу, сделал фикс, чтобы не ждать, отправил в апстрим чтобы не мучаться с поддержкой своего форка.

Могли бы вы более детально раскрыть свою мысль про опенсорс проекты? Из моего опыта...


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

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

Ну и что? Этот вопрос позволяет отсеять тех кто не подготовился и при этом же неспособен выдать решение сходу.
Вооще, сам факт того, что человек способен хорошо подготовиться к собеседованию и может продемонстрировать подготовку — уже плюс к решению его брать.

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

Есть возможность подготовиться к критикал багу на проде — подготовить стабильный протестированный код перед заливкой )

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


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

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

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

На собеседовании стараются оценить все ваши знания.

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


Да и по факту этого не получается. Например:


  1. Обсуждали какую-то задачу, где в качестве одной из структур данных хорошо подходил плюсовый std::deque — приятные асимптотики, дружественный к кешу, все дела. Интервьювер прямо (и немного пассивно-агрессивно) сказал, что про дек ничего не знает, и продолжал ожидать от меня чего-то. Ну я вспомнил брошюрку, которую рассылали, и которую я просмотрел вечером перед интервью, вспомнил, что там очереди упоминались — сказал про них. Интервьювер расцвел и сказал, что ему подходит.
  2. Обсуждали другую задачу, где проверка сбалансированности скобочных выражений плавно перешла в их генерацию. Я уж было начал рассказывать про то, почему алгоритм всегда остановится, как это доказывать, что за фундированные множества такие — интервьювер прервал и сказал, что это всё не нужно.

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


Оффер в этот фаанг я получил, если что.


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

То, что я не успел вспомнить, и есть то, в чём я плаваю.

Что это проверяет? Кратковременную память?

Умение понять и применить алгоритм?

Только его не просят реализовать, обращаться с ним можно как с чёрным ящиком. Асимптотики зазубрил — и вперёд. Не знаю, где тут проверяется понимание.


Умение понять алгоритм логичнее проверять, давая pdf'ку с каким-нибудь не очень известным алгоритмом и затем его обсуждая.

FizzBuzz on Java (не проблема в online найти)
Ваши же разработчики-программисты не работают в пещерах без связи с мировым пространством информации?

P.S. Можете ещё почерпнуть каких то идей по собеседованию на примерах каких то задач на rosettacode.org и возможно протестировать владение мультиязыковостью у претендента на ваши «галеры». :)
Если по теоретической части он вас устраивает, можно ему предложить 2-4 недельки подготовиться к практической части, чтобы он как-нибудь потренировался в стрессовых условиях писать код. Может тогда будет нормальный результат, если он к этому времени не найдет работу или вы другого человека не наймете.

Или другой вариант — дать кусок кода и попросить рассказать, что каждая строчка в нем делает. Если кандидат не программист, то прочитать код он не сможет. А если может прочитать код, то и написать код он тоже сможет.

И ладно бы просили решить упражнение из учебника по языку программирования для 1 курса, на 10 строчек кода.
(Если нанимают мальчика-кодировщика, это еше куда ни шло).


Но ведь есть любители подсунуть под видом тестового задания вполне рабочий законченный проектик, трудоемкостью в несколько человеко-дней. (Типа, вот сделайте, тогда и поговорим. Вдруг найдется дурачок, который согласится побыть бесплатной рабочей силой?).


И еще хорошо, если потом позвонят и сообщат что вы им не подошли.


А иногда сразу видно, что тестовое задание — это не более чем чей-то курсовой проект для ленивого студента.

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


Во-первых это не так. Человеку с минимальными умственными способностями не нужно это зубрить.

И это основной поинт: да, успешное прохождение этого теста скажет вам очень мало о кандидате. Но непрохождение скажет достаточно. А таких кандидатов грубо говоря половина. (а на junior позиции так и 90%)

Об этом собственно и речь в статье. Подобный подход очень хорошо отсекает недостаточно квалифицированных кандидатов, но одновременно с этим он с большой вероятностью отсечет и квалифицированных ребят которые по какой то причине не смогли сходу предложить решение вашей задачи. Простой пример — толковый человек может не написать сходу сортировку двухсвязного списка и потратит много времени чтобы сделать более-менее толковое решение. Исходя из этого вы эту задачу оцените условно на 3 из 5. При этом время уже будет потрачено и вы не сможете пообщаться на более сложные темы и не узнаете что человек например хорошо разбирается в работе ядра линукс или еще каких то сложных и глубоких темах которые вам возможно актуальны на текущей работе. Т.е. если вам надо чтобы на работе человек решал олимпиадные задачки — спрашивайте на собеседовании олимпиадные задачки, а если надо чтобы человек писал драйвера — спрашивайте про драйвера

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

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


ЗЫ: imho разумное количество кода – такое, чтобы его можно было написать на листочке.

имхо ТОЛЬКО испытательный срок объективно паказывает кто есть ху
всё так, проблемы начинаются, когда проект настолько большой, или сложный, что 3х месяцев испытательного может быть недостаточно. Плюс испытательный это тоже деньги.
Всегда достаточно одного месяца и 10 задач из разных областей приложения. 3-х месяцев достаточно с лихвой.
Нельзя просто так взять и дать новому человеку задачу на месяц. Давайте мелкие на день два. Фикс баг идеален.

До взятия первой задачи в работу :) Ну если не считать задачей: настрой себе окружение разработки и код почитайю

1) Многие люди в первый месяц работают продуктивнее. Но не все, чтоб это было так уж легко учитывать
2) Прям суперсложные задачи вы всё равно не дадите, а на легких только джунов отсеете.
3) В Больших корпорациях есть 1000 и 1 возможность иммитировать бурную деятельность.


Так что, бывают случаи, когда и 3х месяцев недостаточно.

Никогда, никогда, никогда не нанимайте людей, не проверив их умение писать код! Я видел миллион примеров, когда человек очень круто всё говорит, но на деле не может решить даже простейшую задачу. Если вы нанимаете человека программировать и не проверяете, как он программирует — может, что-то не так?
Тут может быть дискуссия на тему сложности задач, но они должны быть обязательны, пусть даже тривиальные. Например, вывести наиболее часто встречающийся символ в строке. Даже по этому, казалось бы, простому заданию можно многое узнать о кандидате.

Выше говорят, что и 3х мес испытательного срока кому-то не хватает. Вы же хотите сделать вывод по итогам 2-3ч (суммарно). При этом неужели бекграунд соискателя вам не поможет в этом (где и как долго работал, чего добился)?

Если за 3 месяца не могут оценить кандидата, то это чертовски странно. Возможно, стоит что-то поменять.
Нет, я говорю, что никаких выводов без тестового задания делать нельзя. То есть это минимум. Дальше уже сильно зависит от позиции, компании итп.
Бэкграунд вообще ни о чем не говорит, к сожалению — я проверял и даже писал про это в статье :)

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

Нормально — это рабочий код или как? Без шуток спрашиваю, интересно.

Через цикл и if-else решенная задача FizzBuzz — это нормально или нет? (Потому что выше человек пишет про always true, значит там как минимум не так было написано)

Чтобы это хотя бы был псевдокод, который работает. Через цикл и if-else конечно нормально, особенно если в условиях ничего не напутано :)


Условно, если бы это был код на питоне, то я бы на старте смотрел на такое:
как минимум, результат должен совпадать с требуемым
что синтаксис в принципе адекватный
цикл присутствует (хорошее место, чтобы потом спросить про генераторы и xrange/range в 2 питоне, и что делает range в 3)
что кандидат понимает концепцию деления с остатком
что в случае значения 15 будет написано и fizz, и buzz


Я понимаю, что это звучит довольно тупо, но часть кандидатов валится на таком задании! То "забыл" как в питоне функции оформляются, то в условиях намудрил, то остаток от деления проверяет, что он не равен нулю, вместо проверки на равенство. Ход рассуждений тоже важно видеть: кто сначала чуть подумал, какие варианты могут быть; кто проверил свой код, после того, как его написал.

    /**
     * FizzBuzz тест
     *
     * @param i число, которое нужно обработать
     * @return строка:
     * <li>если параметр <b>не</b> делится (нацело) на 3 или на 5 - значение парамера в строковом виде</li>
     * <li>если параметр делится (нацело) на 3 - строка "Fizz"</li>
     * <li>если параметр делится (нацело)на 5 - строка "Buzz"</li>
     * <li>если параметр делится (нацело) и на 3 и на 5 - строка "FizzBuzz"</li>
     */
    static String fizzBuzz(int i) {
       return "";
    }
Рабочий код — который проходит unit test, который разумеется есть в тестовом проекте, с которым работает соискатель.
Если тест зелёный, а код страшненький (тот же FizzBuzz с тремя вложенными if-ами, в каждом из которых куча всего наверчена), то это повод поговорить о рефакторинге — считает ли соискатель такой код хорошим, и как бы он его поменял.
Заодно становится видно, владеет ли он меню Refactoring и клавиатурными сочетаниями в своей IDE (для Java IDEA практически уже стандарт отрасли)

В Германии типичный испытательный срок равен аж 6 месяцам. И я многократно слышал истории когда человека увольняли буквально за день до последнего дня когда ещё можно уволить :) К примеру к моего коллегу так сократили в корону на его предыдущей работе.

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

Мне бы например было бы приятней и менее стресово написать с нуля микросервис, чем вспоминать что там как нужно выводить символ в строке. Причем минут за 10 можно прилично набросать уже. Потом понять что сказал не самый эффективный способ по подсчёту символов в строке, или использовал не тот метод который хотел интервьюэр, и опять нервничать :)

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

Я из тех людей, кто просит решить простую задачку на собеседовании (требуется буквально 3 строчки кода, но обычно пишут десяток). Эту задачу я с каждым кандидатом обсуждаю, предлагаю улучшения и смотрю как кандидат реагирует, знает ли о чем идёт речь, понимает ли вообще что я говорю. Таким образом, как мне кажется, я довольно точно могу поделить соискателей на три категории:
1. Вообще не знает программирования.
2. Знает общие подходы, умеет решать задачи.
3. Понимает, почему задачи решаются именно так и как это устроено.

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

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

PS: Увидел в комментариях отзывы вида «учу hashmap перед собеседованием чтобы забыть». Мне непонятен такой подход: я знаю приблизительно как он устроен (в реальном коде — тонна оптимизаций, которые не всегда нужно помнить) и когда я его использую — я принимаю некоторые допущения, которые учитываю при разработке кода. Без понимания внутреннего устройства — программист вынужден принимать решения случайным образом, что плохо сказывается на качестве кода. Это влияет не только на производительность, но и на правильную обработку граничных случаев.

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

Проверяйте личку. И да, палить условия не хочется — задачка очень нравится.

Есть например задачка найти два максимальных элемента массива. Которая легко растягивается на десяток строк.

А её тоже можно решить за 3 строчки? — За полтора десятка без проблем вышло.

$arr = [1,2,4,5,4,76,7,8,9,90,0,10];

if(count($arr) < 2){
    throw new RuntimeException('Array must contain at least two elements');
}

$max1 = PHP_INT_MIN;
$max2 = PHP_INT_MIN;
foreach($arr as $v){
    if($max1 < $v){
        $max2 = max($max1, $max2);
        $max1 = $v;
        continue;
    }
    $max2 = max($max2, $v);
}
В зависимости от языка. Но кажется, можно просто отсортировать массив и взять два последних элемента.

А в ленивых языках будет окололинейная сложность (take 2 . sort, да).

Получается, в Haskell sort как бы итерирует по k-ому большему/меньшему элементу? Я, в принципе, помню, что его можно найти за линейное время, но нужно хорошенько подумать, чтобы добиться linearithmic времени для всего массива со стабильностью.

Не то что итерирует, просто производит список, а список в хаскеле ленивый.


Условно, представьте себе, что у вас там merge sort в качестве сортировки, и вам нужно взять k первых элементов из n. Тогда на последнем шаге при мерже двух подпоследовательностей с предпоследнего шага вы потребляете k₁ элементов первой подпоследовательности и k₂ из второй, при этом k₁ + k₂ ≤ k, и ровно столько сравнений вы сделаете. На рекурсивном шаге вы тоже сделали по k сравнений для каждой из половин, в итоге суммарно вы сделаете в районе k log n сравнений.


Правда, в классическом мержсорте по списку вам всё равно придётся бегать O(nlogn) раз, чтобы его рекурсивно делить на половины, но переход к следующему элементу вроде как не считается при анализе сложности, да и в реальной реализации там какой-то более наркоманский алгоритм, делящий на необходимое количество подсписков за один проход.


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

Тогда на последнем шаге при мерже двух подпоследовательностей с предпоследнего шага вы потребляете k₁ элементов первой подпоследовательности и k₂ из второй, при этом k₁ + k₂ ≤ k, и ровно столько сравнений вы сделаете
Я может что-то не так понимаю, но на последнем шаге до мержа двух оставшихся подпоследовательностей вы уже сделали «nlog(n) — n» операций. Я думаю, что merge sort совсем неприменим, если у нас задача сделать итератор по списку как отсортированному (я так понимаю, такая задача эквивалентна ленивым спискам).

Ну может этот более наркоманский алгоритм деления и меняет всё дело. Всё же известное мне нахождение k-ого наибольшего элемента за линейное время — в какой-то мере quick sort. Просто мне не удалось быстро прикинуть, как с ним сделать лог-линейную сортировку, было любопытно, если это вообще возможно.
Я может что-то не так понимаю, но на последнем шаге до мержа двух оставшихся подпоследовательностей вы уже сделали «nlog(n) — n» операций.

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


Я думаю, что merge sort совсем неприменим, если у нас задача сделать итератор по отсортированному списку

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


(я так понимаю, такая задача эквивалентна ленивым спискам).

Да, это достаточно адекватная интуиция для данной задачи.

Может быть допустимым при определённых входных данных, т.к. для восприятия такой код будет намного проще. Не думал в этом направлении, всегда стараюсь выбрать оптимальный алгоритм.

Для начала надо уточнить, что она должна вернуть в таком случае.

Было бы логично не учитывать дубликаты, имхо. Т.е. для моего набора данных должно вернуть 10 и 11
Не логично. Согласно ТЗ — мы ищем два максимальных элемента, а не числа.

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

Если нанимать программиста для дискуссий, то на собеседовании нужно устраивать дискуссии. Если нанимать программиста для программирования, то на собеседовании надо программировать и дебажить. Стандартные задачи, конечно, не надо предлагать. Так ничего не проверить. Нужно придумывать небольшие нестандартные задачи изложенные в виде жизненной ситуации (типа «из пункта А в пункт Б выехал поезд»). Сразу будет видно, может ли человек прочитать, понять и алгоритмизировать задачу
:) Это до первого найма нового сотрудника, который очень неплохо решает задачи, но по поводу которого потом подходят твои коллеги и спрашивают, а нельзя как нибудь сделать так, чтобы с ним в одной комнате не сидеть и вообще не общаться. Увы, реальный опыт, и более чем один раз.
Естественно, говорить тоже надо. С этим никто не спорит. Я, только, против тезиса автора, что на интервью не надо программировать.

На интервью и не надо. Надо на сессии парного прогрммирования, например.

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

Вы оба профессионалы своего дела, работаете и получаете за это деньги. Нет смысла мучать вопросами, гораздо лучше поговорить о «Почему нельзя делать коммиты прямо в ветку develop?», например. Или «Как вы покрываете код тестами?»

Взаимное уважение и Вы сможете нанять кандидата мечты ;)
Есть компании вроде EPAM, которые дают сотрудникам большие лычки, делают соответствующее очень продающие CV, натаскивают на собес… Но не все из них могут решить простую задачку на интервью.
Всегда забавно слушать вопросы из разряда «чем отличается абстрактный класс от интерфейса» на позицию Senior в тот момент когда ты в данный момент работаешь на аналогичной позиции и собеседующий об этом знает.

Это забавно ровно до того момента, пока вам на собесе не попадется синьор-помидор, который в ответ спросит «а что такое интерфейс». Утрирую, конечно, но тем не менее.
Да, думаю это будет действительно забавно )

Не менее забавна, кстати. логика «А давайте опросим 1000 людей чтобы найти того самого обманщика и побьём его»

Такой Among Us на собесах ;)
Я один здесь не понимаю, как можно НЕ написать FizzBuzz? Это же совсем школьная задачка

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


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

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

На своей должности мне очень редко приходиться писать код своими руками. За прошлый год например я этим занимался в лучшем случае несколько часов. Основное время уходит на постановку задач, код ревью и митинги… Поэтому иногда даже при решении простейших задач бывают проблемы типа "забыл как написать цикл на языке Х". Понятно что если мне надо писать код я могу это быстро подглядеть в мануале.
Но на собеседовании по времени не укладываюсь, и в итоге остается наполовину рабочее решение… Это и мне неприятно и думаю производит не лучшее впечатление на собеседующих. Поэтому я вцелом горячо поддерживаю идею не заниматься программированием на собеседовании.

Зачем на собеседовании писать на языке, на котором вы забыли как писать цикл?
И почему перед собеседованием не вспомнить как писать хотя бы на одном каком-то языке?

И почему перед собеседованием не вспомнить как писать хотя бы на одном каком-то языке?

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

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

Согласен. Но иногда даже описание должности вводит в тупик. Видел на днях должность с названием "Principal Backend Engineer" описание обязанностей не содержит ни слова про программирование своими руками (на таком уровне это вцелом уже просто глупо) и вцелом 1-в-1 соответствует тому что я делал последние пару лет. Но внезапно выяснилось что эти ребята тоже расчитывают что кандидат будет писать им код в редакторе на интервью. Пришлось просто отказаться от собеседования чтобы не тратить время.

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

Вам кто-то на собесе говорил, что это плохо?

Ну и самое важное из того что тут мало обсуждается:
Собеседование это взаимный процесс, а не экзамен школьника перед преподавателем.
Если у меня будет на руках 2 оффера, на 1-м я провел условно пару часов в непринужденной атмосфере обсуждая какие нибудь интересные задачи из жизни.
На 2-м мне пришлось чувствовать себя идиотом решая идиотскую задачку в блокнотике под молчаливыми взглядами интервьювера который может решить эту задачку с завязанными глазами (потому что задает ее 5 лет подряд). Как вы думаете какой оффер я буду более склонен принять?

Что выбирать — дело ваше. Не думаю, что ваш выбор будет ограничен лишь тем, задавали ли вам задачу на собесе.

Вам кто-то на собесе говорил, что это плохо?

На собесе обычно не говорят такое, но не дают порефакторить (

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


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

По-этому надо вызубрить задачки, и постараться понравится.

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


А когда собес проводит лид/CTO или кто там ещё, потому что ему нужен человек, который решит его проблемы, то в инете он тупит только в одном случае: уже понял, что кандидат не решит его проблемы, но по какиим-то причинам сказать "спасибо, но вы нам не подходите" не может себе позволить через 5 минут после начала собеса. Кстати, предложить в такой момент решить задачку на листочке — может оказаться хорошим способом спровоцировать кандидата самому прервать собес )

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

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

Это очень плохие компании.

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

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


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

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


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

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


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

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

Давайте про историю. Открываем википедию, читаем:


Fizz buzz (often spelled FizzBuzz in this context) has been used as an interview screening device for computer programmers.[3][4] Writing a program to output the first 100 FizzBuzz numbers is a trivial problem for any would-be computer programmer, so interviewers can easily filter out those with insufficient programming ability.[citation needed]

Открываем ссылку по сноске 3:


Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.

Want to know something scary? – the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

I’m not saying these people can’t write good code, but to do so they’ll take a lot longer to ship it. And in a business environment that’s exactly what you don’t want.

This sort of question won’t identify great programmers, but it will identify the weak ones. And that’s definitely a step in the right direction.

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


Если же более сложные давать — то это уже будет какое-то тестовое задание, и (имхо) чем выше уровень разработчика, тем меньше шансов, что он станет его делать. В принципе, чтобы пообсуждать код — можно уже и прямо на собеседовании дать, вместе сначала прочитать, потом обсудить. Либо прямо на собеседовании всё же не fizzbuzz, а что-то более нормальное писать, тогда можно и посмотреть, как кандидат код пишет, как к решению задачи подходит и т.д.


Мне, например, нравится давать кандидатам написать простейший LRU-кэш. Если кандидат не знает, как он должен работать (алгоритмически) — то я, конечно, рассказываю. Есть простор для обсуждения API (в случае С++, к примеру — как обрабатывать отсутствие элемента), эффективность реализации, когда такой кэш будет плохо работать и т.д.

Имхо то, что все есть в интернете не равно тому, что вы все знаете и умеете использовать. с таким успехом можно нанимать любого человека, который умеет пользоваться браузером. И то же самое с алгоритмами: если вы не знаете их, то, встретив сложную задачу, не будете знать какие алгоритмы вам нужны, т.к. когда вас попросят решить реальную задачу, никто не скажет вам какой тут алгоритм(ы) нужен(ны).
По-моему основная проблема собеседований с решением задачек — это то, что их часто понимают буквально, как задачу на контрольной работе. Решил — 5, не решил — 2, тишина в классе! И естественно получается полный бред. И автор в статье тоже из этого предположения исходит.

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

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

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

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

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

a а давать другие задачи (более реальные и подxодящие к Вашей компании) не пробовали?
На собеседовании давать задачи на программирование, мой опыт показывает — бесполезно. Я к примеру всегда давал задачи (на пару часов, для студентов поболее работы, но попроще, часа на 4-6) до собеседования, уже по факту из выполнения решал, есть ли смысл звать на собеседование. На собеседовании уже косвенно проверял, сами ли выполнял тестовое задание, попадались списуны. В общем ну ни разу эта схема не подвела.
мы ведь не про студентов а про найм специалиста?

и списывать не получится, я наблюдаю в реальном времени как и что он делает
Есть мнение, что в местном рынке нормальный специалист тестовое делать не будет, а просто пройдёт мимо.
Когда разница между 100k GBP + bonus 20k (обычный senior в банке) и 90k + 200k bonus (точно такой-же сениор) еще и не так раскорячишься :) Тестовые задания любят хеджфонды давать, а там примерно такие зарплаты. Разумеется все по-разному и где-как, но есть и настолько жирные позиции. Их считаные единицы, и это разумеется не чистый программист, а с опытом в финансах и/или парой PhD в них-же.

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


У меня есть опыт в одной околофинансовой фирме на 190 + 50 (правда, американских бумажек), и 50 выглядели как гарантированный бонус (надо было, не знаю, менеджера на три буквы послать, разве что, чтобы их не получить). В другой фирме было 180 + 130, и это был хедж-фонд, и на эти 130 надо было действительно работать. Но в этом фонде были люди, которые бонусами добивали до окололямных зарплат (ценой работы 16 часов в сутки 365 дней в год).

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

Поделюсь своим рецептом.
Много раз собеседовал с программированием (удалённо). Техническое собеседование длится 60-90 минут. Вначале идут вводные вопросы «расскажите о себе и том, как пришли в программирование» (свободное сочинение на несколько минут). Потом серия вопросов по основному языку, на который нанимается кандидат.
После этого идёт кодирование в каком-нибудь код-шаре, с подсветкой синтаксиса. Буквально 5-10 минут, зависит от того, насколько успешно и комфортно кандидату такое упражнение. Дедлайн для себя устанавливаю в 15 минут. Если за 15 минут задача не решена до конца — прошу кандидата своими словами рассказать чего ещё не хватает.
Потом на несколько минут устраивается обсуждение результатов, прошу человека рассказать о сильных и слабых сторонах получившегося куска кода.
Всё делается в ненапряжной манере, без острой критики — в стиле парного программирования.
Зачем?
Я задаю задачи не в расчёте на проверку знания паттернов / особенностей языка / фреймворка / платформы. Более того — сразу говорю — если не помните точного наименования и / или сигнатуры нужных методов — придумайте свои, только расскажите что они должны делать.
Если конкретно по задачам — больше всего нравится предложение написать метод, подсчитывающий размер всех файлов в папке. При этом уточняю, что метод должен быть написан в расчёте на периодический возврат текущего прогресса, дабы избежать однострочных решений типа «вытащить средствами фреймворка полный рекурсивный список файлов и просуммировать их размер».
Сам механизм возврата прогресса писать не прошу, но при желании — не останавливаю. Просто указываю, что теоретическая возможность должна быть предусмотрена.
Такая задача — просто кладезь нюансов и позволяет достаточно глубоко оценить опыт и способность кодить. Рекурсивные / нерекурсивные вызовы, способы обхода дерева файлов, способы возврата результатов и многое другое.
Повидал многое. 90% кандидатов догадываются о необходимости поиска файлов в подпапках. 70-80% более-менее знают как правильно написать рекурсию. Очень редко попадаются кандидаты, пишущие нерекурсивные алгоритмы с очередями. Правильно вернуть результат сходу могут буквально единицы.
Если написан рекурсивный вариант — спрашиваю какие подводные камни у этого подхода. Вопрос не академический — на практике приходилось ловить в релизном варианте StackOverflow когда Windows формирует файловую систему с софтлинками и вложенная папка ссылается на родительскую. Спрашиваю как можно было бы этого избежать.
Параллельно могу задавать дополнительные вопросы на затронутые методы.
Это очень гибкий способ, позволяющий оценить кандидата практически любого уровня — от совсем зелёного до подкованного профи. Для каждого уровня найдутся вопросы.
Но никогда не превращаю собеседование в сплошную писанину, особенно если на бумажке. Писать код на бумажке — это издевательство над человеком, такого я избегаю. Хотя в детстве (начало и середина 90-х) сам писал код в тетрадке (дома компа не было), а потом шёл в компьютерный класс и там перепечатывал.
После практической задачи начинается следующая фаза, несколько серий вопросов на более узкие знания по фреймворкам, базе данных и т.д.
После этого небольшая серия вопросов по скраму.
В конце остаётся 5-10 минут на вопросы кандидата ко мне. Это один из самых важных этапов, так как в этот момент человек раскрывается и часто высказывает наиболее волнующие его опасения, выкладывает реальные причины прихода на собеседование (например — он просто тренируется и не занимается активным поиском нового места), и т.п.

Когда-то давно, практически в другой вселенной, ещё в прошлом веке, участвовал в найме разработчика на php. Ну с навыками администрирования, не без этого. Самой большой находкой считаю до сих пор то, что начали давать кандидатам консоль к боевому серверу с просьбой рассказать что там зачем и почему и как бы он это улучшил.


Да, кандидаты реально ходили и по коду, и по настройкам сервера. Вменяемых было на удивление мало, несмотря на заявленный опыт работы, квалификация определялась на раз. Как бы было понятно что если кандидат всерьёз обсуждает конфиги апача и mysql, да ещё и по коду может сделать разумные замечания — то он "наш человек".


К сожалению, с тех пор всё очень сильно изменилось и/или усложнилось, да и к консоли допускать стало сложней — слишком много нужно знать про внутреннее устройство в организации, чего кандидат, понятно, в принципе знать не может


З.Ы. реальный вопрос на собеседовании в одном отдельно взятом областном центре в конце 90-ых.
-А ты вот такого Ивана Петрова знаешь? (известный в том областном центре программист)


  • Да. знаю
  • А вот как ты себя позиционируешь в сравнени с ним? Ты круче программист чем он?

Одно дело когда вы в реальном проекте пользуетесь IDE и ищите решение на SoF, это помогает ускорить процесс и проверить себя. Другое когда без этих инструментов ничего не можете написать. Наверное в идеальном собеседовании должны быть затронуты разные аспекты и дать задачу на кодирование что бы посмотреть как человек над ней работает это вполне разумно. Вопрос какая конкретно задача и что вы этой задачей проверяете.
Проблема в описанная статье объясняется очень просто или же руководство не доверяет в полной мере тем кто собеседует и по этому пытается стандартизировать собеседование или собеседующему наплевать и он просто не хочет напрягаться — а что может быть проще выбрать задачу в сети прочитать её решение и расслабиться пока кандидат напрягается.)

За последние 5 лет не сдал ни одного интервью. При опыте программирования 30 лет и ктн. Плюнул на эту ахинею. Веду свой проект. ЗП в два раза больше, чем в среднем по больнице.
Лив кодинг — это самый удобный и быстрый способ проявить свои навыки программирования для умелого кандидата-программиста. Куда проще «домашнего задания» на целый день. Проще «архитектурного» интервью, где нет правильного ответа и собеседующий сравнивает со своим опытом. Проще софт-скиллового интервью, где всё вообще опирается на чуйку собеседующего. И сомнительно, что лив кодинг прям настолько плох, что в компаниях, проводящих его, работают сплошные бездарности. Как показывает реальность, в FAANG например, вовсе даже нет.
Поэтому в своей процесс собеседования его может и необязательно внедрять, но и жаловаться на чужие со стороны кандидата не вижу смысла.
Я очень много читаю здесь как неправильно проверять на собеседовании, и почти ничего на тему как правильно.
Пока вы не будете соглашаться на собеседования с программированием, найдётся куча людей которые согласяться. Если вакансия мне интересна, я не вижу проблем потратить пару часов времени. Не возьмут так не возьмут, с меня не убудет, зато я получу полезный опыт. Ну и самое главное мне просто самому интересно выяснить, справлюсь я или нет, это мой личный челлендж который делает мою жизнь интереснее :)

Опять много красивых слов, но нет конкретики, как отобрать 5-10 человек из 500 по-другому?


"Почему вы никогда не должны соглашаться на собеседования с программированием" = "Почему вы никогда не должны соглашаться работать в гугле или фейсбуке". И я таки не понял, почему я не должен.

"Почему вы никогда не должны соглашаться на собеседования с программированием" = "Почему вы никогда не должны соглашаться работать в гугле или фейсбуке". И я таки не понял, почему я не должен.

потому что создашь конкуренцию автору (или уменьшишь количество претендентов к автору)

напоминает старую шутку:


Задача по физике: как с помощью настольной лампы и очков узнать показатель преломления стекла?

Ответ: включить лампу, надеть очки и посмотреть в справочнике.
Физику, математику и инженеру дали задание — найти объём красного резинового мячика.
Физик погрузил мяч в стакан с водой и вычислил объём вытесненной жидкости.
Математик измерил диаметр мяча и рассчитал тройной интеграл.
Инженер достал из стола свою «Таблицу объёмов красных резиновых мячей» и нашёл нужное значение.
А, потом, разработчик в комманде спрашивает такой вопрос. :)
Как построить дерево для примера 10+5-4*2+3 ?
или Кто-то встречал SSE asc2Hex to integer ?

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

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


Ещё два оффера на руководящие позиции я также получил после тестовых архитектурных заданий. Код писать было не надо, а надо было придумать архитектуру для гипотетических, но понятных сервисов, интерактивно, на бумаге или доске. Оба раза интервьюеры сказали, что именно эта секция выделила меня среди других кандидатов.


К сожалению, хорошее CV и толковый разговор о технологиях говорят только о навыках составления CV и умении разговаривать.

Меня в 1 фирму на разные вакансии приглашали 3 раза, задавая приблизительно одни и те же вопросы. Я то понимал, что под предлогом интервью, хотят вытащить из меня решение, на котором у них затык. Приходилось отвечать уклончиво и разными примерами, из которых они ничего толком не могли сами для себя понять и как построить контр вопросы со своими сферическими конями. В конечном итоге им надоела такая тягомотина, руководство давит на них. Позвали меня как фрилансера, срубил с них по полной и бай.
У меня один старший и опытный коллега на одной из прошлых работ искал в std::map итератором. В следующем году на другой работе на другом проекте вместо std::set был std::vector, и содержал от десятков тысяч до миллиона записей, которые постоянно искались по значению и удалялись из середины. И это были куски кода, которые делали всю работу. Постоянно сталкивался, что проходят по immutable односвязному списку и добавляют элементы в конец другого immutable односвязного списка (сразу O(N^2) на пустом месте), используют односвязный список для поиска по значению, да полно всего. Так что если в компании не используются собеседования с кодом, то компания рискует.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
www.skillfactory.ru
Численность
201–500 человек
Дата регистрации

Блог на Хабре