По ощущениям все-таки больше порно-кастинг напоминает. Идешь на свидание, а тебе вжух и четырехчасовую техническую секцию. Или две по три. И ты такой "блин, а я думал мы тут кофе попьем и поболтаем". А тебе уже устраивают трипл брейн пенетрейшон без прелюдии и лубриканта.
Ну и не могу не отметить два момента:
Из того что вы посчитали свою личную статистику никак не следует что конверсия любого отклика будет 10%. В среднем у человека хоть с каким-то релевантным опытом и открытым резюме она выше 100%. Потому что мгновенно наваливается почтой того что ты и не увидел в вакансиях.
Оба представленных варианта записи в резюме неверные. Второй слишком длинный. В описании обязанностей и достижений важен, во-первых, вклад - сам/в команде/во главе команды, во-вторых, полнота цикла - с нуля/на поддержке/вытащил из легаси. Остальное, если очень хочется, можно проговорить на вводной к техсекции: "да этот космический корабль я сам сделал, могу показать какие проводки я использовал".
Теперь начнется интересное. Вы по сути "всякого" ещё не видели. Семь лет жалкий трейлер на фоне пенсии в 65. Я как раз третий раз стек менял лет через 8.
Хотя в целом подход с мапками еще полезен чтобы объектики не плодить, один фиг курсоры это своеобразные мапы и параметризация самих sql-запросов без них не обходится. Так зачем нам лишний класс который все равно не уйдет выше дата-слоя.
Ну таки-да, это не ОРМ. ОРМ решает в первую голову задачу объектного мапинга (да даже банально называется Объектно-Реляционным Маппингом) и только по желанию инкапсуляцию SQL-диалектов в свой DSL. Это DSL over SQL. То есть специфический тулинг, как я понимаю, для задач автора. Например, навскидку, шаблонизированного стейт-менеджмента для выборки/солоедита из набора полей/формы замапленной на филдсет.
А вы стрелочку поверните. В какой из вышеперечисленных категорий сорокадвухлетний айтишник с ускоренных курсов учителей/хирургов/пилотирования будет не левым? :) Вам вообще сама идея этих ускоренных курсов не кажется бредовой? Читали бы вы внимательно - поняли бы что никто не охает и в спортлото не пишет. Сегодня оно так. Завтра по-другому. Кто-то бегает туда-сюда за длинным рублем, кто-то работает свою работу и ей доволен. Я вообще за все хорошее и мимо всего плохого. Так что бесполезно на меня повышать буквы.
Выводы на спорных тезисах всегда спорны. Тем не менее есть один тезис с которым я согласен: да действительно индустрия настолько популяризовалась что в ней появилась масса "левых" людей.
"Левых" читай как "профнепригодных" по той или иной причине, не обязательно по причине неумения отличить гитлаб флоу от гитхаб флоу, или отличать логарифмы от квадратов. А, скажем, занимающихся резюме-драйвен девелопмент. Почему так - ниже будет.
Тезис этот затронул не только соискателя, но и работодателя. То есть не только многие люди которые программируют не умеют программировать правильно, но и многие люди решающие кадровые вопросы не умеют их решать правильно.
Порог входа в команду ориентированный на отсев по формальному признаку ничем не лучше на выходе чем творчество чат гпт. То есть настоящую задачу он не решает. Тут звучал вопрос "зачем напрягаться". Ну вот затем. Настоящая задача команды разработки это разработка и поддержка продукта. На этапе поддержки продукта рано или поздно возникает точка Ж (стоимость поддержки > стоимости переделывания), которую желательно отодвинуть как можно дальше. Связанная с ней кадровая "настоящая задача" состоит в том чтобы поддерживать команду способную отодвигать точку Ж вперед по оси времени. Этот момент нельзя убрать. Можно только отсрочить.
Состав команды всегда не константа, а поток. Состояние продукта это не константа, а поток. Если представить себе что из текущего значения потока команды мы можем сделать некоторое преобразование и применить его к текущему состоянию продукта, то результатом будет следующее состояние продукта. И эти эмиты идут постоянно. Какие бы методики и методологии вы не использовали все это надо или поздно приводит к деградации.
Если простыми словами - команда которая ищет не человека который ей подходит для работы над проектом, а ищет того который умеет проходить много секций тех-скринингов обрящет человека который умеет проходить много секций тех-скринингов. Это не коррелирует напрямую с его полезностью продукту и остальной команде в данный момент. То есть может и повезти с полезностью. А может и нет. Как в анекдоте про блондинку и динозавра.
И это не последствия февраля 22-го. Это было раньше и повсеместно и будет дальше и повсеместно - недопонимание методик техногигантов, которые буквально забрасывали любой проект деньгами и "универсальными" инженерами, то есть людьми отбираемыми по принципу наличия у них общей академической подготовки в области компухтер саенс, не вдаваясь в подробности продуктов, ведь если что его всегда можно похоронить, часть людей уволить, а формальных топ-перформеров закинуть в другой (они ж универсальные).
Вот такая вот хурма. Но вы знаете что? Я работаю в индустрии с 2002-го года, когда мне мои же одногруппники из универа говорили что "это не нормальная работа" и "ты упрешься в потолок по бабкам". И ни на что ее не променяю, потому что мне нравится и процесс и результат моего труда. Даже если она вернется в "то" состояние. Чего, я уверен, не будет. Слишком мы привыкли к автоматизации всего и вся в жизни. И рано или поздно, я уверен, наступит спад популярности курсов и установится баланс. Очень хочется надеяться что за счет того что подрастет доход в других, подчас более социально значимых профессиях.
Ага. 1) "Большое" это какое? Сотня экранов - это сотня экранов, под ними может быть не так много домена в облачных решениях. Три оси измерения: объем кода, соотношение объема домен/ui и количество людей показывают сложность проекта (если честно - моя личная метрика). Растет домен/объем или объем/люди - сложность растет. При этом, понятное дело, что прибавлению людей нелинейно работает. То есть вы доводите объем/чел до расслабленного 10-15К строк на человека как в тиньке, но у вас общий объем так же как там два ляма - тут чисто инфраструктурной ереси будет с лям. Уже просто потому что у вас так много людей и надо много бойлерплейта чтобы они друг другу не мешались. Но и 300К на 2-3 человека при толстом домене это офигеть как сложно, я делал. Так что тут закономерный вопрос - насколько большое и почему именно оно такое. Экраны это эмоциональная метрика, имхо.
2) Логика ui-слоя утаптывается в bloc(mvi)|mvvm(cubit)|mvp|mvc(mvc морально устарел уже потому что связность у него выше прочих, mvp, впрочем, тоже, хотя жить и с ним можно). Вы точно уверены что mvc в его классическом понимании где все завязаны на всех без модификаций это нормально по солиду? И логика ui-слоя - она логика отображения стейта. Стейт формируется отдомена.
3) Если взять во внимание клин (я беру, он хороший). Стейт вьюшек композится из массы доменных стейтов как раз в "логике ui" то есть в контроллерах, презентерах, вьюмоделах, блоках. В этом архитектурном плане нет домена. Вообще. Фича-модули построенные на стейт-менеджмент паттернах - ок, но это, по сути, подходит под очень простое фронтенд-приложение и не более. Объем тут вторичен, бьется и параллелится оно легко на любом подходе, коммона там мизер, в основном сессия+ui-кит.
4) Собственно фича-модули. Часто (хотя не всегда, в виде исключения) есть доменные сущности типа той же сессии юзера, или сложносочиненных взаимозависимых репозиториев с синхронизацией замудренной в зависимости от авнономности аппа, и это делает дерево модулей сложным в обслуживании. Если оно не таково, то коммон-штуки дублируются не только прим большом количестве людей которые не знают что уже есть имплементации, но и даже в одно жало. Потому что проще копипаст, чем думать как слабосвязно прокинуть, я такое поддерживал, это боль. Вот это почему? Большое значит бьем, вы уверены что оно из большого не станет именно сложным?
Имхо разница между анемичной и толстой моделью в глазах смотрящего :)
Если мы вынесли логику в некие условные сервисы, юзкейсы и прочее (манипулирующие само собой только доменными же интерфейсами и ентитями ) - они частью домена быть не перестают. Ну или самой моделью в широком смысле этого слова. Так что анемичная модель это такой Гомер Симпсон с защипами на спине. Мне, кстати, с ней удобнее - выстроить иерархию сервисных классов манипулирующих дата-ентити, зацепив их на интерфейсы друг друга. Тогда у нас не нарушается буковка S из нашего любимого SOLID и у нас не возникает необходимости лезть в один класс дважды - за изменением формата данных и протоколом их обработки в бизнес-процессе.
Именно поэтому споры и ненависть про алгоритмы. Именно поэтому сеньор ~3 года это очень смешно. Именно поэтому побеседовать сеньора не умеет 99% собеседующих. На реальной задаче сеньора на ту же оптимизацию ложится не столько параметр ее мат. эффективности, сколько параметры сроков, кадров и пресловутое бизнес-велью.
И да. 99% соискателей сеньорской должности не умеют в построение апи. Этому литкод, хакерранк и олимпиады не учат.
Дык а чего концептуально нового вы ждете от текстового редактора с большим количеством свистоперделок? С течением времени их все больше, они все тяжелее и интегрируют в себя все больше разного барахла. Если писать на c++, то наверное прям всю пользу какой-нить тяжелой idea и не увидишь, даже если это поставляется под названием clion. Слышал много всякого про то что с джава/котлин инструментарием в ней же это несравнимо. Но под jvm или kmp c градлом как бы лучше ничего и нет.
Все дело ж еще может быть именно в том что c++ такой. К примеру недавно пришлось на нем написать немного, писался кусок в vscode из-за того что идея у меня community и я не мог все делать в одной среде и таки это действительно не слишком прям сильно отличающийся от старого опыт писания с чистого листа. С рефакторингом, думаю, он бы был уже значительно лучше. И вряд ли что-то кардинально сдвинется хоть когда-то. Но я бы проснулся в холодном поту если бы мне пришлось пользоваться чем-то типа старых терминальных редакторов на моих jvm-проектах нынешнего масштаба (то есть по дефолту я такое только в страшном сне себе могу представить).
А так да, спасибо, поностальгировал на синие экранчики. Писали в институте и игры и вирусы на турбопаскале и сложные, неполигональные рендер-движки на турбо цпп.
Работал в одной из компаний принадлежавших ВК. На нас так же распространялась эта история. Годовая премия правда нет.
Ничего сверхсложного в истории нет. Ничего сверхурочного тоже не предполагается. Ты работаешь в своем темпе и
1. Видишь что тебе нужно сделать по продукту (обычно это техдолг и его нужно грамотно декомпозировать на n* целей).
2. Оцениваешь задачи бизнеса базируясь на том что тебе нужно закрыть и твои (они гибче чем кажется, цеплять одно за другое так же никто не мешает).
3. Балансируешь 1 и 2.
Там ещё масса хаков на эту тему. Но первично - думать головой и иметь перспективу в своей работе над продуктом. Это как бы и есть цель практики.
И да. Мне эти приседания не нравятся от слова совсем, я привык к небольшим конторам и некоторой свободе планирования. Но для большой это вполне адекватный способ массово потыкать веточкой сотрудников которые только делают вид что соображают.
Ровно наоборот. Мы (все те кто проживает на участке суши от восточной европы до дальнего востока по долготе и от полярного круга до средней азии по широте) берем не математикой, а прикладной сферой. А еще тем что можем пояснить как эта математика живет с другим инженерным багажом. Не все правда. И чем дальше тем больше не все, потому что селекция в индустрии направлена на рекрутинг "индусов" именно по вашим заблуждениям. Которые выдают полное непонимание и самой индустрии и людей которые там работают.
Вы видели хоть когда-нибудь код этих "индусов"? Типовой индус настроен на гугл-лайк собес, и не тренирует ничего кроме этого навыка. Алгоритмы, структуры данных, паттерны проектирования, языковые конструкции. Всё на пятерку. На практике же - хранение пересоздаваемого контекста в синглтоне и "я не понимаю что не так".
Я с большим умилением слушаю как собеседуемый привязывает принципы солид к своему опыту, приводя конкретные примеры из реализованных проектов, даже если мне приходится подсказывать что там за очередной буквой. Это показывает что он их осмыслил, а не зазубрил. И мне вообще неинтересно как он переложит жейсон, или байтики в задачке которая формализована до уровня применения алгоритмов. По факту у меня нет таких задач. И у него не будет. Собственно это я и вижу в статье - ищите человека по тем критериям которые нужны для его вакансии. Спрашивайте его о том что ему придется делать. Это единственно правильный подход. Я и сам именно так веду собеседования и когда их прохожу то стараюсь не слить и переживаю именно за те которые прошли не по методичкам для олимпиадников. Потому что с людьми которые подходят к собесам столь формально я банально не сработаюсь.
Реальность же индустрии такова, что написав куб вы не навредите проекту так как навредите ему не продумав апи своего очередного модуля. Или выстроите взаимодействие слоев так что заложите бомбу под дальнейшее сопровождение. Если уж вас так волнует будет ли человек писать кубы и квадраты - пусть он вам расскажет что это такое. А потом спросите ейчара понятно ли ему. Заодно проверите навык донесения технической мысли до будущего ПО у которого понимания той самой технической мысли примерно столько же сколько у HR, а планировать надо опираясь на разного уровня невнятности бормотание разработчика.
Касаемо вк и прочих спешал олимпикс - погуглите "чат активити" телеги. Этот мем в дроид-разработке давно стал классикой.
От евентбаса в мобильной разработке отказались уже лет эдак 8 назад. Именно как от концепта общей шины. И именно на больших и сложных проектах. Все дело в том, что при достаточно большом количестве гоняемых данных может возникнуть необходимость по-разному обходиться с backpressure, иметь разнообразные (горячие и холодные) стримы (а шина всегда горячая), а так же (что неактуально для дарта) исполнять обработчики цепочек на разных тредпулах. Плюс отлаживать на общей трубе крайне мерзко, потому что правило единого эмиттера конвенциональное, а не контролируется компилятором. Честно-честно, я приходил на проекты с евентбасом и это боль.
Отказались в пользу реактивных стримов на источниках конкретных типизированных данных. Обычно это библиотека "rx[Вставьте свой любимый язык]". RxDart в том числе. То что вы написали называется в rx-терминах PublishSubject (если передвинуть дженерик наверх в сам класс), правда урезанный, обычно у него есть буфер и стратегии поведения при переполнении буфера (backpressure strategy) есть еще один - с фиксированным и обязательно заполненным (seeded) буфером размером в 1, он называется BehaviorSubject и чертовски подходит как раз для UI-стейта в bloc и других разных MV*. Или для выноса в репозиторий.
Таким образом нашим сопричастным к счетчику кубитам остается только дернуть метод репо для инкремента счетчика и подписаться на типизированный стрим счетчика, отдаваемый репозиторием. Иногда потребителю нужны многие стримы и композить их в единый ивент можно при помощи разных combine/merge.
От самого Rx в нативном дроиде тоже отказались в пользу котлиновских Flow, но это уже другая история, тем более что у нас тут дарт. Можно пользоваться или не пользоваться rx, сами стримы в дарте достаточно мощные, но вот использовать именно EventBus я бы крайне не рекомендовал.
Интересный тренд. Большие ребята кинулись строчить о найме с человеческим лицом. Хотя все знают что у больших ребят процессы найма далеки от человеческого лица. Что у вас случилось-то? :) Хотя это все тоже знают. Осталось врубиться что делать вид осознанного выбора это не совсем то же что делать выбор осознанно.
По ощущениям все-таки больше порно-кастинг напоминает. Идешь на свидание, а тебе вжух и четырехчасовую техническую секцию. Или две по три. И ты такой "блин, а я думал мы тут кофе попьем и поболтаем". А тебе уже устраивают трипл брейн пенетрейшон без прелюдии и лубриканта.
Ну и не могу не отметить два момента:
Из того что вы посчитали свою личную статистику никак не следует что конверсия любого отклика будет 10%. В среднем у человека хоть с каким-то релевантным опытом и открытым резюме она выше 100%. Потому что мгновенно наваливается почтой того что ты и не увидел в вакансиях.
Оба представленных варианта записи в резюме неверные. Второй слишком длинный. В описании обязанностей и достижений важен, во-первых, вклад - сам/в команде/во главе команды, во-вторых, полнота цикла - с нуля/на поддержке/вытащил из легаси. Остальное, если очень хочется, можно проговорить на вводной к техсекции: "да этот космический корабль я сам сделал, могу показать какие проводки я использовал".
ПК гейминг с 80-х умирает.
Заскриньте пост чтобы еще через пять лет над собой поржать. И еще через пять. Открывайте раз в пять лет чтобы посмеяться, короче.
Теперь начнется интересное. Вы по сути "всякого" ещё не видели. Семь лет жалкий трейлер на фоне пенсии в 65. Я как раз третий раз стек менял лет через 8.
Хотя в целом подход с мапками еще полезен чтобы объектики не плодить, один фиг курсоры это своеобразные мапы и параметризация самих sql-запросов без них не обходится. Так зачем нам лишний класс который все равно не уйдет выше дата-слоя.
Ну таки-да, это не ОРМ. ОРМ решает в первую голову задачу объектного мапинга (да даже банально называется Объектно-Реляционным Маппингом) и только по желанию инкапсуляцию SQL-диалектов в свой DSL. Это DSL over SQL. То есть специфический тулинг, как я понимаю, для задач автора. Например, навскидку, шаблонизированного стейт-менеджмента для выборки/солоедита из набора полей/формы замапленной на филдсет.
А в чем проблема с lib gdx у котлина? Плюс для 2d есть korge.
Жарковато. Носите шляпу и пейте больше воды. А то все эти ведущие индустрии и нарративы они преходящи, а здоровье одно.
Нуууу, "в на... общество" хорошо попал, душевно, прям цепляет с эмоциональной стороны, но с другой стороны, а как там у вас погодка, а? :)
А вы стрелочку поверните. В какой из вышеперечисленных категорий сорокадвухлетний айтишник с ускоренных курсов учителей/хирургов/пилотирования будет не левым? :) Вам вообще сама идея этих ускоренных курсов не кажется бредовой? Читали бы вы внимательно - поняли бы что никто не охает и в спортлото не пишет. Сегодня оно так. Завтра по-другому. Кто-то бегает туда-сюда за длинным рублем, кто-то работает свою работу и ей доволен. Я вообще за все хорошее и мимо всего плохого. Так что бесполезно на меня повышать буквы.
Выводы на спорных тезисах всегда спорны. Тем не менее есть один тезис с которым я согласен: да действительно индустрия настолько популяризовалась что в ней появилась масса "левых" людей.
"Левых" читай как "профнепригодных" по той или иной причине, не обязательно по причине неумения отличить гитлаб флоу от гитхаб флоу, или отличать логарифмы от квадратов. А, скажем, занимающихся резюме-драйвен девелопмент. Почему так - ниже будет.
Тезис этот затронул не только соискателя, но и работодателя. То есть не только многие люди которые программируют не умеют программировать правильно, но и многие люди решающие кадровые вопросы не умеют их решать правильно.
Порог входа в команду ориентированный на отсев по формальному признаку ничем не лучше на выходе чем творчество чат гпт. То есть настоящую задачу он не решает. Тут звучал вопрос "зачем напрягаться". Ну вот затем. Настоящая задача команды разработки это разработка и поддержка продукта. На этапе поддержки продукта рано или поздно возникает точка Ж (стоимость поддержки > стоимости переделывания), которую желательно отодвинуть как можно дальше. Связанная с ней кадровая "настоящая задача" состоит в том чтобы поддерживать команду способную отодвигать точку Ж вперед по оси времени. Этот момент нельзя убрать. Можно только отсрочить.
Состав команды всегда не константа, а поток. Состояние продукта это не константа, а поток. Если представить себе что из текущего значения потока команды мы можем сделать некоторое преобразование и применить его к текущему состоянию продукта, то результатом будет следующее состояние продукта. И эти эмиты идут постоянно. Какие бы методики и методологии вы не использовали все это надо или поздно приводит к деградации.
Если простыми словами - команда которая ищет не человека который ей подходит для работы над проектом, а ищет того который умеет проходить много секций тех-скринингов обрящет человека который умеет проходить много секций тех-скринингов. Это не коррелирует напрямую с его полезностью продукту и остальной команде в данный момент. То есть может и повезти с полезностью. А может и нет. Как в анекдоте про блондинку и динозавра.
И это не последствия февраля 22-го. Это было раньше и повсеместно и будет дальше и повсеместно - недопонимание методик техногигантов, которые буквально забрасывали любой проект деньгами и "универсальными" инженерами, то есть людьми отбираемыми по принципу наличия у них общей академической подготовки в области компухтер саенс, не вдаваясь в подробности продуктов, ведь если что его всегда можно похоронить, часть людей уволить, а формальных топ-перформеров закинуть в другой (они ж универсальные).
Вот такая вот хурма. Но вы знаете что? Я работаю в индустрии с 2002-го года, когда мне мои же одногруппники из универа говорили что "это не нормальная работа" и "ты упрешься в потолок по бабкам". И ни на что ее не променяю, потому что мне нравится и процесс и результат моего труда. Даже если она вернется в "то" состояние. Чего, я уверен, не будет. Слишком мы привыкли к автоматизации всего и вся в жизни. И рано или поздно, я уверен, наступит спад популярности курсов и установится баланс. Очень хочется надеяться что за счет того что подрастет доход в других, подчас более социально значимых профессиях.
Ага.
1) "Большое" это какое? Сотня экранов - это сотня экранов, под ними может быть не так много домена в облачных решениях. Три оси измерения: объем кода, соотношение объема домен/ui и количество людей показывают сложность проекта (если честно - моя личная метрика). Растет домен/объем или объем/люди - сложность растет. При этом, понятное дело, что прибавлению людей нелинейно работает. То есть вы доводите объем/чел до расслабленного 10-15К строк на человека как в тиньке, но у вас общий объем так же как там два ляма - тут чисто инфраструктурной ереси будет с лям. Уже просто потому что у вас так много людей и надо много бойлерплейта чтобы они друг другу не мешались. Но и 300К на 2-3 человека при толстом домене это офигеть как сложно, я делал. Так что тут закономерный вопрос - насколько большое и почему именно оно такое. Экраны это эмоциональная метрика, имхо.
2) Логика ui-слоя утаптывается в bloc(mvi)|mvvm(cubit)|mvp|mvc(mvc морально устарел уже потому что связность у него выше прочих, mvp, впрочем, тоже, хотя жить и с ним можно). Вы точно уверены что mvc в его классическом понимании где все завязаны на всех без модификаций это нормально по солиду? И логика ui-слоя - она логика отображения стейта. Стейт формируется от домена.
3) Если взять во внимание клин (я беру, он хороший). Стейт вьюшек композится из массы доменных стейтов как раз в "логике ui" то есть в контроллерах, презентерах, вьюмоделах, блоках. В этом архитектурном плане нет домена. Вообще. Фича-модули построенные на стейт-менеджмент паттернах - ок, но это, по сути, подходит под очень простое фронтенд-приложение и не более. Объем тут вторичен, бьется и параллелится оно легко на любом подходе, коммона там мизер, в основном сессия+ui-кит.
4) Собственно фича-модули. Часто (хотя не всегда, в виде исключения) есть доменные сущности типа той же сессии юзера, или сложносочиненных взаимозависимых репозиториев с синхронизацией замудренной в зависимости от авнономности аппа, и это делает дерево модулей сложным в обслуживании. Если оно не таково, то коммон-штуки дублируются не только прим большом количестве людей которые не знают что уже есть имплементации, но и даже в одно жало. Потому что проще копипаст, чем думать как слабосвязно прокинуть, я такое поддерживал, это боль. Вот это почему? Большое значит бьем, вы уверены что оно из большого не станет именно сложным?
Имхо разница между анемичной и толстой моделью в глазах смотрящего :)
Если мы вынесли логику в некие условные сервисы, юзкейсы и прочее (манипулирующие само собой только доменными же интерфейсами и ентитями ) - они частью домена быть не перестают. Ну или самой моделью в широком смысле этого слова. Так что анемичная модель это такой Гомер Симпсон с защипами на спине. Мне, кстати, с ней удобнее - выстроить иерархию сервисных классов манипулирующих дата-ентити, зацепив их на интерфейсы друг друга. Тогда у нас не нарушается буковка S из нашего любимого SOLID и у нас не возникает необходимости лезть в один класс дважды - за изменением формата данных и протоколом их обработки в бизнес-процессе.
Проблема. Сеньор это уже не алгоритмы. Это уже
1. Спектр технологий.
2. Построение и сопровождение продукта с нуля.
3. Работа с людьми.
Именно поэтому споры и ненависть про алгоритмы. Именно поэтому сеньор ~3 года это очень смешно. Именно поэтому побеседовать сеньора не умеет 99% собеседующих. На реальной задаче сеньора на ту же оптимизацию ложится не столько параметр ее мат. эффективности, сколько параметры сроков, кадров и пресловутое бизнес-велью.
И да. 99% соискателей сеньорской должности не умеют в построение апи. Этому литкод, хакерранк и олимпиады не учат.
Дык а чего концептуально нового вы ждете от текстового редактора с большим количеством свистоперделок? С течением времени их все больше, они все тяжелее и интегрируют в себя все больше разного барахла. Если писать на c++, то наверное прям всю пользу какой-нить тяжелой idea и не увидишь, даже если это поставляется под названием clion. Слышал много всякого про то что с джава/котлин инструментарием в ней же это несравнимо. Но под jvm или kmp c градлом как бы лучше ничего и нет.
Все дело ж еще может быть именно в том что c++ такой. К примеру недавно пришлось на нем написать немного, писался кусок в vscode из-за того что идея у меня community и я не мог все делать в одной среде и таки это действительно не слишком прям сильно отличающийся от старого опыт писания с чистого листа. С рефакторингом, думаю, он бы был уже значительно лучше. И вряд ли что-то кардинально сдвинется хоть когда-то. Но я бы проснулся в холодном поту если бы мне пришлось пользоваться чем-то типа старых терминальных редакторов на моих jvm-проектах нынешнего масштаба (то есть по дефолту я такое только в страшном сне себе могу представить).
А так да, спасибо, поностальгировал на синие экранчики. Писали в институте и игры и вирусы на турбопаскале и сложные, неполигональные рендер-движки на турбо цпп.
Работал в одной из компаний принадлежавших ВК. На нас так же распространялась эта история. Годовая премия правда нет.
Ничего сверхсложного в истории нет. Ничего сверхурочного тоже не предполагается. Ты работаешь в своем темпе и
1. Видишь что тебе нужно сделать по продукту (обычно это техдолг и его нужно грамотно декомпозировать на n* целей).
2. Оцениваешь задачи бизнеса базируясь на том что тебе нужно закрыть и твои (они гибче чем кажется, цеплять одно за другое так же никто не мешает).
3. Балансируешь 1 и 2.
Там ещё масса хаков на эту тему. Но первично - думать головой и иметь перспективу в своей работе над продуктом. Это как бы и есть цель практики.
И да. Мне эти приседания не нравятся от слова совсем, я привык к небольшим конторам и некоторой свободе планирования. Но для большой это вполне адекватный способ массово потыкать веточкой сотрудников которые только делают вид что соображают.
Хосподи какой порожняк
Ровно наоборот. Мы (все те кто проживает на участке суши от восточной европы до дальнего востока по долготе и от полярного круга до средней азии по широте) берем не математикой, а прикладной сферой. А еще тем что можем пояснить как эта математика живет с другим инженерным багажом. Не все правда. И чем дальше тем больше не все, потому что селекция в индустрии направлена на рекрутинг "индусов" именно по вашим заблуждениям. Которые выдают полное непонимание и самой индустрии и людей которые там работают.
Вы видели хоть когда-нибудь код этих "индусов"? Типовой индус настроен на гугл-лайк собес, и не тренирует ничего кроме этого навыка. Алгоритмы, структуры данных, паттерны проектирования, языковые конструкции. Всё на пятерку. На практике же - хранение пересоздаваемого контекста в синглтоне и "я не понимаю что не так".
Я с большим умилением слушаю как собеседуемый привязывает принципы солид к своему опыту, приводя конкретные примеры из реализованных проектов, даже если мне приходится подсказывать что там за очередной буквой. Это показывает что он их осмыслил, а не зазубрил. И мне вообще неинтересно как он переложит жейсон, или байтики в задачке которая формализована до уровня применения алгоритмов. По факту у меня нет таких задач. И у него не будет. Собственно это я и вижу в статье - ищите человека по тем критериям которые нужны для его вакансии. Спрашивайте его о том что ему придется делать. Это единственно правильный подход. Я и сам именно так веду собеседования и когда их прохожу то стараюсь не слить и переживаю именно за те которые прошли не по методичкам для олимпиадников. Потому что с людьми которые подходят к собесам столь формально я банально не сработаюсь.
Реальность же индустрии такова, что написав куб вы не навредите проекту так как навредите ему не продумав апи своего очередного модуля. Или выстроите взаимодействие слоев так что заложите бомбу под дальнейшее сопровождение. Если уж вас так волнует будет ли человек писать кубы и квадраты - пусть он вам расскажет что это такое. А потом спросите ейчара понятно ли ему. Заодно проверите навык донесения технической мысли до будущего ПО у которого понимания той самой технической мысли примерно столько же сколько у HR, а планировать надо опираясь на разного уровня невнятности бормотание разработчика.
Касаемо вк и прочих спешал олимпикс - погуглите "чат активити" телеги. Этот мем в дроид-разработке давно стал классикой.
От евентбаса в мобильной разработке отказались уже лет эдак 8 назад. Именно как от концепта общей шины. И именно на больших и сложных проектах. Все дело в том, что при достаточно большом количестве гоняемых данных может возникнуть необходимость по-разному обходиться с backpressure, иметь разнообразные (горячие и холодные) стримы (а шина всегда горячая), а так же (что неактуально для дарта) исполнять обработчики цепочек на разных тредпулах. Плюс отлаживать на общей трубе крайне мерзко, потому что правило единого эмиттера конвенциональное, а не контролируется компилятором. Честно-честно, я приходил на проекты с евентбасом и это боль.
Отказались в пользу реактивных стримов на источниках конкретных типизированных данных. Обычно это библиотека "rx[Вставьте свой любимый язык]". RxDart в том числе. То что вы написали называется в rx-терминах PublishSubject (если передвинуть дженерик наверх в сам класс), правда урезанный, обычно у него есть буфер и стратегии поведения при переполнении буфера (backpressure strategy) есть еще один - с фиксированным и обязательно заполненным (seeded) буфером размером в 1, он называется BehaviorSubject и чертовски подходит как раз для UI-стейта в bloc и других разных MV*. Или для выноса в репозиторий.
Таким образом нашим сопричастным к счетчику кубитам остается только дернуть метод репо для инкремента счетчика и подписаться на типизированный стрим счетчика, отдаваемый репозиторием. Иногда потребителю нужны многие стримы и композить их в единый ивент можно при помощи разных combine/merge.
От самого Rx в нативном дроиде тоже отказались в пользу котлиновских Flow, но это уже другая история, тем более что у нас тут дарт. Можно пользоваться или не пользоваться rx, сами стримы в дарте достаточно мощные, но вот использовать именно EventBus я бы крайне не рекомендовал.
Интересный тренд. Большие ребята кинулись строчить о найме с человеческим лицом. Хотя все знают что у больших ребят процессы найма далеки от человеческого лица. Что у вас случилось-то? :) Хотя это все тоже знают. Осталось врубиться что делать вид осознанного выбора это не совсем то же что делать выбор осознанно.