Нефундаментальные (привязанные к библиотеками и фреймворкам) вопросы, построенные на опыте собеседующего, зачастую говорят об узости кругозора собеседующего.
Во время собеседования лучше выяснять не то, что кандидат НЕ знает из опыта собеседующего, а что и как он знает из своего опыта. Если то, с чем кандидат работал, он знает достаточно глубоко (и может понятно это донести) - то аналогичного уровня погружения и коммуникации можно ожидать от него при работе с любой другой технологией.
Но такой подход является неподъёмным для большинства собеседующих, так как переносит их из сильной позиции "расскажи мне то, что я знаю" в слабую "нужно оценивать то, чего я возможно не знаю".
Судя по тому, что вы "читатель", вам по работе приходится мало общаться с людьми. Когда начнёте, тогда и поймёте, почему созвон экономит время по сравнению с письмом.
Давность разработки сервиса вообще никак не коррелирует с его качеством. Ничего реально нового в языках программирования с 90-х не появилось. Ядра всей критической инфраструктуры в IT (операционных систем, СУБД и пр.) были написаны ДО 2000 года.
Хайп "новее=лучше" поддерживается китами индустрии для выкачивания денег.
Коммуникация экономит время на порядок (раз в 10) по сравнению с перепиской.
В идеальном программистском мире каждый таск идеально расписан и не вызывает двойственных трактовок (но зачем тогда программист, если уже есть AI). А в реале каждая задача даёт на откуп программисту некое количество решений, и часто средний программист к концу двухнедельной задачи формулирует свой статус так, что фиг поймёшь, ему действительно 1 день разработки остался, или ещё 4 недели ковыряться будет (и нужно срочно принимать решения по спасению задачи).
Коммуникация позволяет даже по тону говорящего делать более правильные выводы, стоит ли человеку в данный момент давать конкретную задачу.
В оценке своих знаний лучше полагаться на тех, кто не заинтересован финансово недооценивать.
Собеседование это не только оценка знаний. Это оценка полезности человека для работы в компании. Коммуникация является одним из ключевых навыков. Часть программистов имеет проблемы с пониманием вопросов и способностью прозрачно доносить мысль (статус таска, например).
Тезис "компания развивается, и я тоже" не для топовых компаний сомнителен, потому что управленческие подходы и культура очень разнятся от компании к компании (и чаще всего не меняются десятилетиями). Компании с токсичной культурой и через 20 лет остались компаниями с токсичной культурой, несмотря на многократный рост числа сотрудников.
Многократно по работе сталкивался с зашоренными коллегами, которые считают "так правильно" только потому, что у них на прошлом/текущем месте работы так было.
Собеседовать и оценивать человека должен интервьювер, компетенции которого как минимум не ниже позиции вакансии. Если этого нет, то придумывание ритуала и поиск вопросов для интервью в интернете особо не помогут.
Но в айтишке на управленческие позициях часто оказываются случайные люди.
На протяжении истории своего развития человечество постоянно использовало процессы найма и управления людьми. Руководили армиями, столетиями строили потрясающие по сложности произведения архитектуры.
А сейчас без изобретения велосипеда не получается руководить проектом с количеством людей меньшим, чем было занято в строительстве деревенской избы.
В линкедине пишут истории успеха "как я с 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 лет на должности зарабатывает столько, что на всю оставшуюся жизнь хватит?
Комментарии
Нефундаментальные (привязанные к библиотеками и фреймворкам) вопросы, построенные на опыте собеседующего, зачастую говорят об узости кругозора собеседующего.
Во время собеседования лучше выяснять не то, что кандидат НЕ знает из опыта собеседующего, а что и как он знает из своего опыта. Если то, с чем кандидат работал, он знает достаточно глубоко (и может понятно это донести) - то аналогичного уровня погружения и коммуникации можно ожидать от него при работе с любой другой технологией.
Но такой подход является неподъёмным для большинства собеседующих, так как переносит их из сильной позиции "расскажи мне то, что я знаю" в слабую "нужно оценивать то, чего я возможно не знаю".
Data Engineer с 4 годами опытами походу спрашивает больше, чем знает сам.
Alex Ivanov, вы не знаете что такое пространственная сложность алгоритма.
SQL это общий язык для всех реляционных СУБД последние 50 лет, поэтому знание основ считается необходимым.
Судя по тому, что вы "читатель", вам по работе приходится мало общаться с людьми. Когда начнёте, тогда и поймёте, почему созвон экономит время по сравнению с письмом.
Давность разработки сервиса вообще никак не коррелирует с его качеством. Ничего реально нового в языках программирования с 90-х не появилось. Ядра всей критической инфраструктуры в IT (операционных систем, СУБД и пр.) были написаны ДО 2000 года.
Хайп "новее=лучше" поддерживается китами индустрии для выкачивания денег.
Коммуникация экономит время на порядок (раз в 10) по сравнению с перепиской.
В идеальном программистском мире каждый таск идеально расписан и не вызывает двойственных трактовок (но зачем тогда программист, если уже есть AI). А в реале каждая задача даёт на откуп программисту некое количество решений, и часто средний программист к концу двухнедельной задачи формулирует свой статус так, что фиг поймёшь, ему действительно 1 день разработки остался, или ещё 4 недели ковыряться будет (и нужно срочно принимать решения по спасению задачи).
Коммуникация позволяет даже по тону говорящего делать более правильные выводы, стоит ли человеку в данный момент давать конкретную задачу.
Собеседование это не только оценка знаний. Это оценка полезности человека для работы в компании. Коммуникация является одним из ключевых навыков. Часть программистов имеет проблемы с пониманием вопросов и способностью прозрачно доносить мысль (статус таска, например).
Сложность по памяти O(n), завалили тест.
Главное не терять энтузиазма обеим сторонам:
https://www.youtube.com/watch?v=LuZV9kkzscg
Чаще всего люди долго сидят на одном месте потому, что не чувствуют себя конкурентоспособными на рынке труда.
И чем дольше человек сидит на одном месте, тем больше он боится поменять работу и выйти из зоны комфорта.
Лояльность к компании зачастую даёт карьерный рост, приводя к принципу Питера
https://ru.wikipedia.org/wiki/Принцип_Питера
Тезис "компания развивается, и я тоже" не для топовых компаний сомнителен, потому что управленческие подходы и культура очень разнятся от компании к компании (и чаще всего не меняются десятилетиями). Компании с токсичной культурой и через 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 лет на должности зарабатывает столько, что на всю оставшуюся жизнь хватит?
Программистов может столько и не нужно будет, но заявления уровня
мягко говоря очень далеки от действительности.