Собеседовать и оценивать человека должен интервьювер, компетенции которого как минимум не ниже позиции вакансии. Если этого нет, то придумывание ритуала и поиск вопросов для интервью в интернете особо не помогут.
Но в айтишке на управленческие позициях часто оказываются случайные люди.
На протяжении истории своего развития человечество постоянно использовало процессы найма и управления людьми. Руководили армиями, столетиями строили потрясающие по сложности произведения архитектуры.
А сейчас без изобретения велосипеда не получается руководить проектом с количеством людей меньшим, чем было занято в строительстве деревенской избы.
В линкедине пишут истории успеха "как я с N попытки попал в FAANG", где основной рецепт успеха - если пытаться сделать это много раз, то вероятность пройти собеседование сильно повышается. Что сразу вызывает вопрос, почему собеседование, проводимое успешными faangовцами, на деле оказывается рандомом, проходимым за счёт числа попыток.
IT это отрасль, заливаемая инвестиционными деньгами в надежде на быструю прибыль. Поэтому цель владельцев большинства проектов - рубить бабло, равно как и цель наёмных работников.
Это влечёт за собой массу глобальных последствий для индустрии, от экспоненциального наплыва людей, проходящих те же грабли, что и предыдущее поколение 4-5 лет назад (которые к этому моменту уже "эксперты" и учат других правильно проектировать методом пересказа увиденных в интернете решений задач с других проектов), до волн хайпа, создающих для инвесторов иллюзию прогресса ради выкачивания денег.
Расскажите, а что вы будете делать, если потеряете работу, а интересную для себя не сможете найти?
Покрытие 1 строки кода юнит тестом занимает значительно больше 1 строки кода.
Количество строк кода пропорционально связано со сложностью системы. С этой точки зрения юнит-тесты многократно увеличивают сложность системы. Увеличение сложности вполне может быть оправдано преимуществами, которые даёт юнит-тестирование.
Однако, найти метрики уровня "применение юнит-тестов удешевляет разработку в x раз и уменьшает количество багов с прода в y раз" - чрезвычайно сложно. Зато очень легко найти проект, на котором юнит-тестами покрыто то, что легче всего покрыть (утилиты и статика), а 20% критически важного (и самого сложного) функционала - нет.
Популярный аргумент "вы просто не правильно используете..." вызывает у меня встречный вопрос - а может ли считаться хорошей практика, которая на большинстве проектов оказывается "неправильно использованной".
Во многих случаях юнит-тест является единственным быстрым способом для разработчика проверить корректность работы кусочка написанного кода большой системы. Но ценность этих проверок в репе зачастую не выше ценности комита в репу файла с breakpoints, используемыми для дебага какой-либо задачи.
Также как на определённом этапе проекта денормализация БД является нормальной, так и удаление юнит-тестов, проверяющих работу утилит, которые никто не будет менять - тоже.
Более того, у меня нет сомнений в том, что при использовании НЕ test-first approach каждый девелопер без проблем вкинет сотни строк зелёных юнит-тестов в проект - сейчас за него это сделает Copilot. А ещё можно сгенерить тысячи строк юнит-тестов на юнит-тесты. Но непонятно, а нужны ли тогда ещё какие-либо уровни тестирования, если девелопер всё может сделать сам.
Аргумент об улучшении архитектуры (гибкости) для меня звучит как оправдание ограничений инструментов разработки. Если бы результат любого системного вызова в контексте юнит-теста можно было переопределить - зачем писать обёртки, интерфейсы и настраивать DI? Почему практики тестирования должны диктовать практики разработки?
Суммируя - я считаю, что на многих проектах инвестирование усилий в интеграционные тесты даёт больше измеряемой выгоды, чем юнит-тестирование самого простого кода.
Текстовое описание строки кода на высокоуровневом ЯП будет длиннее, чем сама строка кода.
За 20 лет я не видел ни одного ТЗ, в котором программисту не приходилось бы самостоятельно принимать решения по обработке исключительных ситуаций и граничных значений.
Растянутый во времени процесс разработки - это зачастую то самое время, которое необходимо именно на проработку деталей системы с заказчиком.
AI по вашему высокоуровневому описанию создаст программу, которая работает в соответствии с вашим ТЗ и неизвестно как в 80% не описанных в ТЗ случаев.
И когда с прода вам повалят тикеты уровня "а куда делась моя транзакция", вам придётся долго чатиться с AI, выясняя, а как же на самом деле работает ваш продукт и в чём проблема. Либо нанять программиста(ов), которые будут делать эту работу за вас.
Может Copilot и лучше, но пример с "покрой этот класс юнит тестами" неудачный.
По сути это равносильно задаче "добавь в репу сотни строк кода, которые выглядят так, как будто что-то проверяют, но на самом деле автосгенерированы на основании предположения, что покрываемая тестами логика уже работает верно".
Во время изменений архитектуры легаси проектов мне приходилось удалять тысячи строк таких юнит-тестов, потому ценности в них по сути не было, а сложность изменения покрытого юнит-тестами кода возрастает многократно.
Автогенерация юнит-тестов - это по сути оксюморон. Если юнит-тесты надо генерировать, то не надо их генерировать.
Мне кажется сложность технологий уже давно превышает выгоду от добавленной сложности.
Для Hello World приложения стало нормой требовать сотни мегабайт npm пакетов. И средний программист понятия не имеет что в тех пакетах. Это сотни мегабайт потенциальных косяков и уязвимостей. Прибыль растёт у cloud провайдеров, для которых чем выше сложность систем и больше в них компонентов, тем выше вероятность продления (и удорожания) подписки.
Хайп с AI в программировании вообще непонятен. Если я не смог загуглить ответ за минуту, то во всех этих случаях AI мне тоже ничем не помог. А таких вопросов (которые не загуглишь) у меня сейчас большинство.
Какое качество ответов можно ожидать от AI, обученного на публичной информации, большинство которой создаётся с целью монетизации либо далеко не самыми опытными пользователями - большой вопрос.
Нарисовать зайчика с тремя ушами - ОК.
Сгенерировать шаблон простого скрипта по текстовому описанию - ОК.
Помочь модифицировать говно-css - OK. CSS вообще должен был давно умереть, а не отнимать время инженеров.
Налить воды в ответе вместо одного слова "нет" - ОК.
Сразу увидеть то, что увидишь на первой странице в google - OK.
Но всё вышеперечисленное это примитивные задачи, которые работу только джунов могут отобрать.
Почему долгосрочные перспективы должны интересовать топ-менджмент, который за 3-5 лет на должности зарабатывает столько, что на всю оставшуюся жизнь хватит?
В Китае развитый внутренний рынок и нормальные программисты там зарабатывают не намного меньше, чем в FAANG - от 100K$ в год.
Я не уверен, остались ли ещё заказчики, верящие в дешёвых и квалифицированных программистов из дешёвых локаций, неспособных адекватно оценить себя на мировом рынке труда. Этакий условный Назир из Пакистана или Нигерии, который мог бы пройти собес и работать в Google, но предпочитающий батрачить за 20$ в час на примитивных проектах.
3 дня в офисе = минимум 3 часа в неделю на сборы и дорогу до офиса. Удобно в-основном для тех, у кого дома нет условий выделить комнату под рабочее место.
Если присутствие в офисе является для топ-менеджмента необходимым условием эффективной работы, то почему нет пропорционального увеличения з/п, если пробыл в офисе на полчаса-час больше?
Хороший код - максимально простой и понятный код для решения конкретной задачи (с учётом специфики проекта).
Чтобы научиться писать простой код, нужно много поработать с избыточно сложным.
Понимание необходимого качества кода на данном этапе проекта приходит с опытом.
Избыточная сложность решения (паттерны и обобщения "на будущее") так же плоха, как и спагетти.
Неспособность писать простой и понятный код, как правило, никак не связана с временными ограничениями. Такие люди при любых условиях дают тупые именования и не умеют делать базовую декомпозицию.
Отсутствие оптимизаций в коде зачастую обусловлено временными ограничениями. Но достаточно прогнозируемо исправляется выделением доп. времени.
Нытьё уровня "везде говнокод, нужно рефакторить" не может быть исправлено выделением времени на рефакторинг, так как чаще всего ноющие не могут дать оценку и не представляют финальный результат.
Сначала в требования вакансии со средней по рынку з/п пишут специфическую комбинацию технологий одного проекта компании, заведомо понимая, что шанс найти свободного на рынке человека с опытом из такой комбинации минимален.
Кандидаты понимают, что тексты вакансий обычно заведомо пишутся под отсутствующего на рынке труда человека, поэтому не заморачиваясь отправляют резюме по совпадению слов developer/engineer.
Поэтому рекрутёры десятилетиями жалуются на 2 проблемы
#1. очень много резюме, как же все успеть обработать
#2. очень тяжело закрыть любую вакансию
В отсутствии компетентности с обеих сторон баррикад на помощь приходит ИИ:
кандидата прособеседует виртуальный ИИ-интервьюер
а на вопросы виртуального ИИ-интервьюера ответит виртуальный ИИ-помощник кандидата
Соглашусь - Senior разработчик априори не может считаться джуном в любой технологии. Поэтому в FAANG на собесах знание конкретных языков программирования не требуют.
Опыт не означает знание. Джун в FAANG может быть технически сильнее сеньора, техлида или CTO в мелкой конторке.
Нормально так накинуть 30% к з/п ради иллюзии контроля для менеджмента.
На здоровье либо обучение сотрудников компании вряд ли согласятся столько тратить.
Отсутствие вилки скорее всего говорит о том, что она неконкурентоспособная. Тем, кто готов платить выше среднего, нет смысла скрывать это от потенциальных кандидатов.
Он намерен повысить её продуктивность на 20%. Пичаи намекнул, что одним из способов достичь этого могут стать сокращения.
Если продуктивность компании можно увеличить за счёт сокращений, то означает ли это, что в первую очередь нужно сократить тех, кто принимал решение об избыточном найме и участвовал в процессе найма непродуктивных сотрудников?
Комментарии
Собеседовать и оценивать человека должен интервьювер, компетенции которого как минимум не ниже позиции вакансии. Если этого нет, то придумывание ритуала и поиск вопросов для интервью в интернете особо не помогут.
Но в айтишке на управленческие позициях часто оказываются случайные люди.
На протяжении истории своего развития человечество постоянно использовало процессы найма и управления людьми. Руководили армиями, столетиями строили потрясающие по сложности произведения архитектуры.
А сейчас без изобретения велосипеда не получается руководить проектом с количеством людей меньшим, чем было занято в строительстве деревенской избы.
В линкедине пишут истории успеха "как я с N попытки попал в FAANG", где основной рецепт успеха - если пытаться сделать это много раз, то вероятность пройти собеседование сильно повышается. Что сразу вызывает вопрос, почему собеседование, проводимое успешными faangовцами, на деле оказывается рандомом, проходимым за счёт числа попыток.
IT это отрасль, заливаемая инвестиционными деньгами в надежде на быструю прибыль. Поэтому цель владельцев большинства проектов - рубить бабло, равно как и цель наёмных работников.
Это влечёт за собой массу глобальных последствий для индустрии, от экспоненциального наплыва людей, проходящих те же грабли, что и предыдущее поколение 4-5 лет назад (которые к этому моменту уже "эксперты" и учат других правильно проектировать методом пересказа увиденных в интернете решений задач с других проектов), до волн хайпа, создающих для инвесторов иллюзию прогресса ради выкачивания денег.
Расскажите, а что вы будете делать, если потеряете работу, а интересную для себя не сможете найти?
Покрытие 1 строки кода юнит тестом занимает значительно больше 1 строки кода.
Количество строк кода пропорционально связано со сложностью системы. С этой точки зрения юнит-тесты многократно увеличивают сложность системы. Увеличение сложности вполне может быть оправдано преимуществами, которые даёт юнит-тестирование.
Однако, найти метрики уровня "применение юнит-тестов удешевляет разработку в x раз и уменьшает количество багов с прода в y раз" - чрезвычайно сложно. Зато очень легко найти проект, на котором юнит-тестами покрыто то, что легче всего покрыть (утилиты и статика), а 20% критически важного (и самого сложного) функционала - нет.
Популярный аргумент "вы просто не правильно используете..." вызывает у меня встречный вопрос - а может ли считаться хорошей практика, которая на большинстве проектов оказывается "неправильно использованной".
Во многих случаях юнит-тест является единственным быстрым способом для разработчика проверить корректность работы кусочка написанного кода большой системы. Но ценность этих проверок в репе зачастую не выше ценности комита в репу файла с breakpoints, используемыми для дебага какой-либо задачи.
Также как на определённом этапе проекта денормализация БД является нормальной, так и удаление юнит-тестов, проверяющих работу утилит, которые никто не будет менять - тоже.
Более того, у меня нет сомнений в том, что при использовании НЕ test-first approach каждый девелопер без проблем вкинет сотни строк зелёных юнит-тестов в проект - сейчас за него это сделает Copilot. А ещё можно сгенерить тысячи строк юнит-тестов на юнит-тесты. Но непонятно, а нужны ли тогда ещё какие-либо уровни тестирования, если девелопер всё может сделать сам.
Аргумент об улучшении архитектуры (гибкости) для меня звучит как оправдание ограничений инструментов разработки. Если бы результат любого системного вызова в контексте юнит-теста можно было переопределить - зачем писать обёртки, интерфейсы и настраивать DI? Почему практики тестирования должны диктовать практики разработки?
Суммируя - я считаю, что на многих проектах инвестирование усилий в интеграционные тесты даёт больше измеряемой выгоды, чем юнит-тестирование самого простого кода.
Считаете unit тесты как серебряной пулей программирования? Всегда готовы написать unit test на метод GetById(id)?
Текстовое описание строки кода на высокоуровневом ЯП будет длиннее, чем сама строка кода.
За 20 лет я не видел ни одного ТЗ, в котором программисту не приходилось бы самостоятельно принимать решения по обработке исключительных ситуаций и граничных значений.
Растянутый во времени процесс разработки - это зачастую то самое время, которое необходимо именно на проработку деталей системы с заказчиком.
AI по вашему высокоуровневому описанию создаст программу, которая работает в соответствии с вашим ТЗ и неизвестно как в 80% не описанных в ТЗ случаев.
И когда с прода вам повалят тикеты уровня "а куда делась моя транзакция", вам придётся долго чатиться с AI, выясняя, а как же на самом деле работает ваш продукт и в чём проблема. Либо нанять программиста(ов), которые будут делать эту работу за вас.
Может Copilot и лучше, но пример с "покрой этот класс юнит тестами" неудачный.
По сути это равносильно задаче "добавь в репу сотни строк кода, которые выглядят так, как будто что-то проверяют, но на самом деле автосгенерированы на основании предположения, что покрываемая тестами логика уже работает верно".
Во время изменений архитектуры легаси проектов мне приходилось удалять тысячи строк таких юнит-тестов, потому ценности в них по сути не было, а сложность изменения покрытого юнит-тестами кода возрастает многократно.
Автогенерация юнит-тестов - это по сути оксюморон. Если юнит-тесты надо генерировать, то не надо их генерировать.
Мне кажется сложность технологий уже давно превышает выгоду от добавленной сложности.
Для Hello World приложения стало нормой требовать сотни мегабайт npm пакетов. И средний программист понятия не имеет что в тех пакетах. Это сотни мегабайт потенциальных косяков и уязвимостей. Прибыль растёт у cloud провайдеров, для которых чем выше сложность систем и больше в них компонентов, тем выше вероятность продления (и удорожания) подписки.
Хайп с AI в программировании вообще непонятен. Если я не смог загуглить ответ за минуту, то во всех этих случаях AI мне тоже ничем не помог. А таких вопросов (которые не загуглишь) у меня сейчас большинство.
Какое качество ответов можно ожидать от AI, обученного на публичной информации, большинство которой создаётся с целью монетизации либо далеко не самыми опытными пользователями - большой вопрос.
Нарисовать зайчика с тремя ушами - ОК.
Сгенерировать шаблон простого скрипта по текстовому описанию - ОК.
Помочь модифицировать говно-css - OK. CSS вообще должен был давно умереть, а не отнимать время инженеров.
Налить воды в ответе вместо одного слова "нет" - ОК.
Сразу увидеть то, что увидишь на первой странице в google - OK.
Но всё вышеперечисленное это примитивные задачи, которые работу только джунов могут отобрать.
Почему долгосрочные перспективы должны интересовать топ-менджмент, который за 3-5 лет на должности зарабатывает столько, что на всю оставшуюся жизнь хватит?
Программистов может столько и не нужно будет, но заявления уровня
мягко говоря очень далеки от действительности.
Топовый перформанс показывают топовые специалисты в топовых компаниях за топовую зарплату. Так было, есть, и так будет.
Спасибо, теперь я знаю, что такое feet back:
What does back on its feet mean?
having returned to normal or to a good position after a difficult period
В Китае развитый внутренний рынок и нормальные программисты там зарабатывают не намного меньше, чем в FAANG - от 100K$ в год.
Я не уверен, остались ли ещё заказчики, верящие в дешёвых и квалифицированных программистов из дешёвых локаций, неспособных адекватно оценить себя на мировом рынке труда. Этакий условный Назир из Пакистана или Нигерии, который мог бы пройти собес и работать в Google, но предпочитающий батрачить за 20$ в час на примитивных проектах.
3 дня в офисе = минимум 3 часа в неделю на сборы и дорогу до офиса. Удобно в-основном для тех, у кого дома нет условий выделить комнату под рабочее место.
Если присутствие в офисе является для топ-менеджмента необходимым условием эффективной работы, то почему нет пропорционального увеличения з/п, если пробыл в офисе на полчаса-час больше?
Говнокод слишком абстрактное понятие.
Хороший код - максимально простой и понятный код для решения конкретной задачи (с учётом специфики проекта).
Чтобы научиться писать простой код, нужно много поработать с избыточно сложным.
Понимание необходимого качества кода на данном этапе проекта приходит с опытом.
Избыточная сложность решения (паттерны и обобщения "на будущее") так же плоха, как и спагетти.
Неспособность писать простой и понятный код, как правило, никак не связана с временными ограничениями. Такие люди при любых условиях дают тупые именования и не умеют делать базовую декомпозицию.
Отсутствие оптимизаций в коде зачастую обусловлено временными ограничениями. Но достаточно прогнозируемо исправляется выделением доп. времени.
Нытьё уровня "везде говнокод, нужно рефакторить" не может быть исправлено выделением времени на рефакторинг, так как чаще всего ноющие не могут дать оценку и не представляют финальный результат.
Принципа Питера почти невозможно избежать
https://ru.wikipedia.org/wiki/Принцип_Питера
Сначала в требования вакансии со средней по рынку з/п пишут специфическую комбинацию технологий одного проекта компании, заведомо понимая, что шанс найти свободного на рынке человека с опытом из такой комбинации минимален.
Кандидаты понимают, что тексты вакансий обычно заведомо пишутся под отсутствующего на рынке труда человека, поэтому не заморачиваясь отправляют резюме по совпадению слов developer/engineer.
Поэтому рекрутёры десятилетиями жалуются на 2 проблемы
#1. очень много резюме, как же все успеть обработать
#2. очень тяжело закрыть любую вакансию
В отсутствии компетентности с обеих сторон баррикад на помощь приходит ИИ:
кандидата прособеседует виртуальный ИИ-интервьюер
а на вопросы виртуального ИИ-интервьюера ответит виртуальный ИИ-помощник кандидата
Прогресс налицо!
Соглашусь - Senior разработчик априори не может считаться джуном в любой технологии. Поэтому в FAANG на собесах знание конкретных языков программирования не требуют.
Опыт не означает знание. Джун в FAANG может быть технически сильнее сеньора, техлида или CTO в мелкой конторке.
В США давно рожают.
Те у кого визы США нет - сейчас в Аргентину рожать едут.
Нормально так накинуть 30% к з/п ради иллюзии контроля для менеджмента.
На здоровье либо обучение сотрудников компании вряд ли согласятся столько тратить.
Отсутствие вилки скорее всего говорит о том, что она неконкурентоспособная. Тем, кто готов платить выше среднего, нет смысла скрывать это от потенциальных кандидатов.
Если продуктивность компании можно увеличить за счёт сокращений, то означает ли это, что в первую очередь нужно сократить тех, кто принимал решение об избыточном найме и участвовал в процессе найма непродуктивных сотрудников?