Comments 550
Спасибо всем, кто высказался - и тем, кто согласен, и тем, кто не согласен. Судя по реакции, статья задела за живое, и это нормально :)
Да, задачи в статье - базовые, но сама форма "что выведет код" вызывает у многих ощущение "подвоха" и ассоциируется с собесами, которые больше напоминают проверку на память, чем оценку инженерных навыков. Возможно, это и стало основной причиной негатива.
Цель текста была не "разоблачить кандидатов" и не "похвастаться сложными вопросами", а показать, как накрученный опыт легко вскрывается на простых примерах. Понимаю, что заголовок и подача получились провокационными и могли усилить эффект.
Спасибо за обратную связь - она помогает увидеть статью глазами других и понять, какие темы особенно триггерят сообщество.
Не изучал змеюку и приоритеты операторов (мало-ли), но в данном случае при любой логике false
55 == True is True
# Рассмотрим вариант с приоритетом у ==
55 == True # false и все автоматом false
# Рассмотрим приоритет у is
True is True # True что потом - смотри выше Так что все кто запоролся на этом вопросе даже 3х месяцев не поработали это 100%
Иногда кандидаты видят тут подвох и финально отвечают True, потому что не может же быть все настолько просто? Если бы было базовое понимание этих операторов, то сомнение не было
Думаю, дело в том, что Python в if-statement ненулевые целые отрабатывает как True:>>if 55:
print('True')
else:
print('False')
>> True
(Если сделать то же самое для if 0:, то выдаст False)
Поэтому для них не очевидно, что 55 == True -- это False.
Проверил на JS, ровно так же отрабатывает. !!55 превращается в true, а вот если !!55 == true, то вернётся уже false
Дык оператор отрицания имеет больший приоритет оператора сравнения
если
!!55 == true, то вернётся уже false
А что конкретно за JS? У меня в devtools FF и Chrome !!55 == true возвращает true.
Сори, а что именно ты проверил?) !!55 == true вернёт true. Здесь 55 будет представлено как булево правдивое значение true, которое при сравнении через == даст нам true. Даже через строгое сравнение там не будет false.
Ну так питон написан на Си, в Си только 0 - даст F
Тоже не питонист, в своем языке я знаю как работают приведения типов при сравнении. Но допускаю, что вполне кто-то может не знать, что будет в результате сравнения 55 == True, потому что им в голову не приходило писать такие условия. А как написали выше if 55 - истинное условие.
Тут опять же проверка на базовое знание языка. Выражения if 55: на самом деле выполняется так: if bool(55):
Ну, а оператор сравнения работает со значениями, поэтому 55 == True вернёт False.
Но если честно, то очень часто такие "элементарные" задачки формулируются таким образом, что они вместо теста на знание языка превращаются в тест на внимательность. Поэтому с ними лучше не переборщить.
Приоритет одинаковый, выражение вычисляется слева направо.
Да, спасибо, я уже разобрался.
Автор замечательно постарался - так идею покорёжить!
Изначально-то речь шла про синтаксис, близкий к математической нотации, и заодно про избавление от лишних вычислений (if 1 < x < 10: или if subset in super_set in hyper_set:). А тут такое...
Впору на Obfuscated Code Contest заявляться. Туда, правда, на С программы берут.
Цитата из вашей ссылки
Best Practice & Common Mistakes
Best Practices:
Use chaining to improve readability.
Ensure expressions make logical sense.
Use parentheses when mixing logical (and, or) and comparison operators for clarity.
Leverage short-circuiting for efficiency.
Readability импрувится прям нереально. И logical sense изо всех щелей так и прёт.
Я как начал изучать питон так и не могу понять почему его превозносят. Отовчсюду прёт странность на странности. Но другого питона у нас нет, приходится пользоваться и знать что есть.
Удобно, быстро.
Я выучил синтаксис и основную часть стандартной библиотеки за 2 недели, читая Dive into Python в метро по дороге c работы - на работу. Дело было в 2008 году, когда еще не было ни PyCharm, ни VSCode. У меня, правда, тогда уже был приличный опыт работы на С/С++ и на Perl :)
не могу понять почему его превозносят
Питон это новый BASIC. Человечество скучает по такому, и вот результат
Чисто питонячий прикол для выражений вида 3>2>1, раскладывается в (55 == True) and (True is True)
И вот после таких операторов у меня постоянно возникает вопрос - а зачем авторам языка понадобилось всё это, если как показал опрос почти (а может и полностью) никто этим не пользуется.
Предположу, что был какой-то ужасно специфический кейс, ради которого это возвелось. Он ломает общую логику и понятность (как какой-нибудь ListScreen, который реализует setText, но в действительности текст не меняет и узнаёшь об этом только зубря документацию) однако остаётся для совместимости. Но я, пожалуй, вернусь к Java. Кажется, что там таких приколов поменьше. Или я уже привык)
Хотя знаете, примеры автора мне ещё одно возможное объяснение подкинули. Питон часто называют очень устойчивым к ошибкам языком. Автор же приводит ситуации, где в других языках (или в нормальном коде) были бы ошибки из-за неопределённости. Т.е. с тем же сравнением - кто вообще будет сравнивать разные типы, ещё и в одну строку с непонятной последовательностью. Но в коде прописано поведение на такой случай (если найдётся какой-то гений, который напишет подобное, чтобы программа хоть как-то, но запустилась).
для сравнений удобно, для других операторов сайдэффект - я сам когда первый раз в это вляпался пол дня сидел соображал это глюк или это я тупой
Чисто питонячий прикол
Сейчас попробовал на Java. Оказывается, у нас тоже можно писать несколько логических операторов:
System.out.println(true == true != false);Но мы так не пишем, предпочитая отдельные выражения соединять через &&, ||, ^. И если бы мне на собесе попался такой пример, я бы наверно тоже запаниковал :) Хотя при обучении мне лог алгебра далась легко, сказался опыт в электронике: я просто представлял (рисовал) электрическую схему и мне всё становилось ясно-понятно :)
Это, в силу левоассоциативности операторов сравнения, парсится как (true == true) != false, и с типами, отличными от bool, уже не прокатит.
А в чем здесь собственно должна быть проблема? Логический оператор возвращает булевской значение, с ним можно ещё что-нибудь логическое сделать, почему нет? У нас и присваивание возвращает значение, и поэтому может в цепочку выстраиваться.
Проблема только в том что "так не пишут", значит выглядит непривычно, значит можно накосячить на собесе :)
Это именно что питонячий прикол, как выше написали.
False == False == False — это не (False == False) == False. И не False == (False == False) тоже.
Это скорее такой один большой оператор сравнения с несколькими операндами, False == False == False вернёт True, потому что значения равны между собой (попарно). Как в математической нотации, а не как в Сях
У питона в этом смысле все очень плохо, и единственный верный ответ на все эти вопросы это "все переписать нормально" а не пытаться запомнить что там где.
55 == True
False
1 == True
True
0 == False
True
55 and True
True
0 and True
0
-1 == False
False
-1 == True
False
55 and True
True
0 and True
0
Это фича...
это правила языка.
Оператор and в Python возвращает:
Первый "ложный" (falsy) операнд, если он есть.
Последний операнд, если все операнды "истинные" (truthy). Причём именно последний в том виде как он есть, а не 1, как казалось бы. Поэтому и "True and 55" вернёт 55 - и это несколько обескураживает, хотя и по правилам.
я вообще не погромист, но мне это всё напомнило картинку....
А
True and 55
это всегда True ?
print(55 and True)
True
print(True and 55)
55
А вот в php 55 == true выведет истину, т.к. это не строгое сравнение.
Да нет, могли и не встретиться с цепочечными операторами, вот я до сих пор не встречался - как раз те три месяца. Но с преобразованием типов постоянно встречаюсь и это надо знать.
Пример очень хороший. Сразу надо подумать о преобразованиях, о порядке вычислений, и как итог оказывается это вообще Chaining comparison о котором большая часть комментаторов даже после прочтения статьи не знает так как поленилась кликнуть по ссылке.
Вы не поняли суть, тут нет вопроса приоритета, это питоновский синтаксис, в котором можно написать:
1 < 5 <= 10 # True
Неожиданно, is тут среди тех операторов, которые поддерживают этот описываемый автором chaining, то есть
{}.get(1) is [2, None][1] is None # True
Давным давно, когда я был мидлом - то ответы на подобные вопросы знал.
Сейчас уже с ходу на половину вопросов не отвечу: стараешься такой код инстинктивно не писать, а когда приходится - то всегда в документацию предварительно можно глянуть.
Приходится в голове держать уже более общие вещи, а такие нюансы хранить вовне.
Правда у меня основной язык C++, но так же приходится много и на python писать, а сейчас ещё Rust прокачиваю. Не считая k8s, react и прочих штук. Так что в голове уже больше хранятся принципы построения ПО, а не какие-то тонкие детали языка.
Так и вопросы сами по себе не сложные, на уровне решения повседневных задач. Эта статья выборка из нескольких сотен собеседований, и как показывает практика, если на базовых задачах все плохо, про паттерны смысла спрашивать нет. От слова SOLID бросает в ужас
Не всегда так конечно, но частенько бывает. Да и сам процесс не мной придуман)
Так и вопросы сами по себе не сложные, на уровне решения повседневных задач
За использование таких условий в реальных задачах нужно бить по рукам.
Уточню:
if 50: - - - хорошо
if 50 == True: - - - плохо
Код, разумеется вымышленный.
В статье по мимо примеров с операторами есть еще другие, попробуйте смотреть шире
Абсолютно все примеры из статьи это примеры кода который никогда, ни при каких условиях, не должен быть написан. Не то что это не код для прода, это код, который не должен существовать, нигде, никогда.
Если бы я хотел написать статью с вредными советами для питона, с контерпаттернами, все ваши примеры там бы оказались.
Если у вас в коде есть хоть что-то из того что вы описали, хоть где-то, единственная ваша обязанность как разработчика это переписать весь код, чтобы этого больше не встречалось. Или уволиться, потому что на этом этапе код может быть фундаментально обречен.
Нет, не "абсолютно все". Те же comprehension-ы - вполне валидные вещи, и место им в коде есть.
Ну и знать как можно написать плохой код, почему он плохой, и почему так делать не надо - это как раз чтобы в прод не попадал плохой код. Ведь код не только писать - но и коллег ревьювить(а им - тебя). И там может попадаться и что-то из примеров из статьи.
И не зная Python можно сказать, что это плохой код и почему именно он плохой, и почему так делать не надо.
Сравнивать куриц с помидорами в любом языке попахивает.
"И не зная (название языка) можно сказать, что (любой кусок кода) это плохой код, и почему ьтак делать не надо"
Компрехеншены это лаконичная форма формирования коллекции. "Не зная языка" утверждать что код с ними плохой... ну, показывает ровно незнание любого языка, да. И иногда попадет в плохой код. Или не попадает.
А вот сказать, из незнания языка, "почему так делать не надо" - не выйдет.
Мой комментарий относился к 55 == True
Да, многие языки эту конструкцию как-нибудь да обработают (некоторые даже по-разному в зависимости от опций интерпретатора или компилятора).
Да, понять или вызубрить, как именно этот говнокод выполнится в десятке языков, которые я знаю, можно.
Но проще бить по рукам тех, кто так делает, а неясный кусок кода - переписать.
Компрехеншены это лаконичная форма формирования коллекции
бляяядь Если вы любите англицизмы, так пишите это слово по-английски, иначе глаза режет. Лаконичная форма формирования коллекции, кстати, называется "Списковое включение" или "генератор списков" (в вашем же примере и генератор кстати есть).
Кстати, сложные вложенные включения, особенно с условиями, часто проще переписать через FOR и IF - становится понятнее даже специалистам по Python, не говоря уже о программистах других языков.
В самом дзене питона просят писать ясно и понятно, а не городить неявные конструкции.
По сути поста, вслед за другими комментаторами, я посоветую искать людей с хорошей логикой и кругозором, а не задротов, которые вызубрили stdlib питона, но несколько функций в класс сложить не смогут.
Хороший Junior, прочитавший спецификацию Python, ваше собеседование пройдёт, а мидл или сеньор - не пройдут, или даже осознанно пройдут мимо, потому что они создают системы, а не зубрят особености реализации.
На собеседованиях в FAANG неспроста спрашивают отвлечённые задачи, а не детали реализации очередного языка.
Компрешоны хорошая вещь, но лично я за без малого 10 лет опыта на питоне встречал только
[... for ... in ...]
Чуть реже dict compression
{x: y for x, y in ...}
А вот (... for ... in ...) я вообще первый раз увидел и так же подумал, что по общей логике это будет кортеж. А оказалось, генератор.
Да, с кортежами это подвох, который лично я воспринимаю как повод посмотреть на знание языка глубже. А практически может вылезти при, например, отладке, вызвав недоумение "а где мои значения?". После чего разница и узнаётся.
Если спрашиваемый не знает именно кортеж там или генератор - да и ладно, то не определяющее, просто памятка "глубже вот этого уровня не заглядывал, ОК".
Не знает, как со словарями работать - уже хуже, как можно не работать со словарями в питоне? Джосны пресловутые перекладывать, запросы кидать или получать...
Не знает конструкцию вообще - жёлтая лампочка "а человек точно с питоном работал?" и повод спрашивать дополнительно по уровню "самую базу".
То есть я вот так - "это база и её всю наизусть знать надо" - не считаю. Но считаю что "это база плюс продвинутая база плюс детали". Базу знать надо, продвинутую очень стоит, детали временами стреляют. Ладно хоть не как в плюсах, не в ногу.
Абсолютно все примеры из статьи
Вы сильно утрируете. В статье приведены примеры с базовыми конструкциями языка: list comprehension, генераторы, наследование и дефолтные аргументы. Это стандартный синтаксис Python, который встречается повсеместно и не является "вредным советом". Цель примеров - проверить знание основ, а не пропагандировать антипаттерны.
Просто трудяги-программисты не оценили ваших трудовых порывов и заявили, что ваши задачки - чепуха какая-то. Кажется, эксперимент неудачный.
В статье приведены:
Чудовищнное применение == и is в одном chained comparison, в котором еще и константы сравниваются с булами. Ни при каких условиях ничего подобного не должно появляться ни в каком коде, это единственный правльный ответ на эту "задачу".
Ромбовидное наследование. Нет. Сразу, просто, без вопросов - нет. "Но частный случай разрешения порядка описан в параграфе номер..." Н.Е.Т. Неееет. Нет.
Многоуровневые конструкции как ключи у словарей. Если это встречается в коде, архитектору необходимо прописать таблеток от шизофрении. Если архитектора нет, то найти и потом уже прописать.
Максимально нелогичное по факту кодифицированное UB с кэшированным объектом по умолчанию. Грязное, неожидаемое поведение. Если это встречается в коде, необходимо улучшить код ревью и может быть подкрутить линтер посильнее. Это ошибка архитектуры.
Задача с рассчетом на "замыливание глаза". Рассчет на то что задача в конце интервью, глаза устали, у жертвы поплывет в глазах и [(([{({ распарсится неправильно. Опять-таки, в реальном мире этого необходимо избегать, скобками не мельтешить, и использовать тайп хинты чтобы не приходилось гадать какие скобки какой тип родят. Если вы обнаружили такую помойку в своем коде, настройте пре-комит хук что-ли или еще какой-нибудь автоформат.
В лучшем случае, примеры написаны с подвохом чтобы "завалить" собеседуемого. В худшем, ваша кодовая база и/или ваш мозг забит антипаттернами настолько что вы считаете что это нормальный код. В обоих случаях вам нельзя собеседовать.
pylint умеет детектить и chain operators и мутабельные дефолтные значения.
https://pylint.pycqa.org/en/latest/user_guide/messages/warning/dangerous-default-value.html
https://pylint.pycqa.org/en/latest/user_guide/messages/warning/bad-chained-comparison.html
https://pylint.readthedocs.io/en/stable/user_guide/messages/refactor/chained-comparison.html
if 50: - - - хорошо
Это тоже нехорошо.
Что такое 50?
Я представляю, как бы вы набирали поваров в французский ресторан. Вместо проверки как он хорошо готовит блюда из меню, вы бы давали плов приготовленный из экзотических продуктов (например из собачатины, личинок жуков и фэйхоа). А потом бы спрашивали повара что это за блюдо, из чего же это приготовлено и почему из них нельзя готовить.
Есть халтурный подход проверки кандидата на "знания и навыки". Эдакое прохождение устного чек листа состоящего из довольно рандомных частностей. Наподобие true is true. Если обобщить то такой подход проверяет то какой кандидат "зубрила". Почему-то в общем техническом менталитете уже давно объединены во едино такие качества как умение цитировать общеизвестные факты(память) и навык в рандомной ситуации владеть доступным инструментарием. т.е. мастерство. Для удобства, если кому-то непонятен термин мастерство, то подойдут многие примеры из области искусства, где используется какой либо инструментарий.
Вопрос о том, что важнее в кандедате, мастерство или феноменальная память, как про мальчика из анекдота, для меня лично не стоит. Халтурный HR-подход, на мой взгляд, заполонил практически все.
Это проверка базового понимания языка и инструментов, чтобы убедиться, что человек сможет писать поддерживаемый код без грубых ошибок. После этого в идут более практические и архитектурные задания, где и проявляется мастерство. Никому не интересно впоследствии тратить часы времени на ревью и объяснять, как работает наследование в Python
человек сможет писать поддерживаемый код без грубых ошибок
В таком случае, вы сами его не прошли. Ведь на полном серьёзе пишете
55 == True is True
и спрашиваете кандидатов, как оно работает
Вопрос из статьи не про то, что так нужно писать код в продакшене, а про понимание синтаксиса Python. Такие проверки позволяют понять, знает ли человек язык, которым он заявляет, что владеет
Обычно такие вещи понимают те, кто работал с Python хотя бы немного глубже, чем на уровне "чтобы заработало"
Т.е. зубрёжка. Там можно проще - наизусть перечислить вообще все встроенные функции, модули и базовые методы. Проверять по чек-листу легко, и как KPI элементарно считать.
Это вопрос уровня опросника рекрутера при первом общении с кандидатом. На собеседовании подобных вопросов быть не должно - вы тратите время кандидата и своё.
Ваши проверки на уровне "вы не смогли вспомнить, что в главе X на странице такой-то Кирила Петрович выпил пунш, значит, вы не читали роман "Дубровский", вам двойка!"
понимание синтаксиса Python
Хороший программист должен лучше всего понимать не синтаксис языка, а принципы правильного написания кода, паттернов и архитектуры. Языки приходят и уходят, а паттерны остаются.
Ни один нормальный программист не напишет код, примерами которого вы мучаете кандидатов. К чему эти проверки на знание нюансов, которые у хорошего программиста даже не вылезут при написании кода?
А нужен ли вам человек, который будет на зубок знать такие тонкости синтаксиса? Он же и код будет писать соответствующе сложно. Потом вам же его читать и ломать голову, как это все будет работать.
тонкости синтаксиса
Жесть, конечно. Наследование, comprehension и работа с аргументами по умолчанию - это не тонкости, а базовый синтаксис языка, который встречается в любом реальном проекте. Цель таких вопросов не "усложнить код", а убедиться, что человек понимает фундамент и не будет допускать ошибок уровня "гвозди микроскопом забивать"
Нормальные вопросы для мидл+ специалистов. Если рука набита, то проблем дать правильный ответ не будет.
Плюс на интервью не только правильность ответов оценивается, но и то, как кандидат рассуждает (и какой бред несёт).
Вы продолжаете отвечать одно и то же игнорируя что вам говорят. Вы же задали вопрос не про то как работает наследование, а про то как питон будет обрабатывать показанный вами кейс ромбовидного наследования. На это может существовать только один ответ - ромбовидное наследование недопустимо, и дважды недопустима ситуация когда у двух родительских классов метод с одинаковым именем. И то что в питоне это не UB а определенное поведение это и есть тонкости, знать которые хороший разработчик не обязан, потому что он никогда не должен оказаться в ситуации когда это существует на практике, а заучивать стандарт просто так это пустая трата времени.
Этот пример не является поддерживаемым кодом, никогда не встречается в продакшене, и на практике не пригождается примерно никогда. В лучшем случае, про это поведение знают те, кто с собеседованию зубрил синтаксис по статьям и видео типа "10 мелочей языка, о которых вы никогда не слышали."
Согласен с вами. Большая часть приведенного в статье кода - это именно какие-то синтаксические изыски, которые в нормальном проекте не пройдут через код-ревью, и человек такое мог даже никогда не видеть. Особенно ромбовидное наследование, которое является антипаттерном в любом языке, в котором оно возможно. Если следовать парадигме чистого кода, основной посыл которой заключается в том, что код должен быть читаемым, то ни один человек такой код никогда не напишет, и по хорошему, от греха подальше, не должен знать, что такой код можно написать. А если и встретит такое в каком-нибудь старом легаси - пять минут гуглежки помогут разобраться.
Приведённые примеры - это не про "плохо читаемый код" или "специальные изыски", а про поведение самого языка, с которым неизбежно сталкивается любой, кто работает с Python. Ромбовидное наследование, comprehension и mutable default аргументы - это не пример "так надо писать", а проверка понимания того, как это работает. Даже если вы лично такого кода не пишете, понимать базовое поведение языка всё равно важно: встреча с легаси, отладка чужих тестов, библиотек или автоматизация.
Приведенный код - это примеры того, что если человек скажет "О, да, знаю такое, сталкивался в своем реальном коде" - то его смело можно гнать куда подальше.
Нормальная реакция специалиста - "Фиг его знает, никогда такой порнографии в коде не видел и не допускал. Если это так в легаси - надо загуглить и подумать, если в новом коде - переделать немедленно".
Спасибо за ваш субъективный взгляд, возможно в будущем напишете статью и расскажите, как правильно. Я уже высказал свое мнение выше в комментарии и в статье
Про это не надо писать статей, это описано в любой книге, статье, блог посте, и комментарии, которые хоть как-то затрагивают то как надо писать код.
Это и есть база разработчика, а не то как какая-то там версия какого-то там языка обрабатывает то что всегда должно быть определено как UB.
Если вы этого не знаете или отвергаете, то это вы не знаете базы.
Статья писалась не как "учебник по языку", а как отражение реальных кейсов с собеседований. Кому-то эта база знакома, кому-то - нет, и именно это и вызывает интерес к обсуждению. Думаю, каждый сам решает, какие темы ему интересны писать и читать :)
И более того первое что мне приходить в голову при виде таких извратов:
python3
<копипаст бреда>
<- тут смотрим что получится, если не слишком очевидно то смотрим по частям
Так может он ищет того, кто отрефакторит говнокод в нормальные паттерны)
Аналогичное мнение возникло. Автор пишет непонятный код и спрашивает как это будет работать называя спагетти азами.
Код должен быть простой и понятный для любой блондинки. А не вот это вот.
В итоге мы не проверяем кандидата а самоутверждаемся.
В примерах из статьи нет "спагетти-кода" - это обычные конструкции языка: наследование, list/tuple comprehension, работа с аргументами функций. Они встречаются в повседневной разработке и относятся к базовым возможностям Python.
Цель - не самоутверждение, а проверка того, что кандидат умеет читать и понимать код на языке, с которым он заявляет опыт работы. Если такой код вызывает сложности, это тревожный сигнал для любой команды.
Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
Код пишут чтобы решать задачи бизнеса а не угадывать из какого класса мы наследуем методы. Если лидер проверяет кандидата на угадывание несуществующих ситуаций, не нужных в реальной работе, это тревожный знак для любой команды (.
Не завышать знания лучше, чем завышать.
А коль завышать советуют и говорят "да все так делают" - то не удивляться спросу о знании деталей с уровней выше.
Поддерживаю, я весь пост понять не могла, нахрен это всё нужно в реальном мире. Щас бы ключ словаря делать списком.
База это понимать, как память очищается, как хороший читаемый код пишется. А в посте бесполезная в работе дичь.
Так что в голове уже больше хранятся принципы построения ПО, а не какие-то тонкие детали языка.
Вот не в бровь, а в глаз, что называется :)
Единственно что... из своего опыта помню пару историй, когда подобный ответ на собеседовании (естественно, со всем возможным пиететом к тонким деталям языка), вызывал близкую к парадоксальной реакцию интервьюеров :( Мол, ну что ж, господин умник, ловите вот такую задачку на принципы построения ПО... Со всеми вытекающими :)
Это база. База. Базовая. Самая обычная.
В реальных боевых задачах база другая от слова совсем. И 10 лет опыта решения реальных проблем продуктов намного ценнее, чем наяривание на кортежи.
Да, согласен, бизнес платит не за красивый код, а за работающий продукт. На собеседовании, как правило есть секция, написать автотесты, в статью это не включал, так как супер специфик кейс, но там тоже все плохо. Речь именно про AQA позиции
Встречаются кандидаты, с умеренным опытом, но как говорится: сразу видно человек "шарит в этой теме" и все у него ок, начиная с теории, заканчивая задачками и практикой. Думаю если кандидат работал 1 - 2 года, но при этом вкладывался в свое развитие, не обязательно на основной работе, он покажет очень хороший результат
Красивый код и работающий продукт это элементы связанные гораздо более плотно чем вы думаете
Просто работающий продукт (точнее скорее MVP) и красивый код (к сожалению) почти никак не связаны.
Поддерживаемый в long-term зрелый работающий продукт и красивый код - очень сильно связаны.
Слышал что примеры Oracle и MS Office не вписываются в эту картину чуть менее, чем полностью. Так что ваше утверждение, как мне кажется, излишне технодрочерскре
Добрый день, спасибо за статью. Если можно, укажите куда мне не ходить на собеседования (название компании), просто чтоб не испытывать муки совести от того какой я бесполезный. Но как мне кажется нельзя быть таким категоричным, я предполагаю что вы вырвались с какого-то собеседования и на эмоциях изложили это "базовые вещи". Для вас это база, для меня искреннее изумление из разряда "а что, так можно было?", "а, так вот как это называется". Мне не удалось почитать учебники, походить на курсы и т.д., я просто писал код. И таких как я еще очень много, и я искренне надеюсь что когда я буду искать новую работу, мне попадутся люди, которые заглянут чуть глубже и не отправят меня в ж... потому что я не знаю какого-то названия. А может я совершенно не прав, и выбраны вырванные из контекста примеры, потому что то что вы показали вообще не должно существовать.
P.S. не пишу в резюме про синьоров и т.д. т.к. не понимаю смысла этих терминов, по-видимому вечный джун
Добрый день! Благодарю вас за комментарий и за то, что поделились своим опытом. Статья была написана на основе выборки из нескольких сотен собеседований и отражает обобщённые наблюдения, а не эмоции от конкретной ситуации.
Это вы на сотнях человек так самоутверждались? Типа, ах какие все кругом тупые?
Собственно, а вам шашечки или ехать? Что-то не похоже, что специалисты-то нужны
Цель собеседования - не самоутверждаться, а убедиться, что кандидат сможет эффективно решать задачи без "забивания гвоздей микроскопом". Бизнесу нужны люди, которые понимают базу и применяют инструменты по назначению. Это не про "тупых" или "умных", а про соответствие заявленным компетенциям и реальной работе.
На Хабре аудитория в принципе не глупая и не однобокая. И все как один говорят, что приведенные вами примеры - это не то, что должно быть в интервью. По крайней мере на общеиндустриальном уровне, может быть если Ваш продукт это линтер или другой анализатор кода - тогда ладно.
Поэтому может быть стоит проявить немного гибкости и прислушаться к обратной связи. Возможно, Вы фильтруете достойных мотивированных работать и учится кандидатов тем, что они сиюминутно не знают некой "базы", которую Вы определили для них как фильтр.
Я всегда видел, будет ли человек полезен в работе и может ли он вписаться в команду. В ходе интервью проверял гибкий ли у него ум, внимательность в моменте, умение вовремя попросить помощи или наоборот злоупотребить этим; или же вообще зарыться, но не сдаться пока не разберёшься и поймёшь сам. Или же человек дико креативный, но надо быть с ним не одной волне и это тоже может быть очень полезно, но потребует оверхеда на интеграцию его в команду. А на синьерских позициях важнее баланс ширины и глубины знаний, чтобы можно было эффективно делегировать задачи с высокой степенью неопределенности.
В общем я к чему это говорю - на моих собеседованиях я могу дать задачу написать функцию, которая отправляет http запрос. А потом понемногу по ходу диалога расспросить про асинхронность, многопоточность, попросить сделать этот код конфигурируемым (base_url / apiKey из конфига, переменных среды, секретов, паттерн стратегия или Dependency Injection), попросить сделать этот код тестируемым, написать тест, далее подняться на дизайн API, обсудить аутентификацию, авторизацию (OpenID, oAuth, apiKey, mTLS), идемпотентность, tracing, rate limiting, retry policy, обработку ошибок и тд и ТП. По факту от этой задачи можно плясать куда угодно и стимулировать кандидата объяснять почему он выбрал этот подход и какие были альтернативы. И даже если человек не работал и не знает, я могу попросить его порассуждать, а как бы он это реализовал, хотя бы наивным способом. Так можно узнать о кандидате очень много, при этом стимулируя его говорить и демонстрировать навыки, лишь подталкивая его вопросами в интересующую вас сторону.
А Ваш пример на мой взгляд проверяет только то, насколько такой код вгоняет кандидата в ступор и способен ли он достать правильные ответы из чертог своей памяти.
На собеседованиях проверяется не только компетентность, но и адекватность соискателя. И как было справедливо отмечено выше - тесты могут быть бредом, но адекватный соискатель так и должен сказать - «это бред, так писать не надо и это надо переписать». А не фантазировать бред в ответ.
Спасибо за развёрнутый комментарий и что поделились своим опытом! Ваш подход к интервью интересен и действительно даёт возможность глубже раскрыть кандидата.
При этом мне кажется, что вы немного переоцениваете "среднюю температуру по больнице" на Хабре. В комментариях под этой статьей уже были и оскорбления, и откровенно токсичные сообщения - и это тоже часть аудитории. Плюс в топе регулярно оказываются статьи, которые к IT имеют весьма косвенное отношение ("Как я продал помидоры на маркетплейсе на 100 млн рублей в год" и т.п.). Так что утверждать, что аудитория "все как один не глупая и не однобокая" я бы не стал.
А можно узнать, как выход в топ статьи "Как я продал помидоры на маркетплейсе на 100 млн рублей в год", особенно, если там интересные детали про автоматизацию выращивания, или отражение другого реального опыта, навело вас на мысль:
Так что утверждать, что аудитория "все как один не глупая и не однобокая" я бы не стал
Возможно у меня баннерная слепота и я просто уже физически не обращаю внимания на неадекватность)
убедиться, что кандидат сможет эффективно решать задачи без "забивания гвоздей микроскопом"
Больше половины ваших вопросов звучат в точности так: «я забил гвоздь в стену микроскопом, что разобьётся в процессе: объектив или окуляр?». А потом следуют аргументы о том, что человек, который знает БАЗУ, который знает устройство микроскопа, должен знать, что в нём разобьётся первым при забивании гвоздя в стену. Так вот нет, если человек всегда использовал микроскоп по назначению, то он может не знать, что разобьётся первым. Потому что из инструкции запомнил только, что после забивания гвоздя микроскопом микроскоп перестанет работать по основному назначению.
Можете ли вы, пожалуйста, рассказать, что вы делаете, если на подобный вопрос собеседуемый отвечает: «я говнокод не писал, писать не собираюсь, и вам не советую»?
А ответ про компанию, так и не услышали. Не буду набрасывать на вентилятор, уже много написали.
Подход идейно верный, но реализация на 2-
Вы дайте эти же вопросы внутри нормальных рабочих задач.
Но это попотеть, подумать надо и на собесе пояснений дать( но это же готовиться надо, собирать базу вопросов, не нагуглишь за 5 минут до собеса)
Таких казусов миллион можно найти, недавно собес вел и собеседуемый тоже ведёт собесы, в конце начали перебрасываться такими вопросами хорошо если 2 трети правильно оба ответили.
Это собес, тут и так нервы, начните с привычных задач , профилирование или отслеживание логов когда они есть и не пишутся или как архитектуру построим, ну и на затравку свои любимые.
Я бы ушел с таких вопросов через 10 минут, вне зависимости от результата.
Спасибо за комментарий!
Если перечитать статью внимательно, то как раз там и даны вполне обычные задачи: написать list comprehension, понять, как работают дефолтные аргументы функции, или как Python разрешает методы при наследовании. Это повседневные вещи, а не какие-то "олимпиадные каверзы"
Создается впечатление, что вы читали больше комментарии, чем саму статью :)
Хм, а давайте перечитаем статью, действительно.
Comprehension
Ещё одна максимально простая и будничная задача. Из тех, с чем любой, кто реально работает с Python, сталкивается чуть ли не каждый день.
print([x for x in range(3)])
print((x for x in range(3)))
print({x for x in range(3)})
Это так в вашем мире выглядит "написать list comprehension"?
Не ради высмеивания, но после той же Java или Go - питон выглядит как галюцинация какая то, максимально не очевидно и запутанно. Перед тем как писать бизнес логику - нужно заучить все эти «особенности» питона, потому что маразм by design
В целом справедливо и для js во всех вариациях от фронта до бека
Возможно просто кандидаты изначально выбрали не ту технологию, потому и валяться на собесах )
Добрый день! Как будто тут каждому свое, вкусовщина. С python начать проще, поэтому и выбирают
Не ради высмеивания, но после того же Python или Lua - Жава выглядит как галлюцинация какая то, максимально не очевидно и запутанно. Перед тем как писать бизнес-логику - нужно заучить все эти «особенности» жавы, потому что маразм by design
А можно пару примеров подобного из Java?
Такие примеры есть в любом языке программирования. Меня порадовало, что на Хабре всё ещё много жавистов, верующих в то, что они пишут сложную бизнес-логику и при этом не готовых принять дизайн других языков (Python в частности)
var list = new ArrayList<Integer>() {{ for (var i = 0_0;i < +0x1___ap1_5; this.add(++i));}}Ну собственно, живая иллюстрация к "их демонические практики - наши святые обряды".
Обе позиции, и ваша и "условных их" - как мне кажется, далеки от реальности, так как слишком упрощают, сводя всё к чёрному и белому. Ваша позиция легко проверяется вопросами - существуют ли намеренно сложные (см. Brainfuck) или намеренно простые языки (Basic и Pascal).
Мне больше верится в то, что языки отличаются по логичности и понятности. Какие-то языки сложнее в освоении, какие-то проще, даже если возможности у них равные. Это может быть банальным следствием того, что более логичные и простые языки создавались на ошибках своих предшественников, а у предшественников банально было не у кого поучиться.
нужно заучить все эти «особенности» питона
Вообще не нужно. Нужно не писать как макака лицом по клавиатуре. И помнить ,что отсутствие типизации это хорошо для программ до трёх страниц кода. После достижения трёх страниц, всё удаляем и переписываем заново, тщательно следя за типизацией.
В Java проверка на равенство строковой константе обычно выглядит как
"value".equals(variable)что тоже выглядит странно для разработчиков на других языках. Равно как тройное сравнение в JS со всем кроме null, и простыня из сравнений с err != nil в Go. Но те кто регулярно пишет на обсуждаемом языке привыкли к этому и им удобно.
Питон гораздо более лоялен к откровенно плохому, и зачастую нерабочему коду. Питон с радостью позволит запустить код в котором откровенная беда, и честно постарается ее выполнить, а при достаточно креативном игнорировании ошибок, программа на питоне будет выполняться даже при наличии невалидных и невыполнимых инструкций.
Но заучить все-таки надо не это, а правильные, вполне логичные, способы работы, а всю эту случайно работающую шизофрению обходить стороной
Ну да, в го ведь нет никаких особенностей?
type Person struct {
name string
ban bool
}
func main() {
persons := []Person{Person{name: "Alex", ban: false}}
for _, person := range persons {
person.ban = true
}
}
Изменится ли поле ban после выполнения цикла?
Нет, передача по значению
Это был вопрос для комментатора, который утверждает что в го всё очевидно и без особенностей.
И основной вопрос был не в том, что произойдет, он скорее риторический...
Одно дело когда мы передаём в функцию, другое дело итерация по массиву в том же скоупе...
Как по мне, это ничем не отличается от "особенности" питона с дефолтными значениями аргументов функции из поста.
Ну так это работа с указателями, которые везде используются, а не какая-то подкапотная хрень как у питона 🫢
Ну вот в плюсах я могу при помощи auto& пройтись по тем же объектам, в расте я могу при помощи &mut.
Ява/Свифт/Котлин/Шарпы/Скала/TS - можете сами загуглить как происходит итерация по массиву экземпляров классов. Но там тоже нет копирования/клонирования при обходе.
Почти все языки предоставляют возможность обойти массив объектов без их клонирования, но не го.
В гошке только как в девяностых при помощи индекса persons[i].
А если мы коснемся типизации гошки, то она настолько невыразительная, что под капотом у большинства коровских либ просто interface{}
Так что не нужно говорить о том, что один язык лучше другого. У всех есть свои "приколы".
Просто нетипизированные языки изобрели для того, чтобы на собесах магию приведения типов спрашивать 😁
Не, изначально то питон был больше для математических расчетов, а js был для браузера, но потом в чей то светлейший ум под действием запрещенных веществ пришла идея натянуть сову на глобус, т.е. из штуки заточенной под что то одно - сделать целую экосистему, дальше все это обросло костылями, и теперь имеем то что имеем ))
Нет, изначально Python был не для этого. Но учёные быстро заметили, что требуемые им скрипты на нём пишутся очень быстро и легко. И тогда для расчётов прикрутили быстрые NumPy, SciPy и так далее. На мой взгляд такого вот обычного пользователя питона, этот язык идеально подходит для тех, у кого собственно программирование не является профессиональной деятельностью.
Эх. У меня ситуация обратная, тоже фейспалм, но уже на собеседующих, бывают такие неадекваты, что ужас просто, приходиться доказывать элементарные вещи, которые гугляться за 30 сек, но нет, у них же методичка и там все верно априори
По ту стороны сидят такие же трудяги, которые также могут чего-то не знать. Ну или спрашивать чего сами не знают. Это страх большинства собеседующих, узнать, что кандидат умнее
Ну умнее кандидат вас и что? Что в этом плохого? Или это оверквалифаед для вас? Странная логика: тупой - плохо, умный - плохо, а что тогда хорошо? Чтобы была квалификаци веслами гребсти и лишних вопросов при этом не задавал?
Вы немного передергиваете. Я нигде не говорил, что "умный кандидат = плохо". Речь о том, что интервьюеры тоже люди, и бывают разные ситуации: кто-то спрашивает по методичке, кто-то, что знает сам. Если на собесе есть ошибка - это повод обсудить, а не уходить в крайности вроде "тупой/умный". Цель ведь одна - найти совпадение ожиданий и навыков, а не мериться, кто умнее
Какая статья, такие и комментарии. Из ваших слов я понял, что если я не знаю то, что знаете вы ( точнее то, что вы состряпали в качестве примеров, покуря линолеум и документацию), при этом подняв из пепла в прод несколько крупных коммерческих проектов и еще несколько написав с нуля, то я, оказывается, опыт себе просто накрутил и все, вот такие у меня выводы
Вижу, что тема действительно вызвала много эмоций. Цель статьи не в том, чтобы кого-то обесценить, а показать реальные кейсы с собеседований и напомнить про важные элементы языка, которые встречаются в работе.
Если кто-то поднимает крупные проекты - это отлично, но базовое понимание синтаксиса и особенностей языка всё равно важно, потому что это снижает риски ошибок.
важные элементы языка, которые встречаются в работе.
Все при указании на то, что код в статье это плохо, ссылаются в основном на коммерческий опыт разработки на питоне. А я вам вот что скажу — я такого даже в академических скриптах для расчётов не видел и сам не допускал. А они обычно пишутся один раз левой пяткой при ретроградном меркурии и лицом об клавиатуру. Про читаемость кода там даже не слышали (это не в упрёк, там не до этого), но я всё равно такого не встречал ни разу.
Я больше на плюсах пишу, нежели на питоне, и всё равно не делаю
int a = 55;
if(a) {}Не говоря уже о том, что у меня включены все проверки на неявное приведение типов.
Вас нельзя допускать до собеседований. Вы делаете отрицательную селекцию, с чем вас и поздравляю.
Не надо ничего обсуждать. Нет никаких гарантий, что ни одну сторону правильный ответ не заденет за живое и это не выльется в бессмысленный спор и трату времени. Интервьювер должен просто это себе отметить вопросиком и пойти дальше. После собеседования проверить.
Прикол в том, что для интервьюера это не должен быть красный флаг, так как интервьюируемый аргументированно доказывает факты, а по сути заполняет белые дыры в знаниях итервьера, то биш есть неплохой шанс того, что на работе (если возмут) он будет делать то же самое при виде дичи, а не закрывать глаза на нее. На деле, наоборот - как красная тряпка. Я понимаю если контора маленькая, типо конкуренция, все дела, все ясно, но в крупных корпорациях то почему так?...видимо привычка
у них же методичка и там все верно априори
Ооо, часто такое встречаю. Как-то интервьювер даже гуглить пошел и потом нехотя свою ошибку таки признал. Причем же ничего не мешает отметить себе, что момент спорный, проверить после собеседования (возможно, даже благодарность кандидату написать за новую информацию), но нет, надо спасать свое эго и начинать спор во время собеса, выставляя компанию не лучшим образом.
Самое-то забавное, что у многих опыт не накручен, пишут совершенно честно. Без знания базы вполне можно успешно работать годами. Не только Python касается. Плохо это или хорошо - вопрос открытый. На практике - когда как.
На самом деле тут очень просто все)
Сам ЯП это лишь инструмент, и в конечном итоге нужен для решения бизнесовых задач, и тут можно выделить 3 критерия:
- Делает ли алгоритм то что нужно бизнесу ?
- Насколько быстро и стабильно работает ?
- Насколько трудно масштабировать и расширять ?
- Можно было бы добавить еще цену, но цена штука такая, условно в крупной аутсорс компании фича может стоить 1 млн, а фрилансер Петя сделает за 10к, и по качеству будет одно и тоже
Это то что действительно важно, все остальное лишь вариации
- Можно сделать на if else, можно придумать 157 абстракций (как в Java)
- Можно монолит, можно на каждую функцию микросервис
- Можно написать на PHP, можно на ASM
- Можно на память знать обход дерева, можно не знать
- И еще 100500 вариантов
Но все это не важно от слова совсем, важно что в итоге получает бизнес)
Самое страшное, что вот именно такие собеседующие совершенно искренне считают, что они делают благо для компании, отсеивая людей с "накрученным", но на самом деле реальным опытом по своим оторванным от жизни критериям. А эти кандидаты могли бы принести на много больше пользы для компании, чем "олимпиадники". Одна из граней деградации современной айтишки.
Встречается, да, особенно если место тепленькое и пригретое. Можно так насидеть 10 лет и ничего не знать
Просто потом никому не хочется исправлять чужие ошибки и чужой код в реальной работе. А также тратить время на ревью и объяснять, почему писать так плохо:
if a == True:
...Почему так плохо? В дзене питона написано первой строкой: явное лучше неявного. Человек написал явное условие, он ожидает, что значение у переменной a будет True. То, что придумали сокращать до if a:.., это противоречит первому принципу дзена
А я вот побегал по граблям с Truthy и Falsy и мне теперь кажется, что именно так писать очень хорошо. Только лучше `is True`.
Читая ваши вопросы? вспомнился Пелевин. Крайне неточная цитата не помню из какой книги: "Человек часто забывает, что помимо ответов "Да" и "Нет", всегда можно ответить "Да пошли вы ...". И правильный ответ на все ваши вопросы, за исключением вопроса про comprehension: "За такой код надо бить по морде".
Сама проблематика, затронутая в статье имеет смысл быть. И чтобы отсеять людей, у которых все только в резюме, имеет смысл задавать вопросы без экзотики, без подвоха и без конструкций, которые надо избегать в реальноq жизни. Например, задачу про FizzBuzz. Одно время я просил написать код, который считает среднее арифметическое по массиву чисел. Некоторые числа равны 99, их из расчета среднего надо исключить. Сторонние библиотеки использовать нельзя. Удивительно, как много людей можно отсеять на этой как бы "задачке".
Только лучше
is True.
Это если aэто простой тип, а если кастомный который заимплементил свой __eq__() то is его проигнорирует, а это может быть не то чего вы ожидали при вызове.
Интересно, а есть какой-нибудь пример? У меня ожидания, что если `a` не True, то `a is True` всегда будет False. Разве не так?
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, и в реальности это зачастую имеет внутренний смысл.
Так я и пишу is True, чтобы у меня в условие было True только если переменная - синглетон True, а не какое-нибудь Truthy значение или выражение, которое выдаст True в результате каста типов.
В примере ниже от @krakotay : "А там a может быть и False, и True, и "Error with API" - в a может быть, допустим, 1 и в if a == True тоже выполнится не та ветка.
А там a может быть и False, и True, и "Error with API"
>>> a = "Error"
>>> if a:
... True
... else:
... False
...
True
>>> if a == True:
... True
... else:
... False
...
False
>>>
А ты приходишь и объясняешь, что == True надо убрать.
Вакуумный сферический конь, но это норм практика, если "a: bool". Лучше всё писать явно. Так же, как и "is None" и "is not None".
Ну я пишу лет 8 в том числе и на питоне, и сходу тем не менее затруднился с ответом на {("a", [1, 2]): "value"} и print((x for x in range(3))). А за 55 == True is True надо сразу бить по рукам на месте. Наверное, я не знаю базу? Или просто в нормальных условиях такую дичь на код ревью не пропускают, и вообще такое в голову не приходит? Питон, скажем так, довольно специфичный язык, а автор, видимо, нанимался загадывать ребусы и выводить на чисту воду этих наглых "накрутчиков". Я вот смотрю больше на способность кандидата мыслить, коммуницировать, рассуждать и предлагать варианты, что куда важнее, чем знание 100+ подводных камней питона. И в качестве теста на написание кода идут самые обычные кейсы.
Когда я искал свою первую работу, меня на собеседовании спрашивали, что выведет в PHP конструкция
echo print "";или как-то так. Прикол в том, что print всегда возвращает 1, и за годы работы это знание не пригодилось мне ни разу.
Не так давно я узнал правильный ответ на этот вопрос: «я не знаю, что выведет этот код, но знаю, что сделаю я: git blame»
Отвечаю на этот вопрос в комментариях уже не первый раз :) Ни у кого в последствии нет желания, интереса и времени, объяснять на ревью, как работает наследование в python и почему писать if a == True плохо. Собеседование не состоит только из таких задач, это лишь примеры, которые почему-то воспринимаются, как весь собес. Возможно мне нужно было это явно объяснить в статье, хотя мне казалось это очевидным
Парадоксально, но знание "базы" может свидетельствовать о том, что кандидат только недавно прошел какие-то курсы по питону и просто много ходит по собеседованиям. Если такой человек выступает в качестве интервьюера и спрашивает подобное - возможно, он в свою очередь тоже часто проводит собеседования, или занимается преподаванием языка. В ином случае не совсем понятно, для чего все эти сакральные знания держать в голове. И уж тем более на основе пары таких вопросов делать выводы о профпригодности. Может статься, что оба субъекта никогда в реальной жизни не применяли подобные знания и не применят, просто сошлись в игре под названием "собеседование", негласные правила которой как бы подразумевают, что надо знать "базу".
Знание "базы" само по себе не делает человека хорошим инженером, особенно если оно от "свежих курсов". Эти вопросы служат как быстрый фильтр на базовое понимание, чтобы отделить людей, которые действительно работают с языком, от тех, кто его видел только в теории. А полноценное собеседование, конечно, включает практические и прикладные задачи. В статье лишь выборка
Вот я на джуна пытаюсь. Правда до собесов не доходило пока но это ладно. Есть небольшой сайт на джанго, vue, который я развернул на амазон сервере. Делал в рамках обучения ну и сайт как резюме портфолио. Т.е. практический опыт написания работающего приложения есть. Но также я не писал на питоне почти пол года. Писал фронтенд на джаваскрипте, а теперь читаю другие вещи заделом на будущее, думаю попробовать нво фриланс податься и заполняю пробелы. И по вашему вместо этого я должен дрюкать шаблонные задачки на питоне чтобы не забыть то что я могу в доках почитать или у ИИ спросить? Серьёзно?
Одна из причин почему стоило крутить себе опыта хотя бы до мидла в том, что так выше шанс попасть на нормального собеседующего с адекватными вопросами, а не просто девочку рекрутера, которой распечатали список каверзных вопросов. Мои знакомые вкатуны, кто проходили этот путь честно, искали работу по пол года, а кто наврал с три короба, получал пачку офферов в первые две недели, так еще и с несравнимо выше ЗП. Можно было бы сказать, что таких врунов выкинут еще на испыталке, но ни один из них мало того, что не вылетел, так большинство еще раз сменили компанию в течение первого года по своей инициативе с повышением ЗП или уходом в крупняки.
Одна из причин почему люди крутят опыт-завышенные требования от работодателя. Половина вакансий на junior требует 1-3 года опыта и выкатывает в требования такой стек, что будущего джуна в пот бросает. А ларчик просто открывается: мы хотим middle на зарплату junior. Сейчас сам пытаюсь с инженера в нефтегазе перейти в data engineering, пока опыт себе не крутил, но прихожу к мысли что рано или поздно придется ступить на эту кривую дорожку, т.к. даже на собесы не зовут- сразу в корзину резюме отправляют.
Да, в том числе. Я все вспоминаю как искали людей ко мне в отдел, рекрутинг отдали внешней компании. В итоге они полностью забили на то, что мы для них составили, напихали в вакансию технологий, которые мы не используем, в итоге я на вакансию себе же в подчинение проходил дай бог процентов на 30-40%, хотя у меня вроде был приличный опыт работы, весь из которого приходился именно на эту компанию. Так особо одаренный рекрутер умудрился мне ещё и в ЛС на хабре написать с вакансией, хотя у меня указана компания в профиле. Казалось бы, сильнее облажаться уже нельзя, но там в тексте ещё и версия фреймворка не та была.
В общем, прекрасный опыт. С ужасом представляю когда мне придется быть по другую сторону и самому проходить собесы, а потом выслушивать в причинах отказа чепуху в духе того, что я недостаточно использую AI в своей работе.
Я врать не сумею если захочу даже. Это же тоже навык который требуют "прокачки". А я всегда пытался найти плюс в том что бы быть честным, и как правило это работает - убеждаешь себя что в долгосрочной перспективе сказать правду будет лучше. Но даже я вижу что это не тот случай. Но врать вообще не умею, вот реально не помню сколько лет нарочно не врал. Как будто вечность.
"список вопросов" сейчас, похоже стал массовым явлением не зависящим от позиции, причем в такие списки попадают вопросы на которые отвечать надо не одним предложением (например, про права на файлы в линуксе) или вопросы с фиксированными вариантами ответов без правильного. И спрашивает хр, то есть на "у вас там правильного варианта в списке нет" просто запишет "отвечать отказался".
P.S. Иногда после вопроса "а часто ли у вас такая дичь в проектах встречается, что приходится на собеседованиях спрашивать" собеседующий отвечает что это у них обычная практика, например, иметь кучу методов ProcessSession в иерархии плюсовых классов, которые принимают множество типов сессий и я зря придираюсь.
И так везде. А потом винлаб аэрофлот и аптека взломаны, несмотря на бюджеты. Кто то где то не знал основ, а хакер знал.
А это классика собеседований в айти сейчас. Может, ты и крутой спец с большим опытом, но без зазубривания всех таких неочевидностей рискуешь даже скрининг у HR не пройти.
А главное, если бы его взяли - работал бы не хуже всех прочих.
И если вы честно пашете, растёте и отвечаете за базу — вы уже не в большинстве. Вы — в меньшинстве.
А зарплата при этом как у большинства. Откуда и...
Так и не понял из статьи эти ваши питоны - это база или не база?
У вас там в первом же пояснении ошибка:
Python интерпретирует выражение как:
(55 == True) and (True is True)
Должно быть:
Python интерпретирует выражение как:
((55 == True) is True)
Дальше вы поясняете этот пример корректно. Но после этого примера читать статью уже не стал.
В python как раз пример автора корректен. Не пишу много на python и специально посмотрел документацию
https://docs-python.ru/tutorial/operatsii-sravnenija-python/
В своём случае стараюсь не использовать малораспространённые и значительно отличающиеся от других языков конструкции. Обычно даже в одном проекте пишешь/проверяешь не на одном языке и запутаться достаточно просто.
Ваша ссылка не ведет на документацию. Это какой-то сайт от третьей стороны с уроками. Насколько эти уроки корректны, я даже не берусь судить, и тем более, не буду тратить свое время на его чтение.
Можно потратить время и проверить на практике просто чуть-чуть изменив пример.
0 < 42 is True
Если оно вычисляется как (0 < 42) is True, будет True.
Если оно вычисляется как (0 < 42) and (42 is True), будет False.
Судя по всему, оно действительно выполняется как (0 < 42) and (42 is True) , поскольку интерпретатор выдал ворнинг (SyntaxWarning: "is" with 'int' literal.) и результат False. Так что кажется автор все-таки прав, а @Ilirium ошибается.
Может, вы в таком случае приведете ссылку на документацию? Потому что ниже в этой ветке уже привели такие примеры, что ваш вариант (оба ваших варианта) интерпретации выражения из статьи не проходит.
Там ниже wl2776 привел ссылку на официальную документацию. Я же честно признаюсь, утратил интерес к дискуссии, мне такие мелкие нюансы не очень интересны. В реальном коде, если будет нечто подобное я просто расставлю скобки, чтобы код легче читался. А так на питоне я профессионально программирую больше 7 лет, сейчас как Computer Vision Engineer.
В данном случае приоритет операторов другой: == выше, чем and, а is и and разделены. Python интерпретирует это как (55 == True) and (True is True). Можете проверить в REPL - результат будет False.
Но после этого примера читать статью уже не стал.
Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
В общем случае, если REPL выдает тот же самый результат, вовсе не означает, что интерпретация выражения работает так, как вы описали. Согласны ли вы с этим утверждением? Входит ли оно в базу?
Дальше, разберем по порядку, как работает исходное выражение: 55 == True is True. Такое выражение можно переписать с использованием скобок: ((55 == True) is True). Ну и вообще подобные выражения для лучшего понимания вначале следует записать со скобками. Итак, сначала вычисляется (55 == True). Его результат будет False. Затем этот результат подставится дальше: False is True. Его результат будет False.
Ваше выражение (55 == True) and (True is True) дает такой же результат, но оно не является результатом интерпретации Python исходного выражения.
Что касается:
Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
Вы знаете, информации очень и очень много. Можно считать, что бесконечное количество. Мое же время дифицитно и ограничено. Зачем мне искать в вашей статье что-то полезное (и проверять на ошибки), если я уже вижу, что вы ошибаетесь в первом же примере?
Кроме того, сам посыл статьи "кандидат сбежал в слезах" у меня не добавляет желания смотреть статью дальше.
спасибо за разъяснения. Я не спец в Python, но так и не понял, откуда в статье взялось "and (True is True)"
"55 == True is True" эквивалент "((55 == True) is True)" это неправильно. Откуда столько плюсов. Похоже автор статьи вскрыл реальный нарыв.
Единственный правильный способ узнать как 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
Вы же предлагаете на экзамене, угадав правильный ответ с первого раза, на вопрос экзаменатора "покажите решение" ответить "а вы проверьте, ответ подходит"
Выкроив время, написал небольшой вывод чему же в таком случае равно исходное выражение – (55 == True) and (True is True) или же (55 == True) is True (или ещё чему-то – увидим далее)
Под chain comparison будем понимать выражение вида a OP1 b OP2 c (OP1 / OP2 - доступные в Python операторы сравнения <, <=, >, >=, ==, is)
>>> 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
На этом можно было бы и закончить, т.к. ответ на вопрос "а как Python считает это выражение", уже дан, но рассмотрим байт-код подробнее
Поставляя разные значения вместе a, b и с в выражении a OP1 b OP2 c, а также OP1 и OP2, заметим что меняются только сами значения, которые грузятся на верхушку стека (LOAD_CONST), и опкоды операторов с их аргументами (IS_OP, COMPARE_OP и т.д.)
Просимулируем работы вышеприведённого байт-кода Python на самом же Python:
def vm_simulate() -> bool:
stack = []
stack.append(55) # LOAD_CONST 0 (55)
stack.append(True) # LOAD_CONST 1 (True)
stack[-2], stack[-1] = stack[-1], stack[-2] # SWAP 2
stack.append(stack[-2]) # COPY 2
op_right = stack.pop()
op_left = stack.pop()
stack.append(op_left == op_right) # COMPARE_OP 72 (==)
stack.append(stack[-1]) # COPY
stack[-1] = bool(stack[-1]) # TO_BOOL
if not (stack.pop()): # POP_JUMP_IF_FALSE 4 (to L1)
stack[-2], stack[-1] = stack[-1], stack[-2] # SWAP 2
stack.pop() # POP_TOP
return stack[-1] # RETURN_VALUE
stack.pop() # POP_TOP
stack.append(True) # LOAD_CONST 1 (True)
op_right = stack.pop()
op_left = stack.pop()
stack.append(op_left is op_right) # IS_OP 0
return stack[-1] # RETURN_VALUE
Небольшая ремарка про
op_right = stack.pop()
op_left = stack.pop()
аргументы на стеке идут в том же порядке, в котором они передаются в вызываемую функцию, поэтому достанем их заранее
Заметим что у нас есть ранний выход в случае когда часть выражения a OP1 b равна False
Затем отметим что путём SWAP и COPY у нас с самого начала на дне стека оказывается значение переменной "посередине" этого самого chain comparison – т.е. значение b
Теперь у нас на верхушку стека складывается значение c, причём перед этим в стеке остаётся лишь одно значение - b, поэтому вызывается OP2 между b и c
И таким образом, зная что в Python вычисление булевых выражений происходит лениво, то однозначным аналогом выражения a OP1 b OP2 c будет (a OP1 b) and (b OP2 c)
P.S. Для проверки использовался Python 3.13.5 (main, Jun 23 2025, 16:56:36) [Clang 16.0.0 (clang-1600.0.26.4)] on darwin
Попробуйте угадать, что выведет 55 == True is False
Да, не угадал, спасибо за пример. Я как-то не задумывался, что у is выше приоритет, чем у ==. Со скобками у нас будет следующее выражение: 55 == (True is False).
Исходное сообщение из поста тогда корректно записать так: 55 == (True is True). И эта запись в любом случае не соответствует записи автора: (55 == True) and (True is True).
А на самом деле так как Автор описал.
Цепочечное сравнение оказалось интересным и богатым на информацию - любители numpy спят и видят чтообы оно заработало для массивов: PEP 535 – Rich comparison chaining - а им объясняют почему пока это не работает, и объяснение вполне интересное.
Ха, да, про Numpy я не подумал, хотя его и OpenCV использую много. Надо будет потом PEP прочитать.
The NumPy folks brought up a somewhat separate issue: for them, the most common use case is chained comparisons (e.g. A < B < C).
Думаю для такой операции, если она часто встречается в коде, можно сделать отдельную функцию. Мне в одном проекте нужно было из многомерного массива выбрать по определенным критериям значения (if-else и разные сравнения), я сделал это через несколько бинарных масок, которые потом использовались при вычислении.
Спасибо за статью. Понимаю, что иногда душа болит за то, что нахватавшиеся по верхам и не знающие корневых принципов работы ЯП хотят многаденяк. Кажется, что без знания некоторых вещей из показанных примеров все-таки можно писать годный код, но я не программист, хоть и приходится писать код на Python иногда.
Однако вот пример с def append_to_list(item, my_list=[]) меня, честно говоря, расстроил. Для меня не интуитивно, что при вызове функции без указания аргумента my_list не происходит создания нового списка и такое поведение интерпретатора мне кажется неправильным. То есть если в каких-то примерах действительно можно поразмыслить и понять, что {x for x in range(3)} -- это не словарь, т.к. тут нет пар key-value, но в примере с append нужно именно знать, что питон -- ленивая задница.
Добрый день! Благодарю за ваш комментарий!
Понимаю, что иногда душа болит за то, что нахватавшиеся по верхам и не знающие корневых принципов работы ЯП хотят многаденяк. Кажется, что без знания некоторых вещей из показанных примеров все-таки можно писать годный код, но я не программист, хоть и приходится писать код на Python иногда.
У каждого свои приоритеты, кому-то просто не хочется потом тратить часы и объяснять на ревью, почему писать if a == True плохо и как работает наследование в python
Однако вот пример с
def append_to_list(item, my_list=[])меня, честно говоря, расстроил. Для меня не интуитивно, что при вызове функции без указания аргументаmy_listне происходит создания нового списка и такое поведение интерпретатора мне кажется неправильным. То есть если в каких-то примерах действительно можно поразмыслить и понять, что{x for x in range(3)}-- это не словарь, т.к. тут нет пар key-value, но в примере сappendнужно именно знать, что питон -- ленивая задница.
Да, кажется чем-то не очевидным. Но после пары раз, когда эта "ленивая задница" развалит нам весь прод, уже на такие вещи начинаешь смотреть внимательнее
Статья имеет потенциал набрать комментарии, так что рискну ворваться с оффтопом.
А зачем вообще сделали так что def append_to_list(item, my_list=[]):
создает my_list только один раз? Выглядит как странное поведение и очевидный источник ошибок. "Потому что это изменяемый тип" вообще не аргумент, это типа "Если вы набираете на нашей клавиатуре букву А, то она ломается, потому что А - это гласная".
Кажется что даже запрет передавать передавать изменяемые типы как аргументы по умолчанию был бы лучше.
Я помучал поисковики/чатботов на этот счет выдают аргументы типа
- Нуууу, производительность
- Нуууу, можно сделать на этом мемоизацию и еще специфический синглтон
Выглядит сомнительно если честно. Может это какое-то тайное питонисткое знание, которое знают только люди и кто-то может его поведать? Может есть какое-то Rationale стандарта или хотя бы мемуары разработчиков в которых рассказано почему так сделано и почему это не исправили когда был несовместимый релиз.
( я если что не питонист, но честно хочу разобраться без набросов и претензий )
Добрый день! Благодарю за комментарий!
- Нуууу, производительность
- Нуууу, можно сделать на этом мемоизацию и еще специфический синглтон
На самом деле это и есть основные принципы зачем так сделано. А почему не сделать по другому - думаю нужно спросить у core девелоперов python. Или эксперты в комментариях подскажут :)
"Тайное питонистское знание" в том, что не делайте так - значениями по-умолчанию ставьте только неизменяемые объекты. Как None, например. А мутируемые делай в каких-то ну очень специфических ситуациях если хз ну прям очень надо.
Неизменяемость объектов тут достаточно ортогональна, можно написать
def f(today=datetime.now()):
и дата там так же вычислится один раз и это та же самая проблема.
Хороший пример! Пример, наглядней(чем пример со списком)объясняющий именно "базу" - когда вычисляются дефолты. И это, вобщем-то, не "проблема" питона, а то, как он устроен - место объявления сущности(класса, функции и их дефолтных параметров, даже модуля) это по-сути место выполнения кода создающего их значение(обънкт) в рантайме. Питон - такой, и это стоит понимать.
Да, сделали для скорости, что умолчательные аргументы вычисляются один раз.
А так то по смыслу модифицировать пусть и изменяемые объекты в функции это лучше осторожно. В функциональном программировании так нужно возвращать изменённый объект, но не менять входящий.
Мое непитоническое мнение (не факт, что верное) таково - дело в передаче по ссылке. Лист положили в heap, ссылку в стек и дальше оперируем этой ссылкой. В сущности, я думаю, что это не фича, а исторический баг, которых в питоне кроме этого еще вагон и маленькая тележка.
Проблема в С под капотом. Все параметры по умолчанию вычисляются на этапе создания функции (не забываем что в питоне функции это тоже объекты), после чего создаётся ссылка на объект my_list, который размещается в атрибуте __defaults__. Если мы вызываем функцию без указания объекта my_list, будет использован объект, созданный по умолчанию из атрибута __defaults__. И мы по сути модифицируем объект, переданный нам по ссылке.
Я думаю логика такая — достаточно один раз вычислить значения по умолчанию и переиспользовать их, потому что они всё равно не будут меняться. Но проблема в том, что в питоне все взаимодействия с объектами идут через ссылки, что и приводит к такому поведению, если мы сразу создали пустой список, а не инициализировали его None.
Помню это только потому, что это повергло меня в состояние крайнего ах*я в своё время. Ну и до боли знакомая ситуация в С/C++ когда открываешь чей-то код.
Кстати, вы можете работать с объектами, которые хранятся в __defaults__ напрямую, потому что это по сути кортеж со ссылками. Поэтому на каждый вызов просто создаём новый список если переданный объект None, и значение по умолчанию тоже только None. Да, я люблю копаться в сомнительных вещах, почему это спрашивают на собеседовании — хз.
Вы уверены, что в первом примере chained comparison?
В https://peps.python.org/pep-0535/ говорится только про операторы < ,> ,<= и >=
Про == и `is` не нашёл.
Да, вы правы, классическое chained comparison по стандарту описывает <, >, <=, >=.
В примере в статье это не "классическая цепочка сравнений", а обычная комбинация операторов, где == вычисляется первым, а затем результат участвует в сравнении с is. Поэтому Python и интерпретирует выражение как (55 == True) and (True is True)
Поэтому Python и интерпретирует выражение как
(55 == True) and (True is True)
Не согласен.
У == и is одинаковый приоритет, скобок нет, поэтому выражение вычисляется слева направо: `(55 == True) is True` -> `False is True` -> `False`. Никакого `and` тут нет.
А если так написать то сразу понятно что ваше предположение не верно
>>> 1==1 is True
False
>>> (1==1) is True
True
>>> (1==1) and (1 is True)
FalseДа, я тоже заметил.
>>> 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"
А, вот в чем дело. Раздел 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 zis equivalent toa op1 b and b op2 c and ... y opN z, except that each expression is evaluated at most once.
Т.е. про скрытый `and` автор прав.
Я ответил на все вопросы из статьи правильно с первого раза! Я python-сеньёр? (Ни одного дня в коммерческой разработке на питоне, для себя писал всякие апи, парсеры и телеграм-боты)
Скорее всего вы воспринимаете статью слишком буквально :)
Это всего лишь выборка типовых вопросов, которые встречались на собеседованиях. На реальных интервью обычно проверяют гораздо больше аспектов: архитектуру, опыт работы с проектами, умение решать нетривиальные задачи вживую. Так что правильные ответы на все вопросы статьи это круто, но это не означает автоматического статуса "сеньора помидора"
55 == True is TrueЧто вернёт выражение? Правильный ответ: False. Почему? Потому что это цепное сравнение (chain comparison)
Этот вопрос не на понимание, а просто на детальное знание особенностей конкретного языка (Python).
На понимание (на уровне ЕГЭ хотя бы) можно было бы задать такой вопрос:
Как в питоне из 5 вычесть 3, не используя знак минус?
Честно, я немного удивлен тому, что в статье есть и другие примеры, но в комментариях все свелось к обсуждению задачи с операторами :)
Другие примеры тоже касаются не понимания, а знания/незнания деталей питона.
Человеку, действительно разбирающемуся в программировании, имеющему опыт в языках более низкого уровня (например С/С++), для глубокого понимания всех этих вопросов понадобится несколько минут времени. Например, он с ходу поймет, что в питоне в переменных хранятся не значения, а ссылки на области памяти (он сразу увидит аналогию с указателями в С) и т.д. Большинство вопросов завязаны на знание синтаксического сахара питона. Опытный в программировании человек разберется с этим за минуты. С другой стороны, человек, вызубривший эти нюансы, может не разбираться глубоко в этих темах.
Общий тон статьи можно охарактеризовать как "Смотрите, как я разделываюсь с самозванцами, как я лихо вывожу обманщиков на чистую воду на незнании базы."
При этом, Вы первых же строках показали незнание этой самой базы, притянув в обычное вычисление выражения chained comparison, который и рядом не валялся.
В примере речь шла не про демонстрацию "уникального синтаксиса", а про то, как Python обрабатывает выражения с разным приоритетом операторов. То, что кандидаты на этом сыпались, и было показательно
Если ваше внимание зацепилось именно за термин, это хороший знак - значит, базу вы знаете, и обсуждение статьи для вас не про содержание, а про формулировку. Это нормально: у каждого свой профессиональный триггер
Потому что она первая, и в первом же примере Вы допустили косяк
Имеется ввиду, клавиатурный минус? т.е. решения в духе 5 + (-1 * 3) не подойдут?
С Python незнаком, но всё равно интересно: как тогда сделать? Какой-нибудь "Math.sub(int, int): int"? Или элементарная замена символа на ключевое слово "a = b sub c"?
Имеется ввиду, клавиатурный минус? т.е. решения в духе 5 + (-1 * 3) не подойдут?
Да, клавиатурный минус нельзя использовать, да и вообще любой минус (как бы он ни был закодирован).
>>> import math
>>> 5 + 3 * math.cos(math.pi)
2.0
>>> 5 + 3 * (complex(0, 1)**2).real #Если вдруг импортить нельзя
2.0...и еще 1000 и 1 способ "из ЕГЭ" получить -1
После чего встать и уйти. Работать в зоопарке где задают такие вопросы большого смысла нет.
Предполагаю что ожидался ответ
>>> import operator
>>> operator.sub(5, 3)
2Он хотя бы про python, но при чем тут ЕГЭ?
Еще можно через битовую арифметику. Известная баянистая задача сделать сумму без использования оператора + (рекурсивный вызов sum((x&y) << 1,x^y)). Для вычитания можно сложить с дополнительным кодом. Правда, не факт что эти трюки сработают в таком далеком от железа языке, как питон.
Можно еще:
a = 5
a.__sub__(3)
5 + ~3 + 1
А ЕГЭ при том, что хранение чисел в дополнительном коде проходят в школе.
Всё просто. Надо вспомнить настоящую базу, которую дают еще в школе на уроках информатики: отрицательные числа хранятся в дополнительном коде (побитовая инверсия + 1) и на аппаратном уровне вычитания нет, есть только сложение.
Поэтому я бы предложил такой ответ: 5 + ~3 + 1
А переполнение использовать можно? (Я не питонист)
Т.е. отключаем защиту от переполнения, переполняем до -3 и складываем
А переполнение использовать можно? (Я не питонист)
Т.е. отключаем защиту от переполнения, переполняем до -3 и складываем
Близко :). Но только для "переполнения" достаточно вспомнить, как хранятся отрицательные числа в вычислительных системах и о том, что на аппаратном уровне вычитание происходит через сложение.
Поэтому: 5 + ~3 + 1
У вас как будто чутка смешаны понятия знания и понимания. Мне кажется, что знания - это константа, вроде значения числа Пи или заряда электрона. А понимание - это функция расчета Пи и заряда электрона. Т.е. знание отвечает на вопрос "что?", а понимание "почему?". Поэтому понимание ценится больше, потому что из одной формулы можно сделать 10-ки комбинацией получая разнообразные "что?", а вот из "что?" другие "что?" получить невозможно.
Поэтому правильнее было бы сказать "не вспомнил, как хранятся числа, потому что знал", а "подумал, как могут храниться числа и сам понял, как они хранятся (вычислил "что")", и вот тогда ответил. Иначе получается не очень валидный пример.
Ну это так, демагогия.
Первое, что приходит в голову 5 >> 1. Но этот вопрос ближе к C разработчику под МК, чем python. Я бы задавал вопросы по проекту на который ищу сотрудника и его понимание в целом.
Я рассуждал исключительно в рамках сабжевой темы. Если автор решил задавать вопросы "на понимание", то и вопросы должны быть соответствующие - на понимание.
Первое, что приходит в голову 5 >> 1.
Если человеку подобное сразу приходит в голову, то, согласитесь, это с ходу многое говорит об уровне его образования, да и опыта тоже. Сейчас сын готовится к ЕГЭ и я с некоторым удивлением обнаружил, что эти темы сейчас уже в школе проходят на уроках информатики, и вроде как на экзамене может попасться вопрос о формате хранения чисел с плавающей запятой, отрицательных чисел в дополнительном коде и пр.
Если человеку подобное сразу приходит в голову, то, согласитесь, это с ходу многое говорит об уровне его образования, да и опыта тоже.
Соглашусь, что у вас некорректная корреляция ответов и уровня образования/опыта. Если задаете вопрос с подколом, а это странный вопрос на данном собеседовании, то получайте аналогичный ответ. Результат полностью совпал с ожидаемым? Вы еще заставьте питониста составлять таблицы истинности для тестирования микросхем.
Сейчас сын готовится к ЕГЭ и я с некоторым удивлением обнаружил, что эти темы сейчас уже в школе проходят на уроках информатики
Значит школьная программа изменилась. У меня это было более 20 лет назад на первом курсе. Либо специфика школы. У нас были школы в, которых проходили матричные вычисления, а в моей нет.
Если задаете вопрос с подколом, а это странный вопрос на данном собеседовании, то получайте аналогичный ответ. Результат полностью совпал с ожидаемым? Вы еще заставьте питониста составлять таблицы истинности для тестирования микросхем.
Если речь вести о настоящем понимании, то только подобные вопросы и позволяют это выявить. Я наверно старомоден, но продолжаю считать, что программист должен знать базу: и математику, и электронику (отчасти), схемотехнику, архитектуры вычислительных систем и пр. И повторюсь, форматы хранения чисел (отрицательных, с плавающей точкой) сейчас проходят уже в школе. Не знать программисту, как числа в памяти компьютера хранятся? Ну, такое себе...
Но спорить не буду, есть противоположные мнения, что сейчас никакой подобной базы программистам не нужно знать. Мне в прошлых темах здесь уже доказали, что и врачу не нужны знания химии и анатомии. Спорить не хочу, некоторая логика в этом есть, просто мне это не по душе.
Люто плюсую.
Кандидат, возможно, запускал не один коммерчески успешный проект. Не в одно лицо, естественно, но проходил этот путь. Осваивал на каждом проекте новый стек. И писал код без вот этих вот тру из тру, а нормальный такой kiss, и ему благодарна бывшая команда.
Утверждать, что он не знает базовую базу из-за вот этого вот?
Удачи автору на собесах. Почему-то вижу, что он даже hr не пройдет
Я понимаю вашу точку зрения, но в статье речь не про людей, которые запускали успешные проекты и работали с разными стеками, а про тех, кто приукрашает опыт и не может объяснить даже основы языка, на котором якобы писал код.
Нормальный KISS-код и успешные проекты - это здорово, и такие кандидаты как раз проходят собеседования легко, потому что быстро ориентируются и могут восстановить забытое. А вот когда в резюме написано "5 лет Python", а на практике человек путает tuple и dict - это уже не про забытое, это про отсутствие опыта совсем
Есть ли вероятность, что кандидат, придя к Вам на собеседование, не увидит этих вопросов?
Знание ответов на эти вопросы это Ваш единственный критерий для определения того, что опыт не накручен?
Для отсеве накручивающих "опыт" нужно спрашивать про задачи встречающиеся в этом самом "опыте". У вас задачи на задрачивания конкретных деталей языка которые в нормальных проектах не используются никогда от слова совсем.
На самом деле в статье вопросы выбраны не как "ловушки", а как проверка базового владения Python. Это не засыпка, а фундамент, тот минимум, который нужен, чтобы не тратить часы на ревью кода с банальными ошибками
Ложь - 90% это именно вопросы ловушки, про то, что в живом и минимально адекватном коде не встречается. Соответственно если кандидат не зубрила и не говнокодер, для которого увидеть/написать аналог примера с наследованием ежедневная рутина - он ваше собеседование не пройдет - потому-что "накрутил" опыт.
Если интервьюер для проверки базового понимания языка использует не рабочую кодовую базу или, на худой конец, OpenSource репу какой-нибудь тулзы - он априори, чудак на букву м.
И единственный валидный совет - держаться от компании и такого интервьюера желательно подальше.
Получается, что у вас в кодовой базе не встречается наследование, comprehension или аргументы по умолчанию? :)
Вопросы из статьи - это не "ловушки", а примеры базового синтаксиса Python, который ежедневно встречается в любом живом проекте. Они не про "зубрёжку" и не про говнокод, а про понимание языка, на котором вы заявляете, что работаете.
Да нет тут понимания языка. Ну вот вобще нет.
Можно залезть в спеки питона и натаскать еще десяток уникальных примеров кода, объявить их базовой базой - а вот потому что я так решил - знаешь эти случаи - знаешь базу, а нет ну и катись колбаской.
Так знания не проверяют - так почесывают ЧСВ, за счет отсеивания тех кому не повезло (ну или повезло, тут как посмотреть)
В любом ВАШЕМ живом проекте. К счастью, в нормальных проектах такую дичь не пишут, а если кто попытается написать — больно надают по рукам на код-ревью)
Если в ваших проектах такое ежедневно встречается, добавьте в статью название компании, чтобы люди знали куда не идти
Вы тут всюду пишете про какую-то абстрактную базу. А у нее есть конкретика? Что это такое? Где с ней ознакомиться? Через что провалидировать ваше утверждение про "базовость"?
База - это фундаментальные вещи языка: работа операторов (is, ==), изменяемые аргументы по умолчанию, MRO при наследовании, comprehension. Все это описано в официальной документации Python (docs.python.org) и десятках учебников.
Если вы нашли время оставить комментарий - заглянуть в документацию точно не составит труда.
Странно, что нет вопроса про знаки подчеркивания в численных литералах. Ну, раз уж на то пошло, и мы выясняем, насколько глубоко кандидат знает тонкости языка.
Какой будет результат у
int("198_1")?
Скрытый текст
Я вот на джуна хочу устроиться но ответов на заявки нет пока. Наверное потому что про опыт не врал. Тем не менее есть проект - сайт на vue django rest framework. Но я на вопросы все эти тупые не отвечу потому что я знаю что я просто буду использовать безопасные конструкции в коде а если будут вопросы - спрошу тот же чат гпт. Зачем мне голову забивать? Чтобы немного быстрее работать? Мне кажется что это чушь и такие собесы не актуальны. Разве не более важно что человек говорит и насколько он понимает основные концепции?
Проблема не в том, чтобы "забивать свою голову" редкими приёмами, а в том, что базовые конструкции и особенности языка - это как грамматика в разговоре.
Использовать "только безопасные конструкции" - хорошо, но в реальной работе постоянно встречаются чужие решения, легаси-код и нестандартные ситуации. И если при этом человек не понимает базового поведения языка, он может тратить в разы больше времени на отладку и исправление багов. Поэтому такие вопросы - это не "чушь", а минимальная проверка: сможете ли вы разобраться, если что-то пойдёт не по шаблону
У вас в этом комментарии две пунктуационные ошибки. Тире перед "это" не ставится. И точки в конце нет.
Тире перед "это" ставится. https://gramota.ru/biblioteka/spravochniki/pravila-russkoj-orfografii-i-punktuacii/tire
В разы больше времени, да, это очевидно. Но о какой разнице речь? Мне сложно оценить, но кажется что на практике она не должна быть значимой даже если это 10 минут против ну пусть даже 300. Но ведь не должно же такое часто встречаться. Что это за легаси код такой?) Я просто немного не понял статью. Ну и опыта у меня нет. Но блин, 55 == true is true... Если это намёк на кодовую базу которая ожидает кандидата, то вы должны предупреждать и извиняться заранее.
Он не "убежал в слезах" а пошёл в руководители и вы ещё с ним встретитесь, ни один раз, но смеяться уже будет он, а не вы.
панамка с шашечками детектед
Трюкачество - это антипаттерн, а не "фундамент". Такой переусложненный программный код писать не нужно, а узнать, что он выдает, можно простым тестом
Когда читаю подобные статьи, прихожу к выводу: в подобных компаниях выработаны стандарты для определения годности кандидата, но эти методы не могут точно отобразить качество кандидата. Если это выжимка из пула всех вопросов, то конкретные вопросы не могут точно сказать профи перед нами или дилетант. Поработав на разных проектах и с разным стеком, я понимаю, что все запомнить не возможно, а если код изначально не нагляден, то его не используют. Соглашусь, что базу знать нужно. Но что считать базой зависит от конкретного проекта, где-то важно понимание как это работает "под капотом", где-то важно какой фреймворк для этого подходит.
Лет 10 назад поставил бы минус, потому что был примерно таким кандидатом "ну я же пушил в прод, там все работало, сотни тысяч клиентов пользуются".
Сейчас руководитель и подписываюсь под каждым словом. Кандидатов нужно проверять в хвост и в гриву.
Раздолбы минусуют и их можно понять.
А никто и не говорит, что собесить не надо.
Негодование, что автор придумал очень специфические проверки и смешивает с хм.. грязью тех, кто этого не знает. Да еще и называет врунами, мол опыт прикрутили. Без пруфов. Клевета?
В статье не было цели "облить грязью" людей ради самого процесса. Я сознательно привёл базовые вопросы, с которыми сталкивается любой, кто реально пишет код на Python больше пары месяцев.
Если человек называет себя Senior QA Automation Engineer и при этом не знает, что изменяемые аргументы по умолчанию работают как одна и та же ссылка или что comprehension в скобках даёт генератор, - это не "специфическая проверка". Это проверка минимального практического опыта.
Поэтому вывод "накрутил опыт" не про каждого ошибшегося, а про тех, кто системно не знает основы, но позиционирует себя экспертом
Благодарю за комментарий! Полностью с вами согласен!
У меня та же эволюция восприятия: когда только начинаешь карьеру - кажется, что главное "пушить в прод", а потом всё равно как-то работает. Но со временем, когда отвечаешь за продукт и команду, понимаешь: бездарь в штате - это риск, и дорогой.
И да, минусуют чаще всего как раз те, кто "вроде все делал, но глубины нет". Я провел уже десятки собеседований и вижу: стоит только немного копнуть, и резюме рассыпается. Поэтому проверять кандидатов "в хвост и гриву" - это не вредность, а нормальный подход.
Мой непрошеный совет автору - выйти на рынок и походить по собеседованиям. Корона с головы быстро упадет. Упоротые интервьюеры-гейткиперы сделают свое дело!
Цель статьи - не "гейткипинг ради гейткипинга", а показать, что базовые вещи действительно важны.
Никто не отказывает кандидату за незнание редких алгоритмов или "олимпиадного трюкачества»" - речь идёт про фундамент языка, который заявлен в резюме.
Ну так придете, например, ко мне, а я с порога попрошу рассказать флоу Cython под условным numpy, и что-то я очень сомневаюсь, что получу нужный мне ответ. А ведь это такой же фундамент, настолько же важный, насколько и ненужный.
Вы сильно гиперболизируете :)
Сравнение с флоу Cython под numpy не очень удачное - это узкоспециализированная область, которая нужна далеко не всем, кто пишет на Python.
В статье же приведены вещи уровня "как работает множественное наследование", "что произойдёт с дефолтными аргументами функции" и "чем list comprehension отличается от генератора" - это повседневный синтаксис, который встречается практически в любом проекте.
Кстати 65 тысяч это разве не зарплата курьера? А тут даже не про джуна речь а про мидла... Как всегда чем ниже зп тем больше приколов.
А там 100 фигурировала. Невнимательно прочитал. Но зачем тогда писать про 65 было. 100 тоже маловато на мидла, нет? Мне на заводе больше платили когда я в командировке был. А тут какой то неравноценный обмен получается.
Поставил плюс.
При всей эмоциональной составляющей и далеко идущих и необоснованных предположениях об опыте соискателей перечисленные примеры реально полезны для всех уровней компетенций.
Я выявил для себя одно правило: после ответа кандидата (правильно или неправильно) на задачу, задаю ему дополнительный вопрос на знание принципа, которому посвящена задача. Это очень сильно помогает понять, на основании чего соискатель так ответил. А если ответил неправильно, знал ли он принцип на самом деле или не смог сразу ответить из-за каких-то причин.
Мне кажется кандидат если не уверен то должен об этом прямо сказать, и сказать что знает и что не знает о задаче. Если он с покерфейсом отвечает неправильно то разве это не должно быть красным флагом? Ну мол склонность скрывать ошибки и всё такое. Это же потенциальная катастрофа.
Добрый день! Спасибо за конструктивный комментарий! Полностью согласен, что уточняющие вопросы после основного ответа дают гораздо больше информации о реальном понимании принципов. Иногда человек может растеряться, но по рассуждениям видно, что фундамент есть.
55 == True is True
Я, питонист с ~15-летним опытом, смотрю на это, и у меня какая-то агрессия и зубы скрипят
- Не важно что вернёт это выражение так как оно не пройдёт код-ревью.
- Но у нас такой код!
- Прощайте.
- Но постойте, вот у нас ещё ромбовидное наследовние, посмотрите какая прелесть!
*убегает*
Спасибо за статью, интересно было почитать как мыслит интервьюер и оправдывает такие вопросы на собеседованиях.
У меня 3.5 года опыта фулстеком. 2 года на битриксе и задач сложнее вывода карточек в цикле не было, я даже БД ни разу не открывал. Когда понял что это дно и я недоразраб, пошел учить ларавел и реакт, сейчас уже 1.5 года работаю в этом стеке и получается что опыта у меня 3.5 лет, но на собесах когда спрашивают подобные вопросы, они тоже приводят в ступор и к реальным задачам на проектах отношения не имеют и интервьюеру может показаться что я накрутил опыт.
Но я действительно 3.5 лет работал над коммерческими проектами, просто про их сложность никто не спрашивал, а битрикс так это вообще красный флаг в некоторых фирмах. И да в фирме где я работал на битриксе, я под года был вообще 1 разработчиком, сам себе синьер, в целом и сейчас так, нету какого-то тимлида или другого человека на проекте, сам все решаю. Но собес подобный вашему завалил бы… К чему я это все говорю, к тому что не всегда все опыт накручивают, я тому пример)
Спасибо, что поделились своей историей! Полностью согласен, что реальный опыт может быть разным, и не всегда сложность задач в прошлом отражает реальные навыки кандидата
Моя статья не про людей, которые честно работали в своей зоне ответственности, даже если стек был простым. Она про ситуации, когда опыт намеренно приукрашивают и не могут подтвердить даже базу.
То, что вы честно пишете про свой путь и открыто говорите о сложностях, наоборот, вызывает уважение - и такие кандидаты обычно быстро догоняют новые требования
Я один уверено и правильно ответил лишь на первый вопрос? А над остальными посмеялся, пытаясь выбрать предположительно правильный вариант из множества придуманных, не подглядывая в ответы?)
P.s.Я не спорю, подобное может быть удобным и к подобному можно приспособиться, начав эффективно использовать... но для человека из вне это какая-то магия, причём не понимаемая сходу...
P.p.s.Скажите, авторы Python подрабатывают в отделе кадров и/или часто проводят технические собеседования по нему? А то получается подозрительно удобный язык для отсева не владеющих им ;)
В Java есть класс мысленных задач, которые называются java puzzlers. Там тоже применяется базовый синтаксис, результаты исполнения которого можно вывести, зная "базу". Тем не менее, самые синьористые синьоры поголовно допускают в них ошибки, потому что это именно головоломки, а не типовой продакшн код, с которым они имеют дело ежедневно. Более того, даже если подобное встречается в реальной работе, результат легко узнать при помощи исполнения этого кода.
Ваши примеры - скорее из области головоломок, а не проверки базы.
Понимаю вашу аналогию, но в примерах из статьи не ставилась цель устроить головоломку :)
Все задачи - это повседневный синтаксис Python: базовое наследование и MRO, работа со списками и аргументами по умолчанию, comprehension, хешируемость ключей. Эти вещи встречаются в продакшн‑коде регулярно и знать их полезно хотя бы для того, чтобы писать поддерживаемый код без неожиданных ошибок
Эти вещи встречаются в продакшн‑коде регулярно
Регулярно? Вашу компанию в студию, будем знать, что обходить стороной.
Обходите лучше любые компании стороной, так надежнее будет :)
Говорю вам как человек, который знает достаточно много весьма бесполезных тонкостей как минимум 3-4 языков, на которых я периодически пишу (ну нравится мне копаться в кишках, не могу ничего с собой поделать — просто интересно как это работает). Я бы обходил вашу компанию стороной, если вы реально так проверяете кандидатов на адекватность и реально так пишете код.
Ответ на большую часть вопросов для уровня синьора и выше - "Не делайте так НИКОГДА".
Не важно что вернёт выражение и выпонится ли код вообще, просто не пишите chain comparison с комбинацией "==" и "is". Да и два "is' тоже не пишите. Просто потому что такой код плохо воспринимается и в нём легче пропустить баг.
Наверняка каждый, кто писал функции на Python, хотя бы раз встречал такую ситуацию
Если работал в нормальной компании и не говнокодил сам - вполне мог и не встречать. Довольно странно обвинять людей во вренье просто на том основании, что им не пришлось читать и писать плохой код.
Кандидат сбежал в слезах. Про накрутку опыта
А где название компании, в которой работает автор? Ну, чтобы знать, где работают такие рекрутеры, которые настолько гордятся тем, что доводят рекрутеров до слёз, что даже выносят это в название своих статей на хабре.
Я, конечно, не питонист, но все приведённые примеры выглядят как антипаттерны на которые не то что не надо знать ответ - их в продакшн коде вообще не должно быть
Тут скорее проверка знаний языка.
Нет проблем в том, чтобы посмотреть как сделано в другом месте и скопировать. Оно будет работать.
Но если человек не знает как работает язык/движок/среда, то он не сможет ответить на вопросы с какой-то ерундой вместо реального примера кода.
Вообщем это не проверка на опыт, это проверка на знание движка. Чтобы кандидат мог разложить пример на составляющие и уже по составляющим ответить на основной вопрос. Одновременно проверка на знание ядра и на логическое мышление.
Оно никак не поможет выявить накрученный опыт (ну разве что было указано работа с интерпретатором).
Мне кажется, сейчас появился отдельный раздел на собесах с system design как раз для того, чтобы отсеивать людей с накрутками от тех, кто забыл/не знает движка.
Я даже по себе сужу. Я многих особенностей движка не помню, могу их загуглить и вспомнить быстрее, чем если бы было с нуля. Но тем не менее с ходу на вопросы не отвечу.
То что человек не смог ответить на ваши вопросы не обязательно говорит о том, что у него нету опыта.
Спасибо за комментарий! Конечно, отдельный вопрос или даже несколько не дают полной картины. В статье приведены лишь отдельные примеры, которые хорошо показывают именно знание базового синтаксиса и принципов Python. Знание, который, как правильно, заявлено в резюме.
На реальных собеседованиях это только часть проверки, есть и практические задания, и обсуждение архитектурных решений, и реальные кейсы. Но если человек совсем не ориентируется в базовых вещах, то это, как минимум, сигнал к тому, чтобы копнуть глубже. И как показывает практика, зачастую копать глубже некуда
Вот такие каверзные вопросы совсем не нужны. За такой код надо бить по рукам на код-ревью. И сенъеры с ним почти не сталкивались уже лет 10 к моменту собеседования. Помнить все это наизусть - это не база а бессмысленная зубрежка.
Код пишется в первую очередь для чтения человеком, и только потом - для компьютера. Особенно это применимо к питону, который медленный донельзя и синтаксическими конструциями косит под английский язык.
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")
А это же "база", "основы синтакстиса языка", и не важно что в реальности так практически никто не пишет.
for i in range(2):
print(i)
break
else:
print("end")Так. Правильно и я понимаю, что этот код бодро напечатает
0
и доблестно выйдет из цикла? А, вот, если бы не было инструкции break, то он напечатал бы все числа из диапазона (0 и 1) — каждое — на свой строчке, и напечатал бы также на отдельной строчке "end"?
Да. Но я сам перед написанием сообщения его запустил и проверил. До этого просто помнил, что после цикла можно написать else и никогда ни сам не писал, ни в реальном коде не видел.
Это пример бесполезного вопроса про "базовый синтаксис", на котором могут завалиться куча народу, но который ничего не говорит о реальных навыках.
А как нынче дойти до технического собеседования?
Я не очень понял мораль сей басни.
Автор обижен, что программисты без знания как работает тру из тру, накручивают опыт и тем не менее зарабатывают больше его самого?)
Еще и виновных пытается найти.
А ведь все просто. Рынок решает. Кто-то взял спринг, jpa, докер, а еще лучше зерокод и другие готовые шаблоны и выкатил через неделю сервис продажи лабубы. И заработал больше автора раз в сто. Кто сидит и пишет прошивку косморакете, за идею. Обидно? Мне нет. Каждому свое.
Вы сильно обобщаете и достраиваете картину за меня :)
В статье нет ни слова про "обиду" или про то, что кто-то зарабатывает больше. Речь о другом - о том, что приписанный опыт легко проверяется на базовых вещах, и это вопрос честности, а не зарплат.
Кстати, люди, которые не знают базы, действительно чаще всего оказываются на проектах "галерного" типа с ограниченными задачами. Рынок это тоже решает.
А мне вот сегодня задали
a=5
print(a is 5)
a=45234
print(a is 45234)
ну то есть в историческом разрезе интересно (во 2м питоне было бы True False, а в современных True True)
но вот зачем это знание может пригодиться в принципе и что именно показывает - загадка, это прям эталонная задача из серии "приколы нашего городка"
Это не "прикол", а демонстрация разницы между == и is. Числа до 256 кэшируются, поэтому результат может удивлять. Понимание этого нужно, чтобы не путать сравнение значений с проверкой идентичности объектов.
А числа больше 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 заставлять ковыряться, для особых энтузиастов наверняка занимательно, но пользоваться инструментом никак не помогает
Это всё конечно интересно. Я так понимаю эту интересную особенность переняли из Java. Там то же любимый вопрос сравнить числа типов int и Integer, через == и equal. И да по умолчанию для типа Integer поведение такое же как и с примитивным типом int до значения 256. Но вот, специально для таких любителей "умных" вопрос я этот параметр переопределял для java машины. Весело было смотреть на них когда поведение, не совпадало с тем, что они ожидали. Ведь это куда важнее понимать, как ты можешь сконфигурировать движок для своего таргета. И какую пользу можно из этого получить. Есть и техники докручивания Java до real-time языка, путем манипуляций со сборщиком мусора и прочих твиков машины. Это вот куда интересней, чем странный код.
На 3.10 win/64:
>>> a=45234
>>> print(a is 45234)
:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
False
ага, прикол, через 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
Буду проститукой.jpg
Автору в копилку. Python vs PyPy.
C:\Users\Keeper>python
Python 3.12.6 (tags/v3.12.6:a4a2d2b, Sep 6 2024, 20:11:23) [MSC v.1940 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 5
>>> a is 5
<stdin>:1: SyntaxWarning: "is" with 'int' literal. Did you mean "=="?
True
>>> a = 1234567
>>> a is 1234567
<stdin>:1: SyntaxWarning: "is" with 'int' literal. Did you mean "=="?
False
>>> ^Z
C:\Users\Keeper>pypy
Python 3.11.11 (b38de282cead, Feb 05 2025, 15:27:02)
[PyPy 7.3.18 with MSC v.1941 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>> a = 5
>>>> a is 5
<python-input-1>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
a is 5
True
>>>> a = 1234567
>>>> a is 1234567
<python-input-3>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
a is 1234567
True
>>>>
Автор еще не дошёл до полезной мысли, что он удовлетворяет своё эго, вместо решения задач бизнеса. Задача бизнеса закрыть вакансию, а не то чтобы кандидаты в слезах убегали.
Проверять знание базового синтаксиса у сеньоров, это как проверять работу карьерного самосвала в детской песочнице.
Последние 10-лет стараюсь собеседовать людей в формате разговора, основная задача понять как человек мыслит. Вторая задача это помочь человеку нащупать дальнейшие шаги для роста, где он сможет совершенствоваться. Третья задача впитать в себя нетривиальный опыт человека - он тоже многим может поделиться, с чем вы не сталкивались.
Я понимаю вашу позицию про "разговор и мышление", и это правильный элемент собеседования. Но важно помнить: если человек не знает элементарных основ инструмента, на котором он "якобы работает", это риск для бизнеса.
Это как нанять механика, который отлично рассуждает о логистике автопарка, но не знает, как снять колесо или что такое ГБЦ. Его опыт может быть широким, но без базовых знаний он просто не справится с типовыми задачами. Зачем бизнесу нужен такой механик?
Поэтому проверка базы - это не "удовлетворение эго", а минимальная защита от того, чтобы не тратить месяцы на человека, который красиво говорит, но не умеет работать с инструментом. А уже после базы действительно важно оценивать мышление и опыт.
Скорее, это вопрос уровня "какой тепловой зазор ГРМ у mitsubishi outlander 2010 года выпуска", на который любой инженер покрутит у виска. Ибо такие вещи нужно читать в справочнике, а не вспоминать. Ну и с текущим темпом развития LLM нужда знать нюансы языка будет снижаться, особенно для таких популярных ЯП, как python. Так что лично я проверю общее умение программировать на уровне задачки 4-5kyu с CodeWars.
с текущим темпом развития LLM нужда знать нюансы языка будет снижаться
Ну вот кстати если продавцы ллмок правы, и мы окажемся в том дистопийном мире который они хотят нам построить, нужда знать мелкие гнусные нюансы языка только увеличится. Вместо того чтобы писать код мы будем ревьюить генеренное, а там будут 55 and True or False is not -1 if 55 and False else -1 and not True.
Дополню свой предыдущий комментарий. Как уже некоторые комментаторы писали, этот «тест» не показывает реальный опыт. Промолчу про задачку с условиями (за такой код надо бить). Но возьмём то же множественное наследование: это как нужно было накосячить с архитектурой, что пришлось к нему прибегать? Соответственно, разработчик никогда с ним мог и не сталкиваться. Даже за 8 лет. Comprehension — часто работаю с генераторами и сетами, поэтому сходу могу ответить. Потому что сталкивался. Однако же я понимаю, что даже гораздо более опытный человек мог их не встретить на вполне реальных проектах. Так что эти вопросы не показывают накрутку опыта. Знание некоторых тонкостей — да. Но не опыт.
P. S. Comprehension я бы спросил. Но ответ был бы плюсиком кандидату, а не «индикатором накрутки». И при прочих равных отдал бы предпочтение кандидату с более широким «кругозором» в плане технологий и ЯП, чем того, который кроме питона и его спецификации не видел ничего.
Один сеньор рассказывал, что как-то собеседовал кандидата на позицию сеньора. Кандидат был уверенным и казалось эрудированным, сыпал терминами. И под конец сеньор, уже готовый закончить собеседование, решил все-таки попросить кандидата решить пару простых задачек на лайвкодинг. И оказалось, что человек просто не знает языка. "Я был поражен, как можно буквально не знать синтаксис языка, не знать как писать буквы на этом языке, и при этом идти на собеседование на сеньора".
изучать нужно не языки, а программирование - стандартные методы решения проблем. В остальном все языки одинаковы, различаются возможности и синтаксис.
Возможно, функциональные языки немножко выделяются в особую категорию, так как редко кто начинает осваивать программирование, например, с хаскела. Но, освоив любой из них, можно перескакивать на любой другой, просто имея под рукой документацию (а в наше время еще и ллм).
Условно, если вы знаете, как работает внедрение зависимостей, то достаточно загуглить, как это реализуется в конкретном языке.
Позволю с вами не согласиться. Есть важные особенности.
Например, Golang много взял от Python в смысле синтаксиса. Но Golang статической типизации, а Python - динамической. Golang компилируемый, а Python - интерпретируемый. Да вдобавок ещё у Golang классы отсутствуют он не OOP язык.
Только Golang заточен под параллелизацию со своими горутинами. А в Python только собираются завезти многопоточность, а в JS - даже не собираются. Так что тут масштабируемость только контейнерами и микросервисами.
Так что да, подобные задачки нужны только для самоутверждения. А если и код в компании написан таким же образом, то мне прям жалко тех кто с ним работает.
Но языки и их особенности тоже важно и нужно знать. А ещё и инструменты вокруг языков. Poetry, Maven/Graddle, Conan.io, и т.д.
А то смотришь код пишет такой что и не разобраться, а объяснить virtual environments не может. Как работать с .env - не знает. Настроить, IDE и то не может.
И тут проблема, что и LLM может не помочь, чтобы от него правильный ответ получить нужно знать хотя бы ключевое слово.
Задача кадровика и лида уже давно превратилась из "нанять и закрыть потребность в кадре" в "максимально отсеить и задавить, даже самых лучших". Ну и конечно же месяцами создавать видимость бурной деятельности.
Раньше в стартапах был энтузиазм. Ты мог действительно проявить себя, показать свои сильные стороны, улучшить слабые, реально узнать и научиться чему то новому в процессе, без чувства что ты оказывается дурачок, раз забыл как расшифровывается какая то абревиатура.
Сейчас все эти бигтехи, финтехи, маркетплейсы, корпорации это тупо ботофермы, куда пытаются натолкать болванчиков по методичке. Разве к этому все стремились? Идти на поклон к мальчику/девочке, который считает себя успешным HR и QA при этом не понимая отличия java от javascript и бодаться за ставку в 2 копейки?
По ходу чтения статьи складывается впечатление, что сбежал в слезах как раз-таки не кандидат, а интервьюер.
Напридумывал таких вопросов каверзных, любого завалить могут, а на них никто не отвечает, и еще дурацкими называют, уж на хабре сейчас напишу, что все кандидаты сами дураки, и сами они дурацкие.
Великолепная статья. Описанная проблема действительно существует, и в какой-то мере "ломает" найм. По сути, накрутка опыта - это мошенничество. В проигрыше и работодатели, которым всё сложнее найти достойного кандидата (или ещё хуже - принять "накрутчика" без реального опыта, не способного справляться с задачами), и честные кандидаты с реальным опытом, которым всё сложнее пробиться сквозь эту толпу. Советы даны здравые, примеры - неплохие. Откуда же столько минусов, интересно? Не от тех ли, кто публикует статьи в стиле "как быстрее вкатиться в айти и устроиться на первую работу", со скрытыми намёками на накрутку опыта и рекламой телеграм-канала в конце? А такие статьи обычно оказываются заплюсованными. Вот такой контингент.
Минусы - потому что описанные в статье каверзные задачки не проверяют ничего, кроме знания наизусть стандарта языка. С опытом это знание не коррелирует. Поставленную задачу описанная в статье процедура не решает.
Они проверяют, действительно ли человек работал на этом языке программирования (как написал в резюме), или нет. Если человек каждый день пишет на языке в течение нескольких лет, он без проблем ответит на эти вопросы. Или по крайней мере сможет рассуждать. Если нет - будет молчать и не знать что ответить, всё именно так как описано в статье.
Один сеньор рассказывал, что как-то собеседовал кандидата на позицию сеньора. Кандидат был уверенным и казалось эрудированным, сыпал терминами. И под конец сеньор, уже готовый закончить собеседование, решил все-таки попросить кандидата решить пару простых задачек на лайвкодинг. И оказалось, что человек просто не знает языка. "Я был поражен, как можно буквально не знать синтаксис языка, не знать как писать буквы на этом языке, и при этом идти на собеседование на сеньора".
Если человек каждый день пишет на языке в течение нескольких лет, он без проблем ответит на эти вопросы
Нет, самые матерые сеньеры не будут знать всех этих тонкостей наизусть. Они все как один скажут: "не помню что тут именно происходит, я за такой код ругаюсь на код ревью, сам ничего подобного 20 лет уже не писал".
Рассуждать сможет, да, но желаемого ответа не даст.
И оказалось, что человек просто не знает языка.
Для этого гораздо лучше подойдет fizz-buzz, тестовое задание или даже алгоритмическое интервью (которое еще проверит и смекалку с базой в computer science).
Если человек каждый день пишет на языке в течение нескольких лет, он без проблем ответит на эти вопросы.
Нет. Я 10+ лет пишу на питоне (хоть это и не единственный мой язык) и том что кортеж куда-то себе полезет выяснять хэшируемость я узнал из этой статьи. А не сталкивался я с таким исключительно потому что программиста, додумавшегося использовать ("a", [1, 2])в качестве ключа словаря, я уволю раньше, чем он успеет запустить свой код.
Любители ромбовидного наследования, аналогично, отсеиваются ещё на первом созвоне.
Минусы не из‑за "каверзных задач", а из‑за того, что статья задела за живое. Наследование, comprehension и работа с дефолтными аргументами - это не "знание стандарта наизусть", это повседневная база языка. Эти вещи встречаются в любом рабочем проекте, и их понимание проверяет не память, а умение мыслить в терминах Python
Минусы - это эмоции: никто не любит вспоминать, как на собеседовании "поплыл" на базовом вопросе. Но от этого реальность не меняется: базовые знания важны
это не "знание стандарта наизусть", это повседневная база языка.
Да, особенно повсеместно встречаются конструкции вроде 55 == True is True.
Я, например, писал и читал достаточно кода на питоне, но почти никогда не писал на нём в ООП-стиле с множественным наследованием. Поэтому не понимаю, в каких ситуациях это стало "базой". На вопрос про наследование из статьи я бы не ответил, и наверняка я этот ответ забуду через месяц, потому что мне такие примеры не будут встречаться.
Не стоит воспринимать свой опыт как универсальный. Если вам не приходилось сталкиваться с множественным наследованием - это нормально, но это не значит, что таких случаев нет и что понимание MRO не является базовой частью языка.
Я, например, писал и читал достаточно кода на питоне
Понятие растяжимое: для кого-то это несколько учебных проектов, для кого-то - большие продакшн-системы. В статье речь именно о фундаментальных знаниях, которые полезны независимо от конкретного стиля или стека задач.
Не стоит воспринимать свой опыт как универсальный
Я могу вам дать точно такой же совет. Если вы сталкивались только с проектами с множественным наследованием, то это не значит, что они все такие, и тем более не значит, что это "база".
В статье речь именно о фундаментальных знаниях, которые полезны независимо от конкретного стиля или стека задач
В этом и проблема, что в моём стеке задач того, что лично вы считаете фундаментом, не было. Поэтому ваш совет к вам точно так же применим.
(Само применение множественного наследования в современном ООП - это вообще отдельный вопрос.)
Вам уже сто раз в комментах сказали, что минусы из-за каверзных задач, а вы все равно что-то себе придумываете. Из-за каверзных примеров на грани идиотизма, которых НЕ ДОЛЖНО встречаться в повседневном коде НИКОГДА! (да, не все примеры в статье такие, но достаточно и одного. А он не один!)
Наследование - это повседневная база языка. У вас задача не на наследование, а на ромбовидное наследование, за которое надо гнать ссаными тряпками.
Тупл неизменяем. Лист изменяем. Но у вас задача на тупл с листом в виде ключа хеш-таблицы. Это повседневная база языка? Вы томограмму давно делали? Говорят, помогает на ранних стадиях выявить... Да, я ответил на этот вопрос, хотя с пистоном последний раз общался лет 10 назад. Но сначала мы вынесем мозг человеку зашкаливающим идиотизмом задачи, а потом посмотрим, как он будет догадываться, какого ответа, от него ожидают...
Ну и да, заголовок "Кандидат сбежал в слезах" действительно вызывает эмоциональную реакцию - это видно и по комментам. В нём есть доля иронии, но понимаю, что для кого-то звучит по‑детски. Тем не менее тема статьи серьезная - про накрутку опыта и её последствия.
Добрый вечер! Благодарю за конструктивный комментарий!
Минусы - ожидаемая реакция. Статья затронула болезненную тему: многим комфортнее, когда на собеседовании "разговаривают за жизнь", а не проверяют базовые знания.
Красиво рассказывать о своем опыте умеют многие, а вот показать его на практике - не всегда. Именно эта диссонанс и вызывает негатив. Но в этом и был смысл статьи - показать проблему, а не гладить всех по голове. Хейт - это тоже обратная связь и показатель, что тема действительно задела за больное
Профессиональные программисты высказались, но мне тоже хочется добавить. Я лет 5 разрабатываю проект для замены платного аналога. На питоне. Параллельно иногда скрипты простые пишу. Вот я однажды использовал изменяемый объект в качестве аргумента по умолчанию - получил проблему, решил проблему. Стал всегда писать через if a is None. То есть я сталкивался с этим. Ответил бы я на ваш вопрос? Нет. Я забыл уже, я просто так больше не делаю. Тоже самое с 55==True.
ПМ: лично мне статья понравилась. Напомнила о вещах, которые я когда то тестировал, но забыл результаты
Благодарю за комментарий!
Стал всегда писать через if a is None.
Про такие моменты и идет речь в статье. Если человек работал с языком, он узнает конструкцию, вспомнит, что она означает. Думаю увидев код, вы бы тоже сразу сообразили к чему этот пример.
Честно, я не вспомнил пока не прочитал ваше объяснение. На вашем собесе я бы завалил вопрос.
Если бы вы свои вопросы до такого же уровня опустили, такой негативной реакции бы не было.
Негативная реакция - это ожидаемо. Статья задела людей, потому что многие проецируют ее на собственный опыт
Заголовок и примеры вызывают эмоции, а эмоции часто включают защитную реакцию. При этом цель статьи не обвинять кого-то лично, а показать проблему "накрученного" опыта. Интересно, что под "нейтральными" статьями вроде "как работать с переменными в Python" люди почти не оставляют комментариев - они просто читают и идут дальше. Здесь же пошла дискуссия, а это уже показатель, что тема действительно задела.
Вы так говорите, как будто эти условные эмоции обесценивают аргументы. Только тут эмоции не те, о которых вы думаете. Тут не "блин, я же этого всего не знаю, я самозванец и не настоящий сенъер с накрученным опытом", а "блин, опять эти самоутверждающиеся сенъеры придумывают абсолютно абсурдные и вредные интервью".
Да, статья, возможно, не самая однозначная и она провокационная, но лично мне она нравится, и я знаю людей, которым она тоже зашла.
Просто в этих эмоциях и тексте статьи многие видят отражение самих себя - и это нормально, потому что тема болезненная.
И мне кажется, такая статья намного лучше, чем 95% мусора, сгенерированного LLM, который даже читать неприятно, или публикаций вроде «Как я заработал 100 млн на маркетплейсе, а потом у меня всё забрали» - которые вообще к тематике IT не относятся.
Т.е. ваша цель была написать провокационную статью? А вы пробовали предупреждать заранее о подобных вопросах? Наверняка для многих это были неожиданные вопросы - в стрессе, когда голова забита другой информацией, можно просто ляпнуть что-то глупое в попытках, учитывая контекст, найти сложный ответ на простой вопрос. Много ли разработчиков уровня сеньор согласятся пойти на такой собес, заранее зная, что будут такие вопросы?
Цель статьи - показать, как выглядит накрученный опыт со стороны, и какие простые задачи реально задают на собеседованиях.
Заголовок провокационный, и он вызывает у многих эмоциональную реакцию, иногда даже сильнее, чем сами примеры. При этом сами задачи реальны и встречаются в интервью, это не "вопросы с подвохом". Да, в стрессовой ситуации можно ошибиться - это нормально, поэтому в реальных собеседованиях после таких вопросов обычно идут и практические задания, и архитектурные обсуждения, чтобы получить полную картину.
Давайте сразу определимся, что личный опыт - это всего лишь личный опыт. А не правила верховной инстанции.
Я попробую описать, когда заложенное в статью мировоззрение верно, с моего личного опыта.
Вы считаете, что человек ничем в жизни не занимался кроме 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 или ещё кого-то. А способен сам провести простую операцию подбора инструментов для проекта?
Спасибо за развернутый комментарий и интересный пример из вашего опыта! Полностью согласен, что senior-уровень - это не только владение конкретным языком, но и умение подбирать стек под задачу, понимать инфраструктуру и интеграции.
Однако статья была именно про случаи, когда резюме "накручивают" под конкретный стек (например, Python + автотесты), а на собеседовании кандидат не может ответить даже на элементарные вопросы по базовым особенностям языка, который указал как основной.
То, что вы описали - это широкий инженерный опыт, и он ценен. Но проверка базовых знаний именно заявленного стека нужна не для "выпендрежа", а чтобы убедиться, что человек действительно работал с тем инструментом, который указал. Если он не помнит нюанс - не страшно, но если он в принципе не понимает, как работает конструкция языка - это другой уровень риска для команды.
я извиняюсь, а на кой болт куэю, даже если он Automation, нужно это все знать? Вот чтобы что просто? такой код случайно не написать, а даже если написал, существует отладка. Напомнило ситуацию из примерно 2012го, когда я плюс плюсером был, любили задавать задачки типа "что выведет код C++ + ++C", с ромбовидным наследованием, двойным удалением когда семантика копирования не прописана, удалением через невиртуальный деструктор, delete и delete[], битые итераторы и еще бог весть сколько граблей, но это разрабов спрашивали, а не куэев. У меня стойкое чувство, что автор просто пытается самоутвердиться за счет кандидатов.
Для QA нормальные вопросы - это типа "вот у тебя есть регрессионный автотест, который срабатывает через раз, какие могут быть тут приколы" или "какие тесты нужно написать для: вот форма авторизации, вот вот ручка бэкенда, вот веб морда, туда вводишь номер документа, тебе он выдается, все модно-молодежно-асинхронно", или "как хранить и заливать тестовые данные для регресса", ну ченить такое, специфичное и из опыта
Автоматизация - это тоже разработка.
И да, такие приколы и могут вести к "вот у тебя есть регрессионный автотест, который срабатывает через раз, какие могут быть тут приколы" потому что очерёдность запуска и влияние пропущенного на кодревью списка-по-умолчанию. Или double free в тест на плюсах загнать могут "ну это ж не разработка, зачем детали языка знать".
В целом, в комментариях уже отмечали, но повторюсь: роль AQA действительно недооценивают. Автоматизатор - это не просто "человек, который запускает тесты", это инженер, который пишет код и поддерживает его в рабочем состоянии месяцами и годами.
Почему важна база? Потому что автоматизация - это тоже разработка, со всеми теми же рисками: плохой код = нестабильные тесты = потерянное время всей команды. Разработчику могут простить баг в продукте (он будет зафиксирован как дефект), а у тестов такой "запас прочности" отсутствует: если они ненадежны, ими просто перестают пользоваться.
У AQA есть аналогичный "запас прочности". Ревью автотестов проводят либо коллеги, либо core-разработчики фреймворка в big/fin-техе. Условный баг в тесте тоже простят, он дропнется на первом же nigthly-прогоне и будет исправляться, просто без формального баг-репорта, а пока он на доработке его пройдут ручками при регрессе.
Я не хочу принизить AQA, сам им являюсь, но за мою более чем 3-х летнюю практику я практически не сталкивался с тем, что описано выше, кроме генераторов. И 90% нестабильности тестов связано либо с ошибками в тест-кейсах, либо с неправильным использованием инструментов, либо с непониманием как распараллелить тесты и распределить нагрузку.
За любовь к спискам, беспорядочную лепнину из синтаксического сахара, сомнительных выражений, отсутствия аннотаций типов данных в переменных и методах больно бьют палкой по рукам. Базу конечно знать надо, но как обычно ее больше повторяют для прохождения собесов, чем используют в реальной работе.
Вы начинаете с прелюдии, потом пишете:
Начнём без прелюдий.
И, снова, продолжаете прелюдией. На мой скромный взгляд, для программиста, элементарная логика - это и есть та самая База, которой вам, очевидно, не хватает.
Я бы не придирался к подобной ерунде, если бы статья не была посвящена придиркам к ерунде.
А как же "вайб кодинг"? 😆
"Это База. База. Я базирован. База."
Справедливости ради, после первых двух вопросов пошли нормальные. Но текст статьи так и сочится самодовольством)
В начале статьи как раз указано, что цель - не высмеивать, а показать, как все выглядит со стороны интервьюера. Никого обидеть не хотел, но вижу, что задел половину Хабра - видимо, тема оказалась болезненной.
И да: лучше пусть статья вызывает эмоции и дискуссию, чем будет бездушным LLM-контентом про "как открыть маркетплейс за 5 шагов". Тут хотя бы живой опыт и реальная боль.
Спасибо, убили всё желание пользоваться Питоном.
Почему большинство языков проектируется по "принципу наименьшего удивления", а тут то цепные сравнения с оператором "is", то множественное наследование с "кто первый встал, того и тапки" (если б я в реальном коде увидел такое наследование – я б орал на написавшего его... А вообще в приличных местах множественное наследование допускается или от интерфейсов, или от миксинов, чтобы не допустить такой неоднозначности), то иммутабельных/хэшируемых массивов нет (ну тут ладно, такую хрень всё равно в голову бы не пришло написать).
Спасибо за комментарий! Python действительно не всегда следует "принципу наименьшего удивления", особенно если смотреть на цепные сравнения или множественное наследование. Но именно за счёт своей простоты для изучения и огромной экосистемы он и популярен: скрипты, автотесты, ML, data science.
Для highload‑систем я бы тоже выбрал другой стек, а вот для задач автоматизации и быстрых прототипов Python остаётся отличным инструментом.
У Питона очень низкий порог вхождения и это очень гибкий язык. Он не ограничивает программиста, и надо иметь очень много опыта и дисциплины, чтобы писать хорошо.
Сам язык ничего выдающегося из себя не представляет, но к нему есть много хороших библиотек, не всегда доступных для других языков. (Особенно если учить нейронки) По-факту питон это просто клей между такими библиотеками, описывающий какую-то высокоуровневую логику.
Но у этих библиотек из-за гибкости и динамичности питона свой синтаксис и их тоже надо осваивать. Например, в numpy есть куча всяких мощных операторов, функций и правил броадкастинга многомерных массивов, но их знание не имеет ничего общего со знанием языка.
И к сожалению не все популярные библиотеки с хорошим api, например pandas или matplotlib на мой взгляд совсем неочевидные, каждый раз когда приходится сталкиваться с ними, написание кода похоже на шаманство.
Посмотрел все примеры и у меня только один вопрос: скажите, пожалуйста, где вы работаете?
Чтобы я ни в коем случае туда не ходил
А по-моему, они там опыта накручивают в соответствии с рекомендациями тех курсов, которые они проходили. Это там их учат накручивать и врать.
Там же их учат отвечать на эти "базовые" вопросы, а вот заваливать этот "тест" как раз и будут "не накрученные" кандидаты.
Про курсы рассказывал в другой статье https://habr.com/ru/articles/908744/, там тоже не все однозначно
Спасибо за статью. Соглашусь, что в целом всё базированное, но многие моменты мог бы сам сходу неправильно назвать из-за непривычного написания, или обилие разных скобок. Это конечно говорит больше о том, что не нужно сильно торопиться)
Смущает пример с ООП. Мне за 4 года множественное наследование приходилось использовать пару раз, и скорее всего провалил бы вопрос.
Спасибо за конструктивный комментарий! Даже если вы сходу ответили только на часть вопросов - это уже показатель хорошего практического опыта.
Согласен, что множественное наследование встречается не всегда, особенно если проект небольшой или используется строгая архитектура. Но в библиотеках, фреймворках, а особенно в AQA/SDET-позициях такие вещи встречаются чаще - там приходится работать с обвязкой, расширять готовые классы и переопределять методы. Иногда это даже переходит в работу с метаклассами.
На моей прошлой работе руководитель как-то сказал, что надо бы ему курс по питону пройти. Да и в целом он не вызывал впечатление шарящего человека в питоне, и я на 200% уверена, что он не ответит ни на один вопрос из статьи, что не мешает ему быть лидом и получать свою зп, вот уж точно магия.
Спасибо, что поделились наблюдением!
Быть руководителем и быть активным разработчиком - разные роли. Руководитель может быть сильным в управлении процессами, планировании и мотивации команды, но при этом не писать код годами. И это нормально. Таких еще называют "манагерами"
В статье же речь шла именно об исполнителях, от которых ожидается, что они умеют уверенно работать с инструментами, не допуская элементарных ошибок. То есть если человек заявляет опыт работы именно как разработчик или автоматизатор - хотелось бы видеть соответствующие базовые знания. А не забивание гвоздей микроскопом, когда рядом лежит молоток
Для чего так скрупулёзно проверять знание наизусть синтаксиса языка? Люди программы в блокноте пишут? Без подсветки синтаксиса? Или написанный код идёт сразу в прод?
Вероятно, для копания в чужом [говно]коде. Не скажу, что силён в питоне (вообще не программист, больше пары десятков кб в одной задаче не писал), про генератор на вопрос вряд ли бы ответил хотя бы потому, что в голову никогда не приходило печатать, а не итерировать, но большинство вещей из статьи вызывает желание либо переписать на что-то более приличное, либо сделать git blame.
Питон всё же обычно запускается не там, где требуются странные алгоритмические трюки из-за недостатка ресурсов и надёжнее писать так, чтобы код был понятен кому угодно и при этом интерпретировался однозначно и человеком и разными версиями языка (неявное поведение может быть изменено в следующих спецификациях или просто в разных реализациях, включая какой-нибудь micropython).
Обычно кандидату дают писать там, где ему удобно - в редакторе, в IDE или даже на листочке. Главное - понять, понимает ли человек, что он пишет.
Забавный факт: пару раз сам попадал на собеседования, где просили открыть обычный блокнот и писать там. Тогда это не казалось странным - просто писал и все.
Из практики помню случай: кандидат с 4 годами опыта на позиции Middle, которому предложили в онлайн-редакторе написать простой декоратор. И он честно сказал: "Я забыл, как пишутся функции, потому что IDE делает все за меня". Вот для таких случаев и нужны базовые проверки - это не каверзные задачки, а обычные конструкции языка.
И он честно сказал: "Я забыл, как пишутся функции, потому что IDE делает все за меня". Вот для таких случаев и нужны базовые проверки - это не каверзные задачки, а обычные конструкции языка.
Простите, а зачем помнить всё то, что IDE позволяет не помнить? Память это дефицитный ресурс, который всегда чем-то занят - разве не лучше, чтобы память была занята тем, что действительно нужно помнить для конкретной работы над конкретными проектами?
В реальной жизни легко можно попасть в ситуацию, где приходится иметь дело с довольно широким спектром языков и технологий. У меня в итоге сформировалась привычка в принципе не пытаться запоминать - всё равно забуду, вытеснится постоянно поступающей лавиной информации. Помню только то, что делаю достаточно регулярно, остальное важное - записываю. Ну и не ленюсь проверять документацию и делать микроскопические тестовые кейсы в случае сомнений по поводу того или иного поведения. Зато не завязан на своём основном языке, могу и пишу ещё на нескольких (регулярно обращаясь к ещё 19, нюанс продукта). И очень сильно полагаюсь на IDE, иначе памяти не хватит. Это прямо вот так плохо?
Можно многое не помнить и действительно полагаться на IDE - это нормально и в повседневной работе никто не держит все в голове.
Но есть базовые вещи, которые специалист должен понимать, даже если не помнит синтаксис наизусть. Это как с механиком: он может не помнить момент затяжки каждого болта, но он знает, как пользоваться гаечным ключом и зачем он нужен.
Точно так же в программировании важно понимать базовые принципы языка и то, как он работает "под капотом".
Базу проверяют на предмет мышления. Если извилины плоские то логика в них соответственно будет только по прямой от точки до точки.
Олимпиадные задачи как раз проверяют "извилины" и умение искать нестандартные решения :)
А вот "вопросы за жизнь" чаще показывают только опыт разговоров и терминов, услышанных где-то в коридоре, но не обязательно реальное понимание сути. Поэтому и нужны простые вопросы на базу - чтобы понять, есть ли фундаментальное понимание, а не только набор красивых слов.
Считаю в собесе не должно стоять задачи нахождения результата. Только поиск решения для того чтоб понять собеседующий жив или мертв. Программирование, как минимум инженерная специальность, куда счас лезут все, в том числе и зомби.
И тут не стоит путать с администрированием где приоритетом уже становится не мышление, а опыт.
Странно почему у этой статьи столько минусов, а реально опытных людей еще поискать надо, да и в целом такие сущности давно берега потеряли - им все готовое подай и за них еще сделай, и ныть умудряются еще как им на 100к+ зп в месяц жить...
Думаю, минусы в основном прилетели от тех, кто в статье увидел себя и среагировал эмоционально. Статья написана в провокационном стиле - чтобы обсуждали, спорили, делились опытом.
Ну и Хабр есть Хабр: посты в духе "Как я вырастил куст размером с дом" собирают плюсы быстрее, чем статьи про практическую инженерию :)
почему у этой статьи столько минусов
Потому что автор упорно делает вид, что его вопросы - это фундамент языка, хотя ему уже несколько сказали, что как минимум множественное наследование - это не база и не используется часто. Но автор это упёрто игнорирует и со всеми спорит в пассивно-агрессивном тоне.
Спасибо всем, кто высказался - и тем, кто согласен, и тем, кто не согласен. Судя по реакции, статья задела за живое, и это нормально :)
Да, задачи в статье - базовые, но сама форма "что выведет код" вызывает у многих ощущение "подвоха" и ассоциируется с собесами, которые больше напоминают проверку на память, чем оценку инженерных навыков. Возможно, это и стало основной причиной негатива.
Цель текста была не "разоблачить кандидатов" и не "похвастаться сложными вопросами", а показать, как накрученный опыт легко вскрывается на простых примерах. Понимаю, что заголовок и подача получились провокационными и могли усилить эффект.
Спасибо за обратную связь - она помогает увидеть статью глазами других и понять, какие темы особенно триггерят сообщество.
Судя по реакции, статья задела за живое
Да, но не нас, а вас, судя по тому, как рьяно вы упираетесь и повторяете одни и те же фразы. Может быть, под словом "база" вы понимаете что-то своё, но это тоже не наша вина и проблема.
показать, как накрученный опыт легко вскрывается на простых примерах
Ещё раз, у вас ошибка в (базовой) логике. Вы пытаетесь вывести следствие "не знает ответа на мои конкретные вопросы" -> "однозначный рисователь опыта". Но вы никакого логического вывода этому утверждению не предоставили. А другие, включая меня, предоставили опровержения. Подача и заголовок здесь не при чём. Чистая логика и ничего больше.
накрученный опыт легко вскрывается на простых примерах
Неа. Умный волчара заучит всю вашу тупорылую бредятину либо воспользуется ИИшным интервью-копилотом. А опытного трудягу, который по-честному реализовывал баги и фиксил фичи, вы пошлёте в жопу
Но самый парадокс кста в том, что перформить эти двое будут одинаково, потому что в IT нет ничего сложного. Просто кому-то не влом и не западло перепрыгивать через ваши горящие обручи
вашу тупорылую бредятину
ух ты сколько высокомерия) вот так-таки бредятина? Можете привести пример и объяснить в чем бред? Автор статьи приводит элементарные вопросы, связанные со знанием основ языка.
Умный волчара
А сможет "волчара" в лайвкодинг, без опыта? В ревью чужого кода? В глубокие вопросы - что происходит в этом участке кода, как он работает...? Да, в статье этого нет, но статья, напомню, про собеседование тестировщика
опытного трудягу
никто не мешает трудяге готовиться к собеседованиям и повторять элементарные вещи.
перформить эти двое будут одинаково
Очень спорное утверждение. "Вкатун" после курсов, натасканный на прохождение собеседований, и мидл с 3-4 годами реального опыта. Вы серьезно думаете, что первый сможет справляться с производственными задачами так же, как второй? Даже в этой статье в комментах приводили примеры, как пропускали на собесах "вкатунов", а они потом, не зная что делать с задачей, пытались пихать в ЧатГПТ весь проект, а тот начинал рандомно менять код в разных местах...
Можете привести пример и объяснить в чем бред?
Тут всё выше и ниже уже отлично сказали за меня. С таким кодом обращаться есть только один правильный путь - не делать так самому и выпрямлять извилины тем, кто так делает
А сможет "волчара" в лайвкодинг, без опыта? В ревью чужого кода?
Это что-то сложное?
В глубокие вопросы - что происходит в этом участке кода, как он работает...?
Берёшь и проверяешь, пишешь тесты, отлаживаешь
готовиться к собеседованиям
Почему мы вообще должны к ним готовиться? Для чего сделали вот это всё?
Вы серьезно думаете, что первый сможет справляться с производственными задачами так же, как второй
Канешн. У меня все друзья волчары. В IT вообще нет ничего сложного. Это прост перебирание бумажек, только с помощью языков программирования
Коллега! А как чувствует себя бизнес компании в которой вы занимаетесь ерундой? Или каждый провальный собес своими приколами вы оплачиваете из своей зарплаты и резвитесь за свой счет?
Ну что-ж, уважаемый автор. Проблема не столько в накрученном опыте, сколько в невозможности попасть на тех.собеседование если писать правду (по крайней мере на уровне джунов). Отсюда и результат..
И да, это плохо.. Но как говориться, не мы такие, жизнь такая..)))
Тема с джунами - это отдельный и сложный разговор. Тут речь больше про тех, кто заявляет себя мидлом или сеньором, но не может подтвердить базовые навыки.
Джунам никогда не было легко, это правда, но и требования к ним совсем другие: от джуна ожидают потенциал к развитию, а не готовый опыт уровня middle/senior.
Из жизненного опыта гуманитария-юриста. Были люди, у которых процессуального стажа, больше чем у меня в 2 раза. И при этом я, будучи их начальником, объяснял им базовые вещи (их люди в первый год изучают). Хотя эти юристы позиционировали себя знатоками права.
Так что тут и обман и безумная вера в свои знания. Так сказать 50\50
Очень странно, что ошибаются в таких задачах.
55 == True is True
Что вернёт выражение?
Года, наверное, с 2008 (с перерывами) что-то писал на Питоне, и понятия не имею, что вернёт выражение, потому что за все эти годы ни разу не пришло в голову написать подобный бред. И такое, на мой взгляд, можно сказать про едва ли не любой вопрос из приведённых автором. 55 == True, потому что if 55: print("yes") >> yes? Или 55 != True, потому что int(True) == 1? Каков приоритет операторов == и is, и нужен ли он тут вообще? Да хз на все эти оба вопроса испанской инквизиции.
Потому что list — изменяемый тип данных.
Нет, потому что кто-то альтернативно ментально одарённый придумал mutable defaults.
Если вы не сталкивались с таким кодом — значит, вы не читали код.
И слава тебе, Господи, что не пришлось ни разу читать такой код. Более того, не очень представляю, кто бы такой код мог написать: для новичка это слишком умно, а для графа де ла Фер это слишком глупо.
Эта задача даже не про знание синтаксиса. (...) Если вы смотрите на {x for x in range(3)} и говорите «это словарь» — вы не писали comprehension вообще.
Это задача исключительно про базовую внимательность: заметил кандидат отсутствие двоеточий или только фигурные скобки, и т. п.
Ладно хоть квантовую физику не спрашиваете. База все таки для всего.
Кой толк от таких "олимпиадных" задачек с подвохом, если на практике человек с этим не столкнется? Как с ЕГЭ учимся решать ЕГЭ?
Статья прекрасная, мотивирует.
Но кто виноват, если иеалбная работа это говно и палки, а в требованиях чего только нет и если в резюме не царсеие палаты то его даже не рассмотрят. Я сам писал требования с списком своих опытов, и что? Приняли обычного программиста, и всё нормально. Пишите или читайте резюме адекватно, иначе будете получать кандидатов в блестяшках.
Благодарю за ваш комментарий! Тема с компаниями и их неадекватными требованиями это отдельная боль, писал про это в другой статье https://habr.com/ru/articles/886552/
Нда, я не спец в питоне, но ваши примеры - это какой то сплошной, вы меня извините, говнокод, и ищите вы специалиста, который в сортах этого говна разбирается). Ни один из примеров просто не должен существовать в реальном проекте.
Причина такой тенденции в том, что сейчас ситуация такая в ИТ, при которой джуны никому не нужны. Пример из реальной жизни: изучала основы и разные инструменты в ИТ 3 года, прошла стажировку, начала рассылать своё резюме на джунские позиции. Итог: отказ или игнор. Как мне сообщили знакомые hr, моё резюме скорее всего летело в общую скажем так "свалку" к другим резюме таких же никому не нужных джунов. Я не призываю к вранью. Но когда работодатели начнут лучше нанимать и учить джунов (а не за сеньерами охотиться), поменьше фильтров незаконных использовать, тогда возможно преукрашивать станут меньше. И да, я изменила своё резюме, добавив опыта (внимание, без изменения стека!) и, вот "чудо", мне сразу стали рекрутеры сами писать. И нет, я не воспользовалась этой возможностью, т.к. профессионально врать не умею и меня разоблачить проще простого. Но я однозначно разочаровалась в ИТ-работодателях и этих отборах. Поэтому могу с уверенностью сказать, что в данной ситуации в ИТ уж точно не кандидаты виноваты. Ну а я поставила себе цель, честно идти по тому пути, который однажды осознанно выбрала. Но мой совет работодателям и тем, кто проводит собеседования, начните с себя и может однажды вы сможете поставить себя на место такого человека и понять, что именно толкает кандидатов к таким поступкам. Ведь кто как не вы знаете, какая сейчас далеко непростая ситуация в данной сфере.
Благодарю за ваш комментарий!
Джунам всегда было сложно, это вечная тема для обсуждений. И неадекватные требования работодателей также отдельная боль, писал про это в другой статье https://habr.com/ru/articles/886552/
представляете какую атмосферу создаст такой эксперт как автор в трудовом коллективе, какой волшебный вайбик там будет? а если их там будет несколько, они вам напишут чудо код со всеми этими ромбическими наследованиями, цепочным сравнением и прочей эзотерикой!
Вы сильно гиперболизируете и многое додумываете :)
Откуда вы знаете, какой код я пишу и какая атмосфера в команде? В статье речь не про стиль написания кода в продакшене, а про базовые знания языка и умение их применять
По статье и впрямь было не до конца понятно, но после тонны однотипных ответов сомнений не осталось)
Сейчас LLM очень бодро говнокодит на питоне, так что можно не вникать
Имхо нужно вернуться к старым добрым тестовым задачам, максимально приближеным к реальным, а не вот этот весь жабогадюкинг.
Я полностью согласен, что текущее положение рынка (сейчас я больше говорю про рф, тк за иностранные рынки говорить не могу) ужасно, и применяемые с обоих сторон методы и инструменты просто заставляют обе стороны применять все более ужасные подходы.
Но в вашем примере накрутка опыта проверяется говнокодом, который программист проверяемого вами уровня (а в статье мидл и синьор) не должны пользоваться вообще. За такой код на ревью вся команда должна надавать по шапке, а лид задуматься, как такой человек появился в команде.
А главное - сама статья про то, какие кандидаты плохие, но в статье сменили 2х-3х часовой тех собес с дрочем окололиткодовских задач на дрочь вокруг дерьмовейших конструкций.
В моих глазах собеседник, увидев такие вопросы должен сказать - это говнокод, его нужно переписать по бизнес-логике. Восстанавливать по говнокоду логику - действительно возможная задача на работе, но если у вас везде применяются такие конструкции - счастье кандидата, что он к вам не пройдет
Кажется, вы сильно гиперболизируете и додумываете за автора :) Это не код из продакшена и не образец стиля - это проверка базовых конструкций языка, которые встречаются практически в любом учебнике по Python. И да, хорошая практика - уметь объяснить, что делает даже "плохой" код. Потому что в реальности на ревью или при поддержке legacy приходится разбираться и с более жёсткими примерами. А потом их переписывать, на что-то нормальное
Я конечно не питонист но помню как 10 лет назад заучивал ответы на такие-же тупые вопросы вида "что вернёт 55 == True is True"
Почему это тупой вопрос? Да потому что это не настоящий проектный код. Кто в здравом смысле вообще будет число со True сравнивать?
Ошибиться тут легко - вспоминаем что в C (или js, черт их там разберёт) - любое число отличное от 0 - считается true и всё. 55 == True -> True, True is True -> true.
Не нужно это учить. И конечно такой код никто не пишет. Но вы обязаны знать синтаксис и сематику языка на котором работаете. И если вы их знаете, то и знаете ответы на эти вопросы.
Синтаксис языка или семантика опрелеляет будет ли 55 == True? Нет, это отдельное правило преобразования number -> boolean. Я мог прочитать его 10 лет назад когда учил основы языка, и с тех пор забыть 10 раз, потому что в здравом уме никто так делать не будет.
Это из разряда в java
Integer a = 100; Integer b = 100;
System.out.println(a == b); // true (значение в кэшированном диапазоне)
Integer c = 200; Integer d = 200;
System.out.println(c == d); // false (значение вне кэшированного диапазона)
Адекватные люди не запоминают эти правила так, они запоминают их как - "сравнение Boxed версий скалярных типов по == сломано" и "не используй boxed типы за пределами generic" (а там этой проблемы не будет), видишь что его используют - сделай нормально. И при разборе бага в коде - первое что делают - переписывают сравнение на нормальное и тестируют воспроизводиомсть.
И это вообще не показатель опыта - а супер частный случай который можно только заучить и нельзя понять интуитивно.
Ваш подход, честно говоря, оставляет желать лучшего :) Это как заучивать ответы к каждому квадратному уравнению, вместо того чтобы понять, как они решаются.
Смысл таких вопросов не в том, чтобы встречать их "в боевом коде", а в том, чтобы проверить понимание механики языка - чтобы в реальной работе человек не делал неожиданных ошибок из‑за неверных предположений.
Давайте - расскажите мне, какая формула механик языка позволит понять во что преобразуется объект со значением null при автоматической конверсии в строку (например Obj(null) + " test").
Варианты ответа -
"", "null", "Null", "NULL", null pointer exception , "Obj(null)"
Логически мне цепочку выводов постройте пожалуйста. (вида - я 20 лет не видел таких выражений, но исходя из того, что в языке все конверсии происходят... )
И вам повезет, если в вашем языке NULL - это отедльный singletone object, тогда хоть как-то обоснование можно будет притащить.
Вариант - "создатели языка решили что в 'null'" меня не устроит и "в документации языка так написано" тоже - с такими ответами вы как честный самурай должны сразу уволиться с работы. Потому что по вашему же мнению тут есть какие-то механики которые можно не заучить, а понять эмперерически не обладая этим знанием в заученном виде.
Про 55 == True is True аналогично - почему bool(55) == 0 ? а потому что создатели языка так решили. Могли бы решить что True = 0, а False = 1 - и нет причин почему так не может быть (в unix код выхода 0 - это успех, а код 1 - ошибка).
В "C" - создатели решили что bool(55) == 1.
В js создатели языка вообще решили что если a = 10, a != true, a != false.
Единственный способ ответить на такие вопросы - заучить. А если пишешь на языке больше 5 лет, то такая ерунда из головы улетучивается, потому что не встречается никогда, а когда встречается - то смотришь на неё, говоришь - какая-то херня, надо проверить че тут вообще будет, а потом переписываешь по нормальному.
Такой код может написать джун энергичный с горящими глазами. Узнал новую фишку языка - и написал, потому что красиво и новое. Это естественная часть роста навыка.
А другим это ревьювить. И, если пропустят через ревью не изменив, поддерживать.
Увидев такой код - хорошему программисту потребуется 5 секнуд чтобы понять, что он недаекватный и еще 10 чтобы загуглить как оно работает и исправить, еще 5 на то, чтобы сходить выдать наставление написавшему.
Но этот хороший программист не будет работать в компании человека, который написал статью, ведь на собеседовании - он скажет - "да хрен знает как оно работает, не помню я к чему автоматически приводится 55, к true или false - но это явно надо исправить т.к. не очевидно" и его не возьмут т.к. "не знает базовых механик языка"
Боромиру бы потребовалос 2 секунды. Сыну маминой подруги 3.
Удобно использовать таких прекрасных образцы идеалов, которые знать не знают, но сразу найдут, да и всё равно работать будут в другом месте и не столкнутся с не очень красивым, не очень удобным, не по стандарту кодом ни на ревью, ни в легаси базе, ни сами не наваяют.
Жаль, что в их компаниях работать не получается, всё более в тех, где то и дело почему-то пролезает странное, и надо понимать что это и идти объяснять почему так не надо. Или оставлять, если в конкретных условиях годится, например, в Proof of Concept. Или сразу планировать под замену.
Почему у этой великолепной статьи так много минусов? Это же квинтэссенция нынешнего программирования!
Я начал программировать в нулевые, и вначале выучил синтаксив нужных языков, прочёл их спецификации, прорешал кучу примеров. Потом написал много небольших программ. И лишь затем пошёл искать работу. И во время интервью мне порой говорили, что я знаю языки лучше, чем они.
Сейчас "программисты" вначале ищут работу, а потом уже начинают учить фреймворки. Языки же вообще не учат.
Присоединяюсь. Причём многие комментаторы пишут, что кандидат вообще не обязан это знать или ему это не нужно. Другими словами, человек пишет в резюме "N лет опыта на Python" и при этом не обязан знать синтаксис языка, его базовые конструкции. Занавес.
А минусы - видимо, большей частью от тех, кто пишет статьи в духе "Как быстро вкатиться в айти" или "Как я устроился на первую работу в айти на з/п 300к", со скрытыми намёками на накрутку опыта и рекламой телеграм-канала в конце. И такие статьи часто оказываются заплюсованными.
Здорово, что автор этой статьи поясняет, что нечестные кандидаты с приписанным опытом довольно легко выявляются на собеседованиях (если проводить их правильно). И даже показывает, как именно. По моему скромному опыту, один из самых эффективных способов - лайвкодинг. Попросить человека на собеседовании накидать в онлайн-блокноте несколько функций, классов, решающих какую-то задачу.
Проблема в том, что такие вопросы отсекут даже людей с реальным опытом, потому что задачи из статьи не практико-ориентированные. Но есть подозрение, что автор статьи сам бы с практическими вопросами не справился, поэтому вместо них осознанно решил привести концептуально более простые вопросы, спрятав их за ширмой некой "базы", чтобы хоть как-то заслонить себя от критики.
У вас отличное воображение, особенно про "автор сам бы не справился" :)
Вопросы из статьи - это не "ширма", а реально базовые вещи, с которыми сталкивается любой, кто пишет на Python дольше пары недель. Да, они концептуальные, а не практико-ориентированные в стиле "напиши API за 5 минут", но цель статьи как раз показать разрыв между заявленным опытом и знанием основ.
Вы сейчас просто в десятый раз повторили то, что уже писали раньше. Зачем? Вы думаете, что тут YouTube, и любые комментарии подымают "engagement"?
Я думаю потому что автор демонически выдержан и делает все возможное для поддержания реально вежливой дискуссии. Не ведется на дешевые провокации с переходом на личности и киданием какашек типа "а сам то, а сам".
Вам кажется. Обвинения других в токсичности, когда он сам же снисходительно смотрит на других (то есть банальное лицемерие), постоянный уход от темы, неспособность признать свою неправоту и повторение одних и тех слов - это упёртость, а не выдержанность. И я думаю, что оно вполне намеренное. Моё сравнение с YouTube взято не с потолка.
Автор, по-моему, ChatGPT (несмотря на то, что он где-то тут утверждал обратное) - кто ещё напишет столько комментариев, начинающихся с "Спасибо за конструктивный комментарий!"
Они отсекут людей, у которых опыт не имеет основания в систематическом изучении языка. Опыт это вообще штука хорошая, но количество в качество переходит медленно. Тем более это актуально сейчас, когда куча кода создаётся ИИ и даже иногда работает, но ИИ не влом писать головоломные конструкции, а рано или поздно разбираться с этим придётся человеку.
Не совсем. Вы можете "систематически изучать" язык, и при этом пропустить моменты, приведённые в статье. Это абсолютно нормально, особенно для вещей вроде множественного наследования, за которое автор так рьяно цепляется.
Автор сам говорит, что незнание этих вещей - признак нарисованного опыта. Но он никак не способен это логически обосновать. Потому что это просто не так.
Я могу провести параллель с C++, где даже сам автор языка говорит, что вам не нужно знать его полностью, чтобы успешно использовать. С питоном ситуация такая же, незнание каких-то элементов не отменяет ваш опыт его использования. А автор статьи с этим спорит, но без аргументов, на одних эмоциях (в которых потом обвиняет комментаторов).
Сколько-то лет назад (давно), я помню, как это нынче говорят, "вирусился" в соответствующих узких кругах пост в блоге АлёнаC++, что ли, тоже начинающийся с чего-то вроде 55 == True is True, только ещё ядрёнее и на C++ - забыл, несколько операторов разрушающего присваивания, что ли, наколбашены в одном выражении, и типа чо будет-то? И далее длинная статья про какие-то "точки [чего-то]" в компиляторах C++, про которые если знать, то всё ясно, в том числе и ответ на вопрос "чо будет-то?" Я даже дочитал. Забыл давно всё, включая названия. Вот что надо спрашивать на собеседованиях - точно никто не ответит, кроме считанных единиц высокофункциональных аутистов.
Пример 55 == True is True затрагивает сразу несколько концепций питона. Другие его примеры тоже очень познавательные, так как минимум для меня обратили внимание, в краткой форме, на множество неизвестного мне материала. А глядя на комментарии, где чётко и ясно видно незнание языка комментаторами, и воинствующее стремление и дальше не знать (чего стоит например нежелание нажать на ссылку рядом с этим примером и убедиться что автор прав) убеждает меня что автор всё правильно делает.
А чего стоят многочисленные вопросы где работает Автор - хотя узнать это занимает несколько минут.
Относительно С++ - Стракструп написал даже больше, он написал что сам не знает весь язык. Ну так Автор действительно не лезет в дебри, нет там никаких сокрытых знаний. Просто есть метод изучения языка по примерам в программах, и есть метод по систематическому изучению. Первый вариант даёт 90% (или любое другое число) знаний языка пригодное для практических целей, и не даёт вообще понимания об устройстве и ограничениях языка. Где то первого достаточно.
Посмотрите - комментарии с явными и проверяемыми ошибками плюсуются. Кем они могут плюсоваться?
А потом ruff начинает на два порядка обгонять питоновский аналог.
То, что вопросы "познавательные", никто не спорит. Но ещё раз, автор статьи говорит, что этими вопросами можно "вскрыть накрученный опыт" (это прямо сейчас написано в закреплённом комментарии автора к этой статье). То есть если вы не можете на это ответить, значит ваш опыт ненастоящий. Спорят именно с этим. Это основной посыл статьи по словам автора. Вопросы именно к этому утверждению. Не к их познавательности, не к тому, что ответы на вопросы есть в документации. А к выводу.
Но вы посмотрите как спорят. Есть утверждение, есть рядом с ним ссылка для проверки истинности. Кто то на неё из спорщиков нажал? Нет, но сколько высказываний что автор облажался. Практическое программирование приучает постоянно проверять себя, почему этот навык тут не сработал, как вы думаете?
Про накрутки тут и у меня и у автора и у части комментариев есть консенсус - они возникают не от хорошего положения в индустрии. Но как то же надо делать отсев. Давать тестовые задания? Так этот метод не критиковал только ленивый, доходит до выполнения за деньги. Оченьо может быть что в финансовых проектах и нужно хорошее знание именно основ (хотя я не знаю зачем там вообще питон), это уже вопрос к автору.
Но вы посмотрите как спорят
Неважно, как спорят. Суть статьи не в этом, я это уже написал. Вы пишите при один кейс, а я про общую картину. Статья стоит на неверном базисе (или фундаменте, это слово очень любит автор). И я считаю это более важным, чем обсуждение корректности конкретных кейсов.
они возникают не от хорошего положения в индустрии
Опять же, статья не про это. Автор пытается порассуждать в конце статьи, но быстро скатывается в открытые оскорбления.
Но как то же надо делать отсев
Не так, как предлагает автор в этой статье.
Вот именно, обсуждение скатилось к обсуждению личности автора А вопрос знаний потерялся.
Вопрос о том как проводить тестирование ответа наверно не имеет, но уровень дискуссии показателен. Общий посыл - "я этого не знаю значит и знать не надо".
Вы пытаетесь мне вменить в вину за действия других? Я личность автора не обсуждал, только его материал в этой конкретной статье. Автор же прямо в тексте статьи позволил себе гораздо больше.
"Вопрос знаний" автором вообще не ставился. Я его цитату выше привёл. Додумывать про посыл ничего не надо, всё в явном виде сказано.
Вы пытаетесь мне вменить в вину за действия других?
Где и чем я это делаю?
Пишете мне фразу "обсуждение скатилось к обсуждению личности автора". Когда я несколько раз написал, что мне не важно обсуждение автора и обсуждение корректности отдельных кейсов из статьи. А только посыл статьи, который я процитировал, и ничего больше. Но вы продолжаете каждый раз обратно переключаться на обсуждение из другой ветки, в которой я вообще не участвовал.
Проблема в том, что такие вопросы отсекут даже людей с реальным опытом, потому что задачи из статьи не практико-ориентированные.
Это вопросы про то, чего нельзя не знать. Это как пытаться быть инженером, не зная таблицы умножения! Ну зачем? Компьютер же сам всё решит! И если у вас при перемножении трехзначных чисел получилось девятизначное число -- ну значит так и нужно!
Как можно отсечь хороших инженеров требованием к знанию их инструментов? Ещё раз: если вы знаете язык, вы решите любые примеры. Это как умение умножать числа: вы же можете умножить любые числа, а не только примеры из учебников?
Реальность не совсем такая, какой вы её описываете. Можно "знать язык", успешно решать на нём различные задачи, и при этом завалиться на каком-либо gotcha-моменте. Я уже привёл пример про множественное наследование (несколько раз) - вы можете написать кучу кода на питоне, но не знать порядок наследования. Просто потому, что этим самым множественным наследованием вы никогда не пользовались. Можно ли, исходя из этого, утверждать, что вы не "знаете язык"? Конечно можно, кто ж вам запретит...
Поэтому утверждать, что это прямо "то, чего нельзя не знать", как минимум наивно. Не знать можно много чего. Аналогично с "знаете язык -> решите любые проблемы". Это тоже не совсем так работает. Знание не равно навыку решения проблем.
Посыл статьи, что такими вопросами можно отсечь людей с нарисованным опытом. Но я уже в другом комментарии написал, что никакой логической цепочки рассуждений этому утверждению не предоставлено. Вообще никаких рассуждений нет, просто голословные "это база и точка!"
Забавно меня упрекать после этого комментария в "неконструктивном общении" (что сделал кто-то в другом месте, подозреваю, что автор комментария или статьи, склоняюсь ко второму), когда в самом комментарии, на который я отвечал, не было ни одного "конструктивного" утверждения, только пустые аналогии про умножение, не несущие смысла в контексте статьи, и повторение фраз "это база/это нельзя не знать". Лицемерие в чистом виде.
Согласен, ваш комментарий действительно по делу!
Минусы в основном от людей, которых такие вопросы на собеседованиях когда-то ставили в тупик, и сейчас они воспринимают это как личное нападение. Многие просто привыкли к собесам "за жизнь" и очень не любят проверки базовых знаний.
Я не минусил, но, увидев такие вопросы на собесе, задал бы встречный вопрос: у вас такое в коде? И, напротив, собеседуя кого-то – больше порадовался бы не пониманию смысла этого, а воплю "какой ... это написал?"
Ну и, соответственно, на этом этапе примеры на собесе можно отдать под рефакторинг: типа, не нравится? А как бы вы написали? Тут и понимание закоулков языка проверите (хотя оно и не столь критично), и умение писать читаемый код.
А вот совсем беда – если человек такие фрагменты кода просто не заметит. Особенно если он их поймёт неправильно (но и если правильно – тоже не супер).
А вы на лайвкодинге например требуете от кандидата знание наизусть названий методов? Просто именно на это походит часть (по крайне мере пара примеров) из статьи, из за которых у меня к ней большие вопросы.
Я вот вспоминая свои секции лайвкодинга - помню свои фразы из разряда - "тут length, или size или count - не помню как там метод называется, они в разных коллекциях по разному" и "тут метод обеспечивающий свертку математическую свертку, не помню, reduce скорее всего, или там он в kotlin fold с initalValue называется", "там callback на это дело есть специальный, onЧет-то там, onRetainObject или типо того"
сам собеседований не проводил, фраза "по скромному опыту" относилась к прохождению собеседований. После одного из собеседований на позицию мидла, где был лайвкодинг, девушка HR, давая обратную связь, написала что выбрали другого кандидата, но похвалила за хороший уровень (при этом сам я считал, что прошёл собес далеко не лучшим образом) и сказала что другие кандидаты (большинство) вообще беспомощны и ничего не могут, "после курсов".
Я проводил собесдеования и не мало.
Кандидаты после курсов выявлюятся дейсвтительно очень просто - они хорошо знают ответы на общие вопросы (наизусть), но не могут развить диалог на их тему. Например человек рассказывает идеально и в подробность про то, как устроена hashMap - но одновременно не способен ни рассказать зачем она так устроена, ни как сделать, чтобы её производительность выродилась в связный список, ни что будет для null ключа и зачастую даже что такое хэш. Более того - такие вопросы их ставят в ступор. Разработчик с опытом который не знает ответа - может по рассуждать, и построить предположения - пусть даже не верные, но логику рассуждений и понимание темы сразу видно будет.
Претензии именно к вопросам из статьи - которые рассуждениям не поддаются, требуют однозначного ответа, и этот ответ может быть только заученым.
При этом считаю, что человек, который пишет на языке несколько лет, даже в условиях стресса на собеседовании, даже на автомате, способен писать более-менее адекватный код. Это должно быть просто на кончиках пальцев. И собеседующий это сразу увидит.
Да, можно что-то забыть от волнения, но нельзя забыть все. К тому же подготовку к собеседованиям никто не отменял - она подразумевается по умолчанию. А у человека без опыта (выдающего себя за мидла), который тоже разумеется, готовится к собеседованиям, может быть в голове куча теории, но нет практики. И на лайвкодинге у него, скорее всего, будет просто ступор или что-то невразумительное.
Еще один эффективный метод - попросить кандидата на собеседовании провести ревью кода, содержащего неявные ошибки и "грязный код". Задать вопросы поглубже - что происходит в отдельных частях кода, как они работают. И опять же, будет сразу видно, есть ли у человека опыт и понимание, или он просто плавает и беспомощно барахтается в таких вопросах, выходящих за рамки.
Никогда в жизни не готовился к собеседованиям, считаю это вообще вредной практикой. Какой смысл готовится? Перед работой тоже каждый день готовимся? (Практически все собеседования проходил успешно С++)
По ревью кстати совет суперский, сам так собеседования всегда проводил, позволяет увидеть чёткую градацию уровня знаний.
При этом считаю, что человек, который пишет на языке несколько лет, даже в условиях стресса на собеседовании, даже на автомате, способен писать более-менее адекватный код. Это должно быть просто на кончиках пальцев. И собеседующий это сразу увидит.
К сожалению, нет. У меня 17 лет непрерывного опыта разработки, я пишу код почти каждый день, но на собеседованиях у меня наступает абсолютный ступор. Буквально полгода назад искал работу, на собесе попросили развернуть связный список, а я вместо этого схватил паническую атаку. Причем, что интересно, когда вопросы дают из практики, у меня как-то достаточно легко получается, но как только дают всякое говно с олимпиад - все, амба, приехали. Никакая подготовка не помогает, я до этого месяц на литкоде сидел как дурак. И, как оказалось, я такой очень сильно не один.
Спасибо за конструктивный комментарий!
Вы абсолютно правы - раньше многие шли в профессию именно через понимание языка и постепенное накопление опыта.
Сейчас часто встречается обратный подход: "хочу сразу работать и получать высокий доход", а разбираться в фундаментальных вещах начинают уже "по ходу". При этом никто не против фреймворков или готовых решений, но важно иметь базу - это снижает количество ошибок и делает работу быстрее и надежнее.
Ну так "рынок порешал". За что боролись - на то и напоролись. Бизнес сам платит тем, кто делает быстрее, а не надежнее. Фреймворков, инструментов - куча, а порой тот или иной инструмент нужен эпизодически, так что смысла нет - глубоко копаться в нём.
Конечно база Сеньору нужна - языковая, сети, реляционные БД, но часто возникает и диаметрально противоположная ситуация: ты приходишь такой весь прошареный в базе, на которую потратил много времени, а тебе говорят: а как делается вот такая вот элементарная штука в фреймворке Х? А ты с ним не работал; и опа - ты негоден : )
Короче говоря, при том, что я не считаю озвученные вопросы в статье чем-то невменяемым, вместе с тем - это больше похоже не ретроградство и почти пИсанье против ветра. Почти - потому что всё-таки - да, Сеньор-то уж должен был до базы и через практику уже добраться.
Каждого, кто говорит, что он-де выучил синтаксис нужных языков, прочёл их спецификации, я спрашиваю, познакомился ли он целиком с стандартом HTML (1510 страниц), прежде чем написал первую веб-страницу для своих нужд? Ни одного такого не встречал. Ну может, сейчас, когда он где-нибудь использует теги, он уже познакомился со стандартом и точно знает, какие браузеры как обработают разметку? Нет, таких тоже не встречал.
Я таки скромно предположу, что если человек работал и успешно решал задачи без знания этой "базы", то значимость знаний "базы" сильно преувеличена.
С моим сишным background 55 == True истинно, другой вопрос - вы реально вот так вот пишете: 55 == True is True? Зачем, разрешите полюбопытствовать? Код должен быть читаем, он не должен быть ребусом. Примеры очень надуманные и высосанные из пальца, неудивительно, что кто-то смутился и накосячил.
пояснить за
Скажите, а правильно ботать по-фене - это тоже входит в задаваемые на собеседовании вопросы? Про два стула спрашиваете? Как правильно войти в хату коворкинг?
Было 1,5 года — стало 3
Когда уж вы наконец поймёте, что опыт опыту рознь, и тот факт, что некий кандидат честно просидел N лет за столом в компании А на определённой должности, в реальности слабо корреллирует с его знаниями и навыками.
Автор зануда и сноб, боже меня упаси работать с таким. Сами посмотрите, сколько минусов ему накидали. Я таких наелся и с возрастом они ещё хуже становятся, всех окружающих учат жизни
Если в резюме указано, что человек работает в профессии уже восемь лет, а на собеседовании путается в логических операторах, это, мягко говоря, вызывает вопросы
Вот это - реально жесть, а не всякие там куски говнокода на проверку.
ООП какой то странный у Питон. Совсем не знаю Питон. Но я бы на интуитивном уровне смотря на синтаксис ответ дал ABAC
и эта конструкция смутила не ООП синтаксис у нееprint((x for x in range(3)))
на остальные вопросы ответил верно.
Эти вопросы подходят для оценки рассуждений, но ожидать правильных ответов на все - точно не стоит. Ответы будут знать только те, кто специально заучивал разные вопросы с собесов, в то время как реальные сениоры могут и за 100 лет с некоторыми из особенностей питона не столкнуться. Потому, что большинство этих вопросов - это именно особенности, а не "база".
Вот ещё пример такого вопроса, который может сбить с толку сениоров:
Чем различаются два примера кода и что будет выводить функция:
a = 1
def f(b):
if b:
a = 2
else:
global a
print(a)a = 1
def f(b):
if b:
global a
else:
a = 2
print(a)Очевидный ответ про обратное условие - неправильный.
Скрытый текст
В первом случае, будет SyntaxError и функция не создастся.
Во втором примере функция будет выводить 1, пока b истинно, но после первого же вызова с ложным значением b функция начнёт выводить 2, независимо от значения b.
Скрытый текст
global выглядит как часть кода функции, но на самом деле обрабатывается парсером, а не исполняется при вызове функции. Но кому это вообще нужно постоянно помнить?
Автор упорно не может понять, что ему пытаются донести. Попробую с другой стороны:
Приоритетность операций - это база? База. is имеет больший приоритет чем ==? Стоп. Уже здесь проблема. Как часто в коде возникает необходимость знать приоритет is, учитывая, что синьоры обычно, как минимум, имеют представление, а то и програмят на иных языках? А в тех языках is нету в принципе. Поэтому, когда на ревью я вижу код a == b is True, я сначала пишу "не интуитивно, поставь скобки", а потом через пару секунд когда вьехал "блин, удали нафик эту чуш".
Когда прогаешь мильон лет, то все конструкции у тебя считываются за доли секунды, а когда ты спотыкаешься об 55 == True is True - уверен многие ответили неправильно, потому что мозг не хочет тратить время на анализ этого бреда. И это подсознательно. Потому что жизнь сейчас такая быстрая. А вы записали всех в неумеек
языку программирования у которого 55 == True это false место только в аду.
простите за несдержанность.
А как надо-то? Чтобы 55 == True было true? Чтобы ошибка приведения типов? Или чтобы что чтобы как где?
Вообще, это логично. Если программист проверяет (a == b) and (b == c), то логично предположить, что все три значения равны. А приравнивание чисел к true нарушает эту логику. При этом значение 55 остаётся истинным. if 55: будет выполняться всегда, как и if True:, т.к. bool(55) == True
Такой логике следуют и Python, и JS. А вот PHP с его приравниванием всего подряд является скорее исключением.
вот типизированный си шарп, если от этого вам легче станет))var res = 55 == (true is false ? 1 : 0);
Дайте угадаю у вас текучка кадров и отставание по срокам выполнения проекта?
Смысл спрашивать примеры,которые никогда не пройдут ревью. Или такое у вас в репе лежит и радует глаз "сложными конструкциями". Тем более на сеньерскую позицию. Вам компилятор нужен ?) в принципе самоутвердиться за счёт собеседуемого легко, он в нервозном состоянии, но делать это как минимум глупо, задача ведь не в этом.
А насчёт сроков и текучки сталкивался с такими.. компания начиналась с м и заканчивалась на биржа, там один тимлид , назовем его Филип , устраивал митинги чтобы договориться сколько нужно писать пробелов в табе(при включенной одинаковой настройке на команду) , нужны ли комментарии в тестах, какая максимальная длинна лямбда функции(при наличии корпоративного литера) и ТП, при просрочке проекта где-то на 8 месяцев и постоянной текучки из-за карательного ревью и "тянем друзей" в проекте
Всем советчикам про собеседования в их контору советую сходить на десяток собеседований в разные компании и лично выяснить чего стоят их советы.
А после того как удивление уляжется сделать дополнение к своей статье с советами.
Автор упорно не может понять, что ему пытаются донести.
Автор за деревьями спрятал лес
Советы новичкам
Если вы, уважаемый читатель, только начинаете свой путь в индустрии, искренне рекомендую формировать опыт честно и последовательно, без приписок чужих заслуг. На самом деле, это проще, чем может показаться. Куда разумнее — сделать 5–10 собственных пет-проектов, пройти действительно качественные курсы, прочитать статьи, попробовать технологии на практике, потратить на всё это несколько месяцев, а может, и полгода — но зато погрузиться в тему по-настоящему.
"Мы не можем отфильтровать нарисованный опыт, поэтому не поступайте так! Поступайте так, как удобно нам, а не вам!"
Действительно, если бы описанные "питоновые шарады" позволяли бы отфильтровать самозванцев то и статьи бы не было
Возможно, людей триггерят даже не сами примеры, а то высокомерие, с которым вы преподносите результат ("все кругом глупые стали, а я вот один умный. ну может ещё парочка есть не таких тупых"). В целом примеры норм - никаких сложностей у опытного программиста вызвать не должны. Но всегда можно "запариться", перенервничать на собеседовании. Делать такие глубокие выводы, опираясь только на подобные примеры, неправильно.
Очень интересно а как соотносятся все эти требования автора с состоянием рынка.
Насколько долго бизнес готов простаивать в бесплодных собесах, вместо того, чтобы перестраивать свои процессы и адоптироваться к доступной рабочей силе, даже если она не блещет желаемой квалификацией?
Есть ли какое-то оптимальное решение у задачи о разборчивой невесте, если количество претендентов n неизвестно заранее, но точно очень велико?
Насколько долго бизнес готов простаивать в бесплодных собесах, вместо того, чтобы перестраивать свои процессы
Нет нужды: реальных вакансий очень мало
HR, которые сидят на работных сайтах получают деньги только за нанятых сотрудников. Поэтому они спамят якобы реальными вакансиями по ничего не имеющим под собой просьбам владельцев бизнесов, просто "на удачу". Получится кого-то пропихнуть на очередную галеру - отлично, нет - ну и ладно. Ведь написать письмо/опубликовать вакансию/отправить шаблонный ответ соискателю - это, в реальности, просто тыкнуть кнопку в роботизированной системе найма и не стоит почти ничего
У бизнеса сейчас другие проблемы. Например, к Шадаеву возник вопрос - как он допустил что "импортозамещённые" программы - в действительности форки - вдруг стали российскими и в реестрах. И бизнесу придётся как то помочь ему ответить.
Какие-то смешанные чувства от приводимых примеров.
Mutable default - отличный подвох, неоднократно подсвечивал его на кодревью, и пару раз чинил баги когда оно сквозь кодревью просачивалось.
Comprehensions - тоже понять можно, фича с подвохом, доводилось и этажерки сворачивать в однострочники, и наоборот, все во имя читаемости.
55, ==, is - чёрт его знает, я бы на собеседовании в качестве правильного ответа принимал "надо смотреть порядок операций" и "не знаю, страшно, разворот на кодревью и принудительная расстановка скобок".
Хэшируемость ключей в словарях - ну... у меня есть интерпретатор, линтеры, статические анализаторы и тесты; благодаря этому всему я уже сам не помню, какое именно условие накладывается на ключи и что там хэшируется по умолчанию, что нет, и где (не)работает транзитивность оного хэширования.
Ромбовидное наследование - офигеть, а в питоне это есть? Круто, надо бы запретить по возможности, в плюсах от этого сплошная головная боль была!
Не питон-разработчик, не автотестер, не девопс, просто последние лет 5 часто на нём пишу все подряд. Моя база по питону 100% будет отличаться от базы дата-сатанистов и веб-разработчиков.
Примеры норм, хотя я на первом тоже засомневался - такие конструкции у меня вызывают ступор : ) и негодование : ) Но вообще - автор не перешел всё же черты, за которой начинают требовать ответов на вопросы из разряда WTF Python приправленные еще и какими-то заведомо нишевыми и малоизвестными особенностями каких-то фреймворков, которые встречаются раз в тысячелетие : ) А переходят эту черту нередко.
Ситуация со знанием языков программирования и более общо - компуктер саенс - зачастую аховая, потому что много вайтишников, которые умеют более-менее сносно работать с каким-то конкретным инструментом, но за пределами его - толком ничего не знают. И это... зачастую приемлемая ситуация, ну по-крайней мере до миддловской позиции включительно. Ну а про грейдинг - известная история: в одной компании ты самый умный/опытный - Сеньор, а в другой - уже нет : )
Но в целом - я скорее согласен с автором статьи, что не ответить вменяемо на данные вопросы на уровне Сеньор - это фиаско, потому что это тащем-то действительно основы. Но замечу, что меня бы такие вопросы - насторожили, их и впрямь стоило бы вынести на уровень фильтра первичного собеса с HR, а когда ты приходишь на собес на позицию Сеньора и тебе начинает технический собеседник такие вопросы задавать - слегка теряешься и начинаешь думать: что всё это значит? : )
Пост хороший, рейтинг видимо посту слили как раз "вкатуны" и "волки", накручивающие себе опыт. Россказни о том, что якобы сеньор с 20-летним опытом может "просто не помнить" чему будет равно сравнение "55 == True" разве что для подъездных бабушек, это понятно даже не хватающему звезд с неба (но и не тупому) студенту 1 курса любого ИТ направления, у которого хотя бы пару месяцев как начался курс программирования (на любом языке)
Попробовал ответить на вопросы будучи TypeScript \ JavaScript разработчиком. Провалил всё или почти всё. Особенно удивило поведение default-ных значений в функции.
После прочтения статьи не могу сказать, чтобы у меня сложилось ощущение, что вы спрашиваете что-то прямо полезное.
Порядок выполнения сравнений. А так код пишут? Это идиоматичный python код или просто выпендрёж?
К чему это я? Вроде 15 лет пишу на JS/TS. Но порядок операций не знаю и заучивать не хочу. Если у меня есть сомнения - ставлю скобки. Prettier их потом сам уберёт если лишние были. Зачем мне вот этим голову забивать? Рискну предположить что в Python-е также.
Множественное наследование и порядок resolve-инга колизий имён. Оно вам вообще нужно? За множественное наследование в Python ногами не бьют?
К чему это я? Раньше на собеседованиях задавали каверзные вопросы по prototype-based наследованию в JS. А там есть где закопаться. Но уже тогда это был скорее мёртвый груз. Сейчас с массовым использованием
class-ов, познания в прототипах на практике нужны самые минимальные.
Словарь и мутабельный объект как ключ. Вроде и полезно знать. Но тут правильно отметили, что если такой код падает ещё до выполнения с внятной ошибкой, то такой пробел не выглядит чем-то прямо стрёмным.
И мега-опытный человек с 15 годами опыта, который переключился на Python пару лет назад просто не будет знать таких нюансов. Отбрить его из-за такой глупости...
Пример с генераторами. Ну примерно как и со словарём. Полезно знать, но ценность не высока. В JS тоже есть генераторы. Кому-то по долгу службы нужно работать с ними (а то и с асинхронной версией) каждый день. А кому-то никогда. От задач зависит. Генераторы штука в себе.
Пример с дефолтным значением аргумента в функции. Вот это пожалуй единственный серьёзный аргумент. Про такие подставы нужно знать.
Эпилог: при найме вы по сути отвечаете себе на простой вопрос - сий кандидат снимет с моих плеч больше головняка, чем добавит? Или нет? Если да, торгуемся по зарплате. Если нет - мы вам не перезвоним. И теперь вопрос - знание неких контринтуитивных нюансов языка, редко используемых на практике, это правда существенная часть вашего "головняка"? Или может вам остро нужен товарищ, который перекопает половину кодовой базы, исправляя ошибки архитектуры? Может лучше спросить что-то относящееся к тому, чем он будет заниматься в рабочее время?
Удачный пример вопроса по базе на примере Javascript:
const a = [{ a: 1 }, { a: 2 }];
const b = [...a];
a[1].a = 3;
console.log(b[1].a); // ?^ Это база? О да. Это используется на практике? Да каждый божий день. Если кандидат ответил не правильно и даже после подсказки не догоняет что не так, это нам о чём-то говорит? О да, это говорит, что он вообще не понимает что тут происходит и вероятно верит что [...a] копирует объект в глубину. А коль скоро он в это верит мы легко делаем вывод, что JavaScript человек знает на самом поверхностном уровне. А нам это в целом важно? Более чем. Не понимая таких вещей придётся в каждом пул-реквесте под микроскопом его код проверять. Проверено практикой.
И подобных вопросов можно задать много. Ну если хочется базу проверить.
За множественное наследование в Python ногами не бьют?
Например, mixin-ы - тоже частный случай множественного наследования. Плюсы-минусы, усложняют понимание(могут и уменьшать), уменьшают копипасту(но это неточно). Инструмент. В хорошем исполнении ромба давать не должны, но тут как всегда можно довести и до ужаса.
Вы абсолютно правы в том, что подавляющее большинство вопросов - не соответствуют практике программирования на Python. Но в то же время, если отвязаться от настойчивого желания дать по голове автору такого кода : ) и правильно подать, то эти вопросы таки затрагивают базовые вещи Python.
Первый вопрос не про порядок операций даже, а про приведение типов и то, что в Питоне не переменные, а ссылки на объекты и это порождает ряд особенностей.
Множественное наследование - уже по ответу можно понять, что это потенциальный и неиллюзорный способ выстрелить себе в ногу, вреда от этого множественного наследования больше, чем пользы, тем более, что есть масса других способов сделать то, что требуется, не делая множественного наследования. Но это-то и проверяется этим вопросом : )
Словарь и мутабельный объект как ключ - это тоже скорее вывод на тему хеширования и типов данных в Питоне, само по себе такому коду воспротивится даже интерпретатор, но не всегда... В общем, тут можно почесать языки про хеширование и мутабельность/немутабельность типов, и вот второе - это уже и впрямь база-база.
Пример с генераторами - тут не согласен, для Питона - это базовые и полезные идиомы, странно не знать.
Пример с дефолтным значением аргумента в функции - это совсем детская подстава, поэтому для Сеньора странно не знать, и так же выводит на особенности создания и линковки объектов в Питоне, ведь функция в Питоне - это тоже объект.
Короче говоря, вопросы реально элементарные и, возможно, раздражают скорее тем, что во-первых они как бы сразу ставят кандидата в позицию подозреваемого : ) во-вторых - в рабочем коде они почти все вызовут недоумение : ) Это, наверное, и создает ответную негативную реакцию как на пассивную агрессию со стороны собеседующего - а она вот точно есть: он свое разочарование в кандидатах проецирует без разбора на всех. Это своего рода неуважение без повода с порога - кому это понравится? : ) Я бы вот как минимум бы пометил у себя в голове - а это часом не контора обиженных на мир параноиков? : ) И в чём я был бы не прав? : )
Поэтому, автору - при всех благих намерениях и праведном гневе, стоило бы подумать в первую очередь над своим поведением : ) Тонны говна вылились тут на него в общем-то не просто так и не только от разных неумех. А говоря сухо и алаверды - софт скиллы-то автора статьи похрамывают, выходит?
Что то мало козырных питонячих плюх тут, нате еще одну, и да, бывает спрашивают на собеседованиях :)
def f():
try:
return 1
finally:
return 0Что вернет функция :)
Недавно читал programmers stone, про паковщиков и картостроителей. И автор статьи такого идеального паковщика мне и напоминает. В принципе, кому с кем лучше работать - тот тех и нанимает (а лучший способ найти паковщика - задать каверзный вопрос про нюансы языка), но такая активная (и не особо позитивная) реакция на его примеры вызывает предположение, что аудитория хабра - скорее картостроители, чем паковщики. И это логично. Хорошие программисты скорее картостроители.
Разница между первыми и вторыми в том, что паковщик оперирует набором знаний для решения задач. Чем больше его опыт - тем шире его знания. Он как словарь, который растёт с годами. Но столкнувшись с задачей, которой в словаре нет - он не знает, что ответить. Пытается выдумать ответ, вместо поиска решения.
Картостроитель же оперирует способностью эти знания добывать. Он может не знать (и чаще действительно не знает) синтаксиса языка, его особенностей и конструкций, но если он опытный - он достаточно быстро разберётся. И чем больше опыта, тем быстрее это случится. Но он будет сознательно избегать конструкций, логику которых нужно запоминать, а нюансы не очевидны. А если и столкнётся - быстро пометит их как вредные и забудет о них. Это сэкономит память для логики высшего порядка - архитектуры, лучших способов связать что-то воедино и т.д.
Кто на реальной работе полезнее? Вопрос открытый.
Я понял, что без знания 55 == True is True не возможно написать тесты на api.
И не надо знать теорию тестирования. Это же не так важно по сравнению с языком)))
Ремарка: Нет четкой постановки задачи, нет точной оценки.
Вы начали писать статью очень размыто указав как вы формировали запрос на рынок. Не понимая запроса оценить ваши рассуждения сложно. Текст вакансии это даже не ТЗ, а готовое коммерческое предложение, зная его можно сделать прогноз, кто к вам пойдет.
Предположим, что вы искали Seniora и ваша вакансия сформулирована адекватно, а компания белая и пушистая, при этом вы получили описываемые результат.
Это означает только одно - на ваше предложение специалистов нет. Из этого следует, что либо нужно менять предложение, либо закрывать позицию, либо растить собственных специалистов.
Что-то мне подсказывает, что автор впервые на должности, которая предполагает собеседования кандидатов, хотя могу конечно ошибаться. Сам был когда-то таким. Сейчас же могу сказать, что такие вопросы хороши если вы набираете джунов, для мидлов и сеньоров это уже совсем не, то о чем нужно спрашивать. Тем более, если этот человек будет тимлидом. Это примерно как у инженера начать спрашивать например таблицу умножения, попросить его решить какое-нибудь сложное тригонометрическое тождество или задачу по стереометрии, а когда он зафейлится начать рассказывать про базу. Нужно задавать задачи, которые ему действительно придется решать в процессе своей деятельности на данной должности. Например если он тимлид, то это в значительной степени управленческая должность и стоит убедиться как у него вообще с компетенциями связанными с управлением командой, умеет ли он в архитектуру и пр. высокоуровневые задачи, с которыми ему действительно придется сталкиваться. А такие вопросы оставляют впечатление, что вам явно не сеньор и не лид нужен, ну либо вы хотите просто "пошерстить рынок труда" и нанимать вообще никого не планируете. Ну это так, в порядке критики.
Когда читаю такие статьи или встречаю таких интервьюеров мне кажется, что дело собеседования специалистов все больше захватывают любители казуистики. С одной стороны я понимаю, сейчас всяких вкатунов и волков не мало и надо поставить фильтр. Но вот это адекватным фильтром тоже назвать нельзя. Я больше 10 лет в программировании, работал и на галерах и в стартапах, и над огромным энтерпрайзом и над небольшими проектами. Был и джуном и мидлом и синьором и лидом. И каждый раз перед поиском работы я имею одну и ту же зудящую проблему - надо садиться и повторять базу. Ту самую базу которая пригождается раз в год в реальной разработке и между поисками работы ты ее нафиг забываешь. Но интервьюер, который ее повторяет на регулярной основе конечно считает ее Граалем знаний в разработке. Давайте уже проводить крос-интервью чтобы понимать, что человек который тебя собеседует не забыл фундаментальные вещи в компьютер сеанс. Я обязательно вспомню работу с регистрами, big/little endian, обязательно поговорим про математику стоящую за rsa шифрованием. А что? Это вообще то база! Или кто-то тут на ежедневной основе гоняет запросы незащищённые?
Вас не удивил опус автора про 65К в месяц честные для разработчика?))
Учитель: Давай решим задачу про Машу и яблоки. - Маша нашла 5 яблок. 2 яблока она подарила Пете, одно яблоко она потеряла. Сколько яблок осталось у Маши?
Ученик: А где Маша? Может, нам пойти помочь ей искать яблоко?
Учитель: Нет-нет, Маши и Пети здесь нет, это просто задача. Давай посчитаем: сначала у Маши было 5 яблок.
Ученик: Но если она потеряла яблоко, может, оно под столом? Надо проверить!
Учитель: (спокойно) Это воображаемая ситуация. Давай представим, что у нас есть 5 яблок. (Берёт 5 счётных палочек или рисует 5 кружков.) Вот, смотри — 5 яблок.
Ученик: (рассматривает палочки) Ага...
Учитель: Маша отдала Пете 2 яблока. (Убирает 2 палочки.) Сколько осталось?
Ученик: 1, 2, 3... Три!
Учитель: Верно! А потом она потеряла ещё 1 яблоко. (Убирает ещё одну палочку.) Сколько теперь?
Ученик: Осталось 2!
Учитель: Правильно! Значит, у Маши осталось 2 яблока.
Ученик: А если мы найдём то, которое потеряли, будет 3?
Учитель: (с улыбкой) В реальной жизни — да, но в задаче мы считаем только то, что осталось у Маши. Молодец, что посчитал!
Бред и нонсенс. Автор начинает с накрутки, которую он затем приравнивает к отсутствию теоретических знаний. 1. Не думал ли автор например о том, что люди которые пришли к нему могли иметь опыт и тем не менее просто не столкнуться с нужной теорией? Да, это показатель безалаберного и поверхностного подхода к обучению и практике - и...давайте начистоту - подход этот распространен. 2. Не думал ли автор что люди которые ответили на все его вопросы могли быть накрутчиками опыта которые...ну...знали ответ ?
Далее - конечно, это наверное плохо что вот к вам пришел человек показал что он ничего не знает - и ушел в слезах. Но Вы сами не заметили, что он в целом сделал всё правильно - потому что сюрприз сюрприз - он попал на собеседование!
Для вас, это вероятно прозвучит как нонсенс, но 20 интервью в год где вы ушли в слезах...это значительно лучше чем ноль интервью в год потому что вас никуда не позвали так как вы не накрутили опыт.
Пока вас берут и проверяют на знания - вы можете хотя бы потенциально устроиться или извлечь пользу. Может требования завышенными окажутся, может вы сюрприз- сюрприз знаете достаточно!!!...а может вы ничего не знаете, но из вопросов узнаете что нужно эйчаре (причем давайте будем честны, не компании, а именно эйчаре). Это полезно. Что не полезно - это отсутствие интервью.
Автор переписал на питоне знакомое с давних пор i++ + ++i + ++i и пытается доказать, что "это нужно для работы". Нет, на работе за это бьют палкой до полного просветления, ибо такие загадки в коде есть диверсионная деятельность. Литкод/головоломки на собесе - всегда зло, за исключением случая набора учеников, стажеров, либо нулевых джунов, у которых корммерческого опыта нет, но есть, например, некое участие в опенсорсе (считай тот же студент, но с практикой). С них действительно должен быть спрос по теории, чтобы отсеять лодырей и неучей.
Видишь прописаный опыт в Х - спроси "чего делал по Х, с какими трудностями столкнулся, а почему был выбран Х , а не Y", "мы тут используем spring oauth - ты написал что знаешь его - расскажи подробнее, как сделать Х", и всё в таком ключе. Человек с опытом сразу активно включится в диалог. Жулик-накрутчик либо начнет нести ахинею, либо замолчит, потому что ни горе-ментор, ни нейросеть, ни SO ожидаемого ответа сходу не выдадут, а гугление/чтение/повторение сразу будут видны. Да, это не сможет спрашивать девочка из НR - но это и не ее работа, нужно привлекать синьоров.
Спасибо за конструктивный комментарий!
Достойно стать мемом)
P. S. Почему-то в голове звучит как Бэйлиновский "Nice day for fishin'") Для любителей VLDL.
Вообще все эти ваши собесы лютая дичь которая не отражает действительности, у нас в компании мы даем тестовое на часик, максимально приближенное к бизнесовым задачам. И тут чудеса происходят, мидлы которые заучивали теорию эту вашу - не могут банальное сделать, и в тоже время джуны у которых мозг не испорчен теорией и алгоритмами, с легкостью щелкают подобные задачки)
Шел 2025 год. Кандидатов на позиции Senior и middle тестируют жуткими edge-case'ами и примерами, которые даже Хауди Хо стороной обходит. А сколько опыта накрутил себе ОП?
кандидат на сеньора, который не знает как в словарь добавить значение; а положив - не замечает что не то положил. "запущу, IDE всё подскажет и подсветит, прогон ошибок выкинет, потом буду как-нибудь анализировать" вызывает сомнения как раз в способности анализировать и отлаживать.
Наверное это собеседующие плохие вопросы задают? Надо задавать "на поболтать", ведь сеньор питонодор он не про язык, не про базу, не про детали, он про концепции и обсуждения? А что потом эти концепции надо реализовывать и проверять на валидность - так на то пусть джуны язык зубрят?
"запущу, IDE всё подскажет и подсветит, прогон ошибок выкинет, потом буду как-нибудь анализировать" вызывает сомнения как раз в способности анализировать и отлаживать.
Конечно, тру-сениор (ТС) использует блокнот, чтобы богомерзкая IDE не мешала держать у себя в памяти АБСОЛЮТНО всё - синтаксисы, сигнатуры, команды, каждую деталь каждой экосистемы вокруг основных языков, каждую текущую спецификацию, каждый стандарт, каждый релевантный RFC, все баги всех используемых версий и т.д. и т.п.
Но настоящий тру-сениор (НаТС) использует не блокнот, а ed т.к. это стандартный текстовый редактор.
Однако, по-настоящему настоящий тру-сениор (ПоНаНаТС) использует бабочек для атмосферной фокусировки космических лучей, т.о. побитово записывая свой код на диск.
Впрочем, реально по-настоящему настоящий тру-сениор (РеПоНаНаТС) использует для этого Emacs...
Но только действительно реально по-настоящему настоящие тру-сениоры (ДеРеПоНаНаТС) используют что-то совсем другое, и никогда ничего не забывают.
Правда, этих дерепонанатсов пока никто в природе не встречал, но они есть!
/s
Проблема в том, что подсказки IDE ограничены. Особенно если данные на входе по типам верные, на выходе типы указанным соответствуют, а в середине верные преобразования - то линтеры и анализаторы промолчат. Особенно если типы широко написать(а этому IDE никак не помешает и волшебные инструменты не ругнутся).
Только вот когда в результате этих преобразований попытка запихнуть список как ключ словаря - то это как раз "базу языка знать нужно", а не ходить потом "а что эта ошибка обозначает?" спрашивать. Или когда всё выглядит верно, красным не помечено - только взял не ту библиотеку, потому что "IDE всё знает, импорт подсказала, LLM одобрила", и не работает как ожидалось.
И, сюрприз, не везде с отладчиком IDE подлезешь. Иной раз можно и с PDB зайти, а там подсказок то и нет.
Нет, понятно, что к джуну это не претензии, он не знает, его учить, ему помогать... но завышающие свой опыт то не в джунов целят.
Ну для питонов и жысы это актуально да, там даже IDE не справляется с волшебным синтаксисом и анализом. У типизированных языков - например java, go, rust, таких проблем в принципе нет и не может быть )
угу, и ещё иногда втаскивают динамическую генерацию классов и функций. Вот тут то совсем врата ада можно разверзнуть если пропустить через ревью... что интересно - такую эзотерику тащили не джуны, и было это ещё до модности вкатунов.
так в итоге и пришёл к текущим личным воззрениям "пиши так, чтоб поддерживать потом могли и джуны - прямолинейно, с минимумом сложного; но сложное знай, на случай если всё же нужно, и чтоб предотвращать впихивание"
Проблема в том, что подсказки IDE ограничены.
Понятно, что ограничены. Но есть, какие есть. Что в них плохого? Что плохого, если бы их было больше, т.е., они были бы менее ограничены? Что плохого, если я решил не париться с запоминанием, например, сигнатуры и названия метода стандартной библиотеки, если IDE подсказывает мне и название, и сигнатуру?
Ваши слова "вызывает сомнения как раз в способности анализировать и отлаживать" на гипотетическое высказывание "запущу, IDE всё подскажет и подсветит, прогон ошибок выкинет, потом буду как-нибудь анализировать" лично у меня вызывают вопросы.
Сам неоднократно использую такую практику (особенно на наиболее знакомых языках): пишу в IDE логику - логику, разруливая синтаксис с помощью IDE по мере поступления проблем (если таковые возникают) - в какой-то момент, имея минимально законченную логику, инициирую билд, запускаю программу, читаю результаты. Есть проблемы? Значит это что-то, что IDE не видит. Решаю. После успешного решения дописываю логику, запускаю, опять решаю проблемы. И т.д., до состояния релиза. Что в этом процессе плохого? И что плохого в том, что IDE чувствительную часть проблем берёт на себя, подсвечивая и подсказывая, помогая, т.о., и иметь в итоге меньше проблем, и меньше держать деталей в памяти? Разве было бы плохо, если бы IDE подсказывала вообще всё - от синтаксиса до символов и сигнатур любых включённых в проект библиотек, и до известных багов и уязвимостей? Разгружая, таким образом, и время (неожиданное столкновение с проблемами, поиск, чтение документации), и память разработчика?
IDE это не серебрянная пуля, это инструмент подобно рычагу. Если ваши слова перефразировать в терминах поднимания тяжестей, то получится что-то такое:
"Нажму рычаг и легко подниму очень тяжёлый груз" вызывает сомнения как раз в способности поднимать очень тяжёлые грузы без рычага.
Но я не хочу поднимать очень тяжёлые грузы без рычага! Нет, я хочу делать свою работу умно, а не грубой силой. Потому что я уже очень хорошо знаю, что одной грубой силы не просто не хватит - она ничтожна для любого отдельного человека, сколько бы он ни "качался". Поэтому я рад использовать любые доступные мне легальные средства, чтобы работать умнее и запоминать меньше, высвобождая свой ресурс памяти для того, чему ещё нет подходящего вспомогательного инструментария типа фичей IDE или грамотно составленной документации.
Кто я - джун, миддл, сениор, никому не известный дерепонанатс или вообще мне не место в разработке?
Особенно, если учесть, что я очень стараюсь ничего не запоминать. Только сегодня товарищ из соседней команды дал мне полномочия и стал показывать что и как надо делать в некоторой службе, которую до сих пор я никогда не трогал. Ну так я сразу ему сказал - давай включай запись ПОЖАЛУЙСТА. Потому что всё забуду. А с записью посижу несколько минут - добавлю себе несколько записей в электронную тетрадку, и всё, отвлекать больше никого не нужно. Если бы тупо пытался запомнить, только опозорился бы (впрочем, нет, фирма очень толерантная, мне бы повторили несколько раз, но тут не про это).
И часто у вас в коде встречается?
55 == True is True
Почему? Потому что Python использует ромбовидное наследование и алгоритм разрешения порядка поиска методов (MRO), основанный на линеаризации C3. [...]
Почему это важно? Потому что это тоже база.
Не соглашусь, что это такая уж база. Алгоритм C3 — не особенно интуитивный. Если дать вам граф наследования чуть посложнее, вы точно так же поплывёте. А в языках программирования он применяется не потому, что безумно хорош, а потому, что альтернативные подходы ещё хуже.
Само существование в питоне такого алгоритма — костыль. Это своего рода «алгоритм последнего шанса»: он описывает процедуру, при помощи которой интерпретатор сможет в произвольно сложном графе наследования вызвать хоть что-то хоть где-то более-менее математически корректным способом. В реальной практике следует не полагаться на этот порядок, а переопределить метод в наследнике и перевызвать в нём нужный унаследованный метод вручную.
Очень странное видение найма. Было бы, с натяжкой, объяснимо, если бы вы мучали этим Middle+, но senior почти наверняка не вспомнит многих тонкостей. Хотя и для других уровней это достаточно бессмысленное углубление в дебри, проверяющее память, качество кода, с которым работал кандидат и специфичность кейсов, а не его реальный навык
если автор утверждает, что на этот пример отвечают:
55 == True — это True
True is True — это False
то увы этот пример работает
Безотносительно качества примеров, советы в конце статьи - это примерно как говорить "не нарушайте законы, вас могут поймать". Что теряет кандидат, когда обманывает? Ничего, только свое время. При этом получает хороший шанс проскочить в какое-нибудь "богатое" место, где денег очень много, а процессы настолько запутанные, что затеряться там на годик вполне можно. Дальше идём в новое место. И таким образом, все также не имея никакого толкового опыта, этот пилигрим уже имеет реальные записи в резюме с возможностью их подтвердить, но вообще не понимает ничего: потому что крудошлепил/заполнял формочки по шаблону/делал как сказали. А причины тут две: нет никакого способа таких вот накручивателей отсеивать заранее и готовность слишком богатых компаний брать с рынка хоть кого-то, потому что могут. А потом они идут в другие места с соответствующими запросами, и тратят чужое время на тех. собесе. Только в минусе не кандидат, а компания и собеседующие. Знает он там, как должен (не)работать какой-то говнокод или нет - вообще дело десятое. Если человек может внятно объяснить, что именно и зачем он делал, какие задачи решал, как и почему именно так - это уже успех. Часто даже это не могут объяснить (ну я там данные загружал, ну иногда инциденты приходили, искал). А то, что вместо кортежа получится генератор, можно увидеть при первом же запуске кода, и для этого не нужно обладать какими-то особенными знаниями.
То есть правильный ответ: нет, такой код не выполнится. И это не про подвох, не про тонкости, не про магию. Это просто базовая логика работы типов данных в Python. То, что должен понимать любой человек, который пишет код больше полугода
Ну... Некоторые не склонны писать говнокод. И могут писать крутые штуки, но да, не иметь представления, почему какая-то неведомая выдуманная фигня не работает. Мне за 6 лет ни разу не приходило в голову сувать в ключ словаря что-то нехешируемое. И нет, я не читал учебник по питону. И да, знаю об этом только из подготовки к собесам уже на должности повыше. Наверное, я просто профнепригоден был всё это время и отсутствие этих ценнейших знаний мешало решать бизнес-задачи...
мне еще такая нравится
Назовите типы данных у переменных:
a = ()b = 1c = (2)d = 3,print(type(a))print(type(b))print(type(c))print(type(d))
В php 55 == true вернёт true
Кандидат сбежал в слезах. Про накрутку опыта