Кандидат сбежал в слезах. Про накрутку опыта / forpes.ru

Главная
Кандидат сбежал в слезах. Про накрутку опыта

Кандидат сбежал в слезах. Про накрутку опыта -13

29.07.2025 06:28

sound_right 221 24000 Источник

Вступление

В 2025 году «приукрашенное» резюме — уже не редкость, а скорее стандарт. Кандидаты добавляют себе проекты, в которых не участвовали, технологии, с которыми едва знакомы, и роли, которые никогда не выполняли. Всё ради того, чтобы выглядеть конкурентно. И вот наступает момент — собеседование. А там начинается совсем не тот «стендап», к которому они готовились.

Если вы решили приписать себе опыт с Playwright, Selenium, Allure, CI/CD, Kafka, Kubernetes, Pytest, GitLab, GitHub Actions и вдобавок написать, что «вели QA-гильдию» — окей. Но тогда, пожалуйста:

Понимайте, что делает автотест автоматическим.
Покажите хотя бы один pull request, где вы действительно что-то настроили.
И да, разберитесь, чем @pytest.mark.parametrize отличается от магии.

Никто не против роста и обучения. Но когда в резюме написано «Senior», а в диалоге — уровень «Hello, World», это вызывает вопросы. Причём не риторические.

Важно: в этой статье речь пойдёт не о компаниях и их подходах к найму (об этом — в другой раз). Сейчас — только о кандидатах, которые приходят на собеседование с сильно приукрашенным опытом, не готовые подтвердить написанное делом.

Да, мы будем говорить про вакансии QA Automation Engineer на Python, от Middle до Senior. Да, местами будет жёстко. Но главное — будет честно. Если вы когда-то немного преувеличили свой опыт — приготовьтесь к лёгкому внутреннему дискомфорту.

Цель статьи

Эта статья — не для того, чтобы высмеивать. А чтобы показать: как выглядит «накрученный» опыт со стороны. Как фальшивые строки в резюме распознаются за считаные минуты. И как «10 лет опыта» превращаются в «10 минут фейспалма» — причём не со зла, а просто потому, что всё видно.

Удивительно, но после провала на собеседовании кандидаты часто обижаются: мол, интервьюер «плохой», вопросы «глупые», а компания — «всё равно не та». Давайте разберёмся, почему отказ в таком случае — не месть, не придирка и не заговор. А закономерный итог, к которому вы сами подвели.

Примеры будут настоящие. Где-то неловкие, где-то — болезненные. Но каждый из них — с конкретным выводом. Поехали.

Задачи. Добро пожаловать в реальность

Начнём без прелюдий.

HR-специалистов вы, возможно, и сможете впечатлить. История про то, как вы «8 лет в QA», были «Lead», строили процессы, но вас не ценили и вот теперь вы ищете «команду мечты» — звучит убедительно. Особенно если уверенно подаёте и красиво оформляете резюме.

Но всё меняется, когда вы доходите до технического собеседования.

Тут уже не важно, насколько драматична история вашего увольнения или какие проекты указаны в профиле. Тут важно одно: можете ли вы подтвердить заявленный уровень на практике. Не в лайвкодинге с алгоритмами, не в системном дизайне. А в базовых вопросах. Базовых — в самом прямом смысле.

Операторы

Пример простой, как табуретка. Задача, которая регулярно вызывает панику у кандидатов, претендующих на мидл- и сеньор-позиции по Python:

55 == True is True

Что вернёт выражение? Правильный ответ: False. Почему? Потому что это цепное сравнение (chain comparison), и Python интерпретирует выражение как:

(55 == True) and (True is True)

А 55 == True — это False, потому что в логическом контексте True приравнивается к 1, и никакого наследования тут нет. Дальше уже неважно: False and ... даст False.

Именно такие задачи — не на знание редких фреймворков, а на понимание основ языка — и становятся критерием, отделяющим реального инженера от человека, который просто «наклеил технологии» в резюме.

Что говорят кандидаты?

Вот примеры реальных ответов:

«Ну, 55 == True — это True, потому что bool — это int» (почти, но нет: bool действительно наследуется от int, но True == 55 — это всё равно False)
«True is True — это False, потому что is сравнивает по значению» (наоборот: is сравнивает по идентичности объектов, и True is True всегда True)
«Ну тут == побеждает is» (как будто это Mortal Kombat, а не синтаксис языка)

И всё это произносится с абсолютной уверенностью. Настолько спокойной, что кажется: человек действительно верит, что понимает, о чём говорит. И, судя по интонации, рассказывает это уже не на первом собеседовании.

Почему это важно?

Потому что это фундамент. Если вы не можете объяснить разницу между == и is, не понимаете, как Python обрабатывает цепные сравнения или как работает приведение типов — вы не middle и не senior. Как бы ни выглядело ваше резюме.

Это не про придирки. Это про то, что все фреймворки, пайплайны, Kubernetes и GitHub Actions опираются на знание языка. И если в этом знании дыры — никакая “оркестрация” не спасёт.

Если фундамент кривой — небоскрёб падает. И падает быстро.

ООП

Теперь давайте про объектно-ориентированное программирование. Простая задача на наследование. Да-да, та самая классика, знакомая всем, кто хотя бы раз открывал учебник по Python:

class A:
    def hello(self):
        print("A")

class B(A):
    def hello(self):
        print("B")

class C(A):
    def hello(self):
        print("C")

class D(B, C):
    pass

D().hello()

Ожидаемый вывод:

Почему? Потому что Python использует ромбовидное наследование и алгоритм разрешения порядка поиска методов (MRO), основанный на линеаризации C3. Python сначала смотрит в B, затем в C, и вызывает первый подходящий метод. В данном случае — B.hello.

А что отвечают на собеседовании?

Иногда — действительно страшно:

«Этот код незапустится. Нельзя объявлять одинаковые методы в одном классе.» (А зачем тогда вообще придумали наследование? Чтобы пугать начинающих?)
«Ну… у кого главный метод, у того и вызовется...» (Кто такой «главный метод»? Это какой‑то новый паттерн — магия™?)

Бывают и более обнадёживающие попытки:

«Разрешение идёт слева направо.» Хорошее начало. Но потом продолжение: «до главного родителя». И всё… надежда, как и звук у кандидата, пропадает.

Почему это важно?

Потому что это тоже база. Это даже не про то, как писать продвинутые фреймворки — это про то, как работает язык, которым вы якобы владеете.

Особенно обидно, потому что лет 5–6 назад такие задачи многие решали устно, на слух. Без кода. Я описывал структуру классов — и человек отвечал. Сейчас же, увы, даже те, кто называют себя «QA Lead», не могут объяснить, как Python ищет метод при множественном наследовании.

Даже если вы не писали фреймворки, а занимались автотестами — вам приходилось сталкиваться с классами, наследованием, переопределением. Это часть ежедневной работы. И если за 5–8 лет опыта вы не узнали, как работает super() и порядок разрешения методов — это не ошибка. Это системный пробел.

Вывод

Если вы называете себя «Senior» или «Lead QA на Python», но не понимаете, почему в примере выше выводится B, — значит, вы пока не на этом уровне. Может быть, вы просто не уделяли базовым вещам достаточно внимания. Может быть, вас долго «тащила» команда. А может, вы просто слишком быстро начали учить Allure, не добравшись до __init__.

Как бы там ни было — на собеседовании вы проваливаетесь не на хитроумной задачке. А на вопросе из первой главы.

Словари

Теперь — вообще элементарный вопрос. Звучит он так:

{("a", [1, 2]): "value"}

Может ли такой код выполниться без ошибок? Почти все кандидаты отвечают: «Да, конечно». И сразу начинают объяснять:

«Ну tuple же неизменяемый, значит — норм»
«Я такого не писал, но вроде бы можно»
«Я такого не видел, значит такого не бывает»
«Так делали в одном проекте, и всё работало»

Серьёзно?

Давайте спокойно разберёмся

Ключи в словарях Python должны быть хешируемыми. Это значит: объект должен иметь постоянный hash() и быть неизменяемым.

tuple, действительно, может быть хешируемым. Но только если все его элементы тоже хешируемы. А [1, 2] — это список. А список — изменяемый тип. Следовательно, ("a", [1, 2]) — это нехешируемый кортеж. А значит, такой ключ в словарь вставить нельзя. Python выбросит TypeError.

То есть правильный ответ: нет, такой код не выполнится. И это не про подвох, не про тонкости, не про магию. Это просто базовая логика работы типов данных в Python. То, что должен понимать любой человек, который пишет код больше полугода.

Но почему так сложно?

Вот в чём настоящая боль: многие кандидаты не просто ошибаются. Они даже не пытаются рассуждать. Вместо логики — уверенность в духе:

«У меня так не было — значит, не бывает»
«Я работал 4 года — я бы такое точно запомнил»
«Ну это же tuple!»

Создаётся ощущение, что опыт не систематизировался. Не выстроился в понимание, как работает язык. А просто накопился в виде привычек и копипаста.

А ведь задача — из самых простых

Тут не нужно ни писать код, ни разбираться в каком-то редком поведении. Нужно просто знать: ключ в словаре — это всегда хешируемый тип. И всё. Это база. Это то, с чего начинается работа с Python.

Изменяемые и неизменяемые типы данных

Наверняка каждый, кто писал функции на Python, хотя бы раз встречал такую ситуацию:

def append_to_list(item, my_list=[]):
    my_list.append(item)
    return my_list

print(append_to_list(1))
print(append_to_list(2))

Вопрос: что выведется на экран? Ожидаемый ответ:

[1]
[1, 2]

Почему?

Потому что list — изменяемый тип данных. Когда вы используете его в качестве значения по умолчанию, Python создаёт один и тот же объект списка при определении функции — и использует его повторно при каждом вызове, если аргумент my_list не передан явно.

То есть my_list не создаётся заново при каждом вызове — вы каждый раз работаете с тем самым списком.

Что отвечают кандидаты?

Тут начинается шоу. Вот лишь малая часть реплик с реальных собеседований:

«Такой код не выполнится. Значения по умолчанию в Python нельзя задавать функцией.»
«Не понял, зачем my_list=[] написано. Это магия?»
«А почему второй вызов не должен вернуть [2]?»
«Ну тут просто баг в IDE...»
«У меня такого ни разу не было, значит, это не проблема.»
«У меня лапки!»

Знаете, какая из этих фраз самая опасная?

«У меня такого ни разу не было — значит, это не проблема.»

Это и есть самый надёжный индикатор отсутствия критического мышления. Потому что разработка — это не про «у меня работало». Это про понимание, как работает язык.

А ведь задача — элементарная

Не нужно ничего писать руками
Не нужно разбираться в «мета-классах»
Не нужно знать internals интерпретатора

Нужно просто понимать базовый принцип: изменяемые значения по умолчанию — это потенциальная ловушка. И это не «тонкость», а один из первых анти-паттернов, который подчёркивает любая IDE, любой линтер, любой курс по Python с 2015 года. Даже в документации прямо сказано: «Не делайте так. Используйте None и проверку внутри».

Как правильно?

Вот так:

def append_to_list(item, my_list=None):
    if my_list is None:
        my_list = []
    my_list.append(item)
    return my_list

И вывод

Если вы не сталкивались с таким кодом — значит, вы не читали код. Если вы не понимаете, в чём тут проблема — значит, вы не понимаете, как Python работает с аргументами. И уж точно — вы не Senior. Это не «жёсткий вопрос». Это базовая проверка на знание фундаментального поведения языка.

Comprehension

Ещё одна максимально простая и будничная задача. Из тех, с чем любой, кто реально работает с Python, сталкивается чуть ли не каждый день.

print([x for x in range(3)])
print((x for x in range(3)))
print({x for x in range(3)})

Что нужно ответить?

Тут никаких подводных камней. Просто понять, что тут происходит:

print([x for x in range(3)]) Вывод: [0, 1, 2] — list comprehension
print((x for x in range(3))) Вывод: <generator object ...> — generator expression
print({x for x in range(3)}) Вывод: {0, 1, 2} — set comprehension

Что отвечают «сеньоры»?

Первый случай почти всегда отвечают верно. Ура! А вот потом начинается магия.

Второй случай: Говорят, что будет кортеж: (0, 1, 2)

Почему? Ну... ответа обычно нет. Просто «я думал, что круглые скобки = кортеж». А то, что там не фигурные, не квадратные, и при этом есть for внутри — это, видимо, никого не смущает.

Почему это не кортеж? Потому что кортеж — это: (x, y, z). А внутри comprehension с for и без запятых — это генератор. (x for x in range(3)) — это не кортеж с генератором, это generator expression. Он не выполняется сразу, он ленивый, и это его главное отличие от list/set comprehension.

Третий случай: И тут ответ на миллион: «Это словарь» Словарь. Карл.

Нет, это не словарь. Это set comprehension. Вот так выглядит словарь comprehension:

{x: x * 2 for x in range(3)}

Если в фигурных скобках нет двоеточий, значит это set, а не dict. Set — это просто набор уникальных значений. Тут всё просто. Но почему-то многие уверенно говорят: «словарь».

И вывод

Эта задача даже не про знание синтаксиса. Это про зрение и практику. Если вы пишете на Python, вы просто физически не можете не видеть comprehension. Это визуальный паттерн, который мозг запоминает автоматически, если вы это реально используете.

Если вы смотрите на (x for x in range(3)) и говорите «это кортеж» — вы не пишете на Python. Если вы смотрите на {x for x in range(3)} и говорите «это словарь» — вы не писали comprehension вообще.

Так что снова: задача не из области «алгоритмов», не из «краевых случаев», не из «хакающего мозга собеса». Это — база. Это синтаксис, который либо живёт у вас в пальцах, либо нет. И если его нет — кто вы после 5 лет на Python?

Знаете, в чём нюанс?

Суть в том, что всезадачи выше — это не олимпиады по программированию, не математические загадки, не авторские фокусы с подвохом. Это база. База. Базовая. Самая обычная.

Я, честно признаюсь, бывал на собеседованиях в крупные компании, где автотесты строились из говна и палок, но на собес приносили задачки из олимпиад по информатике, как будто я в финале ACM ICPC. Смешно? Да. Абсурдно? Конечно. Но это хотя бы объяснимо: человек хочет показать «уровень».

Но тут не так. Задачи, о которых я говорил выше — это не уровень, это дыхание. Это то, с чем мы сталкиваемся каждый день, если мы хоть как‑то пишем на Python:

