12 лет назад я считал себя сеньором с 8 годами опыта. Сейчас я понимаю, что был в лучшем случае продвинутым мидлом. И я бы себя не взял на синьора в компанию где я работаю :)
Именно поэтому надо тратить время на подготовку интервьюверов. Буквально вчера мы внутри обсуждали как и зачем проводим архитектурную секцию у себя. По сути согласовывали майндсет интервьюверов.
Лично я считаю что подготовка к архитектурному интервью это некая форма обучения интервьюверов правильным практикам разработки-проектирования, и это полезно не только для проведения собеседований.
Некоторые компании пишут даже текст для кандидата (чтобы он понимал что будет)
Не понимаю почему вы сделали вывод что я не люблю алгоритмы. Я отношусь к ним нейтрально и воспринимаю как рабочий инструмент. Прямо сейчас я даю алгоритмические задачи в упрощенном виде. Но я не вижу смысла давать алгоритмы на обход графа или сложный поиск в тексте.
Я согласен что есть положительная корреляция между участием в "олимпиадах" и умением писать код. Но я в свою очередь видел большой число "олипиадников", которые не умели писать продакшен код. Возможно это связано с тем, что я работал в компании куда брали любителей алгоритмических задач.
Спасибо что поделились опытом и цифрами. По моей памяти мы нанимали 5% от входного потока. Очень много инженеров были не способны пройти наше собеседование.
Сейчас я строю найм инженеров на новом месте и тут у нас все сильно лучше. Мы уже не пытаемся нанимать "олимпиадников". Но все равно - много людей не понимает что они делают.
Я подготовил задачи на ревью кода и оказывается в индустрии очень слабо с пониманием что такое код ревью. Что уж говорить про написание простого прохода по массиву. В общем попробую как-нибудь про это все написать с примерами задач и решений кандидатов.
Проблема не в том что сбежит, проблема в том что придется увольнять. Обычно компания не хочет иметь плохую репутацию на рынке труда из-за постоянного увольнения людей.
Про это я писал в первом разделе - Интерлюдия. Но тут есть повышенные риски со стороны кандидата - увольнение на испытательном сроке. Не все работодатели готовы соглашаться на такой риск.
Совместная беседа двух людей по поводу вакансии и работы обычно происходит после подтверждения технических навыков. Иногда это совмещается с техническим интервью. Акцент в моей публикации был на оценке со стороны работодателя.
не совсем понятно, как поток программистов с плачевными результатами смог привести к успеху
Для начало надо понять что такое успех. По моему мнению тут можно оценивать успех как рост сервисов компании, акций компании и компенсаций сотрудников. Тут все это было в течении 3 лет.
Далее я писал что причин успеха было множество. Я обратил внимание на устранение бардака и фокусировке на правильной культуре. По сути в компании оставались-нанимались люди с похожим майндсетом, что снижало затраты на коммуникацию.
При этом плачевный результат был поначалу, в дальнейшем люди научились и нашли другие способы решения проблем. Давайте я поправлю в тексте так:
В первое время эффективность и результат их работы были плачевными.
Проблема не в легаси, а в кривой обучения. Когда пишешь сам с нуля, то постепенно понимаешь что и как. А вот с легаси надо сразу охватить кучу вещей, про которые знает только прошлый автор. Еще хуже, когда нельзя улучшать чужой легаси код, и тебя заставляют писать плохо всегда.
Обычно я офер показываю из вежливости, когда 99% уже собрался уходить. Причем не обязательно, что это будет компания из офера +) Мне кажется, что отношения построенные на шантаже, не стоят моего времени. Ведь начальство будет помнить про этот шантаж, и тут как раз «остановка карьеры» случается.
Ну а если меня отправляют за офером в другую компанию, то это точно намек на поиск другого места работы. Кстати меня не разу не посылали таким образом +)
Взрывной рост зарплат испортил айти. Без него было бы проще. Но имеем то, что имеем. Опять же, можно позволить себе ипотеку даже без богатых родителей.
В итоге сейчас есть две касты наемного персонала. Первые типичные наемники и меняют работу за любую интересную прибавку. Вторые готовы почти на все, ради своего интереса в работе. И не надо подводить все советы под обе эти касты, кесарю кесарево.
Про первых я ничего не скажу. А вот по поводу вторых, не работает у них нормально подход — пообещал-повысили. Человек должен сразу мочь и хотеть делать больше. К примеру у меня была одна история из жизни. Пришел я ко второму своему клевому начальнику, и сказал что год-прошел-инфляция-мое-понимание-бизнес-процессов-выросло-да-и-вообще-я-ого-го. А он мне на 3% всего прибавку дал. Я конечно обиделся, но тут подвернулся клевый проект, и я в нем погряз, забыв про обиды-деньги. В общем мне через два месяца дали премию в размере зряплаты. И потом стали так каждый квартал делать. То есть если бы я просто не попросил без всякий непонятных обещайний стать-лучше/взять-больше, то мне бы и не дали скорее всего. У айтишников очень плохо с чтением мыслей. Надо уметь говорить честно, когда что-то не нравится. И не надо при рассказывать небылицы и обещать всякую ересь. Можешь делай сразу!
Да и трясти офером перед начальством это тоже гнилая затея. Сколько раз такой шантаж будет работать? Почему офер от другой компании должен быть объективен? Может у меня там друг нарисовал на бумажке удобные цифры? Но вот ходить на собеседования полезно, понимаешь рынок и себя при этом. Обретаешь уверенность/наглость просить больше. Ну а если не дадут, то значит тебя и не ценят в этой компании. А если не ценят, то значит твоя работа особо никому не нужна. Может быть причина в том, что не нужен твой опыт, для такой работы. Есть правило: не повысили за год — ты возможно не нужен (работай над собой или уходи), повысили в рамках инфляции — ты нужен (может быть это потолок уже, или ты недостаточно хорош), повысили больше чем на уровень инфляции — ты очень нужен (надо продолжать жечь в том же духе).
Резюме — будь полезен, работай над собой и не шантажируй начальство. Умей честно говорить о проблемах и немного ждать. Если дело швах, то уходи.
К слову сказать, это уже контрактная модель производства. Но работающая на базе принятия в штат. И не повышение зарплаты, есть сигнал, что твой опыт тут больше ненужен. Многие это понимают, и благодаря опыту и связям сразу работают контрактниками по временным договорам. Может быть действительно, не стоит изображать девочку, и принять что программисты пишущие новый софт, это контрактники на временных договорах?
p/s ну а если после ухода, в старой компании появляется вакансия +xx% к окладу, то это намек, что нужен другой человек. А не закостенелый страрожила рабочего места.
На первой работе вырос в зарплате в 5 раз, правда пришел стажером, ушел ведущим. На второй в 2 раза, там лояльность сильно оплачивалась из премиального фонда. Потом переехал в Питер, и увидел, что тут совсем все не так. И для повышения надо менять работу. То есть таким способом бизнес создает универсальные винтики. Человек знает всего понемногу и быстро учится новому. И эта экспертиза важнее знания постоянно меняющегося бизнеса. И вот это меня угнетает, я не хочу менять работу. Но семья требует денег.
Во первых уместно, надо уметь сказать что иногда подходы к масштабированию не нужны. Во вторых, вы умеете без переписывания кода любое продакшен решение развернуть на двух томкетах с мемкешем сессий? Все равно нужна фаза анализа и подготовки кода.
Иногда дешевле, иногда дороже, все зависит от ситуации. А кстати репликацию настраивать не надо? И собирать отвалившиеся не надо, все само работает? Вы правда верите что без приглядывания это всегда будет работать? И вы тчоно уверены, что тот кто нос воротит от эскуэль процедур, нормально пишет java код? Язык имеет настолько большое значение? Юнит тесты прекрасно пишутся, миграция тоже возможна при помоши уже почти стандартных подходов (например в рамках java: flyway, liquibase).
И пожалуйста не путайте героическое преодолевание трудностей, с решениями созданными для высокой нагрузки. Я не против двух-томкетов, ноуэскуля, или другой фигни. Но где в вашем опусе мысль, что надо проанализировать ситуацию, прежде чем принимать решения. Тем более если вы претендуете на сеньора, то вы должны не просто предлагать что-то, но объяснять почему вы это предлагает, и чем это грозит.
> В: Допустим, у вас есть приложение (самое обычное — JSP, Spring, Hibernate например) развернутое на томкате (Apache Tomcat) и вы однажды замечаете что сервер с томкатом загружен на 80% в среднем. Что делать?
В первую очередь понять, почему мы загружены на 80%. Побенчмаркать цифры на реальном продакшене. А после этого предлагать решения. И кстати не факт, что два томкета будут быстрее. Вдруг проблема в БД. Или даже приложение написано так, что не может быть развернуто на двух томкетах. В общем в первую очередь понять почему, что можно с этим сделать, и сколько это будет стоить (в том числе последствия).
> В: Но как же пользователь будет заходить на ваши несколько серверов?
Про это надо было сразу сказать, когда описывалась «архитектура с двумя томкетами». Картинку там нарисовать от руки. Странный вопрос.
> В: Но ведь может получиться что пользователь залогиниться на одном томкате, а следующий запрос load-balancer пошлёт на другой, где пользователь не залогинен!
А собственно почему сразу про липкие сессии? Разве не надо рассказать, что при этом будет для начала? Что сессия живет по умолчанию только на одном томкете. Хотя опять же про это можно сразу рассказать в «архитектура с двумя томкетами». И самое главное, почему вы не говорите про то, что можно не хранить в сессии ничего. А поднимать все сессионные данные из внешнего хранилища (мемкеш или бд какая).
> В: А если этот конкретный сервер упадёт?
Ну упадет сервер, да и ладно. Но если вы храните в сессии толстые объекты, то не факт что кеш вас спасет. Сериализация не для всех работает из коробки. Вот вы всегда проверяете что объект может быть сериализован, когда пишете приложение? А если это объект из сторонней скомпилированной библиотеки?
> В: Какие ещё преимущества у кэша для сессий?
А где самый главный вопрос про недостатки? По мне, так преимуществ от кеша сессий почти нет, лишь лишняя сущность для понимания работы системы. И вы точно уверенны, что стратегия бета-тестирования имеет прямое отношение к преимуществам кеша сессий?
> В: Хорошо, теперь у нас узким местом становится база. Что мы будем делать при возрастании нагрузки на неё?
Почему все время архитектурные решения? Вы боитесь читать код? Вот почему бы не проанализировать построение запросов? Да, кеш хибернейта сделать чуть лучше, но ведь есть еще и фетчи связанных данных (на случай если все лениво инициализированно). Может быть слой хранения мигрировать c hibernate на jdbc? В общем, в первую очередь надо понять какую проблему мы имеем, как ее можно решить, и сколько это будет стоить.
> В: А какие есть другие пути? Какие решения на уровне самой базы данных?
А как же хранимые процедуры, прекомпиленные вью, временные таблицы, ну или наконец банальные индексы? Почему мы сразу в бой? Ведь расфигачивание БД по разным машинкам это всегда дорого.
p/s надо не боятся читать и понимать код, а также иметь представление к чему приведет его выполнение. А все эти шардирования-кеши-ноэскуэли-архитектуры, придуманы маркетоидами, и перед их использование надо хорошо подумать. Раз семь, минимум!
Я имел ввиду, что ничего не меняется с точки зрения компаний и рынка. Нельзя некоторых людей исправить, надо лишь дождаться пока они вымрут. Вот про это я хотел намекнуть.
p/s То что меняется восприятие продавца себя это априори. Как я уже намекал выше, я имел опыт с некоторыми компаниями. В том числе имел опыт манипуляции эмоциями, через угрозы жизни.
Ничего не меняется, я тоже так собеседуюсь, ибо терпеть не могу менять работу по случайности какой. Но все равно есть компании, которым не понимают зачем я задаю им свои вопросы.
Пара компаний меня больше месяца мариновали так, я все понимал, и только ради опыта продолжал с ними общение (чтобы отсекать потом таких сразу).
Ну организовать раздолбайство это тоже не просто, чтобы оно жило и особо не вредило :)
Мне кажется плохо разделять время и усилия. Хождение на встречи это усилие, особенно для интровертов/социопатов. Еще плохо делить, потому что время и усилия взаимосвязанны. Одно без другого не бывает. Вот их соотношение может меняться, но стоит ли оценивать это? Не стоит ли оценку этого соотношения вынести в отдельную активность?
12 лет назад я считал себя сеньором с 8 годами опыта. Сейчас я понимаю, что был в лучшем случае продвинутым мидлом. И я бы себя не взял на синьора в компанию где я работаю :)
Именно поэтому надо тратить время на подготовку интервьюверов. Буквально вчера мы внутри обсуждали как и зачем проводим архитектурную секцию у себя. По сути согласовывали майндсет интервьюверов.
Лично я считаю что подготовка к архитектурному интервью это некая форма обучения интервьюверов правильным практикам разработки-проектирования, и это полезно не только для проведения собеседований.
Некоторые компании пишут даже текст для кандидата (чтобы он понимал что будет)
https://www.tinkoff.ru/career/it/interview/backend/
https://yandex.ru/jobs/pages/dev_interview
Не понимаю почему вы сделали вывод что я не люблю алгоритмы. Я отношусь к ним нейтрально и воспринимаю как рабочий инструмент. Прямо сейчас я даю алгоритмические задачи в упрощенном виде. Но я не вижу смысла давать алгоритмы на обход графа или сложный поиск в тексте.
Я согласен что есть положительная корреляция между участием в "олимпиадах" и умением писать код. Но я в свою очередь видел большой число "олипиадников", которые не умели писать продакшен код. Возможно это связано с тем, что я работал в компании куда брали любителей алгоритмических задач.
Спасибо что поделились опытом и цифрами. По моей памяти мы нанимали 5% от входного потока. Очень много инженеров были не способны пройти наше собеседование.
Сейчас я строю найм инженеров на новом месте и тут у нас все сильно лучше. Мы уже не пытаемся нанимать "олимпиадников". Но все равно - много людей не понимает что они делают.
Я подготовил задачи на ревью кода и оказывается в индустрии очень слабо с пониманием что такое код ревью. Что уж говорить про написание простого прохода по массиву. В общем попробую как-нибудь про это все написать с примерами задач и решений кандидатов.
Проблема не в том что сбежит, проблема в том что придется увольнять. Обычно компания не хочет иметь плохую репутацию на рынке труда из-за постоянного увольнения людей.
Про это я писал в первом разделе - Интерлюдия. Но тут есть повышенные риски со стороны кандидата - увольнение на испытательном сроке. Не все работодатели готовы соглашаться на такой риск.
Совместная беседа двух людей по поводу вакансии и работы обычно происходит после подтверждения технических навыков. Иногда это совмещается с техническим интервью. Акцент в моей публикации был на оценке со стороны работодателя.
Для начало надо понять что такое успех. По моему мнению тут можно оценивать успех как рост сервисов компании, акций компании и компенсаций сотрудников. Тут все это было в течении 3 лет.
Далее я писал что причин успеха было множество. Я обратил внимание на устранение бардака и фокусировке на правильной культуре. По сути в компании оставались-нанимались люди с похожим майндсетом, что снижало затраты на коммуникацию.
При этом плачевный результат был поначалу, в дальнейшем люди научились и нашли другие способы решения проблем. Давайте я поправлю в тексте так:
Ну а если меня отправляют за офером в другую компанию, то это точно намек на поиск другого места работы. Кстати меня не разу не посылали таким образом +)
В итоге сейчас есть две касты наемного персонала. Первые типичные наемники и меняют работу за любую интересную прибавку. Вторые готовы почти на все, ради своего интереса в работе. И не надо подводить все советы под обе эти касты, кесарю кесарево.
Про первых я ничего не скажу. А вот по поводу вторых, не работает у них нормально подход — пообещал-повысили. Человек должен сразу мочь и хотеть делать больше. К примеру у меня была одна история из жизни. Пришел я ко второму своему клевому начальнику, и сказал что год-прошел-инфляция-мое-понимание-бизнес-процессов-выросло-да-и-вообще-я-ого-го. А он мне на 3% всего прибавку дал. Я конечно обиделся, но тут подвернулся клевый проект, и я в нем погряз, забыв про обиды-деньги. В общем мне через два месяца дали премию в размере зряплаты. И потом стали так каждый квартал делать. То есть если бы я просто не попросил без всякий непонятных обещайний стать-лучше/взять-больше, то мне бы и не дали скорее всего. У айтишников очень плохо с чтением мыслей. Надо уметь говорить честно, когда что-то не нравится. И не надо при рассказывать небылицы и обещать всякую ересь. Можешь делай сразу!
Да и трясти офером перед начальством это тоже гнилая затея. Сколько раз такой шантаж будет работать? Почему офер от другой компании должен быть объективен? Может у меня там друг нарисовал на бумажке удобные цифры? Но вот ходить на собеседования полезно, понимаешь рынок и себя при этом. Обретаешь уверенность/наглость просить больше. Ну а если не дадут, то значит тебя и не ценят в этой компании. А если не ценят, то значит твоя работа особо никому не нужна. Может быть причина в том, что не нужен твой опыт, для такой работы. Есть правило: не повысили за год — ты возможно не нужен (работай над собой или уходи), повысили в рамках инфляции — ты нужен (может быть это потолок уже, или ты недостаточно хорош), повысили больше чем на уровень инфляции — ты очень нужен (надо продолжать жечь в том же духе).
Резюме — будь полезен, работай над собой и не шантажируй начальство. Умей честно говорить о проблемах и немного ждать. Если дело швах, то уходи.
p/s ну а если после ухода, в старой компании появляется вакансия +xx% к окладу, то это намек, что нужен другой человек. А не закостенелый страрожила рабочего места.
Иногда дешевле, иногда дороже, все зависит от ситуации. А кстати репликацию настраивать не надо? И собирать отвалившиеся не надо, все само работает? Вы правда верите что без приглядывания это всегда будет работать? И вы тчоно уверены, что тот кто нос воротит от эскуэль процедур, нормально пишет java код? Язык имеет настолько большое значение? Юнит тесты прекрасно пишутся, миграция тоже возможна при помоши уже почти стандартных подходов (например в рамках java: flyway, liquibase).
И пожалуйста не путайте героическое преодолевание трудностей, с решениями созданными для высокой нагрузки. Я не против двух-томкетов, ноуэскуля, или другой фигни. Но где в вашем опусе мысль, что надо проанализировать ситуацию, прежде чем принимать решения. Тем более если вы претендуете на сеньора, то вы должны не просто предлагать что-то, но объяснять почему вы это предлагает, и чем это грозит.
В первую очередь понять, почему мы загружены на 80%. Побенчмаркать цифры на реальном продакшене. А после этого предлагать решения. И кстати не факт, что два томкета будут быстрее. Вдруг проблема в БД. Или даже приложение написано так, что не может быть развернуто на двух томкетах. В общем в первую очередь понять почему, что можно с этим сделать, и сколько это будет стоить (в том числе последствия).
> В: Но как же пользователь будет заходить на ваши несколько серверов?
Про это надо было сразу сказать, когда описывалась «архитектура с двумя томкетами». Картинку там нарисовать от руки. Странный вопрос.
> В: Но ведь может получиться что пользователь залогиниться на одном томкате, а следующий запрос load-balancer пошлёт на другой, где пользователь не залогинен!
А собственно почему сразу про липкие сессии? Разве не надо рассказать, что при этом будет для начала? Что сессия живет по умолчанию только на одном томкете. Хотя опять же про это можно сразу рассказать в «архитектура с двумя томкетами». И самое главное, почему вы не говорите про то, что можно не хранить в сессии ничего. А поднимать все сессионные данные из внешнего хранилища (мемкеш или бд какая).
> В: А если этот конкретный сервер упадёт?
Ну упадет сервер, да и ладно. Но если вы храните в сессии толстые объекты, то не факт что кеш вас спасет. Сериализация не для всех работает из коробки. Вот вы всегда проверяете что объект может быть сериализован, когда пишете приложение? А если это объект из сторонней скомпилированной библиотеки?
> В: Какие ещё преимущества у кэша для сессий?
А где самый главный вопрос про недостатки? По мне, так преимуществ от кеша сессий почти нет, лишь лишняя сущность для понимания работы системы. И вы точно уверенны, что стратегия бета-тестирования имеет прямое отношение к преимуществам кеша сессий?
> В: Хорошо, теперь у нас узким местом становится база. Что мы будем делать при возрастании нагрузки на неё?
Почему все время архитектурные решения? Вы боитесь читать код? Вот почему бы не проанализировать построение запросов? Да, кеш хибернейта сделать чуть лучше, но ведь есть еще и фетчи связанных данных (на случай если все лениво инициализированно). Может быть слой хранения мигрировать c hibernate на jdbc? В общем, в первую очередь надо понять какую проблему мы имеем, как ее можно решить, и сколько это будет стоить.
> В: А какие есть другие пути? Какие решения на уровне самой базы данных?
А как же хранимые процедуры, прекомпиленные вью, временные таблицы, ну или наконец банальные индексы? Почему мы сразу в бой? Ведь расфигачивание БД по разным машинкам это всегда дорого.
p/s надо не боятся читать и понимать код, а также иметь представление к чему приведет его выполнение. А все эти шардирования-кеши-ноэскуэли-архитектуры, придуманы маркетоидами, и перед их использование надо хорошо подумать. Раз семь, минимум!
p/s То что меняется восприятие продавца себя это априори. Как я уже намекал выше, я имел опыт с некоторыми компаниями. В том числе имел опыт манипуляции эмоциями, через угрозы жизни.
Пара компаний меня больше месяца мариновали так, я все понимал, и только ради опыта продолжал с ними общение (чтобы отсекать потом таких сразу).
Мне кажется плохо разделять время и усилия. Хождение на встречи это усилие, особенно для интровертов/социопатов. Еще плохо делить, потому что время и усилия взаимосвязанны. Одно без другого не бывает. Вот их соотношение может меняться, но стоит ли оценивать это? Не стоит ли оценку этого соотношения вынести в отдельную активность?