Metacareers coding puzzles не показывает данные отвалившегося теста. Закидываю условие и своё решение с 15/33 пройденных тестов в chatgpt, copilot, perplexity - все говорят всё хорошо и не находят ошибку. Либо предлагают сделать проверку, которая априори не имеет смысла.
Прошу сгенерировать набор тестов для граничных условий - предлагают варианты, которые противоречат условию задачи.
интервью он прошел хорошо, но сейчас ему не могут предложить офер — из-за невозможности релокации из Беларуси в Польшу
Самые талантливые рекрутёры из FAANG не осилили для начала разобраться, стоит ли начинать многочасовой процесс собеседования? У меня фамилию из 5 букв умудрялись скопировать в авиабилет с ошибкой.
Опыт и сложность решённых на работе задач мало коррелируют с вероятностью успеха на собеседованиях в FAANG. Вчерашний студент Адитья из Индии, прошедший полугодовой курс подготовки к собесам в FAANG, имеет намного больше шансов на успех, чем условный Вася с 10-20 годами опыта без подготовки. При этом Адитья вполне может вообще не знать SQL (если повезёт и на System Design не спросят), как сделать http-запрос, прочитать файл с диска или ни разу в жизни не дебажить код.
Каждый кейс я выписал, подготовил себе небольшую шпаргалку.
Заранее заготовить "правильные" истории для behavioral вопросов вообще считается нормой для собесов в компании, претендующие на набор "лучших" талантов.
Похоже на игру, в которой побеждает тот, кто больше времени потратил на подготовку. И именно благодаря тому, что реальный опыт работы на успех собеседования вообще не влияет, уже построена целая индустрия, обучающая прохождению интервью в эти компании.
В отличие от Беларуси, благодаря масштабу IT-рынок в Индии намного лучше сортирует разработчиков по уровню. Для тех, кто умеет кодить - есть проторенная тысячами соотечественников дорога подготовки к прохождению собеседований в местный либо американский FAANG.
То есть шанс нанять дешёвого и хорошего разработчика в Индии стремится к нулю.
Так за последние 5 месяцев бурления про ПБХ почему-то никто в польском правительстве не захотел посчитать налоги, уплаченные получателями данной визы. Цель которой - привлечение высококвалифицированных специалистов для пополнения польского бюджета налогами.
Вместо этого считали, сколько раз по ПБХ пересекали польскую границу. А сейчас зачем-то связь с диверсантами ищут. Как будто это единственный способ для диверсанта попасть в Польшу. Остальные 100+ тысяч туристических виз, выданных беларусам в 2023 странами Шенгена как бы не в счёт.
Думаю, что российская агентура уже давно по всей Европе либо с ПМЖ живёт, либо прямо в европейских органах власти работает.
Нефундаментальные (привязанные к библиотеками и фреймворкам) вопросы, построенные на опыте собеседующего, зачастую говорят об узости кругозора собеседующего.
Во время собеседования лучше выяснять не то, что кандидат НЕ знает из опыта собеседующего, а что и как он знает из своего опыта. Если то, с чем кандидат работал, он знает достаточно глубоко (и может понятно это донести) - то аналогичного уровня погружения и коммуникации можно ожидать от него при работе с любой другой технологией.
Но такой подход является неподъёмным для большинства собеседующих, так как переносит их из сильной позиции "расскажи мне то, что я знаю" в слабую "нужно оценивать то, чего я возможно не знаю".
Судя по тому, что вы "читатель", вам по работе приходится мало общаться с людьми. Когда начнёте, тогда и поймёте, почему созвон экономит время по сравнению с письмом.
Давность разработки сервиса вообще никак не коррелирует с его качеством. Ничего реально нового в языках программирования с 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? Почему практики тестирования должны диктовать практики разработки?
Суммируя - я считаю, что на многих проектах инвестирование усилий в интеграционные тесты даёт больше измеряемой выгоды, чем юнит-тестирование самого простого кода.
Комментарии
Metacareers coding puzzles не показывает данные отвалившегося теста. Закидываю условие и своё решение с 15/33 пройденных тестов в chatgpt, copilot, perplexity - все говорят всё хорошо и не находят ошибку. Либо предлагают сделать проверку, которая априори не имеет смысла.
Прошу сгенерировать набор тестов для граничных условий - предлагают варианты, которые противоречат условию задачи.
Как-то так.
Самые талантливые рекрутёры из FAANG не осилили для начала разобраться, стоит ли начинать многочасовой процесс собеседования? У меня фамилию из 5 букв умудрялись скопировать в авиабилет с ошибкой.
Опыт и сложность решённых на работе задач мало коррелируют с вероятностью успеха на собеседованиях в FAANG. Вчерашний студент Адитья из Индии, прошедший полугодовой курс подготовки к собесам в FAANG, имеет намного больше шансов на успех, чем условный Вася с 10-20 годами опыта без подготовки. При этом Адитья вполне может вообще не знать SQL (если повезёт и на System Design не спросят), как сделать http-запрос, прочитать файл с диска или ни разу в жизни не дебажить код.
Заранее заготовить "правильные" истории для behavioral вопросов вообще считается нормой для собесов в компании, претендующие на набор "лучших" талантов.
Похоже на игру, в которой побеждает тот, кто больше времени потратил на подготовку. И именно благодаря тому, что реальный опыт работы на успех собеседования вообще не влияет, уже построена целая индустрия, обучающая прохождению интервью в эти компании.
В отличие от Беларуси, благодаря масштабу IT-рынок в Индии намного лучше сортирует разработчиков по уровню. Для тех, кто умеет кодить - есть проторенная тысячами соотечественников дорога подготовки к прохождению собеседований в местный либо американский FAANG.
То есть шанс нанять дешёвого и хорошего разработчика в Индии стремится к нулю.
Поэтому к подобным статьям в комментариях обычно перепись двоечников.
Каждый, кто плохо учился, но смог заработать себе на жизнь наравне с теми, кто учился хорошо - спешит об этом сообщить всему свету.
Те же, кто учился хорошо, считают свою работу и должность закономерным продолжением своей хорошей учёбы.
При равном уровне профессионализма всегда приятнее работать с разносторонне образованными людьми.
Так за последние 5 месяцев бурления про ПБХ почему-то никто в польском правительстве не захотел посчитать налоги, уплаченные получателями данной визы. Цель которой - привлечение высококвалифицированных специалистов для пополнения польского бюджета налогами.
Вместо этого считали, сколько раз по ПБХ пересекали польскую границу. А сейчас зачем-то связь с диверсантами ищут. Как будто это единственный способ для диверсанта попасть в Польшу. Остальные 100+ тысяч туристических виз, выданных беларусам в 2023 странами Шенгена как бы не в счёт.
Думаю, что российская агентура уже давно по всей Европе либо с ПМЖ живёт, либо прямо в европейских органах власти работает.
Европейская клоунада.
Нефундаментальные (привязанные к библиотеками и фреймворкам) вопросы, построенные на опыте собеседующего, зачастую говорят об узости кругозора собеседующего.
Во время собеседования лучше выяснять не то, что кандидат НЕ знает из опыта собеседующего, а что и как он знает из своего опыта. Если то, с чем кандидат работал, он знает достаточно глубоко (и может понятно это донести) - то аналогичного уровня погружения и коммуникации можно ожидать от него при работе с любой другой технологией.
Но такой подход является неподъёмным для большинства собеседующих, так как переносит их из сильной позиции "расскажи мне то, что я знаю" в слабую "нужно оценивать то, чего я возможно не знаю".
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? Почему практики тестирования должны диктовать практики разработки?
Суммируя - я считаю, что на многих проектах инвестирование усилий в интеграционные тесты даёт больше измеряемой выгоды, чем юнит-тестирование самого простого кода.