Понимание изменяемых и неизменяемых типов
Как работает аргумент по умолчанию
Что такое генератор, comprehension, set, tuple
Как работает наследование
Что можно, а что нельзя класть в словарь

Это не магия, это не глубокая специфика, это не метапрограммирование. Это — обычное поведение языка, и если ты работаешь с Python, ты это знаешь просто потому, что ты работаешь.

И вот где боль

Когда на собес приходит человек с 8 годами опыта, из которых 5 лет на Python, и он не может объяснить, почему tuple со списком не может быть ключом словаря, или что в my_list=[] может быть ловушка, — тут уже не про знания. Тут про честность.

Это не просто «не знал». Это «никогда не делал».
Это не «запутался». Это «всё время пользовался Python, но не понимал, как он работает».

А кто он тогда, если не Python-разработчик? Он — человек, который:

накрутил опыт
сидит спокойный, уверенный, улыбается в камеру
думает, что все так делают, и никто ничего не заметит

Но заметят. И на собесе такого человека просто подвесят за мягкое место и начнут пытать.

И вот что страшно

Таких — большинство. Реально толковый кандидат, который понимает язык, на котором пишет, — это сейчас исключение, а не правило. Так что нет, ты не «не прошёл собес из‑за странных задач». Ты провалился на базовой проверке адекватности, потому что не понял то, что должен был понять в первую неделю после «Hello, World».

Откуда берутся такие люди?

Вопрос, скажем прямо, не из лёгких. Но, на мой взгляд, один из главных факторов — жадность. Желание откусить кусок, который не помещается в рот, и утащить мешок, который не поднять своими руками.

Представим ситуацию:

Есть работодатель, готовый платить зарплату 100 рублей.
Есть кандидат, которому по-честному — 65 рублей в самый раз.
Но у кандидата в голове картинка другая.

Он думает:

“Ну я ж посидел полтора года на галере, сделал TODO на Flask-е, запушил это криво на GitHub — мне теперь не 65, а все 255 положено!”

Ну а чтобы в 255 поверили, надо и опыт подкрутить. Было 1,5 года — стало 3. Нет, лучше сразу 5 — солидно же звучит. Пяти лет-то кто спорить будет?

А может, всё-таки виноват работодатель?

Можно ли сказать, что работодатель — тоже хорош, зарплату занижает, ожидания завышает? Можно. Такое встречается. Особенно если на собесе вместо кофе дают кипяток и совет «держитесь».

Но давайте честно: сейчас речь не об этом. Не о том, что в вакансиях иногда просят «Senior QA с опытом в девOps и ML», а ЗП — 50к. А о тех кандидатах, которые тупо врут. Системно. Хладнокровно. Без тени сомнений.

И да, мне говорят: «Ну это же от безысходности. Требования высокие, конкуренция сильная. Человек вынужден приукрасить…»

А я говорю: «Нет. Это инфантильность.». Если ты открываешь вакансию и видишь:

«Ого, требования жёсткие»
«Ого, технологий я не знаю»
«Ого, платить будут не так много»

Пройдите мимо. Не откликайтесь. Найдите вакансию, где вы подходите. Или — сядьте и разберитесь в технологиях, подтяните скиллы. Так, чтобы потом на собесе можно было ответить за каждое слово в своём резюме.

Надежда на болтовню

Отдельный вид кандидатов — «авось проскочу». Ставка делается на то, что:

спросят не то
не будут вдаваться в детали
поговорим про жизнь, и меня возьмут

Серьёзно. Это работает? Иногда — да. У меня были такие собесы. Но знаете, в чём разница?

Я был готов в любой момент пояснить за каждую строчку в резюме.
Хотите код на собесе? — Да легко.
Хотите лайфкодинг? — Пожалуйста.
Хотите автотест прямо сейчас? — Давайте сделаю.

Просто меня об этом не просили. А не потому что я надеялся на «пронесёт».

Вот поэтому такие люди и появляются: жадность, инфантильность, надежда на удачу и вера в то, что все вокруг такие же. Но нет. Не все такие. И если вы честно пашете, растёте и отвечаете за базу — вы уже не в большинстве. Вы — в меньшинстве.

Как распознать накрутку опыта?

Многие кандидаты, к счастью, не слишком искусны в создании правдоподобных легенд. И в большинстве случаев они сами себя выдают на элементарных вещах. Один из самых простых и эффективных способов — задать те же вопросы на разных этапах: на скрининге, на техническом интервью, а потом — на финальном. Часто оказывается, что версии истории вдруг начинают отличаться. Видимо, кандидат выстроил у себя в голове некий сценарий, но, как говорится, стресс — не лучший помощник при запоминании вымышленных деталей. Поэтому расхождения в описании одного и того же места работы — тревожный звоночек. А вы тем временем — почти детектив.

Ещё один надёжный метод — техническое интервью. Если в резюме указано, что человек работает в профессии уже восемь лет, а на собеседовании путается в логических операторах, это, мягко говоря, вызывает вопросы. Конечно, все мы волнуемся, но между волнением и полным отсутствием базовых знаний — большая разница.

Хороший индикатор — глубина ответов. Допустим, кандидат заявляет, что два года участвовал в каком-то процессе. Вы уточняете детали — в ответах скользящие обобщения и максимум общих слов. Это может быть повод покопать чуть глубже. Пара наводящих вопросов — и становится понятно, был ли там реальный опыт или только желание, чтобы он был.

Ну и классика жанра — практическое задание. Особенно если речь про автоматизацию. Открытый файл, просьба накидать несколько автотестов — и всё становится ясно. Специалист с реальным опытом без особых усилий напишет 5–10 тестов в нормальном, рабочем стиле. А если вместо этого — напряжённый взгляд, молчание и внутренний монолог в стиле «где же мой боевой Stack Overflow?» — возможно, опыта не так уж и много. Конечно, если это совсем начинающий кандидат — другое дело. Но если в резюме указано 5+ лет — ожидания чуть иные.

Накрутка опыта — не просто сомнительный приём, это плохая привычка. К счастью, она довольно легко обнаруживается — особенно если подходить к делу с умом и лёгкой иронией.

Советы новичкам

Если вы, уважаемый читатель, только начинаете свой путь в индустрии, искренне рекомендую формировать опыт честно и последовательно, без приписок чужих заслуг. На самом деле, это проще, чем может показаться. Куда разумнее — сделать 5–10 собственных пет-проектов, пройти действительно качественные курсы, прочитать статьи, попробовать технологии на практике, потратить на всё это несколько месяцев, а может, и полгода — но зато погрузиться в тему по-настоящему.

Такой подход даст вам не только знания, но и уверенность. Вы будете чувствовать себя в новой сфере, как рыба в воде. А главное — совесть чиста, репутация крепка, зарплата растёт, и в голове — никакой каши из выдуманных историй. Только здравый смысл, реальный опыт и спокойствие при любом вопросе от рекрутера. Это путь, который даёт не только оффер, но и внутреннее удовлетворение.

Если же вы всё-таки решили "украсть немного опыта", то тут уж, извините, придётся соответствовать. За каждую строку в резюме, за каждое упомянутое слово и технологию — нужно быть готовым объяснить, показать, доказать. Портфолио, рекомендации, осознанные ответы — всё должно быть на месте. Это база, без которой фальшь рано или поздно всплывёт.

Если же путь был выбран по принципу "накрутил и забыл", то, боюсь, велик риск оказаться в ряду тех, кто потом фигурирует в статьях вроде этой — в качестве поучительного примера. Надеюсь, не вашего.

Заключение

Если в резюме «10 лет опыта», а на практике — 10 минут смущения, виноват не вопрос, а ответ.

Мир IT даёт шанс всем. Но требует быть готовым, а не просто выглядеть. И, пожалуйста — прежде чем писать «Senior», проверьте, что внутри действительно есть знания, а не только заголовок.

Ну а если вам всё ещё кажется, что «пронесёт» и никто не заметит накрутку — не забудьте перезарядить берёзовую палку.

Комментарии (221)

sunUnderShadow
29.07.2025 06:54
#28631754
Не изучал змеюку и приоритеты операторов (мало-ли), но в данном случае при любой логике false
```
55 == True is True

# Рассмотрим вариант с приоритетом у ==
55 == True # false и все автоматом false 

# Рассмотрим приоритет у is
True is True # True что потом - смотри выше 
```
Так что все кто запоролся на этом вопросе даже 3х месяцев не поработали это 100%
1. sound_right Автор
  29.07.2025 06:54
  #28631890
  Иногда кандидаты видят тут подвох и финально отвечают True, потому что не может же быть все настолько просто? Если бы было базовое понимание этих операторов, то сомнение не было
  1. Spiritschaser
    29.07.2025 06:54
    #28633566
    Скажите, а зачем такой код использовать? В эпоху Perl, вы, видимо, писали однострочники с метапрограммами в регэкспах, чтобы не дай б-г мидл не проскочил?
    
    Может, лучше по генераторам-итераторам погонять да по асинхронщине с тредами?
    
    sound_right Автор
    29.07.2025 06:54
    #28633876
    В статье как раз приведён пример и с генератором ((x for x in range(3))), и с другими базовыми конструкциями
1. Mr_Boshi
  29.07.2025 06:54
  #28632028
  Думаю, дело в том, что Python в if-statement ненулевые целые отрабатывает как True:
  >>if 55: print('True') else: print('False')
  >> True
  
  (Если сделать то же самое для if 0:, то выдаст False)
  
  Поэтому для них не очевидно, что 55 == True -- это False.
  1. namikiri
    29.07.2025 06:54
    #28634292
    Проверил на JS, ровно так же отрабатывает. !!55 превращается в true, а вот если !!55 == true, то вернётся уже false
    
    lrmpsm53
    29.07.2025 06:54
    #28634508
    Дык оператор отрицания имеет больший приоритет оператора сравнения
1. positroid
  29.07.2025 06:54
  #28632130
  Тоже не питонист, в своем языке я знаю как работают приведения типов при сравнении. Но допускаю, что вполне кто-то может не знать, что будет в результате сравнения 55 == True, потому что им в голову не приходило писать такие условия. А как написали выше if 55 - истинное условие.
1. wl2776
  29.07.2025 06:54
  #28632782
  Приоритет одинаковый, выражение вычисляется слева направо.
1. Megadeth77
  29.07.2025 06:54
  #28633708
  Чисто питонячий прикол для выражений вида 3>2>1, раскладывается в (55 == True) and (True is True)
1. Nalivai
  29.07.2025 06:54
  #28634302
  У питона в этом смысле все очень плохо, и единственный верный ответ на все эти вопросы это "все переписать нормально" а не пытаться запомнить что там где.
  
  55 == True
  
  False
  
  1 == True
  
  True
  
  0 == False
  
  True
  
  55 and True
  
  True
  
  0 and True
  
  0
  
  -1 == False
  
  False
  
  -1 == True
  
  False
1. gun_dose
  29.07.2025 06:54
  #28634370
  А вот в php 55 == true выведет истину, т.к. это не строгое сравнение.

whiteBlackness
29.07.2025 06:54
#28631758
Давным давно, когда я был мидлом - то ответы на подобные вопросы знал.
Сейчас уже с ходу на половину вопросов не отвечу: стараешься такой код инстинктивно не писать, а когда приходится - то всегда в документацию предварительно можно глянуть.
Приходится в голове держать уже более общие вещи, а такие нюансы хранить вовне.

Правда у меня основной язык C++, но так же приходится много и на python писать, а сейчас ещё Rust прокачиваю. Не считая k8s, react и прочих штук. Так что в голове уже больше хранятся принципы построения ПО, а не какие-то тонкие детали языка.
1. sound_right Автор
  29.07.2025 06:54
  #28631932
  Так и вопросы сами по себе не сложные, на уровне решения повседневных задач. Эта статья выборка из нескольких сотен собеседований, и как показывает практика, если на базовых задачах все плохо, про паттерны смысла спрашивать нет. От слова SOLID бросает в ужас
  
  Не всегда так конечно, но частенько бывает. Да и сам процесс не мной придуман)
  1. PrinceKorwin
    29.07.2025 06:54
    #28632272
    Так и вопросы сами по себе не сложные, на уровне решения повседневных задач
    
    За использование таких условий в реальных задачах нужно бить по рукам.
    
    Уточню:
    
    if 50: - - - хорошо
    
    if 50 == True: - - - плохо
    
    Код, разумеется вымышленный.
    
    sound_right Автор
    29.07.2025 06:54
    #28632496
    В статье по мимо примеров с операторами есть еще другие, попробуйте смотреть шире
    
    Nalivai
    29.07.2025 06:54
    #28634396
    Абсолютно все примеры из статьи это примеры кода который никогда, ни при каких условиях, не должен быть написан. Не то что это не код для прода, это код, который не должен существовать, нигде, никогда.
    
    Если бы я хотел написать статью с вредными советами для питона, с контерпаттернами, все ваши примеры там бы оказались.
    
    Если у вас в коде есть хоть что-то из того что вы описали, хоть где-то, единственная ваша обязанность как разработчика это переписать весь код, чтобы этого больше не встречалось. Или уволиться, потому что на этом этапе код может быть фундаментально обречен.
    
    cruiseranonymous
    29.07.2025 06:54
    #28634502
    Нет, не "абсолютно все". Те же comprehension-ы - вполне валидные вещи, и место им в коде есть.
    
    Ну и знать как можно написать плохой код, почему он плохой, и почему так делать не надо - это как раз чтобы в прод не попадал плохой код. Ведь код не только писать - но и коллег ревьювить(а им - тебя). И там может попадаться и что-то из примеров из статьи.
    
    sound_right Автор
    29.07.2025 06:54
    #28634638
    Абсолютно все примеры из статьи
    
    Вы сильно утрируете. В статье приведены примеры с базовыми конструкциями языка: list comprehension, генераторы, наследование и дефолтные аргументы. Это стандартный синтаксис Python, который встречается повсеместно и не является "вредным советом". Цель примеров - проверить знание основ, а не пропагандировать антипаттерны.
    
    wl2776
    29.07.2025 06:54
    #28632750
    if 50: - - - хорошо
    
    Это тоже нехорошо.
    
    Что такое 50?
    
    PrinceKorwin
    29.07.2025 06:54
    #28633704
    Там приписка - код вымышленный.
