Все статьи

Привет, Хабр! Меня зовут Бартенев Евгений, я автор курса «Python-разработчик» в Яндекс Практикуме и практикующий разработчик. Я прособеседовал сотни кандидатов и сам неоднократно побывал в роли собеседуемого, поэтому хорошо представляю, какие именно знания проверяют на интервью и где чаще всего «проваливаются» не только джуны, но и опытные разработчики. Первая часть этой статьи вызвала оживлённое обсуждение. В комментариях читатели делились собственным опытом, напоминали о тонкостях, которые я упустил, и задавали отличные уточняющие вопросы. В этой части я продолжу разбирать очередные «подводные камни» в Python. Как и раньше, я не буду разбирать заезженные вопросы вроде «чем отличается список от кортежа». Вместо этого — разберём реальные особенности Python, на которых строятся самые коварные задачи и вопросы.

Привет! Меня зовут Евгений Бартенев, я техлид и автор курса «Python-разработчик» в Яндекс Практикуме. В профессии я уже больше 20 лет: прошёл путь от джуниора до эксперта по Python и видел, как меняется рынок и как вместе с ним меняются требования к разработчикам. И за это время я заметил одну закономерность: часто после первых шагов в карьере люди словно упираются в потолок. Кажется, цель ясна: «стать мидлом, потом синьором» — но такой ориентир почти никогда не помогает двигаться вперёд. Дело в том, что должность — лишь формальный ярлык. Настоящий рост приходит через навыки, опыт и умение применять их на деле. Без понимания этой логики легко застрять на одном месте: работать много, но не двигаться в профессии. В этом материале поделюсь подходами, которые помогут выйти из подобной ситуации. Я расскажу, что такое план профессионального развития, зачем он нужен и как его использовать для личного роста, на собеседованиях, в обучении и в реальной работе. Затем покажу пример карты навыков Python-разработчика, дам шаблон плана и конкретные рекомендации, что делать, если вы действительно нацелены на движение вперёд и хотите вырасти до уровня эксперта.

At first glance, Python looks simple and straightforward, which is exactly why it’s such a great language to start a developer career with. However, behind that simplicity lie several nuances that interviewers often use. This is where junior developers can easily get caught off guard: your code seems to work fine, but suddenly the behavior isn’t what you expected. As the author of the Python Developer course at Yandex Practicum, I often break down these situations on my YouTube channel, where I run open mock interviews with junior developers. The examples I cover aren’t abstract; they come directly from real interview sessions and observations. In this article, I’ve collected the most interesting Python quirks that repeatedly come up in interviews and that you’ll almost certainly encounter in your own technical screening. I’ll show you the kinds of questions interviewers typically ask and explain why they matter. Whether you’re preparing for your very first job as a junior developer or want to brush up on your fundamentals, this breakdown will be a valuable resource.

If you’ve ever read developer documentation, you’ve probably seen phrases like “Open the console,” “Run this command in the terminal,” or “You’ll need the command line for this step.” These tools are often described as incredibly powerful and useful, but what does that actually mean in practice? Why is the terminal considered an indispensable tool for developers, and what can it do that goes beyond familiar graphical interfaces? In this article, we’ll unpack the terms terminal, shell, and command line, highlighting the differences between them and how they work together. You’ll learn why working in the console is often faster and more efficient, and we’ll walk through practical examples of tasks that are difficult or sometimes impossible to accomplish using only a graphical interface.

Python кажется простым и понятным — именно поэтому с него так классно начинать карьеру разработчика. Но за этой простотой скрываются тонкости, которые любят проверять на собеседованиях. И тут начинающий разработчик может неожиданно попасть впросак: вроде бы код работает, но поведение совсем не такое, как ожидалось. Как автор курса «Python-разработчик» в Яндекс Практикуме, я часто разбираю подобные ситуации на своём YouTube-канале, где провожу открытые тестовые интервью с джунами. Всё, о чём я говорю, — это не абстрактные примеры, а реальные наблюдения и выводы, сделанные прямо в ходе этих собеседований. В статье я собрал самые интересные особенности Python, которые неоднократно встречались в подобных интервью и которые почти наверняка всплывут на вашем техническом собеседовании. Покажу, что именно спрашивают интервьюеры, и поясню, почему это важно. Если вы только готовитесь к первой работе или хотите подтянуть фундаментальные знания — продолжайте читать.

When building high-load systems, one of the biggest challenges is making sure your solution performs well under pressure. This is especially important when your system relies heavily on a database — often the main bottleneck for throughput. That’s exactly what happened in one of my recent projects, where Cosmos DB turned out to be the limiting factor. The client had strict performance requirements, and meeting them meant I had to dive deep into what Cosmos DB is really capable of — and how to get the most out of it. At first, I didn’t have a clear answer to a simple but critical question: how fast can we actually send data to Cosmos DB? Microsoft’s documentation gave some general ideas and high-level guidelines, but it wasn’t enough to design a solid, performance-focused solution. To make things more challenging, the client chose Kotlin as the development language — and there’s no official Cosmos DB SDK for Kotlin.