Я пришел на собеседование с лайвкодингом — и меня с позором размазали



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

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

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

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

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

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

    Скайп, тёмный экран, голоса — один за другим мне представляются интервьюеры. Ни одного из них не было на предыдущих этапах. Четыре штуки. Объясняют правила игры, говорят, что могу думать сколько угодно, что никто не давит, код пиши там где привык, так, как привык. Можешь гуглить все что хочешь. Но есть одно ключевое условие: задачу нужно решать в манере TDD.

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

    Задача и правда была простой. Надо было написать парсер выражений, начать с простейших «1+2», а закончить настолько глубоко, насколько возможно за отведенные два часа.

    Механизмы в моей башке заскрипели: так, просто сложение сделать невероятно легко, вычитание тоже, умножение потребует порядка действий — только оно стоящее. Если я не сделаю им умножение, они меня пошлют. Твою мать, читал же месяц назад про паттерн интерпретатор, они точно ждут именно его. Блин, я не помню как его делать! Сколько я уже думаю? Несколько минут? Они посчитают, что я идиот. Блин-блин-блин, если я сейчас же не начну хоть что-то писать, мне конец.

    — Какие-то проблемы, Филипп?

    Ну всё. Они все уже решили. Хотя нет, может они просто участливые? Да пиши же ты уже код!!!

    Дрожащими ватными руками я нажимаю «Add file». Боже ж ты мой, как его назвать? Какой-нибудь экспрешн парсер! Стоп. В дотнете же есть родные штуки для распаршивания выражений. Они точно ждут не велосипедиста, а умного разраба, который пойдет и применит готовое решение. Открываю гугл, начинаю вбивать.

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

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

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

    А я хочу увидеть, как тебе хлещут дохлой мороженной рыбиной по морде. Создаю файлик с тестом. Я не знаю, зачем. Уже очевидно, что никуда я не прошел. Туплю в нагенеренный студией код теста, одну минуту, две, три. Слышу возмущенное покашливание из скайпа. Господи, ну почему они не могли прислать на это интервью людей с предыдущего? Чтобы хотя бы один человек с той стороны экрана знал, что я блин не самый тупой человек на земле, и действительно кое-что знаю. Для этих, я определенно стал конченным дном.

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

    Запускаю тест — ничего не происходит. Вообще ничего, список прогнанных тестов пустой. Запускаю ещё раз, то же самое. Господь всемогущий, меня прокляли. Тесты не запускаются! Они не падают, они просто не запускаются!
    Пытаюсь запустить не решарпером, а студией. Не работает. Пишу новый тест, он тоже не запускается. Это невозможно, но это происходит со мной, на кодинг интервью, студия, решарпер или дотнет сломались, и у меня не запускаются тесты.

    — Филипп, вы забыли добавить модификатор public к тесту.
    —…
    —…
    — processing…

    Я понял. Выругался. Замьютил микрофон, выругался покрепче. Вернул микрофон. Добавил public, тест прошел. Я начал писать тест на вычитание. И вдруг как гром среди ясного неба:

    — Филипп, наше интервью подошло к концу, огромное вам спасибо за потраченное время, мы сообщим вам о решении!

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



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

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

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

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

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

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



    На правах рекламы


    Мощные виртуальные серверы с процессорами AMD EPYC для разработчиков. Частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит оторваться на полную — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

    VDSina.ru хостинг серверов
    Серверы в Москве и Амстердаме

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

      +16

      Ну зачем ты так, опять эти флешбеки...

        +26
        Я аж собес в яндексе вспомнил…
          +9
          Ох мои соболезнования…
            +4
            Это вы еще на собеседовании в Одноклассники(!) не были…
            В Яндексе задачки обычно проще.
              –6
              Написать калькулятор достаточно типовая задачка для собеседований.
              Там делов то. Вспомнить про стек и вперед. () — рекурсией тоже просто.

              И все ()*/+- покрываются на раз. Строк 30 кода, если не особо над переполнениями заморачиваться. За типовой час пишется на доске и разбирается с запасом.
                +2
                () — рекурсией тоже просто.

                Специально пошёл смотреть "алгоритм сортировочной станции", чтобы проверить не забыл ли я там рекурсию. Нет — не нужна. И честно говоря я сомневаюсь что вы уместите его в 30 строк.

                  +3

                  Зачем вы искали рекурсию в алгоритме сортировочной станции, если алгоритм рекурсивного спуска — это совсем другой алгоритм, который алгоритмом сортировочной станции не является?

                    +2

                    Стек в этом алгоритме заменяет рекурсию. Ведь рекурсия — это и есть фактически и есть стек.

                    –1

                    У меня вариант попроще описан.
                    Который проще придумать, проще написать и он не сильно хуже. Собеседование же, все на лету.


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

                      0
                      По моему, для этого нужна обратная польская запись. И там вроде бы стэк и все несложно.
                      Алгоритм
                      Пока есть ещё символы для чтения:
                      Читаем очередной символ.
                      Если символ является числом или постфиксной функцией (например, ! — факториал), добавляем его к выходной строке.
                      Если символ является префиксной функцией (например, sin — синус), помещаем его в стек.
                      Если символ является открывающей скобкой, помещаем его в стек.
                      Если символ является закрывающей скобкой:
                      До тех пор, пока верхним элементом стека не станет открывающая скобка, выталкиваем элементы из стека в выходную строку. При этом открывающая скобка удаляется из стека, но в выходную строку не добавляется. Если стек закончился раньше, чем мы встретили открывающую скобку, это означает, что в выражении либо неверно поставлен разделитель, либо не согласованы скобки.
                      Если существуют разные виды скобок, появление непарной скобки также свидетельствует об ошибке. Если какие-то скобки одновременно являются функциями (например, [x] — целая часть), добавляем к выходной строке символ этой функции.
                      Если символ является бинарной операцией о1, тогда:
                      1) пока на вершине стека префиксная функция…
                      … ИЛИ операция на вершине стека приоритетнее o1
                      … ИЛИ операция на вершине стека левоассоциативная с приоритетом как у o1
                      … выталкиваем верхний элемент стека в выходную строку;
                      2) помещаем операцию o1 в стек.
                      Когда входная строка закончилась, выталкиваем все символы из стека в выходную строку. В стеке должны были остаться только символы операций; если это не так, значит в выражении не согласованы скобки.


                      ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B0%D1%8F_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C

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

                        Не нужна тут ОПЗ. Вместо формирования выходной строки можно или сразу вычислять выражение, или же строить AST.


                        ОПЗ — это такой способ записи выражений, который позволяет избежать "продвинутого" парсинга, вроде алгоритма сортировочной станции. Но заставлять пользователя использовать ОПЗ в 2020м году как-то странно, а чтобы преобразовать инфиксную форму в постфиксную — вам придётся алгоритм сортировочной станции использовать. Ну и зачем в таком случае ОПЗ?

                          0
                          Вы скопировали решение другой задачи. Да еще и на русском языке, вместо любого языка програмирования. Вместо того чтобы придумать решение для обычного калькулятора.
                          Что же в этом хорошего?
                        0
                        На олимпиаде по Ораклу вроде писал парсер на SQL.
                        Вот тут было весело.
                          0
                          В Одноклассниках калькулятор мне не задавали.
                          Задачки были несколько посложнее. Ну и вторая из них выглядит как выносящая мозг любому Java-разработчику в силу своей специфики.
                    +17
                    Одна из причин почему не вылазим с фриланса. Внезапные приступы тормозной тупости с реактивной гениальностью. Работает по принципу как в том мультике "Лучше день потерять потом за пять минут долететь"
                    Один раз, в глубокой молодости, интервью случилось аккурат в приступе «реактивной гениальности» и к несчастью прошло успешно. Первая неделя была крайне интересной — каждый день 8 часов тупого пяления в монитор и 3 строчками кода, потом приступ кодинга вечером в домашнее время и притащенное утром решение задачи над которым контора уже 3 дня билась. Через неделю увольнение, после беседы с директором, который это объяснение выслушал с недоверчивым прищуром и явным подозрением, что у нас дома спрятана какая-то команда индусов, а собес был просто куплен по знакомству.
                    Теперь принцип простой. Только проектный фриланс. К любой задаче даже 1 день сроком прибавляется неделя на выполнение. Никакие задачи не показываются в состоянии "тут будет дом, а то что сейчас забор после 50% срока, это норм" Со студиями спускающими нам проекты как «неграм» очень даже работает (правда портфолио не пополняет), с конечными клиентами это уже сложнее (обычно хотят видеть плавный постоянный прогресс, а не авралы с простоями), а вот в команду с таким подходом без шансов — незакоммитил пару килобайт за сутки — весь следующий день будешь оправдываться перед тимлидом вместо работы — это сильно расстраивает на самом деле.
                      +3
                      Где такие заказы:
                      К любой задаче даже 1 день сроком прибавляется неделя на выполнение.
                      ?=) Никогда толком фрилансом не занимался, но как не попадется какая-нибудь «подработка», то вечно с какими-то горящими-сумасшедшими сроками. Не люблю торопиться, поэтому никогда не беру, поэтому нет дополнительных денег (а хотелось бы=) ).
                      незакоммитил пару килобайт за сутки — весь следующий день будешь оправдываться перед тимлидом вместо работы — это сильно расстраивает на самом деле.
                      — очень не очень, согласен!
                        +3
                        ?=) Никогда толком фрилансом не занимался, но как не попадется какая-нибудь «подработка», то вечно с какими-то горящими-сумасшедшими сроками. Не люблю торопиться, поэтому никогда не беру, поэтому нет дополнительных денег (а хотелось бы=) ).
                        Зачастую сводится к цене.
                        Высокий ценник — будут лишь авральные заказы по типу «надо было вчера», т.к. иначе за что платить при прочих равных? Будет низкий ценник — будет из чего выбирать, в т.ч. и заказы вида «мне не горит, главное что бы цена приятная» будут.
                        Тут просто вопрос насколько Вы готовы снижать цену ради приятности заказа. Допустим приходит к Вам заказчик и кидает на стол штукарь баксов «что бы завтра все было готово», а Вы так задумчиво три сотни оттуда тянете, остальное ему обратно двигаете и говорите «а что насчет следующей недели»? И зачастую спешка внезапно куда-то пропадает.
                        .
                        Вторая частая ситуация — многим нужна не столько срочность, сколько гарантированность сроков. А срочность они просят просто потому, что хотят иметь время найти кого-то еще, если тут продинамят. В таких случаях можно обсудить увеличение сроков в обмен на повышенные финансовые гарантии со своей стороны. Типа — а давайте я сделаю это за неделю, а не за день, но если пропущу сроки, то не Вы мне косарь отвалите, а я Вам в качестве неустойки. Достаточно типичный вариант со студиями, кстати, которые сами перед заказчиком отвечают.
                          +2

                          Очень кстати прикольное предложение про "за три сотни и никуда не торопимся", чем-то оно мне нравится.


                          Напоминает анекдот про давно прошедшие времена в судах России:


                          К судье приходит секретарь и говорит: «Ваша честь, у нас проблема. Ответчик дает 130 тыс., а истец дает 100 тыс. Что будем делать?» Судья говорит: «Верните 30 тыс. ответчику, и будем решать дело по закону».

                          И второе предложение хорошо смотрится. Блин. Почему такая практика нигде не прижилась?? Что для этого нужно?

                            0
                            Почему такая практика нигде не прижилась?? Что для этого нужно?
                            Не так много людей кому это подходит.

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

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

                            Странный директор — если проблемы решаются, какая разница каким образом это делается?
                            Paskin «самураю не важна цель, ему важен путь» как-то так. В крупных фирмах предсказуемость и планируемость на первом месте, т.к. иначе невозможно управлять большими процессами. Представьте себе что у Вас колесо авто то 1 оборот в секунду делает, то 10, но в среднем выдает те самые нужные 5 — надо оно Вам в автомобиле?:)
                        +6
                        Странный директор — если проблемы решаются, какая разница каким образом это делается?
                        К нам как-то пришла на интервью девушка, прямо сказавшая что руками она тестировать умеет, а автоматические тесты только начала изучать — но у нее муж крутой спец в этом деле и будет ей советовать если мы ее возьмем.
                        То ли девушка поскромничала, то ли муж действительно оказался крутым спецом — но тестов она написала целую кучу и вполне по делу.
                          +1

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


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


                          Владение лайвкодингом это признак готовности или неготовности. Всё тренируется. И да не спешите. Тяните время. Но это интересно на самом деле проверять самого себя.

                            +1

                            Некоторые действительно не могут эффективно писать по TDD. Особенно если вообще тесты никогда не писали.

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

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

                                0
                                Вот это вы сейчас соврали, если брать конкретный случай с вами: homedevice.pro/product-category/online-course

                                И не надо тут нам заливать, что ваши проекты круче чем у остальных.
                                +5
                                Тесты не имеют отношения к алгоритмам. Рассказ про то как тесты мешали написать интепретатор смахивает на сказочку.

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


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

                                  +3

                                  Причём, емнип, по канону сперва код должен сперва быть такой, чтоб тест падал.

                                    +3
                                    нормального программиста просто от такого будет воротить и придется преодолевать себя

                                    Какой-то у вас неправильный нормальный программист :) для задач уровня парсера выражений TDD очень даже удобен, там тесты нужны уровня expect(calculate("2+2*2"), equals(6));
                                      +2
                                      Ну, это такое. Лично я считаю, что TDD — это overhyped фигня, которая не везде подходит, а часто написание тестов «после» намного удобнее и дает большее покрытие.
                                      А тестирование некоторых вещей — долго и дорого, по сравнению со стоимостью/сроками решаемой бизнес задачи.
                                        +1
                                        а есть ещё совсем свежее поколение разработчиков которое считает что логирование не нужно. про сложность алгоритмов уже ни один андроид-разраб ответит не способен. что же будет дальше.
                                          0
                                          Это ваши аргументы или мысли вслух?
                                            0
                                            это реальность. но я как специалист на фоне такого буду больше зарабатывать. так что можете не тестировать, забыть про логирование, наплевать на сложность алгоритмов, не интересоваться структурами данных.
                                              0
                                              Ну, я не говорил, что автоматизированные тесты не нужны. Я сказал, что я считаю, что TDD не нужно.

                                              И, да, не беспокойтесь, безработица мне не грозит.
                                        0

                                        Парсер выражений должен выдать на выходе не 6, а AST: Add(Const(2), Mul(Const(2), Const(2))).


                                        Два таких дерева сравнить — уже нетривиальная задача (придётся добавлять во все классы метод Equals исключительно для нужд тестирования). А как начинать писать код с тестов, а не с классов для представления AST — для меня и вовсе загадка...

                                          0
                                          придётся добавлять

                                          Или не придется


                                          А как начинать писать код с тестов

                                          Можно написать некомпилирующийся тест

                                            0
                                            Можно написать некомпилирующийся тест

                                            …без подсказок IDE. А современные IDE ещё и будут активно мешать.

                                              +1

                                              С подсказками.


                                              Это слишком большой тест для TDD. Сначала, придется написать Const(2), для этого надо будет написать Const — для текущего кусочка подсказок не будет, но будет кодогенерация

                                            0
                                            Ну, если надо именно аст красивый выдавать, то никто не мешает начать тест с более простого, типа Const(2), потом Add(Const(2),Const(2)). Не знаю, как там в строгом понимании TDD, но я бы делал так. Как минимум, api класса должно какое-то быть для теста. Скажем, та же функция createAst(String input) => throw Error();. Потом тест на неё, сначала expect(createAst("2"), equals(Const(2));, упадёт по-любому, потом можно к минимальной реализации приступать.

                                            придётся добавлять во все классы метод Equals исключительно для нужд тестирования

                                            В нормальных языках уже завезли data-классы.
                                              –1

                                              В каноническом TDD вы API создаёте пытаясь заставить тест скомпилироваться или что там у вас. То есть используете в тесте какой-то не существующий AstNode интерфейс с методом, например, children, получаете ошибку компиляции и только потом создаёте этот интерфейс с этим методом.

                                          +2
                                          Ну в случае ТДД это действительно так — в рамках ТДД вы не можете сразу начать писать итоговый алгоритм, даже если его знаете. Вам надо для каждого теста писать недоалгоритм, а потом с нуля его переписывать под новый тест.

                                          И если не секрет, то в чем здесь проблема? В .net я обычно пишу либо интерфейс без реализации, на него тест, и далее реализация. Либо метод с NotImplementedException, на него тест, далее реализация.

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

                                          Чушь и не правомерное обобщение=)
                                          TDD удобно если умеешь, если есть на него время, если проект в долгую и если не заставляют. Да «если» тут много.
                                            0
                                            И если не секрет, то в чем здесь проблема?

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

                                              +1
                                              Требуется больше итераций и кода на выброс, чем если сначала написать все тесты потом весь код или наоборот.

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

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

                                                Для этого достаточно интерфейса.


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

                                                Мы рассматриваем ситуацию когда алгоритм известен. Например вычисление выражений с приоритетами.

                                              +1
                                              И если не секрет, то в чем здесь проблема? В .net я обычно пишу либо интерфейс без реализации, на него тест, и далее реализация. Либо метод с NotImplementedException, на него тест, далее реализация.

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

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

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

                                                  Не согласен. Допустим, вы транслируете выражение в LLVM байткод, а LLVM генератор выдает Вам машинный код. И вот оно уже работает быстро.
                                                    0

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

                                                      0

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

                                                        0

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

                                                  0
                                                  получится, что в один шаг надо большую часть реализации переделать/выбросить все ранее написанное.

                                                  Программирование, и даже TDD — это ведь не культ (обычно), необязательно неуклонно следовать непонятно кем описанным условностям. Можно, если в голове уже есть представление, что делать, тесты писать более крупными мазками, не начиная с банальщины.
                                                    0
                                                    TDD — это ведь не культ (обычно)

                                                    Разве?

                                                      0

                                                      Я ведь уточнил, что "обычно" :) И да, часто для дискуссии нужно чуть больше, чем одно слово и минус.

                                                        +1
                                                        Я ведь уточнил, что "обычно" :)

                                                        Без "обычно". Тут я вижу есть определенное непонимание — некоторые под ТДД подразумевают просто "пишу код и тесты параллельно, как мне будет удобно". Но нет, это не тдд, это просто человек как-то пишет тесты. ТДД же строго регламентирует как и когда пишутся тесты/продакшн код, из этого регламента тдд и состоит. И если вы базовые принципы тдд нарушаете, то это уже не тдд.
                                                        Ну в самом деле, если вы, когда это удобно и разумно, пишете сперва код, а потом тесты, то в каком месте это будет test driven development?

                                                          0
                                                          И если вы базовые принципы тдд нарушаете, то это уже не тдд.

                                                          Когда человек начинает использовать TDD, ему ведь не дают подписать контракт, запрещающий любые другие подходы? Можно вполне быть разумным человеком и применять то, что удобнее в конкретной ситуации. Также как если человек придерживается в основном ООП, а потом где-то тулит Util- класс или передаёт лямбду в качестве аргумента, (обычно) к нему не прибегают ООП-апологеты с палками.
                                                            0

                                                            TDD это про проектирование и валидацию системы при эксплуатации. А также про эксплорацию кода на каждом из этапов.
                                                            Тесты взаимодействуя с интерфейсами имитируют работу системы, поставляя ей набор данных от других интерфейсов. Реальной системы может ещё и не быть, а всё состоять из рендеров или заглушек. Задача разработчика заменить рендеры и заглушки на реальный код, сохраняя ее работоспособность. Которая и проверяется тестами. Насколько хорошо? Это зависит от граничных данных которые мы хотим или не хотим получать или передавать. Иногда ты физически можешь работать только со статическим рендером, но остальные части твоей системы об этом ничего не знают, так как общаются через интерфейс, который скрывает реализацию и если надо имитирует готовность и валидность.
                                                            Поэтому разумно начинать проектирование именно с описания интерфейсов. Которые обычно задаются схемами с последующей кодогенерацией.

                                                      +1

                                                      Мелкость шагов по TDD определяется разработчиком.

                                                      +2
                                                      И если не секрет, то в чем здесь проблема?

                                                      Проблема в том, что вам надо написать код, который вы совершенно точно целиком выкинете через 5 минут. И так несколько раз.


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

                                                        +2
                                                        Проблема в том, что вам надо написать код, который вы совершенно точно целиком выкинете через 5 минут. И так несколько раз.

                                                        Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?
                                                        Еще проблема ТДД — программист не имеет права сразу в коде обрабатывать краевые случаи. Сперва вы должны написать алгоритм без обработки каких-либо краевых случаев, а потом добавлять краевые случаи по одному с соответствующими тестами.

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

                                                        Довольно бездоказательное утверждение. К слову 100% покрытие — это такой же не здоровый фанатизм, как и полное отсутствие тестов.
                                                          +3
                                                          Эм? А эту догму вы откуда достали?
                                                          https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html

                                                          • You must write a failing test before you write any production code.
                                                          • You must not write more of a test than is sufficient to fail, or fail to compile.
                                                          • You must not write more production code than is sufficient to make the currently failing test pass.
                                                            +1
                                                            Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?

                                                            Ну, хотя бы, что на первый тест assertEqual(3, eval(«1+2»)); по TDD надо написать минимальный код, который починит тест, которым является return 3; Чтобы прийти к return a+b; надо написать минимум два теста. Соответственно, «return 3» тот самый выброшенный код.
                                                            Этот пример, конечно, упрощение, и в реальном мире все сразу напишут return a+b; что будет отступлением от канонов TDD. А если мы разрешаем пропускать шаги и писать больше кода, чем это требуют тесты, то легко пропустить юзкейсы, которые надо было бы зафиксировать в тестах (чтобы убедиться, что они все еще будут работать при последующих рефакторингах), потому что юзкейсы-то уже покрыты и тесты не сломаны.

                                                            Эм? А эту догму вы откуда достали?

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

                                                            К слову 100% покрытие — это такой же не здоровый фанатизм, как и полное отсутствие тестов.

                                                            Ну, по TDD у Вас оно всегда должно быть 100%. Вывод: TDD — нездоровый фанатизм.
                                                              +1
                                                              1) надо писать тест вперед, 2) тест изначально должен быть сломан, 3) надо писать минимальный код, чтобы сделать тест работающим.

                                                              Там выше цитату приводили, что надо писать мало того, что минимальный, но еще и production(не знаю, как на русский перевести), коим return 3 врядли является. Вот если бы return 42, но он тест не пройдет.

                                                              Ну, по TDD у Вас оно всегда должно быть 100%. Вывод: TDD — нездоровый фанатизм.

                                                              Любую идею или подход можно довести до абсурда, мне кажется, что если я сначала напишу набор тестов на граничные случаи, которые взбредут в голову, потом код, который их последовательно закрывает, то это все равно можно назвать TDD.
                                                                0
                                                                Там выше цитату приводили, что надо писать мало того, что минимальный, но еще и production(не знаю, как на русский перевести), коим return 3 врядли является. Вот если бы return 42, но он тест не пройдет.


                                                                production он в том плане, что это не код тестов, а код, собственно, продукта. И это вполне валидный продакшен код, соответствующий спецификации (которая требует, чтобы в итоге результат был «3»).

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

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

                                                                  Не могу согласиться, спецификация все же требует, чтобы была обработана строка «1+2» и на выходе был правильный результат, который равняется «3». Можно конечно возразить, что есть вариант захордкодить все возможные входящие строки, но это абсурд и ИМХО никак не является требованием TDD, смысл 3го шага, который refactor там в том, чтобы сделать изначально работающий корректно код более сопровождаемым и/или читабельным.

                                                                  P.S. Сейчас открыл книжку Бека, как одного из основателей подхода, там действительно предлагается на первом шаге предлагается хардкодить вычисленный в голове результат, но, опять же ИМХО, это намеренное утрирование, чтобы было понятно, что тесты должны запускаться почти на каждую компиляцию, а компилировать стоит почти на каждую новую строку (люди пишушие на C++ вздрогнули).
                                                                    0

                                                                    Хотелось бы всё-таки точную цитату а не имхо. Вообще тесты сейчас просто фоном в процессе набора гоняются NCrunch и live unit testing.


                                                                    Некоторые вообще пропагандируют подход работать и коммитить маленькими кусочками


                                                                    https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864

                                                                0
                                                                и в реальном мире все сразу напишут return a+b;

                                                                А вот и нет. В реальном мире TDD сначала пишут тест, и он даже не должен собираться и выполниться, потому что еще не написали eval. Тесты уже начинаются с этого места.

                                                                0
                                                                Эм, с чего бы? Вероятно я вас не понимаю, вы не могли бы привести пример, какие «недоалгоритмы» понадобятся, чтобы написать тесты на калькулятор?

                                                                Ну очень просто — допустим, вы хотите сделать реализацию калькулятора через стек.
                                                                Но сперва вам надо написать калькулятор, который парсит выражение без скобок/приоритетов — так как вы напишите, например, тест "1+2+3+4" (а до этого — вообще тесты на "5" или пустую строку). Потом вы, например, добавляете скобки или приоритеты — но вы не можете из калькулятора без скобок/приоритетов сделать калькулятор со скобками/приоритетом — это принципиально другой алгоритм. Изначально же подложить соломки и сразу писать алгоритм с возможностью допиливания — вы не имеете права, т.к. если у вас есть тест "1+2+3+4", то вы должны писать код конкретно под зафиксированный этим тестом инвариант — не более того. Если бы в описанном в обсуждаемой статье случае вы начали объявлять какой-то там стек, то вам бы интервьюеры сказали бы: "а зачем вам этот стек? 1+2+3+4 можно распарсить и посчитать без всего вот этого".


                                                                Эм? А эту догму вы откуда достали?

                                                                Ну, это и есть определение ТДД — не писать код до теста, который покроет этот код. Если вы сперва пишите код, а потом тесты на него (в данном случае — сперва пишите код для обработки краевого случая, а потом тест для этого случая) — это прямой tdd violation.


                                                                Довольно бездоказательное утверждение.

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


                                                                К слову 100% покрытие — это такой же не здоровый фанатизм, как и полное отсутствие тестов.

                                                                С тдд у вас всегда будет 100% покрытие. Т.к. любой код пишется по причине непрохождения какого-либо теста — который этот код потом и покроет.

                                                                  0

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

                                                                    0

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

                                                                      0

                                                                      Есть ТЗ на работу с каким-то списком из 10 элементов. На задачу хорошо ложится единоразовое выделение памяти. Пишем тесты для 10 элементов, пишем единоразовое выделение памяти изначально, захардкодив 10. Но мы же думаем о будущем и понимаем, что скоро может прилеть задача на расширение списка до 11+ элементов. И делаем ветку, в которой при обращении к элементу с индексом большей длины происходит выделение памяти в достаточном для этого индекса размере. Наши тесты этого не покрывают, но остаются зелёными. Рефакторинг проведён, наблюдаемое поведение кода осталось неизменным.

                                                                        0

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


                                                                        Википедия:


                                                                        Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1][2].


                                                                        У вас цель не совпадает с целью из определения

                                                                          0

                                                                          Английской вики я доверяю больше:


                                                                          code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.
                                                                            0
                                                                            Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality.

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

                                                                              0

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

                                                                                0

                                                                                Это уже не рефакторинг. Меняется не только факторинг но и функциональность.


                                                                                Там уточнено.


                                                                                (its non-functional attributes)
                                                                                  0

                                                                                  Никто эти изменения функциональности не видит, ни одним существующим способом их выявить нельзя. Разве это можно назвать изменением функциональности?

                                                                                    0

                                                                                    То есть это мертвый код?


                                                                                    In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.

                                                                                    Статья factoring ведет на decomposition.


                                                                                    Decomposition in computer science, also known as factoring, is breaking a complex problem or system into parts that are easier to conceive, understand, program, and maintain.

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


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

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

                                                                                      Как же это нельзя? Можно. До этого у вас был один результат вызова ф-и, а теперь — другой.


                                                                                      Разве это можно назвать изменением функциональности?

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


                                                                                      До рефакторинга никто не мог видеть поведения для 11.

                                                                                      Как это не мог? Мог. Вызываю вашу ф-ю на списке размером >10, и вижу это поведение.

                                                                                        0

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

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

                                                                                          Изменение семантики — это не рефакторинг.

                                                                                0
                                                                                without changing its external behavior.

                                                                                То, что вы описываете, поведение, очевидно, меняет.


                                                                                Если в команде программист обязан работать по TDD, то не писать их он права не имеет.

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

                                                                                  0

                                                                                  Внешнее поведение не изменяется, поскольку оно определено только для 10 элементов. Для 11 оно неопределённое.

                                                                                    0

                                                                                    Разве изменение не было для того, чтобы доопределить его для 11?

                                                                                      0

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

                                                                                      0
                                                                                      Внешнее поведение не изменяется, поскольку оно определено только для 10 элементов. Для 11 оно неопределённое.

                                                                                      Ну т.е. меняется внешнее поведение для 11. До рефакторинга f(x) (где х — список длины >10) давало один результат, после — другой.


                                                                                      С-но, по ТДД вы сперва напишите тест для >10 элементов, а потом проведете соответствующее изменение кода.

                                                                                        0

                                                                                        До рефакторинга никто не мог видеть поведения для 11. после рефакторинга его также никто не может видеть. Следовательно внешнее поведение не изменилось. )

                                                                      0

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

                                                                        0
                                                                        Программист имеет право сразу написать тесты на краевые случаи

                                                                        Программист имеет право вообще не писать тесты, например. Только это будет уже не ТДД :)

                                                                          0

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

                                                                0
                                                                Оу, прекрасно вас понимаю. А какой у вас рабочий стек технологий?
                                                                +12
                                                                Чем-то похоже на блиц-шахматы. Это надо иметь навык и/или талант. Алёхину, понятно, это не помеха, но обычные люди, хорошие шахматисты, очень часто теряются.
                                                                  +3
                                                                  по-моему, очень удачное сравнение!
                                                                    0

                                                                    Ещё бы глупые ошибки в фамилии шахматиста не делать.

                                                                      +1

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

                                                                    0
                                                                    Как программист и шахматист не соглашусь :) В блиц гасить могут все, вопрос в наигранности схем, даже можно не считать варианты.
                                                                    А программировать до сих пор, сам, предпочитаю после того, как уляжется в голове.
                                                                    +4

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

                                                                      0

                                                                      Чем писание кода на доске не лайвкодинг?! В период пандемии теперь все интервью — лайв кодинг: пишете в каком-нибудь coderpad, там же и запускаете. Решение задачек на доске/блокноте — это повсеместные практики интервью для программистов. И да, к этому надо готовиться, тренироваться. Есть задачи на знание алгоритмов и структур данных, есть — на реализацию (как у автора).

                                                                        +2
                                                                        На доске тоже лайвкодинг, да. Разве я говорил обратное?
                                                                        Да и про то, что это весьма распростанено, тоже понятно.
                                                                        Я говорил только, что реально стрессирует. Конечно если много раз выступить таким образом, стресс должен уйти.
                                                                          +4
                                                                          И да, к этому надо готовиться, тренироваться.

                                                                          Единственно непонятно, каким боком этот скилл связан с реальной работой.

                                                                            0

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

                                                                              0

                                                                              Лайвкодинг — он разновидность кодинга. Так что он похож на то что делается на работе.

                                                                                0

                                                                                Более того, на многих проектах это нормально. Не то чтобы прямо каноническое парное программирование, но спонтанно возникает: кто-то помощи просит, подходишь и вдвоём в монитор смотрите, а код пишет один.

                                                                                  +1

                                                                                  Там другая атмосфера, нет ощущения экзамена, а это ощущение как раз ответственно за 80% провалов.

                                                                                    +1

                                                                                    Так это ощущение, надо от него избавляться. Собственно когда избавился, крайне редко испытываю сожаление, что не прошёл. В 80% случаев облегчение что пронесло )

                                                                                –3
                                                                                А может даже и вреден, ведь в том же Яндексе нет своих уникальных продуктов, всё откуда-то спёртое. Ну и особо про качество тоже не сказать, тот же Яндекс.Диск как то системы пользователям поудалял.
                                                                                  0
                                                                                  А можете привести пример «уникального» продукта? Интересно, что вы вкладываете в это слово.
                                                                                    –3
                                                                                    Зачем?
                                                                                      +1
                                                                                      Объясню. В моём представлении об устройстве мира все продукты уникальны. Вы не найдёте два идентичных продукта. Да, даже в Яндекс.Браузере, на мой вкус, есть неплохие технологические фишки, которых нет больше нигде, хотя база же на Хромиуме. Идеи, на которых строятся продукты, могут быть не уникальны, да. Новые идеи вообще редко когда возникают сейчас. Вот только люди пользуются не идеями, а конечными продуктами. И их удовлетворённость зависит от того, как продукт реализован, а не как идея сформулирована. Поэтому мне и стало интересно, что же такое «уникальный продукт» в вашем представлении. Хочется посмотреть на него.
                                                                                        0
                                                                                        Уникальный продукт это который вы придумали и выпустили в мир первые, например? Это всё тонкие материи, насколько копия отличается от оригинала и мало интересно. Есть же специалисты по копированию, тот же Naspers. Мало кто знает, что они делают, но многие пользуются. Нет в этом ничего плохого. Ну просто им придумывать ничего не надо, надо просто хорошо повторить.

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

                                                                                          Веб-поиск, например? Если, конечно, не считать Yahoo! Directory — поисковой системой, или Lycos — хоть сколько-нибудь конкурентноспособным. Или это недостаточно революционно для вас? Или вы думаете, что Гугл старше? Или что?

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

                                                                                            Другими словами, а если ты круче СТО, то ты сам приглашаешь его на интервью, либо заходишь в его офис и просто выцепляешь его с его рабочего места.
                                                                                            0

                                                                                            Но вы не привели пример :)


                                                                                            В вашей терминологии есть предвзятость: подразумевается, что «копия» это что-то заведомое более плохое, чем «оригинал». Понятно, что наверно есть мелкие ребята, которые просто копированием занимаются, но в реальности и у крупных ребят обычно похожие продукты возникают вокруг похожих идей, и заменить один на другой не всегда просто. Например, Netflix и Amazon Prime. На одном есть сериалы «Загадочные события», на другом «Пацаны». Но я не хочу смотреть «Пацанов». Имеет ли в этом случае значение, кто из них появился раньше? А если нет, то в чем физический смысл довода про «неуникальность»? Вы думаете, у ребят из Амазона техническая сложность задач ниже? Конечно же, нет. Или вот Альтависта и Гугл. Правда ли тут важно кто «копия»? Повлияло ли это на качество продукта, успех в будущем или сложность задач?


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


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

                                                                                              0
                                                                                              Ну нет, я к тому, что придумывать что-то уникальное не надо и всё. не надо глубокого смысла искать. Есть готовый продукт и надо сделать не хуже. К тому же в Яндексе полно уважаемых специалистов, типа Полухина, например, которые плохо сделать не дадут ну или исправят.
                                                                                                0

                                                                                                Ох, если бы всё было так просто :)


                                                                                                Антон крутой, да. Кстати, скоро планирует новый пост опубликовать.

                                                                              0
                                                                              У меня тоже похожее было, я застыл и после 20ти минут тупения в монитор. сказал что я завис, и я без понятия что надо делать. Но зато после интервью мне дали детальнейший отзыв расписали что не так и как оно должно быть
                                                                                +7

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


                                                                                Кстати ещё раньше мода была на тесты на знание языка — вот это вообще жесть.

                                                                                  0
                                                                                  Ерунда.

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

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

                                                                                  Объективно они не настолько выше вас профессиональным классом, насколько они вам это показали.

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

                                                                                  Тем не менее примите как данность — оно встречается.

                                                                                  Но при этом ничего не говорит ни о фирме.
                                                                                  Ни о потенциальных коллегах.

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

                                                                                  Причины этого явления хорошо были показаны, например, в тюремном эксперименте в Стенфорде:

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

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

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

                                                                                    habr.com/ru/post/414973
                                                                                      +1
                                                                                      Причины этого явления хорошо были показаны, например, в тюремном эксперименте в Стенфорде:

                                                                                      … про проблемы которого в той же википедии есть ссылки, в англицкой подробней чем русской.
                                                                                      Участники эксперимента играли в тюрьму. Некоторые прямо намеренно отыгрывали роль как они её видели: "Critics also noted that some of the participants behaved in a way that would help the study, so that, as one "guard" later put it, "the researchers would have something to work with," which is known as demand characteristics."
                                                                                      Причём было указание прессовать "заключённых": "Although Zimbardo interpreted the experiment as having shown that the "prison guards" instinctively embraced sadistic and authoritarian behaviors, Zimbardo actually instructed the "guards" to exert psychological control over the "prisoners"."
                                                                                      То есть, они попросту делали что а) входило в роль; б) было прямо запрошено заказчиком.

                                                                                        –1

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

                                                                                          +2

                                                                                          Странная логика. Вам показывают проблемы дизайна исследования, а вы говорите, что это не отменяет его выводов.

                                                                                            0
                                                                                            Странная логика. Вам показывают проблемы дизайна исследования, а вы говорите, что это не отменяет его выводов.

                                                                                            А в чем конкретно проблемы дизайна? Т.е., да, люди делали то, что:
                                                                                            а) входило в роль; б) было прямо запрошено заказчиком.


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


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


                                                                                            evadesad


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

                                                                                            Все верно. Ровно это (в том числе) в эксперименте и исследовалось.


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

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


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


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

                                                                                              +1
                                                                                              Ноуп, им никто не приказывал, только предлагал.

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

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

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

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

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


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

                                                                                                Нет, этого не было.


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

                                                                                                Нет, этого не было.


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


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

                                                                                                А дальше — уже полная самодеятельность. Ни к каким конкретным действиям "вертухаев" никто не принуждал.


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


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

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


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


                                                                                                С чем тут можно спорить — непонятно.

                                                                                                  0
                                                                                                  Так это "заключенных" не выпускали, т.е. вы сейчас на мою мельницу воду льете — у людей настолько сдвинулось восприятие реальности, что они действительно начали считать, что это нормально кого-то не выпускать!

                                                                                                  А Вы перечитайте кто конкретно не выпускал. Сам же руководитель лично и.


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

                                                                                                  С чем тут можно спорить — непонятно.

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

                                                                                                    +1
                                                                                                    А Вы перечитайте кто конкретно не выпускал. Сам же руководитель лично и.

                                                                                                    При поддержке остальных "работников тюрьмы", ага.


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

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


                                                                                                    Вы немного переворачиваете ситуация — это не стэнфордский эксперимент является частным случаев эксперимента Милгрэма, а наоборот — эксперимент Милгрэма является частным случаем стэнфордского.

                                                                                                      0

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

                                                                                                        0
                                                                                                        Ещё раз, по буквам: ожидаемый результат эксперимента и ожидаемое поведение было донесено до "охранников" заранее, до начала эксперимента.

                                                                                                        Ну да все верно. Установление ролевой модели — это часть эксперимента.


                                                                                                        А не "они сами стали такими в ходе эксперимента"

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


                                                                                                        Не "сами в ходе", а "как задали заранее — так и вели"

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

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

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

                                                                                            0

                                                                                            С собеседованием тоже самое может быть: сказали программисту провести его в первый раз в жизни и он вспоминает такие посты на Хабре и начинает отыгрывать роль крутого собеседующего.

                                                                                              0

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


                                                                                              Эксперимент Милгрэма, кстати, поляки воспроизвели. https://journals.sagepub.com/doi/10.1177/1948550617693060

                                                                                                0

                                                                                                Милгрэма с влиянием авторитета и тут считают затесавшимся, то есть знатно влиявшим эффектом.

                                                                                              0
                                                                                              Ерунда.

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

                                                                                              А.С. Макаренко и Э.В. Ильенков давно научно опровергли туфту, что люди говно по своей природе.
                                                                                                0
                                                                                                А.С. Макаренко и Э.В. Ильенков давно научно опровергли туфту, что люди говно по своей природе.

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

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

                                                                                                  А Ильенков доказал, что человек является продуктом общественной практики, а не чем-то отдельным. Это подтверждается Загорским экспериментом, где сделали людьми слепоглухонемых детей, которые в обычных условиях стали бы почти «овощами». Ну и не забываем про реальных маугли, которые во всём вели себя, как животные, с которыми выросли.
                                                                                                0
                                                                                                Будучи принятыми в коллектив и уже будучи с ними в равном положении вы могли узнать насколько они приятные люди.

                                                                                                Эхм… точно? Или они и тут найдут варианты "реализоваться"?

                                                                                                +9

                                                                                                Я 5 недель уже сижу без работы. Опыт разработки лет 8-9. Каждое техническое собеседование как колоноскопия. С лайвкодингом никогда не сталкивался и, надеюсь, не столкнусь. Это же вообще ад.


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

                                                                                                  0
                                                                                                  Как и автору поста, вам помогла бы работа над ошибками. Да, работа над ошибками, все очень просто.
                                                                                                  Приходим домой после собеседования и сразу выписываем какие были вопросы, как мы на них отвечали и какая была реакция интервьюеров. Бывает, что на некоторые вопросы удалось хорошо ответить, такое сохраняем отдельно и стараемся запомнить к следующему интервью. Те вопросы, где есть какие-то сомнения в ответе или реакция интервьюера нам не понравилась, прорабатываем и находим ответы дома в спокойной обстановке. Так к вашему -дцатому собеседованию у вас будет покрыто 90% наиболее частых вопросов.
                                                                                                    0

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


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

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

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

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

                                                                                                          +2
                                                                                                          Теперь я понимаю, откуда на хабре берутся статьи про ООП, SOLID и прочие баззворды — люди просто к собеседованиям готовятся :-).
                                                                                                    0

                                                                                                    У нас в семье этот ад регулярно на добровольной основе :)

                                                                                                      0
                                                                                                      да, знакомо) Я вот 13 лет с JS суммарно, но на собесах просто большая половина мозга отваливается или занята не тем, чем надо, но все ровно половины мозга обычно достаточно для прохождения тех интервью.
                                                                                                      Но вот лайвкоддинг в маленькой формочке на каком то сайте вообще застал врасплох, я там даже не мог нормально воспринять шрифт, цветовую схему и банально скобки расставить, буквально ослеп ибо не было еще и подсветки блоков/сигнатур.
                                                                                                      Начал писать код, просто чтобы начать что то писать, до конца не поняв ТЗ по реализации API, ибо я ожидал от них спецификацию по интерфейсам, а они примеры вызовов налепили.
                                                                                                      Короче, я как в универе- лучше начать что то делать, чтобы не совсем зафейлить). Очень долго рожал, как потом уже понял, посредственную фигню. Тупка жесткая, сам себе удивился… Просто дно, еще и при этом, в качестве хобби, коллаборатор/около ментейнер пакетов, один с которых с 17лямами загрузок в месяц и 1,5к зависимых модулей :)
                                                                                                      0
                                                                                                      Хоть и не одобряю лайвкодинг, должен признать что через какой-то время привыкаешь и волнение отходит, черствеешь как-то. Начинал всегда с чего-то тривиального, вся оптимизация, красота и пр. — потом, если есть время, в основном устно.
                                                                                                      Если кому не нравится и хочет чтобы я на лайвкодинге фигачил продакшн код нон-стоп — пусть идет лесом.
                                                                                                        +2
                                                                                                        У самого было похожее интервью. Очень странные ощущения. Причем в какую-то задрипанную конторку из региона по профильному языку. Прошло ужасно и, естественно, не написали даже потом. А вот в одну крупную компанию пробовал собеседоваться (причем, только лайвкодинг и был) ради «а почему бы и нет» по совершенно непрофильному языку и на удивление прошло гладко, хотя тоже волновался, но впечатления остались приятнее.
                                                                                                          +8
                                                                                                          Причем в какую-то задрипанную конторку из региона по профильному языку.
                                                                                                          Не надо так делать. В нормальные конторы на нормальную зарплату устроиться, как показывает мой пятнадцатилетний опыт, зачастую проще, приятнее и профита куда больше. У меня есть знакомые в малом бизнесе и не понаслышке знаю, если пойдёшь устраиваться продавцом в задрипаный бутик 2х2 метра — зачастую тебя будут на собесе (и на работе потом) драть и в хвост и в гриву, при зарплате в реальные копейки. С другой стороны, если не совсем олень, можно устроиться в место покрупнее, и получать без нервов зарплату получше, попивая кофеёк в кресле. Это какая-то профдеформация владельцев и мелких руководителей нижних сегментов рынка в постсоветских странах.
                                                                                                            0

                                                                                                            Согласен

                                                                                                          +1

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

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

                                                                                                              Я рассматриваю собесы, тестовые, включая лайвкодинг как презентацию своих знаний и навыков с полным пониманием, что на 100% вряд ли попаду в потребности с одной стороны, ведь какие-то пробелы могут быть выявлены всегда. А, с другой, нужно показать, что при достаточной мотивации за короткий срок могу закрыть конкретные пробелы, знаю куда рыть. Ещё нужно показать свой предпочитаемый подход к разработке и что есть границы, по его изменению, которые я перейти не готов. Понравилось — жду ваших предложений и ответов на мои вопросы. Нет — мне повезло, что потратил на выяснение того, что мы не сработаемся, всего несколько часов, а не год.

                                                                                                              0
                                                                                                              +1
                                                                                                                +1
                                                                                                                Это как с противоположным полом знакомство. Когда вопросы задают, то смотрят подходите друг другу или нет, а не баллы считают

                                                                                                                А что, знакомство со своим полом в этом смысле как-то кардинально отличается?

                                                                                                                  0

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

                                                                                                                    –5
                                                                                                                    Имелось в виду для романтических отношений.

                                                                                                                    Мне кажется, это стоило бы сразу уточнить.

                                                                                                                +1
                                                                                                                почти на всех недавних собесах я писал код онлайн, а их было штук 10, на некоторых даже поисковиками не давали пользоваться, для меня это тупо стресс… я привык думать в спокойной обстановке, попивая чаек
                                                                                                                  +6

                                                                                                                  Есть конторы особо упоротые на TDD, ничего плохого в этом нет, просто заранее кандидату надо сказать. Т.к. навык скоростного TDD прекрасно тренируется, погонял coding kata немного, и будете говорить на одном языке на собеседовании. Хуже когда по факту никакое TDD и не используется в конторе, и на собеседование протащили 'потому что модно', как с теми олимпиадными задачками в Гугле.

                                                                                                                    0
                                                                                                                    Кажется, моду на олимпиадные задачки придумал Гугл, потому что у них реально очередь из кандидатов, и надо отсеивать.
                                                                                                                      0
                                                                                                                      Еще хуже, когда у интервьюеров вертится в голове «ни проектов ни денег больше не стало, а начальство ищет человека — видимо на замену кому-то из нас». Тогда TDD может показаться детскими игрушками…
                                                                                                                        +4
                                                                                                                        Это называется конфликт интересов, можно задать об этом вопрос на начальных этапах. Ситуации, в которых появляются эти конфликты — угроза существующим процессам.
                                                                                                                          0
                                                                                                                          Вопрос-то можно задать — но кто же вам ответит, тем более когда интервьюеров несколько. Именно поэтому, если поведение интервьюеров вам показалось странным — лучше возблагодарить судьбу и поискать более нормальную компанию. А если странным образом ведет себя HR — вдвойне.
                                                                                                                            +1
                                                                                                                            Смотря кому задавать вопрос. Есть не заинтересованные источники, нельзя вот так вот просто взять и пойти и устроиться в произвольную компанию, не понимая, какие у неё текущие финансовые показатели, вероятные интересные проекты и обстановка внутри.
                                                                                                                            При одном из предыдущих трудоустройств я не знал об этих показателях, и в итоге за это поплатился. Хотя там был опыт, и я особо сильно не жалею.
                                                                                                                      +7
                                                                                                                      Любая новая ситуация для человека — стрес. Это нормально. Пройдете десяток и все наладится.

                                                                                                                      «Простейшая университетская задачка». Именно что университетская. Я в университете был последний раз десять лет назад. А на работе таких задач не было. Мозг забывает то, что не вспоминает регулярно. Кто-то здесь помнит уравнение фотосинтеза? А ведь это простая школьная задачка.
                                                                                                                        0
                                                                                                                        (Неожиданно для себя, но даже вспомнил. В школе учился лет 15 назад, и уверен, что за это время ни разу с формулой не встречался. А что было неделю назад — не помню. Память странная штука.)
                                                                                                                          0
                                                                                                                          уравнение фотосинтеза

                                                                                                                          Да я сейчас даже уравнение получения C2H5OH из сахара не вспомню.
                                                                                                                          0
                                                                                                                          В самом лайвкодинге ничего плохого нет. Он ставит целью проверить соображалку разработчика и умение родить какой-то алгоритм.
                                                                                                                          Когда я проводил собеседования, то просил разработчка изобразить какой-нибудь простой алгоритм на целевом языке на доске. Сразу с оговорками, что всякие синтаксические ошибки если и будут — то не страшно. Из задач предлагалось обычно перевернуть строчку задом наперёд или поменять порядок бит в числе на обратный. Требовать парсер выражений писать бессмысленно. Так вот, далеко не все Senior'ы даже с такими задачами справлялись (что, в первую очередь, говорит о качестве рынка разработчиков в целом).

                                                                                                                          Но если к вам приходят чуваки и говорят работать строго в одной парадигме (TDD), то от них надо бежать сломя голову. И есть серьёзные сомнения, что с архитектурой их проекта тоже не всё в порядке, и там костыль на костыле, но зато тесты работают.
                                                                                                                            +4
                                                                                                                            Ну да, я на своём первом интервью 10+ лет назад не смог написать Фибоначи. Передо мной положили листок — и внутри головы все сразу опустело, и я уже даже не особо понял задание, что они спрашивали. Потому что лайв-кодинг — это 80% стресс-тест и в лучшем случае около 20% — проверка навыков. И если бы у меня, даже на привычной мне работе, постоянно стояли бы сзади и смотрели бы, как я пишу код, я бы тоже долго не задержался. Слава-богу, такого нигде нет.
                                                                                                                            Если человек не имеет привычку часто менять работу, или просто часто ходит на собеседования, шансы на успешное прохождение лайф-кодинга и алгоротмичных задач весьма низки. Говорит ли это как-либо о ровне навыков человека? Я не уверен в этом.
                                                                                                                              –5
                                                                                                                              И если бы у меня, даже на привычной мне работе, постоянно стояли бы сзади и смотрели бы, как я пишу код, я бы тоже долго не задержался. Слава-богу, такого нигде нет.


                                                                                                                              Ойли! А вы не слышали про парное программирование? Очень модная фигня, кстати. Не все это делают, но те, кто делают, очень этим гордятся.

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

                                                                                                                              Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.

                                                                                                                              Говорит ли это как-либо о ровне навыков человека? Я не уверен в этом.

                                                                                                                              Может, говорит, может — не говорит. Можно долго рассуждать на эту тему, но те, кто готовятся, попадают в хорошие компании на хорошие зарплаты, а те, кто не готовится, продолжают рассуждать, что это не показатель.
                                                                                                                                +1
                                                                                                                                Ойли! А вы не слышали про парное программирование? Очень модная фигня, кстати. Не все это делают, но те, кто делают, очень этим гордятся.
                                                                                                                                Ну тут совершенно разные ситуации, на самом деле.
                                                                                                                                При парном программировании вы сидите вместе не с каким-то абсолютно незнакомым мутным типом который смотрит на вас с подозрением «а не самозванец ли ты», а с коллегой по проекту с которым знакомы уже какое-то время и который знает что вы нормальный разработчик. И точно так же различаются цели: при парном программировании вы команда, ваша общая цель — написать рабочий код, а если один будет тупить/тормозить, то другой его поддержит и поможет, и это абсолютно естественно. На собеседовании же цель «написать рабочий код» только у вас, а цель интервьюера — оценить как вы умеете это делать, и каждый ваш затуп работает против вас, отнимая ценные очки (общее число которых вы знать не можете, и каждый затуп может оказаться последним), отсюда и стресс.
                                                                                                                                  +3
                                                                                                                                  У меня раньше тоже было такое отношение к собеседующему, типа, «меня оценивают», «ему нельзя доверять», «все советы интервьюера будут засчитаны не в мою пользу, если я ими воспользуюсь, ибо будет выглядеть как подсказка». И все поменялось, когда я перестал бояться интервьюеров и относиться к ним как к своим коллегам, где вы вместе на собеседовании пытаетесь решить общую задачу. Также, есть возможность показать свои софт скилы, как вы умеете слушать и общаться с другими, воспринимать критику.
                                                                                                                                  Бывает, конечно, когда интервьюер &удак и нормальный диалог с ним трудно построить. Но тогда и Вам стоит задуматься: а хотите ли вы работать с такими &удаками в одной компании. Интервью — это обоюдный процесс: они оценивают Вас, Вы — их. Им тоже важно заинтересовать придти работать к ним в компанию (и сэкономить немного на Вашей зарплате, потому что работать с &удаками люди идут только если там платят больше других).
                                                                                                                                    0
                                                                                                                                    Да, интервьюверов тоже оценивают, но это сводится к вежливому поведению и рассказе о проекте/компании. Им не приходится активно защищать свои профессиональные навыки. Для них это не стресс, а рутина, или даже навязанная обязанность, как это бывало со мной.
                                                                                                                                    Раньше, если хорошо подобрал компанию и она тебе подходила по профилю, можно было с очень высокой вероятностью устроиться туда, сейчас же люди зачастую собеседуются десятки раз, ибо это превратилось в лотерею, ну или в длительное задротсво.
                                                                                                                                      +1

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

                                                                                                                                  +2
                                                                                                                                  Ойли! А вы не слышали про парное программирование?

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

                                                                                                                                  И все поменялось, когда я перестал бояться интервьюеров

                                                                                                                                  Это приходит с практикой, а не «потому что так подумал». Покуда не пойдешь их какое-то количество, спокойствие не придет.

                                                                                                                                  Еще раз: к собеседованиям надо готовиться

                                                                                                                                  Хах, в этом-то и проблема. Почему это вдруг, надо (кроме того, конечно, что печальные современные реалии так диктуют)?
                                                                                                                                  Какая вообще цель технического интервью?
                                                                                                                                  Проверить, кто как/сколько подготовился быстро и правильно решать олимпиадные задачи под давлением? Оценить, насколько человек задротил litcode и насколько способен в стрессе это воспроизвести?
                                                                                                                                  Или, все же, быть может, подобрать своей компании/команде подходящего по опыту и навыкам сотрудника?
                                                                                                                                  Конечно, если человек — джун, то там должен быть достаточно энтузиазма/памяти с универа/отчаяния, что бы это канало.
                                                                                                                                  Но после 10+ лет в продакшене, думаете, мне интересно готовить этот непотреб, который даже не служит задаче, которую, якобы, должен решать? Нет. Это последнее, что я хочу делать, возвращаясь поздно вечером домой, потому что это уже не так задорно и весело, как было когда-то, но в основном, потому что это переливание из пустого в порожнее.
                                                                                                                                    –1
                                                                                                                                    Но после 10+ лет в продакшене, думаете, мне интересно готовить этот непотреб, который даже не служит задаче, которую, якобы, должен решать? Нет.

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

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

                                                                                                                                      И да, вы совершенно правы про FAAGN и пр… Они, впрочем, сами заявляют, что им норм большой процент false-negatives, т.е. то что они отвергают много хороших специалистов, которые им на самом деле подошли бы. Но у них огромная очередь, всех не принять, вот и придумали, как отсеивать дополнительно.
                                                                                                                                      Проблема только в том что не все компании — это FAANG, но они этого не понимают. А потому продолжают в лайв-кодинг просит делать неприличные вещи с деревьями, и потом жаловаться на то что не могут полгода закрыть одну вакансию, когда у них в продакшене унылый REST API с каким-нибудь legacy/говнокодом.
                                                                                                                                    0

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

                                                                                                                                      0
                                                                                                                                      Еще раз: к собеседованиям надо готовиться. Это не так, что сегодня вместо работы пошел на собеседование, а завтра — опять на работу. В хорошие компании люди по полгода готовятся к собеседованиям, по вечерам решая задачи на LeetCode, прорабатывая дизайны разных систем для дизайн интервью, делая mock-интервью.

                                                                                                                                      К собеседованиям в нормальные компании готовится не надо.
                                                                                                                                      Потому что в нормальных компаниях оценивают навык работы а не навык прохождения собеседований.
                                                                                                                                      И нет, Гугл и прочие подобные нормальными не являются.
                                                                                                                                      Да, там есть пончики, настольный теннис, огромная зарплата и интересные задачи на острие технологий (но попасть на них очень и очень сложно, в большинстве случаев ты будешь писать нечто супер скучное для чего не требуется не один из навыков которые у тебя спрашивали на собеседовании) и строчка в резюме «я работал в Гугле».
                                                                                                                                      Собственно за зарплатой и строчкой в резюме туда и идут.
                                                                                                                                      Но это не делает Гугл нормальной компанией.
                                                                                                                                        0
                                                                                                                                        А как оценить навык работы?
                                                                                                                                        Я просто вижу несколько способов —
                                                                                                                                        1. устроить на испытательный срок, причем, в зависимости от бизнес-логики, в которую понадобится вникать, срок может варьироваться от месяца до года. — не подходит по очевидным причинам.
                                                                                                                                        2. рекомендации с прошлой работы от начальства — не видел ни одной норррмальной конторы, где такое просили бы (в России)
                                                                                                                                        3. поверить кандидату на слово, что он хорошо работает. Автор статьи, под которой мы комментим, как раз про такое писал не раз — что он знает, что мало чего умеет, а собесы прошёл исключительно на софт-скиллах, нагрузив интервьюверов — читай обманув. В норррмальных конторах работают лохи, которых можно легко обмануть?

                                                                                                                                        Ничего не упустил?
                                                                                                                                          +2
                                                                                                                                          А как оценить навык работы?

                                                                                                                                          Заглянуть в код, написанный соискателем? Подойдет OSS проект, коммиты в чужие проекты, тестовое задание на крайняк.


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

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

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

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

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


                                                                                                                                              люди, которые делают коммиты в чужие проекты либо сверхлюди

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


                                                                                                                                              либо недостаточно времени уделяют основной работе

                                                                                                                                              Да-да. И те, кто на Stack Overflow отвечают — делают это в ущерб работе. И в блоги тоже пишут лентяи. Слыхали, знаем. Я лично не скрываю ни активность на SO, ни PR в чужие проекты, ни почти десяток активно поддерживаемых и развиваемых мною лично библиотек, — от руководства. И ему, руководству, почему-то не приходит в голову сделать из этого вывод, что я — тунеядец.


                                                                                                                                              Про тестовое задание вам тоже выскажут своё «фи» секта свидетелей ненужного тестового задания [...]

                                                                                                                                              Так это же прекрасно: мы расстанемся с такими кандидатами на берегу, даже не встретившись. И я лично уж точно сожалеть не стану.