1. WALL_E
  29.07.2025 06:54
  #28632390
  Есть халтурный подход проверки кандидата на "знания и навыки". Эдакое прохождение устного чек листа состоящего из довольно рандомных частностей. Наподобие true is true. Если обобщить то такой подход проверяет то какой кандидат "зубрила". Почему-то в общем техническом менталитете уже давно объединены во едино такие качества как умение цитировать общеизвестные факты(память) и навык в рандомной ситуации владеть доступным инструментарием. т.е. мастерство. Для удобства, если кому-то непонятен термин мастерство, то подойдут многие примеры из области искусства, где используется какой либо инструментарий.
  
  Вопрос о том, что важнее в кандедате, мастерство или феноменальная память, как про мальчика из анекдота, для меня лично не стоит. Халтурный HR-подход, на мой взгляд, заполонил практически все.
  1. sound_right Автор
    29.07.2025 06:54
    #28632512
    Это проверка базового понимания языка и инструментов, чтобы убедиться, что человек сможет писать поддерживаемый код без грубых ошибок. После этого в идут более практические и архитектурные задания, где и проявляется мастерство. Никому не интересно впоследствии тратить часы времени на ревью и объяснять, как работает наследование в Python
    
    krakotay
    29.07.2025 06:54
    #28632888
    человек сможет писать поддерживаемый код без грубых ошибок
    
    В таком случае, вы сами его не прошли. Ведь на полном серьёзе пишете
    55 == True is True
    и спрашиваете кандидатов, как оно работает
    
    sound_right Автор
    29.07.2025 06:54
    #28632926
    Вопрос из статьи не про то, что так нужно писать код в продакшене, а про понимание синтаксиса Python. Такие проверки позволяют понять, знает ли человек язык, которым он заявляет, что владеет
    
    Обычно такие вещи понимают те, кто работал с Python хотя бы немного глубже, чем на уровне "чтобы заработало"
    
    krakotay
    29.07.2025 06:54
    #28632974
    Т.е. зубрёжка. Там можно проще - наизусть перечислить вообще все встроенные функции, модули и базовые методы. Проверять по чек-листу легко, и как KPI элементарно считать.
    
    wmns
    29.07.2025 06:54
    #28633050
    Это вопрос уровня опросника рекрутера при первом общении с кандидатом. На собеседовании подобных вопросов быть не должно - вы тратите время кандидата и своё.
    
    SystemOutPrintln
    29.07.2025 06:54
    #28633364
    Ваши проверки на уровне "вы не смогли вспомнить, что в главе X на странице такой-то Кирила Петрович выпил пунш, значит, вы не читали роман "Дубровский", вам двойка!"
    
    понимание синтаксиса Python
    
    Хороший программист должен лучше всего понимать не синтаксис языка, а принципы правильного написания кода, паттернов и архитектуры. Языки приходят и уходят, а паттерны остаются.
    
    Ни один нормальный программист не напишет код, примерами которого вы мучаете кандидатов. К чему эти проверки на знание нюансов, которые у хорошего программиста даже не вылезут при написании кода?
    
    zamir__zakiev
    29.07.2025 06:54
    #28634390
    А нужен ли вам человек, который будет на зубок знать такие тонкости синтаксиса? Он же и код будет писать соответствующе сложно. Потом вам же его читать и ломать голову, как это все будет работать.
    
    sound_right Автор
    29.07.2025 06:54
    #28634668
    тонкости синтаксиса
    
    Жесть, конечно. Наследование, comprehension и работа с аргументами по умолчанию - это не тонкости, а базовый синтаксис языка, который встречается в любом реальном проекте. Цель таких вопросов не "усложнить код", а убедиться, что человек понимает фундамент и не будет допускать ошибок уровня "гвозди микроскопом забивать"
1. Wosk1947
  29.07.2025 06:54
  #28632696
  Согласен с вами. Большая часть приведенного в статье кода - это именно какие-то синтаксические изыски, которые в нормальном проекте не пройдут через код-ревью, и человек такое мог даже никогда не видеть. Особенно ромбовидное наследование, которое является антипаттерном в любом языке, в котором оно возможно. Если следовать парадигме чистого кода, основной посыл которой заключается в том, что код должен быть читаемым, то ни один человек такой код никогда не напишет, и по хорошему, от греха подальше, не должен знать, что такой код можно написать. А если и встретит такое в каком-нибудь старом легаси - пять минут гуглежки помогут разобраться.
  1. sound_right Автор
    29.07.2025 06:54
    #28632868
    Приведённые примеры - это не про "плохо читаемый код" или "специальные изыски", а про поведение самого языка, с которым неизбежно сталкивается любой, кто работает с Python. Ромбовидное наследование, comprehension и mutable default аргументы - это не пример "так надо писать", а проверка понимания того, как это работает. Даже если вы лично такого кода не пишете, понимать базовое поведение языка всё равно важно: встреча с легаси, отладка чужих тестов, библиотек или автоматизация.
    
    AlexMih
    29.07.2025 06:54
    #28633064
    Приведенный код - это примеры того, что если человек скажет "О, да, знаю такое, сталкивался в своем реальном коде" - то его смело можно гнать куда подальше.
    
    Нормальная реакция специалиста - "Фиг его знает, никогда такой порнографии в коде не видел и не допускал. Если это так в легаси - надо загуглить и подумать, если в новом коде - переделать немедленно".
    
    sound_right Автор
    29.07.2025 06:54
    #28633276
    Спасибо за ваш субъективный взгляд, возможно в будущем напишете статью и расскажите, как правильно. Я уже высказал свое мнение выше в комментарии и в статье
    
    Nalivai
    29.07.2025 06:54
    #28634446
    Про это не надо писать статей, это описано в любой книге, статье, блог посте, и комментарии, которые хоть как-то затрагивают то как надо писать код.
    
    Это и есть база разработчика, а не то как какая-то там версия какого-то там языка обрабатывает то что всегда должно быть определено как UB.
    
    Если вы этого не знаете или отвергаете, то это вы не знаете базы.
    
    sound_right Автор
    29.07.2025 06:54
    #28634674
    Статья писалась не как "учебник по языку", а как отражение реальных кейсов с собеседований. Кому-то эта база знакома, кому-то - нет, и именно это и вызывает интерес к обсуждению. Думаю, каждый сам решает, какие темы ему интересны писать и читать :)
1. ronden
  29.07.2025 06:54
  #28634944
  Аналогичное мнение возникло. Автор пишет непонятный код и спрашивает как это будет работать называя спагетти азами.
  
  Код должен быть простой и понятный для любой блондинки. А не вот это вот.
  
  В итоге мы не проверяем кандидата а самоутверждаемся.

akod67
29.07.2025 06:54
#28631766
Это база. База. Базовая. Самая обычная.

В реальных боевых задачах база другая от слова совсем. И 10 лет опыта решения реальных проблем продуктов намного ценнее, чем наяривание на кортежи.
1. sound_right Автор
  29.07.2025 06:54
  #28631958
  Да, согласен, бизнес платит не за красивый код, а за работающий продукт. На собеседовании, как правило есть секция, написать автотесты, в статью это не включал, так как супер специфик кейс, но там тоже все плохо. Речь именно про AQA позиции
  
  Встречаются кандидаты, с умеренным опытом, но как говорится: сразу видно человек "шарит в этой теме" и все у него ок, начиная с теории, заканчивая задачками и практикой. Думаю если кандидат работал 1 - 2 года, но при этом вкладывался в свое развитие, не обязательно на основной работе, он покажет очень хороший результат
  1. Nalivai
    29.07.2025 06:54
    #28634456
    Красивый код и работающий продукт это элементы связанные гораздо более плотно чем вы думаете

pastop
29.07.2025 06:54
#28631768
Добрый день, спасибо за статью. Если можно, укажите куда мне не ходить на собеседования (название компании), просто чтоб не испытывать муки совести от того какой я бесполезный. Но как мне кажется нельзя быть таким категоричным, я предполагаю что вы вырвались с какого-то собеседования и на эмоциях изложили это "базовые вещи". Для вас это база, для меня искреннее изумление из разряда "а что, так можно было?", "а, так вот как это называется". Мне не удалось почитать учебники, походить на курсы и т.д., я просто писал код. И таких как я еще очень много, и я искренне надеюсь что когда я буду искать новую работу, мне попадутся люди, которые заглянут чуть глубже и не отправят меня в ж... потому что я не знаю какого-то названия. А может я совершенно не прав, и выбраны вырванные из контекста примеры, потому что то что вы показали вообще не должно существовать.

P.S. не пишу в резюме про синьоров и т.д. т.к. не понимаю смысла этих терминов, по-видимому вечный джун
1. sound_right Автор
  29.07.2025 06:54
  #28631992
  Добрый день! Благодарю вас за комментарий и за то, что поделились своим опытом. Статья была написана на основе выборки из нескольких сотен собеседований и отражает обобщённые наблюдения, а не эмоции от конкретной ситуации.
  1. TonySi
    29.07.2025 06:54
    #28634232
    Это вы на сотнях человек так самоутверждались? Типа, ах какие все кругом тупые?
    
    Собственно, а вам шашечки или ехать? Что-то не похоже, что специалисты-то нужны
    
    sound_right Автор
    29.07.2025 06:54
    #28634272
    Цель собеседования - не самоутверждаться, а убедиться, что кандидат сможет эффективно решать задачи без "забивания гвоздей микроскопом". Бизнесу нужны люди, которые понимают базу и применяют инструменты по назначению. Это не про "тупых" или "умных", а про соответствие заявленным компетенциям и реальной работе.

stas_dubich
29.07.2025 06:54
#28631784
Не ради высмеивания, но после той же Java или Go - питон выглядит как галюцинация какая то, максимально не очевидно и запутанно. Перед тем как писать бизнес логику - нужно заучить все эти «особенности» питона, потому что маразм by design

В целом справедливо и для js во всех вариациях от фронта до бека

Возможно просто кандидаты изначально выбрали не ту технологию, потому и валяться на собесах )
1. sound_right Автор
  29.07.2025 06:54
  #28632000
  Добрый день! Как будто тут каждому свое, вкусовщина. С python начать проще, поэтому и выбирают
1. Q3_Results
  29.07.2025 06:54
  #28633038
  Не ради высмеивания, но после того же Python или Lua - Жава выглядит как галлюцинация какая то, максимально не очевидно и запутанно. Перед тем как писать бизнес-логику - нужно заучить все эти «особенности» жавы, потому что маразм by design
1. MountainGoat
  29.07.2025 06:54
  #28633084
  нужно заучить все эти «особенности» питона
  
  Вообще не нужно. Нужно не писать как макака лицом по клавиатуре. И помнить ,что отсутствие типизации это хорошо для программ до трёх страниц кода. После достижения трёх страниц, всё удаляем и переписываем заново, тщательно следя за типизацией.
1. DarthVictor
  29.07.2025 06:54
  #28634182
  В Java проверка на равенство строковой константе обычно выглядит как
  
  "value".equals(variable)
  
  что тоже выглядит странно для разработчиков на других языках. Равно как тройное сравнение в JS со всем кроме null, и простыня из сравнений с err != nil в Go. Но те кто регулярно пишет на обсуждаемом языке привыкли к этому и им удобно.
1. Nalivai
  29.07.2025 06:54
  #28634498
  Питон гораздо более лоялен к откровенно плохому, и зачастую нерабочему коду. Питон с радостью позволит запустить код в котором откровенная беда, и честно постарается ее выполнить, а при достаточно креативном игнорировании ошибок, программа на питоне будет выполняться даже при наличии невалидных и невыполнимых инструкций.
  
  Но заучить все-таки надо не это, а правильные, вполне логичные, способы работы, а всю эту случайно работающую шизофрению обходить стороной

fixikus
29.07.2025 06:54
#28631818
Эх. У меня ситуация обратная, тоже фейспалм, но уже на собеседующих, бывают такие неадекваты, что ужас просто, приходиться доказывать элементарные вещи, которые гугляться за 30 сек, но нет, у них же методичка и там все верно априори
1. sound_right Автор
  29.07.2025 06:54
  #28632054
  По ту стороны сидят такие же трудяги, которые также могут чего-то не знать. Ну или спрашивать чего сами не знают. Это страх большинства собеседующих, узнать, что кандидат умнее
  1. fixikus
    29.07.2025 06:54
    #28632818
    Ну умнее кандидат вас и что? Что в этом плохого? Или это оверквалифаед для вас? Странная логика: тупой - плохо, умный - плохо, а что тогда хорошо? Чтобы была квалификаци веслами гребсти и лишних вопросов при этом не задавал?
    
    sound_right Автор
    29.07.2025 06:54
    #28632878
    Вы немного передергиваете. Я нигде не говорил, что "умный кандидат = плохо". Речь о том, что интервьюеры тоже люди, и бывают разные ситуации: кто-то спрашивает по методичке, кто-то, что знает сам. Если на собесе есть ошибка - это повод обсудить, а не уходить в крайности вроде "тупой/умный". Цель ведь одна - найти совпадение ожиданий и навыков, а не мериться, кто умнее
    
    fixikus
    29.07.2025 06:54
    #28632966
    Какая статья, такие и комментарии. Из ваших слов я понял, что если я не знаю то, что знаете вы ( точнее то, что вы состряпали в качестве примеров, покуря линолеум и документацию), при этом подняв из пепла в прод несколько крупных коммерческих проектов и еще несколько написав с нуля, то я, оказывается, опыт себе просто накрутил и все, вот такие у меня выводы
    
    zamir__zakiev
    29.07.2025 06:54
    #28634438
    Не надо ничего обсуждать. Нет никаких гарантий, что ни одну сторону правильный ответ не заденет за живое и это не выльется в бессмысленный спор и трату времени. Интервьювер должен просто это себе отметить вопросиком и пойти дальше. После собеседования проверить.
    
    fixikus
    29.07.2025 06:54
    #28634948
    Прикол в том, что для интервьюера это не должен быть красный флаг, так как интервьюируемый аргументированно доказывает факты, а по сути заполняет белые дыры в знаниях итервьера, то биш есть неплохой шанс того, что на работе (если возмут) он будет делать то же самое при виде дичи, а не закрывать глаза на нее. На деле, наоборот - как красная тряпка. Я понимаю если контора маленькая, типо конкуренция, все дела, все ясно, но в крупных корпорациях то почему так?...видимо привычка
