Проблема не в том, чтобы "забивать свою голову" редкими приёмами, а в том, что базовые конструкции и особенности языка - это как грамматика в разговоре.
Использовать "только безопасные конструкции" - хорошо, но в реальной работе постоянно встречаются чужие решения, легаси-код и нестандартные ситуации. И если при этом человек не понимает базового поведения языка, он может тратить в разы больше времени на отладку и исправление багов. Поэтому такие вопросы - это не "чушь", а минимальная проверка: сможете ли вы разобраться, если что-то пойдёт не по шаблону
Вы немного передергиваете. Я нигде не говорил, что "умный кандидат = плохо". Речь о том, что интервьюеры тоже люди, и бывают разные ситуации: кто-то спрашивает по методичке, кто-то, что знает сам. Если на собесе есть ошибка - это повод обсудить, а не уходить в крайности вроде "тупой/умный". Цель ведь одна - найти совпадение ожиданий и навыков, а не мериться, кто умнее
Приведённые примеры - это не про "плохо читаемый код" или "специальные изыски", а про поведение самого языка, с которым неизбежно сталкивается любой, кто работает с Python. Ромбовидное наследование, comprehension и mutable default аргументы - это не пример "так надо писать", а проверка понимания того, как это работает. Даже если вы лично такого кода не пишете, понимать базовое поведение языка всё равно важно: встреча с легаси, отладка чужих тестов, библиотек или автоматизация.
Да, вы правы, классическое chained comparison по стандарту описывает <, >, <=, >=.
В примере в статье это не "классическая цепочка сравнений", а обычная комбинация операторов, где == вычисляется первым, а затем результат участвует в сравнении с is. Поэтому Python и интерпретирует выражение как (55 == True) and (True is True)
Скорее всего вы воспринимаете статью слишком буквально :)
Это всего лишь выборка типовых вопросов, которые встречались на собеседованиях. На реальных интервью обычно проверяют гораздо больше аспектов: архитектуру, опыт работы с проектами, умение решать нетривиальные задачи вживую. Так что правильные ответы на все вопросы статьи это круто, но это не означает автоматического статуса "сеньора помидора"
- Нуууу, производительность - Нуууу, можно сделать на этом мемоизацию и еще специфический синглтон
На самом деле это и есть основные принципы зачем так сделано. А почему не сделать по другому - думаю нужно спросить у core девелоперов python. Или эксперты в комментариях подскажут :)
Понимаю, что иногда душа болит за то, что нахватавшиеся по верхам и не знающие корневых принципов работы ЯП хотят многаденяк. Кажется, что без знания некоторых вещей из показанных примеров все-таки можно писать годный код, но я не программист, хоть и приходится писать код на Python иногда.
У каждого свои приоритеты, кому-то просто не хочется потом тратить часы и объяснять на ревью, почему писать if a == True плохо и как работает наследование в python
Однако вот пример с def append_to_list(item, my_list=[]) меня, честно говоря, расстроил. Для меня не интуитивно, что при вызове функции без указания аргумента my_list не происходит создания нового списка и такое поведение интерпретатора мне кажется неправильным. То есть если в каких-то примерах действительно можно поразмыслить и понять, что {x for x in range(3)} -- это не словарь, т.к. тут нет пар key-value, но в примере с append нужно именно знать, что питон -- ленивая задница.
Да, кажется чем-то не очевидным. Но после пары раз, когда эта "ленивая задница" развалит нам весь прод, уже на такие вещи начинаешь смотреть внимательнее
В данном случае приоритет операторов другой: == выше, чем and, а is и and разделены. Python интерпретирует это как (55 == True) and (True is True). Можете проверить в REPL - результат будет False.
Но после этого примера читать статью уже не стал.
Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
Да, может быть ощущение, что рынок усредняет зарплаты и это демотивирует. Но как показывает практика, специалисты, которые растут и развиваются, в итоге уходят в более интересные роли и проекты с совсем другим уровнем ЗП
Знание "базы" само по себе не делает человека хорошим инженером, особенно если оно от "свежих курсов". Эти вопросы служат как быстрый фильтр на базовое понимание, чтобы отделить людей, которые действительно работают с языком, от тех, кто его видел только в теории. А полноценное собеседование, конечно, включает практические и прикладные задачи. В статье лишь выборка
Отвечаю на этот вопрос в комментариях уже не первый раз :) Ни у кого в последствии нет желания, интереса и времени, объяснять на ревью, как работает наследование в python и почему писать if a == True плохо. Собеседование не состоит только из таких задач, это лишь примеры, которые почему-то воспринимаются, как весь собес. Возможно мне нужно было это явно объяснить в статье, хотя мне казалось это очевидным
Это проверка базового понимания языка и инструментов, чтобы убедиться, что человек сможет писать поддерживаемый код без грубых ошибок. После этого в идут более практические и архитектурные задания, где и проявляется мастерство. Никому не интересно впоследствии тратить часы времени на ревью и объяснять, как работает наследование в Python
Встречается, да, особенно если место тепленькое и пригретое. Можно так насидеть 10 лет и ничего не знать
Просто потом никому не хочется исправлять чужие ошибки и чужой код в реальной работе. А также тратить время на ревью и объяснять, почему писать так плохо:
По ту стороны сидят такие же трудяги, которые также могут чего-то не знать. Ну или спрашивать чего сами не знают. Это страх большинства собеседующих, узнать, что кандидат умнее
Добрый день! Благодарю вас за комментарий и за то, что поделились своим опытом. Статья была написана на основе выборки из нескольких сотен собеседований и отражает обобщённые наблюдения, а не эмоции от конкретной ситуации.
Да, согласен, бизнес платит не за красивый код, а за работающий продукт. На собеседовании, как правило есть секция, написать автотесты, в статью это не включал, так как супер специфик кейс, но там тоже все плохо. Речь именно про AQA позиции
Встречаются кандидаты, с умеренным опытом, но как говорится: сразу видно человек "шарит в этой теме" и все у него ок, начиная с теории, заканчивая задачками и практикой. Думаю если кандидат работал 1 - 2 года, но при этом вкладывался в свое развитие, не обязательно на основной работе, он покажет очень хороший результат
Так и вопросы сами по себе не сложные, на уровне решения повседневных задач. Эта статья выборка из нескольких сотен собеседований, и как показывает практика, если на базовых задачах все плохо, про паттерны смысла спрашивать нет. От слова SOLID бросает в ужас
Не всегда так конечно, но частенько бывает. Да и сам процесс не мной придуман)
Проблема не в том, чтобы "забивать свою голову" редкими приёмами, а в том, что базовые конструкции и особенности языка - это как грамматика в разговоре.
Использовать "только безопасные конструкции" - хорошо, но в реальной работе постоянно встречаются чужие решения, легаси-код и нестандартные ситуации. И если при этом человек не понимает базового поведения языка, он может тратить в разы больше времени на отладку и исправление багов. Поэтому такие вопросы - это не "чушь", а минимальная проверка: сможете ли вы разобраться, если что-то пойдёт не по шаблону
Вы немного передергиваете. Я нигде не говорил, что "умный кандидат = плохо". Речь о том, что интервьюеры тоже люди, и бывают разные ситуации: кто-то спрашивает по методичке, кто-то, что знает сам. Если на собесе есть ошибка - это повод обсудить, а не уходить в крайности вроде "тупой/умный". Цель ведь одна - найти совпадение ожиданий и навыков, а не мериться, кто умнее
Приведённые примеры - это не про "плохо читаемый код" или "специальные изыски", а про поведение самого языка, с которым неизбежно сталкивается любой, кто работает с Python. Ромбовидное наследование, comprehension и mutable default аргументы - это не пример "так надо писать", а проверка понимания того, как это работает. Даже если вы лично такого кода не пишете, понимать базовое поведение языка всё равно важно: встреча с легаси, отладка чужих тестов, библиотек или автоматизация.
Честно, я немного удивлен тому, что в статье есть и другие примеры, но в комментариях все свелось к обсуждению задачи с операторами :)
Да, вы правы, классическое chained comparison по стандарту описывает
<,>,<=,>=.В примере в статье это не "классическая цепочка сравнений", а обычная комбинация операторов, где
==вычисляется первым, а затем результат участвует в сравнении сis. Поэтому Python и интерпретирует выражение как(55 == True) and (True is True)Скорее всего вы воспринимаете статью слишком буквально :)
Это всего лишь выборка типовых вопросов, которые встречались на собеседованиях. На реальных интервью обычно проверяют гораздо больше аспектов: архитектуру, опыт работы с проектами, умение решать нетривиальные задачи вживую. Так что правильные ответы на все вопросы статьи это круто, но это не означает автоматического статуса "сеньора помидора"
Добрый день! Благодарю за комментарий!
На самом деле это и есть основные принципы зачем так сделано. А почему не сделать по другому - думаю нужно спросить у core девелоперов python. Или эксперты в комментариях подскажут :)
Добрый день! Благодарю за ваш комментарий!
У каждого свои приоритеты, кому-то просто не хочется потом тратить часы и объяснять на ревью, почему писать
if a == Trueплохо и как работает наследование в pythonДа, кажется чем-то не очевидным. Но после пары раз, когда эта "ленивая задница" развалит нам весь прод, уже на такие вещи начинаешь смотреть внимательнее
В данном случае приоритет операторов другой:
==выше, чемand, аisиandразделены. Python интерпретирует это как(55 == True) and (True is True). Можете проверить в REPL - результат будетFalse.Буду рад, если все же дочитаете статью до конца, возможно, там найдете еще что-то полезное :)
Да, может быть ощущение, что рынок усредняет зарплаты и это демотивирует. Но как показывает практика, специалисты, которые растут и развиваются, в итоге уходят в более интересные роли и проекты с совсем другим уровнем ЗП
Знание "базы" само по себе не делает человека хорошим инженером, особенно если оно от "свежих курсов". Эти вопросы служат как быстрый фильтр на базовое понимание, чтобы отделить людей, которые действительно работают с языком, от тех, кто его видел только в теории. А полноценное собеседование, конечно, включает практические и прикладные задачи. В статье лишь выборка
Отвечаю на этот вопрос в комментариях уже не первый раз :) Ни у кого в последствии нет желания, интереса и времени, объяснять на ревью, как работает наследование в python и почему писать
if a == Trueплохо. Собеседование не состоит только из таких задач, это лишь примеры, которые почему-то воспринимаются, как весь собес. Возможно мне нужно было это явно объяснить в статье, хотя мне казалось это очевиднымЭто проверка базового понимания языка и инструментов, чтобы убедиться, что человек сможет писать поддерживаемый код без грубых ошибок. После этого в идут более практические и архитектурные задания, где и проявляется мастерство. Никому не интересно впоследствии тратить часы времени на ревью и объяснять, как работает наследование в Python
В статье по мимо примеров с операторами есть еще другие, попробуйте смотреть шире
Встречается, да, особенно если место тепленькое и пригретое. Можно так насидеть 10 лет и ничего не знать
Просто потом никому не хочется исправлять чужие ошибки и чужой код в реальной работе. А также тратить время на ревью и объяснять, почему писать так плохо:
По ту стороны сидят такие же трудяги, которые также могут чего-то не знать. Ну или спрашивать чего сами не знают. Это страх большинства собеседующих, узнать, что кандидат умнее
Добрый день! Как будто тут каждому свое, вкусовщина. С python начать проще, поэтому и выбирают
Добрый день! Благодарю вас за комментарий и за то, что поделились своим опытом. Статья была написана на основе выборки из нескольких сотен собеседований и отражает обобщённые наблюдения, а не эмоции от конкретной ситуации.
Да, согласен, бизнес платит не за красивый код, а за работающий продукт. На собеседовании, как правило есть секция, написать автотесты, в статью это не включал, так как супер специфик кейс, но там тоже все плохо. Речь именно про AQA позиции
Встречаются кандидаты, с умеренным опытом, но как говорится: сразу видно человек "шарит в этой теме" и все у него ок, начиная с теории, заканчивая задачками и практикой. Думаю если кандидат работал 1 - 2 года, но при этом вкладывался в свое развитие, не обязательно на основной работе, он покажет очень хороший результат
Так и вопросы сами по себе не сложные, на уровне решения повседневных задач. Эта статья выборка из нескольких сотен собеседований, и как показывает практика, если на базовых задачах все плохо, про паттерны смысла спрашивать нет. От слова SOLID бросает в ужас
Не всегда так конечно, но частенько бывает. Да и сам процесс не мной придуман)