Спасибо за совет, но знания-то у меня есть..

А чем вуз мешает? Да и вопрос с армией на следующие 3 года решен, получается

Так делайте pet проекты, изучайте технологии. Пока вы не закончили вуз и не решили вопрос с армией, на фуллтайм кандидатура довольно спорная.

Можете не продолжать писать, закончим диалог, мне ваша позиция не по душе совсем, но спасибо за желание помочь

Так а чем вам не нравится ответ выше? Тем что он не соответствует вашим ожиданиям?

Я проходил с накрученным резюме в вб собес. меня, как уверенного мидла оценили А я готов у них со своим реальным резюме(тем, что выше) хоть как джун работать, за зп ниже, а ВООБЩЕ все игнорят

так а в чем проблема была пойти в вб?) оценили как мидла, но офер не дали?

Да, а то, как минимум, жить на что, пока я с пет проектами играюсь

а если хочется столкнуться с техническими вызовами, то тут сильно профитнее идти в уже крупную компанию, которая продолжает активный рос. они уже нащупали какой-то успешный кейс, у них уже есть нагрузка\большие цифры в рпс и они как-раз дошли до этапа когда старая инфра перестает справляться из-за того что Х лет назад при проектировании никто на такую нагрузку не рассчитывал, т.к. бизнес был маленький у глупо было оверинженерить. там уже можно столкнуться с проблемами что перестает базы хватать, что сервис уже некуда маштабировать вверх и тд

А как же революция с gpt5?

есть ли у вас знание о компаниях \ либо командах, где есть такие сложные технические вызовы?

Ну я в озоне работал, причём в части, которая касается поставок товаров селлерами в озон. И там например нагрузка сильно меньше чем в основном озоне, но несмотря на это часто бывало куча чего-то интересного. Не обязательно это должна быть сложная инженерная задача, чтобы быть интересной, мне например сильно запомнилась одна из первых моих задач, если кратко, нам в кафку прилетал эвент, после этого наш сервис, через пару прослоек шёл в мастер систему, читал оттуда данные и сейвил их часть к нам в бд. И переодически к нам в бд почему-то попадали не актуальные данные. Я потратил примерно неделю на раскопки (большая часть ушла на общение с другими командами в попытках понять кто отвечает за мастер систему т. к. это была одна из легаси частей озона). В итоге дело оказалось в том, что мы через сервис фасад читали из асинк реплики, и приходили читать, мы как правило в течении 1мс после коммита в мастер. Т. Е. За 1 мс, сервис успевал отправить сообщение в кафку, мв его успевали прочитать, сделать вызов примерно через 3 сервиса прослойки до асинк реплики, и не всегда в неё успевали новые данные долететь. Для меня тогда это был необычный опыт, я не подозревал что Инфраструктура может быть настолько быстрой, поэтому и запомнилось. Или например были инциденты, когда при миграции вместо 200к сообщений нам налили 20кк, за короткое время, т. К. Бизнес требования поменялись и команда которая делала миграцию данных и должна была пролить сообщения в наш сервис, забыла нас предупредить. Мы тогда уперлись в скорость чтения базы с диска, тоже интересно было. Ну и в целом несмотря на то что мы не проектировании сервисы с тысячами рпс, было много интересных вызовов из разряда, а как сделать так чтобы все стабильно работало, а если что-то пошло не так, то мы об этом могли узнать бы от аллерта, а не от пользователей. Было много интересных задач на перепроектирование домена, т. К. я пришёл когда команда сильно пересобиралась и от старой почти никого не осталось и нам в наследство достался домен не в лучшем состоянии. У ребят из логистики насколько я знаю были интересные задачи и довольно неплохая нагрузка. (мы с ними взаимодействовали поэтому чуть в курсе про их внутрянку) Да в целом много где можно найти кучу интересных задач, необязательно это должен быть хайлоад или бигтех, сильнее влияет то как ты подходишь к решению задач, о чем ты думаешь при проектировании системы. Я вот до озона слабо задумывался о том как себя система в проде идёт, ну вроде юзеры не жалуются и норм. В этом плате опыт озона чуть перевернул представление и я осознал что на самом деле между юзеры не жалуются и "система работает заебись" есть огромная пропасть и в этой пропасти куча интересны задач. Да даже элементарно, а как написать логи так чтобы потом по ним можно было во время инцидента понять что происходит, когда сидишь на инциденте, смотришь на свои логи и понимаешь что они тебе говорят примерно нефига, а прод прилёг, то вдруг приходит осознание, что написать грамотные логи, которые будут сходу говорить тебе в чем дело и при этом там будет минимум мусора - это тоже скилл который надо качать. Жесть телегу я накатал крч. В целом, попробуй просто на свои текущие задачи "посмотреть в глубь", скорее всего там есть куча интересного, просто для меня именно озон выступил местом, где я научился это делать.

