"Давайте понимать, что лайвкодинг - это этап собеседования со своей спецификой (которая не всем подходит) позволяющий нам получить много полезной информации для принятия решения по кандидату."
Какие альтернативы и на каком этапе собеса вы предлагаете кандидату если онлайн кодинг ему не подходит? Я не умею лайв кодинг, всегда предлагаю альтернативу по разбору существующего кода, поску ошибок, рефакторингу. Практически всегда получаю отказ. И да, в VK тоже отказали изменить формат собеса (one day offer).
Тоже не понимаю зачем всё это всё. Алгоритмы, онлайн коддинг. Приходишь на новое место и первое что ты делаешь - не крутишь бинарное дерево на причинном месте в режиме онлайн коддинга, а разбираешься в чужом коде. Иногда в очень дремучем легаси. Соответственно зачем устраивать цирк из собеса? Можно же просто давать кусок кода и попросить в нем разобраться,исправить баги, недочеты,выполнить рефакторинг. Хоть в режиме онлайн, хоть с перерывом в офлайн на подумать.
Это первая система, которая позиционировалась как полностью интегрированная, с приложениями и графическим интерфейсом. Она была известна как «The Xerox Star», позже была названа «ViewPoint» и ещё позже переименована в «GlobalView».
Почему вы не упомянули про то, что отладка превращается в пущий кошмар? А если происходит падение программы, то по логам невозможно определить где и почему упало, в каком модуле. Например, просто в provide прописали вызов конструктора,а сам конструктор возвращает nil. А если ещё там сложная иерархия, то вообще ужас. Опять же, чтобы просто написать тесты, приходится наворотить тонны кода, чтобы просто обеспечить работу всех DI. Проект конечно структурируется,но он становится очень сложным в поддержке и сопровождении. Новым людям сложно разбираться в этой магии. А про то чтобы разобраться с иерархией вызовов я вообще молчу, потому что не очевидно,не наглядно и даже ide не помогает. И самое главное : зачем тащить в Go идеологию Spring Boot? Здесь это не нужно.
Я бы рекомендовал не исключать Хабр.Карьера из списка площадок для поиска работы. По своему опыту и опыту коллег могу сказать,что самые лучшие предложения и серьезные фирмы находим там.
Спасибо за статью. У меня и коллег разработчиков было всё так же, один в один. Кто-то ушел через 7 месяцев sbergile, у кого-то хватило нервов на 1,5 года. Но уволились все.
Опять же это в вашем радужном мире теории. На практике в канбане нет Service Request Manager, Service Delivery Manager. А есть команда разработки и тимлид команды, который рулит созданием задач и приоритетами.
Agile-манифест читал, и не только его: книги, митапы. Плотно знакомился с вопросом, чтобы продуктивно спорить с scrum-сектантами. За роли и события в kanban не согласен. Всё таки их существенно меньше. Но вот если kanban внедряет scrum-сектант, то получаются те же яйца,только в профиль. Спасибо за продуктивный спор, интересно было послушать вашу точку зрения!
Вот эти шаблонные фразы : "проблема здесь не в скраме, а в способах его применения","мы гибкие" и "соблюдение церемоний повышает продуктивность" постоянно и слышу от скрам-сектантов. Да и вообще они всегда только шаблонными фразами из книг и манифестов общаются. Возникает вопрос - а зачем этот скрам вообще нужен,если от него столько проблем и негатива? Может стоит или чётко прописать все правила или вообще его не применять? Сейчас вы пытаетесь защитить скрам,перекладывая ответственность за реализацию на кого угодно,только не на самих адептов скрама )))
Есть kanban и waterfall. Разработчикам с ними комфортно, зачем натягивать сову на глобус?
а что такое нормализация и денормализация json? в мире бэкенда в контексте нормализации обычно БД имеют ввиду.
Можно же воспользоваться сервисами WebSDR для приема. Но это если прям хочется сырой сигнал и самому производить цифровую обработку сигналов (http://www.websdr.org/).
Есть готовые инструменты для обработки сигналов со спутников, например: https://www.satdump.org/Satellite-List/
По получению телеметрии от Сube Sat есть проект: https://satnogs.org/
Вот пример доски: https://dashboard.satnogs.org/d/QjDe5S8mk/satellite-telemetries?orgId=1
Потрясающая статья! Приятно встретить единомышленника!
Жаль,очень жаль что ещё одна прекрасная компания превратилась в agile-секту... А как поступили с теми кто не захотел работать с по этим принципам?
Спасибо за статью!! Всё кратко и емко разложено по полочкам! Приятно читать!
"Давайте понимать, что лайвкодинг - это этап собеседования со своей спецификой (которая не всем подходит) позволяющий нам получить много полезной информации для принятия решения по кандидату."
Какие альтернативы и на каком этапе собеса вы предлагаете кандидату если онлайн кодинг ему не подходит?
Я не умею лайв кодинг, всегда предлагаю альтернативу по разбору существующего кода, поску ошибок, рефакторингу. Практически всегда получаю отказ. И да, в VK тоже отказали изменить формат собеса (one day offer).
Тоже не понимаю зачем всё это всё. Алгоритмы, онлайн коддинг. Приходишь на новое место и первое что ты делаешь - не крутишь бинарное дерево на причинном месте в режиме онлайн коддинга, а разбираешься в чужом коде. Иногда в очень дремучем легаси.
Соответственно зачем устраивать цирк из собеса? Можно же просто давать кусок кода и попросить в нем разобраться,исправить баги, недочеты,выполнить рефакторинг. Хоть в режиме онлайн, хоть с перерывом в офлайн на подумать.
Было бы интересней почитать историю от отечественного разработчика.
Она бы звучала так: N-лет разработки на Qt, а потом пришлось менять стек из-за того что вакансий кот наплакал и зп ниже рынка.
Интересный проект, хотелось бы пощупать руками код
Xerox 8010 Star (1981 год)
Это первая система, которая позиционировалась как полностью интегрированная, с приложениями и графическим интерфейсом. Она была известна как «The Xerox Star», позже
была названа «ViewPoint» и ещё позже переименована в «GlobalView».
А потом уже появилась Mac OS
Реальная вакансия в крупное предприятие с очень сложной и ответственной работой.
https://rostov.hh.ru/vacancy/76559161?from=vacancy_search_list
Почему вы не упомянули про то, что отладка превращается в пущий кошмар? А если происходит падение программы, то по логам невозможно определить где и почему упало, в каком модуле. Например, просто в provide прописали вызов конструктора,а сам конструктор возвращает nil. А если ещё там сложная иерархия, то вообще ужас.
Опять же, чтобы просто написать тесты, приходится наворотить тонны кода, чтобы просто обеспечить работу всех DI.
Проект конечно структурируется,но он становится очень сложным в поддержке и сопровождении. Новым людям сложно разбираться в этой магии.
А про то чтобы разобраться с иерархией вызовов я вообще молчу, потому что не очевидно,не наглядно и даже ide не помогает.
И самое главное : зачем тащить в Go идеологию Spring Boot? Здесь это не нужно.
Я бы рекомендовал не исключать Хабр.Карьера из списка площадок для поиска работы. По своему опыту и опыту коллег могу сказать,что самые лучшие предложения и серьезные фирмы находим там.
Спасибо за статью. У меня и коллег разработчиков было всё так же, один в один. Кто-то ушел через 7 месяцев sbergile, у кого-то хватило нервов на 1,5 года. Но уволились все.
Полностью с вами согласен! Приятно встретить человека, который понимает весь абсурд этого театра под названием "гибкие методологии"
Когда стоит использовать Скрам в разработке? - тогда когда нужна имитация бурной деятельности,вместо результата
Спасибо за интересную статью!
Опять же это в вашем радужном мире теории. На практике в канбане нет Service Request Manager, Service Delivery Manager. А есть команда разработки и тимлид команды, который рулит созданием задач и приоритетами.
https://scrumtrek.ru/blog/kanban/5796/kanban-scrum-agile-otlichiya/
Обратите внимание на раздел "Разница с точки зрения предусловий"
Agile-манифест читал, и не только его: книги, митапы. Плотно знакомился с вопросом, чтобы продуктивно спорить с scrum-сектантами.
За роли и события в kanban не согласен. Всё таки их существенно меньше. Но вот если kanban внедряет scrum-сектант, то получаются те же яйца,только в профиль.
Спасибо за продуктивный спор, интересно было послушать вашу точку зрения!
Вот эти шаблонные фразы : "проблема здесь не в скраме, а в способах его применения","мы гибкие" и "соблюдение церемоний повышает продуктивность" постоянно и слышу от скрам-сектантов. Да и вообще они всегда только шаблонными фразами из книг и манифестов общаются.
Возникает вопрос - а зачем этот скрам вообще нужен,если от него столько проблем и негатива? Может стоит или чётко прописать все правила или вообще его не применять? Сейчас вы пытаетесь защитить скрам,перекладывая ответственность за реализацию на кого угодно,только не на самих адептов скрама )))
Есть kanban и waterfall. Разработчикам с ними комфортно, зачем натягивать сову на глобус?