Comments 76
То же самое применимо и к sequence & component (как оно сейчас то работает?).
Можно конечно пойти и поверить документации или чьим-то словам, но путь весьма рискованный.
Если честно — не очень понятно. Всё что там описано (слишком уж абстрактно и вообще без примеров) сводится к:
- Есть системные архитекторы. Те про кого в первую очередь все думают — матёрые опытные спецы нерды, которые знают все техн. нюансы в деталях
- Есть солюшн архитекторы. Они проанализируют задачу, которую бизнес вдруг захотел решать. Выявят все действущие роли (кто потребители продукта, какие они бывают), выявят что этим ролям можно предложить, и что они на самом деле хотят. Придумают в общих чертах какие для этого нужны системы\команды людей. Вообще не вникая в детали. Будут много много разговаривать "за жизнь" со всем начальством. В итоге рождается диаграма со стрелочками. Которая уходит уже системным архитектам, и они её воплощают в жизнь (или принимают во внимание).
Всё так? Никогда в живую с такими не сталкивался. Всё решали своими силами, включая диаграммы, анализ ролей, требований, всякие оценки. Наверное это удел совсем уж большого бизнеса.
(слишком уж абстрактно и вообще без примеров)
На самом деле в этом проблема современного программинга. Многие программисты не могут в абстракции.
По факту есть запрос «хочу вот такой сервис, есть команда, но не выходит». Берешь ручку, рисуешь абстракции и к ним технические роли, и вот, система начинает оживать.
Тут как тимлиду с опытом работы в год объяснять чем краткосрочное планирование отличается от долгосрочного, зачем нужно строить план на 5 лет вперед и как его сделать «если завтра всё поменяется» и объяснять разницу тактического планирования и стратегического. Это всё абстракции, но по абстракциям можно строить уже какие либо планы. Тупо как заметки на полях на 10 лет вперед.
Дык никто не спорит, что планирование и проектировка архитектуры нужны и полезны. Просто мне всегда казалось, что те самые "системные архитекторы" занимаются в том числе и этим. Просто как часть их ответственности. Одна из многих задач, особенно актуальная на самой ранней стадии. Ведь с не со структуры таблиц в СУБД же проект рождается. Вначале надо понять что мы хотим сделать. Кому мы это будем продавать. А что они на самом деле хотят? А что на самом деле им нужно? А что мы можем предложить такого, чтобы было лучше чем у конкурентов. А есть ли у нас на эти силы? Сколько потребуется людей и мощностей? Каков бюджет? Сколько планируем на этом заработать. Если всё ок — преходим к более конкретному планированию. Какие конкретные роли есть в системе. Каковы их потребности. Как мы будем их удовлетворять. Постепенно паззл складывается, рисуются всякие моки при необходимости, строются диаграммы, споры спорятся. Можно проводить опросы среди потенциальных потребителей. Заказать исследование рынка. По итогу появляется уже более детальное понимание будущего продукта и можно приступать к его имплементации. Уже другой уровень построения архитектуры. Более технический.
Вот исходя их статьи выше получается что почти всю вышеописанную работу выполняют solution архитекторы. На моём опыте этим занимаются все. В особенности СТО и "системные" архитекторы (a.k.a. "архитекторы"). Но привлекают всех чьё мнение имеет вес и опыт в этой сфере релевантен.
Но видимо в особо крупных конторах для этого есть отдельный человек. Я не сталкивался. Я в ынтерпрайзах не работал, так что спорить не берусь. Мне непривычно.
А касательно абстрактности не соглашусь. Программисты хорошо умеют в абстракции. Бывают просто хорошие и понятные статьи. А бывает bullshit с кучей воды, не подкреплённой примерами. Вот если взять ту статью и переписать, добавив некий абстрактный проект и расписав в диалогах — будет просто о сложном, главное понятно. А накидать в статью чуть ли не энциклопедичных врезок — это не программисты нынче обмельчали, а статья хреновая. Sorry.
Один раз в жизни видел Solution Architecture, и он очень сильно помогал в компании, это Solution Architect SAP/Oracle. Тогда строили большую ERP систему используя продукты двух компании, и одну проблему можно решить несколькими продуктами того же SAP'а, а какой именно будет лучше для нас, все тонкости, знал уже Архитектор.
Я не думаю, что человек прям совсем не умеет в код. Наверняка некоторые (базовые) навыки программирования у него есть, это так или иначе нужно и при том достаточно.
Также думаю, что это позволяет отесчь вопросы типа вспомните какие есть функции в стандартной библиотеке/фреймворке для этой задачи, какие есть параметры у этих функций, и в каком порядке они идут :)
Без проблем все схемы, и часто воплощаю проект включая экплуатацию. Для софта есть системные архитекторы и лиды, которые могут определить стэк руководствуясь опытом и командой.
"Уметь в" — это устойчивое веб2.0 выражение. Все же сленг надо знать.
Хороший совет про спрашивать что не так и как можно улучшить. На моей памяти так не делал никто :)
Не стесняйтесь ходить на технические собеседования. Это очень сильно прокачивает стрессоустойчивость, отрезвляет от синдрома звезды, выявляет слабые места и помогает определиться с направлением саморазвития.
Итак, собеседование, сначала техническая часть, все ок. Переходим к вопросам от HR:
— Почему вы хотите работать именно в нашей компании?
— Я? Это же вы мне звоните и предлагаете.
В итоге «спасибо за ваше время, но мы нашли другого кандидата»
— Я? Это же вы мне звоните и предлагаете
Ответ неверный.
Даже если ничего не известно о компании, даже если не искал ее прицельно, всегда есть что сказать.
Можно же было что-нибудь сказать по результатам технического собеседования, и по результатам общения с HR.
Оценить компетенцию будущих коллег, оценить настойчивость HR которые сами нашли кандидата и уговорили на встречу, выразить желание работать в одной команде с такими замечательными людьми.
— А, результатов говорите, нет? Ну так это рынок кадров сами знаете какой, трудно сейчас хороших специалистов найти, но мы стараемся, вот сами видите, приток кандидатов обеспечен — мы получаем по сто заявок ежедневно, отбор кандидатов ведется — проводим по 30 интервью в день. Среднее время ответа на заявку — одна неделя.
— А, ну работайте, работайте.
Любопытно — сколько решений (solution) автор реализовал на практике
Ведь агентству надо заплатить комиссию, если не ошибаюсь в размере месячного оклада найденного кандидата...
Один оклад это ещё весьма скромно. Порой эта комиссия составляет 2-3 оклада, что в отдельных случаях может приводить к бонусу агенства более 1 млн. руб. за трудоустроенного сотрудника.
Техносерв
Как человек, видевший всю эту кухню изнутри, могу сказать что, в зависимости от менеджера, может быть ситуация в которой не будет ни технического специалиста, ни каких-либо технических вопросов. Зато можно попасть на менеджера, который будет готов платить сильно выше рынка за ковыряние в носу, для кого-то это может быть подарком с небес. Но чаще всего платят они все же сильно ниже рынка.
Тоже сейчас ищу работу. Ваша статья заставила меня задуматься об отказе сотрудничества со сторонними рекрутерами в случае интересных вакансий. Лучше отправлю резюме в компании напрямую.
Обратил внимание, что некоторые рекрутеры переделывают отправленное резюме под вакансию на свое усмотрение или берут резюме в том виде, в котором оно опубликовано в HH, LinkedIn и других ресурсах. Это скорее всего уменьшит шансы успешного прохождения интервью. Пару раз мне говорили, что резюме очень краткое, как у начинающего. Разок сказали, что оно как будто на скорую руку написано. При исправленном резюме вопросы могут быть не по профилю или же по технологиям, с которыми давно не работал, но указывал это в резюме. Некоторые важные вещи, вроде публикаций, рекрутер может убрать из резюме.
Рекрутерам я бы посоветовал согласовывать изменения в резюме с кандидатом, а соискателям уточнять в начале технического интервью, в каком виде интервьюер получил резюме и читал ли его. В моем резюме указано, что есть 5 лет опыта разработки на React и есть краткое описание нескольких проектов на нем. Тем не менее, на техническом интервью как-то спросили: «есть ли опыт разработки на React? Только один проект делал на React ?»
Я бы сказал, что меня максимально удивило то, что и технические специалисты, которым надо работать с архитектором, и бизнес, который фактически отдаёт ему под непрямой контроль специалистов с многомиллионными зарплатами в месяц на команды и ещё более многомиллионные проекты, просто забивают на собеседования и попытки понять, с кем им надо будет работать. Условно, люди просто готовы отдать серьёзный контроль чуть ли не первому человеку, который удачно пройдёт «клоунский» фильтр от HR и удачное собеседование с техническим специалистом, который вдруг не забил на встречу.
Я отдельно отметил что мне интересна позиция именно solution-архитектора, я уже давно не программирую и code review выполнять не смогу
Одному мне кажется странным, что технический архитектор не умеет кодить?
Мне кажется, кодить он умеет. Просто не кодит ежедневно (да и раз в месяц вряд ли), но опыта именно программирования хоть отбавляй, хоть и, возможно, на совсем других языках, чем проект. Потому и ревью качественно делать не сможет, но это и не его задача.
Внезапно меня начали спрашивать про те навыки и знания, которых в моём резюме нет. Согласитесь, странно ожидать от человека, который всю жизнь работает на экскаваторе, знания синхрофазотрона. Далее мне было высказано явное неудовольствие от того, что я этот синхрофазотрон не знаю.
В конце этого странного собеседования я обратил внимание коллег из ВТБ, что ссылка на онлайн чатик – статичная и не закрыта хотя бы паролем и получил ответ «что это ерунда и это не важно».
Но был и положительный момент после этого собеседования – я перестал удивляться как банк ВТБ, три раза перепуская мне карту, не смог выпустить карту, которая бы работала. Во всём есть плюсы )
Только вчера читал твой пост в песочнице а сегодня он уже в топе. Красава!
Пожалуйста не звоните сразу на телефон, даже если вам нужен срочный ответ — лучше пишите в мессенджеры. И для начала отправьте хотя бы описание вакансии на почту. Почему-то рекрутеры думают что кандидаты сидят и ждут когда им кто-то позвонит с предложением о работе.
Да уж, даже когда даже отмечаешь в резюме предпочтительным способом связи почту — всё равно постоянно звонят. Особенно раздражает в рабочее время, когда и так коммуникации с клиентом выше крыши.
Читайте внимательно резюме и пишите только если опыт кандидата и желаемая позиция релевантны вашей вакансии.
Также постоянно происходит. Я работаю аналитиком данных с уклоном в ML и постоянно получаю приглашение на собеседованием в качестве системного аналитика, продуктового аналитика, аналитика bi и т.п. — там конечно есть общее слово, но профессии достаточно разнятся. Уважаемые эйчары, будьте пожалуйста более точны в поиске кандидатов: холодные звонки — дело статически оправданное, но кармы не добавляет)
Вот хорошая статья на эту тему: gaperton.livejournal.com/35460.html
от коллеги по работе. Цитата:
Когда ты не пишешь код, ты не получаешь обратной связи, ты не видишь, во что выливаются на практике твои мысли. Когда ты не правишь багов, и не сидишь на поддержке, ты лишаешь себя важнейшего элемента обратной связи — ты не видишь, какие решения оказались плохи, а какие хороши. А обратная связь — это сама суть инженерии.
я думал, что у Люксофта за 2 года качество найма повысился…
Аналогичная история (только другая должность) — 5 ТИ за месяц
Я вот думаю, что все кто выше неоднократно спрашивал в чём разница между солюшн и системным, не совсем точно сформулировали вопрос, и остались не до конца удовлетворёнными ответом. Давайте я попробую перефразировать: что солюшн делает такого, что не может или не хочет делать системный? В каких ситуациях/для решения каких проблем нужен и полезен именно солюшн, а системный не справится?
Мой личный ответ — солюшн очень много работает с бумажками, по сути только с ними он и работает. Системные столько бумажной работы делать обычно не любят — они, конечно, тоже рисуют диаграммы и пишут документы, но заниматься этим 100% своего времени совершенно не жаждут. Соответственно, как только количество бумажной работы у системного начинает зашкаливать — возникает нужда в солюшне.
Но хотелось бы услышать ответ автора, конечно. Потому что я системный, и, вполне вероятно, несколько предвзят. :)
Вы что-то переоцениваете существующие вилки. Зарплаты выросли конечно, но пока не настолько. 250-300 это цена очень качественного сениора. И начинающего/среднего системного/солюшен архитектора
что при найме непосредственно в Люксофт все происходит по-другому и такой бардак только на собеседованиях для ВТБ
Люксофт ни для кого ничего не разрабатывает. Это не аутсорсер, а крупный бодишопер. Они просто посредники и перепродают людей своим клиентам, поэтому собеседуют всегда представители заказчика, и работают люди на территории заказчика, и уволить вас могут по желанию заказчика. Люксофт только зарплату платит.
А как было в 2016? Потому как в 2017 уже было то, что было. Люксофт — это вообще не ИТ компания. По сути — это HR-агентство-посредник. Сколько раз они ко мне приходили, столько раз обещали "интересные проекты у крупных клиентов", а на самом деле там надо разгребать авгиевы конюшни (древнее легаси) на правах рабов на галере во всяких банках в России и в Польше в основном.
В 2016 году весь БЦ Осень в славном городе Питере был занят компанией Luxoft. Проекты, судя по общению с коллегами были разнообразны: банки, Automotive, всякое сложное и всякое простое. На территории заказчика я ни разу не был за полгода.
Однако, с представителем заказчика я действительно проходил собеседование за жизнь, после прохождения технического собеседования с командой из Luxoft. Это в чем-то похоже, в чем-то отличается от вашего описания.
При этом, мне действительно предлагали перейти на проект, где надо было работать на территории заказчика. Но от этого предложения я отказался, так как это уже прям совсем рабство какое-то, вполне подходящее под ваше описание.
интересные проекты у крупных клиентовЧестно признаюсь, что проект, в котором я принимал участие, мне показался интересным. Поковырял новые для меня штуки: тот же ElasticSearch, фишки из нового на тот момент PostgreSQL, на RabbitMQ и Kafka посмотрел. Ну и проект был новым, команда собиралась под него.
Как я искал работу весной 2021 года