Comments 52
Спасибо за статью, но мне кажется, нет каких-то простых вопросов, которые можно задать и узнать что за человек. На вопрос можно ответить правильно / неправильно. Что-то упустить, или наоборот - рассказать все достаточно полно. Но ведь тут как - пока не попробуешь с человеком поработать, не узнаешь, что за специалист перед тобой.
Кандидат может на 1-й вопрос ответить "Я!" и ошибиться (что для тимлида, конечно, не очень), но при этом, с большим энтузиазмом относиться к работе, брать на себя ответственность и предлагать решения. Для меня перечисленные качества важнее понимания принципа командной ответственности и подстраховки(их в конце концов легко объяснить).
Более того, если вы составили список "контрольных" вопросов и кандидат ответил не так. Это еще не значит, что он ответил неправильно. Возможно у него другой опыт, он побывал в других ситуациях. А возможно, и ваш собственных ответ, на ваш же вопрос неидеален.
Да, согласен, в идеале лучше поработать с человеком и посмотреть в деле.
Но на этапе найма у нас всегда есть ограничение по времени, поэтому приходится проводить первоначальный "скрининг".
Для меня эти вопросы не про "правильный" ответ, а про то, как человек думает и как раскрывает ситуацию. Обычно на практике ответы довольно хорошо читаются между строк.
"Возможно у него другой опыт, он побывал в других ситуациях." - да, все так, именно поэтому такие вопросы использую не как "контрольную", а как способ понять модель мышления кандидата и чего от него ожидать в работе.
Да, но как правило, мало волнуют ситуации, когда человек побывал в других ситуациях, подбор в команду осуществляется исходя из тех ситуаций, в которых оказывается команда, поэтому вопросы обычно подстраиваются именно под нужды команды, поэтому выберут того, кто на этапе собесов создаст о себе более удобное впечатление, из-за этого могут отсеяться действительно хорошие специалисты, но которым понадобилось бы время для адаптации
Кто отвечает за задачу?
У кого есть административный ресурс. Комплименты Я-модели заканчиваются там, где ответственный, проактивный, неперекладывающий сотрудник упирается в невозможность осуществления необходимых изменений из-за линейности своей должности.
Команда отвечает за результат. А роль тимлида — сделать так, чтобы команда могла его добиться.
Понятно. Здравствуй, коллективная ответственность!
А) не работать там где для решения своих должностных обязанностей (доставка работающего функционала) мешает "линейная структура"
Б) донести до "линейных" окружающих, что все таки бизнес это не пансионат для содержания менеджеров а комбайн по производству денег. Софт скиллы, все такое
Не линейная структура, а линейная должность в иерархической структуре. Где бы ни работал, как только начинается кризис, все скатывается в ответственность без полномочий. Ну собственно, да, потом уходишь и ищешь новое место.
На линейной должности есть полное право требовать зрелую экосистему менеджмента и выстроенную среду условий для выполнения чисто технической работы, не заморачиваясь на риски, проблемы, убытки и миссию бизнеса.
"упирается в невозможность осуществления необходимых изменений из-за линейности своей должности."
Да, согласен, неприятная и сложная ситуация. На практике помогают идеи из моделей внедрения изменений: искать точки влияния, союзников и постепенно расширять зону ответственности.
Если вдруг нужна будет помощь - пишите в директ, попробую помочь.
Команда отвечает за результат.
Здравствуй, коллективная ответственность!
Не совсем так. Тимлид отвечает за результат команды (выполнение всех задач), а разработчик отвечает за поставленные лично ему задачи. Всегда можно построить процесс так, чтобы у каждого его фрагмента был ответственный. Важно то, что роль тимлида включает ответственность "за всё" (в пределах команды) и возможность смены исполнителя задачи, а роль разработчика не имеет отвественности за всю команду.
Хотя да, в некоторых организациях бывает, что члены команды разработки несут коллективную ответственность за косяки ближайших коллег, менеджеров, других отделов, коммерческого и генерального директоров и т.д., а тимлид не имеет полномочий делать даже замечания команде, но это некая нездоровая организация процесса.
как бы вы оценили разработчика ядра Linux, который не пишет unit-тесты?
Как очень крутого разработчика :)
В случае низкоуровневых разработчиков точно своей отдельный контекст и стоит придумывать другую систему вопросов.
Хорошо, низкоуровневые – отдельный контекст. А разработчик распределённых систем, который верифицирует корректность через TLA+ и chaos engineering?
А вот тут думаю вопросы хорошо подходят. Если в ответе будет про TLA+ и chaos engineering, то это хорошее начало обсуждения для понимания инженерной зрелости.
но ваш вопрос в статье конкретно про unit-тесты, а не про практики верификации в целом.
если разработчику распределённых систем, практикующему TLA+ и chaos engineering, задать вопрос “пишете ли вы unit-тесты”, то он ответит “нет”, потому что TLA+ это принципиально иной инструмент совершенно иного уровня инженерии.
и получается, что проблема не в кандидате, а в вопросе?
Я бы с удовольствием заменил вопрос на более общий, если есть удачный вариант - пожалуйста, поделитесь.
вы предлагаете мне остаться в том же подходе – заменить одну редукцию на другую, но проблема не в том, что выбран неудачный инструмент, а в самом подходе: редуцировать оценку инженерной зрелости до одного вопроса или до использования одного инструмента.
unit-тесты – частный случай; TLA+ – частный случай; chaos engineering – частный случай.
а вот зрелость это не владение конкретным инструментом, а способность выбрать адекватный инструмент под контекст.
Как отражал в статье, это начало разговора, а не полная замена.
Хочется на скрининге заранее понимать, кто более перспективный. Пока из вашего ответа не понял как тогда лучше систему выстраивать?
Понимаю, что текущие вопросы неидеальные, но точно заинтересован в поиске более эффективных подходов.
обратите внимание на то, что вы сами сказали: “хочется на скрининге заранее понимать, кто более перспективный”.
вот это и есть ядро проблемы: вы продолжаете искать редукцию (один-два вопроса, которые за минуты дадут полноценную оценку) уже после того, как её ограниченность была обоснована, ещё и от меня просите более другую/правильную “серебряную пулю” в рамках этой же редукции.
именно поэтому вам и сложно понять, как выстраивать систему: потому что система – это не два вопроса.
инженерная зрелость многомерна, контексты различаются, и попытка свести оценку к быстрому фильтру неизбежно будет приводить к потере тех, кого вы сами выше назвали “очень крутыми”.
Со всем, что вы писали, согласен, но в реальности просто нет времени досконально разбираться с каждым кандидатом. Могу даже поверить, что предложенные автором вопросы дают лучшую предсказательную силу, чем алгоритмические, архитектурные и интервью на знание ЯП.
Последний раз, когда я собеседовал разработчика, он очень плохо отвечал на вопросы — и по ЯП, и по архитектуре. И обратная связь от других интервьюеров была на троечку. Тем не менее, взяли его, потому что все остальные были еще хуже, а еще и ставку у нас могли забрать. В итоге разработчик разобрался в первую неделю с довольно большим проектом, никого не отвлекает лишними вопросами, пишет хороший код.
В идеале бы брать на тестовый период в пару месяцев и смотреть, как кандидат справляется, но мир далёк от идеала. Поэтому то, что предлагает автор статьи, имеет право на жизнь.
вы сами только что описали идеальный контрпример: кандидат провалил интервью, но оказался сильным.
это подтверждает, что любые вопросы на интервью, включая предложенные автором, имеют слабый предсказательный характер качества реальной работы человека.
а “нет времени на точность” это аргумент за честное признание ограничений метода, а не за то, что метод работает 🤷🏻♂️
Вопрос же не в том, как найти способ исключить false positive и false negative, а как эффективнее получить предсказание, затратив меньше времени.
а “нет времени на точность” это аргумент за честное признание ограничений метода, а не за то, что метод работает 🤷🏻♂️
А разве кто-то утверждал, что какой-то метод отбора не имеет ограничений?
эффективность предсказания имеет смысл, когда предсказание хотя бы положительно коррелирует с результатом.
метод, который систематически отсеивает сильнейших (negative selection), – это не “менее точный, зато быстрый”, это антипредсказание.
быстро получить антипредсказание – не эффективность, а антиэффективность.
А разве кто-то утверждал, что какой-то метод отбора не имеет ограничений?
автор нигде не упомянул ограничения.
заголовок: “скажут о разработчике и тимлиде больше, чем техническое интервью”.
текст: “корреляция оказалась удивительно высокой”.
ни одного указания на ограничения до тех пор, пока на них не указали в комментариях.
метод, который систематически отсеивает сильнейших
Если бы это было доказано, то вы были бы правы. Но ни вы, ни я не знаем, какая эффективность предсказания у подхода из статьи, а какая у собеседований, как в FAANG.
текст: “корреляция оказалась удивительно высокой”.
Видимо, это эмпирический вывод автора.
negative selection не нуждается в доказательстве – он уже продемонстрирован в этой дискуссии самим автором (разработчик ядра – “очень крутой”, но по его фильтру с unit-тестами не проходит).
при этом вы принимаете “корреляция оказалась удивительно высокой” как эмпирический вывод – без данных, без выборки, без метрик, но от меня же требуете доказательств, в то время как от автора достаточно слова “видимо”.
это двойной стандарт, обнуляющий вашу аргументацию.
negative selection не нуждается в доказательстве
Если ваша цель — опровергнуть тезис: “метод Х позволяет гарантированно определить, подходит кандидат или нет“, то конечно, это легко опровергнуть. Но никто этот тезис не произносил. А вот ваш тезис как раз догматический:
это подтверждает, что любые вопросы на интервью, включая предложенные автором, имеют слабый предсказательный характер качества реальной работы человека
Мы не знаем, любые или не любые. Можно только сказать, что “какие-то вопросы имеют слабый предсказательный характер “. Но вы пишете “любые“, потому что пришли к этому эмпирически — и при этом упрекаете автора в эмпирике. Вот это тоже двойной стандар.
Каждый сам решает, что брать от статьи. Я давно заметил, что отбор по типу FAANG — неэффективный. Вопросы про тесты и ответственность мне нравятся. Даже если кандидата спросят, использует ли он Unit-тесты, а он ответит, что нет, и на этом разговор не продолжится, — это проблема коммуникации с двух сторон. И интервьюер должен спросить: “а как вы гарантируете качество кода“, и кандидату бы хорошо ответить не односложно сразу.
И по поводу статьи: не должен же автор писать тут ветвление всех вариантов диалога с кандидатом. Он показал, как можно начать диалог и на что обратить внимание.
Если ваша цель
это булверизм (вы приписываете мне цель и спорите с ней, а не с предоставленным мною аргументом).
Никто этот тезис не произносил
заголовок статьи: “скажут больше, чем техническое интервью”; тезис в заголовке тезисом не является?
по поводу обвинения в догматичности на базе слова “любые”: моё утверждение было выводом из вашего же примера – ваш кандидат провалил интервью, но (внезапно!) “разобрался в первую неделю с довольно большим проектом, никого не отвлекает лишними вопросами, пишет хороший код”.
Проблема коммуникации с двух сторон
вопрос автора более чем конкретный: “пишете ли вы unit-тесты?”.
ответ инженера, не пишущего unit-тесты: “нет”, и это не проблема коммуникации, это проблема вопроса.
Он показал, как начать диалог
он показал “больше, чем техническое интервью”, и это его заголовок, не мой, а подключение очередной уловки (булверизм) лишь подчёркивает исчерпание логоса
заголовок статьи: “скажут больше, чем техническое интервью”; тезис в заголовке тезисом не является?
Тезис “скажут больше, чем технические интервью“ не равно “скажут точно“. Вы подменили понятие на “точно не скажут“ и доказываете, что неверно. А этого никто и не имел в виду изначально. Вопрос о том, скажут ли больше или меньше, остаётся открытым.
по поводу обвинения в догматичности на базе слова “любые”: моё утверждение было выводом из вашего же примера
Это же всего лишь один пример. Мы не можем говорить про “любые“.
ответ инженера, не пишущего unit-тесты: “нет”, и это не проблема коммуникации, это проблема вопроса.
Мне хочется, чтобы разработчик был умнее, чем нейросеть с промптом “отвечай“ односложно. Я сам разработчик до сих пор и часть моей ответственности — разобраться, что от меня хотят. Поэтому и считаю, что вопросы автора имеют право на жизнь.
Я предлагаю закончить дискуссию, пусть каждый возьмёт от статьи, что хочет, или не берёт ничего.
“Скажут больше” и “систематически отсеивают сильнейших” – взаимоисключающие утверждения.
фраза “скажут точно” появилась именно у вас, следовательно и подмена тезиса тоже у вас.
А этого никто и не имел в виду изначально.
очередная итерация булверизма со сверхобобщением – защитывается как комбо 🎳
ваш пример с кандидатом был аргументом, пока работал в вашу пользу, и стал “всего лишь одним примером”, когда из него сделали вывод противоречащий вам.
третье применение двойного стандарта в течении дискуссии это уже паттерн.
Разработчик должен быть умнее
отличный пример перекладывания ответственности на кандидата за бинарный вопрос, который кандидат не конструировал.
Я сам разработчик
argumentum ad verecundiam
дискуссию закончить согласен.
Тут, на самом деле, нет противоречий. Редукция необходима, так как сложность системы, с которой происходит взаимодействие (нанимаемый сотрудник, со всеми его знаниями и опытом), не позволяет за короткое время (интервью) исследовать её полностью. Приходится ограничиваться моделью, которая априори проще оригинала, и, соответственно, имеет ограничения применения. Т.е. ключ к эффективному использованию подхода автора - понимание, что его “два вопроса” - это модельный эксперимент, и соответствующая модель имеет ограничения. Ну и, конечно, совсем здорово - понимать, в чём ограничения, как оценить применимость модели, и какие модели использовать в случае, когда эта не работает ;)
вы описали ровно то, чего у автора не было: понимание ограничений модели, оценка применимости, альтернативные модели для случаев, когда эта не работает. всё это выяснилось только в ходе обсуждения.
проблема не в том, что редукция существует, а в том, что она была подана как универсальный инструмент для достижения качественного результата.
конкретное ограничение этой конкретной модели – negative selection: автор сам признал, что разработчик ядра, не пишущий unit-тесты, – “очень крутой” (при этом забавно, что бедолага с TLA+ и chaos engineering уже не был крутым), но по его фильтру этот кандидат не проходит.
модель, которая систематически отсеивает сильнейших, это не просто модель с ограничениями, это модель с дефектом в основе.
Ответ: Unit тесты не пишем, для проверок используем такой-то подход. И описываешь TLA+ и chaos engineering
У нас в компании с тестами так: надо бы, да всё не до них. Начальство не даёт команду, а разработчикам недосуг этим заниматься. Если выделить разработчику отдельный день на написание тестов, чтобы улучшить кодовую базу, то кто будет за это платить? Нужно ведь как-то выбить деньги с заказчика под такую деятельность. Да и вообще, пусть сперва кто-то проведёт обучение, покажит хорошие примеры, что стоит тестировать, что не стоит, а что нужно сперва отрефакторить, только потом тестировать.
У меня, например, есть несколько boolean-значений, которыми жонглирует сервер, я в зависимости от этого вывожу всякие предупреждения или блоки на странице. Мне тестировать, вариант "если eventStarted == true, то блок event показан"? Но v-if="eventStarted" и так гарантирует это. Это всё равно что тестировать работоспособность vue. А тестировать правильное сочетание всех этих флагов — задача бэкенда, он отвечает за текущее состояние (я предлагал заменить пачку флагов одним строковым значением, обозначающим текущее состояние в целом, но уже поздно делать такие крупные изменения).
Короче, я без понятия, что мне можно было бы протестировать. Разве что вариант "сервер почему-то не прислал поле X у объекта", а то бывает такое, что я в типах записал поле как обязательное, а бэкендер решает его вообще не присылать, если там пустая строка.
Наверное, стоит начать не с "напишите тесты", а с "устройтесь на работу, где вашей задачей будет не просто вывести html-блок с данными или отправить поля формы в API".
Стоило начать с объяснения, что такое "отвечать за задачу". Типа, кого накажут, если задача будет закрыта, время списано, а оно всё равно не работает как просили? Смотря какой заказчик. Орать он будет на менеджера. Но если это не ключевой заказчик, то менеджер передаст разработчикам, что не всё починилось, надо передалть. А если заказчик ключевой, то менеджер передаст то же самое, только с использованием матерных слов. Наказания вряд ли будут. Ну а какие наказания? Понизят часовую ставку? Куда уж ниже? Перестанут в рабочее время отпускать в ветеринарку или отвезти мать к зубному? Себе же хуже сделают.
Не совсем понял, как ответ "хорошего тимлида": "у каждой задачи есть ответственный", помог бы в первом случае, когда задачу перекидывают. Бывает, что такое перекилывание возникает даже не между командами в рамках компании, а между компаниями, когда 1 линия поддержки (а,может, ещё и вторая) реализуется заказчиком программного продукта
Интересный вопрос. И вот тут как раз и возникает та самая ситуация. Если никто не возьмет на себя ownership проблемы, то пользователь так и будет с проблемой. Если тикет не закрывать, а позвать тимлида помочь с кросс-командной проблемой / проблему с другими организациями - это уже здорово и хорошее решение.
В блоке про тимлида - то, что он возьмет на себя решение проблем - это здорово. Ответ - "Я", это хороший ответ. Но поверх этого ответа важно, чтобы он умел себя масштабировать. Чтобы не в одно лицо решать все проблемы, а чтобы подключаться только в тех ситуациях, где без его помощи не справляются.
закрыли свою задачу с формулировкой: «Проблема не у нас»
Очень удобно наверное перекладывать ответственность с фирмы на кандидата, которого в первый раз видите. Довольно лживая статья получилась.
Ни один нормальный человек не будет брать ответственность за то, над чем он не имеет контроля. Если команда девопсов закрыла тикет, и не нашлось человека способного сказать "да вы охренели что ли?" - то каким же магическим образом человек с улицы должен брать на себя какую то "ответственность" за их действия?
То же самое и к юнит тестам относится. Где то есть отдельная команда тестеров, и разработчик уж точно не должен их писать. Где то применяется test-driven development, и внезапно, разработчик опять не сам пишет тесты. Ну а если юниты у вас начал писать лид (наверное на созвонах это делает) - то тут вообще комментировать - только портить. Понаберут ЧСВшных эйчаров, потом волшебника гудвина ищут.
за автора рад :) но чутка не дожал до сути - суть этих "простых" вопросов в том что бы понять "а будет ли мне комфортно работать с данным человеком" (потому и нет на них "правильных" ответов)
и имхо это лучшая стратегия найма, при чем для обеих сторон.
сложность же в том что это не универсальные вопросы, и каждому придётся формулировать свои, с "чужими" не выйдет, тк ответа не поймёшь (ответ то неформальный) - собственно что мы и видим в комментариях - очень много жуют формальных моментов, а по сути ничего
автору благ и удач!
По мне это просто какие то завышенные ожидания или человек сам себе просит соврать. (От большинства обычных работодателей, когда сам обычный а хочешь о го го го)
Большинство компаний не платят работнику 100 тыщ долларов в год. И ждать что ваш проект является для него чем то сакральным ради которого будут радеть и переживать как за родной ну такое себе. Поэтому для меня ответ "Я отвечаю только за свою область, сферу и уровень" полностью нормальный.
Да чисто по человечески если работодатель хороший, с которым в средним можно особо не напрягаться и норм(имено норм не кучу золото, но и не миску супу) платит, но когда надо напрячься - берёшь и хотя бы стараешься. Ладно. Но это не прям обязанность.
По второму это не универсально. Чем проще организация - тем меньше бюджеты. Вот у меня в сфере "обычных сайтов" - зачастую вообще тестировщика даже нет. Ему платить нечем)) Ну какие тут юнит тесты ещё. Потом когда кто-нибудь наткнётся попробуем починить))
Странное чувство. Мне не нравится как сформулировано. Но по сути я вроде со всем согласен
Очень сильно зависит от процессов в компании.
На хороших процессах- спору нет, а вот с плохими - нюанс на нюансе.
По unit-тестам плохие процессы очень сильно бьют.
Если задачу надо было начать решать позавчера, вчера получили описание задачи, сегодня прилетели новые правки по требованиям (тестировщики только сегодня их вычитали), а завтра релиз…
То тесты получится писать хорошо если на железобетонную логику, ту, которая не поменяется по прихоти менеджмента.
Те же паршивые процессы напрочь убивают ответственность за баги. Иной раз приходится строить звездолеты на настолько зыбком фундаменте, что удивляешься, что оно хоть как-то работает. Начинаешь расковыривать какой-нибудь баг, а там наслоения вторпродуктов такие, да еще от давно уволившихся ребят, что прямо теряешься. Кто виноват в данном случае? Нанятый вчера специалист, или система, в рамках которой выстроены такие процессы?
Как завуалированно переносится ответственность, с “хорошего менеджера” (который как раз должен был настроить эти процессы взаимодействия и поделить ответственности) на “плохого инженера” (который якобы должен выполнить работу менеджера, по мнению автора).
В идеальном мире все так, ответственность несёт исполняющий, раз он взялся, тут спору нет. Но если человек называется менеджером (лидом, пм), то будет добр - создай условия, чтобы такого в принципе не возникало.
Так же как и инженер - вряд ли будет спрашивать у менеджера: “как сделать это, а как то”. Это его зона ответственности, и чем меньше он отвлекается на ошибки менеджмента - тем эффективнее работает.
Описанный 2 пример с backend разработчиком - будет работать по умолчанию, если условием для “отфутболивания” задачи будут не просто “у нас все работает”, а “у нас все протестировано и вот результат”.
Дальше - задача управляющего проектом(командой) решить в каком же месте оно тогда могло сломаться, с кого спрос и где архитектурная проблема.
Про первую ситуацию из первого вопроса. Если тикет гуляет по кругу, а команды по сути перекладывают друг на друга ответственность, то проблема в такой компании явно не на уровне сеньора, а на уровне организации работы. Так же, почему-то не была упомянута команда тестировщиков, которая и должна воспроизвести баг. Понимаю, что хотел сказать автор, но ответил бы на первый вопрос немного иначе. За все задачи, что поступают мне ответственен я, пока они не будут выполнены, либо пока на 100% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами. Чего буду в подобных ситуациях ждать и от коллег, а не просто "у нас всё хорошо, ищите сами", я то найду, но если выяснится, что проблема всё же на строне коллег выйдет неприятный момент.
Касаемо тестов. Ответ в наших реалиях очень простой. Без git и unit тестов даже разработка пет проектов невозможна. Это базовый минимум в наши дни, особенно с приходом llm, которые программисты любят использовать, но не особо любят ревювить их код. Без тестов, проект сейчас просто невозможно адекватно поддерживать вдолгую. Какую бы вы замороченную и идеальную архитектуру не выбрали и какую бы навороченную инфру вокруг неё не выстроили, без тестов это превратиться со временем в кучу малу.
Имхо, но эти вопросы сейчас валидны для всех. Я мидл разработчик и это 2 базовых вопроса, которые и джунам задают.
Мне кажется сейчас в принципе актуальнее вопрос про ответственность, потому что именно за неё мы получаем зп. Контракт с бизнесом очень прост. Бизнес платит деньги нам не за писульки кода, а за ответственность стабильной работы созданных по запросу бизнеса решений. Всем плевать, что вы использовали лучшие практики. Если что-то не работает спрашивают с нас. Да да, капитан очевидность, но вы даже не представляете, как много людей не понимают этой простой истины. Бизнес не будет слушать про, то что json'ы пользователю не приходят из-за особенностей вашей же выстроенной архитектуры, он найдет вместо вас тех, кто сделает так, чтобы json'ы приходили, если вы не хотите нести за это ответственность.
Да ладно)) 10+ лет в веб-программировании. Ни на одном сайте не было юнит тестов, да и мерзкий ГИТ к счастью большая редкость. Мне иногда кажется что статьи на хабре про ИТ это как с другой планеты. С большим отрывом от массового народного продукта)) Я объясняю это спецификой аудитории хабра, что большая часть обычных ИТ специалистов тут не сидят, т.к. работаю ради зарплаты и им интереснее другие темы танки, сериалы и т.д. Соответственно их мнение мало представлено. Из за чего картина в сфере сильно искажается.
Платят за то что могут себе позволить. У работодателей, как и у нас есть градация. Мощные богатые действительно часто могут попытаться и преуспеть в найме основном горячих, мотивированных, очень квалифицированных, стремящихся развиваться сотрудниках.
А вот середнячки не могут себе такое позволить их основной рабочий состав - это работающие за зарплату без лишний инициативы и желания развиваться сотрудники(не стоит путать с полными неумехами и неспособными контролировать свою лень лодырями в ситуациях предельно ясных кто и что должен сделать, от них действительно стоит избавиться). Поэтому нытьё про ответственность тут не проканает, да можно потом уволить какого-нибудь середнячка, но скорей всего на его место придёт такой же если не хуже, которому еще и осваиваться фиг знает сколько времени надо.
Однако и середнячки ещё ничего. А бывают ещё хуже работодатели. Те вообще пусть радуются и спасибо скажут что хоть что то работает))
Когда разработка работает без системы контроля версий - это не "массовый народный продукт", а "дно разработки". Бэкапы исходников скриптами, ручные объединения правок... Так лет 20-30 назад делали, за это время можно было внедрить git, в котором это автоматизировано общепринятым способом.
И большинство разработчиков всё-таки и git используют, и юнит-тесты пишут, даже на начальном уровне, что уж говорить о "середнячках". Да, есть очень простые проекты, где тесты не нужны, есть модули систем, где они малоприменимы, но обычно тесты полезны.
Системы контроля версий и есть то самое дно, зло и угнетатор. Для разработчика точно. Это как покакать и вместо того чтобы просто подтереться и помыть руки. Начинаешь в тетрадку записывать. Какашка отправлена, бумага получена. Ужас и жесть какая то. НЕНАВИЖУ!!! Не буду я вместо нормального cntrl+s в нотпаде++ вводить какую тучу галимых консольных команды и плясать с бубном просто чтобы сохранить свой код.
У меня вообще есть теория. Что это Гитлера в аду черти жарили. А он такой отпустите меня реинкарнировать я снова людям поднасру. Вот он взял и придумал это исчадие ада назвав в честь себя сокращено "Гит" программистам на мучения.
Все эти джуны, мидлы, сеньоры. Даже в одной конкретной области часто имеют расплывчатые границы и сложно куда то однозначно отнести человека. Чего уж говорить про разные сферы. Мидл в программировании ракет и мидл в народном производстве обычных сайтов. Ну это разные планеты.Чтобы ими оперировать.
Вот за 12 лет, я поведал где то 100-200 сайтов изнутри. 0 юнит тестов на них. И где то около 10 был этот какогит. И дело даже не столько в сложности проектов, сколько в бизнес модели. Не готовы заказчики обычных сайтов платить в полтора два раза больше за хорошо оттестированный код. Проще этот баг потом поправить когда кто-нибудь обнаружит. Поэтому у меня к юнит тестам нет неприязни в отличии от гита. Если из-за того что Гиту я показываю фиги, где на собеседованиях меня не взяли или давили. Да и то куда меньше проблем чем из за того же незнания CSS. То про юнит тесты ни разу никто не спросил.
Ну я конкретно в веб разработке поменьше, лет 6, до этого был в десктоп разработке + администрирование сетей/серверов. Причём я буквально тот самый создатель "массового продукта", потому что пишу в основном под wordpress и laravel на php, сейчас немного вкатываюсь в go.) У меня как раз много проектов сейчас скопилось, где git и автотесты не использовали и они с годами превратилось в legacy ад. Хороший пример сайты на wordpress. Сам по себе wp очень плохо поддаётся покрытию тестов. С git ещё ладно, можно вынести в репозитории отдельные плагины, чтобы не тащить всё на сервера, какого-нибудь github. Я специально для этого создал даже небольшую composer библиотеку, что основана на основе шаблонного метода (да, да, да сейчас тут на хабре мне расскажут, что нужно было DDD пихать, а я такое видел, и вообще делать плагин для wp на миркросервисах иначе не тру архитектура) и позволяет создавать плагины в ООП стиле, отделяя бизнес логику от wp приколов, по типу action filter и прочего. Правда моя библиотека тоже кривая, но лучше, чем ничего.) Надо бы её довести до ума как-нибудь.
Так вот, даже моя кривая библиотека позволила покрывать тестами код wp плагинов и это облегчило жизнь, убрав огромное количество плавающих багов. В wp они не редкость, где action в action в filter с кучей transients. А теперь представьте, что со всем этим нужно подружить нейросеть и чтобы она ничего не сломала.) К слову, о нейросетях, сейчас все агентные нейронки, по типу claude, codex и т.д., не просто так создают папочку project_name.worktree с отдельной git веткой внутри и не удаляет её после apply.) Codex вон вообще работает через github создавая самостоятельно PR.
Касаемо тестов, ну вот недавно у меня была задача написать десяток сложных медицинских калькуляторов, где расчёт шёл не просто по формуле, а с использованием разных медицинских таблиц и особенностей расчётов, интерпретаций ответов исходя из научных статей. Конечно, все расчёты для калькуляторов были изолированы друг от друга, но без покрытия тестов, я не представляю, как бы этот проект закрыл. Учитывая, что калькуляторы могут использовать одни и те же таблицы, а нейронка, чтобы подогнать ответ обожала их немного менять, либо если запретить им строго менять, они делали "хаки", т.е. пытались подогнать например округлением или интерполяцией под ответ. Но когда есть десяток тестов с 100-1000 кейсами основанных на эталонных данных, уже мухлевать ей было сложно. Поэтому и говорю, что не представляю как сейчас делать проекты без git и unit тестов. Причём unit тесты это один из типов тестов, которых намного больше, но unit имхо это базовый минимум) Тем-более, что сейчас можно тестами покрывать проект "лениво" при помощи тех же нейронок. Да, так лучше не делать, но это лучше, чем ничего.) Главное следить чтобы не было галлюцинаций наподобие assert(true, true), нейронки такое любят 😂.
В общем, советую попробовать применить у себя в проектах хотя бы unit тесты. Поначалу будет непривычно, но потом вы даже не представляете, как вам это жизнь облегчит, даже если вы ведёте один проект и один программист на нём, который идеально его знает.)
А что если в случае ответа "Я за всё отвечаю" от сильного разработчика, вышестоящий увидит угрозу своему креслу и отклонит кандидата под другим предлогом?
Все сильно зависит от этапа на котором находится задача и на разных этапах граница ответственности может размываться.
Когда задача проходит ревью, когда задача уходит в тестирование и даже когда залетает в прод. Ответ «Я», на мой взгляд, не совсем корректен, всё зависит от выстроенного процесса.
Вопросы для разведения полемики, имхо
Цель их крутая - понять как человек мыслит, а не какие технологии знает, за это респект.
СТРЕЛА АРИМАНА
Иван Антонович Ефремов - среди огромного количества фундаментальных открытий, сделанных в самых различных областях - ввел понятие т.н. "Стрелы Аримана". Которое он определял как: "...тенденцию плохо устроенного общества с морально тяжелой ноосферой умножать зло и горе." В результате чего "...каждое действие, хотя бы внешне гуманное, оборачивается бедствием для отдельных людей, целых групп и всего человечества...".
На самом деле открытие "Стрелы Аримана" - это само по себе фундаментальный скачок в понимании процессов социальной динамики, невероятно важное понятие, которое само по себе стоит целых трактатов и монографий "на тему этики". (А Ефремов вводит его походя, как часть приключенческого романа!) Хотя, конечно, постфактум кажется, что это же элементарно! Это же просто выводится из законов диалектики: "...Идея, провозглашающая добро, имеет тенденцию по мере исполнения нести с собой все больше плохого, становиться вредоносной..." Ну да, отрицание отрицания в чистом виде!
Однако ДО Ефремова подобные вопросы мало кто рисковал поднимать. (Ну да, как же это может быть: зло порождается добром! Это же противоречит всем обыденным "истинам". Хотя на самом деле именно то, что противоречит этим обыденным истинам, и является верным.) Но теперь, после того, как "Час Быка" не просто написан и опубликован, но и прочитан "любым образованным человеком", стоит только удивляться тому, что указанное вспоминается так редко!
Лично мои аргументированные ответы на вопросы:
Я (бэкенд, в основном крупные банки) отвечаю за задачу в области технической реализации, здравого смысла при даблчеке аналитики и качестве (если QA не нашли баг, то проблема не в QA, а в моём коде всё же). Я не могу отвечать за фронт и бизнесовые решения при всём желании - сроки всегда сжатые и играть на всех ролях я просто не успею, хотя такой опыт тоже был вне банков. За настройку инфры могу отвечать частично, тут уже есть место для обсуждений.
Зависит от сроков и количества задач. Если сроки не горят - могу сделать тестовое покрытие, если горят - более приоритетно сделать задачу
Два вопроса, которые скажут о разработчике и тимлиде больше, чем техническое интервью