+1. У нас (биг тех / продукт с десятизначным ревеню) рефакторинг делается перед тем как пишется фича, с конкретным обоснованием для чего. На код ревью например, если увидят трёхэтажные моки в тестах - тоже попросят отдельно отрефакторить сначала, чтобы любой джун разбуженный среди ночи понял что к чему. После того как код ушел в прод - никаких чисток чистоты ради.
Все правильно, тоже пришел к подобной схеме после годов мучений. Одно только смущает - только один разминочный подход в базовых упражнениях? Или это просто я старый и замученный травмами .. у меня 3-5 разминочных подходов, при сравнимых рабочих, иначе суставы и мышцы ругаются.
Интересно, не знал что мидвест настолько другой мир. На побережье (Бостон, Сиэтл, Калифорния, Нью Йорк), все по другому. Зарплаты большие, куча фаангов и контор попроще, но все могут платить норм, жизнь дорогущая. Интерншип у всех почти есть, один из лучших путей начать карьеру, вообще я бы сказал обязательно для любого кто в местных вузах учится. Правительственных контор мало, они не на слуху да и делать там нечего - ни денег толком, ни опыта, да и иммигрантом попасть сложно.
По поводу джунов проблема не "я Джун как мне быть на удалёнке" а "мы огромная компания у нас тыщи джунов как их всех научить". Так то да, полно видел джунов у кого никаких проблем с удаленной не было - но и обратных случаев много.
+100, если человек не хочет / не умеет работать - офис никак не поможет. Причины тенденции на возврат в офис понятны: 1/ налоговые послабления от городов где локации офисов 2/ чувство контроля для хреновых менеджеров, 3/ ещё проредить ряды сотрудников без громких сокращений, 4/ заставить сеньоров вживую подтягивать ленивых зато дешёвых джунов.
Наблюдаю щас в Амазоне, вроде как хайринг фриз, сокращения и все такое, а поток новых джунов не прекращается, и сильный прессинг со стороны менеджеров "ты сеньор тебе учить!". Нашли решение, эффективные наши ...
Например - в МААНГах не нужны ".NET разработчики" или "Java разработчики", а скорее бэкенд-девелоперы в целом, которые могут переучиться на то что будет нужно для решения конкретных проблем
Это ситуация с наймом в большие компании, где поток кандидатов в сотни тысяч человек в год, стандартизация итп. К тому же в МААНГах обычно нет такой привязки к языку/стеку, люди осваивают нужные технологии на ходу. А раньше вон вообще всякие Брейн тизеры давали, типа почему люки круглые, так что сейчас ещё нормально. Ну и всегда есть вариант пойти в компании поменьше/попроще, где будет важен именно ваш стек, коммиты в гитхаб итп.
Как резидента ФААНГа тоже волнует вопрос "куда дальше", и вот переход в области где "высокий порог вхождения в отличие от" итп вообще непонятен. Ну вот работал ты в ФААНГе, ни разу не в финансах и трейдинге, и тут хочешь устроится в HFT (больше денег богу денег!). Ну и на собеседовании они от тебя хотят кучи специфических вещей которых ты не работая в HFT не знаешь. Как раз таки с ФААНГами все понятно, литкод +книги/видео по систем дизайну + любой опыт разработки, не нужно никаких сакральных знаний и умений, или там 10 лет опыта в новейшем фреймворке и тысячи звездочек в гитхабе.
Специфики не хватило, что конкретно ценят в HFT чтобы разработчик без опыта в HFT мог войти в отрасль не джуном.
Так вроде ж стандартная схема в крупных продуктовых компаниях, по крайней мере в западных. Могут быть ротации по разным типам дежурств, или один на все как у автора. У нас в Амазоне в моей команде обычно совмещается с онколл дежурством, из отдела в 30-40 человек обычно дежурят 3, один пейджер держит и тикеты разгребает, другой больше на всякой рутине (скрипты, дашборды, ранбуки, доки), третий (самый сеньористый, зачастую тимлид или дев менеджер) руководит онколл сменой и ответственный за внешние контакты (вплоть до разговоров с заказчиком в случае инцидентов), все вместе занимаются выкатками. В разных отделах и компаниях свои нюансы, но в целом принцип дежурств очень часто применяется, по причинам описанным автором.
Если 5-6 секций - то да, отличный тип вопроса на проверку определенного типа навыков, в одной из секций, для отсеивания "чукча не читатель". Встречал и сам давал вне ФААНГов, в ФААНГах тоже бывает но редко.
А в других форматах собеседования все ещё веселее, "мне он не понравился, мутный какой то", "да он не знает аргументов функций стандартной либы" итп. Все остальные способы абсолютно так же подвержены человеческому фактору.
После США просто смешно читать про цены на медицину :) 100, 250... да, это типичная цена за скорую, если у вас хорошая страховка. Полная стоимость без страховки будет 2000+.
Хмм, а какой ещё рынок слился китайцам из-за "безликости" итп? Как раз таки от китайцев ни стиля ни оригинальности ждать не приходится, они другим всегда брали.
1) на собеседованиях в Г чаще можно встретить Литкод Хард чем например в Амазон
2) в Амазоне вопросы явно с Литкода брать не рекомендуется, но многим влом думать-искать
3) все проблемы которые были у меня в вопросах на интервью в Амазоне встретились впоследствии в реальной работе
4) непосредственно навык скоростного решения таких проблем - не нужен. Но нужно уметь быстро писать хороший и тестируемый код и быстро распознавать алгоритмические паттерны, чтобы не велосипедить и не плодить тормозной код.
На самом деле это только часть навыков software engineer, и эффективность принятого формата интервью - вопрос спорный, но... Как то работает, а лучшего способа не придумали. "Гитхаб" и "поговорить за проекты" для бигтеха очевидно не вариант.
Тут зависит от того как использовать литкод. Если тупо адаптироваться под систему и фигачить write only, тогда да, может и во вред пойти. А можно писать нормально, с юнит тестами ИТП. В фаангах на интервью обращают внимание на то как код написан, олимпиадный код получит жирный минус несмотря на эффективность.
В общем позиция автора по поводу "монолит или микросервисы" понятна.... Не взлетит - с масштабированием швах, в любую сторону.
+1. У нас (биг тех / продукт с десятизначным ревеню) рефакторинг делается перед тем как пишется фича, с конкретным обоснованием для чего. На код ревью например, если увидят трёхэтажные моки в тестах - тоже попросят отдельно отрефакторить сначала, чтобы любой джун разбуженный среди ночи понял что к чему. После того как код ушел в прод - никаких чисток чистоты ради.
Все правильно, тоже пришел к подобной схеме после годов мучений. Одно только смущает - только один разминочный подход в базовых упражнениях? Или это просто я старый и замученный травмами .. у меня 3-5 разминочных подходов, при сравнимых рабочих, иначе суставы и мышцы ругаются.
Интересно, не знал что мидвест настолько другой мир. На побережье (Бостон, Сиэтл, Калифорния, Нью Йорк), все по другому. Зарплаты большие, куча фаангов и контор попроще, но все могут платить норм, жизнь дорогущая. Интерншип у всех почти есть, один из лучших путей начать карьеру, вообще я бы сказал обязательно для любого кто в местных вузах учится. Правительственных контор мало, они не на слуху да и делать там нечего - ни денег толком, ни опыта, да и иммигрантом попасть сложно.
По поводу джунов проблема не "я Джун как мне быть на удалёнке" а "мы огромная компания у нас тыщи джунов как их всех научить". Так то да, полно видел джунов у кого никаких проблем с удаленной не было - но и обратных случаев много.
+100, если человек не хочет / не умеет работать - офис никак не поможет. Причины тенденции на возврат в офис понятны: 1/ налоговые послабления от городов где локации офисов 2/ чувство контроля для хреновых менеджеров, 3/ ещё проредить ряды сотрудников без громких сокращений, 4/ заставить сеньоров вживую подтягивать ленивых зато дешёвых джунов.
Наблюдаю щас в Амазоне, вроде как хайринг фриз, сокращения и все такое, а поток новых джунов не прекращается, и сильный прессинг со стороны менеджеров "ты сеньор тебе учить!". Нашли решение, эффективные наши ...
Книгу читать не пробовали? Вот целая глава на эту тему. https://sre.google/sre-book/eliminating-toil/
В Google SRE book, например. Причем не только файлы описания инфры, а именно автоматизацию (скрипты-утилиты итп)
Например - в МААНГах не нужны ".NET разработчики" или "Java разработчики", а скорее бэкенд-девелоперы в целом, которые могут переучиться на то что будет нужно для решения конкретных проблем
Это ситуация с наймом в большие компании, где поток кандидатов в сотни тысяч человек в год, стандартизация итп. К тому же в МААНГах обычно нет такой привязки к языку/стеку, люди осваивают нужные технологии на ходу. А раньше вон вообще всякие Брейн тизеры давали, типа почему люки круглые, так что сейчас ещё нормально. Ну и всегда есть вариант пойти в компании поменьше/попроще, где будет важен именно ваш стек, коммиты в гитхаб итп.
Как резидента ФААНГа тоже волнует вопрос "куда дальше", и вот переход в области где "высокий порог вхождения в отличие от" итп вообще непонятен. Ну вот работал ты в ФААНГе, ни разу не в финансах и трейдинге, и тут хочешь устроится в HFT (больше денег богу денег!). Ну и на собеседовании они от тебя хотят кучи специфических вещей которых ты не работая в HFT не знаешь. Как раз таки с ФААНГами все понятно, литкод +книги/видео по систем дизайну + любой опыт разработки, не нужно никаких сакральных знаний и умений, или там 10 лет опыта в новейшем фреймворке и тысячи звездочек в гитхабе.
Специфики не хватило, что конкретно ценят в HFT чтобы разработчик без опыта в HFT мог войти в отрасль не джуном.
Интересно б посмотреть на оф статистику, из немногих знакомых кто начал/закончил школу на год раньше все весьма успешны/счастливы.
Так вроде ж стандартная схема в крупных продуктовых компаниях, по крайней мере в западных. Могут быть ротации по разным типам дежурств, или один на все как у автора. У нас в Амазоне в моей команде обычно совмещается с онколл дежурством, из отдела в 30-40 человек обычно дежурят 3, один пейджер держит и тикеты разгребает, другой больше на всякой рутине (скрипты, дашборды, ранбуки, доки), третий (самый сеньористый, зачастую тимлид или дев менеджер) руководит онколл сменой и ответственный за внешние контакты (вплоть до разговоров с заказчиком в случае инцидентов), все вместе занимаются выкатками. В разных отделах и компаниях свои нюансы, но в целом принцип дежурств очень часто применяется, по причинам описанным автором.
Если 5-6 секций - то да, отличный тип вопроса на проверку определенного типа навыков, в одной из секций, для отсеивания "чукча не читатель". Встречал и сам давал вне ФААНГов, в ФААНГах тоже бывает но редко.
А в других форматах собеседования все ещё веселее, "мне он не понравился, мутный какой то", "да он не знает аргументов функций стандартной либы" итп. Все остальные способы абсолютно так же подвержены человеческому фактору.
Пособия приводят к гетто, а безусловный обязательно решит эти проблемы? Но как, в чем разница?
После США просто смешно читать про цены на медицину :) 100, 250... да, это типичная цена за скорую, если у вас хорошая страховка. Полная стоимость без страховки будет 2000+.
Хмм, а какой ещё рынок слился китайцам из-за "безликости" итп? Как раз таки от китайцев ни стиля ни оригинальности ждать не приходится, они другим всегда брали.
Из моего опыта:
1) на собеседованиях в Г чаще можно встретить Литкод Хард чем например в Амазон
2) в Амазоне вопросы явно с Литкода брать не рекомендуется, но многим влом думать-искать
3) все проблемы которые были у меня в вопросах на интервью в Амазоне встретились впоследствии в реальной работе
4) непосредственно навык скоростного решения таких проблем - не нужен. Но нужно уметь быстро писать хороший и тестируемый код и быстро распознавать алгоритмические паттерны, чтобы не велосипедить и не плодить тормозной код.
На самом деле это только часть навыков software engineer, и эффективность принятого формата интервью - вопрос спорный, но... Как то работает, а лучшего способа не придумали. "Гитхаб" и "поговорить за проекты" для бигтеха очевидно не вариант.
Тут зависит от того как использовать литкод. Если тупо адаптироваться под систему и фигачить write only, тогда да, может и во вред пойти. А можно писать нормально, с юнит тестами ИТП. В фаангах на интервью обращают внимание на то как код написан, олимпиадный код получит жирный минус несмотря на эффективность.