Ну я в озоне работал, причём в части, которая касается поставок товаров селлерами в озон. И там например нагрузка сильно меньше чем в основном озоне, но несмотря на это часто бывало куча чего-то интересного. Не обязательно это должна быть сложная инженерная задача, чтобы быть интересной, мне например сильно запомнилась одна из первых моих задач, если кратко, нам в кафку прилетал эвент, после этого наш сервис, через пару прослоек шёл в мастер систему, читал оттуда данные и сейвил их часть к нам в бд. И переодически к нам в бд почему-то попадали не актуальные данные. Я потратил примерно неделю на раскопки (большая часть ушла на общение с другими командами в попытках понять кто отвечает за мастер систему т. к. это была одна из легаси частей озона). В итоге дело оказалось в том, что мы через сервис фасад читали из асинк реплики, и приходили читать, мы как правило в течении 1мс после коммита в мастер. Т. Е. За 1 мс, сервис успевал отправить сообщение в кафку, мв его успевали прочитать, сделать вызов примерно через 3 сервиса прослойки до асинк реплики, и не всегда в неё успевали новые данные долететь. Для меня тогда это был необычный опыт, я не подозревал что Инфраструктура может быть настолько быстрой, поэтому и запомнилось. Или например были инциденты, когда при миграции вместо 200к сообщений нам налили 20кк, за короткое время, т. К. Бизнес требования поменялись и команда которая делала миграцию данных и должна была пролить сообщения в наш сервис, забыла нас предупредить. Мы тогда уперлись в скорость чтения базы с диска, тоже интересно было. Ну и в целом несмотря на то что мы не проектировании сервисы с тысячами рпс, было много интересных вызовов из разряда, а как сделать так чтобы все стабильно работало, а если что-то пошло не так, то мы об этом могли узнать бы от аллерта, а не от пользователей. Было много интересных задач на перепроектирование домена, т. К. я пришёл когда команда сильно пересобиралась и от старой почти никого не осталось и нам в наследство достался домен не в лучшем состоянии. У ребят из логистики насколько я знаю были интересные задачи и довольно неплохая нагрузка. (мы с ними взаимодействовали поэтому чуть в курсе про их внутрянку) Да в целом много где можно найти кучу интересных задач, необязательно это должен быть хайлоад или бигтех, сильнее влияет то как ты подходишь к решению задач, о чем ты думаешь при проектировании системы. Я вот до озона слабо задумывался о том как себя система в проде идёт, ну вроде юзеры не жалуются и норм. В этом плате опыт озона чуть перевернул представление и я осознал что на самом деле между юзеры не жалуются и "система работает заебись" есть огромная пропасть и в этой пропасти куча интересны задач. Да даже элементарно, а как написать логи так чтобы потом по ним можно было во время инцидента понять что происходит, когда сидишь на инциденте, смотришь на свои логи и понимаешь что они тебе говорят примерно нефига, а прод прилёг, то вдруг приходит осознание, что написать грамотные логи, которые будут сходу говорить тебе в чем дело и при этом там будет минимум мусора - это тоже скилл который надо качать. Жесть телегу я накатал крч. В целом, попробуй просто на свои текущие задачи "посмотреть в глубь", скорее всего там есть куча интересного, просто для меня именно озон выступил местом, где я научился это делать.