1. zamir__zakiev
  29.07.2025 06:54
  #28634424
  у них же методичка и там все верно априори
  
  Ооо, часто такое встречаю. Как-то интервьювер даже гуглить пошел и потом нехотя свою ошибку таки признал. Причем же ничего не мешает отметить себе, что момент спорный, проверить после собеседования (возможно, даже благодарность кандидату написать за новую информацию), но нет, надо спасать свое эго и начинать спор во время собеса, выставляя компанию не лучшим образом.
  1. fixikus
    29.07.2025 06:54
    #28634904
    Да, желание там работать отпадает начисто, так как не понятно сколько он уже таких интервью провел и сколько там уже работает человек, для кого свои знания не важны, а важно лишь приземлиться поудобнее

WaldemarsonTheForester
29.07.2025 06:54
#28631824
Самое-то забавное, что у многих опыт не накручен, пишут совершенно честно. Без знания базы вполне можно успешно работать годами. Не только Python касается. Плохо это или хорошо - вопрос открытый. На практике - когда как.
1. stas_dubich
  29.07.2025 06:54
  #28631934
  На самом деле тут очень просто все)
  
  Сам ЯП это лишь инструмент, и в конечном итоге нужен для решения бизнесовых задач, и тут можно выделить 3 критерия:
  
  - Делает ли алгоритм то что нужно бизнесу ?
  - Насколько быстро и стабильно работает ?
  - Насколько трудно масштабировать и расширять ?
  - Можно было бы добавить еще цену, но цена штука такая, условно в крупной аутсорс компании фича может стоить 1 млн, а фрилансер Петя сделает за 10к, и по качеству будет одно и тоже
  
  Это то что действительно важно, все остальное лишь вариации
  
  - Можно сделать на if else, можно придумать 157 абстракций (как в Java)
  - Можно монолит, можно на каждую функцию микросервис
  - Можно написать на PHP, можно на ASM
  - Можно на память знать обход дерева, можно не знать
  - И еще 100500 вариантов
  
  Но все это не важно от слова совсем, важно что в итоге получает бизнес)
1. akod67
  29.07.2025 06:54
  #28631942
  Самое страшное, что вот именно такие собеседующие совершенно искренне считают, что они делают благо для компании, отсеивая людей с "накрученным", но на самом деле реальным опытом по своим оторванным от жизни критериям. А эти кандидаты могли бы принести на много больше пользы для компании, чем "олимпиадники". Одна из граней деградации современной айтишки.
  1. WaldemarsonTheForester
    29.07.2025 06:54
    #28632006
    Все же от ситуации зависит. Хотя компаний, где такой подход идет на благо, гораздо меньше, чем компаний, где он вредит.
1. sound_right Автор
  29.07.2025 06:54
  #28632282
  Встречается, да, особенно если место тепленькое и пригретое. Можно так насидеть 10 лет и ничего не знать
  
  Просто потом никому не хочется исправлять чужие ошибки и чужой код в реальной работе. А также тратить время на ревью и объяснять, почему писать так плохо:
  
  if a == True: ...
  1. Q3_Results
    29.07.2025 06:54
    #28633046
    Почему так плохо? В дзене питона написано первой строкой: явное лучше неявного. Человек написал явное условие, он ожидает, что значение у переменной a будет True. То, что придумали сокращать до if a:.., это противоречит первому принципу дзена
    
    cruiseranonymous
    29.07.2025 06:54
    #28633076
    В дзене питона написано и что "один и только один способ сделать что-то". И три вида строк, а так-же циклы и comprehension-ы хором "ага, ага".
    
    Q3_Results
    29.07.2025 06:54
    #28633094
    Неправильно цитируете:
    
    Должен существовать один и, желательно, только один очевидный способ сделать это.
  1. Cekory
    29.07.2025 06:54
    #28633356
    А я вот побегал по граблям с Truthy и Falsy и мне теперь кажется, что именно так писать очень хорошо. Только лучше `is True`.
    
    Читая ваши вопросы? вспомнился Пелевин. Крайне неточная цитата не помню из какой книги: "Человек часто забывает, что помимо ответов "Да" и "Нет", всегда можно ответить "Да пошли вы ...". И правильный ответ на все ваши вопросы, за исключением вопроса про comprehension: "За такой код надо бить по морде".
    
    Сама проблематика, затронутая в статье имеет смысл быть. И чтобы отсеять людей, у которых все только в резюме, имеет смысл задавать вопросы без экзотики, без подвоха и без конструкций, которые надо избегать в реальноq жизни. Например, задачу про FizzBuzz. Одно время я просил написать код, который считает среднее арифметическое по массиву чисел. Некоторые числа равны 99, их из расчета среднего надо исключить. Сторонние библиотеки использовать нельзя. Удивительно, как много людей можно отсеять на этой как бы "задачке".
    
    Nalivai
    29.07.2025 06:54
    #28634686
    Только лучше is True.
    
    Это если aэто простой тип, а если кастомный который заимплементил свой __eq__() то is его проигнорирует, а это может быть не то чего вы ожидали при вызове.
    
    Cekory
    29.07.2025 06:54
    #28634724
    Интересно, а есть какой-нибудь пример? У меня ожидания, что если `a` не True, то `a is True` всегда будет False. Разве не так?
    
    Nalivai
    29.07.2025 06:54
    #28634900
    a is True будет False, а вот a == True уже не обязательно, и если владелец класса заимплементил свой __eq__() то зачастую он и ожидает что он будет вызываться во всех случаях сравнения.
    
    class IsNumberEven: def __init__(self, value): if value % 2 == 0: self._is_even = True else: self._is_even = False def __eq__(self, value): if isinstance(value, bool): return self._is_even a = IsNumberEven(5) b = IsNumberEven(2) print(a is True) print(b is True) print(a == True) print(b == True)
    
    False False False True
    
    Первые два результата - сравнение инстанса класса с синглтоном True, вторые - вызов метода __eq__() из класса.
    Пример синтетический, но такое встречается регулярно например в numpy, и в реальности это зачастую имеет внутренний смысл.
    
    Cekory
    29.07.2025 06:54
    #28634974
    Так я и пишу is True, чтобы у меня в условие было True только если переменная - синглетон True, а не какое-нибудь Truthy значение или выражение, которое выдаст True в результате каста типов.
    
    В примере ниже от @krakotay : "А там a может быть и False, и True, и "Error with API" - в a может быть, допустим, 1 и в if a == True тоже выполнится не та ветка.
  1. krakotay
    29.07.2025 06:54
    #28633370
    А там a может быть и False, и True, и "Error with API"
    
    >>> a = "Error" >>> if a: ... True ... else: ... False ... True >>> if a == True: ... True ... else: ... False ... False >>>
    
    А ты приходишь и объясняешь, что == True надо убрать.

musk
29.07.2025 06:54
#28631946
Ну я пишу лет 8 в том числе и на питоне, и сходу тем не менее затруднился с ответом на {("a", [1, 2]): "value"} и print((x for x in range(3))). А за 55 == True is True надо сразу бить по рукам на месте. Наверное, я не знаю базу? Или просто в нормальных условиях такую дичь на код ревью не пропускают, и вообще такое в голову не приходит? Питон, скажем так, довольно специфичный язык, а автор, видимо, нанимался загадывать ребусы и выводить на чисту воду этих наглых "накрутчиков". Я вот смотрю больше на способность кандидата мыслить, коммуницировать, рассуждать и предлагать варианты, что куда важнее, чем знание 100+ подводных камней питона. И в качестве теста на написание кода идут самые обычные кейсы.
1. m03r
  29.07.2025 06:54
  #28631982
  Когда я искал свою первую работу, меня на собеседовании спрашивали, что выведет в PHP конструкция
  
  echo print "";
  
  или как-то так. Прикол в том, что print всегда возвращает 1, и за годы работы это знание не пригодилось мне ни разу.
  
  Не так давно я узнал правильный ответ на этот вопрос: «я не знаю, что выведет этот код, но знаю, что сделаю я: git blame»
1. sound_right Автор
  29.07.2025 06:54
  #28632534
  Отвечаю на этот вопрос в комментариях уже не первый раз :) Ни у кого в последствии нет желания, интереса и времени, объяснять на ревью, как работает наследование в python и почему писать if a == True плохо. Собеседование не состоит только из таких задач, это лишь примеры, которые почему-то воспринимаются, как весь собес. Возможно мне нужно было это явно объяснить в статье, хотя мне казалось это очевидным

vagrius
29.07.2025 06:54
#28632032
Парадоксально, но знание "базы" может свидетельствовать о том, что кандидат только недавно прошел какие-то курсы по питону и просто много ходит по собеседованиям. Если такой человек выступает в качестве интервьюера и спрашивает подобное - возможно, он в свою очередь тоже часто проводит собеседования, или занимается преподаванием языка. В ином случае не совсем понятно, для чего все эти сакральные знания держать в голове. И уж тем более на основе пары таких вопросов делать выводы о профпригодности. Может статься, что оба субъекта никогда в реальной жизни не применяли подобные знания и не применят, просто сошлись в игре под названием "собеседование", негласные правила которой как бы подразумевают, что надо знать "базу".
1. sound_right Автор
  29.07.2025 06:54
  #28632546
  Знание "базы" само по себе не делает человека хорошим инженером, особенно если оно от "свежих курсов". Эти вопросы служат как быстрый фильтр на базовое понимание, чтобы отделить людей, которые действительно работают с языком, от тех, кто его видел только в теории. А полноценное собеседование, конечно, включает практические и прикладные задачи. В статье лишь выборка
  1. whippoorwill
    29.07.2025 06:54
    #28632922
    Вот я на джуна пытаюсь. Правда до собесов не доходило пока но это ладно. Есть небольшой сайт на джанго, vue, который я развернул на амазон сервере. Делал в рамках обучения ну и сайт как резюме портфолио. Т.е. практический опыт написания работающего приложения есть. Но также я не писал на питоне почти пол года. Писал фронтенд на джаваскрипте, а теперь читаю другие вещи заделом на будущее, думаю попробовать нво фриланс податься и заполняю пробелы. И по вашему вместо этого я должен дрюкать шаблонные задачки на питоне чтобы не забыть то что я могу в доках почитать или у ИИ спросить? Серьёзно?
1. zamir__zakiev
  29.07.2025 06:54
  #28634460
  А это классика собеседований в айти сейчас. Может, ты и крутой спец с большим опытом, но без зазубривания всех таких неочевидностей рискуешь даже скрининг у HR не пройти.

nerudo
29.07.2025 06:54
#28632034
А главное, если бы его взяли - работал бы не хуже всех прочих.

WaldemarsonTheForester
29.07.2025 06:54
#28632044
И если вы честно пашете, растёте и отвечаете за базу — вы уже не в большинстве. Вы — в меньшинстве.

А зарплата при этом как у большинства. Откуда и...
1. sound_right Автор
  29.07.2025 06:54
  #28632558
  Да, может быть ощущение, что рынок усредняет зарплаты и это демотивирует. Но как показывает практика, специалисты, которые растут и развиваются, в итоге уходят в более интересные роли и проекты с совсем другим уровнем ЗП

KirillBelovTest
29.07.2025 06:54
#28632060
Так и не понял из статьи эти ваши питоны - это база или не база?

Ilirium
29.07.2025 06:54
#28632080
У вас там в первом же пояснении ошибка:

Python интерпретирует выражение как:(55 == True) and (True is True)

Должно быть:

Python интерпретирует выражение как: ((55 == True) is True)

Дальше вы поясняете этот пример корректно. Но после этого примера читать статью уже не стал.
1. AZverg
  29.07.2025 06:54
  #28632508
  В python как раз пример автора корректен. Не пишу много на python и специально посмотрел документацию
  https://docs-python.ru/tutorial/operatsii-sravnenija-python/
  
  В своём случае стараюсь не использовать малораспространённые и значительно отличающиеся от других языков конструкции. Обычно даже в одном проекте пишешь/проверяешь не на одном языке и запутаться достаточно просто.
  1. Ilirium
    29.07.2025 06:54
    #28632976
    Ваша ссылка не ведет на документацию. Это какой-то сайт от третьей стороны с уроками. Насколько эти уроки корректны, я даже не берусь судить, и тем более, не буду тратить свое время на его чтение.
1. sound_right Автор
  29.07.2025 06:54
  #28632584
  В данном случае приоритет операторов другой: == выше, чем and, а is и and разделены. Python интерпретирует это как (55 == True) and (True is True). Можете проверить в REPL - результат будет False.
  
  Но после этого примера читать статью уже не стал.
  
  Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
  1. Ilirium
    29.07.2025 06:54
    #28632662
    В общем случае, если REPL выдает тот же самый результат, вовсе не означает, что интерпретация выражения работает так, как вы описали. Согласны ли вы с этим утверждением? Входит ли оно в базу?
    
    Дальше, разберем по порядку, как работает исходное выражение: 55 == True is True. Такое выражение можно переписать с использованием скобок: ((55 == True) is True). Ну и вообще подобные выражения для лучшего понимания вначале следует записать со скобками. Итак, сначала вычисляется (55 == True). Его результат будет False. Затем этот результат подставится дальше: False is True. Его результат будет False.
    
    Ваше выражение (55 == True) and (True is True) дает такой же результат, но оно не является результатом интерпретации Python исходного выражения.
    
    Что касается:
    
    Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
    
    Вы знаете, информации очень и очень много. Можно считать, что бесконечное количество. Мое же время дифицитно и ограничено. Зачем мне искать в вашей статье что-то полезное (и проверять на ошибки), если я уже вижу, что вы ошибаетесь в первом же примере?
    
    Кроме того, сам посыл статьи "кандидат сбежал в слезах" у меня не добавляет желания смотреть статью дальше.
  1. Veritaris
    29.07.2025 06:54
    #28634046
    Единственный правильный способ узнать как Python интерпретирует это выражение – это
    
    import dis dis.dis("55 == True is True") 0 RESUME 0 1 LOAD_CONST 0 (55) LOAD_CONST 1 (True) SWAP 2 COPY 2 COMPARE_OP 72 (==) COPY 1 TO_BOOL POP_JUMP_IF_FALSE 4 (to L1) POP_TOP LOAD_CONST 1 (True) IS_OP 0 RETURN_VALUE L1: SWAP 2 POP_TOP RETURN_VALUE
    
    Вы же предлагаете на экзамене, угадав правильный ответ с первого раза, на вопрос экзаменатора "покажите решение" ответить "а вы проверьте, ответ подходит"
1. slsktnkv
  29.07.2025 06:54
  #28633264
  Попробуйте угадать, что выведет 55 == True is False
  1. Ilirium
    29.07.2025 06:54
    #28633442
    Да, не угадал, спасибо за пример. Я как-то не задумывался, что у is выше приоритет, чем у ==. Со скобками у нас будет следующее выражение: 55 == (True is False).
    
    Исходное сообщение из поста тогда корректно записать так: 55 == (True is True). И эта запись в любом случае не соответствует записи автора: (55 == True) and (True is True).
    
    valentinoshm
    29.07.2025 06:54
    #28634410
    a = 55
    
    55 == a is a

