Много знаешь - меньше возможностей устроиться на работу и финансового повышения. Поделюсь личным опытом собеседований, анализом рынка, перспективах.
Дано
Возраст: |
30+ |
Опыт: |
6+ |
Стек: |
С++17, Qt, PostgreSQL, ELK, Linux, Python, Apache Thrift, RabbitMQ... |
Место работы: |
Банк |
Время работы на текущем месте: |
1.5 года |
Оклад: |
медиана с учётом премии для Software Engineer, Russia |
Семейное положение: |
женат, есть ребенок |
Квартира: |
съемная |
Место проживания: |
Москва |
Условие
Узнал, что коллега пошел в другой банк и получил зарплату почти в 2 раза большую по сравнению с моей без учёта премии. Правда, он java разработчик. На текущем месте проработал лет 5.
Решил и я попробовать будучи уверенным в своих силах. Это был для меня один из возможных вариантов. Считал его самым перспективным. Поэтому из всех собеседований старался оставить его напоследок, чтобы придти в наилучшей форме.
Решение
Пересмотрел нужные видео. Перечитал нужные статьи. Немного покодил задачи.
Собеседование №1. Финансовые услуги
Уверенный в реальности этой суммы и в том, что варюсь в самой оплачиваемой области для своего стека смело её обозначал в процессе общения.
Hr: "... у нас разработчики получают примерно равную сумму - 300к. Нет любимчиков."
"Мы можем попробовать пройти тех интервью. Если всё хорошо, то с руководителем возможно обсудить."
Интервью в zoom. Классика нашего времени. Размышляли вслух над выводом в консоль.
Задача
Хотелось сразу сказать, что вызывать виртуальный метод из конструктора не хорошо. Потом к этому вернулись. Вспомнил случай когда такое сделал и получил ошибку run time.
Затем спросили про паттерны. Какие-то назвал. Хотелось громко крикнуть:
"Ребята, у меня профиль в github. Там таких нарешанных примеров пруд пруди. Давайте мой код пообсуждаем?"
В hh, linkedin ссылка на очень видном месте. Никого не интересует мои реальные примеры?
Спросили как я приступаю к решению задачи. Ответил, что могу схемку набросать, затем отойти подумать.
Интервьювер1: "Ага! Значит сразу не решаешь! И долго ждать?"
Воспринял примерно так. Хотел объясниться, что после первого решения надо бы подождать, чтобы созрело лучшее. Но воспринял отклик как негативный и не хотел дальше объясняться. Понял, что с этим парнем не на одной волне.
Был и второй. Он отвечал на мои вопросы в конце интервью про архитектуру, подходы к разработке. Я радовался, что у них разработчик разрабатывает большую часть времени, а не капельку, как у меня в последнее время.
Попрощались. На них особо не рассчитывал. Воспринимал скорее как полигон. Хотя, если бы сказали "ок", может быть и пошел. Спустя пару недель жена посоветовала получить обратную связь. Помнил, что hr же обещала вернуться. Может, до сих пор думают. Последовал совету.
"Взяли другого, ты красавчик, честное слово."
Собеседование №2. Алго-торговля, собственный фонд
Питер, Санкт-Петербург, Ленинград. Оплачиваемая квартира за 50к. Бонусы по нарастающей каждый пол года. Дружный коллектив. Уютная домашняя обстановка. Релокация. Поездки в Европу.
Отличное общение с hr. Пробуюсь в команду №2. Отлично пообщались с руководителем направления. Про умные указатели, многопоточность? Не-не. За жизнь, за понимание.
"Какие протоколы использовал в embedded?"
Рассказывал про свой первый опыт. Ему интересно, мне. Движуха.
Даже, вроде, рассказал как автоматизировал завод, что использовал.
"Сети?", - не, не слышал.
"Профилирование?", - сорри, не попадалось.
"html запросы?", - делал https сервер на POCO. Сейчас не вспомню специфики.
"websocket? Если дать время, разберешься?", - естественно!
flashback
Попрощались. Это был мой второй заход. Первый был в команду №1 в конце весны. Тогда это было одно из первых собеседований спустя 1.2 года как я устроился на текущее место.
Спрашивали про перегрузку функций, связку с шаблонными функциями. Нужно было рассказать какая вызовется.
Не скажу, что это вопрос из топа. Когда есть два параметра - int, short. Когда есть шаблонная функция с одним типом T. Что-то в этом духе. Потом понял, что для шаблонной важно, чтобы эти 2 параметра были одного типа. Тогда бы она вызвалась. Еще момент с повышением типа. В общем, сейчас не всё вспомню.
Вкратце по quick sort, heap sort. Внятно не ответил, потому что давно не вспоминал. А знание это быстро выветривается. Хотя в профиле github лежит написанная мною сортировка¯\_(ツ)_/¯
Смело называл манящую сумму. Тогда hr ответила, что для senior это реальная сумма. Через какое-то время пришел вежливый отказ в стиле:
"Наверное, задачки оказались не те, к которым был готов."
Попрощались на хорошей ноте. Честно признался, что команда классная, общение понравилось.
В этот раз hr сделала доп звонок:
"У вас такой отличный контакт получился!"
"По технической части оцениваем как middle. Всё-таки, на senior не хватает знаний, умений", - по их шкале, естественно.
"У нас middle получает в районе 200. На сколько готовы пересмотреть?"
За мою небольшую практику собеседований не часто возникал такой встречный вопрос. Как увидим далее в банке мечты с этим не заморачивались. Хотел взять паузу, посоветоваться с женой. Ей же рисовал молочные реки и кисельные берега. Для того, чтобы оправдать переезд с насиженного места. Где у нас обжитая квартира, классный садик, шикарная инфраструктура и хорошая работа у жены.
Hr не дала такое время. Назвал среднее между ожидаемой и текущей.
Забыл про вторую мотивацию - рост. Особого роста уже не ощущаю. А вот там - да. Сложные задачи, классная инфраструктура. Да и руководитель - человек, который 5 лет назад устроился и сам всё это поднял. Такое не часто встретишь. У него вся экспертиза. Не надо страдать в поисках обрывков документаций и слухов как это всё работает.
"Я вас поняла". И тишина.
Ну ладно. Еще не спросил обратную связь. Это позволит говорить в следующих компаниях, что я в процессе собеседования на желаемую сумму, которая реальна.
Собеседование №3. Биржа зарубежная
Есть движок. Нет С++ разработчика. Оно как-то работает. Медленно. Спрашивали в целом. Про 10к проблему. Про сети. К этому моменту уже немного почитал про select, poll.
"Когда 20 лет назад пробовал писать сервер..."
Вместе со мной размышлял. Было интересно.
"У нас дух стартапа. Вообще, стартап - это вещь экстраординарная. Ведь есть корпорации, которые всё предоставляют".
"А тут нужно что-то экстра", - и мягенько рассказал про систему опционов и работу сверх нормы. Стартап же. Нужно обгонять корпорации же.
Обратная связь отсутствует до сих пор. Сам человек русскоговорящий. Команда интернациональная. Английский для меня не проблема.
Лирическое отступление. Плюсы собеседований - разобраться в себе, своей мотивации
В процессе общения стал лучше понимать чего хочу. На текущем месте хотел стать тимлидом. Сам оказался в гуще, когда меня брали для усиления одной команды. Другая полностью ушла и меня направили туда с обещанием вернуться.
И какие-то:
Разработки
Доработки
Баг фиксы
Раскапывание дебрей
Общение с внутренними заказчиками
Апдейты ввиду обновления интерфейсов взаимодействия
Заявки на доступы
Тушение пожаров на проде
...и прочая
...легло на меня и вновь пришедшего аналитика. После такого разгребания жара пыла быть тимлидом поубавилось. И вот это радужная мысль с конференций:
"Я тут создаю рабочие процессы и условия для работы, несу свет и теплую атмосферу людям" - потускнела под грудой серых булыжников ежедневных преодолеваний.
Стало хотеться больше разрабатывать в роли разработчика. А возможности, как я посчитал, нет. Всё примерно работает. Слабо эволюционирует.
В первых собеседованиях говорил, что вот этим пресыщен. Немного обесценивая свой тимлидерский опыт. Который я так хотел получить. Парадоксально. Потом стал себя слушать, больше понимать.
"Ты это чего? Ты же через это прошёл и разгреб. Все сервисы работают. Цепочки сервисов отрабатывают на тестовых контурах, на проде. Поставь себе +сик"
На форуме когда делился мыслями услышал:
"Пожалуйста, ты можешь именно такой опыт и продавать на собеседованиях"
Хм. Т.е. это в своём роде уникальный опыт(хотя... насколько нужный?).
Стал понимать, что первична движуха сменить работу. И нахожу под это пункты. "Разработчик должен менять работу каждые N лет, чтобы не застаиваться", - пульсирует в голове. Это правда? Или, как я слышал, можно на текущем месте стать супер профи?
Или же, как я слышал, разработчик уже больше копает вширь:
В бизнес процессы
Предметную область
И может в будущем продавать такую экспертизу. А если вглубь - до какой глубины?
"Ну что ж, сейчас я эти биты запакую и получу более компактную структуру, которая ляжет в кэш и уменьшит время обращения"
Пересмотреть все видео с конференций по языку? Что еще?
Еще понял, что для меня важна социализация. На прошлой работе был командный дух разработки. Все сидели через пару метров друг от друга. Руководитель "заходил на огонёк" каждое утро. Подходил к моей парте у стены, опирался на неё и делился мыслями. Рассказывал, что он подумал о таком-то компоненте - как работает, как преобразовать. Я предлагал стул. Он садился, рисовал, визуализировал понимание.
Как-то раз он пришел с озарением. Встретились в коридоре. Распарсил в голове протокол общения сервисов. Ходил из клеточки в клеточку показывая сущности и порядок взаимодействия. Мы тогда перенимали телекоммуникационный проект - работающие асинхронно установки. Я был первым среди нанятых им разработчиков.
Год такого классного взаимодействия. Потом начали приходить еще. Внимание руководителя стало делиться на всех. Сначала было не привычно. Потом как-то получилось выровняться эмоционально.
В какой-то момент, когда уже набирался штат я немного опечалился:
"Вот столько рефакторинга проводили"
"И толку? Какая эта заслуга?"
"Сейчас приходят ребята и для них это уже как данность, пилят фичи."На что руководитель рассказал утешительную историю:
"В одной книжке прочитал пример. Есть комната 3ех метровой высоты. Сверху люк. И есть человек 2м. Не может вылезти. Нужен еще один, чтобы его подсадить, чтобы сдвинуть крышку"
Не строгий пересказ получился. Может, кто-нибудь вспомнит оригинал. Отложилось в памяти, что один может пахать и сделать 80% работы. И есть еще, который может сделать 20%(для которого это его 100%). Вроде и немного. Зато вместе, они сделают 100%. И откроют этот люк.
Еще я отметил, что продукт живет. То что я сделал - это для других само собой разумеющееся. И не надо печалиться. Если бы мы тогда не разгребли эти дебри, то сейчас люди не смогли бы вкладывать в уже более понятную, разобранную архитектуру, понятный код. Каждому моменту жизни проекта своя работа.
Собеседование №4. Финтех решения
Пробовал еще летом, следом за 1ым питерским собеседованием. На звонке пообщался с руководителем. Такой бодрый мужик. Держался вежливо. Чувствовалось, что требовательный. Интересовался чем отличается многопоточность от асинхронного программирования. Кейсы? Рассказывал про свой опыт, про контекст использования.
Спрашивал, как бы я описал развитие продукта. Однако ж! Не задачки тут решаем, а говорим про важные вещи! Рассказал как себе представляю:
Выкатили пилот
Получили обратную связь
Пилим дальше
Тогда думал что ответил хорошо. Это же современный подход. Все так говорят! После смотрел видео про архитектуру, осознавал agile подход. Ответил бы более полно. Того что сказал, видимо, хватило. Позже было тех интервью в стиле: "Готовься к 14:00 быть на связи. Тебе высылается опросник. У тебя 1 час." Поехали!
Тесты
По ощущением, ответил на процентов 70-80%. Пришел отказ.
Еще опросник от другой компании, где спрашивали с какими БД работал, сколько запросов в секунду обслуживал и как бы решил проблему 10к. Hr представила проект и команду как аналог гугла. Продают рекламу везде по миру. Гигабиты скорости. Терабайты данных. Отказ.
Ну и пускай. То была летняя проверка на прочность и прицел к рынку. Хотя бы попрактиковался.
К собеседованию в банке мечты с желаемой суммой подошел уже в хорошей форме.
Следующие части:
Нужно больше собеседований
Автоматизируем завод
Пол года спустя
Если хотите раскрытия какой-то темы, пишите в комментариях. Постараюсь учесть.
Комментарии (92)
Terras
27.03.2022 10:30+5Ну вот в следующих статья и посмотрю, что по итогу вышло, а за эту недостатью минус.
avovana7 Автор
27.03.2022 12:16+1Спасибо за отклик. Подскажите, пожалуйста, что интересно было бы прочитать/подсветить/о чём узнать в следующей статье?
Когда буду формировать содержание по возможности учту пожелания.
NTDLL
27.03.2022 10:53-6А если вам предоставят коротенькую строку, сможете вручную посчитать CRC32, в частности её разновидность, которая применяется в тотал коммандере?
А вручную закодировать строку в Base64?
gecube
27.03.2022 11:12+4Однозначно, если спеку дадут (что такое crc и что такое бейз64, я попросту не помню точных правил преобразования - они в RFC должны быть)
hard2018
27.03.2022 12:48-4Кто же вам её даст. Перед глазами бумажка с строчкой и уточнение, что это циклическая сумма, применяемая в большинстве программ (WinRar, Total Commander, WinHex, к примеру). И вперёд. Её легко вручную посчитать, правила очень просты. Таблица ASCII вроде тоже не менялась.
gecube
27.03.2022 13:10+1Ну, циклическую сумму напишу. Бейз64 - я попросту не помню точный алгоритм. Там как-то бинарные данные разбиваются, кажется на блоки по 7 битов и заталкиваются в подмножество текстовых символов. Все. Дальше склероз.
Metotron0
29.03.2022 09:2764 в названии наводит на мысль, что должно быть 6 битов.
А CRC же вроде бы требует порождающего полинома нужного размера. Его так легко посчитать? Или он не обязателен?gecube
29.03.2022 09:29Я поэтому и просил rfc. Я ж не должен константы и все такое помнить наизусть. Это попросту глупо и не нужно. Это как своё шифрование писать. Может быть и полезно с академической точки зрения, до саморазвития, но его ни в коем случае не стоит использовать в production. Лучше взять готовую либу
64 в названии наводит на мысль, что должно быть 6 битов
может быть, спорить не буду
edo1h
28.03.2022 06:58+1А если вам предоставят коротенькую строку, сможете вручную посчитать CRC32, в частности её разновидность, которая применяется в тотал коммандере?
без порождающего полинома и прочих констант? то есть их вспомнить надо? я — точно не вспомню.
А вручную закодировать строку в Base64?
опять же вспомнить таблицу из стандарта? ну процентов 10, что угадаю.
только какое отношение эти задачи «на вассерманистость» имеют к программированию?
если уж и захотелось спросить именно про base64 и crc32, то интереснее было бы обсудить положенные в основу идеи, достоинства и недостатки, возможные улучшения/альтернативы (например, почему для адресов биткоина решили использовать base58, а для сортируемых uuid предлагается crockford base32)а «посчитать вручную», на собеседовании сеньора, серьёзно?
dimti
27.03.2022 11:18+9Читается как нечто человеческое. Текст не причесан, не разбит структурно на сюжет. Все довольно естественно, как ход мыслей - он всегда немножечко сумбурный.
В целом переносится мимолётное ощущение от всего этого на читателя. Нет логической концовки и иногда, ощутимых переходов между рассказами о собеседованиях и общих мыслях насчёт всей этой палаты (менять работу каждые n, куда развиваться). Но, душевный отклик нашелся.
Я сам немного шокирован тем фактом, что в отрасли бытует мнение, об обязательной смене рабочего места, каждые 2-3 года. Не пойму как вообще к этому относится. Но решил забить по итогу и не думать про эту хрень.
gecube
27.03.2022 11:55что в отрасли бытует мнение, об обязательной смене рабочего места, каждые 2-3 года
скажем так - я бы работал и 10 лет в одной компании, если б это был гугл или амазон. Но реальность немного другая...
avovana7 Автор
27.03.2022 12:12+2Работать 10 лет в одной компани- если бы была возможность смены проектов, то да. Как недавно услышал - когда становится легко и не надо учиться - это уже звоночек.
avovana7 Автор
27.03.2022 12:10Спасибо за отклик. Действительно, это статья была написано по горячем следам. Понимал, что если не напишу в моменте после начальных собеседований и всех переживаний, то статья может получится хранилищем сухих фактов со столбиками "+" и "-" от очередного собеседования.
Graf54r
27.03.2022 16:28+1Согласен — текст совсем не причесан. И часто не понятно — кто говорит, к кому относится данные текст.
Зачем-то указана ссылка на медиану, почему тут не указать?
Много лишних слов.
Читать сложно, надеюсь что автор код пишет не так же.
Koval97
28.03.2022 14:02Комментарий как бальзам на душу. Редко такое нынче встретишь на Хабре. Остальные небось уже забыли как выглядит человеческое отношение.
vadimbereza
27.03.2022 11:50+4Чувствуется боль автора про никому ненужный гитхаб
Сам в последние пару месяцев прошел десяток интервью, около 70% компаний спрашивают про гитхаб, им особенно важно, чтобы был какой-то актуальный код (ну, чтобы можно было посмотреть и убедиться в том, что кодить ты умеешь)
В итоге (на основании гитхаб инсайтс) твой гитхаб открывает процентов 5 из тех, кто про него спрашивал, а клонирует или смотрит что-то кроме ридми - никто или почти никто
Видимо просто считается хорошим тоном спросить про гитхаб, а действительно зайти и посмотреть - никому не нужно, куда важнее спросить про солид или "кем ты себя видишь через 90 лет"
Самый крутой случай был, когда зашли и посмотрели, что нет "актуального кода", в связи с этим попросили сделать тестовое (как обычно, на "2-3 часа", но на самом деле на "2-3 дня"), а в итоге не то что не склонили и потестили, даже не заходили) До этого последний раз делал тестовое много лет назад, сейчас ради интереса решил сделать, после таких приколов больше никогда не буду
avovana7 Автор
27.03.2022 12:23С тестовым в будущем статье тоже опишу случай. Печальный по соотношению затраченному времени/выхлопу :(
Самое интересное, что в профиле у меня был реальный проект - автоматизация завода. При создание проекта договорился с заказчиком, что могу показывать код. Поэтому и горел желанием его обсуждать. Ведь это я делал. Каждую строку писал, дебажил, рефакторил.
Но никому нет дела. Сделай, пожалуйста, уважаемый соискатель:
алгоритм, многопоточность, design patterns, запросы в БД.
Тогда и поговорим.
Koval97
28.03.2022 15:03Хорошо быть инженером. Ни тебе никаких тестовых заданий, ни презрения к дипломной работе, ни игнорирования твоих слов. Я в таких ситуациях, когда не желают договариваться, всегда напоминаю, что на рынке они не одни. Конкуренция быстро отрезвляет. А если упорные, то "спасибо за собеседование" и нечего тут больше задерживаться - раз люди не заинтересованы в компетентном сотрудничестве, то нет смысла слушать их трёп об "поиске магазина волшебных палочек".
avovana7 Автор
29.03.2022 10:20Знаю про подход - сказал цену, а тебе в ответ "да"/"нет".
А у вас торги. Часто такое бывает?
Koval97
29.03.2022 14:25А у вас торги. Часто такое бывает?
Конечно. Люди более сговорчивы и не стремятся прям строить из себя пуп Земли. Неадекваты сразу отсеиваются после минимального диалога, многие даже не отвечают - и хуй с ними. А если человек заинтересован, а таких хватает, то и сам могу пойти человеку навстречу.
"Люди часто судят, не разобравшись в проблеме, потому что полагают, что знают ее. Не полагайте!" (Ицхак Адизес)
Я не полагаю как вы, а спрашиваю. Если мне нужна прибавка к зарплате, то я просто спрошу с аргументами, а дальше что будет то будет. Захочет уволить - патенты на мои разработки всё равно у меня, размер отчислений указан в отдельном документе. Захочет выгнать и отругать - пусть попробует, я его самого дураком выставлю не меньше. Захочет подумать - пусть думает, ответ получу при следующей встрече. Если мне нужно что-то сделать под конкретное предприятие, то я это делаю, чем-то приходится пожертвовать, что-то делаешь сам, применять знания полученные на предприятие никто запретить не может. А хочет судиться - у меня всегда есть контакты хороших адвокатов. Но конфликты крайне редкая история, часто предприниматели готовы пойти на встречу и нет смысла отказываться пойти навстречу самим.
Профессиональный рост должен быть постепенным. Если бы люди избегали пожертвовать самым малым, то у нас не работал бы ни один договор.
Не беру на себя лишнюю работу, но при этом не пытаюсь избегать своей работы - я знаю как сделать её хорошо, и делаю. Что-то приходится вводить в привычку, что-то остаётся с предыдущих мест работы, часто всё начинается с вхождения в рутину или вхождения в должность, как это называют академически, а после применяешь свои сильные мотивации и слабые отдают блеском в виде проектов и некоторых событий, которые воспринимаются как приключение.
Если для вас всё это кажется чем-то сверхъестественным, то я вам скажу ещё больше - это просто то, что делает любой здравомыслящий человек.
tremp
27.03.2022 12:26+1Такое же ощущение. Спрашивают про гитхаб. Говорю есть непубличный проект - могу дать временный доступ, только скажите кому. На этом в 100%случанв общение про гитхаб заканчивается. И тестовое тоже было на 2 дня по итогам которого ни одного серьезного недочёты не было (не по гайдам названы директории, лишние(тут наоборот хотел показать - какие при дальнейшем развитии будут классы/слои) - на основании этого отказ. Что это было? Короче, собеседования - тот ещё опыт )
gecube
27.03.2022 12:33мне присылали гитхаб. Лучше бы не присылали. Там такой позор и тлен, что просто жесть. Я бы тоже постеснялся это показывать. С другой стороны, гораздо выигрышнее быть коммитером в какой-нибудь активный опенсурс проект. Ишью репортить, патчи слать. И после этого станешь известным в какой-то момент времени. В хорошем смысле. И не нужно будет ничего показывать.
vkni
27.03.2022 22:26Тем не менее, когда на интервью говоришь, что да, тесты пишу - вот ссылка, то многие вопросы снимаются.
0xd34df00d
28.03.2022 07:24Хы, у меня как-то наоборот, гитхаб даже никто не спрашивал, но на одном из собеседований не так давно собеседующая откопала мой мелкий проект десятилетней давности и начала его со мной обсуждать. Ей очень нравилось взятие производных, а я там как раз производные в компилтайме на C++ брал, и она попросила меня рассказать, что и зачем я там десять лет назад делал.
questor
27.03.2022 12:02+6Ребята, у меня профиль в github. Там таких нарешанных примеров пруд пруди. Давайте мой код пообсуждаем?
Не, это так не работает. У меня тоже профиль на so, leetcode, github - и тоже хочется кричать, что у меня по этой метке куча задач нарешана, а по этому языку вообще золотой бейдж. Но когда речь идёт про собеседование в контору где процесс собеседований поставлен на поток - то интервьюирующему важно задавать свои одни и те же задачи, а не копать то, что вы пришлёте.
Дело в том, что интервьюеру важна "насмотренность", как у врача: он смотрит как сто человек отвечают на одну и ту же задачу и через некоторое время приходит понимание какой интервьюируемый сильнее, какой слабее.
Ваши профили и проекты при этом быстренько пробегут, чтобы примерно понять ваш уровень и прикинуть какие задачи давать. (У интервьюирующего пяток "любимых" задач разного уровня, чтобы посмотреть. При этом в целом база задач для АА-интервью может включать более 1500 вопросов) Но спрашивать всё равно будут по своему собственному, готовому треку. Не относитесь к этому слишком строго, таковы правила игры.
DrinkFromTheCup
27.03.2022 12:10Возражу.
Человек идёт на Сеньора и идёт небезосновательно.
Кандидат в Сеньоры с непустым гитом - это просто подарок для нанимающего: по содержимому проектов можно с 90% уверенностью решить, стоит ли пытаться его брать как Сеньора или лучше сначала переспросить "Может, всё-таки, на Миддла?"
Если, конечно, у компании есть человек, способный бегло оценить качество и документированность кода. Если такого человека у компании нет, то стоит им обзавестись (и перестать требовать Сеньоров до того момента): по шаблонным тестовым заданиям и не менее шаблонным вопросам адекватного Сеньора профукать легче лёгкого.
gecube
27.03.2022 12:12-1по шаблонным тестовым заданиям и не менее шаблонным вопросам адекватного Сеньора профукать легче лёгкого.
сомнительно, а я не соглашусь. Синьор шаблонные задачи будет решать даже не включая мозг
DrinkFromTheCup
27.03.2022 13:07+6Я бы тогда попросил сделать шаг назад и определиться, понимаем ли мы с Вами под Senior один и тот же набор умений и навыков.
В моём (довольно странном) мире Senior - человек, от которого ждут творческого подхода + сильнейшей экспертизы.
С достаточно высокой вероятностью на шаблонный вопрос Senior ответит сообразно своей экспертизе. Что будет воспринято интервьюирующим как полная фигня в лучшем случае ("у меня в бумажке же не так написано").
Чем ещё адекватно мерять "сеньорность" кандидата, помимо ревизии его публичных проектов и многочасовых импровизированных хакатонов, мне неведомо.
При этом, плохо подобранный Senior - это риск для проекта, большой риск.
Я рад, что Вы можете себе позволить заложить буфер на такие риски заранее. Это нечасто встречающаяся роскошь.
avovana7 Автор
27.03.2022 12:32Сейчас понимаю, что еще можно добавить такой фактор как величина компании. Если крупная - то чисто потоковые интервью. Если мелкая/средняя, то уже можно реализовать такой подход к внимательному изучению гитхаба.
ComodoHacker
27.03.2022 13:44Если быть честным, на сеньора ТС не объективно тянет. У сеньора не может быть ответов "не слышал", "не сталкивался". Точнее, может, но очень редко.
И компании сеньоров не нанимают "на потоке" (кроме FAANG).
DarkTiger
27.03.2022 15:07+6У сеньора не может быть ответов "не слышал", "не сталкивался".
Да сколько угодно может быть. Опытный сеньор от этого совершенно не парится, помня известную истину "Один дурак может задать столько вопросов, что на них не ответит и тысяча мудрецов". У него по 10 приглашений на неделе в почте, зачем ему пытаться производить впечатление на очередных самовлюбленных придурков, заучивших ответы на собственные вопросы?
Цитата из БГ "Мне было бы лестно прийти к ним домой и оказаться сильней" работает только до 35 лет, дальше становится совершенно по фиг.ComodoHacker
27.03.2022 19:52Причем здесь "париться" и "производить впечатление". Я про знания и опыт. Я не могу представить себе C++ сеньора, который никогда не сталкивался с сетевым программированием или не занимался профилированием.
Cheater
27.03.2022 20:54Ну давайте знакомиться, C++ разраб почти с 15 годами опыта, Principal SW Engineer, ни разу в жизни не писал:
Ничего сетевого
Ничего многопоточного на сколь-нибудь серьёзном уровне
Ничего под GUI (Qt, Gtk)
Без профилирования да, я хз как обойтись, но в собеседовании с ТСом я всё же не стал бы клеить ярлыки и начал бы копать уровень его понимания, мб и правда сеньор.
vkni
27.03.2022 22:35Без профилирования да, я хз как обойтись
У меня последние несколько лет в новом коде более-менее понятно, что где тормозит и почему (IO). Буквально всё упирается в золотое правило "опытный пишет сразу обработку пакета данных, даже если нужно обрабатывать один элемент".
Многопоточку на серьёзном уровне на С++ писать очень тяжело, лучше взять Haskell с STM. Ну senior он на то и senior, чтобы выбирать инструмент под задачу.
Сетевое, кмк, большинство пишет через 33 прокладки. То есть, игра с сокетами крайне редка. Это и объяснимо: для сетевого хочется писать используя RAII, которого в С нет => надо использовать С++ прокладку, написанную, как правило, кем-то другим.
avovana7 Автор
28.03.2022 07:55Какая прикладная область, если не секрет? По профилированию нашел ресурс easyperf Дениса Бахвалова. Его книжку про профилированию уже практически дочитал. Остаётся упражнения делать. Подскажите, какие еще есть ресурсы по теме?
Недавно попробовал его применить на небольшом сетевом коде : perf -I=3000... - т.е. периодически сохранять значения основных счетчиков. Далее цепочка:
perf.out -> питон скрипт tail'ит, преобразовывает в json -> его читает filebeat -> Elastic Search -> в Kibana смотрю график онлайн.
Получается наглядная картинка)
Cheater
28.03.2022 11:37Разработка EDA (сред для проектирования микроэлектроники) и IDE.
По профилированию я читал только гайд от автора perf https://www.brendangregg.com/perf.html и вики проекта https://perf.wiki.kernel.org/index.php/Main_Page.
vkni
27.03.2022 22:29Могло быть "я успел забыть то, о чём вы никогда даже не догадывались". Типа было профилирование с gprof, но давно. А последние 10 лет и так в 90% случаев понятно, что тормозит и почему.
avovana7 Автор
27.03.2022 12:30Первый раз слышу про "насмотренность". Это хороший аргумент в сторону таких потоковых интервью.
WraithOW
28.03.2022 19:46+1Не, это так не работает. У меня тоже профиль на so, leetcode, github — и тоже хочется кричать, что у меня по этой метке куча задач нарешана, а по этому языку вообще золотой бейдж.
Во-первых, это всегда вопрос верификации. Ну то есть объективно бывают ситуации, когда у человека в репозиториях всякие clean architecture, всё вылизано, а на деле выясняется, что он эту репу под чутким руководством разраба с 10 годами опыта ведет, а сам хорошо если MVP и SOLID отличает.
Во-вторых, репа — это результат, который не отражает процесс. Посмотреть, как человек себя ведет во время работы многого стоит. И даже если вы эту задачу уже решали — хороший ревьюер послушает, как вы опишете решение, упомянете ли о граничных случаях, как обоснуете выбор конкретных инструментов. «Это так, потому что А, Б, В» гораздо лучше, чем «Это так, потому что в solution так написано».
ToTheHit
27.03.2022 12:33Была ли у тебя дизмораль после отказов на собеседованиях? Есть опыт за спиной, куча решённых сложных кейсов, а тебе все равно говорят «ты слишком слаб». Не появлялась мысль «на текущем месте я себя уже зарекомендовал, тут какая-то стабильность есть. Лучше не буду лишний раз дёргаться…»?
avovana7 Автор
27.03.2022 12:41Это очень хороший вопрос. Наверное зависит от темперамента, усидчивости, удовлетворенностью закрытием текущих семейных нужд и т.п.
По характеру - так получилось, что в какой-то момент я уже не мог остановиться. Об этом напишу. Т.е. уже набраны обороты. Эндорфины в крови. Зрачки расширены. И не получается сказать "нет" очередному зазывающему hr :)
По нуждам - писал, что нет собственной квартиры.
Я как-то в студенчестве месяц поработал в продажах - ip телефония. За месяц обошел сотни фирм. Почти продал 1ой. Т.е. выхлоп был меньше процента.
В каких-то статья люди пишут как полгода готовятся. У меня так не получится. Мне нужно чувствовать обратную связь. Если пол года вкладываться и потом всё за зря, то время потрачено впустую. А так пособеседовался - получил обратную связь, чуть подчитал, порешал. И снова. Переступая через печаль, мысли что "не оценили" и т.п.
И чем больше втягивался, тем меньше посещала мысль, чтобы "лишний раз не дергаться".
iboltaev
27.03.2022 15:01+1"Ты слишком слаб" - это часто бывает, когда денег платить хотят поменьше. Вообще деморализация после серии отказов - это вполне нормально. И дать себе годик на восстановиться - вполне рабочее и нормальное решение. Тут нужно понимать, что собеседование - это элемент случайности, и получается вполне себе пуассоновский поток событий - то пусто, то густо.
Olevin84
27.03.2022 12:46+1"Разработчик должен менять работу каждые N лет, чтобы не застаиваться", - пульсирует в голове. Это правда? Или, как я слышал, можно на текущем месте стать супер профи?
Если ты задумался, через сколько лет следует менять работу (чтобы не застаиваться), значит уже пора. И неважно, сколько лет прошло.
Хотя бывают ситуации, когда человек работает в конторе чуть ли не всю жизнь, и менять ее не собирается. Значит, для него в конторе все норм. Не надо мне делать как лучше, сделайте как было хорошо.
DrunkSkipper
27.03.2022 12:46+1Ну, четвёртая компания это Scalable Soltuions, прошёл к ним, сделал тестовое, договаривались на 4500 usd, всех всё устраивало. Где-то спустя неделю пришёл ответ - “мы решили, что прошёл на миддла, готовы предложить максимум 3к евро”. К слову, контора хочет ип, а не трудовой.
avovana7 Автор
27.03.2022 12:47В точку. Рассказывали интересные вещи про проекты. У тебя получилось дойти до конца. Поздравляю!
gecube
27.03.2022 13:12контора хочет ип,
Это вполне ок, если у них нет Юрика в РФ.
WASD1
27.03.2022 20:06Тут скорее если контора оптимизирует твои соц.выплаты, то ожидаешь, что как минимум часть недоплаченного пойдёт прямо в оклад.
А тут по ощущениям, что они и нанимали по низу рынка, да ещё и тариф "налоговой оптимизации соц.взносов".
korizza_spb
27.03.2022 17:21+1я остановился на общении с их хрюшей в чатике с пингом в неделю. последнее ее сообщение было предложением написать тестовое, на этом все. привет, кстати! что на тебе надето?
Hait
27.03.2022 13:00А в законодательстве РФ есть какая-то защита от отказа после получения оффера?
gecube
27.03.2022 13:12Нет
Hait
27.03.2022 13:22Хм. Т.е. надо заключать отложенный трудовой договор, чтобы быть уверенным?
gecube
27.03.2022 13:25+1похоже на то, но чем это поможет, если у Вас все равно будет probation период с возможностью увольнения за X дней по notice от empoyer?
Если что - я не ТРУДОВОЙ юрист, поэтому все мои высказывания стоит перепроверять
Hait
27.03.2022 13:29ОК, спасибо. Ну увольнение после устройства выглядит более затратным для работодателя
Stauroman
27.03.2022 13:53Паста годная, как уже сказали не сухая и это классно. Как тут подписываться на следующие части?
ChiDa
27.03.2022 13:53+3Автор, у вас проблема с формулировкой мыслей. Сплошной поток сознания и парцелляция. Читается тяжело и вязко. Много сумбура. Надеюсь, вы документацию пишите не так.
iboltaev
27.03.2022 14:14+1Мде. Как было у меня:
1) офер. Потом "мы тебя сможем нанять только если ты куда-нибудь уедешь"
2) "мы тебя готовы нанять, если ты уедешь в Турцию"
3) "Мы тебя готовы нанять, если ты уедешь в Сербию"
Вот такие пироги.
Про C10k и epoll - это до сих пор проблема, что такое до сих пор спрашивают? Epoll вроде в районе 2004го прикрутили. 10 лет назад, когда еще на плюсах сидел - вот тогда спрашивали. Сейчас работаю на scala, и по-моему сейчас у нас для бэка адекватный не-асинхронный фреймворк просто не найти, так уже года с 15го точно.
ЗЫ: const еще в template parameters-ах можно использовать, вспомнилось
kotlomoy
28.03.2022 00:36+1Я человек простой, вижу тесты - руки тянутся порешать.
1: 1. Указатель на константу; 2. Константа указатель; 3. То же, что и 1
2: + Для обозначения метода класса, не изменяющего данные класса
3: 1. Лямбда-функция с изменяемыми данными; 2. Не использовать этот конструктор для неявных приведений типа
4: 4. Ошибка компиляции, т.к. x3 типа double
5: Приведение типа с потерей const, delete без []
9: AABCcbaa
10: Никак
12: 2 1
13: Для X нет операции сравнения
14: Статичный метод обращается к нестатичным данным
15: Приведение с избавлением от const, убрать const?
16: Не нужно удалять элементы в цикле, нужно очистить весь набор после цикла
17: Нельзя переопределять ссылкиCheater
28.03.2022 01:5317) Ещё тип данных в map дб Default-constructible (с конструктором по умолчанию).
0xd34df00d
28.03.2022 08:07+1Для обозначения метода класса, не изменяющего данные класса
Для обозначения метода класса, который можно вызывать на константном объекте этого класса (это кривая формулировка, но совсем в standardese ударяться я не хочу).
В частности, есть тонкости.
Во-первых, этот метод может менятьmutable-члены класса.
Во-вторых, сconst_castэтот метод может менять даже не-mutable-члены класса, и это не будет UB, если объект не объявлен какconst:struct Foo { int x = 0; void doShit() const { const_cast<Foo*>(this)->x = 42; } }; int main() { Foo foo {}; foo.doShit(); // не UB const Foo foo2 {}; foo2.doShit(); // UB }В-третьих, этот метод может вызывать только другие
const-методы (с точностью доconst_cast).Как же я люблю вопросы по C++!
Не использовать этот конструктор для неявных приведений типа
Забыли
explicit operator Type(). Ещё можно выпендриться и вспомнить, что с C++20explicitможет быть условным (ну там,explicit(std::is_something...)).- Ошибка компиляции, т.к. x3 типа double
Это удивительно, но нет, ошибки компиляции не будет. Вот если бы там не было
const…Статичный метод обращается к нестатичным данным
Ещё у него не может быть
const-квалификатора.Не нужно удалять элементы в цикле, нужно очистить весь набор после цикла
ХЗ, какое вообще «текущее поведение» они имеют в виду, если оно может быть каким угодно, ибо в коде UB. Может, они пытаются распечатать каждое второе число?
Нельзя переопределять ссылки
А тут никто и не переопределяет ссылки, тут пытаются присвоить новое значение объекту по ссылке. Просто объекты по ключам 0.2 и 0.3 (кстати, использовать даблы для ключей пахнет проблемами) создадутся, но никак не изменятся, но, вероятно, автор кода имел в виду не это.
По оставшемуся:
\18. double free статического kernel'а плюс забыли
constу параметраprintLog, в результате чего забиндиться ко временному значению, сконструированному из строки, оно не сможет.\20. Чего там писать,
void sort12(std::vector<int>& vec) { size_t ones = 0, twos = 0; for (auto el : vec) { if (el == 1) ++ones; else if (el == 2) ++twos; else assert(false); // или экзепшон, или пустота, или что угодно } std::fill(vec.begin(), vec.begin() + ones, 1); std::fill(vec.begin() + ones, vec.end(), 2); }
Stan88
28.03.2022 01:07+2"Проект нужно менять каждые 2-3 года..." Никогда не мог понять этого обобщающего изречения. Все крайне индивидуально. Ведь так? Если у вас на проекте через некоторое время задачи стали однотипными, или были таковыми изначально, и вас это напрягает - нужно менять. Если вы хотите больше ЗП а тут уже потолок - нужно менять. А если вас все устраивает - то зачем менять? Что бы иметь еще больше опыта и инструментария за спиной? Что бы что в итоге? Развиваться ради развития? С возрастом этот энтузиазм будет только угасать. Да и развивать нужно не только себя, а и сам проект. Это как бы конечная фаза любого участника бизнеса - проект развивается, оптимизируется, расширяется, прибыль растет (по крайней мере я себе это так представляю). Если проект прекратил стадию развития - то тут уже волей не волей задумаешься о смене проекта. Но если у вас есть опыт работы в сложном проекте и вы уже умеете решать как стандартные, так и оригинальные задачи, то вы в любом случае при смене работы овладеете любым новым нужным инструментом, языком, средой и т.д.
Да и сами проекты бывают весьма уникальными. Я сейчас работаю как раз на таком. Тут и Embedded часть, и программная часть кем тока не писалась за последние 25 лет, и куча специфической технической информации, и Real time OS со своими аппаратными заморочками. Документация при этом отсутствует как класс. Что из коментов нашел - то и твое. Архитектура, протоколы обмена между аппаратными и программными частями, криптография, топография, закрученная реализация Security brand, куча багов от каждого этапа разработки. Из отладочных средств нет ничего - ибо собирается на х86, а заливается и крутиться в железе. Ни Debug-а, ни программаторов с трассировкой. Только printf на монитор да собственные утилиты, позволяющие хоть как-то заглянуть что там происходит на аппаратном и на программном уровне. А происходит там очень много. Плюс еще нужно следить как отрабатывает физическая часть, которой этот софтовый монстр управляет. А там и теория антенн, и RFID, и механика с сенсорами.
Примерный порог вхождения в проект что бы реально работать - около года. Кропотливого года решения инженерных задач, разбора на атомы огромнейших обработчиков прерываний и их условностей, механизма обмена сообщениями подзадач, отрисовки логики работы всей системы, понимание бизнес-логики проекта, разработки собственного программного функционала для анализа текущего и т.д. Все задачи индивидуальны, повторяемых нет ни одной. Пока лишь этап изучения и фиксации предыдущих багов. Плоскостей для развития, расширения и поддержки просто тьма. Вплоть до смены программно-аппаратной реализации в целом ввиду ее устаревания.
Я попал на проект, который мне крайне нравиться, после 10 лет опыта в промышленности, разработки бортовых комплексов, систем навигации и прочего - и только теперь я могу сказать, что это мой проект. Иначе я бы всем этим не заморачивался. Условия работы лучшие из того то встречалось ранее, да и заказчик крайне адекватный. И как вы думаете потратив столько времени, сил и нервов, захочу ли я менять этот проект через 2-3 года?)selkwind
28.03.2022 08:00и только теперь я могу сказать, что это мой проект.
Здесь возникает риск что Вы попали на корабль и приросли к нему за это время. И стали, скорее всего настолько же нужны этому проекту, насколько не нужны за его пределами. А ну-как корабль называется "Титаник" - что, вместе сним тонуть будете, если у конторы сменится руководство и(или) финансирование?
Stan88
28.03.2022 12:16Приростание к подобным старым, Legacy, 30 летним мохнатым проектам давольно частое явление. Тут глупо спорить. Предыдущий специалист проработатл тут 7 лет. Я в большей степени embedder, а не кодер. Поэтому у меня намного важнее разбираться с аппаратной реализацией, прикладным программированием, инженерными задачами, чем с новым языком или фреймом. Да и в нашей стези все очень консервативно и меняется давольно редко. Я же говорю, что будет потребность - сяду, изучу, разберусь с тем что более актуально и востребовано. Мой опыт в этой сфере от этого не изменится.
Это специфическое оборудование занимает львиную долю рынка США и крупную часть Азии. Проект живет и развивается еще с времен мейнфреймов и загибаться не планирует. И могу Вас заверить, что на текущий момент я единственный человек кто разбирается в этом проекте. Что бы меня заменить потребуется примерно год времени. И уже наконец то взяли еще одного человека на проект, чтоб как то минимизировать потери и риски в таком случае. Все это понимают, но вот так сложилась ситуация.
Koval97
28.03.2022 19:09Ух ты, да у вас там сам Бог велел провести полномасштабный рефакторинг. Представляю сколько исписано листов тетрадей, чтобы это как-то задокументировать, сколько пришлось рисовать схем и диаграмм, чтобы кто-то еще смог это понять, и сколько приходится выискивать, чтобы понять где кончается творчество предыдущих разработчиков, а где просто заимствовали или интегрировали готовое решение.
Как инженер инженера понимаю, насколько это важная работа, которую некоторые адепты с Хабра пытаются всеми силами в упор игнорировать.
Stan88
29.03.2022 00:30Я аж прослезился!) Но все именно так. Есть и такие проекты, и их кто-то должен сапортить и рефакторить. И тут речь не об одном годе работы. И тут очень большие объемы работы и прибыли на кону. Далеко не каждый сможет концентрироваться над одной и той же задачей месяц, написать кучу фиксов, кучу инструментов просмотра сообщений между устройствами и графических тулзов - что бы в итоге прийти к решению в один бит!!! Бит, а даже не байт. Который в итоге решит с десяток тасок, отменит кучу прежних фиксов и добавит кардинальное описание в документацию. Далеко не каждый синьор готов к такой работе. На этот проект пробовали взять многих - после месяца все уходили. Иногда важен и аналитический подход, и опыт инженера, и способность концентрации и специфические методы программирования, где весомую роль может играть один бит.
Koval97
29.03.2022 20:30Далеко не каждый синьор готов к такой работе. На этот проект пробовали взять многих - после месяца все уходили.
А были ли другие причины, почему люди уходили? По моему всё что вы перечислили не сложнее толковой магистратской работы. Исследование функциональности, выявление связей между устройства, построение системной карты - это всё высокоуровневый дизайн. Если нет исходного кода, то почему не обратиться к дизассемблированию и интерпретаторам на С, где уже с анализом исходного кода для документирования работать будет проще? Как бы такие вещи первыми приходят на ум, когда речь идёт об анализе чего-то уже давно не обновляющегося.
Stan88
30.03.2022 00:35Причины почему уходили люди очень просты. Есть программисты, а есть инженеры-программисты. Кто бы там что мне не говорил. И вот с последними очень большая проблема. И не только в IT - не первый год наблюдаю как за инженерами идет настоящая охота.
Еще одна причина - сам проект. Люди понимают порог вхождения и не хотят тратить столько времени на это. Я в общем то все именно так и делаю как вы описали. Вопрос лишь в том что там километровые простыни кода и порядка 50 самописных библиотек. И вроде бы ты анализируешь все и документируешь, но не зная логики работы ты полагаешься на то что есть. А оно то как раз то и не работает. И ты кучу времени пытаешься понять почему не работает и как именно работать должно. Если бы задача была лишь в разборе рабочего устройства, а так все эти археологические раскопки нужно делать по ходу кучи самых разных тасок, которые нужно сделать как можно быстрее.
ПС: не совсем понял что такое магистратская работа. Если Вы имели ввиду магистерскую работу в университете, то могу лишь привести аналогию со своей - увы, но она ни имела ничего общего с реалиями жизни) Надеюсь что так это было только у меня, но что то сомневаюсь.
Elena_Fedorenko
28.03.2022 08:00автор статьи проработал в банке полтора года и претендует на сеньора? при этом не помнит(ежедневно НЕ применяет классические алгоритмы, но хвалится победой в каком-то громком конкурсе),остынь парень!
dimskiy
Вот скажите - к чему эти тайны, посему нельзя указать названия компаний? А то как эйчар из агентства «крупнейший российский банк, входящий в тройку…»
avovana7 Автор
Стремился я в Дойче. Тогда это был в моём сознание сияющим градом на холме.
gecube
Лучше в Райффайзен :-) Поговаривают в Альфа еще хорошо. Дойче в РФ кажется все.
Плюсисты нужны далеко не везде, преимущественно банковский софт на джава, но вот электронная торговля и все вокруг - вполне себе плюсы. Можете реализовать свой потенциал.
На самом деле у меня тоже есть детская травма из 90-х. Когда крутые админы работали или в highload, или в провайдерах, или в банках. И это тогда считалось круто. Но дорога туда мне была заказана. В любом случае свой гештальт я уже закрыл :-)
avovana7 Автор
И кем работаете сейчас? Какой стек? Как закрыли? :)
В альфе оклад меня не устроил, не собеседовался.
gecube
в личку
dimskiy
Смотря что вы понимаете под «хорошо». В красном банке рыночная зп (более-менее), но это все те же муторные процессы, согласования, встречи и скрам во имя скрама
SpiderEkb
Вот уж не знаю где как, но у нас в Альфе центральные сервера - IBM i (она же AS/400 в прошлом). Java есть, но на внешних системах. А большая часть бизнеслогики, что крутится на серверах, написана на RPG - язык для коммерческих расчетов преимущественно, почти с такими же древними корнями как COBOL, но развивающийся и в настоящее время вполне себе современный процедурный язык.
С/С++ тоже можно (поддерживается), но на нем пишутся всякие вспомогательные вещи, требующие низкоуровневого общения с системой. А бизнеслогику проще писать на RPG.
Разработчиков, котрые приходят со стороны, первым делом обучают специфике платформы (а она очень специфична) и языкам.
Ну и на следующий комментарий, чтобы два раза не вставать
Скрама во имя скрама не замечал. По крайней мере у нас (разработка центральных банковских систем). Тут вообще никакой лишней бюрократии, большинство вопросов решаются оперативно на уровне личных встреч.
Согласования документации по новым разработкам есть, но это неизбежное зло - архитектура системы слишком сложна и слишком объемна, а цена часа простоя, если что-то вдруг не впишется в общую архитектуру и начнет конфликтовать слишком высока. Поэтому любое новое решение тщательно анализируется на предмет совместимости и отсутствия конфликтов со всем уже существующим. Ну и плюс высокие требования по эффективности использования ресурсов - нагрузочное тестирование обязательно для любой мало-мальски объемной задачи. Поскольку на сервере одновременно крутится тысячи заданий и все они одинаково mission critical, то задача разработчика всегда в балансе между временем выполнения "его" задачи и тем количеством ресурсов, которое может быть ему выделено без превышения уровня загрузки сервера выше критического максимума в данном временном окне.
В целом - банки отдельная тема. Там все очень консервативно. Кого-то устраивает, кому-то просто поперек души все это.
Но в целом отношения в команде очень позитивные. Да и деньгами не обижают. Если чего-то стоишь, то доход будет расти. У меня лично за время работы (я лет без малого) выросло чуть более чем в три раза. 15-го марта вот был внеочередной пересмотр всем сотрудникам ДИТ (дирекция информационных технологий - IT подразделение Альфы). Причем, весьма ощутимый пересмотр. С 1-го апреля еще на 15% всем сотрудникам банка поднимают. В итоге даже в пересчете на валюту по курсу ощутимое повышение получилось.
gecube
спасибо за комментарий.
ну, это мертвому припарки в условиях полной турбулентности и вообще отсутствия ясных перспектив дальнейшей работы в РФ. Вот IBM санкционирует свои AS/400 и что? Будете по авито шариться и искать запчасти для этих мейнфреймов? Или срочно на Эльбрусы переходить? А ничего, что там ничего даже похожего нет?
Яндекс вроде тоже повышает, или Тинькоф, не помню, на 20%. И что толку? Если инфляция все равно все съест. Вы не поймите неправильно - я рад, что сотрудникам з/п поднимают, это реально хорошая антикризисная мера. Но в глобальной перспективе российское айти ничего хорошего все равно не ждет.
ща посчитаю свой доход. За 5 лет ( c 2017) рост в 10 раз (!). Если не учитывать курс.
sshikov
>Яндекс вроде тоже повышает, или Тинькоф, не помню, на 20%.
С бюджете Сбера повышение на этот год было запланировано еще где-то в ноябре что-ли. Но насчет «и толку» могу только согласиться. Потому что те же акции всех троих упомянутых упали до нуля, все что Яндекс ими платил — возможно не стоит нынче ни шиша (в любом случае, продать их прямо сейчас не выйдет никак). Удар по бизнесам множества банков и ИТ был огого, и 20% — это надо было прямо вот щас повысить, чтобы компенсировать провал за март. Где-то так. А потом еще много раз так же повторить.
SpiderEkb
В условиях турбулентности и всеобщей паники сложно говорить о каких-то "глобальных перспективах".
Ну и на все остальное разом.
Переход на новые платформы в такой консервативной сфере как банки малоосмысленен. Банк не может сказать своим клиентам - "подождите пару годиков, мы тут на новую платформу переход затеяли". Тут просто чтобы стоять на месте надо бежать очень быстро. Потому что и процессы нове появляются и требования (со стороны законодательства, регулятора) или меняются, или появляются новые.
К слову сказать, пример уже набивши оскомину в соответсвующих кругах - Банк Содружества Австралии и Океании повелся на желание молодых-горячих "перевести все с дремучего легаси на современный стек". Заняло это 5 лет (2012-17гг), обошлось банку в $750млн (американских, в родных австралийских - миллиард плюс-минус). Не считая стрессовых ситуаций когда в процессе перехода, к примеру, обнулилась вся кредиторская задолженность всех клиентов. А это кошмар всех и вся - восстановление с ленты и дальше в ручном режиме.
У нас вроде (информация неофициальная, так что за достоверность не ручаюсь) - Росбанк. "Мы сейчас тут все свое замутим с нуля". Так и не замутили. Побарахтались и бросили.
Так что золотое правило "не трогать работающее" тут соблюдается в полном объеме.
Да, развиваются "внешние системы" вокруг ядровых серверов. Насколько знаю (точной цифры нет, только порядок) - их несколько десятков разных. SAP, Pega, бог знает что еще. И да, нагрузка распределяется между ядровыми серверами и внешними системами.
Да, очень много работ ведется по оптимизации уже существующего. Тут много делает сопровождение - есть такой инструмент - PEX (Perfomance EXplorer) - постоянно собирается статистика, выявляются узкие места (порой в модулях очень старых), выносятся рекомендации, отправляются на доработку. Это я бы сказал основная составляющая техдолга.
Но в целом система живет и имеет неплохой потенциал и запас по производительности. Менять ее на что-то другое смысла не видно. В плане ядровых серверов уж точно.
Пилить фичи - это точно не к нам :-) Фичи пилят на фронтах. А это уже те самые "внешние системы". А к нам приходят уже когда нужно ту или иную фичу обеспечить функционалом на стороне ядра АБС (Автоматизированной Банковской Системы). Это на уровне "к вам по такому-то каналу будет приходить такой-то запрос, нужно в такой-то канал на него дать такой-то ответ".
Честно говоря, очень странно слышать такие заявления. Нет, было бы нормально от джуна, который освоил 2-3 модных фреймворка и хочет свои умения максимально монетизировать.
Я до банка вообще работал в области промавтоматизации. Занимался разработкой системы мониторинга инженерного оборудования зданий. И проблемы всегда были не на уровне языка или платформы, а более глубокие - разработка помехоусотойчивого протокола, позволяющего получать максимальную плотность передачи информации по медленным каналам связи (например, 1.5км линия RS485 на скорости 57.6 кбод). Или общая архитектура распределенной гетерогенной системы на микроядерной архитектуре... Как в такой системе обеспечить гарантированность доставки и 100% сохранность информации при любых мыслимых аварийных ситуациях...
Многое из того опыта и сейчас помогает (хотя радикально другая сфера). Вот не далее как сегодня полтора часа штормили на тему развития некоторых процессов - от построения батчмашин для распараллеливания обработки больших объемов данных до построения единного сервиса межпроцессного обмена данными как гомогенного (когда источник и получатель в одой среде работают), так и гетерогенного (источник и получатель работают в разных средах). И все это с максимальным уровнем эффективности, устойчивости, масштабируемости и сопровождаемости.
Конкретная платформа, язык и инструменты тут уже отходят на второй план. Конкретика реализации. Главное - изначально выбрать правильную идеологию. Транспортный уровень, протокольный, прикладной. Уровни изоляции. Что доступно конечному разработчику, что скрыто от него. Уровни логирования. Алгоритмы действий во внештатных ситуациях. И много чего еще.
Тут уже очень много архитектуры. Может быть даже больше чем собственно кодирования.
Рисовать формочки в конкретных фреймворках и складывать цифирьки мне перестало быть интересно лет 20 назад. И примерно столько же я не пишу код по ТЗ в стиле "если А=0, то Б = В + Д, иначе Б = Е - К".
Так что если не банк, то что-то другое себе найду без проблем. Пусть и в другой области.
А чего нет-то? Система показала неплохую производительность, надежность, устойчивость и сопровождаемость. В мире эту платформу достаточно много ее используют в банковской и смежных сферах. Да, весьма специфична, да достаточно узконаправленна, но здесь она вполне справляется и смысла менять ее на что-то иное не видно.
Тем более, что, как уже написал выше, на этой системе работает только собственно ядро АБС. А вокруг еще огромное количество разнородных внешних систем.
В среднесрочной перспективе каких-либо угроз в связи с текущей обстановкой не просматривается, а дальше все может или откатится и скатиться туда, где все это вообще не нужно будет. Сейчас нет возможности делать долгосрочные прогнозы.
avovana7 Автор
(я лет без малого)имелось ввиду 5 лет?Как боретесь с тех долгом? Есть технологические трансформации - когда на уровне руководства поднимается вопрос об усовершенствование платформ, перехода на новые. Всё это вписывается в планы ближайших лет и постепенно реализуется командами. Такая работа с техдолгом на уровне систем.
Здесь нужно обоснование бизнесу почему сейчас не фичи будем пилить, а какие-то трансформации делать, которые уменьшат время отклика, увеличат конверсию, помогут оторваться от конкурентов т.п. Причём не в моменте, а в ближайшей перспективе.
sshikov
>Вот уж не знаю где как, но у нас в Альфе
А теперь найдите еще один банк, где так же. Все подобные технологии, не очень широко распространенные, чреваты тем, что вы потом замучаетесь искать другое место, если вдруг что.
lair
Все еще? Я, кажется, лет 15 назад участвовал во внедрении там одного продукта для этой инфраструктуры, вот уж не думал, что оно так долго там задержится.
sshikov
>Лучше в Райффайзен :-)
Почему лучше? В то далекое уже время, когда я делал проект с ними, за два года на стороне заказчика сменилось два состава команды, включая всех уровня архитектора. Ну правда, Дойче в РФ кажется реально все, и если сравнивать с ними — то конечно лучше.
dimskiy
Ну, деньги у ребят есть, факт. Но это же банк :) Квинтэссенция пота и крови энтерпрайза
avovana7 Автор
Да. Я первый раз работал в кровавом энтерпрайзе. Теперь понимаю наполнение этого словосочетания. Со своими плюсами и минусами. Конечно, в каждой компании, отделе, даже команде всё немножко по-своему.