Пушто все на своих местах, если чел шарит, то он, условно, один делает фичу/либу/IaaS для всего Озона и все ею пользуются, улучшают. А не так, что наняли миллиард персонала в миллиард независимых команд, все делают примерно одно и то же, но одинаково плохо.

В розовом маркетплейсе у меня так и было :(

В какой команде? Розовый это вб?

Ну я в озоне работал, причём в части, которая касается поставок товаров селлерами в озон. И там например нагрузка сильно меньше чем в основном озоне, но несмотря на это часто бывало куча чего-то интересного. Не обязательно это должна быть сложная инженерная задача, чтобы быть интересной, мне например сильно запомнилась одна из первых моих задач, если кратко, нам в кафку прилетал эвент, после этого наш сервис, через пару прослоек шёл в мастер систему, читал оттуда данные и сейвил их часть к нам в бд. И переодически к нам в бд почему-то попадали не актуальные данные. Я потратил примерно неделю на раскопки (большая часть ушла на общение с другими командами в попытках понять кто отвечает за мастер систему т. к. это была одна из легаси частей озона). В итоге дело оказалось в том, что мы через сервис фасад читали из асинк реплики, и приходили читать, мы как правило в течении 1мс после коммита в мастер. Т. Е. За 1 мс, сервис успевал отправить сообщение в кафку, мв его успевали прочитать, сделать вызов примерно через 3 сервиса прослойки до асинк реплики, и не всегда в неё успевали новые данные долететь. Для меня тогда это был необычный опыт, я не подозревал что Инфраструктура может быть настолько быстрой, поэтому и запомнилось. Или например были инциденты, когда при миграции вместо 200к сообщений нам налили 20кк, за короткое время, т. К. Бизнес требования поменялись и команда которая делала миграцию данных и должна была пролить сообщения в наш сервис, забыла нас предупредить. Мы тогда уперлись в скорость чтения базы с диска, тоже интересно было. Ну и в целом несмотря на то что мы не проектировании сервисы с тысячами рпс, было много интересных вызовов из разряда, а как сделать так чтобы все стабильно работало, а если что-то пошло не так, то мы об этом могли узнать бы от аллерта, а не от пользователей. Было много интересных задач на перепроектирование домена, т. К. я пришёл когда команда сильно пересобиралась и от старой почти никого не осталось и нам в наследство достался домен не в лучшем состоянии. У ребят из логистики насколько я знаю были интересные задачи и довольно неплохая нагрузка. (мы с ними взаимодействовали поэтому чуть в курсе про их внутрянку) Да в целом много где можно найти кучу интересных задач, необязательно это должен быть хайлоад или бигтех, сильнее влияет то как ты подходишь к решению задач, о чем ты думаешь при проектировании системы. Я вот до озона слабо задумывался о том как себя система в проде идёт, ну вроде юзеры не жалуются и норм. В этом плате опыт озона чуть перевернул представление и я осознал что на самом деле между юзеры не жалуются и "система работает заебись" есть огромная пропасть и в этой пропасти куча интересны задач. Да даже элементарно, а как написать логи так чтобы потом по ним можно было во время инцидента понять что происходит, когда сидишь на инциденте, смотришь на свои логи и понимаешь что они тебе говорят примерно нефига, а прод прилёг, то вдруг приходит осознание, что написать грамотные логи, которые будут сходу говорить тебе в чем дело и при этом там будет минимум мусора - это тоже скилл который надо качать. Жесть телегу я накатал крч. В целом, попробуй просто на свои текущие задачи "посмотреть в глубь", скорее всего там есть куча интересного, просто для меня именно озон выступил местом, где я научился это делать.

Всего сообщения не читал 😁 но плюсую Озон. Остается моим самым лучшим опытом работы, занимался релиз инжинирингом 🎃

Потрясающе Спасибо огромное, вы так подробно написали и + с описанием кейсов «где надо подумать/исследовать» Ваш рассказ дал понимание о том как много может быть развивающих моментов. Мнение об Озон дополнилось Очень благодарен Возможно такие вызовы и в других бигтехах как Авито, WB

Мой пост скорее про то что такие вызовы могут быть где угодно, даже в маленькой компании, все дело в том, а какие вопросы ты сам перед собой ставишь. До озона ищ некоторых мест я уходил, т. к было скучно, сейчас я понимаю что там на самом деле была большая куча интересных задач, которые можно было бы на себя взять и которые я в тот момент или не замечал или не видел их глубины. Просто сам себе попробуй ответить, а что тебе интересно, сходи с этим своему лиду и обсуди с ним, а как можно что-то из этого поделать, скорее всего вы умеете найти что-то прикольное. Сейчас я работаю в небольшой команде, в которой нагрузка на все решение всего несколько рпс, да и домен не очень сложный (не сравнить с тем что у меня был в озоне) но при этом и здесь у меня есть как и интересные задачи, так и интересные инциденты, пусть они и не связаны с тем, что на нас неожиданно свалилась нагрузка в х100 от ожидаемой

Ну и мнение лучше всего составлять не о компании в целом а о конкретной команде. У меня есть примеры оч унылых команд в крутых компаниях, так и есть опыт работы о котором я могу говорить что компания не оч, но при этом команда у меня была 10 из 10 и я там с удовольствием работал

О, это слышал и это очень сложный вопрос: как же понять на собесе с командой, что там будет не уныло Разве что конкретно знать про такие-то команды уже заранее

Наверное только задав большое количество вопросов им на собеседовании

Поделитесь умными вопросами пожалуйста? Их надо так задать, чтобы сложно было скрыть ту самую унылость

Я бы спросил: 1. Какие технологии используете? 2. С какой нагрузкой работаете? Сколько пользователей/запросов в день? 3. Чем потенциально буду заниматься я? Какие проблемы сейчас стоят, которые предстоит решить? 4. Кто принимает архитектурные решения, будет ли у меня возможность участвовать в их принятии? 5. Чем сейчас занимаетесь больше, фиксами и поддержкой или больше разрабатываете новые фичи?

Я бы спросил: 1. Какие технологии используете? 2. С какой нагрузкой работаете? Сколько пользователей/запросов в день? 3. Чем потенциально буду заниматься я? Какие проблемы сейчас стоят, которые предстоит решить? 4. Кто принимает архитектурные решения, будет ли у меня возможность участвовать в их принятии? 5. Чем сейчас занимаетесь больше, фиксами и поддержкой или больше разрабатываете новые фичи?

Где похоронен предыдущий разработчик?

Про планы на будущее говорят обычно максимально расплывчато

Отсюда и тема: Как правильно задать эти вопросы. Возможно стоит добавить некоторых деталей, чтобы люди из команды что-то рассказали Хотя впрочем , если все расплывчато - уже можно понять, что к ним идти не надо

Все же во многих компаниях: Хоть и есть место творчеству, но оно объективно не нужно, Лид вполне может на это времени не выделить и будет прав Вы описали кейсы где была явная нужда разобраться и исследовать

Ну лиду нужно чтобы ты круто перформил, поэтому вписать что-то полезное и при этом интересное для тебя в бизнес задачи я думаю он будет не против (по моему опыту это так и работает, если не приходить конечно с набросок мол давай все перепишем, а например прийти с тем что тебе хочется качнуть я в архитектуру, и просто спросить как это можно сделать и что из архитектурный задач и в каком виде ты бы мог на себя взять.

О, это слышал и это очень сложный вопрос: как же понять на собесе с командой, что там будет не уныло Разве что конкретно знать про такие-то команды уже заранее

Я просто смотрю на впечатление от собеса и от тех кто его проводит. Ну а в целом испытательный срок, он не только для тебя, но и для компании, я для себя в первые 3 мес работы просто решаю хочу ли я работать в этой команде, т. К. Просто за собес ты никогда со 100% точностью никак не сможешь составить полное впечатление

Отсюда и тема: Как правильно задать эти вопросы. Возможно стоит добавить некоторых деталей, чтобы люди из команды что-то рассказали Хотя впрочем , если все расплывчато - уже можно понять, что к ним идти не надо

Да нет никаких правильных вопросов, точто также как и собеседующий незнает о чем тебя таком спросить, чтобы понять крутой ты тип или просто например статей в инете поначитался, а на практике знания применять не можешь =) Составь для себя свои личные критерии, по которым ты можешь понять конкретно для тебя команда топ или не топ, и исходя из них составь вопросы которые тебе помогут оценить их по этим критериям, люди разные, и там где я могу рассказывать что команда 10 из 10, для тебя она может быть вообще полный отстой, т. К. Линейка у каждого из нас своя. Можешь поспрашивать как построен процесс работы над задачами. Можешь про отношения в команде (из разряда есть ли неформальные взаимодействия) Можешь спросить как часто происходят инциденты или какой например был самый интересный за последнее время. Можешь спросить у собеседующего, какая лично для него была самая интересная задача за последние пол года. (ток не жди что он расскажет интересное что-то лично тебе, может он людей никогда не нанимал и для него самая интересная задача это закрыть позицию, т. К. Он с этим в первый раз например столкнулся) Или например когда в последний раз собирались пиво в пятницу пить. Крч, здесь можно что угодно спрашивать, серебряной пули не существует

Спасибо Ваш опыт - это бигтехи или вообще в целом?

эмоции - как интегральный показатель внутренних оценок - да, тоже хорошо. А насчет уйти с испыталки - вот не хотелось бы, думаю другие компании настороженно будут смотреть на запись в трудовой в 2 месяца

Вообще в целом, бигтехи это тоже не серебряная пуля, там тоже могут быть свои проблемы (например в озоне в нашей команде была бешеная потогонка, т. К. Было очень много бизнес задач и мы жили от метеорита к метеориту. Тот-же процесс ревью, тоже не особо интересный и удовольствия вообще не приносил (хотя на что его заменить в масштабах озона я хз если честно) Мало смысла искать идеальную компанию =)

Ну, ответ что за время испытательного понял что не подходите друг другу, более чем нормальный.

Да нет никаких правильных вопросов, точто также как и собеседующий незнает о чем тебя таком спросить, чтобы понять крутой ты тип или просто например статей в инете поначитался, а на практике знания применять не можешь =) Составь для себя свои личные критерии, по которым ты можешь понять конкретно для тебя команда топ или не топ, и исходя из них составь вопросы которые тебе помогут оценить их по этим критериям, люди разные, и там где я могу рассказывать что команда 10 из 10, для тебя она может быть вообще полный отстой, т. К. Линейка у каждого из нас своя. Можешь поспрашивать как построен процесс работы над задачами. Можешь про отношения в команде (из разряда есть ли неформальные взаимодействия) Можешь спросить как часто происходят инциденты или какой например был самый интересный за последнее время. Можешь спросить у собеседующего, какая лично для него была самая интересная задача за последние пол года. (ток не жди что он расскажет интересное что-то лично тебе, может он людей никогда не нанимал и для него самая интересная задача это закрыть позицию, т. К. Он с этим в первый раз например столкнулся) Или например когда в последний раз собирались пиво в пятницу пить. Крч, здесь можно что угодно спрашивать, серебряной пули не существует