Mr_Boshi
29.07.2025 06:54
#28632116
Спасибо за статью. Понимаю, что иногда душа болит за то, что нахватавшиеся по верхам и не знающие корневых принципов работы ЯП хотят многаденяк. Кажется, что без знания некоторых вещей из показанных примеров все-таки можно писать годный код, но я не программист, хоть и приходится писать код на Python иногда.

Однако вот пример с def append_to_list(item, my_list=[]) меня, честно говоря, расстроил. Для меня не интуитивно, что при вызове функции без указания аргумента my_list не происходит создания нового списка и такое поведение интерпретатора мне кажется неправильным. То есть если в каких-то примерах действительно можно поразмыслить и понять, что {x for x in range(3)} -- это не словарь, т.к. тут нет пар key-value, но в примере с append нужно именно знать, что питон -- ленивая задница.
1. sound_right Автор
  29.07.2025 06:54
  #28632608
  Добрый день! Благодарю за ваш комментарий!
  
  Понимаю, что иногда душа болит за то, что нахватавшиеся по верхам и не знающие корневых принципов работы ЯП хотят многаденяк. Кажется, что без знания некоторых вещей из показанных примеров все-таки можно писать годный код, но я не программист, хоть и приходится писать код на Python иногда.
  
  У каждого свои приоритеты, кому-то просто не хочется потом тратить часы и объяснять на ревью, почему писать if a == True плохо и как работает наследование в python
  
  Однако вот пример с def append_to_list(item, my_list=[]) меня, честно говоря, расстроил. Для меня не интуитивно, что при вызове функции без указания аргумента my_list не происходит создания нового списка и такое поведение интерпретатора мне кажется неправильным. То есть если в каких-то примерах действительно можно поразмыслить и понять, что {x for x in range(3)} -- это не словарь, т.к. тут нет пар key-value, но в примере с append нужно именно знать, что питон -- ленивая задница.
  
  Да, кажется чем-то не очевидным. Но после пары раз, когда эта "ленивая задница" развалит нам весь прод, уже на такие вещи начинаешь смотреть внимательнее

terrier
29.07.2025 06:54
#28632184
Статья имеет потенциал набрать комментарии, так что рискну ворваться с оффтопом.
А зачем вообще сделали так что
def append_to_list(item, my_list=[]):
создает my_list только один раз? Выглядит как странное поведение и очевидный источник ошибок. "Потому что это изменяемый тип" вообще не аргумент, это типа "Если вы набираете на нашей клавиатуре букву А, то она ломается, потому что А - это гласная".
Кажется что даже запрет передавать передавать изменяемые типы как аргументы по умолчанию был бы лучше.

Я помучал поисковики/чатботов на этот счет выдают аргументы типа
- Нуууу, производительность
- Нуууу, можно сделать на этом мемоизацию и еще специфический синглтон

Выглядит сомнительно если честно. Может это какое-то тайное питонисткое знание, которое знают только люди и кто-то может его поведать? Может есть какое-то Rationale стандарта или хотя бы мемуары разработчиков в которых рассказано почему так сделано и почему это не исправили когда был несовместимый релиз.

( я если что не питонист, но честно хочу разобраться без набросов и претензий )
1. sound_right Автор
  29.07.2025 06:54
  #28632630
  Добрый день! Благодарю за комментарий!
  
  - Нуууу, производительность
  - Нуууу, можно сделать на этом мемоизацию и еще специфический синглтон
  
  На самом деле это и есть основные принципы зачем так сделано. А почему не сделать по другому - думаю нужно спросить у core девелоперов python. Или эксперты в комментариях подскажут :)
1. warkid
  29.07.2025 06:54
  #28633020
  "Тайное питонистское знание" в том, что не делайте так - значениями по-умолчанию ставьте только неизменяемые объекты. Как None, например. А мутируемые делай в каких-то ну очень специфических ситуациях если хз ну прям очень надо.
1. Juri7788
  29.07.2025 06:54
  #28634170
  Да, сделали для скорости, что умолчательные аргументы вычисляются один раз.
  
  А так то по смыслу модифицировать пусть и изменяемые объекты в функции это лучше осторожно. В функциональном программировании так нужно возвращать изменённый объект, но не менять входящий.

wl2776
29.07.2025 06:54
#28632372
Вы уверены, что в первом примере chained comparison?

В https://peps.python.org/pep-0535/ говорится только про операторы < ,> ,<= и >=
Про == и `is` не нашёл.
1. sound_right Автор
  29.07.2025 06:54
  #28632654
  Да, вы правы, классическое chained comparison по стандарту описывает <, >, <=, >=.
  
  В примере в статье это не "классическая цепочка сравнений", а обычная комбинация операторов, где == вычисляется первым, а затем результат участвует в сравнении с is. Поэтому Python и интерпретирует выражение как (55 == True) and (True is True)
  1. wl2776
    29.07.2025 06:54
    #28632680
    Поэтому Python и интерпретирует выражение как (55 == True) and (True is True)
    
    Не согласен.
    
    У == и is одинаковый приоритет, скобок нет, поэтому выражение вычисляется слева направо: `(55 == True) is True` -> `False is True` -> `False`. Никакого `and` тут нет.
    
    Ender2012
    29.07.2025 06:54
    #28633512
    А если так написать то сразу понятно что ваше предположение не верно
    
    >>> 1==1 is True False >>> (1==1) is True True >>> (1==1) and (1 is True) False
    
    wl2776
    29.07.2025 06:54
    #28633554
    Да, я тоже заметил.
    
    >>> 55 == True is True False >>> 55 == True is False False >>> (55 == True) is False True >>> 55 == (True is True) False >>> 55 == (True is False) False
    
    Все-таки, похоже, справа налево вычисление идёт, а не слева направо
    
    Документация.
    
    Operators in the same box group left to right (except for exponentiation and conditional expressions, which group from right to left).
    
    == и `is` находятся в одной ячейке, под Bitwise OR. Значит, я неверно понимаю что такое "operators group"
    
    wl2776
    29.07.2025 06:54
    #28633608
    А, вот в чем дело. Раздел 6.10 Comparisons
    
    Formally, if a, b, c, …, y, z are expressions and op1, op2, …, opN are comparison operators, then a op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z, except that each expression is evaluated at most once.
    
    Т.е. про скрытый `and` автор прав.

Scott_Leopold
29.07.2025 06:54
#28632424
Я ответил на все вопросы из статьи правильно с первого раза! Я python-сеньёр? (Ни одного дня в коммерческой разработке на питоне, для себя писал всякие апи, парсеры и телеграм-боты)
1. sound_right Автор
  29.07.2025 06:54
  #28632646
  Скорее всего вы воспринимаете статью слишком буквально :)
  
  Это всего лишь выборка типовых вопросов, которые встречались на собеседованиях. На реальных интервью обычно проверяют гораздо больше аспектов: архитектуру, опыт работы с проектами, умение решать нетривиальные задачи вживую. Так что правильные ответы на все вопросы статьи это круто, но это не означает автоматического статуса "сеньора помидора"

nivorbud
29.07.2025 06:54
#28632494
```
55 == True is True
```
Что вернёт выражение? Правильный ответ: False. Почему? Потому что это цепное сравнение (chain comparison)

Этот вопрос не на понимание, а просто на детальное знание особенностей конкретного языка (Python).

На понимание (на уровне ЕГЭ хотя бы) можно было бы задать такой вопрос:

Как в питоне из 5 вычесть 3, не используя знак минус?
1. sound_right Автор
  29.07.2025 06:54
  #28632658
  Честно, я немного удивлен тому, что в статье есть и другие примеры, но в комментариях все свелось к обсуждению задачи с операторами :)
  1. nivorbud
    29.07.2025 06:54
    #28632928
    Другие примеры тоже касаются не понимания, а знания/незнания деталей питона.
    
    Человеку, действительно разбирающемуся в программировании, имеющему опыт в языках более низкого уровня (например С/С++), для глубокого понимания всех этих вопросов понадобится несколько минут времени. Например, он с ходу поймет, что в питоне в переменных хранятся не значения, а ссылки на области памяти (он сразу увидит аналогию с указателями в С) и т.д. Большинство вопросов завязаны на знание синтаксического сахара питона. Опытный в программировании человек разберется с этим за минуты. С другой стороны, человек, вызубривший эти нюансы, может не разбираться глубоко в этих темах.
  1. wl2776
    29.07.2025 06:54
    #28633140
    Общий тон статьи можно охарактеризовать как "Смотрите, как я разделываюсь с самозванцами, как я лихо вывожу обманщиков на чистую воду на незнании базы."
    
    При этом, Вы первых же строках показали незнание этой самой базы, притянув в обычное вычисление выражения chained comparison, который и рядом не валялся.
    
    sound_right Автор
    29.07.2025 06:54
    #28633298
    В примере речь шла не про демонстрацию "уникального синтаксиса", а про то, как Python обрабатывает выражения с разным приоритетом операторов. То, что кандидаты на этом сыпались, и было показательно
    
    Если ваше внимание зацепилось именно за термин, это хороший знак - значит, базу вы знаете, и обсуждение статьи для вас не про содержание, а про формулировку. Это нормально: у каждого свой профессиональный триггер
  1. Scott_Leopold
    29.07.2025 06:54
    #28634946
    Потому что она первая, и в первом же примере Вы допустили косяк
1. krakotay
  29.07.2025 06:54
  #28633088
  Имеется ввиду, клавиатурный минус? т.е. решения в духе 5 + (-1 * 3) не подойдут?
  1. HardlinePeak936
    29.07.2025 06:54
    #28633398
    С Python незнаком, но всё равно интересно: как тогда сделать? Какой-нибудь "Math.sub(int, int): int"? Или элементарная замена символа на ключевое слово "a = b sub c"?
  1. nivorbud
    29.07.2025 06:54
    #28633416
    Имеется ввиду, клавиатурный минус? т.е. решения в духе 5 + (-1 * 3) не подойдут?
    
    Да, клавиатурный минус нельзя использовать, да и вообще любой минус (как бы он ни был закодирован).
    
    krakotay
    29.07.2025 06:54
    #28633856
    Понял. Я бы сделал через битовый сдвиг. Увы, не помню по памяти, как он реализуется... но chatgpt мне валидный пример набросал =)
  1. Ender2012
    29.07.2025 06:54
    #28633540
    >>> import math >>> 5 + 3 * math.cos(math.pi) 2.0 >>> 5 + 3 * (complex(0, 1)**2).real #Если вдруг импортить нельзя 2.0
    
    ...и еще 1000 и 1 способ "из ЕГЭ" получить -1
    
    После чего встать и уйти. Работать в зоопарке где задают такие вопросы большого смысла нет.
    
    Ender2012
    29.07.2025 06:54
    #28633764
    Предполагаю что ожидался ответ
    
    >>> import operator >>> operator.sub(5, 3) 2
    
    Он хотя бы про python, но при чем тут ЕГЭ?
    
    wataru
    29.07.2025 06:54
    #28633878
    Еще можно через битовую арифметику. Известная баянистая задача сделать сумму без использования оператора + (рекурсивный вызов sum((x&y) << 1,x^y)). Для вычитания можно сложить с дополнительным кодом. Правда, не факт что эти трюки сработают в таком далеком от железа языке, как питон.
    
    nivorbud
    29.07.2025 06:54
    #28634008
    Для вычитания можно сложить с дополнительным кодом.
    
    Бинго!
    
    5 + ~3 + 1
    
    Человеку, знающему, как хранятся отрицательные числа под капотом, и что на аппаратном уровне вычитание происходит через сложение, дополнительный код сразу придет на ум.
    
    hssergey
    29.07.2025 06:54
    #28633944
    Можно еще:
    
    a = 5
    
    a.__sub__(3)
    
    nivorbud
    29.07.2025 06:54
    #28633986
    5 + ~3 + 1
    
    А ЕГЭ при том, что хранение чисел в дополнительном коде проходят в школе.
    
    nivorbud
    29.07.2025 06:54
    #28633984
    Всё просто. Надо вспомнить настоящую базу, которую дают еще в школе на уроках информатики: отрицательные числа хранятся в дополнительном коде (побитовая инверсия + 1) и на аппаратном уровне вычитания нет, есть только сложение.
    
    Поэтому я бы предложил такой ответ: 5 + ~3 + 1
1. p07a1330
  29.07.2025 06:54
  #28633916
  А переполнение использовать можно? (Я не питонист)
  
  Т.е. отключаем защиту от переполнения, переполняем до -3 и складываем
  1. nivorbud
    29.07.2025 06:54
    #28633960
    
    А переполнение использовать можно? (Я не питонист)
    
    Т.е. отключаем защиту от переполнения, переполняем до -3 и складываем
    
    Близко :). Но только для "переполнения" достаточно вспомнить, как хранятся отрицательные числа в вычислительных системах и о том, что на аппаратном уровне вычитание происходит через сложение.
    
    Поэтому: 5 + ~3 + 1

9241304
29.07.2025 06:54
#28632674
Ох уж эти гении собеседовальщики и их мнимая объективность. А ещё и советы новичкам.

Когда в жизни изучил что-то одно, сидишь на этом стеке 20 лет, то очень сложно дойти до мысли, что люди, работающие со множеством технологий, могут, внезапно, забывать что-то напрочь. Но возможно, до автора когда-то дойдёт)

Ах да. Вот эти вопросы на засыпку - это прежде всего признак выпендрежника, но никак не специалиста)
1. aiminkai
  29.07.2025 06:54
  #28633200
  Люто плюсую.
  
  Кандидат, возможно, запускал не один коммерчески успешный проект. Не в одно лицо, естественно, но проходил этот путь. Осваивал на каждом проекте новый стек. И писал код без вот этих вот тру из тру, а нормальный такой kiss, и ему благодарна бывшая команда.
  
  Утверждать, что он не знает базовую базу из-за вот этого вот?
  
  Удачи автору на собесах. Почему-то вижу, что он даже hr не пройдет
  1. sound_right Автор
    29.07.2025 06:54
    #28633322
    Я понимаю вашу точку зрения, но в статье речь не про людей, которые запускали успешные проекты и работали с разными стеками, а про тех, кто приукрашает опыт и не может объяснить даже основы языка, на котором якобы писал код.
    
    Нормальный KISS-код и успешные проекты - это здорово, и такие кандидаты как раз проходят собеседования легко, потому что быстро ориентируются и могут восстановить забытое. А вот когда в резюме написано "5 лет Python", а на практике человек путает tuple и dict - это уже не про забытое, это про отсутствие опыта совсем
    
    wl2776
    29.07.2025 06:54
    #28633446
    Есть ли вероятность, что кандидат, придя к Вам на собеседование, не увидит этих вопросов?
    
    Знание ответов на эти вопросы это Ваш единственный критерий для определения того, что опыт не накручен?
