Получается, что у вас в кодовой базе не встречается наследование, comprehension или аргументы по умолчанию? :)
Вопросы из статьи - это не "ловушки", а примеры базового синтаксиса Python, который ежедневно встречается в любом живом проекте. Они не про "зубрёжку" и не про говнокод, а про понимание языка, на котором вы заявляете, что работаете.
Спасибо за комментарий! Конечно, отдельный вопрос или даже несколько не дают полной картины. В статье приведены лишь отдельные примеры, которые хорошо показывают именно знание базового синтаксиса и принципов Python. Знание, который, как правильно, заявлено в резюме.
На реальных собеседованиях это только часть проверки, есть и практические задания, и обсуждение архитектурных решений, и реальные кейсы. Но если человек совсем не ориентируется в базовых вещах, то это, как минимум, сигнал к тому, чтобы копнуть глубже. И как показывает практика, зачастую копать глубже некуда
Понимаю вашу аналогию, но в примерах из статьи не ставилась цель устроить головоломку :)
Все задачи - это повседневный синтаксис Python: базовое наследование и MRO, работа со списками и аргументами по умолчанию, comprehension, хешируемость ключей. Эти вещи встречаются в продакшн‑коде регулярно и знать их полезно хотя бы для того, чтобы писать поддерживаемый код без неожиданных ошибок
Спасибо, что поделились своей историей! Полностью согласен, что реальный опыт может быть разным, и не всегда сложность задач в прошлом отражает реальные навыки кандидата
Моя статья не про людей, которые честно работали в своей зоне ответственности, даже если стек был простым. Она про ситуации, когда опыт намеренно приукрашивают и не могут подтвердить даже базу.
То, что вы честно пишете про свой путь и открыто говорите о сложностях, наоборот, вызывает уважение - и такие кандидаты обычно быстро догоняют новые требования
Добрый день! Спасибо за конструктивный комментарий! Полностью согласен, что уточняющие вопросы после основного ответа дают гораздо больше информации о реальном понимании принципов. Иногда человек может растеряться, но по рассуждениям видно, что фундамент есть.
В статье не было цели "облить грязью" людей ради самого процесса. Я сознательно привёл базовые вопросы, с которыми сталкивается любой, кто реально пишет код на Python больше пары месяцев.
Если человек называет себя Senior QA Automation Engineer и при этом не знает, что изменяемые аргументы по умолчанию работают как одна и та же ссылка или что comprehension в скобках даёт генератор, - это не "специфическая проверка". Это проверка минимального практического опыта.
Поэтому вывод "накрутил опыт" не про каждого ошибшегося, а про тех, кто системно не знает основы, но позиционирует себя экспертом
Благодарю за комментарий! Полностью с вами согласен!
У меня та же эволюция восприятия: когда только начинаешь карьеру - кажется, что главное "пушить в прод", а потом всё равно как-то работает. Но со временем, когда отвечаешь за продукт и команду, понимаешь: бездарь в штате - это риск, и дорогой.
И да, минусуют чаще всего как раз те, кто "вроде все делал, но глубины нет". Я провел уже десятки собеседований и вижу: стоит только немного копнуть, и резюме рассыпается. Поэтому проверять кандидатов "в хвост и гриву" - это не вредность, а нормальный подход.
Я понимаю вашу точку зрения, но в статье речь не про людей, которые запускали успешные проекты и работали с разными стеками, а про тех, кто приукрашает опыт и не может объяснить даже основы языка, на котором якобы писал код.
Нормальный KISS-код и успешные проекты - это здорово, и такие кандидаты как раз проходят собеседования легко, потому что быстро ориентируются и могут восстановить забытое. А вот когда в резюме написано "5 лет Python", а на практике человек путает tuple и dict - это уже не про забытое, это про отсутствие опыта совсем
На самом деле в статье вопросы выбраны не как "ловушки", а как проверка базового владения Python. Это не засыпка, а фундамент, тот минимум, который нужен, чтобы не тратить часы на ревью кода с банальными ошибками
В примере речь шла не про демонстрацию "уникального синтаксиса", а про то, как Python обрабатывает выражения с разным приоритетом операторов. То, что кандидаты на этом сыпались, и было показательно
Если ваше внимание зацепилось именно за термин, это хороший знак - значит, базу вы знаете, и обсуждение статьи для вас не про содержание, а про формулировку. Это нормально: у каждого свой профессиональный триггер
Спасибо за ваш субъективный взгляд, возможно в будущем напишете статью и расскажите, как правильно. Я уже высказал свое мнение выше в комментарии и в статье
Вопрос из статьи не про то, что так нужно писать код в продакшене, а про понимание синтаксиса Python. Такие проверки позволяют понять, знает ли человек язык, которым он заявляет, что владеет
Обычно такие вещи понимают те, кто работал с Python хотя бы немного глубже, чем на уровне "чтобы заработало"
В статье нет намеренного усложнения, примеры взяты из базового синтаксиса Python (ООП, list comprehension, mutable defaults и т.п.). Это не "олимпиадные" задачи и не трюкачество, а повседневные конструкции, которые реально встречаются в коде и которые важно понимать на базовом уровне
Возможно, и так. В статье речь не про конкретных людей и не про карьеры в целом, а про несоответствие заявленного опыта фактическим знаниям на собеседовании. Каждый идет своим путём, и руководителей тоже проверяют, только другими вопросами :)
Проблема не в том, чтобы "забивать свою голову" редкими приёмами, а в том, что базовые конструкции и особенности языка - это как грамматика в разговоре.
Использовать "только безопасные конструкции" - хорошо, но в реальной работе постоянно встречаются чужие решения, легаси-код и нестандартные ситуации. И если при этом человек не понимает базового поведения языка, он может тратить в разы больше времени на отладку и исправление багов. Поэтому такие вопросы - это не "чушь", а минимальная проверка: сможете ли вы разобраться, если что-то пойдёт не по шаблону
Вы немного передергиваете. Я нигде не говорил, что "умный кандидат = плохо". Речь о том, что интервьюеры тоже люди, и бывают разные ситуации: кто-то спрашивает по методичке, кто-то, что знает сам. Если на собесе есть ошибка - это повод обсудить, а не уходить в крайности вроде "тупой/умный". Цель ведь одна - найти совпадение ожиданий и навыков, а не мериться, кто умнее
Приведённые примеры - это не про "плохо читаемый код" или "специальные изыски", а про поведение самого языка, с которым неизбежно сталкивается любой, кто работает с Python. Ромбовидное наследование, comprehension и mutable default аргументы - это не пример "так надо писать", а проверка понимания того, как это работает. Даже если вы лично такого кода не пишете, понимать базовое поведение языка всё равно важно: встреча с легаси, отладка чужих тестов, библиотек или автоматизация.
Получается, что у вас в кодовой базе не встречается наследование, comprehension или аргументы по умолчанию? :)
Вопросы из статьи - это не "ловушки", а примеры базового синтаксиса Python, который ежедневно встречается в любом живом проекте. Они не про "зубрёжку" и не про говнокод, а про понимание языка, на котором вы заявляете, что работаете.
В статье как раз приведён пример и с генератором (
(x for x in range(3))), и с другими базовыми конструкциямиСпасибо за комментарий! Конечно, отдельный вопрос или даже несколько не дают полной картины. В статье приведены лишь отдельные примеры, которые хорошо показывают именно знание базового синтаксиса и принципов Python. Знание, который, как правильно, заявлено в резюме.
На реальных собеседованиях это только часть проверки, есть и практические задания, и обсуждение архитектурных решений, и реальные кейсы. Но если человек совсем не ориентируется в базовых вещах, то это, как минимум, сигнал к тому, чтобы копнуть глубже. И как показывает практика, зачастую копать глубже некуда
Понимаю вашу аналогию, но в примерах из статьи не ставилась цель устроить головоломку :)
Все задачи - это повседневный синтаксис Python: базовое наследование и MRO, работа со списками и аргументами по умолчанию, comprehension, хешируемость ключей. Эти вещи встречаются в продакшн‑коде регулярно и знать их полезно хотя бы для того, чтобы писать поддерживаемый код без неожиданных ошибок
Спасибо, что поделились своей историей! Полностью согласен, что реальный опыт может быть разным, и не всегда сложность задач в прошлом отражает реальные навыки кандидата
Моя статья не про людей, которые честно работали в своей зоне ответственности, даже если стек был простым. Она про ситуации, когда опыт намеренно приукрашивают и не могут подтвердить даже базу.
То, что вы честно пишете про свой путь и открыто говорите о сложностях, наоборот, вызывает уважение - и такие кандидаты обычно быстро догоняют новые требования
Добрый день! Спасибо за конструктивный комментарий! Полностью согласен, что уточняющие вопросы после основного ответа дают гораздо больше информации о реальном понимании принципов. Иногда человек может растеряться, но по рассуждениям видно, что фундамент есть.
Вы воспринимаете все слишком буквально, цифры 65 и 100 были приведены для примера и не имеют отношения к реальным зарплатам
Цель статьи - не "гейткипинг ради гейткипинга", а показать, что базовые вещи действительно важны.
Никто не отказывает кандидату за незнание редких алгоритмов или "олимпиадного трюкачества»" - речь идёт про фундамент языка, который заявлен в резюме.
В статье не было цели "облить грязью" людей ради самого процесса. Я сознательно привёл базовые вопросы, с которыми сталкивается любой, кто реально пишет код на Python больше пары месяцев.
Если человек называет себя Senior QA Automation Engineer и при этом не знает, что изменяемые аргументы по умолчанию работают как одна и та же ссылка или что comprehension в скобках даёт генератор, - это не "специфическая проверка". Это проверка минимального практического опыта.
Поэтому вывод "накрутил опыт" не про каждого ошибшегося, а про тех, кто системно не знает основы, но позиционирует себя экспертом
Благодарю за комментарий! Полностью с вами согласен!
У меня та же эволюция восприятия: когда только начинаешь карьеру - кажется, что главное "пушить в прод", а потом всё равно как-то работает. Но со временем, когда отвечаешь за продукт и команду, понимаешь: бездарь в штате - это риск, и дорогой.
И да, минусуют чаще всего как раз те, кто "вроде все делал, но глубины нет". Я провел уже десятки собеседований и вижу: стоит только немного копнуть, и резюме рассыпается. Поэтому проверять кандидатов "в хвост и гриву" - это не вредность, а нормальный подход.
Я понимаю вашу точку зрения, но в статье речь не про людей, которые запускали успешные проекты и работали с разными стеками, а про тех, кто приукрашает опыт и не может объяснить даже основы языка, на котором якобы писал код.
Нормальный KISS-код и успешные проекты - это здорово, и такие кандидаты как раз проходят собеседования легко, потому что быстро ориентируются и могут восстановить забытое. А вот когда в резюме написано "5 лет Python", а на практике человек путает tuple и dict - это уже не про забытое, это про отсутствие опыта совсем
На самом деле в статье вопросы выбраны не как "ловушки", а как проверка базового владения Python. Это не засыпка, а фундамент, тот минимум, который нужен, чтобы не тратить часы на ревью кода с банальными ошибками
В примере речь шла не про демонстрацию "уникального синтаксиса", а про то, как Python обрабатывает выражения с разным приоритетом операторов. То, что кандидаты на этом сыпались, и было показательно
Если ваше внимание зацепилось именно за термин, это хороший знак - значит, базу вы знаете, и обсуждение статьи для вас не про содержание, а про формулировку. Это нормально: у каждого свой профессиональный триггер
Спасибо за ваш субъективный взгляд, возможно в будущем напишете статью и расскажите, как правильно. Я уже высказал свое мнение выше в комментарии и в статье
Вопрос из статьи не про то, что так нужно писать код в продакшене, а про понимание синтаксиса Python. Такие проверки позволяют понять, знает ли человек язык, которым он заявляет, что владеет
Обычно такие вещи понимают те, кто работал с Python хотя бы немного глубже, чем на уровне "чтобы заработало"
В статье нет намеренного усложнения, примеры взяты из базового синтаксиса Python (ООП, list comprehension, mutable defaults и т.п.). Это не "олимпиадные" задачи и не трюкачество, а повседневные конструкции, которые реально встречаются в коде и которые важно понимать на базовом уровне
Возможно, и так. В статье речь не про конкретных людей и не про карьеры в целом, а про несоответствие заявленного опыта фактическим знаниям на собеседовании. Каждый идет своим путём, и руководителей тоже проверяют, только другими вопросами :)
Проблема не в том, чтобы "забивать свою голову" редкими приёмами, а в том, что базовые конструкции и особенности языка - это как грамматика в разговоре.
Использовать "только безопасные конструкции" - хорошо, но в реальной работе постоянно встречаются чужие решения, легаси-код и нестандартные ситуации. И если при этом человек не понимает базового поведения языка, он может тратить в разы больше времени на отладку и исправление багов. Поэтому такие вопросы - это не "чушь", а минимальная проверка: сможете ли вы разобраться, если что-то пойдёт не по шаблону
Вы немного передергиваете. Я нигде не говорил, что "умный кандидат = плохо". Речь о том, что интервьюеры тоже люди, и бывают разные ситуации: кто-то спрашивает по методичке, кто-то, что знает сам. Если на собесе есть ошибка - это повод обсудить, а не уходить в крайности вроде "тупой/умный". Цель ведь одна - найти совпадение ожиданий и навыков, а не мериться, кто умнее
Приведённые примеры - это не про "плохо читаемый код" или "специальные изыски", а про поведение самого языка, с которым неизбежно сталкивается любой, кто работает с Python. Ромбовидное наследование, comprehension и mutable default аргументы - это не пример "так надо писать", а проверка понимания того, как это работает. Даже если вы лично такого кода не пишете, понимать базовое поведение языка всё равно важно: встреча с легаси, отладка чужих тестов, библиотек или автоматизация.