Можно многое не помнить и действительно полагаться на IDE - это нормально и в повседневной работе никто не держит все в голове.
Но есть базовые вещи, которые специалист должен понимать, даже если не помнит синтаксис наизусть. Это как с механиком: он может не помнить момент затяжки каждого болта, но он знает, как пользоваться гаечным ключом и зачем он нужен.
Точно так же в программировании важно понимать базовые принципы языка и то, как он работает "под капотом".
Цель статьи - показать, как выглядит накрученный опыт со стороны, и какие простые задачи реально задают на собеседованиях.
Заголовок провокационный, и он вызывает у многих эмоциональную реакцию, иногда даже сильнее, чем сами примеры. При этом сами задачи реальны и встречаются в интервью, это не "вопросы с подвохом". Да, в стрессовой ситуации можно ошибиться - это нормально, поэтому в реальных собеседованиях после таких вопросов обычно идут и практические задания, и архитектурные обсуждения, чтобы получить полную картину.
Сравнение с флоу Cython под numpy не очень удачное - это узкоспециализированная область, которая нужна далеко не всем, кто пишет на Python.
В статье же приведены вещи уровня "как работает множественное наследование", "что произойдёт с дефолтными аргументами функции" и "чем list comprehension отличается от генератора" - это повседневный синтаксис, который встречается практически в любом проекте.
Если перечитать статью внимательно, то как раз там и даны вполне обычные задачи: написать list comprehension, понять, как работают дефолтные аргументы функции, или как Python разрешает методы при наследовании. Это повседневные вещи, а не какие-то "олимпиадные каверзы"
Создается впечатление, что вы читали больше комментарии, чем саму статью :)
Спасибо за развёрнутый комментарий и что поделились своим опытом! Ваш подход к интервью интересен и действительно даёт возможность глубже раскрыть кандидата.
При этом мне кажется, что вы немного переоцениваете "среднюю температуру по больнице" на Хабре. В комментариях под этой статьей уже были и оскорбления, и откровенно токсичные сообщения - и это тоже часть аудитории. Плюс в топе регулярно оказываются статьи, которые к IT имеют весьма косвенное отношение ("Как я продал помидоры на маркетплейсе на 100 млн рублей в год" и т.п.). Так что утверждать, что аудитория "все как один не глупая и не однобокая" я бы не стал.
Как видите, 50+ человек, которые минуснули статью, явно не считают это странным. :)
Для меня это тоже было удивлением - задачи ведь действительно базовые. Но практика собеседований показывает, что многие кандидаты уверенно заявляют опыт, а на таких вопросах "спотыкаются"
Тема с джунами - это отдельный и сложный разговор. Тут речь больше про тех, кто заявляет себя мидлом или сеньором, но не может подтвердить базовые навыки.
Джунам никогда не было легко, это правда, но и требования к ним совсем другие: от джуна ожидают потенциал к развитию, а не готовый опыт уровня middle/senior.
Думаю, минусы в основном прилетели от тех, кто в статье увидел себя и среагировал эмоционально. Статья написана в провокационном стиле - чтобы обсуждали, спорили, делились опытом.
Ну и Хабр есть Хабр: посты в духе "Как я вырастил куст размером с дом" собирают плюсы быстрее, чем статьи про практическую инженерию :)
Обычно кандидату дают писать там, где ему удобно - в редакторе, в IDE или даже на листочке. Главное - понять, понимает ли человек, что он пишет.
Забавный факт: пару раз сам попадал на собеседования, где просили открыть обычный блокнот и писать там. Тогда это не казалось странным - просто писал и все.
Из практики помню случай: кандидат с 4 годами опыта на позиции Middle, которому предложили в онлайн-редакторе написать простой декоратор. И он честно сказал: "Я забыл, как пишутся функции, потому что IDE делает все за меня". Вот для таких случаев и нужны базовые проверки - это не каверзные задачки, а обычные конструкции языка.
Быть руководителем и быть активным разработчиком - разные роли. Руководитель может быть сильным в управлении процессами, планировании и мотивации команды, но при этом не писать код годами. И это нормально. Таких еще называют "манагерами"
В статье же речь шла именно об исполнителях, от которых ожидается, что они умеют уверенно работать с инструментами, не допуская элементарных ошибок. То есть если человек заявляет опыт работы именно как разработчик или автоматизатор - хотелось бы видеть соответствующие базовые знания. А не забивание гвоздей микроскопом, когда рядом лежит молоток
Спасибо за конструктивный комментарий! Даже если вы сходу ответили только на часть вопросов - это уже показатель хорошего практического опыта.
Согласен, что множественное наследование встречается не всегда, особенно если проект небольшой или используется строгая архитектура. Но в библиотеках, фреймворках, а особенно в AQA/SDET-позициях такие вещи встречаются чаще - там приходится работать с обвязкой, расширять готовые классы и переопределять методы. Иногда это даже переходит в работу с метаклассами.
Да, статья, возможно, не самая однозначная и она провокационная, но лично мне она нравится, и я знаю людей, которым она тоже зашла.
Просто в этих эмоциях и тексте статьи многие видят отражение самих себя - и это нормально, потому что тема болезненная.
И мне кажется, такая статья намного лучше, чем 95% мусора, сгенерированного LLM, который даже читать неприятно, или публикаций вроде «Как я заработал 100 млн на маркетплейсе, а потом у меня всё забрали» - которые вообще к тематике IT не относятся.
Спасибо за комментарий! Python действительно не всегда следует "принципу наименьшего удивления", особенно если смотреть на цепные сравнения или множественное наследование. Но именно за счёт своей простоты для изучения и огромной экосистемы он и популярен: скрипты, автотесты, ML, data science.
Для highload‑систем я бы тоже выбрал другой стек, а вот для задач автоматизации и быстрых прототипов Python остаётся отличным инструментом.
В начале статьи как раз указано, что цель - не высмеивать, а показать, как все выглядит со стороны интервьюера. Никого обидеть не хотел, но вижу, что задел половину Хабра - видимо, тема оказалась болезненной.
И да: лучше пусть статья вызывает эмоции и дискуссию, чем будет бездушным LLM-контентом про "как открыть маркетплейс за 5 шагов". Тут хотя бы живой опыт и реальная боль.
Негативная реакция - это ожидаемо. Статья задела людей, потому что многие проецируют ее на собственный опыт
Заголовок и примеры вызывают эмоции, а эмоции часто включают защитную реакцию. При этом цель статьи не обвинять кого-то лично, а показать проблему "накрученного" опыта. Интересно, что под "нейтральными" статьями вроде "как работать с переменными в Python" люди почти не оставляют комментариев - они просто читают и идут дальше. Здесь же пошла дискуссия, а это уже показатель, что тема действительно задела.
Рад, что материал оказался полезным. Даже если прямо сейчас не планируете идти на собеседование по Python, такие знания помогут и в практической работе - как минимум расширят кругозор, как максимум избавят от потенциальных багов в проде.
Можно многое не помнить и действительно полагаться на IDE - это нормально и в повседневной работе никто не держит все в голове.
Но есть базовые вещи, которые специалист должен понимать, даже если не помнит синтаксис наизусть. Это как с механиком: он может не помнить момент затяжки каждого болта, но он знает, как пользоваться гаечным ключом и зачем он нужен.
Точно так же в программировании важно понимать базовые принципы языка и то, как он работает "под капотом".
Цель статьи - показать, как выглядит накрученный опыт со стороны, и какие простые задачи реально задают на собеседованиях.
Заголовок провокационный, и он вызывает у многих эмоциональную реакцию, иногда даже сильнее, чем сами примеры. При этом сами задачи реальны и встречаются в интервью, это не "вопросы с подвохом". Да, в стрессовой ситуации можно ошибиться - это нормально, поэтому в реальных собеседованиях после таких вопросов обычно идут и практические задания, и архитектурные обсуждения, чтобы получить полную картину.
Обходите лучше любые компании стороной, так надежнее будет :)
Вы сильно гиперболизируете :)
Сравнение с флоу Cython под numpy не очень удачное - это узкоспециализированная область, которая нужна далеко не всем, кто пишет на Python.
В статье же приведены вещи уровня "как работает множественное наследование", "что произойдёт с дефолтными аргументами функции" и "чем list comprehension отличается от генератора" - это повседневный синтаксис, который встречается практически в любом проекте.
Спасибо за комментарий!
Если перечитать статью внимательно, то как раз там и даны вполне обычные задачи: написать list comprehension, понять, как работают дефолтные аргументы функции, или как Python разрешает методы при наследовании. Это повседневные вещи, а не какие-то "олимпиадные каверзы"
Создается впечатление, что вы читали больше комментарии, чем саму статью :)
Спасибо за развёрнутый комментарий и что поделились своим опытом! Ваш подход к интервью интересен и действительно даёт возможность глубже раскрыть кандидата.
При этом мне кажется, что вы немного переоцениваете "среднюю температуру по больнице" на Хабре. В комментариях под этой статьей уже были и оскорбления, и откровенно токсичные сообщения - и это тоже часть аудитории. Плюс в топе регулярно оказываются статьи, которые к IT имеют весьма косвенное отношение ("Как я продал помидоры на маркетплейсе на 100 млн рублей в год" и т.п.). Так что утверждать, что аудитория "все как один не глупая и не однобокая" я бы не стал.
Как видите, 50+ человек, которые минуснули статью, явно не считают это странным. :)
Для меня это тоже было удивлением - задачи ведь действительно базовые. Но практика собеседований показывает, что многие кандидаты уверенно заявляют опыт, а на таких вопросах "спотыкаются"
Тема с джунами - это отдельный и сложный разговор. Тут речь больше про тех, кто заявляет себя мидлом или сеньором, но не может подтвердить базовые навыки.
Джунам никогда не было легко, это правда, но и требования к ним совсем другие: от джуна ожидают потенциал к развитию, а не готовый опыт уровня middle/senior.
Думаю, минусы в основном прилетели от тех, кто в статье увидел себя и среагировал эмоционально. Статья написана в провокационном стиле - чтобы обсуждали, спорили, делились опытом.
Ну и Хабр есть Хабр: посты в духе "Как я вырастил куст размером с дом" собирают плюсы быстрее, чем статьи про практическую инженерию :)
Обычно кандидату дают писать там, где ему удобно - в редакторе, в IDE или даже на листочке. Главное - понять, понимает ли человек, что он пишет.
Забавный факт: пару раз сам попадал на собеседования, где просили открыть обычный блокнот и писать там. Тогда это не казалось странным - просто писал и все.
Из практики помню случай: кандидат с 4 годами опыта на позиции Middle, которому предложили в онлайн-редакторе написать простой декоратор. И он честно сказал: "Я забыл, как пишутся функции, потому что IDE делает все за меня". Вот для таких случаев и нужны базовые проверки - это не каверзные задачки, а обычные конструкции языка.
Спасибо, что поделились наблюдением!
Быть руководителем и быть активным разработчиком - разные роли. Руководитель может быть сильным в управлении процессами, планировании и мотивации команды, но при этом не писать код годами. И это нормально. Таких еще называют "манагерами"
В статье же речь шла именно об исполнителях, от которых ожидается, что они умеют уверенно работать с инструментами, не допуская элементарных ошибок. То есть если человек заявляет опыт работы именно как разработчик или автоматизатор - хотелось бы видеть соответствующие базовые знания. А не забивание гвоздей микроскопом, когда рядом лежит молоток
Спасибо за конструктивный комментарий! Даже если вы сходу ответили только на часть вопросов - это уже показатель хорошего практического опыта.
Согласен, что множественное наследование встречается не всегда, особенно если проект небольшой или используется строгая архитектура. Но в библиотеках, фреймворках, а особенно в AQA/SDET-позициях такие вещи встречаются чаще - там приходится работать с обвязкой, расширять готовые классы и переопределять методы. Иногда это даже переходит в работу с метаклассами.
Про курсы рассказывал в другой статье https://habr.com/ru/articles/908744/, там тоже не все однозначно
Да, статья, возможно, не самая однозначная и она провокационная, но лично мне она нравится, и я знаю людей, которым она тоже зашла.
Просто в этих эмоциях и тексте статьи многие видят отражение самих себя - и это нормально, потому что тема болезненная.
И мне кажется, такая статья намного лучше, чем 95% мусора, сгенерированного LLM, который даже читать неприятно, или публикаций вроде «Как я заработал 100 млн на маркетплейсе, а потом у меня всё забрали» - которые вообще к тематике IT не относятся.
Не ходите никуда - точно не промахнётесь :)
Спасибо за комментарий! Python действительно не всегда следует "принципу наименьшего удивления", особенно если смотреть на цепные сравнения или множественное наследование. Но именно за счёт своей простоты для изучения и огромной экосистемы он и популярен: скрипты, автотесты, ML, data science.
Для highload‑систем я бы тоже выбрал другой стек, а вот для задач автоматизации и быстрых прототипов Python остаётся отличным инструментом.
В начале статьи как раз указано, что цель - не высмеивать, а показать, как все выглядит со стороны интервьюера. Никого обидеть не хотел, но вижу, что задел половину Хабра - видимо, тема оказалась болезненной.
И да: лучше пусть статья вызывает эмоции и дискуссию, чем будет бездушным LLM-контентом про "как открыть маркетплейс за 5 шагов". Тут хотя бы живой опыт и реальная боль.
Куда же без него. Но об этом как-нибудь в другой статье :)
Негативная реакция - это ожидаемо. Статья задела людей, потому что многие проецируют ее на собственный опыт
Заголовок и примеры вызывают эмоции, а эмоции часто включают защитную реакцию. При этом цель статьи не обвинять кого-то лично, а показать проблему "накрученного" опыта. Интересно, что под "нейтральными" статьями вроде "как работать с переменными в Python" люди почти не оставляют комментариев - они просто читают и идут дальше. Здесь же пошла дискуссия, а это уже показатель, что тема действительно задела.
Спасибо за конструктивный комментарий!
Рад, что материал оказался полезным. Даже если прямо сейчас не планируете идти на собеседование по Python, такие знания помогут и в практической работе - как минимум расширят кругозор, как максимум избавят от потенциальных багов в проде.