Программисты не могут написать алгоритмы без помощи: ещё раз про интервью

    Дэвид Хэнссон, создатель Ruby on Rails, признался в своём твиттере, что не написал бы сортировку пузырьком на доске. Дэвид подсматривает код в интернете всё время:

    image

    Его поддержали многочисленные коллеги:

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

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

    Итак, две трудности:

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

    2) Вторая трудность является следствием фундаментальной особенности цифровой эры. Поясню на маленьком примере.

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

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

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

    Ровно о же самое можно сказать и о знаниях в программировании. Положа руку на сердце, каждый может признаться: он рано или поздно подзабывает какие-то вещи, принятые относить к Основам. Например, любой хороший курс по JavaScript включает себя понятие ООП, раскрытие темы наследования, создания «классов» и так далее. Однако в современных проектах, особенно основанных на фреймворках, программист напрямую использует ООП-парадигмы в написании своего кода не так часто. Не так часто, как спрашивают ООП на интервью при приёме на работу (а его любят спрашивать практически всегда). Естественно, возникают коллизии между тем, что есть на самом деле, и тем, что ты, как тебе кажется, твёрдо запомнил (и успешно забыл).

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

    По этой теме у буржуев, кстати, есть исследования. Например, вот это.

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

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

    Подробнее
    Реклама
    Комментарии 741
    • +5
      На собеседованиях не требую синтаксической правильности, сразу говорю, что пишите псевдокод похожий на целевой язык. И не требую проверки всех граничных условий. Но прошу назвать некоторые, которые кодом не предусмотрены. В общем, относитесь к людям так, как хотите, чтобы они относились к вам. Гуглом пользоваться запрещаю.
      • 0
        Граничные условия — это, кстати, хороший «дополнительный вопрос».
        • +26
          В реальной работе тоже запрещаете?
          • –34

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

            • +10
              «Вы так говорите, как будто это что-то плохое»(с) ))
              • +6
                Что именно? Что человек не способен ни на что кроме СОДД? Мы ведь еще про собеседование говорим?

                А чтобы понять, что решение на СО подходит для специфики — это тоже можно нагуглить? А недостатки решения, о которых не сказали, потому что для примера автора это не недостаток, а для нашего приложения это критично тоже на СО нагуглится?

                Я пять лет собеседовал людей в свою команду для разработки игр на js в Варгейминге. И я знаю, что большинство решений на СО нельзя вставлять в свой код без предварительной подготовки?

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

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

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

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

                Может для типичных сайтиков бездумный СОДД вполне подходит. А в чем-то менее типичное всегда есть своя специфика.
                • +5
                  Ну, тут не только люди с «другой» стороны баррикады.
                  Просто вы очень уж жесткую позицию занимаете.
                  В мире интернета, да без гугления?
                  Да и такое пренебрежение «для типичных сайтиков бездумный СОДД вполне подходит».
                  Почему же бездумный сразу? А вы попробуйте наклепать типичных сайтиков. Та еще работенка.
                  Не вижу ничего плохого в гуглении.
                  Это как была у нас бабушка, преподаватель высшей математики в институте.
                  Да, пользуйтесь, говорит, учебниками на экзамене, на здоровье, только сумейте задачи решить.
                  Ну да, будет по первой гуглить (если ближе никто не может отвлечься, что бы подсказать), потом будет гуглить меньше и меньше.
                  Хотя речь про таких себе «синьоров», которые прямо таки должны все знать. :)
                  Я правда по БД, обычно в новой команде больше времени уходит, что бы структуру базы уяснить, чем на гугление.
                  • +2

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

                    • 0
                      Согласен.
                      • 0

                        Только на письменных. На устных нельзя.

                        • 0
                          не буду спорить, давно все ж было. но на устных тоже на определения/стандартные решения вопросов вроде не было никогда, скорее «ну на билет вы ответили, это ясно, давайте-ка просто поговорим». тут уж никакой учебник не спасет.
                          но это наверное оффтоп злостный уже.
                        • +2
                          На собеседовании Вас не просят вспомнить алгоритм. Вас просят его реализовать. Это простая проверка Вашей способности выразить что-то простое на целевом ЯП.
                          Если Вы решили вспоминать алгоритм на собеседовании — Вы, скорее, его завалили. ИМХО.
                          • 0

                            Ну и проверка на адекватность. Если не помнишь, то нужно просить описание алгоритма, а не пытаться натужно его вспомнить.

                            • 0
                              не знаю, на чем вы пишите и какие задачи выполняете, но я тоже не помню когда последний раз писал сортировку пузырьком(наверное школе), но я легко могу восстановить алгоритм, т.к. его не нужно помнить если понимаешь его суть.
                              • 0
                                Это потому что сортировка пузырьком — наивный алгоритм. А сможете описать суть например БПФ?
                                • 0
                                  А сможете описать суть например БПФ?
                                  Вы о простом "разделяй и властвуй" подходе? Собственно этих слов плюс пары наводящих вопросов должно быть достаточно для приличного программиста, чтобы реализовать БПФ.

                                  Хотя для интервью (волнение, руки дрожат, голова «кипит») это всё же сложновато IMO.
                                  • +1
                                    Возможно, распишусь в собственной неполноценности, но думаю, что для меня этого было бы недостаточно. И не думаю, что это так уж плохо. В конце концов, программисты в реальности сильно отличаются от голливудских программистов. Никто и никогда не сидит с таймером, чтобы в последние десять секунд успеть написать квиксорт, чтобы остановить ядерный взрыв (или даже задеплоить хотфикс). Если программисту для подобных вещей надо будет заглянуть в гугл, это не страшно, на мой взгляд.
                                  • 0
                                    Если Вы о преобразовании Фурье, то с точки зрения математики, еще не успел забыть с университета, а вот с точки зрения программирования мне не приходилось сталкиваться, сомневаюсь, что я решил бы эффективно подобную задачу, без подглядывания в умные книжки.
                                  • +1
                                    Собственно, я именно это и сказал =) Необходимости помнить эти алгоритмы — нет. В ряде случаев даже нормально не знать их суть. Например, требовать от JS-программиста знать суть QSort/MergeSort/etc — очень странно. Но если он не смог за полчаса ни один алгоритм сортировки сочинить… Ну я бы не хотел с таким JS-разработчиком работать.
                            • 0
                              СОДД — что это?
                              • 0
                                СтекОверфлоу-дривен-девелопмент
                                • +1
                                  Драйвен же!
                                  • +1
                                    Таки дривен. На русском английском — иногда «драйвен» (от создателей «ихнего» и «егойного»).
                              • +5
                                Насчет типичных сайтиков и бездумного SODD.

                                К примеру, реальная задача: есть легаси REST сервис, который крутится на Tomcat и есть HTTP-клиент для этого сервиса. Вместо русского текста: сервис возвращает краказябры, клиент возвращает краказябры, в логах краказябры. Поэтому нужно начать везде использовать UTF-8 и проверить, что это действительно так.

                                Как решал бы здоровый человек — убедился бы, что:

                                1. БД использует правильный collation (ага, гуглим какой для кириллицы: Cyrillic_General_CI_AS);

                                2. JDBC-драйвер использует UTF-8 (ага, гуглим параметры инициализации: useUnicode=true;characterEncoding=UTF-8);

                                3. установил кодировку сервлета в параметрах Tomcat (снова гуглим, выясняется: URIEncoding="UTF-8" в настроечном файле);

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

                                5. и вишенка на торте — ставим везде UTF-8 в логах:
                                <encoder>
                                  <charset>UTF-8</charset>
                                <encoder>
                                


                                На все ушло порядка 10 минут, с проверкой на каждом этапе. А вы здесь говорите про «бездумное гугление». Я понимаю, для кого-то не проблема переключить в голове пять разных технологий, но блин. Кто-то пишет калькуляторы, а кто-то — компиляторы. Это нормально.
                                • 0

                                  По сути это всё не задачи разработчика, максимум вынести параметры инициализации в конфиги.

                                  • 0
                                    Вот игра в responsibility-ping-pong отнимает в разы больше времени чем гугление.
                                    • 0

                                      Я про то, что это не SODD, задача к разработке мало отношения имеет, это диагностика проблемы эксплуатации.

                                      • 0
                                        Не важно. Так же могут придираться к работе админа. Мол, ты должен все настройки по памяти помнить. Ну или встроенный man читай. Если начал гуглить — провалился.
                                  • 0
                                    Кто-то пишет калькуляторы, а кто-то — компиляторы.


                                    Классная фраза, я бы взял как заголовок даже.
                              • +19
                                Я и сам предпочитаю досконально изучить какой-либо вопрос, а не пользоваться поверхностными ответами. Но мои желания и мои возможности не всегда совпадают. Стековерфлоу дривен девелопмент экономит уйму времени, не только когда нужно быстро что-то вспомнить, но и когда сталкиваешься с «неизвестной территорией». Мы живём в конкурентном мире. Если вы не станете пользоваться имеющимися средствами экономии, за вас ими воспользкются ваши конкуренты.
                                • +1
                                  А если собрать команду, которая без гугла шагу ступить не может, то вам потом сольют репутацию, заберут назад деньги и ничего не купят несмотря на то, что вы зарезились раньше конкурентов и в удачную дату.

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

                                  Не забывайте, мы сейчас говорим именно про собеседования.
                                  • +2

                                    "Если разработчик неспособен без СО даже поговорить на собеседовании с другим технарем" — мне кажется такой разработчик и на СО вопрос сформулировать не сможет.

                                    • +4
                                      А что, в приведенном вами примере про Бетмена, была именно такая команда, которая без гугла шагу ступить не могла? Вы это точно знаете? Если да, расскажите. плиз, интересно.
                                  • +37
                                    Долго ждать результата будут, если НЕ лезть в Google.
                                    Если вы считаете иначе — либо у вас феноменальная память, либо слишком простая работа.
                                    • –8
                                      Вы б посмотрели мои статьи, что-ли, перед тем, Как предположения делать
                                      • +9

                                        Посмотрел. Согласился с предыдущим оратором.

                                    • +8
                                      Всегда казалось, что в наше время 80% навыков программиста/инженера – умение думать и добывать необходимую для задачи информацию, и только оставшиеся 20 – знания какого-либо языка или технологии. ИМХО, конечно.
                                      • +1
                                        Зачем вы подменяете понятия «умение думать» и «умение нагуглить ответ на вопрос»? Как раз никто не приносит с собой на собеседование ноутбук и не предлагает пользоваться гуглом, потому что хочется проверить умение думать.

                                        Или вы думаете, что я, как собеседующий — это такой робот, который сверяет, совпадает ли ответ с листочком и если нет, то отказывает даже талантливому кандидату?
                                        • +4
                                          Простите, конечно, но с каких пор умение искать и добывать информацию в доступных источниках перестало быть умственной деятельностью? Честно, я не представляю разработчика, который был бы высококлассным специалистом и при этом бы не пользовался на работе гуглом.
                                          • +2
                                            Простите, конечно, но с каких пор умение искать и добывать информацию в доступных источниках перестало быть умственной деятельностью?

                                            Конечно умственная, но это то что отличает инженера от кодерочка.
                                          • +1
                                            Ходил на собеседования с ноутбуком. Сажали в комнату на 40 минут с Wi-fi и гуглом и просили написать код для алгоритмической задачи. Это и есть проверка умственных способностей инженера: из подручных средств собрать работающее решение конкретной проблемы.

                                            Да и вообще — полным полно таких задач, на которые было бы неплохо найти хоть какое-нибудь решение, а потом уже его совершенствовать.
                                            • –1
                                              > Зачем вы подменяете понятия «умение думать» и «умение нагуглить ответ на вопрос»?

                                              Я думаю есть вопросы над которыми надо думать, а есть вопросы, которые надо гуглить. И это разные вопросы. Вы на собеседовании какие задаёте?
                                              • +3
                                                Я думаю есть вопросы над которыми надо думать, а есть вопросы, которые надо гуглить. И это разные вопросы

                                                Ну так «в продакшене» и на собеседовании требования к вопросам различаются. Тот же «написать алгоритм чего-то» в боевых условиях предполагает нагуглить и проверить реализацию, а на собеседовании означает «пошевелить мозгами и придумать реализацию самому».
                                                • –2
                                                  > требования к вопросам различаются

                                                  К ответам?

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

                                                  Задавать вопросы на собеседовании — это как KPI выставить. Что попросите, то и получите.
                                                  • +3
                                                    К ответам?

                                                    К вопросам.

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

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

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

                                                      В целом, велосипедостроитель — профпригодный программист. Не эффективный, но профпригодный.

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

                                                      > Взрослый человек переживёт, не помрёт.

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

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

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

                                                        А если вы приходите, видите обычный офис, 24" мониторы, и у вас просят написать алгоритм — вас это меньше пугает, чем тёмный подвал и 17" мониторы?

                                                        Ну конкретно написать хеш-таблицу — это не странный, но очень скучный вопрос.

                                                        Ну извините. Если что, попросите собеседующего рассказывать вам анекдоты ;)
                                                        • 0
                                                          > и даже банальный пузырёк люди обычно выводят, а не вспоминают.

                                                          Лично мне хватает хитрости притвориться, что я «вывожу» )

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

                                                          > А если вы приходите, видите обычный офис, 24" мониторы, и у вас просят написать алгоритм — вас это меньше пугает, чем тёмный подвал и 17" мониторы?

                                                          Да, меньше. Но при прочих равных, что я пойду работать не туда, а в офис класса А с 2 27" мониторами. И где анекдоты рассказывают. И смузи на халяву
                                          • +8

                                            Вступлюсь за TheShock. Человек, вообще-то дело говорит.


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


                                            Зазубрить 3 разных алгоритма — круто, но бесполезно, если не знать, что такое, узко говоря, вычислительная сложность, а широко говоря — теория алгоритмов.


                                            И в этом кардинальный минус СтекОверфлоу-дривен-девелопмента. Люди собирают куски кода, лепят всё вместе, но не понимают почему, например, в финансовых операциях (и то — не всех) нужно использовать банковское, а не математическое округление: какое было в найдёном примере — то и возьмут.
                                            Каждый второй новоиспечённый гэймдевелопер — это вчерашний дизайнер. Эти ребята проходят недельный курс С++, находят какую-нибудь биржу кода и контента, лепят лепят, а на выходе получают эффективный прожигатель заряда акума телефона. Им невдомёк, что сцена отрисовывается в несколько слоёв не просто так, а для повторного использования многих слоёв в последующих кадрах. Им — пофиг. Ведь можно взять куски кода, слепить их… уяк, уяк — в продакшн!
                                            Они думают, что NoSQL решения реально круче RDBMS. Потому что маркетологи им так сказали. А спроси их что такое RDBMS? "британский бойз-бэнд, да?"


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


                                            Кто смотрел сериал "Друзья", вспомнит отличную зарисовку: Джо взял хорошо написанное письмо, и каждое слово заменил тезаурусом на синоним. Каждое, отдельно от контекста. Получилась белиберда, хотя и смешная (https://www.youtube.com/watch?v=yGR78nzyznM).
                                            Такой же нелепый результат получается и при использование СО/гугл, обладая лишь поверхностными знаниями. Продукт получается, вроде бы как проходящий по спецификации, но воняет жутко: мобильный апп — батарею сжирает, сайт визитка — проц на 100% загружает, сервер — дедлокит...


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

                                            • +5

                                              Совершенно верно, есть большая разница между "помнить" и "понимать".


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


                                              @TheShock просто неудачно сформулировал свою мысль, уверен, что он имел ввиду не такую ситуацию, а именно тупой копипаст с SO.

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

                                                Возможно в нашем мире задач требующих такой уровень столько нет?
                                                Поэтому и проходит оптимизация, как и везде, в этой жизни.
                                                Не требуется столько краснодеревщиков. Не все отращивают мышцы, как у Шварца, не все могут водить автомобиль, как гонщик Формулы… и т.д. Просто на всех не хватит такой работы, да может и не всем дано.
                                                Зато вот «сайтики» или мебель стандартную, выпускают очень много людей.
                                                Мир стремится достигнуть большего, при меньших затратах. Этот закон везде работает.
                                                Ну, в самом деле, посадите TheShock клепать сайтики.
                                                Он окажется не эффективен для этой работы, по параметру цена/качество, потому, что слишком дорого стоит.
                                              • 0
                                                Не пойму понять, что за «СтекОверфлоу-дривен-девелопмент». На stackoverflow не принято просить, чтобы за тебя писали код или реализовывали какой-то функционал (помимо минусов, которые сразу прилетят, это напрямую противоречит правилам форума). На моем опыте, на SOF чаще всего обращаются с просьбой найти конкретную ошибку. Не уверен, что искать ошибку самому это всегда сильно быстрее, чем найти аналогичную ситуацию и ее решение (сильно сомневаюсь).
                                                • +3
                                                  Имеется ввиду нагуглить решение в виде вопроса и чьего то ответа на so, а потом его тупо скопипастить.
                                              • +5

                                                Нет, конечно. Но там есть требование писать синтаксически правильный код :)

                                                • +9
                                                  Честно говоря, это разные вещи. Я, когда собеседую человека, тоже прошу написать алгоритм сортировки, и не даю пользоваться гуглом. И это я делаю не потому, что мне интересно, знает ли он алгоритмы сортировки. Мне не это интересно. Наоборот, я уверен, что кроме вчерашних студентов, их никто наизусть не помнит. Мне интересно, может ли он *придумать* алгоритм, т.е. умеет ли человек вообще программировать.
                                                  То, что он в реальной жизни сможет нагуглить сортировку, это и так понятно. А вот нагуглить алгоритм работы контроллера насосной станции, которые мы изготавливаем, он не сможет. У него будет блок-схема от инженера-гидравлика, и ему самому нужно будет сочинять алгоритм работы машины состояний и т.д. Вот это я и хочу увидеть на примере сортировки массива, способен ли человек взять задачу, разложить её на шаги и запрограммировать.
                                                  • –2
                                                    Не стебусь, но что даже в компанию, где пишут софт для насосов у вас есть возможность выбирать из нескольких кандидатов? Или вы спрашиваете про сортировку, и не важно отвечает или нет — все равно принят?
                                                    • +7
                                                      Ну а чем софт для насосов принципиально отличается от софта, например, для смартфонов? Тем, что у такой установки разрешение экрана не FullHD, а всего 320х480 (я тут тоже не стебусь), и она не поддерживает блютус? Позвонить на неё, кстати, в принципе можно :) Она имеет ADSL-модем для телеметрии.
                                                      Мы же на эти задачи ищем не программистов с опытом работы с насосами, а программистов, имеющих опыт программирования микроконтроллеров. Обычное программирование промышленных контроллеров, ничего военного и уникального.
                                                      • 0

                                                        Навскидку я писал непубличный софт для:


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

                                                        Это не считая "сайтиков", краулеров, конверторов и т. п., где предметная область по сути чистая информатика — взять информацию в одном виде и показать/сохранить её в другом. И без них минимум с десяток программно-аппаратных платформ (включая гетерогенные сети на экзотических ныне основах) по 2-3 языка на каждую часто.


                                                        Неужели думаете, что какие-то насосы (пускай даже несущие угрозу миллионам людям) меня испугают, а DrPass откажет мне лишь потому, что у меня нет опыта работы конкретно с насосами?

                                                  • –1
                                                    +1. На доске код можно писать очень сокращенно, если все детально устно комментировать. Например, для js и разговора о композиции вполне пойдет такой код:
                                                    cl Dog ext Anim (
                                                      eat(IMeal meal)
                                                       list.add(meal)
                                                    
                                                      bool isHungry()
                                                        ret list.len == 0
                                                    )
                                                    


                                                    С точки зрения языка тут много ошибок, но если вы понимаете тему настолько, что можете устно объяснить ее — это очень легко.
                                                    • –1
                                                      Конечно, Если речь о разговоре хотя бы на мидла или синиора и понятно, что синтаксис человек знает. Никогда джунов не нанимал, а там слегка другие законы, но вполне возможно, что мне бы захотелось проверить, что человек правда знает основы синтаксиса.
                                                      • +8
                                                        Сортировку я писал последний раз в 2005 году, на Pascal.

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

                                                        После 12 лет в деле, написать сортировку на доске звучит как оскорбление. Вам надо сортировки писать, или вам нужно что-бы кто-то исправил ваше приложение, которое заваливает 5 серверов, где должен справиться 1 веб сервер + сервер базы данных?
                                                        • +3
                                                          вам нужно что-бы кто-то исправил ваше приложение, которое заваливает 5 серверов, где должен справиться 1 веб сервер + сервер базы данных?
                                                          Нам нужно чтобы «кто-то» не создавал приложение, которое заваливает 500 серверов притом что задача, которую он решает, может быть решена и одним.
                                                          • +3
                                                            Если вы ищите человека по алгоритмам, вы пишите это в объявление о найме, а не говорите об этом на собеседовании.
                                                            К тому же, если мы говорим о 500 серверах, то о сортировке пузырьком спрашивать вообще глупо.

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

                                                            Я не работаю с алгоритмами, я не планирую с ними работать и лезть в науку или обработку огромных массивов данных — это не моя область. Если мне понадобится это делать — я найму специалиста, который этому посвятил свою карьеру.
                                                            • +1
                                                              Я не работаю с алгоритмами, я не планирую с ними работать и лезть в науку или обработку огромных массивов данных — это не моя область.
                                                              Если бы все были так честны и не пытались устраиваться на software engineerа обладая знаниями application engineerа — мир был бы гораздо светлее. Но, увы, в реальном мире это не так.

                                                              К тому же, если мы говорим о 500 серверах, то о сортировке пузырьком спрашивать вообще глупо.
                                                              Почему глупо? Вы можете себе представить человека способного создать распределённую сортировку на кластере в 10000 машин, но не способного написать пресловутый «пузырёк»? Я — нет. Никто же не говорит о том, что вы должны уметь писать только пузырёк!
                                                          • +2
                                                            За всю мою карьеру мне каким либо алгоритмом, который нужно было реализовать самому, пришлось сталкиваться 2 раза.

                                                            Простите, а кем вы работаете? Не программистом же, ведь бОльшая часть работы обычного программиста и состоит в реализации алгоритмов, когда поданных сверху, когда придуманных самим. Весь написанный нами код (по крайней мере императивный) и является записью алгоритмов в конкретной нотации, будь то PHP, C, Assembler или Python, записью последовательности действий по достижению нужного выходного состояния при определенном входном.

                                                            • 0

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

                                                              • 0

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

                                                                • 0
                                                                  * Придумать конечно означает придумать как реализовать и реализовать. Разговор ведь про программирование.

                                                                  Я о том, что «реализовать алгоритм оформления заказов» и «реализовать алгоритм сортировки с вот такой сложностью» это разные понятия «реализовать алгоритм». Первая бизнес-задача, вторая техническая. Реализации первых используют реализацию вторых. И вот реализацию вторых во многих случаях делать не надо, потому что они уже есть в виде библиотек или встроенных возможностей.
                                                                  • +1
                                                                    Я о том, что «реализовать алгоритм оформления заказов» и «реализовать алгоритм сортировки с вот такой сложностью» это разные понятия «реализовать алгоритм». Первая бизнес-задача, вторая техническая.

                                                                    Вообще, нет. Это просто разные предметные области. А суть работы одна и та же. Может быть, сложность конкретной задачи отличаться. Причём не факт, что оформление заказов будет проще — например, если в процессе присутствует функция расчета автоматического дозаказа.
                                                                    • 0
                                                                      А суть работы одна и та же.

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


                                                                      Причём не факт, что оформление заказов будет проще

                                                                      Вот про это многие и говорят, а другие говорят, что это и не программирование вовсе)

                                                                      • 0
                                                                        Если бы это было так, никто бы не давал задачи на алгоритмику. Проверяли бы только ООП и умение закодить задачу.

                                                                        Следует различать задачи на алгоритмику ("реализовать сортировку с временной сложностью O(n*log n)", "реализовать воркфлоу заказа с такими-то ограничениями"), то есть на придумывание или поиск готовых алгоритмов, и задачи на реализацию готовых алгоритмов ("реализовать сортировку массивом пузырьком", "реализовать воркфлоу заказа конечным автоматом с таким-то графом переходов статуса заказа")

                                                                    • 0

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


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

                                                                      • 0

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

                                                                        • 0

                                                                          Как кандидат реально сталкивался с ситуациями когда даётся название, а полное описание по вопросу: "деталей не помню, вам по памяти писать или не тратить время вообще"? Подход понравился, использую теперь с другой стороны баррикад :)

                                                                    • +1
                                                                      Заменим «алгоритм сортировки» на «алгоритм хеширования», И вот уже 90% программистов отсеивается из программистов.
                                                                      Заменим на «алгоритм шифрования», желательно каким-либо более устойчивым, чем SHA1, и останется 1% тех, кто собственно работал в разработке алгоритмов шифрования.

                                                                      Давайте не будем цепляться к словам — понятно же, что человек писал не об алгоритмах вообще, а именно о технических алгоритмах, которые есть не на SODD а в виде best practice.
                                                                      • +1

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

                                                                        • +1
                                                                          Я еще пойму, если нужно написать простейший работающий алгоритм пузырьковой сортировки. Его действительно можно использовать.

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

                                                                          В общем окей, у каждого свое видение как подбирать команду.
                                                                          • 0

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

                                                                            • 0

                                                                              И снова, соль — это не про шифрование, а про хеширование. Уже стоит задуматься, хотел ли бы я с вами работать. А то вот так спросишь про шифрование, а тебе про соль, коллизии и SHA1 толкать начнут...

                                                                            • 0

                                                                              Устроят ли тогда такие ответы: сортировка — пузырёк; хэширование — разбиение данных на блоки по 4 байта и последующий XOR, шифрование — XOR 4-байтных блоков с фиксированным ключом?


                                                                              Или нужно блеснуть знаниями и вспомнить, как вычисляется MD5 или SHA1, вспомнить, как работают RSA и AES? Особенно при условии, что на практике будут использоваться только библиотечные реализации этих алгоритмов.

                                                                          • +2
                                                                            Заменим «алгоритм сортировки» на «алгоритм хеширования», И вот уже 90% программистов отсеивается из программистов.
                                                                            Заменим на «алгоритм шифрования», желательно каким-либо более устойчивым, чем SHA1, и останется 1% тех, кто собственно работал в разработке алгоритмов шифрования.

                                                                            SHA1 как раз алгоритм хеширования, а не шифрования.
                                                                            • 0

                                                                              И тут вдруг обнаруживается, SHA1 — это алгоритм хеширования, а не шифрования… Фейл.
                                                                              UPD, а, уже сказали. Ну ладно, будет ещё раз.

                                                                  • +36
                                                                    Мне кажется умение делать исследование вопроса — лучшее качество для разработчика. Например можно понаблюдать как человек это делает. Выбирает первый попавшийся ответ или сравнивает с другими. Сверяется ли потом с документацией. Правильно ли задает вопросы? Может ли объяснить ответ, который он выбрал. Поделитесь пожалуйста, что за мотивация запрещать гуглить?
                                                                    • +6

                                                                      как жаль, что таких людей мало среди интервьюеров =)

                                                                      • 0

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

                                                                        • +2

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


                                                                          А задачки на доске/на листочке, теоретически, нужны лишь для того, чтобы поговорить о решении (ну не дашь для этого сложную задачку, зато возможности адаптации решения — хорошая тема для разговора). Но на практике — почему-то люди на них отсеиваются (в примере с сортировкой — как если бы человек не то что не воспроизвёл по памяти quick sort или пузырёк, но даже не смог бы на коленке придумать хоть какую-то сортировку за O(n²) или написал вместо неё slow sort)

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

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

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

                                                                            Вот и всё. Как вы умеете решать сложные задачи — несомненно важно, но куда важнее — знать умеете ли вы решать задачи простые.
                                                                            • +1
                                                                              Спасибо! Вы заставили задуматься об этом в другом ракурсе. Никогда не смотрел на собеседование с такой точки зрения.

                                                                              Около месяца назад смотрел выступление на тедтолкс, где человек говорил тоже самое. https://youtu.be/YyXRYgjQXX0. Его выступление конечно же не про собеседование разработчиков, но про собеседования вообще. Забавно, но только сейчас я понял его совет.

                                                                              Он говорит что при собеседовании важнее исключить неподходящих людей, чем пропустить подходящего. Можно сказать что False Positive ошибка предпочтительнее, чем False Negative при стремлении недопустить в команду неправильных людей.
                                                                              • 0
                                                                                отсеять откровенно некомпетентный народ может и сам хр без технического народа.
                                                                                у вас правда в конторе десятки-сотни народу ничем не занимаются, только решают чужие проблемы? и они вот прям самые скиллованные из всех?
                                                                                или всё-таки у них есть свои задачи, от которых еще надо оторваться, въехать в чужую проблему, решить ее, а потом опять вспоминать свою задачу столько же времени?
                                                                                • +2
                                                                                  У нас принято помогать друг другу. И да, чаще всего помогают самые скиллованные. Они не делают это все время, у них есть и своя работа. Взаимопомощь и код ревью укрепляет отношения внутри команды. Благодаря этому джуны и мидлы боятся сделать что-то плохо, нечитаемо или неверно. А главное, они не бояться задавать вопросы. И в этом стремлении писать хорошо их мотивирует совсем не бизнес, а что-то другое, чисто человеческое. Если никто не будет помогать, ничего этого не будет. Будет тупое производство кода.

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

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

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

                                                                                      И как вы их предлагаете отсеивать?

                                                                                      но почему бы просто не проверять нужные навыки сразу, а не придумывать под это идеологию какую-то?
                                                                                      Ещё раз: потому что важнее не то, что кандидат умеет делать, а то чего он не умеет — но пытается.

                                                                                      вот только в этом случае я вижу плюсы от проверки пузырька
                                                                                      Вы вообще сколько людей в своей жизни проинтервьюировали? За исключением тех, которых вам знакомые порекомендовали?

                                                                                      А если я вам скажу что на телефонном интервью больше половины соискателей не могут написать ничего? Ну вот совсем ничего — ни FuzzBuzz, ни пузырка, ни чего-либо подобного?
                                                                                      • –1
                                                                                        Вот я — на бумажке не смогу написать ничего — ни физбаз, ни пузырька. Ни на одном языке программирования. Уверяю с честными глазами, что знаю их три, а основной — один.
                                                                                        Давайте обсудим:
                                                                                        1. с какой стороны меня это характеризует как специалиста?
                                                                                        2. чем плохо для компаний меня нанимать?
                                                                                        • +2
                                                                                          1. с какой стороны меня это характеризует как специалиста?

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

                                                                                          Ну как минимум риски выше, чем в случае кандидатов без этих проблем.
                                                                                          • –1
                                                                                            С позиции «нужно рассудить и решить здесь и сейчас» вы правы, но есть подвох.

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

                                                                                            Люди разные. У кого-то собеседование вызывает заметный стресс и с каждым случаем нужно разбираться. Времени ровно час. Мы все куда-то спешим.
                                                                                            • +1
                                                                                              Если встретите кандидата, который не может написать физбаз, спросите его номер телефона, день рождения или что-нибудь еще, что он вроде «должен» знать. И удивитесь…

                                                                                              Это абсолютно разумный критерий проверки, но есть нюанс. На собеседования же никто «с места в карьер» не скачет. Т.е. не бывает такого, что приходит кандидат, ему сразу говорят: «Берите ручку, первый вопрос физбаз, второй баблсорт. Садитесь, пишите, время пошло.»
                                                                                              Есть этап знакомства, есть этап общих вопросов. И когда доходит до практической задачки, уже и так прекрасно видно, кандидат растерян/перепуган, или нормально всё воспринимает. Поэтому и к результатам теста уже относишься вполне объективно.
                                                                                  • 0
                                                                                    у вас правда в конторе десятки-сотни народу ничем не занимаются, только решают чужие проблемы?
                                                                                    И близко нет. И всех есть свои задачи. Но если вы «увязните», если задача вам окажется «не по зубам» — помощники найдутся.

                                                                                    или всё-таки у них есть свои задачи, от которых еще надо оторваться, въехать в чужую проблему, решить ее, а потом опять вспоминать свою задачу столько же времени?
                                                                                    Разумеется есть. Потому писать пресловутый «пузырёк» они за вас не будут. А вот исправлять приложение, которое заваливает 500 серверов и с которым вы уже месяц совладать не можете — будут.

                                                                                    Потому умение вами самостоятельно справиться с пузырьком важнее, чем умение совладать с 500 серверами.
                                                                              • +7

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


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

                                                                                • +4
                                                                                  Проблема с тестовым в том, что неясно сколько по факту человек времени потратил на его решение. У нас был печальный опыт найма сотрудника, когда с тестовым он справился неплохо, а в итоге выяснилось, что этот человек работает в 3 раза медленнее остальных наших разработчиков.
                                                                                  • +1
                                                                                    Есть как минимум два хороших способа засечь время для выполнения небольших задач и один — для больших.

                                                                                    1) Тесты на Codility
                                                                                    2) Посадить человека с ноутбуком за стол, дать задачу, засечь время
                                                                                    3) Дать человеку рабочую задачу за деньги и поставить дедлайн. Если выполнил вовремя и согласен продолжать за те же деньги — значит с большой вероятностью работает удовлетворительно.
                                                                                    • 0
                                                                                      1) У нас тестовое на Unity3d.
                                                                                      2) На удалёнку ищем. Это, во-первых. Во-вторых, я бы как соискатель отказался от такого тестового, что за контроль такой? Недавняя история с устройством на работу в Амазон вспоминается; то ли тут, то ли на гиктаймс была статья. Как следствие, я бы таким образом явно не стал человеку тестовое давать. Это, как минимум, не слабый стресс для него.
                                                                                      3) Разработчик как правило ищет работу не в конкретную контору. При прочих равных, вряд ли он будет тратить время на тестовое в таких условиях.
                                                                                      • +1
                                                                                        Да, в случае удаленки + Unity первые два варианта — не вариант :) По поводу третьего — меня удивляет ваш подход, честно говоря. Что значит «разработчик ищет работу не в конкретную контору»? Как это связано с тестовым заданием? Разработчик ищет работу, есть тестовое задание для этой работы.

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

                                                                                        Ключевые слова в моем предложении — «за деньги». Что значит «в таких условиях»? Самые нормальные обычные рабочие условия. Есть работа за деньги. В вашем случае — удаленно, на Unity 3D.
                                                                                        • +7

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

                                                                                          • +2
                                                                                            Тут ещё дело не только в нежелании делать тестовое, но и в том, что в компанию, куда вы хотите устроиться, также и другие люди подаются.

                                                                                            В итоге, пока вы делаете тестовое (даже оплачиваемое) для одной компании, можете упустить рабочее место в другой. Вон у zagayevskiy можно спросить. Он несколько недель потратил на тестовое для ZeptoLab. За это время вакансию, где тестового нет, уже и закрыть могут. Правда, в его случае, он целенаправленно в ZeptoLab шёл…
                                                                                            • +6

                                                                                              Лично для себя вижу два варианта, когда соглашусь делать тестовое не "на бумажке" прямо на собеседовании на 10-15 минут:


                                                                                              • очень хочу в конкретную фирму
                                                                                              • условия заметно выделяются среди рыночных, скажем, предлагают процентов на 20 больше или офис в пешей доступности от дома.
                                                                                              • 0
                                                                                                Второй вариант является разновидностью(входит в подмножество?) первого :)
                                                                                                • 0

                                                                                                  Скорее наоборот, например заметно выделяются среди рыночных предложение с условием "Кратко о себе: https://google.com"

                                                                                      • +3
                                                                                        1) Codility — полный бред, даже хуже вопросов по алгоритмам у доски. Может там и можно создать свое уникальное задание, но те, что давали мне, были задачками далекими от реальных и представляли собой классические олимпиадные задачки. Все бы ничего, но в них очень много граничных условий, которые очень сложно продумать за отведенное время. В итоге получаешь очень низкий рейт из-за мелкой ошибки вроде (< вместо <=). Все задачи, что мне давали, гуглились. Это значит, что проходят эти задания не те, кто честно пытаются их решить, а обычные Stack Overflow Driven девелоперы или олимпиадники (которые часто не так хороши в разработке реальных проектов).
                                                                                        2) Довольно хороший подход из моего опыта как со стороны кандидата, так и со стороны собеседующего.
                                                                                        3) Тут уже зависит, есть ли подходящие задачи для такого аутсорса.
                                                                                        • 0
                                                                                          Я несколько раз проходил тесты на Codility как первый этап. Потом переходили к пункту 2, обычно. И на этой стадии я нередко выяснял, что codility нужен чтобы отбраковать людей, которые совсем не умеют писать код и простейшие алгоритмы (никак олимпиад, например может быть простая функция для преобразования массива по заданному правилу). Без подобного отсева на следующие этапы, по утверждениям рекрутеров, будет тратиться неоправданно много ресурсов впустую. Есть же статьи в т.ч. на хабре про то, как много людей не умеют писать код, на примере FizzBuzz. Так что есть смысл сделать комбо. Быстрый отсев через Codility-like (задание поставьте хотя бы FizzBuzz), потом переход ко второму или третьему варианту.
                                                                                          • 0
                                                                                            Отсеивать можно, но тут важно не перегнуть палку. Я проходил вроде бы 3 теста на Codility. Уровень сложности задач был от очень простых до реально олимпиадных, при чем время на олимпиадные было меньше, чем на простые. Однако даже для простых задач есть набор тестов, которые по сути должны являются требованиями, но вы о них ничего не знаете. Соответственно ваш код могу запустить, например, с массивом очень большой длины на которую вы не рассчитывали, а условие задачи об этом умалчивает, и вы получите очень низкий рейт. Некоторые даже давали второй шанс с указанием результатов, в котором был список тестов: зеленых и красных. Но в попытке пофиксить один тест можно с легкостью завалить два других (вы ведь не видите код теста, только его абстрактное название) и еще ухудшить рейт. На код обычно вообще не смотрят при этом, так как тест дает рекрутер (видимо даже не советуясь с нанимателем) и пропускает только основываясь на рейте.
                                                                                            • +1

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

                                                                                            • 0

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


                                                                                              Но то, что гуглится, позволяет сэкономить время: там часто удобнее сначала написать брутфорсный вариант, а потом уже искать "правильное" решение, используя брутфорсный в качестве теста. Гуглом можно сэкономить минут 5-10.


                                                                                              (То, что полный бред — не оспариваю и целиком согласен, см. мой коммент ниже.)

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

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


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

                                                                                            • +1

                                                                                              Codility — это вообще фигня бессмысленная. Умение решать околоолимпиадные задачки очень слабо коррелирует с умением решать прикладные задачи.


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

                                                                                            • +7

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

                                                                                              • 0
                                                                                                А что мешает человеку, выполнившему тестовое задание быстро, впоследствии работать медленнее остальных?
                                                                                                Да ничего. Правда, в таком случае с человеком придётся распрощаться.
                                                                                                Мой опыт также говорит, что медленнее — не значит хуже (если вы, конечно, не студия-потогонка).
                                                                                                Я число 3 не просто так привёл. Этот сотрудник делал таски в 3 раза медленнее, а баги в его коде мы отлавливаем до сих пор.
                                                                                                Минус, безусловно, и в нашу сторону, у нас нет нормального процесса код ревью =\

                                                                                                А вот детальное обсуждение результатов тестового задания, с дополнительными сопутствующими вопросами — дает отличное представление о том, что человек умеет и знает на самом деле.
                                                                                                Проблема в том, что тестовое должно быть не слишком большим. Как следствие, довольно сложные штуки туда не впихнёшь. Тестовое показывает, что человек владеет технологией/движком. А вот уже при работе с конкретными вещами на проекте возникают проблемы.
                                                                                                • 0
                                                                                                  при работе с конкретными вещами

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


                                                                                                  баги в его коде мы отлавливаем до сих пор

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

                                                                                                  • 0
                                                                                                    Ну вот попался вам криворукий персонаж, это понятно, но почему из этого опыта вы делаете странный вывод о том, что скорость выполнения задания — главный параметр, по которому его стоило отсеять?
                                                                                                    Я такого не говорил. Я лишь сказал, что нам не нужен разработчик, который работает очень медленно и при этом косячит.
                                                                                                    • 0
                                                                                                      Проблема с тестовым в том, что неясно сколько по факту человек времени потратил на его решение.
                                                                                                      • 0

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

                                                                                                  • 0
                                                                                                    > Минус, безусловно, и в нашу сторону, у нас нет нормального процесса код ревью

                                                                                                    Кроме этого возможно, что нет грамотной постановки задачи, приемочных тестов с приличным code coverage и QA и т.д. и т.п.

                                                                                                    > Проблема в том, что тестовое должно быть не слишком большим.

                                                                                                    См. выше. Это не проблема, когда за уделенное вам время и предоставленные результаты вы начинаете платить деньги. Тогда «тестовое» задание может быть сколь угодно большим и сложным и результаты пойдут в работу. На самом деле это реальная работа. Просто посмотрев результаты вы либо примете человека в проект, либо нет. Вот и вся суть «теста».
                                                                                                    • +3
                                                                                                      Мы над проектом более 3 лет работаем. Человеку только чтоб разобраться в нём, как минимум, пару дней потратить придётся. То есть, мы заплатим за неделю, а по факту за день работы. Таких соискателей несколько. Если не касаться вопроса денег, то это много времени занимает с нашей стороны, а команда у нас небольшая.

                                                                                                      Это не фриланс заказ на какой-то небольшой скрипт, который работает и ладно.
                                                                                                      • 0
                                                                                                        Тестовым заданием оторванным от работы протестить работу в проекте где неделю разбираться надо конечно не получится. Если у вас только неделю в работу въезжать надо… ну вы либо это оплачиваете работнику, либо продолжаете есть кактус, либо что-то меняете в процессе разработки (я НЕ утверждаю что он плохой, может действительно у вас там rocket science). Можно только посочувствовать.

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

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

                                                                                                        • 0
                                                                                                          > Просто посмотрев результаты вы либо примете человека в проект, либо нет. Вот и вся суть «теста».

                                                                                                          Это суть испытательного срока
                                                                                                        • 0
                                                                                                          Я число 3 не просто так привёл. Этот сотрудник делал таски в 3 раза медленнее, а баги в его коде мы отлавливаем до сих пор.

                                                                                                          А человека, который делает таски в 3-5 (буквально) раз медленнее, но баги вылазят через полгода и связаны с неверно сформулированными в тз граничными условиями, а на ревью правится разве что кодстайл вы бы тоже не взяли?
                                                                                                          • 0
                                                                                                            Вы какие-то абстрактные вопросы приводите, когда я конкретный пример привёл =\
                                                                                                            Проблема была не в ТЗ, так как другой сотрудник по такому же ТЗ нормально всё сделал.
                                                                                                            • –1
                                                                                                              Но вы-то подаёте это так, как будто вообще не стоит брать разработчиков, которые не хреначат код нон-стопом и вообще скорость — главный параметр при собеседовании.
                                                                                                            • 0

                                                                                                              Как неверно сформулированные в ТЗ граничные условия могут привести к багам в коде? Баг — неверно реализованное ТЗ, а если ТЗ не соответствует бизнес-задаче, но верно реализовано в коде, то баг в ТЗ, а не в коде.

                                                                                                        • +4

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


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

                                                                                                          • +6

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

                                                                                                            • 0
                                                                                                              Медленно-то в каком плане? Набора кода или проектирования, продумывания архитектуры, уточнения требований и условий? Если второе — то это не плохо, а скорее даже хорошо. Если первое — это временное явление, которое с опытом нивелируется, выучит синтаксис, паттерны конетного языка (или набора языков) и т.д.
                                                                                                              • 0
                                                                                                                1) Медленно набирает. Hot keys почти не использует. А человека мы нанимали изначально удалённо, про это узнали, только когда в офисе все вместе собрались.
                                                                                                                2)
                                                                                                                Если второе — то это не плохо
                                                                                                                Чем же хорошо? Я приведу конкретный пример. У нас в игре есть различные персонажи, у каждого свои спелы. Стояла задача сделать спелы для нового персонажа. Человек провозился несколько недель. Уже прошло несколько месяцев после увольнения, но баги то тут, то там всплывают.
                                                                                                                Другой сотрудник для уже следующего нового персонажа сделал все спелы за пару дней. Ну да, сложность проектирования новых спелов +- может отличаться, но не в 3-4 раза по времени.
                                                                                                                • +3
                                                                                                                  Я почти не использую хоткеи в некоторых средах, где проще через гуй сделать что-то, что я теперь разработчик никакой из-за этого?