профессии IT-архитектора создавать приложения на low-code BPM-платформе
Альфа, вы сами-то потом готовы такого спеца на позицию архитектора взять? Или как обычно "от меня пули ушли, проблема на принимающей стороне"? Скажите им хотя бы, что они понарошку архитекторы.
Почему компании не могут пройти собеседование с айтишником
Да нет у них никаких проблем, все они "могут". Перефразируя Карлина, "HR is fine, the devs are f***d". О чем говорит тот факт, что самые дебильные практики в HR спокойно живут уже десятилетиями? О том, что всем и так норм. Большинство из нас побухтит на хабре, а на деле все равно покорно пройдет первичный собес, где эйчар будет сбивчиво по бумажке читать вопросы а ля "что такое полиморфизм". А потом мы пойдем писать алгоритм Дейкстры на вакансию, где нужно перекладывать джейсоны. Реально переломить ситуацию можно массовым бойкотом контор, где вращают деревья на доске и вот это все. Вот, чем стоило бы заниматься небезызвестному Профсоюзу вместо написания истеричных пассажей.
Извините, но похоже на замануху того же сорта, что и "до мидла за 3 месяца", только уже для действующих работников ИТ. Это все девальвирует ценность конференций. Раньше конференции были редкими и несли эссенцию экспертного знания. Теперь же каждая контора, у которой завалялся в бюджете лишний миллион мечтает устроить (или устраивает) свою именную конференцию и тащит на нее все, что похоже на доклад. У меня пару лет назад был такой духоподъемный период и я ходил на все митапы, куда меня приглашал спам в почте. Очень быстро понял, что в дцатом году уже как-то странно слушать "как использовать стримы в джаве" и "зачем нужна кафка". А ничего реально вдохновляющего там не было.
К тому же, есть такое наблюдение что люди, которые засиживаются в одном месте, экспертнее
Другой вопрос, сильно ли нужна такая экспертность. Вспоминаем тибетскую притчу про полную чашку чая, в которую уже невозможно налить ни капли. Я не скажу за управленцев и бизнесменов, но рядовой исполнитель, который дцать лет сидит и решает одни и те же проблемы одним и тем же инструментом это очень спорный актив, если мы собираемся его нанять. Вне своей зоны комфорта он скорее создает проблемы, а не решает.
Всем желающим испытать механизм стоит напомнить, что у тащ плковника в военкомате есть Его Величество План. Не закон, не инструкции Минцифры, не бумажки из вашей конторы, а План. За срыв Плана его могут наказать. За все остальное - даже не мечтайте. Пугать тащ плковника на его территории бумажкой о том, что ты тимлид в трех командах и держишь облачный прод с 1кк tps, - ну вы понимаете.
Раз вы спросили, то могу рассказать про то, что отвращает от чтения и дальнейшего общения.
Окутанные тайной темы типа "вакансия в банке из ТОП-50". К чему экивоки-то? Мы начнем говорить и вы тут же расскажете, что это за банк. В чем проблема написать сразу?
Булшит типа "я показала ваше CV нашему CTO, он писал кипятком 10 минут, и приказал немедленно писать вам". Дешевая такая замануха. Соглашаешься - а потом все равно месяц ждешь, пока интервьюера найдут и пока этот самый CTO из отпуска выйдет.
Однажды вообще было, что рекрутер закосил под тимлида, который якобы увидел меня как профессионал профессионала.
Когда рекрутер додумывает специализацию за кандидата. Платиновый пример, когда додумывают, что котлинист == андроид-разработчик. Или когда ты писал что-то на фронте 5 лет назад - тебя зовут на фронтенд-лида.
Когда прямо в тексте письма просят озвучить зарплатные ожидания и прислать реюзме. А как вы нашли-то меня, если не видели мое резюме и мои зарплатные ожидания в нем? Во сне я вам приснился?
Отдельный жанр, когда "у меня есть для вас вакансия, но вы сначала напишите, что согласны на обработку ваших ПД". Серьезно? Соглашается кто-то?
Когда собственно описание вакансии присылают в каком-нибудь DOCX, TXT, CSV, BASE64 и т.д. Прямой текст, оформленный PDF или страничка на вашем сайте - в чем проблема именно такие форматы выбрать?
Потому что именно эти ребята должны будут не просто написать в PR замечание, а подкрепить его документацией, ссылкой на хабр и, в совсем тяжелых случаях, созвоном.
Справедливости ради, описанный риск может приключиться с сотрудником любой квалификации. В моей практике были случаи, когда люди с опытом 10+ лет без всяких дискуссий саботировали принятый стиль кодирования и идиоматику просто потому, что "я в лохматом году писал не так". Или вступали в какие-то бескрайние душные дискуссии прямо в гитлабе. Это уже про адекватность и командное поведение, а не про вайтишничество.
Воображаемый диспут с каким-то мифическим айтишником из 90х. Ну с тем, который лохматый, бородатый, в прокуренном сером свитере, сидит в темной каморке, ест исключительно бич-пакеты и пишет что-то на плюсах через vim. Поздравляю, воображаемый противник повержен. Теперь самое время вернуться в реальность.
Я выработал для себя правило (но не изобрел его, само собой), что сообщение об ошибке должно строиться по шаблону "что случилось - почему так случилось - что с этим делать". Что-то вроде "Невозможно выполнить загрузку. Удаленный сервер недоступен. Попробуйте выполнить загрузку позднее или обратитесь в администратору. Детали ошибки: ххх". Просто ужасно, когда люди не парятся и просто швыряют в клиента exception.getMessage() не глядя.
У меня как-то была история с банком Т******. Ко мне по ошибке попало 4000 рублей. Так я тоже 2 недели переписывался с саппортом, чтобы их вернуть. Было где-то 10 редиректов с одного специалиста на другого. Пару раз пришлось доказывать, что я это я. В итоге возврат произошел не прямым списанием со счета, а путем каких-то фокусов с пополнением счета через банкомат. Похоже, что это вообще какой-то кейс с нулевой вероятностью для таких организаций.
С var накладные расходы на извлечение части кода в именованную переменную уменьшаются, поэтому разработчики с большей вероятностью будут это делать, что приведет к более чистому коду.
Как-то спорно. По-моему реальная проблема это придумать название для промежуточной переменной посреди длинного метода, а не объявлять ее тип. От var тут ни холодно, ни жарко. Красивое решение этой проблемы - это контекстные функции в Kotlin. Там если повезет, то можно весь метод выразить как цепочку из функций высшего порядка без промежуточных переменных.
главное чтобы вы ... красиво рассказывали паттерны проектирования.
В чем проблема рассказать про паттерны, которые вы реально используете? Допустим, у вас микросервисы и вы используете паттрен API Gateway. Вы испытываете затруднения объяснить, зачем он нужен? Или вы пишете на Node.js и используете паттерн Reactor (aka Event Loop). Снова пояснить не можете? Или вы пишете на Spring и у вас по всему коду расставлены аннотации Transactional. Что, опять какая-то проблема пояснить, как работают прокси? Может не в плохих собесах дело?
Ну а если из вас настойчиво трясут то, что вы в глаза не видели, то голосуйте ногами из такого места.
но я могу использовать это, и я могу использовать это во благо
Что-то вы путаетесь в показаниях. Если вы реально пишете сложные расширяемые и отказоустойчивые приложения, то какой для вас труд пояснить мотивацию своих действий? А кристаллизованная правильная мотивация - это как раз и есть всякие солиды, паттерны, лучшие практики и т.д.
Городить отдельный тип со своей ошибкой для такого простого поля, как email, кажется оверхедом, ведь это всего лишь строка.
Какая-то тут недосказанность в истории с PersonItem и PersonFullItem. У вас же наверняка есть кейсы, когда у объекта Х полей и лишь несколько из них появляются всегда. Получается, что все же придется идти на оверхед и заменять примитивные типы алгебраическими.
Объект это не концепция реального мира. ... Надо прекратить думать в данном ключе!
А кто или что вообще заставляло вас думать в этом ключе? Это в манифесте какого-то языка заложено? Или у какого-то автора типа Шилдта постулировано?
По мне так это такой детский миф, живущий в джуновской среде. Только на джуновских собеседованиях я слышу про все эти "объекты реального мира", "наследование для переиспользования кода" и "Cat extends Animal". На практике принципиально другие вопросы задаются: "это работает?", "это тестируемо?", "это расширяемо?", "лучшим практикам не противоречит?" "это не антипаттерн?", "через месяц пойму, что написал?". Никто уже всерьез не упарывается экзистенциальным поиском святого Грааля ООП. Тем более, что почти все популярные языки давно уже мультипарадигменные.
Альфа, вы сами-то потом готовы такого спеца на позицию архитектора взять? Или как обычно "от меня пули ушли, проблема на принимающей стороне"? Скажите им хотя бы, что они понарошку архитекторы.
Да нет у них никаких проблем, все они "могут". Перефразируя Карлина, "HR is fine, the devs are f***d". О чем говорит тот факт, что самые дебильные практики в HR спокойно живут уже десятилетиями? О том, что всем и так норм. Большинство из нас побухтит на хабре, а на деле все равно покорно пройдет первичный собес, где эйчар будет сбивчиво по бумажке читать вопросы а ля "что такое полиморфизм". А потом мы пойдем писать алгоритм Дейкстры на вакансию, где нужно перекладывать джейсоны. Реально переломить ситуацию можно массовым бойкотом контор, где вращают деревья на доске и вот это все. Вот, чем стоило бы заниматься небезызвестному Профсоюзу вместо написания истеричных пассажей.
Извините, но похоже на замануху того же сорта, что и "до мидла за 3 месяца", только уже для действующих работников ИТ. Это все девальвирует ценность конференций. Раньше конференции были редкими и несли эссенцию экспертного знания. Теперь же каждая контора, у которой завалялся в бюджете лишний миллион мечтает устроить (или устраивает) свою именную конференцию и тащит на нее все, что похоже на доклад. У меня пару лет назад был такой духоподъемный период и я ходил на все митапы, куда меня приглашал спам в почте. Очень быстро понял, что в дцатом году уже как-то странно слушать "как использовать стримы в джаве" и "зачем нужна кафка". А ничего реально вдохновляющего там не было.
Другой вопрос, сильно ли нужна такая экспертность. Вспоминаем тибетскую притчу про полную чашку чая, в которую уже невозможно налить ни капли. Я не скажу за управленцев и бизнесменов, но рядовой исполнитель, который дцать лет сидит и решает одни и те же проблемы одним и тем же инструментом это очень спорный актив, если мы собираемся его нанять. Вне своей зоны комфорта он скорее создает проблемы, а не решает.
Ну а кто в общем-то заварил эту кашу, если не работодатели?
Всем желающим испытать механизм стоит напомнить, что у тащ плковника в военкомате есть Его Величество План. Не закон, не инструкции Минцифры, не бумажки из вашей конторы, а План. За срыв Плана его могут наказать. За все остальное - даже не мечтайте. Пугать тащ плковника на его территории бумажкой о том, что ты тимлид в трех командах и держишь облачный прод с 1кк tps, - ну вы понимаете.
А здесь пишут, что по выручке. Там же пишут об исключении крупных банков - что вообще логично, если мерить по выручке.
Это те самые компании, которые не банки, не ритейл, не маркетплейсы, а специальные ФГУП ЦНИИ Погромирования?
Раз вы спросили, то могу рассказать про то, что отвращает от чтения и дальнейшего общения.
Окутанные тайной темы типа "вакансия в банке из ТОП-50". К чему экивоки-то? Мы начнем говорить и вы тут же расскажете, что это за банк. В чем проблема написать сразу?
Булшит типа "я показала ваше CV нашему CTO, он писал кипятком 10 минут, и приказал немедленно писать вам". Дешевая такая замануха. Соглашаешься - а потом все равно месяц ждешь, пока интервьюера найдут и пока этот самый CTO из отпуска выйдет.
Однажды вообще было, что рекрутер закосил под тимлида, который якобы увидел меня как профессионал профессионала.
Когда рекрутер додумывает специализацию за кандидата. Платиновый пример, когда додумывают, что котлинист == андроид-разработчик. Или когда ты писал что-то на фронте 5 лет назад - тебя зовут на фронтенд-лида.
Когда прямо в тексте письма просят озвучить зарплатные ожидания и прислать реюзме. А как вы нашли-то меня, если не видели мое резюме и мои зарплатные ожидания в нем? Во сне я вам приснился?
Отдельный жанр, когда "у меня есть для вас вакансия, но вы сначала напишите, что согласны на обработку ваших ПД". Серьезно? Соглашается кто-то?
Когда собственно описание вакансии присылают в каком-нибудь DOCX, TXT, CSV, BASE64 и т.д. Прямой текст, оформленный PDF или страничка на вашем сайте - в чем проблема именно такие форматы выбрать?
Вам стоит почитать о разнице между асинхронностью и реактивностью.
Вы императивно запрашиваете имя, императивно обновляете переменную в шаблоне. AJAX вижу, реактивность - нет.
Справедливости ради, описанный риск может приключиться с сотрудником любой квалификации. В моей практике были случаи, когда люди с опытом 10+ лет без всяких дискуссий саботировали принятый стиль кодирования и идиоматику просто потому, что "я в лохматом году писал не так". Или вступали в какие-то бескрайние душные дискуссии прямо в гитлабе. Это уже про адекватность и командное поведение, а не про вайтишничество.
Воображаемый диспут с каким-то мифическим айтишником из 90х. Ну с тем, который лохматый, бородатый, в прокуренном сером свитере, сидит в темной каморке, ест исключительно бич-пакеты и пишет что-то на плюсах через vim. Поздравляю, воображаемый противник повержен. Теперь самое время вернуться в реальность.
Я выработал для себя правило (но не изобрел его, само собой), что сообщение об ошибке должно строиться по шаблону "что случилось - почему так случилось - что с этим делать". Что-то вроде "Невозможно выполнить загрузку. Удаленный сервер недоступен. Попробуйте выполнить загрузку позднее или обратитесь в администратору. Детали ошибки: ххх". Просто ужасно, когда люди не парятся и просто швыряют в клиента exception.getMessage() не глядя.
У меня как-то была история с банком Т******. Ко мне по ошибке попало 4000 рублей. Так я тоже 2 недели переписывался с саппортом, чтобы их вернуть. Было где-то 10 редиректов с одного специалиста на другого. Пару раз пришлось доказывать, что я это я. В итоге возврат произошел не прямым списанием со счета, а путем каких-то фокусов с пополнением счета через банкомат. Похоже, что это вообще какой-то кейс с нулевой вероятностью для таких организаций.
Как-то спорно. По-моему реальная проблема это придумать название для промежуточной переменной посреди длинного метода, а не объявлять ее тип. От var тут ни холодно, ни жарко. Красивое решение этой проблемы - это контекстные функции в Kotlin. Там если повезет, то можно весь метод выразить как цепочку из функций высшего порядка без промежуточных переменных.
В чем проблема рассказать про паттерны, которые вы реально используете? Допустим, у вас микросервисы и вы используете паттрен API Gateway. Вы испытываете затруднения объяснить, зачем он нужен? Или вы пишете на Node.js и используете паттерн Reactor (aka Event Loop). Снова пояснить не можете? Или вы пишете на Spring и у вас по всему коду расставлены аннотации Transactional. Что, опять какая-то проблема пояснить, как работают прокси? Может не в плохих собесах дело?
Ну а если из вас настойчиво трясут то, что вы в глаза не видели, то голосуйте ногами из такого места.
Что-то вы путаетесь в показаниях. Если вы реально пишете сложные расширяемые и отказоустойчивые приложения, то какой для вас труд пояснить мотивацию своих действий? А кристаллизованная правильная мотивация - это как раз и есть всякие солиды, паттерны, лучшие практики и т.д.
Какая-то тут недосказанность в истории с PersonItem и PersonFullItem. У вас же наверняка есть кейсы, когда у объекта Х полей и лишь несколько из них появляются всегда. Получается, что все же придется идти на оверхед и заменять примитивные типы алгебраическими.
А кто или что вообще заставляло вас думать в этом ключе? Это в манифесте какого-то языка заложено? Или у какого-то автора типа Шилдта постулировано?
По мне так это такой детский миф, живущий в джуновской среде. Только на джуновских собеседованиях я слышу про все эти "объекты реального мира", "наследование для переиспользования кода" и "Cat extends Animal". На практике принципиально другие вопросы задаются: "это работает?", "это тестируемо?", "это расширяемо?", "лучшим практикам не противоречит?" "это не антипаттерн?", "через месяц пойму, что написал?". Никто уже всерьез не упарывается экзистенциальным поиском святого Грааля ООП. Тем более, что почти все популярные языки давно уже мультипарадигменные.