1. sound_right Автор
  29.07.2025 06:54
  #28633310
  На самом деле в статье вопросы выбраны не как "ловушки", а как проверка базового владения Python. Это не засыпка, а фундамент, тот минимум, который нужен, чтобы не тратить часы на ревью кода с банальными ошибками
  1. EasyGame
    29.07.2025 06:54
    #28633668
    Ложь - 90% это именно вопросы ловушки, про то, что в живом и минимально адекватном коде не встречается. Соответственно если кандидат не зубрила и не говнокодер, для которого увидеть/написать аналог примера с наследованием ежедневная рутина - он ваше собеседование не пройдет - потому-что "накрутил" опыт.
    
    Если интервьюер для проверки базового понимания языка использует не рабочую кодовую базу или, на худой конец, OpenSource репу какой-нибудь тулзы - он априори, чудак ~~на букву м~~.
    
    И единственный валидный совет - держаться от компании и такого интервьюера желательно подальше.
    
    sound_right Автор
    29.07.2025 06:54
    #28633890
    Получается, что у вас в кодовой базе не встречается наследование, comprehension или аргументы по умолчанию? :)
    
    Вопросы из статьи - это не "ловушки", а примеры базового синтаксиса Python, который ежедневно встречается в любом живом проекте. Они не про "зубрёжку" и не про говнокод, а про понимание языка, на котором вы заявляете, что работаете.
    
    EasyGame
    29.07.2025 06:54
    #28634090
    Да нет тут понимания языка. Ну вот вобще нет.
    
    Можно залезть в спеки питона и натаскать еще десяток уникальных примеров кода, объявить их базовой базой - а вот потому что я так решил - знаешь эти случаи - знаешь базу, а нет ну и катись колбаской.
    
    Так знания не проверяют - так почесывают ЧСВ, за счет отсеивания тех кому не повезло (ну или повезло, тут как посмотреть)
    
    andreymal
    29.07.2025 06:54
    #28634144
    В любом ВАШЕМ живом проекте. К счастью, в нормальных проектах такую дичь не пишут, а если кто попытается написать — больно надают по рукам на код-ревью)
  1. HiItsYuri
    29.07.2025 06:54
    #28635032
    Вы тут всюду пишете про какую-то абстрактную базу. А у нее есть конкретика? Что это такое? Где с ней ознакомиться? Через что провалидировать ваше утверждение про "базовость"?

wl2776
29.07.2025 06:54
#28632708
Странно, что нет вопроса про знаки подчеркивания в численных литералах. Ну, раз уж на то пошло, и мы выясняем, насколько глубоко кандидат знает тонкости языка.

Какой будет результат у
```
int("198_1")
```
?

Скрытый текст
https://peps.python.org/pep-0515/

whippoorwill
29.07.2025 06:54
#28632806
Я вот на джуна хочу устроиться но ответов на заявки нет пока. Наверное потому что про опыт не врал. Тем не менее есть проект - сайт на vue django rest framework. Но я на вопросы все эти тупые не отвечу потому что я знаю что я просто буду использовать безопасные конструкции в коде а если будут вопросы - спрошу тот же чат гпт. Зачем мне голову забивать? Чтобы немного быстрее работать? Мне кажется что это чушь и такие собесы не актуальны. Разве не более важно что человек говорит и насколько он понимает основные концепции?
1. sound_right Автор
  29.07.2025 06:54
  #28632886
  Проблема не в том, чтобы "забивать свою голову" редкими приёмами, а в том, что базовые конструкции и особенности языка - это как грамматика в разговоре.
  
  Использовать "только безопасные конструкции" - хорошо, но в реальной работе постоянно встречаются чужие решения, легаси-код и нестандартные ситуации. И если при этом человек не понимает базового поведения языка, он может тратить в разы больше времени на отладку и исправление багов. Поэтому такие вопросы - это не "чушь", а минимальная проверка: сможете ли вы разобраться, если что-то пойдёт не по шаблону
  1. krakotay
    29.07.2025 06:54
    #28633010
    У вас в этом комментарии две пунктуационные ошибки. Тире перед "это" не ставится. И точки в конце нет.
    
    holodoz
    29.07.2025 06:54
    #28634152
    Тире перед "это" ставится. https://gramota.ru/biblioteka/spravochniki/pravila-russkoj-orfografii-i-punktuacii/tire
  1. whippoorwill
    29.07.2025 06:54
    #28633196
    В разы больше времени, да, это очевидно. Но о какой разнице речь? Мне сложно оценить, но кажется что на практике она не должна быть значимой даже если это 10 минут против ну пусть даже 300. Но ведь не должно же такое часто встречаться. Что это за легаси код такой?) Я просто немного не понял статью. Ну и опыта у меня нет. Но блин, 55 == true is true... Если это намёк на кодовую базу которая ожидает кандидата, то вы должны предупреждать и извиняться заранее.

SSukharev
29.07.2025 06:54
#28632846
Он не "убежал в слезах" а пошёл в руководители и вы ещё с ним встретитесь, ни один раз, но смеяться уже будет он, а не вы.
1. sound_right Автор
  29.07.2025 06:54
  #28632892
  Возможно, и так. В статье речь не про конкретных людей и не про карьеры в целом, а про несоответствие заявленного опыта фактическим знаниям на собеседовании. Каждый идет своим путём, и руководителей тоже проверяют, только другими вопросами :)

helgifisher
29.07.2025 06:54
#28632852
панамка с шашечками детектед

SergeyProkhorenko
29.07.2025 06:54
#28632876
Трюкачество - это антипаттерн, а не "фундамент". Такой переусложненный программный код писать не нужно, а узнать, что он выдает, можно простым тестом
1. sound_right Автор
  29.07.2025 06:54
  #28632910
  В статье нет намеренного усложнения, примеры взяты из базового синтаксиса Python (ООП, list comprehension, mutable defaults и т.п.). Это не "олимпиадные" задачи и не трюкачество, а повседневные конструкции, которые реально встречаются в коде и которые важно понимать на базовом уровне
  1. krakotay
    29.07.2025 06:54
    #28632988
    Вы не взяли примеры, вы придумали их сами. Это то самое трюкачество, в котором вас справедливо обвиняют

5oo5ly
29.07.2025 06:54
#28632898
Когда читаю подобные статьи, прихожу к выводу: в подобных компаниях выработаны стандарты для определения годности кандидата, но эти методы не могут точно отобразить качество кандидата. Если это выжимка из пула всех вопросов, то конкретные вопросы не могут точно сказать профи перед нами или дилетант. Поработав на разных проектах и с разным стеком, я понимаю, что все запомнить не возможно, а если код изначально не нагляден, то его не используют. Соглашусь, что базу знать нужно. Но что считать базой зависит от конкретного проекта, где-то важно понимание как это работает "под капотом", где-то важно какой фреймворк для этого подходит.

Gordon01
29.07.2025 06:54
#28633002
Лет 10 назад поставил бы минус, потому что был примерно таким кандидатом "ну я же пушил в прод, там все работало, сотни тысяч клиентов пользуются".

Сейчас руководитель и подписываюсь под каждым словом. Кандидатов нужно проверять в хвост и в гриву.

Раздолбы минусуют и их можно понять.
1. aiminkai
  29.07.2025 06:54
  #28633252
  А никто и не говорит, что собесить не надо.
  
  Негодование, что автор придумал очень специфические проверки и смешивает с хм.. грязью тех, кто этого не знает. Да еще и называет врунами, мол опыт прикрутили. Без пруфов. Клевета?
  1. sound_right Автор
    29.07.2025 06:54
    #28633382
    В статье не было цели "облить грязью" людей ради самого процесса. Я сознательно привёл базовые вопросы, с которыми сталкивается любой, кто реально пишет код на Python больше пары месяцев.
    
    Если человек называет себя Senior QA Automation Engineer и при этом не знает, что изменяемые аргументы по умолчанию работают как одна и та же ссылка или что comprehension в скобках даёт генератор, - это не "специфическая проверка". Это проверка минимального практического опыта.
    
    Поэтому вывод "накрутил опыт" не про каждого ошибшегося, а про тех, кто системно не знает основы, но позиционирует себя экспертом
1. sound_right Автор
  29.07.2025 06:54
  #28633362
  Благодарю за комментарий! Полностью с вами согласен!
  
  У меня та же эволюция восприятия: когда только начинаешь карьеру - кажется, что главное "пушить в прод", а потом всё равно как-то работает. Но со временем, когда отвечаешь за продукт и команду, понимаешь: бездарь в штате - это риск, и дорогой.
  
  И да, минусуют чаще всего как раз те, кто "вроде все делал, но глубины нет". Я провел уже десятки собеседований и вижу: стоит только немного копнуть, и резюме рассыпается. Поэтому проверять кандидатов "в хвост и гриву" - это не вредность, а нормальный подход.

via-site
29.07.2025 06:54
#28633062
Мой непрошеный совет автору - выйти на рынок и походить по собеседованиям. Корона с головы быстро упадет. Упоротые интервьюеры-гейткиперы сделают свое дело!
1. sound_right Автор
  29.07.2025 06:54
  #28633390
  Цель статьи - не "гейткипинг ради гейткипинга", а показать, что базовые вещи действительно важны.
  
  Никто не отказывает кандидату за незнание редких алгоритмов или "олимпиадного трюкачества»" - речь идёт про фундамент языка, который заявлен в резюме.

whippoorwill
29.07.2025 06:54
#28633080
Кстати 65 тысяч это разве не зарплата курьера? А тут даже не про джуна речь а про мидла... Как всегда чем ниже зп тем больше приколов.

А там 100 фигурировала. Невнимательно прочитал. Но зачем тогда писать про 65 было. 100 тоже маловато на мидла, нет? Мне на заводе больше платили когда я в командировке был. А тут какой то неравноценный обмен получается.
1. sound_right Автор
  29.07.2025 06:54
  #28633396
  Вы воспринимаете все слишком буквально, цифры 65 и 100 были приведены для примера и не имеют отношения к реальным зарплатам

Q3_Results
29.07.2025 06:54
#28633130
Поставил плюс.

При всей эмоциональной составляющей и далеко идущих и необоснованных предположениях об опыте соискателей перечисленные примеры реально полезны для всех уровней компетенций.

Я выявил для себя одно правило: после ответа кандидата (правильно или неправильно) на задачу, задаю ему дополнительный вопрос на знание принципа, которому посвящена задача. Это очень сильно помогает понять, на основании чего соискатель так ответил. А если ответил неправильно, знал ли он принцип на самом деле или не смог сразу ответить из-за каких-то причин.
1. whippoorwill
  29.07.2025 06:54
  #28633372
  Мне кажется кандидат если не уверен то должен об этом прямо сказать, и сказать что знает и что не знает о задаче. Если он с покерфейсом отвечает неправильно то разве это не должно быть красным флагом? Ну мол склонность скрывать ошибки и всё такое. Это же потенциальная катастрофа.
  1. Q3_Results
    29.07.2025 06:54
    #28633410
    Всё верно пишете. Это как раз я и стараюсь выяснить вторым вопросом. Просто множество исходов слишком большое, проще держать в голове принцип, что после ответа (любого) нужно выяснить мотив или основание ответа.
1. sound_right Автор
  29.07.2025 06:54
  #28633412
  Добрый день! Спасибо за конструктивный комментарий! Полностью согласен, что уточняющие вопросы после основного ответа дают гораздо больше информации о реальном понимании принципов. Иногда человек может растеряться, но по рассуждениям видно, что фундамент есть.

andreymal
29.07.2025 06:54
#28633142
55 == True is True

Я, питонист с ~15-летним опытом, смотрю на это, и у меня какая-то агрессия и зубы скрипят
1. Q3_Results
  29.07.2025 06:54
  #28633170
  Потому что это предлагаемая зарплата после собеседования до уплаты налогов

FD4A
29.07.2025 06:54
#28633158
- Не важно что вернёт это выражение так как оно не пройдёт код-ревью.
- Но у нас такой код!
- Прощайте.
- Но постойте, вот у нас ещё ромбовидное наследовние, посмотрите какая прелесть!
*убегает*

Pavel-Lukyanov
29.07.2025 06:54
#28633230
Спасибо за статью, интересно было почитать как мыслит интервьюер и оправдывает такие вопросы на собеседованиях.

У меня 3.5 года опыта фулстеком. 2 года на битриксе и задач сложнее вывода карточек в цикле не было, я даже БД ни разу не открывал. Когда понял что это дно и я недоразраб, пошел учить ларавел и реакт, сейчас уже 1.5 года работаю в этом стеке и получается что опыта у меня 3.5 лет, но на собесах когда спрашивают подобные вопросы, они тоже приводят в ступор и к реальным задачам на проектах отношения не имеют и интервьюеру может показаться что я накрутил опыт.

Но я действительно 3.5 лет работал над коммерческими проектами, просто про их сложность никто не спрашивал, а битрикс так это вообще красный флаг в некоторых фирмах. И да в фирме где я работал на битриксе, я под года был вообще 1 разработчиком, сам себе синьер, в целом и сейчас так, нету какого-то тимлида или другого человека на проекте, сам все решаю. Но собес подобный вашему завалил бы… К чему я это все говорю, к тому что не всегда все опыт накручивают, я тому пример)
1. sound_right Автор
  29.07.2025 06:54
  #28633438
  Спасибо, что поделились своей историей! Полностью согласен, что реальный опыт может быть разным, и не всегда сложность задач в прошлом отражает реальные навыки кандидата
  
  Моя статья не про людей, которые честно работали в своей зоне ответственности, даже если стек был простым. Она про ситуации, когда опыт намеренно приукрашивают и не могут подтвердить даже базу.
  
  То, что вы честно пишете про свой путь и открыто говорите о сложностях, наоборот, вызывает уважение - и такие кандидаты обычно быстро догоняют новые требования