бигтехи хотя бы хороши высокими нагрузка ми = необходимостью правильно проектировать, фиксить баги, а не и так сойдет

Бигтех бигтеху рознь и это очень сильно зависит от команды

по 10 часов в день пару раз в каждую неделю - такая потогонка? а code review конечно нужен, как же без него

В 2027+ появиться сверхразумный ии

Не, я не про код ревью, в больших компаниях раз в полгода идёт перформанс ревью, когда оценивают твою работу по определённому процессу, оценка влияет на повышение и премию. Можешь погуглить я думаю на то же хабре это все прекрасно расписано. Процесс не идеален, т. К. Если ты делаешь задачи которые не супер инженерные, но при этом приносят большое вейлю бизнесу, то будешь получать крутые оценки, ну и в такой парадигме кто-то обязательно должен получить плохие. Крч есть некоторая боль от процесса, но чем его заменить пока никто не придумал. А по поводу потогонка, скорее это 2-3 мес жёстких сроков и овертаймов, потом пару недель выдохнуть потом снова пачка метеоритов с жёстким сроками и нам надо понять как их успеть сделать. Но это была особенность нашей команды, такое не по всему озону, да и у нас в команде такое было в силу специфики, и через какое-то время стало полегче, но пол года примерно были вообще адскими

я больше о личном проф. росте интересовался, чем про perf review. А вот потогонка это конечно на любителя. Сроки спкучались сверху, команда не участвовала? А овертаймы фиксируются - и оплачиваются или просто люди работали по ночам за свой счет, вот интересно

