Главная проблема роста в том, что 10 джунов одновременно могут расти в синьоров в рамках одной компании и одного отдела, но лидом стать из них сможет только один. Не потому что остальные плохие, а потому что они перейдут к нему в подчинение. И чем выше вы поднимаетесь, тем сильнее эта воронка сужается.
1 тимлид на команду из 10 человек. Один груплид на 30 человек. Один лид отдела на 100. Если на линейной позиции ваши шансы вырасти из джуна в мидла, а из мидла в синьора примерно равны и при хороших задатках близки к 100%, то, при прочих равных, шанс стать тимлидом уже в 10 раз ниже, чем синьором, а рук. отдела - в 10 раз ниже, чем тимлидом.
В Java есть класс мысленных задач, которые называются java puzzlers. Там тоже применяется базовый синтаксис, результаты исполнения которого можно вывести, зная "базу". Тем не менее, самые синьористые синьоры поголовно допускают в них ошибки, потому что это именно головоломки, а не типовой продакшн код, с которым они имеют дело ежедневно. Более того, даже если подобное встречается в реальной работе, результат легко узнать при помощи исполнения этого кода.
Ваши примеры - скорее из области головоломок, а не проверки базы.
Не раз видел людей с "20-летним опытом", которые не знают что такое докер или как настроить пайплайн в gitlab ci. Очень неправильно в ит искать прямую корреляцию между стажем работы и профессиональным уровнем.
Если после 20 лет работы человек 2 года не может пройти собеседование, вероятно, есть что-то, о чём мы не знаем.
У кассира есть кнопка "забить болт". На кассах самообслуживания в Спаре для многих товаров сейчас тоже есть такая опция, но она требует отсканировать бейджик наблюдателя за кассами, что всё равно неудобно.
Перебивать и перескакивать разумеется не приветствуется, но тут всё зависит от конкретных собеседующих.
Возможно, проблема как раз в том, что вы говорите про заучивание решения задач по видео с Ютуба, а от вас ждут понимания того, какие инструменты применять в той или иной ситуации и знания типовых шаблонов. Сейчас все научились рисовать квадратики, но копни чуть глубже - сразу сыпятся на непонимании деталей.
Странно в тиньке то, что для разработчиков грейд, по сути, выставляется на первом собеседовании, и даже идеально сданные последующие секции особо не могут на него повлиять в сторону повышения.
Потому что ваши запросы, как правило, или слишком простые, чтобы для них использовать орм, или слишком сложные, чтобы их можно было качественно выразить через орм.
А он так и останется без опыта. Просто потратит два года на изобретение костылей и велосипедов, которые никто и никогда не провалидирует. Может быть его проект будет как-то работать, может быть сможет корректно и быстро обрабатывать сотню записей в бд и нагрузку в виде пары кликов мышкой, но шанс получить при этом релевантный продуктовый опыт крайне мал.
Скорее, есть шанс освоить десяток-другой антипаттернов, прокачать ЧСВ, а потом строчить слёзные статьи о смерти айти и глупости алгоритмических собеседований.
Напихали автору в панамку, но по существу он прав. Если отбросить некоторые преувеличения в зарплатах курьеров и слегка истеричный стиль подачи, то видим, что можно относительно быстро вырасти до синьора, но дальше рост сильно замедляется. Потому что джуны в синьора могут расти параллельно, а вот тимлид уже может быть только один на 10 человек. Груплид - один на 40 человек. Рук.отдела - один на 120 человек. И можно быть сколько угодно крутым специалистом, но ты не станешь груплидом, потому что груплид уже есть. А больше некуда. Да, где-то цифры могут отличаться, где-то могут создаваться новые команды и отделы, но сути это не меняет.
Сейчас ещё можно прокатиться на волне за 300 к/наносек, но в потолок вы упрётесь за несколько лет, а скакать по компаниям долго не получится просто потому что когда вам будет 35, на вашу позицию синьор разработчика найдется несколько 25-летних, которые будут делать вашу работу гораздо лучше.
В который раз читаю "появляется много новых технологий", "не поспеваем в ногу со временем" и вот это всё. Наверное я и сам отстал от жизни, но скажите, как часто появляются альтернативы TCP, http, реляционным бд, брокерам сообщений? Новые способы виртуализации? Новые парадигмы программирования? Может быть новые способы физического размещения данных на дисках? Новые типы процессоров с принципиально иной архитектурой? Новая реализация сортировки пузырьком?
Конечно, если вы учите фреймворки, и для вас каждая версия реакта и ангулара или новая либа для реализации http api на питоне - повод обучаться с нуля, то да, вам придётся бежать очень быстро, но фундаментальных изменений не так много. Если есть базовые знания, овладеть инструментами можно в короткие сроки.
В таком случае, можно заявить, что у нас есть шифр, который отображает любой набор входных данных в единицу, а ключом являются сами исходные данные.
Давайте мысленно зашифруем два блокнота и выбросим ключи. У нас есть две единицы. Можем ли мы заявить, что информация из обоих блокнотов сохранилась ? Или только из одного? Если из одного, то из какого?
Скорее нет, чем да. Кажется, ни разу не сталкивался с тем, чтобы схема движения принципиально менялась на крупных развязках.
Понятно, что ответственность с водителя никто не снимает, но увидеть, например, что поворот с крайних двух полос, но эти полосы появляются только за 100 метров до перекрёстка - это удобно.
Будет ли что-нибудь сделано с тем, что в режиме навигации очень сложно (иногда невозможно) увидеть название улицы, по которой ты едешь, или на которую хочешь свернуть? При дефолтном масштабе названия не видно, при увеличении отрисовывается что угодно, кроме названия. Особенно это заметно на длинных улицах, которые приходится мотать туда-сюда в надежде найти незанятый кусок, на котором название всё-таки будет видно
Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".
Имхо, хороший индикатор накруток - обилие бессмысленных комментариев в стиле "спасибо, что раскрыли глаза", "очень полезно" и прочее капитанство в стиле GPT генератора, никак не отражающее суть статьи.
Итого, вы взяли сферу деятельности с низким порогом входа и обнаружили, что дешевле взять студента, который готов работать за еду, и быстро его обучить, чем сотрудника, который уже давно работает и всё ещё находится на этой базовой позиции. А потом решили экстраполировать это кликбейтным заголовком на всё айти (мы же на Хабре?).
Главная проблема роста в том, что 10 джунов одновременно могут расти в синьоров в рамках одной компании и одного отдела, но лидом стать из них сможет только один. Не потому что остальные плохие, а потому что они перейдут к нему в подчинение. И чем выше вы поднимаетесь, тем сильнее эта воронка сужается.
1 тимлид на команду из 10 человек. Один груплид на 30 человек. Один лид отдела на 100. Если на линейной позиции ваши шансы вырасти из джуна в мидла, а из мидла в синьора примерно равны и при хороших задатках близки к 100%, то, при прочих равных, шанс стать тимлидом уже в 10 раз ниже, чем синьором, а рук. отдела - в 10 раз ниже, чем тимлидом.
В Java есть класс мысленных задач, которые называются java puzzlers. Там тоже применяется базовый синтаксис, результаты исполнения которого можно вывести, зная "базу". Тем не менее, самые синьористые синьоры поголовно допускают в них ошибки, потому что это именно головоломки, а не типовой продакшн код, с которым они имеют дело ежедневно. Более того, даже если подобное встречается в реальной работе, результат легко узнать при помощи исполнения этого кода.
Ваши примеры - скорее из области головоломок, а не проверки базы.
Не раз видел людей с "20-летним опытом", которые не знают что такое докер или как настроить пайплайн в gitlab ci. Очень неправильно в ит искать прямую корреляцию между стажем работы и профессиональным уровнем.
Если после 20 лет работы человек 2 года не может пройти собеседование, вероятно, есть что-то, о чём мы не знаем.
Вот чего не понимаю в USB-C, так это почему разъёмы папа-мама сделаны именно таким образом, а не наоборот.
Lightning от Эппл выглядит гораздо логичнее.
У кассира есть кнопка "забить болт". На кассах самообслуживания в Спаре для многих товаров сейчас тоже есть такая опция, но она требует отсканировать бейджик наблюдателя за кассами, что всё равно неудобно.
Перебивать и перескакивать разумеется не приветствуется, но тут всё зависит от конкретных собеседующих.
Возможно, проблема как раз в том, что вы говорите про заучивание решения задач по видео с Ютуба, а от вас ждут понимания того, какие инструменты применять в той или иной ситуации и знания типовых шаблонов. Сейчас все научились рисовать квадратики, но копни чуть глубже - сразу сыпятся на непонимании деталей.
Странно в тиньке то, что для разработчиков грейд, по сути, выставляется на первом собеседовании, и даже идеально сданные последующие секции особо не могут на него повлиять в сторону повышения.
Потому что ваши запросы, как правило, или слишком простые, чтобы для них использовать орм, или слишком сложные, чтобы их можно было качественно выразить через орм.
А он так и останется без опыта. Просто потратит два года на изобретение костылей и велосипедов, которые никто и никогда не провалидирует. Может быть его проект будет как-то работать, может быть сможет корректно и быстро обрабатывать сотню записей в бд и нагрузку в виде пары кликов мышкой, но шанс получить при этом релевантный продуктовый опыт крайне мал.
Скорее, есть шанс освоить десяток-другой антипаттернов, прокачать ЧСВ, а потом строчить слёзные статьи о смерти айти и глупости алгоритмических собеседований.
Напихали автору в панамку, но по существу он прав. Если отбросить некоторые преувеличения в зарплатах курьеров и слегка истеричный стиль подачи, то видим, что можно относительно быстро вырасти до синьора, но дальше рост сильно замедляется. Потому что джуны в синьора могут расти параллельно, а вот тимлид уже может быть только один на 10 человек. Груплид - один на 40 человек. Рук.отдела - один на 120 человек. И можно быть сколько угодно крутым специалистом, но ты не станешь груплидом, потому что груплид уже есть. А больше некуда. Да, где-то цифры могут отличаться, где-то могут создаваться новые команды и отделы, но сути это не меняет.
Сейчас ещё можно прокатиться на волне за 300 к/наносек, но в потолок вы упрётесь за несколько лет, а скакать по компаниям долго не получится просто потому что когда вам будет 35, на вашу позицию синьор разработчика найдется несколько 25-летних, которые будут делать вашу работу гораздо лучше.
Примерно в любой крупной ИТ компании. ВБ, Озон, Авито, Тиньков, Альфа, Сбер, Т1 и так далее.
Для вашего понимания, и синьор, и ведущий разработчик - это тоже линейные специалисты. И даже тимлид - это линейный менеджер 1 уровня.
В который раз читаю "появляется много новых технологий", "не поспеваем в ногу со временем" и вот это всё. Наверное я и сам отстал от жизни, но скажите, как часто появляются альтернативы TCP, http, реляционным бд, брокерам сообщений? Новые способы виртуализации? Новые парадигмы программирования? Может быть новые способы физического размещения данных на дисках? Новые типы процессоров с принципиально иной архитектурой? Новая реализация сортировки пузырьком?
Конечно, если вы учите фреймворки, и для вас каждая версия реакта и ангулара или новая либа для реализации http api на питоне - повод обучаться с нуля, то да, вам придётся бежать очень быстро, но фундаментальных изменений не так много. Если есть базовые знания, овладеть инструментами можно в короткие сроки.
В таком случае, можно заявить, что у нас есть шифр, который отображает любой набор входных данных в единицу, а ключом являются сами исходные данные.
Давайте мысленно зашифруем два блокнота и выбросим ключи. У нас есть две единицы. Можем ли мы заявить, что информация из обоих блокнотов сохранилась ? Или только из одного? Если из одного, то из какого?
На отрезке с 2008 года по сегодня депозиты в среднем немного обгоняют инфляцию.
Победит более быстрый маршрут. Регулярно приходится переключать предложенные маршруты, которые на 4 минуты быстрее, но на 15 км длиннее.
А после малейшего схода с маршрута - на заправку или в соседний переулок, маршрут снова перестраивается по длинному пути.
Скорее нет, чем да. Кажется, ни разу не сталкивался с тем, чтобы схема движения принципиально менялась на крупных развязках.
Понятно, что ответственность с водителя никто не снимает, но увидеть, например, что поворот с крайних двух полос, но эти полосы появляются только за 100 метров до перекрёстка - это удобно.
Будет ли что-нибудь сделано с тем, что в режиме навигации очень сложно (иногда невозможно) увидеть название улицы, по которой ты едешь, или на которую хочешь свернуть? При дефолтном масштабе названия не видно, при увеличении отрисовывается что угодно, кроме названия. Особенно это заметно на длинных улицах, которые приходится мотать туда-сюда в надежде найти незанятый кусок, на котором название всё-таки будет видно
Как ни странно, RnD задачи тоже можно и нужно оценивать. Не в терминах "я найду решение за 4 дня", а в терминах "мы готовы выделить на исследование 4 дня". Во втором случае по истечении этого времени должны быть зафиксированы промежуточные результаты и принято решение о продолжении или отказе от дальнейшего RnD. В противном случае такое исследование рискует превратиться в бесконечную задачу по итогам которой будет сказано: "не шмогла я".
Имхо, хороший индикатор накруток - обилие бессмысленных комментариев в стиле "спасибо, что раскрыли глаза", "очень полезно" и прочее капитанство в стиле GPT генератора, никак не отражающее суть статьи.
Ага, именно по этой причине найм мидл разработчика занимает по 3-4 месяца, а синьор QA - полгода.
Итого, вы взяли сферу деятельности с низким порогом входа и обнаружили, что дешевле взять студента, который готов работать за еду, и быстро его обучить, чем сотрудника, который уже давно работает и всё ещё находится на этой базовой позиции. А потом решили экстраполировать это кликбейтным заголовком на всё айти (мы же на Хабре?).