Просто на рынке пошел большой перевес в сторону корпоратов. Они всегда отличались характеристиками из статьи, но при этом генерировали огромные деньги. Всегда была более шустрая, гибкая и менее мозговыносящая альтернатива из стартапов и среднего размера компаний, где в целом восприятие мира более адекватное, шустрое и... ненадежное.
Деньги (кредиты) подорожали. По всему миру. Рисковать при дорогих деньгах люди стали меньше. Корпораты пока держатся на жирках, которые накопили до этого, но все равно оптимизируют расходы. Среднячки и стартапы стали сворачиваться и перестали открываться, потому что очень мало выхлопа, а риски сесть в лужу большие.
Ждем дешевых денег, тогда ситуация стабилизируется. Но не факт, что в IT, потому что помимо дорогих денег еще пошла дискредитация сферы в том числе и с ИИ, и инвесторы наверняка сомнительнее будут относиться к новым затеям от IT, перестраховываясь в других сферах деятельности.
Тут каждый волен сам выбирать, схема же очень гибкая, и можно перегнуть со многих сторон:
1) Работодатель может затягивать испытательный срок под разными предлогами из-за того, что не научился нормально оценивать результаты в сжатые сроки.
2) Работодатель может просто устроить ферму желающих поработать и под предлогом "нужно еще посмотреть" экономить на ФОТе, получая приемлимый пласт работ от испытуемых, которых после окончания времянки не продлевать.
3) Работник может выдавать результаты только в первую неделю, когда все в новинку, потом получить контракт и расслабиться. Здесь еще спасет испытательный срок в самом контракте, но встречал ситуацию, когда после его прохождения людей будто подменяли.
4) Может возникнуть поток людей мимопроходилов, для которых будут за неделю для себя зарабатывать определенные деньги, уходить с ними на месяц, а потом искать других таких работодателей.
5) В целом может сложиться так, что процессы компании настолько не готовы к такому воплощению идеи, что компанию разворотит со всех сторон, т.к. вскроются различные гнойники которые не получится залатать.
Это лишь первое что в голову приходит, если рассматривать эту схему в деталях. Конечно, нужно ее полировать, и дорихтовывать. По одному комментарию на хабре процесс не строится.
Но я не однократно видел фейлы при найме с обоих сторон процесса, и в последние годы этот процесс становится все печальнее и печальнее. Потому глядя на текущие реалии и появилась такая идея, которая его переиначивает и делает попроще (а может и не попроще, и много корнер-кейсов всплывет при детальной проработке).
Со своей стороны всегда отмечал, что найм процесс обоюдный. И неоднократно сам не продолжал работать в компаниях, которые не прошли испытательный срок с моей стороны. Как бы складно не пели на собеседованиях про крутость, реалии всегда другие. Потому считаю облегченный испытательный срок довольно неплохой альтернативой.
Потому я писал про неполный рабочий день. И рисковые могут поставить на выгорание и работу 12 часов, и нерисковые не будут заняты на полную, чтобы была возможность параллельно вести диалоги с другими компаниями на предмет поработать.
Найм оптимизировать хватит, но давайте каждый день со всех сторон кричать, что он сломан?
А по поводу недели такое работает только для безработных
Так в текущих реалиях рынка безработных намного больше. Прошли времена, когда можно было без проблем сменить компанию и получить несколько офферов, при этом еще сидя на хороших условиях в текущей компании.
Из недавнего мой кейс собеса на позицию тех дира.
В статье и комментариях идет обсуждение рядовых айтишников, а не управленцев. Максимум предложенная схема работает до уровня тимлида.
У управленцев совсем другие алгоритмы найма, работы, испытательного срока и компенсации. Вы натянули сову на глобус.
А можете поделиться ссылкой? Интересно было бы почитать доводы. Просто с моей стороны эта ситуация воспринимается немного иначе: от многоэтапного цирка с конями при найме убытков будет поболее, чем при упрощенном найме + испытательном сроке.
Особенно если посчитать тех, кто после многоэтапного отбора решил покинуть компанию на испытательном сроке плюс время дорогих специалистов, которые участвовали в этом цирке с конями.
Очень сильно зависит от домена и процессов работодателя. Да, есть такие, где онбординг может легко расстянуться на год. А есть, в которых за первый день твой код уже окажется на проде.
И компания на таких маленьких дистанциях может делать выводы и адаптировать процессы внутри так, чтобы онбординг был простым. Либо долгий онбординг может сигнализировать об огромном bus-факторе внутри компании, и может послужить сигналом к пересборке критических вещей, распределяя с них высокий уровень ответственности на другие команды.
Можно облегчить процесс найма в компанию. Подписать временный договор на неполный рабочий день с условной зарплатой в 0.5 от итоговой суммы, которую закладывали на вакансию, дать человеку поработать недельку-другую, и ударить по рукам полным контрактом, если качество его работы устроит. Перед этим можно полчаса-час поговорить "за жизнь" на предмет отсева совсем неадекватов.
И компании легче закрывать вакансии, и кандидат может осознать, куда он идет работать, и стоит ли ему в таких процессах вариться.
Хакатон - это тоже соревнование со стрессом и потогонкой, которое оторвано от реального положения дел при работе в компании.
Как говорил мой первый тимлид: "нет лучше собеседования, чем испытательный срок в компании".
Рынок диктует условия. И на рынке предложений по современному стеку и подходам больше. Ограничиваясь текущим стеком рано или поздно вы отстанете от рынка и ваш опыт перестанет быть релевантным.
Судя по тому же gemini в подсказках гугла на распространенные вопросы, нейросети еще плохо показывают примеры реального опыта. Потому я и говорю про смену ракурса вопросов с "расскажи мне вызубренную теорию" до "покажи, как в своем опыте использовался тот или иной подход, и какие подходы можно было использовать в альтернативе". Отличить джуна-вкатуна с зубрежкой и человека с богатым опытом в данном случае не предоставляется сложным. И по ответам видно в том числе и то, как человек анализирует свой опыт, рефлексирует над ним и предлагает более корректные альтернативы.
У нас кардинально отличаются точки зрения на собеседования. Предлагаю завершить этот баттл :)
Да почему же "правильных ответов"? Это просто пример практических вопросов, являющийся альтернативой лайф-кодингу. Кандидат может иметь свое мнение насчет этих нововведений языка и оно может противоречить мнению интервьюера. Другое дело, что он знает про эти тонкости и сферу их применения на практике.
Имхо, профи следит за развитием инструментов, которые использует при разработке. Если этого не происходит, обычно его опыт считается устаревшим, и компании потребуется n-ое количество времени на дообучение, что не всегда целесообразно. Я встречал зубров, которые писали на версии языка десятилетней давности, и их переобучение занимало от полугода, чтобы они вошли в темп современное разработки на уровне middle хотя бы. А некоторые и вовсе не проходили переобучение, и компания несла только убытки.
Для меня подтягивание знаний по ключевому стеку - необходимый обряд перед прохождением интервью. И вы удивитесь, но так делают примерно 50% разработчиков судя по моей личной статистике.
С такими ответами КПД таков, что вы не пройдете интервью, потому что:
1) Не заинтересованы в развитии языка, и не следите за инструментом, который вас кормит.
2) Не заинтересованы в интервью (такой ответ про интерфейсы грубоват, и если его не расширить доп. информацией, будет восприниматься как огромный минус, но если мне так отвечают, я задаю наводящие вопросы из разряда "А где нужно было?")
В реальной ситуации люди отвечают иначе. В 95% случаев интервью люди заинтересованы в вакансии, и стараются ответить то, что знают или не знают по теме. В остальных случаях бывает, что у человека день не задался или он все-таки очень токсичный, но интервью в таком случае быстро сворачивается.
А вы уверены, что это задачка для лайв-кодинга? Похоже на тестовое больше.
Для эндпоинта нужно:
1) Выбрать фреймворк, запустить на нем скелетон-приложение или найти готовый проект
2) Написать миграции, описать модели данных
3) Понять, какую вы ожидаете архитектуру. Простую или слоистую. Раз уж про DTO заговорили. Если делим на слои - еще продумать вложенность и абстракции участвующие в эндпоинте, их описать
4) Заморочиться с окружением, т.к. может быть необходимость проверки кода для понимания, где в нем допущен баг или неточность
Наверное, это займет более получаса времени.
Тут я бы смотрел в сторону тестовового задания в виде готового приложения с написанными тестами под его функционал и желаемую архитектуру, с дальнейшим обсуждением результатов после вашего ревью кода.
Но все же придерживаюсь мнения, что по разговору "по душам" с разработчиком можно понять многое и без кода, который он пишет. Просто составить блоки теоретических и практических вопросов по темам, касающихся разработки (язык, паттерны, бд, тулзы, расследование инцидентов), и понять, насколько вы подходите друг другу по его ответам. Сам действую именно таким методом.
QA пропустил баг, остальные разработчики из команды или лид пропустили баг на ревью, а виноват разработчик, который писал код?
Нет, в командной разработке так не работает. Виновата вся команда без перехода на личности, и требуется править процессы, чтобы ситуаций не повторялось.
А устранить баг может и непричастный к написанию разработчик/лид. На то она и командная разработка, что люди друг друга страхуют и выручают в различных ситуациях, даже если кто-то перестал выходить на связь. Не раз меня так выручали от ночных правок и я страховал людей срочнофикся микробаги, когда они были заняты по каким-либо причинам. Либо просто видел баг и решал не переключать человека от другой важной задачи, и фиксил сам.
Винить причастного к написанию кода в любом случае не стоит. Всегда есть ряд обстоятельств, которые в первую очередь требуют разбора. Смотрите на них. Переход на личности в данном случае лишь подтверждает кавардак в процессах.
Так в статье как раз описывается, что лайф-кодинг не позволяет это посмотреть. Он лишь погружает человека в стрессовую атмосферу, и его мышление становится иным. Это может отражаться как на ходе мыслей, так и на написании кода (например, экономлю время под давлением - не называю переменные в полный рост или забиваю на форматирование).
И любую теорию можно проверить практикой. Достаточно поставить вопрос немного иначе. Не "для чего нужны интерфейсы?", а "в каких случаях использовали интерфейсы?". Не "скажите новые особенности языка в 15ой версии", а "что нового использовали из последней версии языка" и т.д.
Чаще всего разработчик под себя настраивает среду разработки, устанавливает плагины и так далее. То, что предлагают для лайвкодинга компании - либо собственные поделки, либо какие-то решения из разряда "вот вам ссылка на онлайн-блокнот". И то и другое не удобно и может быть новым для кандидата, и накладывать доп. уровень стресса.
2) Нерелевантность задач
Задачи для лайвкодинга вообще стали оторваны от реального мира. Там все больше и больше низкоуровневых материй, которыми программисты оперируют в ничтожном проценте своего рабочего времени. Чаще всего задачи более высокоуровневые, и это низкоуровневое месиво будет просто убыточно для компании, если в разработке сделать упор именно на него.
3) Накопленный негативный опыт
Чем чаще был на лайвкодинге, тем больше за плечами вспоминались прошлые случаи, которые только тратили мои нервы и время. Я начинал с лайвкодинга на листочках ручкой когда только в it пошел, и попадались индивиды, которые говорили "код не сработает, вы точку с запятой пропустили". Я еще тогда был в недоумении: ручку использую только для схематики или когда подписать надо что-нибудь, а для кода у меня удобная клавиатура. Зачем вам это надо? Так или иначе, при упоминании лайвкодинга у меня начинаются вьетнамские флешбеки с теми курьезными случаями, когда лайвкодинг не удался. К слову, не удался он в процентах 80 случаев из-за "боязни сцены", которую описал автор статьи.
Потому всегда выпытываю компанию, что у нее скрывается под "техническим интервью" (прошу указать этапы собеседования и форматы этих этапов, и только потом решаю, подходит оно мне или нет). Сэкономило много нервов, но, возможно, были какие-то упущенные вкусные предложения. Все равно не жалею.
На самом деле, я почти никогда не встречал компании, которые изолировали разработчиков только до написания кода. Везде была лазейка в стиле "проявляешь инициативу - получаешь разнообразнее задачи и больше ответственности".
Это может быть ответственность как техническая из разряда "я писал код и придумал как его улучшить", так и процессная из разряда "у меня предложение по флоу задач и документированию нашего функционала, кажется, у нас просадка в полизводительнлсти из-за этого", так и продуктовая из разряда "да я вот видел в похожих проектах делали этот момент иначе, и, кажется, мы сэкономим много времени без текущего переусложнения".
Другое дело, нужно ли это самому разработчику, и готов ли он ввязываться в эти приключения. На самом деле, зависит от атмосферы в команде. Где-то она задает плодотворный темп и дает возможность проявлять инициативу сотрудникам, а где-то лишь делает вид и действует по принципу "я - начальник, ты - дурак". В плодотворной атмосфере легче начинать такие движения, а плохая лишь загубит на корню любое желание проявлять инициативу. Но первоначальный шаг должен быть все равно от желающего роста.
А зачем тогда разработчику нужен заказчик, если он сам прекрасно знает, как развивать продукт? Сделал бы свой да занимался им.
Вы описали роли продуктолога и аналитика, но никак не разработчика. Из-за такого смешения ответственности и осуперменивания разработчиков и происходит описанное в статье. Это уже не разработка, а хаос. Разработка это как раз воплощение идей в коде и архитектуре приложения.
Замечал, что чем больше хаоса в процессах компании, тем меньше удается писать код. Основное время начинает занимать варево в этом хаосе либо попытках его упорядочить. И упорядочивание хаоса в рамках команды довольно реально, если все понимают свои роли и цели. Но на межкомандном взаимодействии часто идет просадка и давление. А частое межкомандное взаимодействие нередко порождает расплывчатая изначальная цель функционала, который хочет инициатор.
Подобная статистика майкрософта лишь говорит о довольно посредственных процессах и отсутствии понимания ключевых результатов при разработке.
Для себя считаю идеальным 50/50 после примерно 15 лет в разработке. В периоды джуномиддловости эта пропорция была скорее в 80/20 в сторону кода. И важно, чтобы время было гармонично распределено: полдня - углубленный код, полдня - созвоны. Когда ты раз в час меняешь деятельность и переключаешься из кода в созвоны, ничего хорошего не получается. Помню, даже был инициатором dnd-времени в одной компании, где договорились разработку не тревожить в первую половину рабочего дня. Конечно, не всегда это срабатывало, но в целом, было поспокойнее.
Просто на рынке пошел большой перевес в сторону корпоратов. Они всегда отличались характеристиками из статьи, но при этом генерировали огромные деньги. Всегда была более шустрая, гибкая и менее мозговыносящая альтернатива из стартапов и среднего размера компаний, где в целом восприятие мира более адекватное, шустрое и... ненадежное.
Деньги (кредиты) подорожали. По всему миру. Рисковать при дорогих деньгах люди стали меньше. Корпораты пока держатся на жирках, которые накопили до этого, но все равно оптимизируют расходы. Среднячки и стартапы стали сворачиваться и перестали открываться, потому что очень мало выхлопа, а риски сесть в лужу большие.
Ждем дешевых денег, тогда ситуация стабилизируется. Но не факт, что в IT, потому что помимо дорогих денег еще пошла дискредитация сферы в том числе и с ИИ, и инвесторы наверняка сомнительнее будут относиться к новым затеям от IT, перестраховываясь в других сферах деятельности.
Отличный пример, когда удаленка не работает. И как всегда, проблемы в процессах:
1) Прототип с размытыми требованиями, раз по ним требуется так много уточнений и диалогов.
2) Проблемы декомпозиции задач, раз ничего не работает и столько багов породила одна задача.
3) Проблемы контроля, раз разраб может на неделю исчезать, возвращаясь с непонятным результатом.
4) Проблемы с синхронизацией по времени. Обычно у удаленной компании есть рекомендуемые часы присутствия для решения срочных вопросов.
5) Проблемы работы с асинхронщиной и приоритизацией проблем, потому что по эмоциям видно, что "все срочно". Ну или банального планирования нет.
Да, без отладки процессов работать на удаленке довольно сложно.
Тут каждый волен сам выбирать, схема же очень гибкая, и можно перегнуть со многих сторон:
1) Работодатель может затягивать испытательный срок под разными предлогами из-за того, что не научился нормально оценивать результаты в сжатые сроки.
2) Работодатель может просто устроить ферму желающих поработать и под предлогом "нужно еще посмотреть" экономить на ФОТе, получая приемлимый пласт работ от испытуемых, которых после окончания времянки не продлевать.
3) Работник может выдавать результаты только в первую неделю, когда все в новинку, потом получить контракт и расслабиться. Здесь еще спасет испытательный срок в самом контракте, но встречал ситуацию, когда после его прохождения людей будто подменяли.
4) Может возникнуть поток людей мимопроходилов, для которых будут за неделю для себя зарабатывать определенные деньги, уходить с ними на месяц, а потом искать других таких работодателей.
5) В целом может сложиться так, что процессы компании настолько не готовы к такому воплощению идеи, что компанию разворотит со всех сторон, т.к. вскроются различные гнойники которые не получится залатать.
Это лишь первое что в голову приходит, если рассматривать эту схему в деталях. Конечно, нужно ее полировать, и дорихтовывать. По одному комментарию на хабре процесс не строится.
Но я не однократно видел фейлы при найме с обоих сторон процесса, и в последние годы этот процесс становится все печальнее и печальнее. Потому глядя на текущие реалии и появилась такая идея, которая его переиначивает и делает попроще (а может и не попроще, и много корнер-кейсов всплывет при детальной проработке).
Со своей стороны всегда отмечал, что найм процесс обоюдный. И неоднократно сам не продолжал работать в компаниях, которые не прошли испытательный срок с моей стороны. Как бы складно не пели на собеседованиях про крутость, реалии всегда другие. Потому считаю облегченный испытательный срок довольно неплохой альтернативой.
Потому я писал про неполный рабочий день. И рисковые могут поставить на выгорание и работу 12 часов, и нерисковые не будут заняты на полную, чтобы была возможность параллельно вести диалоги с другими компаниями на предмет поработать.
Найм оптимизировать хватит, но давайте каждый день со всех сторон кричать, что он сломан?
Так в текущих реалиях рынка безработных намного больше. Прошли времена, когда можно было без проблем сменить компанию и получить несколько офферов, при этом еще сидя на хороших условиях в текущей компании.
В статье и комментариях идет обсуждение рядовых айтишников, а не управленцев. Максимум предложенная схема работает до уровня тимлида.
У управленцев совсем другие алгоритмы найма, работы, испытательного срока и компенсации. Вы натянули сову на глобус.
Давайте уже ковид еще один. Чтобы уж точно передумали в это туда-обратно играть.
А можете поделиться ссылкой? Интересно было бы почитать доводы. Просто с моей стороны эта ситуация воспринимается немного иначе: от многоэтапного цирка с конями при найме убытков будет поболее, чем при упрощенном найме + испытательном сроке.
Особенно если посчитать тех, кто после многоэтапного отбора решил покинуть компанию на испытательном сроке плюс время дорогих специалистов, которые участвовали в этом цирке с конями.
Очень сильно зависит от домена и процессов работодателя. Да, есть такие, где онбординг может легко расстянуться на год. А есть, в которых за первый день твой код уже окажется на проде.
И компания на таких маленьких дистанциях может делать выводы и адаптировать процессы внутри так, чтобы онбординг был простым. Либо долгий онбординг может сигнализировать об огромном bus-факторе внутри компании, и может послужить сигналом к пересборке критических вещей, распределяя с них высокий уровень ответственности на другие команды.
Можно облегчить процесс найма в компанию. Подписать временный договор на неполный рабочий день с условной зарплатой в 0.5 от итоговой суммы, которую закладывали на вакансию, дать человеку поработать недельку-другую, и ударить по рукам полным контрактом, если качество его работы устроит. Перед этим можно полчаса-час поговорить "за жизнь" на предмет отсева совсем неадекватов.
И компании легче закрывать вакансии, и кандидат может осознать, куда он идет работать, и стоит ли ему в таких процессах вариться.
Хакатон - это тоже соревнование со стрессом и потогонкой, которое оторвано от реального положения дел при работе в компании.
Как говорил мой первый тимлид: "нет лучше собеседования, чем испытательный срок в компании".
Рынок диктует условия. И на рынке предложений по современному стеку и подходам больше. Ограничиваясь текущим стеком рано или поздно вы отстанете от рынка и ваш опыт перестанет быть релевантным.
Судя по тому же gemini в подсказках гугла на распространенные вопросы, нейросети еще плохо показывают примеры реального опыта. Потому я и говорю про смену ракурса вопросов с "расскажи мне вызубренную теорию" до "покажи, как в своем опыте использовался тот или иной подход, и какие подходы можно было использовать в альтернативе". Отличить джуна-вкатуна с зубрежкой и человека с богатым опытом в данном случае не предоставляется сложным. И по ответам видно в том числе и то, как человек анализирует свой опыт, рефлексирует над ним и предлагает более корректные альтернативы.
У нас кардинально отличаются точки зрения на собеседования. Предлагаю завершить этот баттл :)
Да почему же "правильных ответов"? Это просто пример практических вопросов, являющийся альтернативой лайф-кодингу. Кандидат может иметь свое мнение насчет этих нововведений языка и оно может противоречить мнению интервьюера. Другое дело, что он знает про эти тонкости и сферу их применения на практике.
Имхо, профи следит за развитием инструментов, которые использует при разработке. Если этого не происходит, обычно его опыт считается устаревшим, и компании потребуется n-ое количество времени на дообучение, что не всегда целесообразно. Я встречал зубров, которые писали на версии языка десятилетней давности, и их переобучение занимало от полугода, чтобы они вошли в темп современное разработки на уровне middle хотя бы. А некоторые и вовсе не проходили переобучение, и компания несла только убытки.
Для меня подтягивание знаний по ключевому стеку - необходимый обряд перед прохождением интервью. И вы удивитесь, но так делают примерно 50% разработчиков судя по моей личной статистике.
С такими ответами КПД таков, что вы не пройдете интервью, потому что:
1) Не заинтересованы в развитии языка, и не следите за инструментом, который вас кормит.
2) Не заинтересованы в интервью (такой ответ про интерфейсы грубоват, и если его не расширить доп. информацией, будет восприниматься как огромный минус, но если мне так отвечают, я задаю наводящие вопросы из разряда "А где нужно было?")
В реальной ситуации люди отвечают иначе. В 95% случаев интервью люди заинтересованы в вакансии, и стараются ответить то, что знают или не знают по теме. В остальных случаях бывает, что у человека день не задался или он все-таки очень токсичный, но интервью в таком случае быстро сворачивается.
А вы уверены, что это задачка для лайв-кодинга? Похоже на тестовое больше.
Для эндпоинта нужно:
1) Выбрать фреймворк, запустить на нем скелетон-приложение или найти готовый проект
2) Написать миграции, описать модели данных
3) Понять, какую вы ожидаете архитектуру. Простую или слоистую. Раз уж про DTO заговорили. Если делим на слои - еще продумать вложенность и абстракции участвующие в эндпоинте, их описать
4) Заморочиться с окружением, т.к. может быть необходимость проверки кода для понимания, где в нем допущен баг или неточность
Наверное, это займет более получаса времени.
Тут я бы смотрел в сторону тестовового задания в виде готового приложения с написанными тестами под его функционал и желаемую архитектуру, с дальнейшим обсуждением результатов после вашего ревью кода.
Но все же придерживаюсь мнения, что по разговору "по душам" с разработчиком можно понять многое и без кода, который он пишет. Просто составить блоки теоретических и практических вопросов по темам, касающихся разработки (язык, паттерны, бд, тулзы, расследование инцидентов), и понять, насколько вы подходите друг другу по его ответам. Сам действую именно таким методом.
QA пропустил баг, остальные разработчики из команды или лид пропустили баг на ревью, а виноват разработчик, который писал код?
Нет, в командной разработке так не работает. Виновата вся команда без перехода на личности, и требуется править процессы, чтобы ситуаций не повторялось.
А устранить баг может и непричастный к написанию разработчик/лид. На то она и командная разработка, что люди друг друга страхуют и выручают в различных ситуациях, даже если кто-то перестал выходить на связь. Не раз меня так выручали от ночных правок и я страховал людей срочнофикся микробаги, когда они были заняты по каким-либо причинам. Либо просто видел баг и решал не переключать человека от другой важной задачи, и фиксил сам.
Винить причастного к написанию кода в любом случае не стоит. Всегда есть ряд обстоятельств, которые в первую очередь требуют разбора. Смотрите на них. Переход на личности в данном случае лишь подтверждает кавардак в процессах.
Так в статье как раз описывается, что лайф-кодинг не позволяет это посмотреть. Он лишь погружает человека в стрессовую атмосферу, и его мышление становится иным. Это может отражаться как на ходе мыслей, так и на написании кода (например, экономлю время под давлением - не называю переменные в полный рост или забиваю на форматирование).
И любую теорию можно проверить практикой. Достаточно поставить вопрос немного иначе. Не "для чего нужны интерфейсы?", а "в каких случаях использовали интерфейсы?". Не "скажите новые особенности языка в 15ой версии", а "что нового использовали из последней версии языка" и т.д.
Еще добавлю к минусам лайвкодига следующее:
1) Незнакомые инструменты
Чаще всего разработчик под себя настраивает среду разработки, устанавливает плагины и так далее. То, что предлагают для лайвкодинга компании - либо собственные поделки, либо какие-то решения из разряда "вот вам ссылка на онлайн-блокнот". И то и другое не удобно и может быть новым для кандидата, и накладывать доп. уровень стресса.
2) Нерелевантность задач
Задачи для лайвкодинга вообще стали оторваны от реального мира. Там все больше и больше низкоуровневых материй, которыми программисты оперируют в ничтожном проценте своего рабочего времени. Чаще всего задачи более высокоуровневые, и это низкоуровневое месиво будет просто убыточно для компании, если в разработке сделать упор именно на него.
3) Накопленный негативный опыт
Чем чаще был на лайвкодинге, тем больше за плечами вспоминались прошлые случаи, которые только тратили мои нервы и время. Я начинал с лайвкодинга на листочках ручкой когда только в it пошел, и попадались индивиды, которые говорили "код не сработает, вы точку с запятой пропустили". Я еще тогда был в недоумении: ручку использую только для схематики или когда подписать надо что-нибудь, а для кода у меня удобная клавиатура. Зачем вам это надо? Так или иначе, при упоминании лайвкодинга у меня начинаются вьетнамские флешбеки с теми курьезными случаями, когда лайвкодинг не удался. К слову, не удался он в процентах 80 случаев из-за "боязни сцены", которую описал автор статьи.
Потому всегда выпытываю компанию, что у нее скрывается под "техническим интервью" (прошу указать этапы собеседования и форматы этих этапов, и только потом решаю, подходит оно мне или нет). Сэкономило много нервов, но, возможно, были какие-то упущенные вкусные предложения. Все равно не жалею.
На самом деле, я почти никогда не встречал компании, которые изолировали разработчиков только до написания кода. Везде была лазейка в стиле "проявляешь инициативу - получаешь разнообразнее задачи и больше ответственности".
Это может быть ответственность как техническая из разряда "я писал код и придумал как его улучшить", так и процессная из разряда "у меня предложение по флоу задач и документированию нашего функционала, кажется, у нас просадка в полизводительнлсти из-за этого", так и продуктовая из разряда "да я вот видел в похожих проектах делали этот момент иначе, и, кажется, мы сэкономим много времени без текущего переусложнения".
Другое дело, нужно ли это самому разработчику, и готов ли он ввязываться в эти приключения. На самом деле, зависит от атмосферы в команде. Где-то она задает плодотворный темп и дает возможность проявлять инициативу сотрудникам, а где-то лишь делает вид и действует по принципу "я - начальник, ты - дурак". В плодотворной атмосфере легче начинать такие движения, а плохая лишь загубит на корню любое желание проявлять инициативу. Но первоначальный шаг должен быть все равно от желающего роста.
А зачем тогда разработчику нужен заказчик, если он сам прекрасно знает, как развивать продукт? Сделал бы свой да занимался им.
Вы описали роли продуктолога и аналитика, но никак не разработчика. Из-за такого смешения ответственности и осуперменивания разработчиков и происходит описанное в статье. Это уже не разработка, а хаос. Разработка это как раз воплощение идей в коде и архитектуре приложения.
Замечал, что чем больше хаоса в процессах компании, тем меньше удается писать код. Основное время начинает занимать варево в этом хаосе либо попытках его упорядочить. И упорядочивание хаоса в рамках команды довольно реально, если все понимают свои роли и цели. Но на межкомандном взаимодействии часто идет просадка и давление. А частое межкомандное взаимодействие нередко порождает расплывчатая изначальная цель функционала, который хочет инициатор.
Подобная статистика майкрософта лишь говорит о довольно посредственных процессах и отсутствии понимания ключевых результатов при разработке.
Для себя считаю идеальным 50/50 после примерно 15 лет в разработке. В периоды джуномиддловости эта пропорция была скорее в 80/20 в сторону кода. И важно, чтобы время было гармонично распределено: полдня - углубленный код, полдня - созвоны. Когда ты раз в час меняешь деятельность и переключаешься из кода в созвоны, ничего хорошего не получается. Помню, даже был инициатором dnd-времени в одной компании, где договорились разработку не тревожить в первую половину рабочего дня. Конечно, не всегда это срабатывало, но в целом, было поспокойнее.
Эххх, а я думал таки найду соответствие заголовка с содержимым в статье :(