Про проф рост - в целом такая потогонка даёт норм опыт, если хватает сил её переварить, ну и в целом получился крутой опыт на тему, а как жонглировать эпиками, и как при этом не пережечь команду в угли. По поводу сроков, в их формировании участвовал наш тимлид, но в целом так бывает, что бизнес прибивает сроки справа, это нормально. Овертаймы официально не оплачивались, но фиксировались тимлидом, и потом можно было уйти в счёт этого в отгул (который оплачивался, и просто достаточно было написать тимлид) Ну и вся команда после такого получила хорошие оценки на ревью, что вылилось в повышения грейдов и премии.

А как фиксировались овертаймы? Допустим Вася пишет тимлиду: сегодня я работал 10 часов и у него +2 часа идёт в запись? Если вся неделя так - получается за неделю будет 10 доп часов

В конце эпика тимлид приходил и спрашивал овертаймил ли ты и если да, то сколько. В целом все было на доверии

Ага, понятно А вы писали 2-3 месяца жестких сроков : получается овертаймы были каждую неделю в такие жёсткие месяцы? Хочется вообразить нагрузку

Да по разному, в зависимости от эпика, обычно овертацмы начинались ближе к концу, плюс разные части команды были на разных эпиках

молодому организм можно кодить по 12-16 часов в день на протяжении полугода вообще без последствий.

