Некоторым людям нравятся собеседования с написанием кода. Я к их числу не отношусь.
Недавно мне на LinkedIn попался пост такого содержания:
Мы задаём каждому соискателю тривиальную задачу на программирование. Что-нибудь вроде: «Дан список чисел, нужно вернуть сумму чётных из них». И такая задача не предполагается как сложная или заумная, и её цель не в том, чтобы кого-то отсеять, теоретически.
Это лишь базовая проверка. Разработчик или SRE с опытом от 6 до 10 лет должен решать такие во сне, согласитесь?
Оказывается, нет.
Где-то 75% кандидатов не справляются. И не только джуниоры. Я говорю о людях с приставкой «Senior» в их квалификации. О людях, которые заявляют, что учат новичков. О тех, кто говорит, что имеет за плечами годы опыта в продакшене.
Для меня это загадка.
Поначалу звучит абсурдно. С чего бы вдруг старший разработчик, который уже много лет пишет код, провалился на таком простом алгоритме? Неужели он внезапно забыл, как программировать? Возможно. Но я вижу это иначе.
Небольшой курьёз из жизни
Четыре года назад я пробовал устроиться в Toptal. В итоге я прошёл первый этап. Это было 90-минутное испытание на Codility — всего три задачи, из которых достаточно сделать две. Я сделал все три. Последняя была реально сложной.
После этого я провалил простой тест по лайв-кодингу (из одной задачи), который длился где-то полчаса — примерно, точно не помню. Через пару часов я взялся за эту задачу ещё раз и решил моментально.
Меня это сильно смутило. Задача-то была не такая уж сложная. Я вполне мог её решить, но не справился именно в процессе лайв-кодинга.
Этот эпизод вызвал во мне любопытство, и я начал изучать ситуацию. Оказалось, в научной литературе такой феномен широко известен. Всё дело в стрессе.
Ваш мозг в состоянии стресса
Когда вы оказываетесь в стрессовой ситуации при высоких ставках, например, на собеседовании с лайв-кодингом, то ваш мозг реагирует на неё так же, как на любую другую угрозу. Активируется амигдала, уровень кортизола подскакивает, и работа вашей префронтальной коры, отвечающей за сложные логические рассуждения и рабочую память, нарушается. Нарушение может быть лёгким, умеренным или серьёзным — это будет зависеть от ваших личных особенностей и способности выдерживать стресс.
Рабочая память выполняет важную функцию в подвижном интеллекте, способности рассуждать, решать новые задачи и мыслить абстрактно. Думаю, именно она играет решающую роль при прохождении тестов по лайв-кодингу. Когда работа префронтальной коры нарушается из-за стресса, ёмкость рабочей памяти уменьшается.
Для некоторых людей, особенно тех, кто испытывает даже лёгкую боязнь сцены, становится практически нереально мыслить в состоянии стресса ясно. Ваше внимание сужается. Вы не можете удерживать в голове несколько шагов. Вы забываете, что напечатали буквально несколько секунд назад. Такое ощущение, что ваш IQ падает до 30 пунктов. Как будто вы стали другой версией себя, намного тупее.
Подтверждающие исследования
Пока я писал эту статью, нашёл глубокое научное исследование, которое ставит в этом вопросе точку.
Эта работа называется «Does Stress Impact Technical Interview Performance?», и в её проведении участвовали исследователи из Microsoft. Специалисты, по сути, просто просили участников решить задачу по программированию в двух сеттингах:
В приватном, когда человек находится в кабинете один, и никто не смотрит.
В публичном, когда присутствует наблюдатель, и рассуждать нужно вслух.
Одна и та же задача, один и тот же тайминг, но разные уровни стресса.
В результате участники, за которыми наблюдали, справились вдвое хуже тех, которые решали задачу без сторонних глаз.
Когнитивные показатели в публичном сеттинге не только оказались ниже в среднем, но и демонстрировали намного больший разброс (высокую дисперсию). Это говорит о том, что некоторые кандидаты значительно хуже справляются в состоянии стресса, в то время как другие справляются одинаково или даже чуть лучше. Вот почему лайв-кодинг — это несправедливо.
Все эти открытия не стали для меня новостью. Но выяснилось и кое-что реально удивительное — ни одна девушка из участвовавших не прошла тест в публичном сеттинге, зато все они прошли его в закрытом. Поэтому, если ваша компания хочет «поддержать привлечение женщин в техно-среду», но при этом проводит собеседования с лайв-кодингом, поздравляю…вы используете научно подтверждённую технику отсева.
Эффективность в состоянии стресса
Мне нравится рассматривать лайв-кодинг как способ проверки эффективности в состоянии стресса.
Существуют компании, немного, для которых этот аспект реально важен. Некоторые даже упоминают это в описании вакансий. Они ищут кандидатов, которые хорошо справляются в условиях постоянного давления (держитесь подальше от таких компаний). Если рассматривать этот случай, то да, лайв-кодинг поможет отсеять непригодных.
Но в большинстве компаний смотрят на это иначе.
Чаще всего в вакансиях не указывается устойчивость к стрессу. Рекрутёры не заявляют, что работать придётся «под высоким давлением». Они не ищут людей, которые будут «хорошо справляться в условиях стресса». Им просто нужен хороший разработчик.
Разработчик, который впадает в ступор в процессе 30-минутного собеседования по LeetCode, вполне может быть тем, кто в обычном состоянии способен лихо поставлять безупречный код, писать прекрасную документацию и отлаживать сложные системы. В этом случае вы отклоняете не плохого разработчика, а человека, который плохо справляется, когда за ним кто-то смотрит.
И это не тот навык, который требуется на большинстве должностей.
Компании преподносят лайв-кодинг как проверку способности писать код. Но это заблуждение. Хуже того, это лишь усиливает боязнь сцены. Такой подход заставляет кандидатов верить, что этот тест надёжно отражает их навыки. Но для большинства это не так.
Лайв-кодинг не измеряет то, что мы хотим с его помощью измерить. Этот метод точнее отражает уровень кортизола в состоянии стресса, нежели навыки программирования.
Противодействие стрессу
Мы не можем изменить тот факт, что лайв-кодинг является распространённой практикой на собеседованиях. Но мы можем попытаться снизить вызываемый им стресс.
Лучший способ снизить острое реагирование мозга на стресс — это часто ему подвергаться. Проводите имитированные сеансы лайв-кодинга, похожие на настоящие. Для этого подойдут платформы вроде Pramp, Interviewing.io или Leet Code Mock Assessment.
Можете дополнительно установить таймер, включить запись (симулируя «наблюдателя») и рассуждать вслух. Постепенно повышайте степень давления (например, пригласите друга в качестве наблюдающего).
Я также думал поэкспериментировать с БАДами, которые должны помочь побороть стресс.
L-тирозин: в состоянии стресса истощаются катехоламины, которые могут лежать в основе упадка когнитивных способностей в подобных ситуациях. Пищевые добавки с L-тирозином должны помочь восполнить баланс этих нейротрансмиттеров в состоянии стресса.
L-теанин: аминокислота, содержащаяся в чае и отвечающая за расслабление. Было доказано, что она снижает стресс и улучшает внимание.
Сам я эти добавки ещё не применял (для собеседования), и никого к этому не призываю. Но мне кажется, что есть смысл с ними поэкспериментировать, особенно, если вы испытываете боязнь сцены. Но сначала определённо нужно протестировать их приём в тренировочном контексте. Все мы разные, и то, что работает для одного, не всегда сработает для другого.
Если вы не справляетесь с лайв-кодингом, это ещё не значит, что вы плохой разработчик. Это лишь значит, что вы человек.
Дополнение #1
Эта статья породила на HN очень бурную дискуссию со множеством прекрасных комментариев, и я решил выделить самый популярный, так как считаю, что он заслуживает отдельного внимания.
Не хочу обобщать свой случай на всех, просто расскажу личную занятную историю.
Сегодня я успешный инди-разработчик. Одной из причин, почему я пошёл в эту сферу в тяжёлые времена — для меня сработала поговорка «Чтобы добиться успеха за одну ночь, требуется пять лет» — было то, что я просто не мог никуда устроиться. Против меня работало сразу несколько аспектов: во-первых, мне уже много лет, а в индустрии царит дискриминация по возрасту; во-вторых, у меня нет степени в области компьютерных наук; и в-третьих, я склонен впадать в ступор на собеседованиях с лайв-кодингом.
Но здесь я хочу отметить, что стресс бывает разный. Взять, к примеру, пожарных. Эти ребята готовы решительно броситься в горящее здание, и этим зарабатывают на хлеб. Казалось бы, что может быть более стрессовым? Но при этом многие из них запаниковали бы от одной мысли выступить с речью в не горящем зале, полном незнакомых людей. У меня нет проблем со стрессом на работе, и за время карьеры я успешно справлялся со множеством критических случаев. Но меня воротит от ситуации, когда за мной следит незнакомый, оценивающий мои действия человек, который, подобно Дамоклову мечу, решает вопрос о моём трудоустройстве и финансовом будущем. И я так же, как автор статьи, могу после собеседования без проблем вернуться к тем же задачам и решить их. Интервьюеры, должно быть, думают, что я какой-то самозванец, который не умеет писать код, хотя вся история моей карьеры, на сегодня составляющая уже почти двадцать лет, говорит об обратном.
Многие комментаторы ссылаются на «ложные отрицательные» так, будто это какие-то случайные эпизоды, но некоторые люди, включая меня, всегда попадают в эти ложные отрицательные. Меня постоянно отсеивают на собеседованиях, где нужно озвучивать свой ход мысли. Не рождён я для сцены.
— lapcat
Дополнение #2
Вот ещё один мощный комментарий с HN, который вывел дискуссию на новый уровень.
Я работаю над документальным фильмом, посвящённым процессу собеседования в сфере разработки. Называется он Computer Silenced и является полнометражным дополнением к моему проекту Whiteboard Challenge(R). В фильме раскрывается как раз эта проблема, а конкретнее то, как она влияет на людей, у которых диагностированы скрытые расстройства, например, аутизм, СДВГ, тревожность, а также ПТСР и прочие недуги, вызываемые стрессом.
За моими плечами 25+ лет разработки, и меня тоже отсеивали на подобных собеседованиях, которые не связаны с фактической работой. И у меня также диагностированы РАС 1-й степени и СДВГ с провоцируемой стрессом дислексией.
Прошу участников дискуссии прочесть выдержку из федерального закона и подтвердить, что он в этом случае работает. С помощью фильма я пытаюсь скорректировать определение инвалидности, чтобы у всех нас были равные права.
Раздел 12112(b)(6) главы 42 Кодекса США: «запрещается использование квалификационных стандартов, экзаменов для трудоустройства или иных критериев отбора, которые исключают или склонны исключать лицо с инвалидностью либо класс лиц с инвалидностями, кроме случаев, когда установленное затрагиваемым субъектом применение данного стандарта, экзамена или иного критерия отбора доказано как относящееся к выполняемой работе и соответствующее необходимостям бизнеса».
Дополнение #3
Иронично, но «Техническое собеседование поразительно походит на социальный стресс-тест Трира, многие десятилетия используемый психологами и являющийся «золотым стандартом» исключительно как средство для уверенного вызова стресса».
Джеффри прокомментировал эту статью на LinkedIn.
Поздравляю всех, кто дочитал до конца.
Комментарии (134)
MonkAlex
21.12.2025 09:19Но выяснилось и кое-что реально удивительное — ни одна девушка из участвовавших не прошла тест в публичном сеттинге, зато все они прошли его в закрытом.
По моему опыту девушки способны проходить лайв-кодинг абсолютно так же уверенно как и все остальные люди. Насколько это исследование достоверно и качественно?
UPD: https://dl.acm.org/doi/epdf/10.1145/3368089.3409712 судя по этому документу, проверяли студентов, с не очень большой количественной выборкой.
alliumnsk
21.12.2025 09:19Забавно, что якобы существующий стресс женщин не приводит к их недопредставленности на оффлайн конференциях и к перепредставленности во всяких олимпиадах и литкодах. Впрочем, у авторов статьи все логические следствия плана просматривать и не было.
kipar
21.12.2025 09:19Т.к. кандидатов у проводящих собеседования, вероятно, хватает, то убрав лайв-кодинг им пришлось бы повысить сложность самих задач.
И на это точно также стали бы ныть (уже ноют) "в топку задачи на алгоритмы, математика программисту не нужна, все алгоритмы уже написаны".
И как же тогда им отбирать самых способных кандидатов? Вариант "по портфолио""по решению реальных задач" плох тем что вместо перспективного новичка ты наймешь кандидата с меньшим IQ но с большим опытом.
Lewigh
21.12.2025 09:19А можно поинтересоватся, какая связь между IQ, решением алгоритмических задач на собеседованиях и решением задач реальных, и как это должно выявлять сильных кандидатов?
kipar
21.12.2025 09:19лучше решает нестандартные задачи -> выше IQ -> после некоторого периода обучения будет лучше справляться с задачами реальными.
В мире где все зубрят задачи с собеседований цепочка будет скорее такая: лучше всех научился зазубрил нестандартные задачи -> выше IQ -> после некоторого периода обучения будет лучше справляться с задачами реальными.
Lewigh
21.12.2025 09:19лучше решает нестандартные задачи -> выше IQ ->
Прошу прощения, а нестандартные задачи это проходы по деревьям, задачи на бин поиск, интервалы там и прочие стандартные алгоритмические задачи, решения которых особо упорные кандидаты за полгода зубрешки забивают себе в мозжичок, не особо понимая сути решения?
Если нет, зачем вообще проводить собеседование, можно же просто отбирать призеров олимпиад и турниров, не тратя время на собесы?
kipar
21.12.2025 09:19решения которых особо упорные кандидаты за полгода зубрешки забивают себе в мозжичок, не особо понимая сути решения
Если есть два кандидата, один забил себе решения в мозжечок а другой не смог\не захотел, то при прочих равных кого вы выберете?
А если оба кандидата зазубрили - повышаем уровень задач вплоть до олимпиад. Но призеров на все фирмы не хватит да и не факт что они пойдут джейсоны перекладывать, так что стоит остановиться на уровне когда отсеиваются почти, но не все, кандидаты.
antonb73
21.12.2025 09:19https://www.youtube.com/shorts/LutbNtlds94
Выпусник ФИЗМАТ решает задачу :)
Наверняка и другие мемы есть, но этот я видел недавно.
stas_dubich
21.12.2025 09:19Посмотрите на Яндекс, на их 76 алгоритмических секций и на Алису, сразу все станет ясно)
ChizhM
21.12.2025 09:19Кстати, совсем недавно у меня случилось восстание машин.
Я ей говорю "алиса, включи аквариум" в она мне "такое устройство умного дома не найдено".
Хм...дней пять назад эта фраза включала музыку.
Ладно, попытка номер два "алиса, включи группу телевизор".
Слышу в ответ "устройство не найдено, проверьте настройки умного дома".
TimurRyabinin
21.12.2025 09:19Здравствуйте! Я из Яндекса. Заметил ваш комментарий и не смог пройти мимо. Пожалуйста, напишите нам через приложение Дом с Алисой: Настройки → Помощь → Чат с поддержкой. Коллеги обязательно во всём разберутся и помогут вам.
ChizhM
21.12.2025 09:19А сегодня новая фишка.
Говорю "включи Эдуарда сурового", а она включает рандомную музыку, то русский рок, то евроденс.
Говорю "включи гарика харламова", а она включает радиоспектакль какой-то.
michael_v89
21.12.2025 09:19Вариант "по решению реальных задач" плох тем что вместо перспективного новичка ты наймешь кандидата с меньшим IQ но с большим опытом.
Поиск перспективных кандидатов без опыта это редкий случай, он может требовать других процессов, это нужно далеко не всем. Тем не менее, live coding с простыми задачами, как ни странно, уровень IQ не показывает.
И как же тогда им отбирать самых способных кандидатов?
По решению тех задач, которые вы решаете чаще всего. У вас есть API? Просите добавить эндпойнт. Вы пишете тесты? Просите написать тест. Код даете заранее для ознакомления, задачу на собеседовании.
kipar
21.12.2025 09:19По решению тех задач, которые вы решаете чаще всего. У вас есть API? Просите добавить эндпойнт. Вы пишете тесты? Просите написать тест.
Это не дает возможность оценить потенциал. Допустим, кандидат справился. Это значит только то что на прошлой работе он делал примерно тоже самое. Дальше мы будем смотреть из справившихся на самого дешевого\молодого\небинарного\прочие критерии и упустим того кто мог бы привести нашу компанию к миллионам.
Тем не менее, live coding с простыми задачами, как ни странно, уровень IQ не показывает.
как утверждается в статье, он показывает способность справляться со стрессом. Не самый плохой навык с точки зрения компании.
michael_v89
21.12.2025 09:19вместо перспективного новичка
и упустим того кто мог бы привести нашу компанию к миллионам.Новичок без опыта, который мог бы привести компанию к миллионам, это настолько редкий случай, что массово использовать этот подход в найме нецелесообразно. Почему вдруг задачи "вернуть сумму чётных чисел" означают приведение к миллионам, тоже непонятно.
как утверждается в статье, он показывает способность справляться со стрессом.
Он показывает способность решать простые задачи, когда кто-то смотрит, в условиях ограниченного времени. Если в работе у вас таких ситуаций нет, тогда этот навык бесполезен. Он не означает, что человек будет работать так же эффективно при стрессе с другими условиями.
novoselov
21.12.2025 09:19Если у вас возникает вопрос как "отбирать самых способных кандидатов", то возможно вам не стоит проводить собесдования. Понятно что это не научиться с нуля и все равно требуется какая-то практика, но со временем становится неважно о чем спрашивать кандидата, через 15 минут уже примерно понятно подходит человек или нет. Я мог бы вместо кодинга с ним поговорить хоть о механизме эволюции животных, хоть о проектировании сферы Дайсона, просто потом будет сложнее объяснить HRу почему кандидат нам подходит.
kipar
21.12.2025 09:19Так я их собеседований и не провожу, рассуждаю с дивана. Если бы все проблемы с отбором кандидатов решались путем 15 минутного разговора, то HR как профессия бы не возникли, так что делаю вывод что эта методика не масштабируется.
GerrAlt
21.12.2025 09:19Чем Live Coding вызывает стресс? Кажется что ответственностью - он показывает можешь ты или нет, а тебе боязно что ты не можешь. Если с таким уровнем стресса кандидат не может справиться - можно ему доверить написание кода, от которого реально будет зависеть работа чего-то важного? Это же серьезная ответственность, а он теряет способность нормально функционаировать даже просто от того, что какой-то неизвестный ему собеседующий увидит что он не умеет что-то реализовывать. Кажется что при таких вводных кандидату ничего серьезного не доверишь - а это не лучшие вводные для трудоустройства.
kneaded
21.12.2025 09:19можно ему доверить написание кода, от которого реально будет зависеть работа чего-то важного?
А что, при написании кода всегда кто-то сзади стоит и наблюдает за тобой, твоим кодом и просит комментировать что делаешь, как решишь проблему? А ещё этот наблюдатель как правило типа умнее, точно знает как решить задачу (это ж именно так на собеседованиях и происходит). Разве так в обычной работе происходит что кто-то умнее вас стоит сзади наблюдает, проверяет и не подсказывает?
Вас разве не раздражает когда кто-то стоит "над душой"? Вот, а теперь представьте что на работу брали бы только тех, кого не раздражает?
Вот так и тут. Не надо подменять понятия
GerrAlt
21.12.2025 09:19Кажется это не я подменяю понятия, а вы высказываете претензии не к лайв кодингу как таковому, а к тому как именно он организован - очевидно что любое испытание можно организовать плохо, но это не значит что все испытания плохи.
Насчет обычной работы я бы заметил что в обычной работе и задачи достаются куда как более сложные, на лайв кодинг дают что-то обобщенное, шаблонное, поэтому и предполагается что такие вещи вы пишете без проблем. Если проблемы возникают, то на ум приходит мысль, что дело не в том что кто-то смотрит, а в том что со стековерфлоу копипастить не дают.
Destros
21.12.2025 09:19К слову о том, каковы методы достижения цели. Если человек выполняет работу качественно, есть ли разница к каким средствам он прибегает в процессе?
Не думаю, что рассмотрение тикетов на стаковерфлоу чем-то вредит, чтобы приводить это в пример.
Я, конечно, не разработчик, но когда мне нужно что-то написать, я часто обращаюсь к сторнним ресурсам за информацией, и пока не было замечено, чтобы это чем-то вредило.
GerrAlt
21.12.2025 09:19Вообще никаких проблем не вижу, в том чтобы искать решения проблем в том числе и на стековерфлоу. Есть только 1 важный момент - когда читаешь предлагаемый вариант решения нужно реально понимать, что тебе предлагают, насколько оно подходит именно в твоей ситуации, а не просто копипастить и пытаться запустить. И смысл всего мероприятия по оценке кандидата это попытаться понять, он сам что-то понимает, осознает что как работает и какие решения что за собой влекут, или он просто копипастит что на форме сказали и проверяет - вдруг заработает.
michael_v89
21.12.2025 09:19даже просто от того, что какой-то неизвестный ему собеседующий увидит
Не от этого. Вы это сами придумали.
Чем Live Coding вызывает стресс?
Тем, что кто-то смотрит, и времени мало, это отвлекает внимание.
можно ему доверить написание кода, от которого реально будет зависеть работа чего-то важного?
Можно. Если вы на код, от которого реально будет зависеть работа чего-то важного, выделяете полчаса, то проблемы тут не в кандидатах.
GerrAlt
21.12.2025 09:19Если вы на код, от которого реально будет зависеть работа чего-то важного, выделяете полчаса, то проблемы тут не в кандидатах.
То что на код для чего-то важного дают полчаса это вы тоже сами придумали. На LiveCoding не дают реально сложных задач, требующих большого контекста для объяснения (если дают это проблема организации LiveCoding в конкретном случае, а не этого типа проверки знаний/навыков как такового)
Тем, что кто-то смотрит, и времени мало, это отвлекает внимание.
Несомненно свое объяснение я придумал исходя из своих представлений о причинах, не настаиваю на его истинности для вас, но уточню что ваше как минимум для меня выглядит сомнительно: в момент решения задачи мне все равно, смотрят на меня или нет, лишь бы не отвлекали пока решаю (после написания решения могу и объяснить если требуется).
donRumatta
21.12.2025 09:19лишь бы не отвлекали пока решаю (после написания решения могу и объяснить если требуется)
Не пройдете)
GerrAlt
21.12.2025 09:19Если так то это, вероятно, даже хорошо: мне намного проще при поиске работы попробовать больше вариантов, и выбрать такой который действительно мне подходит, и где действительно я подожду, чем выходить снова на собеседования через пару месяцев после трудоустройства (а возможность сосредоточиться на решаемой задаче и не отвлекаться мне важна)
Gromilo
21.12.2025 09:19Дан список чисел, нужно вернуть сумму чётных из них
Конкретно эта задача - проверка механических навыков программирования. Человек вообще код писал или нет. Как долго кандидат (в своей иде) пишет public class, выбирает ли он .Where из выпадающего списка и т.п.
А вот с более сложными задачами, действительно могут быть проблемы и вариаций куча. И вообще не поймёшь, человек будет нормально работать или нет. Просто от мидла ожидаешь решения поставленных задач в разумное (принятое в этой компании для тех кто считается мидлом) время, а не способность решить "когда-нибудь".
gybson_63
21.12.2025 09:19Я бы вообще ничего не проверял кроме стиля кода кандидата. По стилю очень сразу все видно. Даже простая оценка, ставит ли он везде пробелы, где принято :)
И компании ищут не человека, а функцию. Даже если человек немного туговат, система его подтянет. И наоборот, таланту даст слегка по голове и встроит в ровную цепочку. Не будет никаких самых лучших у вас или худших. Будут как все.
Ну может кто и попадется с характером, но я бы не особо рассчитывал.
Ndochp
21.12.2025 09:19Что "все" видно по стилю и кем "принято". В каждом месте, где я работал был документ для людей "регламент разработки" - компактное описание что мы делаем не так как в стандарте или какой из двух равнозначных по стандарту путей используем здесь.
firegurafiku
21.12.2025 09:19По стилю видно, конечно, не всё, но небрежность оформления выдаёт нубов.
Вы видели когда-нибудь, что пишут студенты, не привыкшие к простому текстовому редактору (а часто ещё и к английской раскладке)? Им показываешь на лекциях нормально оформленный код, а в ответ получаешь нагромождение символов без отступов и пробелов вообще — просто не видят ценности тратить усилия на оформление.
и кем "принято"
Во многих популярных языках есть стандартный кодстайл, навскидку: Python, C#, Go, Rust.
gybson_63
21.12.2025 09:19Да. Я когда смотрю на python профессионалов, очень четко понимаю насколько я не так пишу, хотя кажется мог бы
Когда долго работаешь с кодом, твой естественный интеллект очевидно обучается тому, как этот код должен выглядеть. И в глаза бросаются уже "помарки" в виде неправильных пробелов, регистра букв, имен переменных. Ну типа когда у тебя есть переменная x и X, что постоянно встречается в блокнотах питоньих, но читать это невозможно же.firegurafiku
21.12.2025 09:19когда у тебя есть переменная x и X
В математике это нормально и идиоматично, поэтому когда адаптируют в код сложные формулы, часто так и оставляют. Проще найти ошибку глазами, когда и на бумаге, и в коде переменные называются одинаково. Проще документировать код, когда можно сослаться на статью, где всё то же самое в тех же самых обозначениях.
Ndochp
21.12.2025 09:19Так я и говорю, есть стандартный кодстайл. А все отклонения от него (нарушения, ужесточения и тп) выписываются в локальном "регламенте разработки"
gybson_63
21.12.2025 09:19Чтобы его поддерживать нужен опыт определенный. Его довольно сложно скопировать и подделать. Даже стандартный. Это как хороший почерк.
Ну и архитектура даже в малых формах хорошо видна. Мне племянник прислал код, ну там прям видно что 16 лет человеку.
Mazrigosh
21.12.2025 09:19Некоторым людям нравятся собеседования с написанием кода.
А такие есть?)
По теме - неистово плюсую. Сторонникам могу задать вопрос - а есть ли у вас пример реальной рабочей задачи, при решении которой вы писали код, а над вами коллега/начальник/ментор стоял и смотрел что вы делаете? Нет такого? Вот то-то же.
Следовательно - лайф кодинг плохо стыкуется с реальными задачами и вообще, скорее всего, придуман людьми, не являющимися профессионалами в IT.
fshp
21.12.2025 09:19Иногда практикуем парное программирование.
Но есть некоторая разница. Коллега не пытается тебя оценить, он пытается помочь.
Mazrigosh
21.12.2025 09:19Прикольно. В этом вижу смысл, но, в первую очередь, в контексте обучения и наставничества. В этом, наверно, и есть цель? Т.к. на деле - есть вопросы к тому, насколько целесообразно тратить на одну задачу ресурсы двух человек.
fshp
21.12.2025 09:19У нас пока 2 вида задач были. Первое это обучение конечно же. Второе это отсутствие экспертизы, когда никто в команде в полной мере не знает какую-то новую штуку, но работать с ней нужно. Оба случая на мой взгляд окупаются.
Есть ещё третий вариант, который пока не попробовали, но предстоит. Это проектирование публичного api для библиотеки, которую будут использовать другие команды. Тут чем больше глаз тем лучше. Хотя в общем случае это конечно не программирование, а написание RFC.
antonb73
21.12.2025 09:19Ппросто один предприниматель, у нас таких инфоцыганами называют, написал книжку и долго её рекламировал. Практика XP не прижилась, как и TDD.
Stasikslayer
21.12.2025 09:19да, такие есть, я практик а не теоретик, чем отвечать на теоретические вопросы которые в работе не нужны, я лучше код буду писать
Mazrigosh
21.12.2025 09:19Это хорошо. Чем вас как практика не устраивает, например, "задание на дом", лимитированное по времени? На предыдущую работу, когда устраивался, там такой формат и был. По-моему оптимальный - и не теория (а код), и над душой никто не стоит не смотрит.
Anton_Timofeev
21.12.2025 09:19Выше уже написали, что это проверка механических навыков. Примерно как человека, который пришёл устраиваться на кухню поваром, попросить яичницу пожарить.
IvanSTV
21.12.2025 09:19уважаемые, пожалуй, поддержу автора статьи.
Совсем недавно слил вживую совсем простенький тест - мне на живом собесе предложили выполнить работу оператора с планированием и выполнением отборов. И я понял, что навскидку уже ен помню процесс. Тыкался, будто впервые вижу.
А мне многго лет, я 24 года на складах в различных должносях. Я же видел десяток WMS, я писал тонны доработок, и ТЗшек целый чемодан, и описаний этих процессов десятки. Я админил WMS, рассчитывал специализированные функции как то оптимальные маршруты\отборы четырьмя различными инструментами, делал хренову аналитику по планированию зон склада и прочий функционал, о котором собеседующий не имел даже внятного представления. Но срубился, когда вживую попросили показать процесс на операторе. Не, с подсказками показал, рассказал, потом пришло понимание, что от меня, собственно, хотят, но вот ощущение удара мешком по голове, когда я сел под взглядом из-за плеча и понял, что ранее я всегда имел возможность предварительно час-два полазить по системе и освоиться с интерфейсом, а сейчас надо с ходу воспроизводить по огрызкам воспоминаний процесс, который когда-то крутил на тесте года три-чеьыре назад.
И вообще, показывать незавершенный или кривой код сильно посторонним для многих стресс сам по себе - буквально в пятницу - показал код нерабочего запроса разраюотчику, по совместительству архитектору, уточнить поля, и получил презрительный ответ, показавший мне мою полную никчемность. И самое интересное, что я потом разобрался, что я был прав, а он не прав, и метод, который он мне озвучил, так же не работает. как и тот, который я применял (особенность системы, как оказалось при плотном чтении документации и гуглеже форумов). Но осадочек остался, и по второму вопросу я даже звонить не стал, чтобы не ловить стресс на ровном месте. Работа не про стресс, работа - это про то, как ты работаешь и получаешь деньги. А когда на работе постоянно какая-то херня, что к обеду уже подгорает, а к 17 часам уже думаешь, а не уволиться ли, это не работа, лучше уж на складе тележку катать. Там хоть скорость движения тележки лимитированная и никто в спину не тычет.Mazrigosh
21.12.2025 09:19Понимаю. Я вот на таком проклятущем лайф-кодинге при проверке навыков по написанию sql-запросов зачем-то написал distinct в запросе с группировкой. Вообще-то sql я знаю хорошо, и для аналитики, и для разработки. Просто психологическое давление что ли так сработало, и я запамятовал, что группировка в sql вообще-то и сама по себе возвращает набор уникальных значений - следовательно distinct тут вообще нужен как в бане лыжи. И мне говорят, а зачем это вы сюда пихаете distinct? И тут до меня доходит...
Но, как говорится, уже поздно, косяк зафиксирован, выводы сделаны) То что они не соответствуют действительности - всем накласть.
Sabiko
21.12.2025 09:19Тоже с sql недавно такое было. Вообще не ожидала задачи написать sql запрос и давно очень их не писала. Но в целом они у меня никогда сложностей не вызывали на работе - писала сложные, оптимизировала по плану и по дебаг логам бд. А тут простенький совсем, из разряда первых занятий по бд в универе - и всё, ступор мозговины. Даже не хочу вспоминать, что там конкретно было (да это и не важно, в нём не было никакой хитрости), я потом неделю чуть ли не по ночам с криком просыпалась.
При этом за пару месяцев до этого сходила на лайвкодинг в яндекс, и, не смотря на всю их дурную славу, осталась с очень хорошим впечатлением - интервьюер очень много сил положил на то, чтобы остановить мою разогнавшуюся паничку и перейти к конструктиву. Ощущение, что они там в курсе этой проблемы и серьёзно к ней подходят.
Не смотря на свою личную проблему, думаю что лайвкодинг в некотором виде вещь необходимая, но тут хитрость в том, что в зависимости от того, как он настроен, им можно проверять очень разные вещи. И есть вопрос, всегда ли интервьюер хорошо осознаёт, что именно он проверяет.
Stasikslayer
21.12.2025 09:19а что лучше? теоритические вопросы которые в работе не нужны? или какойнить говнокод с вопросом "че выведется?"
vmx
21.12.2025 09:19«Дан список чисел, нужно вернуть сумму чётных из них». И такая задача не предполагается как сложная или заумная
В смысле? Я бы наоборот считал что задача с подвохом.
Как именно этот список дан?
Если в текстовом виде, нужно ли проверять числа при парсинге?
Что это за числа, в каком они лежат диапазоне?
Сколько этих чисел может быть в списке, нужно ли готовиться к тому что машинные 64-битные переполнятся?
Нужно ли быстро считать эту сумму, может быть собеседующие - аутисты и хотят посмотреть как вы наваливаете SIMD-интринсиков вживую.
В общем, из такой "несложной" задачи можно сделать целый цикл статей на хабре, если захотеть.
Anton_Timofeev
21.12.2025 09:19Обычно предполагается, что кандидат будет уточняющие вопросы задавать, и сначала наскоро напишет "что-то работающее", а уже потом, если понадобится, можно и улучшать.
tduser
21.12.2025 09:19Насчёт биодобавок. Экспериментировал, успехи есть. Эффект давно известен, просто если кто не знал, напишу здесь :) Если вас одолевает стресс, или плохое настроение (это тоже снижает когнитивные функции), вернуть свои суперспособности и даже их временно усилить можно с помощью следующих веществ: половинка плитки шоколада, чашки зернового кофе, какао, зелёный чай, пуэр, адаптогены - такие как лимонник, элеутерококк, женьшень. Список не полный. Желательно заранее это попробовать на себе и выбрать то, что для вас подходит лучше всего. Только меру соблюдайте )
Насчёт приведенных в статье L-добавок, я бы не стал. Синтезированным аминокислотам не доверяю, лучше натуральные, в составе натуральных продуктов, таких как грецкие орехи например.
alliumnsk
21.12.2025 09:19А у других людей жуткий стресс вызывают резюме и слова "джуниор", "сениор", "аджайл". Их права тоже надо защищать, чем они хуже?
anaxita
21.12.2025 09:19Через пару часов я взялся за эту задачу ещё раз и решил моментально.
Интересно, эти пару часов+ время проведеное на собеседовании как то помогли в таком быстром решение задачи?
demoniqus
21.12.2025 09:19Считаю лайв кодинг полной ерундой. Когда тебя на собеседовании заваливают умными словечками о всяких библиотеках, плагинам и прочей ерунде "специалисты", которые, как потом выясняется, забывают завернуть сложную логику в банальный try catch, что в итоге выливается в нарушение целостности данных, о чем дальше с ними говорить? Помню, когда проходил собеседования, часто был вопрос про работу с большим данными, мол, что будете делать, если запрос тормозит... До чего ж тупой вопрос. Сниму трусы и буду бегать, ибо тут можно целый талмуд написать, что делать. Никакой конкретики в вопросе нет, а ты угадай, чего от тебя хотят, как в той сказке "Пойди туда не знаю куда, принеси то не знаю что". Опять же по опыту, были в проекте древовидные данные и пересчет их выполнялся медленно. Но зато, как сейчас модно, готовым сторонним решением. Я выкинул это решение, написал свою функцию. Скорость выросла на два с лишним порядка. Дело не в запросе было вовсе. Есть ещё один пример - всеми любимые Entity Framework различного толка. Только пользоваться ими правильно "специалисты" не умеют сами, лепят куда надо и не надо, не думая, сколько и где они заплатят за это решение. Переписав логику на чистый read-only в методах вывода данных пользователю, я получил 3-4 кратное ускорение. Всех этих специалистов и экзаменаторов самих надо проверять... И что толку с их знаний языков и фреймворков, если они простую бизнес-логику не могут адекватно написать?
PerroSalchicha
21.12.2025 09:19Лично я к лайв-кодингу отношусь равнодушно. С одной стороны - да, стресс. С другой стороны, ну хотят в какой-то конторе отфильтровать стрессующих людей, ну и, собственно, что такого? Это их желание, это их контора, это их право. Если вы стрессующий, вы не попадёте на работу в контору, где вам будет неудобно, а они не получат сотрудника, который у них бы не сработался. Все счастливы в итоге.
Andyrey01
21.12.2025 09:19Автор абсолютно прав. Есть много людей, устойчивых к стрессу, но я к таким не отношусь. Простую задачку на сумму четных из списка (в начале статьи автор привел пример), которую решаю мгновенно у себя дома, точно завалил бы на публике. Наверное, есть специализации, где действительно требуется мгновенность мышления и устойчивость к стрессу, но это далеко не для всех.
WieRuindl
21.12.2025 09:19Лайф кодинг тоже бывает разный. Две истории буквально из моего опыта:
1) я проводил собес. Кандидат - вроде как сеньор, если верить резюме. Задача - лайф кодинг, только наоборот - это я шарю экран и пишу код, а ему надо только указывать, что писать. Типа я джун, который все умеет, но нифига не понимает, и у нас что-то типа парного программирования. Надо было написать класс типа MathUtils, в котором один метод, который принимает 2 int-а и возвращает сумму, и юнит-тест для этого метода. Сколько должна занимать такая задача? Минут 5? 10, если с перерывами на перекур? В общем, спустя 20 минут мы даже не добрались до юнит-теста. Отказал я этому парню
2) собеседование проходил уже я в Ebay. Какой-то индус по ту сторону экрана попросил меня написать rest-ендпойнт с jwt авторизацией, и все это в каком-то онлайн блокноте. Вот тогда я офигел, конечно. Задача абсолютно решаемая, но не без гугла и не в блокноте. Я просто отказался ее решать, меня, очевидно, не взяли, но я не то чтобы расстроен, ну их нафиг
А в общем, к чему я. Как по мне, лайф-кодинг - это как раз самая весёлая часть интервью, и мне жаль, что ее так редко устраивают. Ну опостылело по сто раз отвечать теоретические вопросы, это скучно, неинтересно и в целом нафиг не надо, спросите вон гугл или чатжпт, чем одна коллекция от другой отличается под капотом
Лайф-кодинг как раз позволяет посмотреть как человек думает. Как принимает решения, чем обосновывает и т.д. Как пишет код, в конце концов. А что ценного в том, что кто-то зазубрил кучу теории?
Yago
21.12.2025 09:19Так в статье как раз описывается, что лайф-кодинг не позволяет это посмотреть. Он лишь погружает человека в стрессовую атмосферу, и его мышление становится иным. Это может отражаться как на ходе мыслей, так и на написании кода (например, экономлю время под давлением - не называю переменные в полный рост или забиваю на форматирование).
И любую теорию можно проверить практикой. Достаточно поставить вопрос немного иначе. Не "для чего нужны интерфейсы?", а "в каких случаях использовали интерфейсы?". Не "скажите новые особенности языка в 15ой версии", а "что нового использовали из последней версии языка" и т.д.
WieRuindl
21.12.2025 09:19Ну, в статье высказывается одно мнение, я высказываю другое. Если для человека комментирование своего мыслительного процесса - это настолько стресс, что он становится не в состоянии решить простейшую задачу, то я такого человека не возьму
Опять же, мы говорим о простых задачах. FizzBuzz какой-нибудь, например. Человек же не забывает, как еду в рот класть и как челюстями двигать, когда он на совместный обед с коллегами идёт, верно? Ну вот ровно так же я ожидаю, что тривиальные вещи не должны вызывать у человека панику и ступор. Я понимаю, что мы тут все программисты, а значит интроверты и социофобы, и все такое, но идея, что человек может быть на самом деле богом программирования, но только когда на него никто не смотрит, а иначе он превращается в тыкву - она... Ну, фигня какая-то
"В каких случаях использовали интерфейсы" - в тех, где нужно было. "Что нового использовали в новой версии языка?" - я понятия не имею, что новая версия вообще появилась, я пишу на той, которая в компании, и задачи решаю на ней. Ну и каков КПД этих вопросов?
Yago
21.12.2025 09:19С такими ответами КПД таков, что вы не пройдете интервью, потому что:
1) Не заинтересованы в развитии языка, и не следите за инструментом, который вас кормит.
2) Не заинтересованы в интервью (такой ответ про интерфейсы грубоват, и если его не расширить доп. информацией, будет восприниматься как огромный минус, но если мне так отвечают, я задаю наводящие вопросы из разряда "А где нужно было?")
В реальной ситуации люди отвечают иначе. В 95% случаев интервью люди заинтересованы в вакансии, и стараются ответить то, что знают или не знают по теме. В остальных случаях бывает, что у человека день не задался или он все-таки очень токсичный, но интервью в таком случае быстро сворачивается.
WieRuindl
21.12.2025 09:19Интервью - это обоюдный процесс. Если меня на собеседовании будут спрашивать про версии языка, я для себя как минимум сделаю вывод, что со мной общается не технический специалист, а условная некомпетентная hr с набором вопросов и "правильных" ответов, которые требуется угадать. В стиле "кем вы видите себя через 5 лет?". Ну либо собеседующий откровенно сам не уважает моё время. Я разработчик, который разбирается в своём инструменте и умеет на нем работу работать, а не блогер, который за новыми технологиями следит
Разных технологий и версий одной и той же технологии в современном мире гораздо больше, чем в принципе возможно удержать в голове, и спрашивать, что там нового где-то появилось - ну, бред же. Будет надо - почитаю, разберусь, изучу. Просто же так не досуге читать, что там нового в React завезли или какие новые фичи в очередной версии Java появились я не буду - у меня так-то жизнь помимо работы есть
Если компании нужен блогер - то пусть ищут блогера
Yago
21.12.2025 09:19Да почему же "правильных ответов"? Это просто пример практических вопросов, являющийся альтернативой лайф-кодингу. Кандидат может иметь свое мнение насчет этих нововведений языка и оно может противоречить мнению интервьюера. Другое дело, что он знает про эти тонкости и сферу их применения на практике.
Имхо, профи следит за развитием инструментов, которые использует при разработке. Если этого не происходит, обычно его опыт считается устаревшим, и компании потребуется n-ое количество времени на дообучение, что не всегда целесообразно. Я встречал зубров, которые писали на версии языка десятилетней давности, и их переобучение занимало от полугода, чтобы они вошли в темп современное разработки на уровне middle хотя бы. А некоторые и вовсе не проходили переобучение, и компания несла только убытки.
Для меня подтягивание знаний по ключевому стеку - необходимый обряд перед прохождением интервью. И вы удивитесь, но так делают примерно 50% разработчиков судя по моей личной статистике.
WieRuindl
21.12.2025 09:19Это набор ничего не значащих вопросов, ответы на которые прекрасно даёт chatgpt. Для чего в этом процессе нужен собеседуемый? Чтобы косплеить прокси? У интервьюера vpn не работает и он сам в ai не может вопрос написать?
Имхо, если в компании есть принятый стек технологий, то знать и уметь работать надо именно с этим стеком, и совершенно нет никакой разницы, что там ещё нового в мире придумали. И проверять надо не теоретическое знание каких-то технологий и версий, а в целом умение человека думать, анализировать и т.д. (что - сюрприз - гораздо лучше видно на решении задач, а не на отвечании на вопросы). Я вот встречал людей, которые вызубрили какие-то определенные технологии или фреймворки, но ни шага за их пределами не умеют. Условно, метод findById в spring data они умеют писать, а отбери у них spring, и простое "select * from ... where id=..." они не в состоянии. И толку мне от такого разработчика, пусть даже он офигенно шарит в самых новых версиях spring data?
А для меня необходимый обряд - это просто пройти пару собесов для разминки, и в целом уметь отвечать на фундаментальные вопросы, и по моему личному опыту мои знакомые делают именно так. Ну так и чей личный опыт более опытный?
Yago
21.12.2025 09:19Рынок диктует условия. И на рынке предложений по современному стеку и подходам больше. Ограничиваясь текущим стеком рано или поздно вы отстанете от рынка и ваш опыт перестанет быть релевантным.
Судя по тому же gemini в подсказках гугла на распространенные вопросы, нейросети еще плохо показывают примеры реального опыта. Потому я и говорю про смену ракурса вопросов с "расскажи мне вызубренную теорию" до "покажи, как в своем опыте использовался тот или иной подход, и какие подходы можно было использовать в альтернативе". Отличить джуна-вкатуна с зубрежкой и человека с богатым опытом в данном случае не предоставляется сложным. И по ответам видно в том числе и то, как человек анализирует свой опыт, рефлексирует над ним и предлагает более корректные альтернативы.
У нас кардинально отличаются точки зрения на собеседования. Предлагаю завершить этот баттл :)
gybson_63
21.12.2025 09:19Ну не пройдет и ладно. Вот тот человек, с другой стороны стола, сколько нанял крутых программистов и как это докажет? Глаза закатывать и щеки дуть это не профессия.
Ndochp
21.12.2025 09:19Стресс не только и не столько в комментировании. В реальной работе я напишу фигню, или полную или плейсхолдер просто. Потом сотру, потом перепишу и выдам результат может сразу хороший, а может через пяток падений юнит теста.
А в лайф кодинге у тебя нет черновика - все что ты пишешь сразу попадает на контроль. Значит нельзя ошибиться ни в одном слове, все то, что я обычно проделываю за несколько версий на экране надо сделать в уме и напечатать уже правильное решение.WieRuindl
21.12.2025 09:19Да нет. Пиши так и столько, как и сколько хочется. Я в такой задаче не строгая учительница, которая линейкой по пальцам бьёт за ошибки, я лишь наблюдаю за мыслительным процессом, и если он состоит в итеративном приближении к ответу, то и ладно, мне норм. Процесс завершится либо когда будет заявлено, что готово, либо когда кандидат сдастся, ну либо могу прервать досрочно, если время будет кончаться
Если какие-то другие интервьюеры косплеят училок, то, ну, пусть идут в баню
FlyingDutchman2
21.12.2025 09:19Как по мне, лайф-кодинг - это как раз самая весёлая часть интервью, и мне жаль, что ее так редко устраивают.
То есть вы обрадовались, что вас не взяли в EBay?
WieRuindl
21.12.2025 09:19Я на тот собес в принципе пошёл лишь для "разминки". Нет, может, конечно, мне бы выкатили оффер на 100500 денег в секунду, и тогда бы я, разумеется, согласился, но вообще работать там я не то чтобы хочу
Yago
21.12.2025 09:19Еще добавлю к минусам лайвкодига следующее:
1) Незнакомые инструменты
Чаще всего разработчик под себя настраивает среду разработки, устанавливает плагины и так далее. То, что предлагают для лайвкодинга компании - либо собственные поделки, либо какие-то решения из разряда "вот вам ссылка на онлайн-блокнот". И то и другое не удобно и может быть новым для кандидата, и накладывать доп. уровень стресса.
2) Нерелевантность задач
Задачи для лайвкодинга вообще стали оторваны от реального мира. Там все больше и больше низкоуровневых материй, которыми программисты оперируют в ничтожном проценте своего рабочего времени. Чаще всего задачи более высокоуровневые, и это низкоуровневое месиво будет просто убыточно для компании, если в разработке сделать упор именно на него.
3) Накопленный негативный опыт
Чем чаще был на лайвкодинге, тем больше за плечами вспоминались прошлые случаи, которые только тратили мои нервы и время. Я начинал с лайвкодинга на листочках ручкой когда только в it пошел, и попадались индивиды, которые говорили "код не сработает, вы точку с запятой пропустили". Я еще тогда был в недоумении: ручку использую только для схематики или когда подписать надо что-нибудь, а для кода у меня удобная клавиатура. Зачем вам это надо? Так или иначе, при упоминании лайвкодинга у меня начинаются вьетнамские флешбеки с теми курьезными случаями, когда лайвкодинг не удался. К слову, не удался он в процентах 80 случаев из-за "боязни сцены", которую описал автор статьи.
Потому всегда выпытываю компанию, что у нее скрывается под "техническим интервью" (прошу указать этапы собеседования и форматы этих этапов, и только потом решаю, подходит оно мне или нет). Сэкономило много нервов, но, возможно, были какие-то упущенные вкусные предложения. Все равно не жалею.
Gromilo
21.12.2025 09:19Лайф-кодинг на бэкендера: реализовать ендпоинт в любом удобном ему инструменте. Код не должен компилироваться, но ожидается объяснение основных шагов, описание DTO, метода контроллера и реализация запроса к бд уровня: вернуть количество строк в таком-то статусе с группировкой по типу (linq или sql на выбор). Гуглить, использовать ИИ можно.
Кажется 1 и второй 2 пункт закрыт.
Просто я не знаю как понять, что может кандидат, если не посмотреть на его код и на то, какие вопросы он задаёт.
Я может есть какие-нибудь методы снизить стресс?
Yago
21.12.2025 09:19А вы уверены, что это задачка для лайв-кодинга? Похоже на тестовое больше.
Для эндпоинта нужно:
1) Выбрать фреймворк, запустить на нем скелетон-приложение или найти готовый проект
2) Написать миграции, описать модели данных
3) Понять, какую вы ожидаете архитектуру. Простую или слоистую. Раз уж про DTO заговорили. Если делим на слои - еще продумать вложенность и абстракции участвующие в эндпоинте, их описать
4) Заморочиться с окружением, т.к. может быть необходимость проверки кода для понимания, где в нем допущен баг или неточность
Наверное, это займет более получаса времени.
Тут я бы смотрел в сторону тестовового задания в виде готового приложения с написанными тестами под его функционал и желаемую архитектуру, с дальнейшим обсуждением результатов после вашего ревью кода.
Но все же придерживаюсь мнения, что по разговору "по душам" с разработчиком можно понять многое и без кода, который он пишет. Просто составить блоки теоретических и практических вопросов по темам, касающихся разработки (язык, паттерны, бд, тулзы, расследование инцидентов), и понять, насколько вы подходите друг другу по его ответам. Сам действую именно таким методом.
WieRuindl
21.12.2025 09:19Это отличная задача для лайф кодинга. У меня, кстати, была именно такая на последнем собесе, я с огромным удовольствием с ней поигрался на интервью
1) подготовить пустой проект с нужными зависимостями - это в худшем случае вопрос примерно 5 минут. К тому же его можно подготовить перед самим собесом
2) для такой задачи не нужны никакие миграции, нужен функционал, который можно дернуть условным Postman и посмотреть на ответ
3) навскидку нужны примерно 5 классов: контроллер, сервис, репозиторий, класс-dto и класс-entity (если мы в мире java). Этого уже достаточно, чтобы понять, понимает ли человек, что он делает, и как планировать архитектуру. Если очень хочется выпендпиться, то можно добавить mapstruct маппер, но это уже прямо роскошный максимум
4) да пофиг, если даже проект не запустится. Опять же, по одному только процессу создания и обсуждения всего вышеперечисленного уже понятно, что человек знает и умеет
Где-то примерно полчаса, наверное, такое и займёт. Отличная задача, в общем
Gromilo
21.12.2025 09:19В .net мире новый asp.net проект есть в любой студии. Даже ef можно не ставить, если надо, говоришь, что тебя есть IQueryable<MyEntity> и вперёд.
Миграции писать не надо, модель данных - 1 класс и 2 енама.
Ожидаю любую архитектуру, можно даже в контроллере написать код, если кандидат обоснует, почему такой выбор.
Код можно не запускать. Во многих местах достаточно что-то типа: использую код фёрст подход, миграции сделает ef, эту модель проще всего замапить через автомаппер, здесь воткну медиатР, потому что...
Проверяется видел ли кандидаты бэкенды в глаза за свой пятилетний опыт, например.
Заметил, что от уровня кандидата меняются вопросы (задавать можно и нужно). Джуны тяготеют к "правильности кода", люди поопытнее выясняют требования и сообщают о допущения которые они делают. Тут инфы как-будто даже больше чем от интервью.
С тестовыми есть проблемка: иногда оно написано не кандидатом, он может хорошо рассказать где и что, но не может воспроизвести (было 1 раз).
С разговором по душам та же проблема: поговорили, вроде всё хорошо, а потом IDE как-будто в первый раз видит. Ну типа, public class по букве пишет, вспоминает название Linq-методов (из тройки Select, Where, GroupBy).
В идеале поработать с человеком недельку, но где такие ресурсы взять?
alldark
21.12.2025 09:19Где-то раз в неделю занимаюсь лайвкодингом, и заметил, что превращаю его в метод утёнка с живым собеседником. Кажется что аморально, но стресса не испытываю.
teiuaz
21.12.2025 09:19Вообще не понимаю как без лайв кодинга можно делать адекватные выводы о разработчике. Это же основной навык, за который вы берете на работу. В процессе можно разобраться, как человек мыслит, как человек схватывает информацию, как с человеком обсуждать технические детали наживую.
От стресса человек может забыть что-то, но база мышления остаётся, тем более я разрешаю гуглить, и даже иногда прошу, чтобы посмотреть как человек это делает.
gybson_63
21.12.2025 09:19Основной навык это разобраться в вашем коде, чтобы грамотно его модифицировать. Если вы по тысячному разу пишите сортировки, то может и не надо вам новых сотрудников, а просто поискать библиотеки какие-то, изучить их.
Konvergent
21.12.2025 09:19Просто на втором этапе у автора закончился кошелёк Миллера) В целом, я тоже против таких отборов. Сейчас можно нанять человека на 2 недели присмотреться к его способам и способностям решать реальные задачи и организовывать процессы.
vov-crao
21.12.2025 09:19Все Live Coding я завалил. Потому-что для меня это оказалось идеальным способом ввести в стресс и посмотреть, как я буду выкручиваться под прицелом снайпера и с взведенной гранатой на столе. Именно так.
Последний собес я прошел 2 этапа с топ-5 результатом, час поболтали об опыте и следом лайф кодинг простой задачи завалил. Сам понимал, что задача простая, но не мог схватить, почему буксую. У меня крутой problem solving. Меня зовут, когда за день-два решить не могут проблему, я ее за час два решаю. В тишине. В оптимальных для решения условиях. Без пригляда как за школяром. Эффективность - 100.1% ))
И в Авралах себя уверенно чувствую, потому что знаю, что и как применять и где искать. Но это результат работы в комфортных условиях. И только в них. И на созвонах не решаю, потому что там обычно зашкаливает паника и бесполезно что либо делать.
То как обычно проводится этот лайф кодинг - это ограничение по комфорту и создание стресса. Это получается обычная практика в компании, типа корпоративного кода?
Чтоб понять, что чувствует в стрессе собеседник, вот пример с аналогией:
- Пришел директор, сказал, что упала у него мелкая прога, включил секундомер и дал 10 минут. Или починишь под его приглядом или уволен. И заявление на стол положил.
И не важно, что в комфортных условиях, даже в сильном стрессе эффективность зашкаливает, сейчас же это не так. Значит и всегда так. - Такая логика рассуждений и действий.
rombell
21.12.2025 09:19Анекдот из недавнего прошлого:
Опубликовали вакансию, получили тысячу откликов. Сидит молодая эйчарка с заплаканными глазами в ступоре, смотрит на огромную стопку. К ней подходит начальница - в чём дело? Та отвечает: "Да столько отзывов, я не успеваю обработать!". Начальница хмыкает, берёт попловину стопки и сразу в мусорку: "Во-первых, неудачники нам не нужны".
Так вот лайв-кодинг - с одной стороны, способ отсчечь тех, кто решает задачи с помощью друга или, нынче, ИИ. С другой - способ отсечь неудачников, просочившихся достаточно далеко. Увы, на рынке работодателя работники всегда страдают.
fshp
Потом у неустойчивого к стрессу разработчика падает прод, а он вместо мобилизации всех своих сил перестает выходить на связь.
Понятно, что разработчик не должен работать постоянно в стрессе. Но дерьмо случается, к нему нужно быть готовым.
antonb73
Хороший пример рассуждений "мускулинных интеллектуалов" - тяп, ляп, а если чё, то напрягём бисепс и решим. Почему бы таким не занятся физкультурой, спортом, где именно такие качества требуются, хотя постойте, спортсмены тренируются, у них режим...
Пропаганду такой культуры "побед за счёт концентрации воли" я наблюдаю в массовой культуре, особенно в голивудских блокбастерах, где м@дак и лентяй по жизни в критический момент, под величавые звуки труб, напрягает всю волю и побеждает - звучит торжественная музыка, все празднуют победу героя.
Выводы неутешительные - люди не склонные к критическому мышлению применяют предлагаемые им паттерны поведения, без какой-либо оценки насколько они хороши в данной ситуации.
GerrAlt
Мускулинных или нет, но со стороны кажется что любой бизнес скорее выберет не слишком сильно ошибающегося "мускулинного интелектуала", который будет разгребать проблемы (которые будем честны, в любом сколько-нибудь сложном проекте после внедрения будут), чем нежного гения, который идеально все реализует, но при возникновении проблем (возможно даже и не по его вине) впадает в прострацию.
dibu28
Почему не выбрать лучшее из обоих миров и нанять двух?
fshp
А лучше трёх да на одну зарплату.
Gromilo
А как так получилось, что мускулинный - звучит как что-то плохое, а мужественный как что-то хорошее?
Stasikslayer
ты думаешь у таких людей есть положительный термин "мужественный"?
stas_dubich
Прод падает обычно из-за авральной выкатки фич, когда прибегают блаженные менеджеры с криками «СРОЧНО ВЧЕРА ПОЗАВЧЕРА». В итоге начинается цепная реакция, где на тушение пожаров и бесконечные хотфиксы уходит как минимум х2 времени по сравнению с нормальным циклом «подумать — сделать — проверить».
И в этот момент разработчик перестает выходить на связь не потому, что он «нежный» или сломался под давлением. Он уходит в игнор, потому что у него заканчивается моральный ресурс участвовать в этом балагане. Трудно найти в себе мотивацию на «трудовой подвиг», когда ты три дня твердил: «Нельзя катить, оно сырое, мы ляжем», — а тебя заставили нажать кнопку деплоя ради красивого отчета. Требовать от человека с энтузиазмом чинить то, что он умолял не ломать — это уже особая форма управленческого садизма.
Так что, когда разраб «пропадает», это не баг, а предохранитель психики. Если ваши бизнес-процессы держатся исключительно на надежде, что Вася в 3 ночи совершит чудо и своими нервами залатает дыры, которые пробили сами же менеджеры, — у меня для вас плохие новости. Авралы одних — это всегда лишь следствие некомпетентности других, и рано или поздно «спасатели» либо заканчиваются, либо увольняются.
Tzimie
Не всегда. Иногда просто shit happens. Упал сервер, выросла нагрузка x3 перед новым годом. А зумер отключил телефон и в домике)
stas_dubich
Не ну нагрузка х3 да, это аргумент, стресс тесты же наверно запрещено делать, чтоб понимать какой есть запас прочности у системы, за это сразу увольняют одним днем ?
Tzimie
Да, в мире розовых пони все системы масштабируемые и заранее везде подложена соломка, потому что в мире розовых пони у девелоперов и админов бесконечное количество ресурсов
fshp
А потом инженер фесйбука во время сбоя не может открыть дверь в ЦОД. А CF роняет пол интернета. Дважды.
markmariner
Умножить ресурсы на 3 обычно проще, чем написать в три раза более эффективную программу.
Тем более, если было так, что сервера и так работают на 60 процентах от нагрузки чего-нибудь, но это повод уже сейчас увеличивать ресурсы.
А если там проблема в том, что просто программа вылетела, так у админа должна быть инструкция по повторному запуску.
В общем, сломанный прод -- проблема внедрения, а не разработки, особенно в нерабочие часы.
michael_v89
Если вам нужно дежурство перед новым годом в нерабочее время, договаривайтесь с разработчиками заранее за дополнительную плату.
leiz
Выросла нагрузка x3 перед новым годом это реально shit happens. Никогда такого не было и вот опять - никто не был готов в мире без розовых пони в умных очках. Выделять людские ресурсы заранее это невообразимо и требует бесконечное количество умственных затрат.
Gromilo
Сам придумал про менеджеров, сам опроверг :)
Иногда покупают 10 одинаковых сетевых железяк, заливают туда одинаковые конфиги, а потом разрабы пол ночи переписываются к сетевиками, потому что каждый считает, что у него проблемы быть не может. А оказывается, что аппаратный сбой.
Иногда soap запрос не ходит, потому что версия ядра линукс на стейже и проде отличается в номере пачта. А когда его обновляют, падает другой сервис :D
Иногда разраб сносит продовую бд, потому что подключался к ней 3 месяца назад, когда сервис даже близко не было готов и забыл убрать коннект из секретов.
Всякое дерьмо случается. Хорошо, если это большой проект и есть поддержка, но иногда и она не вывозит.
Мимобэкендер, который хорошо спит ночами.
bkar
Вспомним, откуда понятие аврал пошло. Парусное судно. Налетает шквал, или пираты, или само судно налетает на риф. АВРАЛ !!
Мне жаль вас расстраивать, но есть виды деятельности, где аврал это то, вокруг чего всё и крутится, ради чего людей и держат. Ради чего и платят "не по рынку". И никакой компетентностью этого не перешибить. От людей зависит, будет чаще, реже, глубже или большее. Но так, чтобы навсегда исключить - нет.
antonb73
Это описание очень очень похоже на описание пограничного или нарциссического расстройства личности, где внутренние страдания человека становятся центром восприятия реальности. Он не просто испытывает боль - он бессознательно втягивает в неё других, требуя соучастия, чтобы подтвердить собственные эмоции и не чувствовать себя одиноким в боли. Такое поведение часто не злонамеренность, а попытка обрести контроль над хаосом внутри себя.
JustMoose
И даже в трудовом договоре будет написано, что "данный сотрудник нужен на случай аврала"?
JBFW
Может и не написано, но именно в таком режиме я когда-то и работал.
В нормальное время не делая примерно ничего. В ненормальное - присылание бизнес-такси прямо на дачу, "потому что надо ехать чинить - кто-то всё поломал".
В этом есть свои плюсы, "почувствуй себя Бэтменом"...
sulqadari
Мне жаль вас расстраивать, но есть отрасли, где за учинение аврала можно не хило так получить по трусам.
А то, что описали вы - обыкновенная точка кипения, где люди просто одноразовый ресурс.
PerroSalchicha
Прод падает обычно по любой из стапицот причин, и авральная выкатка фич тут одна из самых заурядных. Никогда и нигде не бывает непробиваемого тестового покрытия. Даже если по метрикам у вас там 100% покрытия, это всего лишь означает, что у вас тесты затыкают все дырки, но никак не означает, что они покрывают все кейсы. Никогда и нигде не бывает идеального стресс-тестирования, потому что единственный достоверный стресс-тест, это выросшая рабочая нагрузка. Никогда и нигде не бывает так, чтобы техзадание всегда было верно сформулировано, и учитывало все возможные кейсы на продакшене, и так далее.
markmariner
Да, именно так!
Поэтому эти проблемы решаются очень просто, но по-другому.
Если после выката что-то сломалось, нужно всегда иметь возможность быстро откатить.
Чтобы хватило ресурсов, нужно знать где их быстро купить в 5-кратном размере на короткий срок.
То есть, это административные проблемы, которые решаются не программированием и правильной постановкой задач.
vmarunin
Бывают авралы внешние.
28 ноября 2025 года было окончательно принято решение о повышении НДС в РФ. С 1 января 2026 (33 дня до дедлайна)
Я нашёл письмо минфина, которое разъясняет как выбивать чеки и ещё кое-какие детали от 15 декабря 2025 (16 дней до дедлайна)
Представляете сколько всего надо поменять во всех банках, финансовых и торговых организациях? Аврал? Аврал!
И никто в этих самых организациях не хотел менять НДС.
И да, если не починить, то можно нарваться на очень большие неприятности, когда будет не только штрафы, но и банкротство или сроки.
Бывают случаи, когда надо катить сырое. И нужны люди которые умеют катить сырое и жить потом с ним.
kalombo
Еще можно брать в разрабочтики только людей с медицинским образованием. Вдруг дерьмо случится и на работе кому-то станет плохо, тогда он сможет диагностировать и оказать необходимую помощь.
Если серьезно, то проблема таких суждений, что у вас нет осознанного подхода. Вы взяли алгоритм, а потом придумали объяснение себе, почему он хороший. Должно быть ровно наоборот. У вас же получается вы режете 25% хороших кандидатов, которые пишут хороший код и готовы закрывать задачи, но не могут оперативно поднять прод в критической ситуации? Ну ок, пусть пишут код, а для поднятия прода назначьте специально заточенных людей. Но это я вообще в допущения пошел, хотя на самом деле следствие "не решил литкод - не будет брать трубку, когда упадет прод" - это максимальное натягивание совы на глобус, которое вы сами для себя придумали, чтобы оправдать литкод.
fshp
Прямо как в анекдоте про спички.
Что говориться в статье? Что решение задач показывает не возможность решать задачи, а возможность действовать в стрессовой ситуации. Важно же не то решил ли кандидат задачу, а сам процесс.
kalombo
В статье лишь приведено мнение автора, такого же обычного человека как и я. И вот я говорю - не показывает. И кто прав? Пока у вас не будет какой-то доказательный базы - это просто гипотеза, пусть она вам и очень нравится.
fshp
Если прав ТС, то оставляем лайвкодинг как минимальный тест на стрессоустойчивость.
Если правы вы, то оставляем лайвкодинг как минимальный тест на программирование.
funca
Нужно учитывать, что складываются не только достоинства, но и недостатки. Причём, недостатки в итоге перекрывают весь профит (ложка детям в бочке меда). Поэтому лайвкодинг плох одновременно и как тест на программирование из-за стресса, и как тест на стресс - из-за лишней зауми.
anshdo
В той же статье написано, что человек сильно по разному реагирует на разные стрессовые ситуации. Перечитайте пример про пожарного. Так вот, упавший прод для разработчика, это как пожар для пожарного — стресс, да, но знакомый и привычный. А вот когда кто-то во время работы над душой стоит, это для многих совсем не привычная ситуация.
adrozhzhov
У вас нет планов отката при выкатке фич, не DR планов и вы не проводите регулярные учения по переключению-поднятию систем, чтобы убедиться что планы DR актуальны, а разработчики не будут придумывать как поднять эту систему с сотней неявных зависимостей?
И вообще без прохождения систем проверки качества, на падении систем которых можно получить опыт оперативного поднятия системы, который может пригодиться для работы на проде, выкатку производите?
если этого всего нет, то кажется что не совсем понятно что
fshp
Простите, что перехожу на личности. Из вашего профиля могу предположить, что вы работаете или работали в билайне. Если у вас все это есть, то откуда возникают новости подобные этой?
https://habr.com/ru/news/886000/
adrozhzhov
(Впервые увидев новость, невозможно про все везде знать, есть специализация и звать тушить пожар будут ответственных за эту зону людей из DR-планов) если в новости сказано про DDoS то соответственно действовали по плану локализации DDoS. Знали кого надо вызывать на работы такого типа, и действовали как обычно в таких ситуациях.
То, что может сломаться - когда-то сломается. Вопрос в поведении. К тому, что все когда-нибудь сломается готовимся, пишем планы и отрабатываем их. И на тренеровках опыт получают разные люди, чтобы не сыграл фактор автобуса. Вот тут про выход из строя целой СХД рассказано
Как планы действий помогают нам работать с аварийными ситуациями в критических системах / Хабр
Та аварийная ситуация устранялась более недели. Снаружи аварийность прошла абсолютно незамеченой.
JBFW
ИМХО, "стресс" тут не совсем правильное слово, и статья немного не об этом.
Когда у тебя падает прод, и тебе нужно проанализировать проблему и найти решение максимально быстро, в двух вариантах "костыль сейчас" и "заплатка завтра" - это одна задача.
Если в то же самое время кто-то сидит у тебя над душой и долбит как дятел "Ну что? Ну когда? Получается? А что случилось? А когда починишь? А как? А почему?" - это уже совсем другая задача.
Просто в реальной жизни дятла можно выключить или просто наорать "заткнись дебил!" - то на собеседовании такой финт не пройдет )
amazingname
Вот это и есть самое главное заблуждение, которое можно прямо вставлять в рамочку.
Если очень кратко - вы проверяете не стрессоустойчивость а уверенность в себе.
Если длинно, то это два противоположных вида стрессоустойчивости. Не знаю почему но это факт, они никак не коррелируют. Как минимум могу судить по себе. Когда дело совсем плохо в процессе работы у меня будет абсолютно ясная голова. Когда я пытаюсь доказать на собеседовании что я не идиот, происходит именно то что описано в статье - короткий буфер памяти. Хуже того, я прилично тупею даже в моменты когда сам провожу собеседования, просто из за стресса от взаимодействия с кандидатом.
Почему так очень сложно сказать. Возможно это какой то древний защитный механизм. Т.е. если ты на охоте, момент ответственный и может даже твоя жизнь в опасности, включается максимальная соображала. А если ты окружён "соплеменниками" которые сильней тебя и решают, оставить тебя в племени или забраковать, навалять и выгнать, то включается максимальная реакция, потому что умным быть в этот момент быть не нужно, умных не любят, нужно вызвать у них сочувствие и в то же время не получить копьё от раздраженный коллег.
Люди по складу психики уверенные в себе, лидеры по натуре вероятно не имеют таких проблем. Такие проблемы это что то вроде лёгкой стадии аутизма, когда острое социальное взаимодействие вызывает стресс. Но беда в том, что хороший девелопер и даже лидер запросто может получаться из подобного "аутиста". Единственное что с ним не нужно делать, это предлагать ему выполнить задачу на показ начальнику, который подумывает его уволить. С остальными стрессовыми ситуациями у него может быть полный порядок.
Sabiko
Тут соглашусь, такие же ощущения. И один из комментариев, приведённых в посте, именно об этом. Когда срочная задача - у тебя максимальная концентрация и наоборот как будто выходишь на локальный пик способности соображать.
А на собеседованиях "угроза" некого другого вида, вызывает панический ступор и думать не получается совсем, только какие-то полуавтоматические реакции выдавать. Интересно, что такая же проблема у меня была на экзаменах по вождению, а вот на экзаменах в универе с ней не сталкивалась. Возможно, дело в том, что на последних у тебя есть достаточно длительный период подготовки билета наедине с собой, где ты может спокойно рассуждать.
amazingname
Да. Была бы моя воля, я бы так собеседования и проводил - позвать кандидата очно, забрать телефон, дать ему листик и ручку или комп без интернета, оставить его одного на минут 40 с "билетом" и задачей. А потом пусть рассказывает что навспоминал.
Первые 5 минут он конечно будет под стрессом, но потом успокоится и что-то вспомнит. А потом уже обсуждать будет под стрессом, но все что будет требоваться - вспомнить что надумал пока сидел.
С точки зрения HR такой формат абсолютная дичь, потому что по их мнению чувствовать себя свободно и продавать красиво в реальном времени - это самый важный навык.
vesper-bot
Если прод падает именно у разработчика, то виноват QA, потому что должен был упасть тест (а то и дев), либо девопс прода, который что-то не то запилил при выкатке обновления. Разработчик тут должен быть не при делах. Но это в идеале, который мало где достижим.
rpc1
Как удобно получается, проектированием и разработкой занимается разработчик, а в случае возникновения проблем виноваты все вокруг, но не он. В таких случаях надо не виновных искать, а проводить постмортем, выявлять где проблема и как ее избежать в будущем.
vesper-bot
Разработчик развернул код на деве, оттестировал - ОК. QA раздеплоил код на тест, оттестировал - ОК, девопсы или команда поддержки прода раздеплоили код на прод - упало. Кто виноват? По мне - в явном виде вина разработчика не видна, потому что по пути с дева на прод код прошел несколько других валидаций, и если в нём есть баг, его надо было поймать раньше, а если входные данные вызвали некорректное поведение, надо как минимум дополнить тесты, проверить наличие ретроградных поломок, ещё кучу всего в зависимости от детализации проблемы - но не всё это должен делать разработчик. Фиксить сам баг - да, его работа, но баг мог оказаться, например, в ТЗ, неоднозначная интерпретация которого вызвала каскад необнаружимых ошибок. Вот мы не так давно деплоили оттестированный код на прод - упало с треском, а баг был в некорректной процедуре деплоя на прод (не хватило прав у деплоящей УЗ, упор в бюрократию не позволил им создать выделенную именно для деплоя, контроль также в бюрократии погряз). Облаяли в итоге нас, всё равно.
Постмортем нужен в любом случае, даже если виноватого назначили, а не нашли.
rpc1
Вы в каком-то идеальном мире работаете, а сервис - это сферический конь в вакууме. За мою довольную долгую карьеру в ИТ я встречал много случаев, когда возникали баги на проде. А полностью протестировать сервис невозможно, потому что у сервисов много зависимостей и упасть может где угодно.
Например, сервис выводит какие-то агрегированные данные из внешних сервисов и показывает их на экране и вот внешний сервис в ответ на ваш запрос начинает возвращать неожиданные ответы (изменили тип поля, такое бывает) и экран у вас полностью падает из-за одной зависимости. Тут кто виноват QA или DevOps, а может разработчик, который не ожидал такого и не сделал интеграционный тест?
Или зависимости, вы обновляете спринг или том кат (или любую зависимость) и сервис после деплоя падает из-за бага который был. Или QA должен проводить полное тестирование включая нагрузочное, после каждого обновления зависимостей? Я уже не беру различные утечки памяти, некорректные данные в базе данных (например неправильный UUID), отсутствие индексов
vesper-bot
Если внешний сервис начал возвращать json, не соответствующий согласованной схеме взаимодействия, виноват внешний сервис, а если наш код не обработал ошибку валидации ответа, виноват тот, кто должен был её написать и проверить. (Хотя в соседней ветке в этом случае говорят более правильно - виновата команда как целое, один забыл обработать ошибку, второй забыл тесты написать, третий забыл согласовать схему, четвёртый забыл обработать сообщение от внешнего сервиса об её изменении, пятый не продумал, как такие сообщения обрабатывать вообще, шестой нормально эскалацию не провёл, и так далее - главное для заказчика, что "программа не работает").
При обновлении зависимостей - в идеале таки да, QA должен все тесты прогонять, включая нагрузочный, на практике всплывает всякое, а чаще всего обновляться приходится в темпе из-за найденной CVE или пойманной ИБшниками атаки (ну или прошедшей, что хуже), и на полное тестирование банально нет времени.
А вот если сервис падает внутри зависимости - вопрос пожалуй не ко мне, а к архитектору, что делать, патчить зависимость своими силами, пилить обход бага в своём коде, менять зависимость на аналог, ждать патча от коммьюнити или мейнтейнера, или вообще сменить к хренам стек. И каждый вариант имеет свою стоимость, шансы на успех, доступность и остальные факторы, влияющие на релиз.
fshp
Речь не о поиске виновных, а об устранении последствий.
QA пропустил баг, который допустил разработчик. Этот баг QA должен сам исправить?
Тут уже много людей высказались, что просто нужно иметь план действий на любой факап. Не паниковать, спокойно сесть и починить. Это очень здорово работает где-то в параллельной вселенной. В нашей же даже гиганты двигающие индустрию ошибаются. Что уж говорить про маленькие компании.
Я бы назвал сбой необходимым фактором эволюции системы, после которого вырабатываются защитные механизмы. Можно и нужно перенимать опыт у других, но абсолютно всего заранее предусмотреть не получится.
inkelyad
Вот эти гиганты - они 'звонили разработчику', что что-то не так сделал или у них починкой всего дежурная смена занималась?
fshp
Дежурная смена это sre. Они могут откатить релиз максимум. Хорошо, если это поможет. А если новый релиз криво миграцию в бд накатил и она не откатывается? Или приложение не стартует из-за какого-нибудь кэша локального побитого? Придумывать можно много. И да, в этих случаях вызванивается разработчик.
В маленьких компаниях вообще и дежурных может не быть.
inkelyad
Мы, (разработчики, да) вполне сидели в таких дежурных сменах на внедрениях. Как раз чтобы такое чинить и логи с внедрения читать. Ночных сменах. Вот прямо в офисе и сидели. Пустой опенспейс без освещения в пустом офисном здании - весьма атмосферно, кстати.
fshp
А мы релизы по субботам проводили, потому что в это время биржи (кроме крипты) не работают и любой факап не так страшен. У каждой компании своя специфика.
Yago
QA пропустил баг, остальные разработчики из команды или лид пропустили баг на ревью, а виноват разработчик, который писал код?
Нет, в командной разработке так не работает. Виновата вся команда без перехода на личности, и требуется править процессы, чтобы ситуаций не повторялось.
А устранить баг может и непричастный к написанию разработчик/лид. На то она и командная разработка, что люди друг друга страхуют и выручают в различных ситуациях, даже если кто-то перестал выходить на связь. Не раз меня так выручали от ночных правок и я страховал людей срочнофикся микробаги, когда они были заняты по каким-либо причинам. Либо просто видел баг и решал не переключать человека от другой важной задачи, и фиксил сам.
Винить причастного к написанию кода в любом случае не стоит. Всегда есть ряд обстоятельств, которые в первую очередь требуют разбора. Смотрите на них. Переход на личности в данном случае лишь подтверждает кавардак в процессах.
fshp
Вы веткой не ошиблись? Я не говорил, что кого-то нужно винить.
markmariner
Да, мой преподаватель по си тоже говорил, что сначала на пары опаздывают, а потом за руль пьяными садятся :)
markmariner
Но добавлю по существу. Упавший прод из-за новой версии должен исправляться одной кнопкой отката к предыдущему релизу и выкатом не в пятницу.
А если там ресурсов не хватает, атака, электричество выключили, то это уже не разработчика проблема.
И это я не теоретически говорю, это я так вправду работаю для того, чтобы после 18 и по выходным быть спокойным и не ждать с работы вестей.