Роскосмос пару дней назад опубликовал отчёт о том, почему упала "Луна-25". Там конечно канцелярит, но можно примерно понять, что двигатель коррекции получил неверные данные от акселерометра:
из-за возможного попадания в один массив данных команд с различными приоритетами их исполнения прибором
Это очень похоже на программную ошибку, а это моя сфера, и я решил над ситуацией поразмыслить.
Хейтеры сразу стали строчить комментарии в стиле "Ололо, наняли каких-то идиотов, которые простейшие тесты не провели". Тут обычно справедливо вспоминают аварию с европейской ракетой Ариан-5 в 1996 году. Там буквально из-за пары строчек кода в результате неправильного приведения числовых типов ракета за 7 млрд баксов развалилась на куски в воздухе. Бывает.
Что касается Роскосмоса, при всей его сомнительной репутации, объяснение "Дураки не провели тесты" звучит лично для меня неправдоподобно. На мой личный взгляд возможны два варианта:
1. Если в описании ошибки слово "приоритет" обозначает какой-то признак внутри объекта команды, значит, на входе в приёмный модуль эти команды не были отфильтрованы. Выглядит как грубая ошибка, целый логический блок упущен. Вряд ли этот блок вообще не написан, скорее всего он не выполнился. Такое бывает, если в тестовой среде есть какое-то условие, которого нет в рабочей, и именно это условие отвечает за выполнение участка кода.
Сталкивался с таким миллион раз. Самое дикое из последнего: код парсит эксель-таблицу с числами. Разработчик написал, запустил проверил, прогнал тесты, всё ок. Отправляем в прод — все числа будто бы рандомно меняются на другие. Запускаем снова — у всех разработчиков функционирует нормально, а в проде на сервере нет. Таблица одна и та же. Можете подумать, почему так. Ответ: у разработчиков стоит русская локаль и десятичный разделитесь это запятая, а на проде в докере точка. При парсинге на проде запятая уже интерпретируется как разделитель тысячных разрядов.
2. Куда вероятнее, что слово "приоритет" в описании ошибки обозначает время, а, значит, список команд просто не был отсортирован, и в обработчик уже после актуальных значений попали какие-нибудь начальные нулевые данные, сбившие логику. По косвенному описанию проблемы очень похоже именно на это. Значит, на тестах всегда порядок возникновения команд соответствовал порядку их прихода, а в реальности перестал соответствовать. Вообще, работать с железом очень сложно. Какую-нибудь схемку заглючило от холода, она задержала ответ от датчика на миллисекунду, и всё. Никто не знал, что такая проблема возможна, пока она не возникла.
Мне рассказывали о таком случае: юзер логинится на сайт и иногда логин проходит, а иногда нет. Логин и пароль те же самые. Просто в случайные моменты времени ему возвращают токен авторизации, а в другие моменты времени ошибку 403. Никакой закономерности нет вообще. Нет зависимости от времени суток и даты. Сервер точно работает стабильно и не падает все 100% времени. Почему так может быть? Ответ: у сервиса авторизации два инстанса, перед которыми балансировщик нагрузки. В одном инстансе данные для авторизации есть, в другом нет. Балансировщик при примерно одинаковой нагрузке включает просто случайный выбор между ними.
В общем, программисты иногда допускают такие косяки, что какая-то мелочь может привести к серьёзной аварии. Это я вам говорю как программист, который пишет для атомных станций :)
#dev
Magnit Tech #interview#dev
Что? Да. У сети магазинов «Магнит» внезапно большой современный технический отдел. В обслуживании парка из 30к магазинов без развитого айти никуда. Увидел вакансию тимлида .NET, и там прямо очень похоже на то, чем я занимался в АСЭ: электронный документооборот, BPMN-системы, интеграционные потоки. А ещё можно было бы всем говорить, что работаю в Магните.
Скрининг показался чуть менее номинальным, чем в Ozon. Вообще, роль эйчаров тут была более глубокая, и эйчар присутствовала на всех секциях. Изначально должна была быть одна большая общая секция, но в итоге оказалось две.
Общая техническая и архитектурная секция
В целом, явно видна попытка провести собеседование одностадийно (с моей точки зрения это плюс). Была эйчар, старший разработчик и техлид/архитектор. Эйчар задавала вопросы по опыту и по менеджменту. Затем вступил техлид.
Вопросы местами были странными, и почти на каждый вопрос после моего ответа техлид отвечал ещё и сам. Иногда вопрос казался заковыристым, но ожидался на деле какой-то совсем школьный ответ, например:
Интервьюер:
— Скажите, а кроме EntityFramework, какие вы ещё знаете средства взаимодействия с БД?
Я (тут я подумал, что он интересуется альтернативными ORM):
— Dapper пробовали один раз, в некоторых случаях он вполне удобен, работа чуть более низкоуровневая. Ещё активно изучал Linq2Db, потенциально выглядит очень интересно, но на практике так и не удалось применить.
Интервьюер:
— На самом деле можно ещё и просто писать SQL-запросы!
И далее он пару минут рассказывает, почему SQL-запросы лучше, чем ORM. Не «чем лучше», а именно «почему лучше», то есть защищая позицию полного отказа от ORM в любых условиях. Позже в другом вопросе он защищал отказ от строгих типов при десериализации, что на мой взгляд является признаком не выстроенных процессов по согласованию контрактов.
Пару раз спросили про вещи, о которых я никогда раньше не слышал. А после собеса полез искать, и узнал, что это давным-давно deprecated. Зачем про это спрашивали? Либо просто прозондировать мой опыт (то есть, писал ли я на .NET Framework 20 лет назад), либо у них где-то используется. Второе гораздо хуже, но и первое не слишком осмысленно, на мой взгляд.
Языковая секция
Далее эйчар написала, что они совсем забыли задать мне вопросы по языку, и предложила ещё один небольшой созвон на 40 минут. В итоге вышла почти часовая полноценная языковая секция. Вопросы в основном ожидаемые, но пара странных тоже была. Если в Ozon гоняли по глубоко академической теории, то здесь иногда цеплялись за какие-то невероятно нишевые примеры использования, которые в опыт к программисту могут попасть только случайно. Из-за этого у меня осталось послевкусие, что прошёл я средненько.
Результат
Ещё через пару дней эйчар написала, что всё очень хорошо, я понравился, но, к сожалению, у них сотрудник изнутри пожелал вырасти до тимлида, и они отдали предпочтение ему. Ну, бывает. Странно, что в момент открытия вакансии этот вопрос не проработали явно с собственным же персоналом. По крайней мере это собеседование не отняло много времени и дало любопытный опыт, так что я не расстроился.
Что понравилось:
1. Роль эйчара более активная и глубокая
2. Мало стадий, в норме вообще одна
Что не понравилось:
1. Интервьюер слишком много времени посвятил тому, чтобы защищать свои собственные решения, которые он принял в компании
2. Есть признаки работы с легаси, и в целом не слишком современных технических подходов, но могу ошибаться
И так, Ozon Tech. #interview#dev
Наверное, первая крупная организация, которая приходит на ум, когда думаешь о работе для C#-программиста. В Озоне и правда очень много всего на шарпе. У нас туда уходили разработчики из дирекции, но и обратный случай был (когда разработчик перешёл в АСЭ из Озона). Так что у меня была одной из первых, куда я подался. Но подавался через знакомства. Хотя, я думаю, что и при обычном отклике по общим каналам мне бы написали. Эйчар отвечала быстро и охотно, но скрининг был скорее номинальным, просто по ключевым технологиям: .NET, PostgreSQL, Kafka итд.
А теперь важный дисклеймер: это первый раз в жизни, когда я пошёл на собеседование, как соискатель. И вообще, резюме я оформил вот только в мае этого года. До АСЭ я много лет работал на аутсорсе, а в АСЭ устроился по приглашению после хакатона, собеседования не было. Так что уже тимлидом я проводил собеседования, но сам их не проходил.
К сожалению, навык прохождения собеседований соотносится с настоящим умением работать программистом очень ортогонально. Я распишу своё мнение по современным процессам найма как-нибудь потом, но достаточно сказать, что для подготовки я в течение двух недель читал книжки и общался с DeepSeek, и без этой подготовки я бы собеседования нигде не прошёл. Хотя, разумеется, двухнедельное чтение книжек не сделали меня ни на йоту лучшим разработчиком, не добавили мне опыта и умений.
После первичного скрининга в Озоне три секции: технический скрининг, большая техническая секция и system design с небольшим фитом в конце (фит это общение с руководителем на предмет того, совпадаете ли вы).
Технический скрининг
Чисто разговорная секция на 40-50 минут. Интервьюер один. Задаёт вопросы общего плана по языку, структурам данных, многопоточности. Ничего неожиданного нет. Я шёл на ведущего разработчика C# (это тимлид), так что нужно быть готовым рассказывать про поколения сборщика мусора и особенности работы IO-bound операций в асинхронном контексте. Секция сугубо академически-теоретическая. Кроме языка была пара вопросов по энтерпрайз-архитектуре и по базам данных, но без копания вглубь.
С моей точки зрения для скрининга всё равно секция чрезмерно подробная, и позже на большой технической секции часть тем повторилась.
Большая техническая секция
Два интервьюера, два часа. Задачи по коду, но не на алгоритмы, а скорее на решение конкретных кейсов. Например, нужно параллельно читать из кэша и из БД (если в кэше нет), как это написать максимально эффективно. Дан шаблон, который нужно заполнить. Параллельно задавали вопросы по теории.
Одна задача по SQL (я решил только с подсказкой). Вообще с чистым SQL в современном энтерпрайзе работают мало и редко. Когда дошли до этой задачи, я честно сказал собеседующим: «В реальной работе, получив такую задачу, я бы изучил документацию по средствам СУБД, которые позволили бы мне её решить, и погонял бы тестовые запросы на предмет правильности и оптимальности». По моим ощущениям, им этот ответ не понравился, и в целом мне показалось, что оценили мои навыки в этой части низко.
И в конце кусочек код-ревью. Когда я сам проводил собеседования, это была моя любимая часть, потому что наш пример кода на ревью содержал сразу большой пласт разнообразных проблем: инъекции, ошибки асинхронности, освобождение неуправляемых ресурсов, безопасность итд. Сразу было видно, с чем человек часто сталкивался, а с чем редко.
Здесь на ревью я стал давать комментарии по кодстайлу, за которым, как тимлид, тоже регулярно следил. Но меня попросили сосредоточиться на проблемах другого рода, и по сути весь код крутился вокруг неверного использования lock. Я увидел эту проблему, предложил решение, но не смог глубоко объяснить, какими особенностями поведения среды выполнения вызвана эта проблема.
Понижение должности
Через пару дней эйчар написала, что на ведущего разработчика (тимлида) они не готовы меня рассмотреть, но готовы на старшего (сеньора). Запомните этот момент. Я согласился. На мой вопрос о том, ниже ли вилка, она ответить не смогла, и сказала, что обсуждать нужно с руководителем.
@Chatbotcreatorbot
Qué puede hacer este bot?
Con este bot puedes crear tus propios Telegram Chatbots o usar plantillas existentes. No se requieren habilidades de codificación.
Idioma: Inglés
(visto en @BotsGram_cu)
#create, #chat, #development, #dev, #botbuilding