единственная причина работать сверхурочно это безделье (ноулайф, хобби и проч.). Впрягаться за тимлида или бизнес, которому всегда нужно быстро это деструктивное поведение

И важно помнить что тебя могут сократить и все твои потуги быть суперменом спасателем идут вместе с тобой нахуй😁

В конце эпика тимлид приходил и спрашивал овертаймил ли ты и если да, то сколько. В целом все было на доверии

Егор, хочу очень поблагодарить за столь развернутые и подробные ответы. Я сейчас в поиске работы и ваша информация для меня весьма актуальна и полезна. Была бы система репутации - хочется +3 поставить :)

— Кстати, чат Знаете ли по теме интересных задач в Бюро 1440 или в Ядро? по отзывам прочитал, что такие есть, однако без подробностей

Коротко Бюро - делать старлинк, интеренет через спутники Ядро - делать чебурнет

это я знаю, достаточно почитать интернет

хочу узнать о наличии там сложных технических вызовов

Много ты знаешь компаний которые делают спутниковый интернет? Или запускают спутники? Вопрос всегда в другом Что ты можешь дать команде?

единственная причина работать сверхурочно это безделье (ноулайф, хобби и проч.). Впрягаться за тимлида или бизнес, которому всегда нужно быстро это деструктивное поведение

впрягаться можно за бабло, за долю в бизнесе, за карьерный рост. в гугле в былые времена осыпали стоками перформящие команды.