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

Автор оригинала: Dr Stuart Woolley
  • Перевод
Собеседование инженера программиста сегодня часто включает в себя некий тест или упражнение на программирование, и я думаю, что это очень плохая вещь. Вот почему.




Ленивые тропы


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

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

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

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

Память


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

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

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

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

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

Общие задачи


Кое-что я уже затронул: это максима — не изобретайте колесо. Например, если вы работаете на языке Си и вам нужна процедура последовательного порта, не пишите её с нуля, если только ситуация не требует этого. Возможно, вам нужен парсер JSON, очень распространённое требование — если только вы не пишете код на встроенной плате с ограниченным ресурсом, для спутника на геостационарной орбите или в Malbolge; тогда, возможно, вам стоит просто вытащить из библиотеки то, что уже написали. Скорее всего, код уже давно применяется, он полностью протестирован и имеет подробную (и корректную) документацию. Он надежен.

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

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

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

Дискуссия. Дискуссия. Дискуссия


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

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

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

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

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

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

Подведем итоги




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

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

У других есть обобщённые «тесты способностей» для определённых языков, тесты со множественным выбором, где в ограниченном времени намёк на туман в голове означает, что вы завалили собеседование!

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

Если вы, как я, старше и опытнее, пусть нанимающая компания просто поговорит с вами. У нас много опыта, мы многое видели и делали, квалификацию ясно видно в резюме и CV. И я возмущён тем, что меня направляют по общему конвейеру найма и многократно проверяют мои способности.

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



image



SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Похожие публикации

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

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

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

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

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

                0

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

                  +1

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

                    +4

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

                      0
                      Это функциональный менеджмент?
                        0

                        незнакомый термин

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

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

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

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

                          0

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

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

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


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

                                0

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

                                  0

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

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

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

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

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

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

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

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

                              0

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

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

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

                                  0

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

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

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


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

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

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


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

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

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


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

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


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


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

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

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


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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                      0

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

                                +1

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

                                  +1

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

                                    0

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

                                  +17
                                  а потом люди не могут ответить на собеседование, в чем будет проблема если написать
                                  public int hashCode() {
                                          return 9;
                                  }
                                  
                                    0
                                    Это типовой вопрос, его можно выучить. То есть Вы оцениваете только факт подготовки кандидата к собеседованию.
                                      +3

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

                                        +8

                                        Зачем его учить?

                                          –1

                                          -

                                          +11

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


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

                                          Ваш ход.

                                            +5

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

                                              +2

                                              Разве так можно?

                                                +5

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

                                                  0

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

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

                                                    Вот интересный вопрос на stackoverflow на эту тему:
                                                    ru.stackoverflow.com/questions/930894/Кастомные-ключи-в-словаре
                                              0
                                              прошу прощения за то, что влез
                                              следующий ход:
                                              -XX:hashCode=2
                                              0

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

                                                +4
                                                Java
                                                  +2

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


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

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

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

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

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

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

                                                        0

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

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

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

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

                                                  да


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

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


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

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


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

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

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

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

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

                                                        P.S. Вообще-то, код HashMap'ы и т.п. классов легко можно увидеть в той же IDEA, если вам любопытно как все там устроенно. И код там относительно простой.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                      +2
                                                      O(N) не будет, будет O (logN), при миллионе объектов будет дерево а не лист
                                                        –1

                                                        Да, согласен поспешил с ответом

                                                          +7
                                                          Очень надменным выглядит ваше утверждение про «я прекрасно знаю как работает equals и hashCode», и немного неуместным на фоне ошибки оценки сложности.
                                                            0
                                                            В контексте моего ответа, сложность O(log(N)) потому я говорил о большом количестве данных, но по факту сложность O(N) тоже правильная, ибо она может быть когда у всех объектов в бакете один хешкод(как раз обсуждаемый кейс) и не достаточно много объектов что бы использовать TreeNode
                                                            и немного неуместным на фоне ошибки оценки сложности.
                                                            я уже признал выше что мне нужно было более точно расписать.

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

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

                                                            –1
                                                            я прекрасно знаю как работает 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() » может быть вполне адекватным.
                                                              +1
                                                              выберут какой-нибудь LinkedList,

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

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

                                                              Из мира Java это примерно как профессиональный водитель будет гуглить правило проезда равнозначного перекрестка, так как на правильном использовании hashCode и equals построенно практически все в языке.
                                                                0
                                                                LinkedList настолько плохая структура, что половина коллекций в Java использует его в той или иной степени.
                                                                Плохому танцору…
                                                                  –1
                                                                  LinkedList настолько плохая структура, что половина коллекций в Java использует его в той или иной степени.
                                                                  плохо что вы не видите в этом проблемы
                                                                    +1
                                                                    половина коллекций в 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. Подробнее о коллекциях я писал тут.
                                                                      –3
                                                                      Сможете перечислить эту самую половину коллекций?

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

                                                                      Плюс любой функционал туда-сюда, типа истории действий, тоже так или иначе будет основан на Linked List
                                                                        0
                                                                        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 (именно из-за производительности).
                                                                          –2
                                                                          Я так то говорю за структуру данных, а не за реализацию LinkedList в java.util
                                                                          Бинарная куча — это массив? Ну здрасте.
                                                                          Вы можете получить доступ к крайним элементам ветки в кучи по индексу?
                                                                          Вы можете получить доступ к любому элементу куче без необходимости пройти от корня?
                                                                          Какой это массив? Это и есть в некотором смысле связные списки, только со ссылкой не на один следующий элемент, а на два.
                                                                            +1
                                                                            Бинарная куча — это массив? Ну здрасте.

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

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

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

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

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


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


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


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

                                                                      +1
                                                                      Чтож, вот мой контрибьют в одну большую библиотеку. Не самый сложный и не самый простой функционал. Что вы как потенциальный работодатель можете из него вынести? github.com/microsoft/microsoft-ui-xaml/commit/2ec9b1cdc15c3aa3d459b926f7e4888234b30387
                                                                        0

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


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


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

                                                                          +12
                                                                          Вот только код написан на C++ :) (+ тесты на C#)
                                                                            0

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

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

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

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

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

                                                                          0

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


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


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

                                                                            +1

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


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

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


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

                                                                              0

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

                                                                                0

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


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

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

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


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

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

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

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

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


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

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


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

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

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

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

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

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


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

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


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

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


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

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

                                                                              И вот почему:

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

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

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

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

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

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

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

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


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

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


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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                  Могу и вам предложить мой коммит https://habr.com/ru/company/skillfactory/blog/538240/#comment_22568182
                                                                                                  Если вы, конечно, тред тот не прочитали.

                                                                                            +5
                                                                                            Из моего опыта:

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

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


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

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


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

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

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

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

                                                                                                      –1
                                                                                                      Есть возможность подготовиться к критикал багу на проде — подготовить стабильный протестированный код перед заливкой )
                                                                                                        +1
                                                                                                        Только тот код без багов, который ничего не делает.
                                                                                                      +12

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


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

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

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

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

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


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


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

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


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


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

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

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

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

                                                                                                            +1

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


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

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

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

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

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


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


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


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

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


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

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

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

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

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


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

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

                                                                                                                    Только до первой задачи может месяц пройти.

                                                                                                                      0
                                                                                                                      Нельзя просто так взять и дать новому человеку задачу на месяц. Давайте мелкие на день два. Фикс баг идеален.