HardlinePeak936
29.07.2025 06:54
#28633260
Я один уверено и правильно ответил лишь на первый вопрос? А над остальными посмеялся, пытаясь выбрать предположительно правильный вариант из множества придуманных, не подглядывая в ответы?)

P.s.Я не спорю, подобное может быть удобным и к подобному можно приспособиться, начав эффективно использовать... но для человека из вне это какая-то магия, причём не понимаемая сходу...

P.p.s.Скажите, авторы Python подрабатывают в отделе кадров и/или часто проводят технические собеседования по нему? А то получается подозрительно удобный язык для отсева не владеющих им ;)

svz
29.07.2025 06:54
#28633268
В Java есть класс мысленных задач, которые называются java puzzlers. Там тоже применяется базовый синтаксис, результаты исполнения которого можно вывести, зная "базу". Тем не менее, самые синьористые синьоры поголовно допускают в них ошибки, потому что это именно головоломки, а не типовой продакшн код, с которым они имеют дело ежедневно. Более того, даже если подобное встречается в реальной работе, результат легко узнать при помощи исполнения этого кода.

Ваши примеры - скорее из области головоломок, а не проверки базы.
1. sound_right Автор
  29.07.2025 06:54
  #28633466
  Понимаю вашу аналогию, но в примерах из статьи не ставилась цель устроить головоломку :)
  
  Все задачи - это повседневный синтаксис Python: базовое наследование и MRO, работа со списками и аргументами по умолчанию, comprehension, хешируемость ключей. Эти вещи встречаются в продакшн‑коде регулярно и знать их полезно хотя бы для того, чтобы писать поддерживаемый код без неожиданных ошибок

VitalyZaborov
29.07.2025 06:54
#28633278
Ответ на большую часть вопросов для уровня синьора и выше - "Не делайте так НИКОГДА".

Не важно что вернёт выражение и выпонится ли код вообще, просто не пишите chain comparison с комбинацией "==" и "is". Да и два "is' тоже не пишите. Просто потому что такой код плохо воспринимается и в нём легче пропустить баг.

Наверняка каждый, кто писал функции на Python, хотя бы раз встречал такую ситуацию

Если работал в нормальной компании и не говнокодил сам - вполне мог и не встречать. Довольно странно обвинять людей во вренье просто на том основании, что им не пришлось читать и писать плохой код.

SystemOutPrintln
29.07.2025 06:54
#28633388
Кандидат сбежал в слезах. Про накрутку опыта

А где название компании, в которой работает автор? Ну, чтобы знать, где работают такие рекрутеры, которые настолько гордятся тем, что доводят рекрутеров до слёз, что даже выносят это в название своих статей на хабре.

gohrytt
29.07.2025 06:54
#28633400
Я, конечно, не питонист, но все приведённые примеры выглядят как антипаттерны на которые не то что не надо знать ответ - их в продакшн коде вообще не должно быть

alex_29
29.07.2025 06:54
#28633498
То что человек не смог ответить на ваши вопросы не обязательно говорит о том, что у него нету опыта.
1. sound_right Автор
  29.07.2025 06:54
  #28633548
  Спасибо за комментарий! Конечно, отдельный вопрос или даже несколько не дают полной картины. В статье приведены лишь отдельные примеры, которые хорошо показывают именно знание базового синтаксиса и принципов Python. Знание, который, как правильно, заявлено в резюме.
  
  На реальных собеседованиях это только часть проверки, есть и практические задания, и обсуждение архитектурных решений, и реальные кейсы. Но если человек совсем не ориентируется в базовых вещах, то это, как минимум, сигнал к тому, чтобы копнуть глубже. И как показывает практика, зачастую копать глубже некуда
  1. alex_29
    29.07.2025 06:54
    #28633650
    Ну вы проверяете глубину знаний, а привязываете это к проверке опыта. Опыт может быть и при не столь глубоких знаниях.

wataru
29.07.2025 06:54
#28633558
Вот такие каверзные вопросы совсем не нужны. За такой код надо бить по рукам на код-ревью. И сенъеры с ним почти не сталкивались уже лет 10 к моменту собеседования. Помнить все это наизусть - это не база а бессмысленная зубрежка.

lgorSL
29.07.2025 06:54
#28633686
Код пишется в первую очередь для чтения человеком, и только потом - для компьютера. Особенно это применимо к питону, который медленный донельзя и синтаксическими конструциями косит под английский язык.
```
55 == True is True
```
Что вернёт выражение? Правильный ответ: ...

Правильный ответ: не надо так писать. Chain comparison придумали для того, чтобы записывать условия типа 1 < n < 10, а не для того чтобы запутывать программиста.

Почему? Потому что Python использует ромбовидное наследование и алгоритм разрешения порядка поиска методов (MRO), основанный на линеаризации C3.

Замечательно. А теперь скажите честно - как часто Вы это используете в питоне? И ещё вопрос - а вы пробовали так сделать с классами, у которых в конструкторах есть разные аргументы? И в init в super() получить предыдущий тип в цепочке линеаризации и по этой цепочке попередавать аргументы? Вместо этих извращений намного проще и понятнее использовать композицию объектов, что все и делают.
В языках типа Scala такая же линеаризация, но компилятор всё проверяет в compile time, в питоне я такое просто не захочу писать. Неосторожное изменение в любом классе и всё это наследование в динамическом языке рассыпается как карточный домик.
```
{("a", [1, 2]): "value"}
```
Может ли такой код выполниться без ошибок?

В реальности человек его запустит, код упадёт, а дальше он поймёт что список изменяемый и никакой проблемы не будет.
```
def append_to_list(item, my_list=[]):
    my_list.append(item)
    return my_list
```
То есть my_list не создаётся заново при каждом вызове — вы каждый раз работаете с тем самым списком.

Окей, впервые полезный пример. Вернее, ужасные грабли питона, которые надо обходить стороной. Кстати, тот же Pycharm вам подсветит что аргумент по-умолчанию изменяемый.
```
print((x for x in range(3))) # Вывод: <generator object ...> 
```
И что? Можно прекрасно писать код и никогда не использовать генераторы. Это не ключевая фича языка. То что они при итерировании ведут себя как одноразовый список, но при этом печатаются на экран как generator object - просто ещё одна особенность питона.

Вдобавок, в зависимости от того, что писал человек на питоне, его знания могут сильно отличаться. Например, для ML надо знать numpy и pythorch/tensorflow и можно годами не сталкиваться с асинхронными функциями, а можно писать на сайты и там буквально всё будет асинхронным.

Давайте, представьте что Вы сам на собеседовании и попробуйте скажите без запуска кода, что он выведет:
```
for i in range(2):
    print(i)
    break
else:
    print("end")
```
А это же "база", "основы синтакстиса языка", и не важно что в реальности так практически никто не пишет.

DjUmnik
29.07.2025 06:54
#28633780
А как нынче дойти до технического собеседования?

aiminkai
29.07.2025 06:54
#28633802
Я не очень понял мораль сей басни.

Автор обижен, что программисты без знания как работает тру из тру, накручивают опыт и тем не менее зарабатывают больше его самого?)

Еще и виновных пытается найти.

А ведь все просто. Рынок решает. Кто-то взял спринг, jpa, докер, а еще лучше зерокод и другие готовые шаблоны и выкатил через неделю сервис продажи лабубы. И заработал больше автора раз в сто. Кто сидит и пишет прошивку косморакете, за идею. Обидно? Мне нет. Каждому свое.
1. sound_right Автор
  29.07.2025 06:54
  #28633920
  Вы сильно обобщаете и достраиваете картину за меня :)
  
  В статье нет ни слова про "обиду" или про то, что кто-то зарабатывает больше. Речь о другом - о том, что приписанный опыт легко проверяется на базовых вещах, и это вопрос честности, а не зарплат.
  
  Кстати, люди, которые не знают базы, действительно чаще всего оказываются на проектах "галерного" типа с ограниченными задачами. Рынок это тоже решает.

Megadeth77
29.07.2025 06:54
#28633864
А мне вот сегодня задали
a=5
print(a is 5)
a=45234
print(a is 45234)

ну то есть в историческом разрезе интересно (во 2м питоне было бы True False, а в современных True True)

но вот зачем это знание может пригодиться в принципе и что именно показывает - загадка, это прям эталонная задача из серии "приколы нашего городка"
1. sound_right Автор
  29.07.2025 06:54
  #28633938
  Это не "прикол", а демонстрация разницы между == и is. Числа до 256 кэшируются, поэтому результат может удивлять. Понимание этого нужно, чтобы не путать сравнение значений с проверкой идентичности объектов.
  1. Megadeth77
    29.07.2025 06:54
    #28634000
    А числа больше 256 не кэшируются?
    
    a=45234 b=45234 print(a is b) # python 3.10 True
    
    более того
    
    a=None b=None if 1: a = 45234+1 b = 45234+1 print(a is b) if 1: a = 45234+1 print(a is b) # True True
    
    так что с этим самым интернированием в новых питонах какая то суровая работа произведена, но это примерно то же что от кандидата в недрах CPython заставлять ковыряться, для особых энтузиастов наверняка занимательно, но пользоваться инструментом никак не помогает
  1. Chelyuk
    29.07.2025 06:54
    #28634590
    Это всё конечно интересно. Я так понимаю эту интересную особенность переняли из Java. Там то же любимый вопрос сравнить числа типов int и Integer, через == и equal. И да по умолчанию для типа Integer поведение такое же как и с примитивным типом int до значения 256. Но вот, специально для таких любителей "умных" вопрос я этот параметр переопределял для java машины. Весело было смотреть на них когда поведение, не совпадало с тем, что они ожидали. Ведь это куда важнее понимать, как ты можешь сконфигурировать движок для своего таргета. И какую пользу можно из этого получить. Есть и техники докручивания Java до real-time языка, путем манипуляций со сборщиком мусора и прочих твиков машины. Это вот куда интересней, чем странный код.
1. nerudo
  29.07.2025 06:54
  #28634622
  На 3.10 win/64:
  
  >>> a=45234
  >>> print(a is 45234)
  :1: SyntaxWarning: "is" with a literal. Did you mean "=="?
  False
  1. Megadeth77
    29.07.2025 06:54
    #28634640
    ага, прикол, через repl False, если запустить скрипт то True
    
    (.venv) PS C:\...\Documents\Projects\playground> python Python 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> a=45234 >>> print(a is 45234) <stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="? False
    
    C:\...\Documents\Projects\playground\.venv\Scripts\python.exe C:/.../Roaming/JetBrains/PyCharm2022.1/scratches/scratch_156.py C:\...\AppData\Roaming\JetBrains\PyCharm2022.1\scratches\scratch_156.py:3: SyntaxWarning: "is" with a literal. Did you mean "=="? print(a is 45234) True
    
    nerudo
    29.07.2025 06:54
    #28634664
    Буду проститукой.jpg

verls
29.07.2025 06:54
#28633952
Автор еще не дошёл до полезной мысли, что он удовлетворяет своё эго, вместо решения задач бизнеса. Задача бизнеса закрыть вакансию, а не то чтобы кандидаты в слезах убегали.

Проверять знание базового синтаксиса у сеньоров, это как проверять работу карьерного самосвала в детской песочнице.

Последние 10-лет стараюсь собеседовать людей в формате разговора, основная задача понять как человек мыслит. Вторая задача это помочь человеку нащупать дальнейшие шаги для роста, где он сможет совершенствоваться. Третья задача впитать в себя нетривиальный опыт человека - он тоже многим может поделиться, с чем вы не сталкивались.
1. sound_right Автор
  29.07.2025 06:54
  #28634112
  Я понимаю вашу позицию про "разговор и мышление", и это правильный элемент собеседования. Но важно помнить: если человек не знает элементарных основ инструмента, на котором он "якобы работает", это риск для бизнеса.
  
  Это как нанять механика, который отлично рассуждает о логистике автопарка, но не знает, как снять колесо или что такое ГБЦ. Его опыт может быть широким, но без базовых знаний он просто не справится с типовыми задачами. Зачем бизнесу нужен такой механик?
  
  Поэтому проверка базы - это не "удовлетворение эго", а минимальная защита от того, чтобы не тратить месяцы на человека, который красиво говорит, но не умеет работать с инструментом. А уже после базы действительно важно оценивать мышление и опыт.
  1. Aisho
    29.07.2025 06:54
    #28634290
    Скорее, это вопрос уровня "какой тепловой зазор ГРМ у mitsubishi outlander 2010 года выпуска", на который любой инженер покрутит у виска. Ибо такие вещи нужно читать в справочнике, а не вспоминать. Ну и с текущим темпом развития LLM нужда знать нюансы языка будет снижаться, особенно для таких популярных ЯП, как python. Так что лично я проверю общее умение программировать на уровне задачки 4-5kyu с CodeWars.
1. Tim_86
  29.07.2025 06:54
  #28634580
  Один сеньор рассказывал, что как-то собеседовал кандидата на позицию сеньора. Кандидат был уверенным и казалось эрудированным, сыпал терминами. И под конец сеньор, уже готовый закончить собеседование, решил все-таки попросить кандидата решить пару простых задачек на лайвкодинг. И оказалось, что человек просто не знает языка. "Я был поражен, как можно буквально не знать синтаксис языка, не знать как писать буквы на этом языке, и при этом идти на собеседование на сеньора".
  1. sound_right Автор
    29.07.2025 06:54
    #28634692
    Вот как раз про такие случаи и статья. Красиво разговаривать и "вешать лапшу на уши" умеют многие, а вот подтвердить знания на практике - не всегда. Причём задачи в статье - даже не лайвкодинг, а уровень "расскажи, что делает этот код".

ZhetoN
29.07.2025 06:54
#28634230
изучать нужно не языки, а программирование - стандартные методы решения проблем. В остальном все языки одинаковы, различаются возможности и синтаксис.
Возможно, функциональные языки немножко выделяются в особую категорию, так как редко кто начинает осваивать программирование, например, с хаскела. Но, освоив любой из них, можно перескакивать на любой другой, просто имея под рукой документацию (а в наше время еще и ллм).
Условно, если вы знаете, как работает внедрение зависимостей, то достаточно загуглить, как это реализуется в конкретном языке.
1. Chelyuk
  29.07.2025 06:54
  #28634534
  Позволю с вами не согласиться. Есть важные особенности.
  Например, Golang много взял от Python в смысле синтаксиса. Но Golang статической типизации, а Python - динамической. Golang компилируемый, а Python - интерпретируемый. Да вдобавок ещё у Golang классы отсутствуют он не OOP язык.
  Только Golang заточен под параллелизацию со своими горутинами. А в Python только собираются завезти многопоточность, а в JS - даже не собираются. Так что тут масштабируемость только контейнерами и микросервисами.
  Так что да, подобные задачки нужны только для самоутверждения. А если и код в компании написан таким же образом, то мне прям жалко тех кто с ним работает.
  Но языки и их особенности тоже важно и нужно знать. А ещё и инструменты вокруг языков. Poetry, Maven/Graddle, Conan.io, и т.д.
  А то смотришь код пишет такой что и не разобраться, а объяснить virtual environments не может. Как работать с .env - не знает. Настроить, IDE и то не может.
  И тут проблема, что и LLM может не помочь, чтобы от него правильный ответ получить нужно знать хотя бы ключевое слово.

ddv88
29.07.2025 06:54
#28634240
Задача кадровика и лида уже давно превратилась из "нанять и закрыть потребность в кадре" в "максимально отсеить и задавить, даже самых лучших". Ну и конечно же месяцами создавать видимость бурной деятельности.

Раньше в стартапах был энтузиазм. Ты мог действительно проявить себя, показать свои сильные стороны, улучшить слабые, реально узнать и научиться чему то новому в процессе, без чувства что ты оказывается дурачок, раз забыл как расшифровывается какая то абревиатура.

Сейчас все эти бигтехи, финтехи, маркетплейсы, корпорации это тупо ботофермы, куда пытаются натолкать болванчиков по методичке. Разве к этому все стремились? Идти на поклон к мальчику/девочке, который считает себя успешным HR и QA при этом не понимая отличия java от javascript и бодаться за ставку в 2 копейки?

Nalivai
29.07.2025 06:54
#28634328
По ходу чтения статьи складывается впечатление, что сбежал в слезах как раз-таки не кандидат, а интервьюер.

Напридумывал таких вопросов каверзных, любого завалить могут, а на них никто не отвечает, и еще дурацкими называют, уж на хабре сейчас напишу, что все кандидаты сами дураки, и сами они дурацкие.
1. sound_right Автор
  29.07.2025 06:54
  #28634708
  Да, вопросы, конечно, "каверзные" :) Отличить list comprehension от tuple comprehension и понять, как работают дефолтные аргументы в Python - это прям, наверное, уровень олимпиад. Но ведь это и есть базовое знание языка, которым заявлено владение.

Tim_86
29.07.2025 06:54
#28634352
Великолепная статья. Описанная проблема действительно существует, и в какой-то мере "ломает" найм. По сути, накрутка опыта - это мошенничество. В проигрыше и работодатели, которым всё сложнее найти достойного кандидата (или ещё хуже - принять "накрутчика" без реального опыта, не способного справляться с задачами), и честные кандидаты с реальным опытом, которым всё сложнее пробиться сквозь эту толпу. Советы даны здравые, примеры - неплохие. Откуда же столько минусов, интересно? Не от тех ли, кто публикует статьи в стиле "как быстрее вкатиться в айти и устроиться на первую работу", со скрытыми намёками на накрутку опыта и рекламой телеграм-канала в конце? А такие статьи обычно оказываются заплюсованными. Вот такой контингент.
1. wataru
  29.07.2025 06:54
  #28634392
  Минусы - потому что описанные в статье каверзные задачки не проверяют ничего, кроме знания наизусть стандарта языка. С опытом это знание не коррелирует. Поставленную задачу описанная в статье процедура не решает.
  1. Tim_86
    29.07.2025 06:54
    #28634462
    Они проверяют, действительно ли человек работал на этом языке программирования (как написал в резюме), или нет. Если человек каждый день пишет на языке в течение нескольких лет, он без проблем ответит на эти вопросы. Или по крайней мере сможет рассуждать. Если нет - будет молчать и не знать что ответить, всё именно так как описано в статье.
    
    Один сеньор рассказывал, что как-то собеседовал кандидата на позицию сеньора. Кандидат был уверенным и казалось эрудированным, сыпал терминами. И под конец сеньор, уже готовый закончить собеседование, решил все-таки попросить кандидата решить пару простых задачек на лайвкодинг. И оказалось, что человек просто не знает языка. "Я был поражен, как можно буквально не знать синтаксис языка, не знать как писать буквы на этом языке, и при этом идти на собеседование на сеньора".
    
    wataru
    29.07.2025 06:54
    #28634752
    Если человек каждый день пишет на языке в течение нескольких лет, он без проблем ответит на эти вопросы
    
    Нет, самые матерые сеньеры не будут знать всех этих тонкостей наизусть. Они все как один скажут: "не помню что тут именно происходит, я за такой код ругаюсь на код ревью, сам ничего подобного 20 лет уже не писал".
    
    Рассуждать сможет, да, но желаемого ответа не даст.
    
    И оказалось, что человек просто не знает языка.
    
    Для этого гораздо лучше подойдет fizz-buzz, тестовое задание или даже алгоритмическое интервью (которое еще проверит и смекалку с базой в computer science).
  1. sound_right Автор
    29.07.2025 06:54
    #28634762
    Минусы не из‑за "каверзных задач", а из‑за того, что статья задела за живое. Наследование, comprehension и работа с дефолтными аргументами - это не "знание стандарта наизусть", это повседневная база языка. Эти вещи встречаются в любом рабочем проекте, и их понимание проверяет не память, а умение мыслить в терминах Python
    
    Минусы - это эмоции: никто не любит вспоминать, как на собеседовании "поплыл" на базовом вопросе. Но от этого реальность не меняется: базовые знания важны
    
    wataru
    29.07.2025 06:54
    #28634880
    это не "знание стандарта наизусть", это повседневная база языка.
    
    Да, особенно повсеместно встречаются конструкции вроде 55 == True is True.
    
    rokorok
    29.07.2025 06:54
    #28635024
    Я, например, писал и читал достаточно кода на питоне, но почти никогда не писал на нём в ООП-стиле с множественным наследованием. Поэтому не понимаю, в каких ситуациях это стало "базой". На вопрос про наследование из статьи я бы не ответил, и наверняка я этот ответ забуду через месяц, потому что мне такие примеры не будут встречаться.
  1. sound_right Автор
    29.07.2025 06:54
    #28634768
    Ну и да, заголовок "Кандидат сбежал в слезах" действительно вызывает эмоциональную реакцию - это видно и по комментам. В нём есть доля иронии, но понимаю, что для кого-то звучит по‑детски. Тем не менее тема статьи серьезная - про накрутку опыта и её последствия.
1. sound_right Автор
  29.07.2025 06:54
  #28634746
  Добрый вечер! Благодарю за конструктивный комментарий!
  
  Минусы - ожидаемая реакция. Статья затронула болезненную тему: многим комфортнее, когда на собеседовании "разговаривают за жизнь", а не проверяют базовые знания.
  
  Красиво рассказывать о своем опыте умеют многие, а вот показать его на практике - не всегда. Именно эта диссонанс и вызывает негатив. Но в этом и был смысл статьи - показать проблему, а не гладить всех по голове. Хейт - это тоже обратная связь и показатель, что тема действительно задела за больное

w0lkolak
29.07.2025 06:54
#28634476
Профессиональные программисты высказались, но мне тоже хочется добавить. Я лет 5 разрабатываю проект для замены платного аналога. На питоне. Параллельно иногда скрипты простые пишу. Вот я однажды использовал изменяемый объект в качестве аргумента по умолчанию - получил проблему, решил проблему. Стал всегда писать через if a is None. То есть я сталкивался с этим. Ответил бы я на ваш вопрос? Нет. Я забыл уже, я просто так больше не делаю. Тоже самое с 55==True.

ПМ: лично мне статья понравилась. Напомнила о вещах, которые я когда то тестировал, но забыл результаты
1. sound_right Автор
  29.07.2025 06:54
  #28634796
  Благодарю за комментарий!
  
  Стал всегда писать через if a is None.
  
  Про такие моменты и идет речь в статье. Если человек работал с языком, он узнает конструкцию, вспомнит, что она означает. Думаю увидев код, вы бы тоже сразу сообразили к чему этот пример.
  1. w0lkolak
    29.07.2025 06:54
    #28634876
    Честно, я не вспомнил пока не прочитал ваше объяснение. На вашем собесе я бы завалил вопрос.
  1. wataru
    29.07.2025 06:54
    #28634890
    Если бы вы свои вопросы до такого же уровня опустили, такой негативной реакции бы не было.

Chelyuk
29.07.2025 06:54
#28634490
Давайте сразу определимся, что личный опыт - это всего лишь личный опыт. А не правила верховной инстанции.
Я попробую описать, когда заложенное в статью мировоззрение верно, с моего личного опыта.
Вы считаете, что человек ничем в жизни не занимался кроме Python последние лет 5-10. Желательно все это время он ходил по собеседованиям или сам кого-то собеседовал подобным образом.
У меня на текущий момент подобная проблема, я давно не помню эту базовую мишуру из справочника, потому что могу посмотреть ее в справочнике. Я уже молчу про Copilot.
Но за 13 лет, мне довелось поработать с C/C++, Python, RobotFramework, Java, JS, Golang. Да, я не знаю ни один из них так же хорошо как джун который только на 1 язык и готовился.
И довелось мне работать с этими языками, потому что в тот или иной момент так нужно было проекту/компании.
Но, при этом я могу развернуть сам kubernetes/terraform, могу развернуть проект на стэке Azure, Atlassian, GitLab с пайплайнам, тестированием, quality gates, pre-commit хуками, настройками код стилей для IDE и чтобы вот это все автоматически побежало, и деплоилось без ручных манипуляций.
Когда нужно было поднять проект на JS, а договаривались изначально на Java, просто пошел за месяц освоился с фреймворком, параллельно его поднял и настроил всю обвязку.
Вот интересно, мне узнать. Приходит к вам проект, например. Есть у вас супер Python инженер.
Какой язык и стэк он подберёт исходя из потребностей проекта?
А скажем проект нацелен на Automotive или Embedded? Или другой проект для High Frequency Trading?
Я же надеюсь Senior Engineer не пойдет просить DevOps или ещё кого-то. А способен сам провести простую операцию подбора инструментов для проекта?
1. sound_right Автор
  29.07.2025 06:54
  #28634810
  Спасибо за развернутый комментарий и интересный пример из вашего опыта! Полностью согласен, что senior-уровень - это не только владение конкретным языком, но и умение подбирать стек под задачу, понимать инфраструктуру и интеграции.
  
  Однако статья была именно про случаи, когда резюме "накручивают" под конкретный стек (например, Python + автотесты), а на собеседовании кандидат не может ответить даже на элементарные вопросы по базовым особенностям языка, который указал как основной.
  
  То, что вы описали - это широкий инженерный опыт, и он ценен. Но проверка базовых знаний именно заявленного стека нужна не для "выпендрежа", а чтобы убедиться, что человек действительно работал с тем инструментом, который указал. Если он не помнит нюанс - не страшно, но если он в принципе не понимает, как работает конструкция языка - это другой уровень риска для команды.

iboltaev
29.07.2025 06:54
#28634524
я извиняюсь, а на кой болт куэю, даже если он Automation, нужно это все знать? Вот чтобы что просто? такой код случайно не написать, а даже если написал, существует отладка. Напомнило ситуацию из примерно 2012го, когда я плюс плюсером был, любили задавать задачки типа "что выведет код C++ + ++C", с ромбовидным наследованием, двойным удалением когда семантика копирования не прописана, удалением через невиртуальный деструктор, delete и delete[], битые итераторы и еще бог весть сколько граблей, но это разрабов спрашивали, а не куэев. У меня стойкое чувство, что автор просто пытается самоутвердиться за счет кандидатов.
Для QA нормальные вопросы - это типа "вот у тебя есть регрессионный автотест, который срабатывает через раз, какие могут быть тут приколы" или "какие тесты нужно написать для: вот форма авторизации, вот вот ручка бэкенда, вот веб морда, туда вводишь номер документа, тебе он выдается, все модно-молодежно-асинхронно", или "как хранить и заливать тестовые данные для регресса", ну ченить такое, специфичное и из опыта
1. cruiseranonymous
  29.07.2025 06:54
  #28634620
  Автоматизация - это тоже разработка.
  
  И да, такие приколы и могут вести к "вот у тебя есть регрессионный автотест, который срабатывает через раз, какие могут быть тут приколы" потому что очерёдность запуска и влияние пропущенного на кодревью списка-по-умолчанию. Или double free в тест на плюсах загнать могут "ну это ж не разработка, зачем детали языка знать".
1. sound_right Автор
  29.07.2025 06:54
  #28634826
  В целом, в комментариях уже отмечали, но повторюсь: роль AQA действительно недооценивают. Автоматизатор - это не просто "человек, который запускает тесты", это инженер, который пишет код и поддерживает его в рабочем состоянии месяцами и годами.
  
  Почему важна база? Потому что автоматизация - это тоже разработка, со всеми теми же рисками: плохой код = нестабильные тесты = потерянное время всей команды. Разработчику могут простить баг в продукте (он будет зафиксирован как дефект), а у тестов такой "запас прочности" отсутствует: если они ненадежны, ими просто перестают пользоваться.

i360u
29.07.2025 06:54
#28634714
Вы начинаете с прелюдии, потом пишете:

Начнём без прелюдий.

И, снова, продолжаете прелюдией. На мой скромный взгляд, для программиста, элементарная логика - это и есть та самая База, которой вам, очевидно, не хватает.

Я бы не придирался к подобной ерунде, если бы статья не была посвящена придиркам к ерунде.

Кандидат сбежал в слезах. Про накрутку опыта -13

Вступление

Цель статьи

Задачи. Добро пожаловать в реальность

Операторы

Что говорят кандидаты?

Почему это важно?

ООП

А что отвечают на собеседовании?

Почему это важно?

Вывод

Словари

Давайте спокойно разберёмся

Но почему так сложно?

А ведь задача — из самых простых

Изменяемые и неизменяемые типы данных

Почему?

Что отвечают кандидаты?

А ведь задача — элементарная

Как правильно?

И вывод

Comprehension

Что нужно ответить?

Что отвечают «сеньоры»?

И вывод

Знаете, в чём нюанс?

И вот где боль

И вот что страшно

Откуда берутся такие люди?

А может, всё-таки виноват работодатель?

Надежда на болтовню

Как распознать накрутку опыта?

Советы новичкам

Заключение

Комментарии (221)

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор

sound_right Автор