20 вопросов и ответов из интервью на позицию Python-разработчика

Оглавление (нажмите, чтобы открыть):

Дзен питона на русском

Разработчики языка Python придерживаются определённой философии программирования, называемой «The Zen of Python» («Дзен Питона», или «Дзен Пайтона»). Её текст выдаётся интерпретатором Python по команде import this (работает один раз за сессию).

В целом она подходит к программированию на любом языке.

Текст философии

  • Красивое лучше, чем уродливое.
  • Явное лучше, чем неявное.
  • Простое лучше, чем сложное.
  • Сложное лучше, чем запутанное.
  • Плоское лучше, чем вложенное.
  • Разреженное лучше, чем плотное.
  • Читаемость имеет значение.
  • Особые случаи не настолько особые, чтобы нарушать правила.
  • При этом практичность важнее безупречности.
  • Ошибки никогда не должны замалчиваться.
  • Если они не замалчиваются явно.
  • Встретив двусмысленность, отбрось искушение угадать.
  • Должен существовать один и, желательно, только один очевидный способ сделать это.
  • Хотя он поначалу может быть и не очевиден, если вы не голландец [^1].
  • Сейчас лучше, чем никогда.
  • Хотя никогда зачастую лучше, чем прямо сейчас.
  • Если реализацию сложно объяснить — идея плоха.
  • Если реализацию легко объяснить — идея, возможно, хороша.
  • Пространства имён — отличная штука! Будем делать их больше!

Автор этой философии — Тим Петерс. Оригинал на английском:

Отсылка к нидерландскому программисту, создавшему язык Python, Гвидо ван Россуму (нидерл. Guido van Rossum).

Подготовка к собеседованию на позицию Python-разработчика

На сегодняшний день число Python-программистов продолжает расти, однако количество рабочих мест для них увеличивается не так быстро. Современному разработчику нужно быть конкурентоспособным, чтобы пробиться на желаемую позицию. Мы подготовили статью с темами и вопросами, которые работодатель может затронуть на собеседовании, и дополнили их небольшими объяснениями — по сути, это задачи по программированию на Python с решениями. Материал будет полезен продолжающим для повторения, а начинающим поможет сориентироваться, куда делать первые шаги, на что обратить внимание. Воспринимайте как своеобразный маяк.

Работа со списками

Лямбда-выражения, генераторы списков и выражения-генераторы

Лямбда-выражения — сокращённый метод создания однолинейных анонимных функций. Их простота часто (но не всегда) делает код более стройным и читабельным, чем классическое объявление функций. С другой стороны, та же простота ограничивает возможности и зоны применения лямбда-выражений.

Генераторы списков обеспечивают краткий синтаксис для создания списков. Они используются для составления списков, в которых каждый элемент — результат некоторой операции (операций) с элементами другой последовательности или итератором. Генераторы списков могут использоваться для создания подпоследовательности тех элементов, члены которых удовлетворяют определённому условию. Генераторы списков в Python — своеобразная альтернатива встроенным функциям map() и filter() .

Лямбда-выражения с функциями map() и filter() и генераторы списков схожи, поэтому выбор одного из этих инструментов субъективен и зависит от случая. Но следует отметить, что генераторы списков выполняются несколько быстрее — вызов лямбда-функции создаёт новый стековый кадр.

Выражения-генераторы синтаксически и функционально похожи на генераторы списков, но есть важные различия между их механизмами работы и областями применения. Итерация при наложении выражения-генератора или генератора списка будет делать всё то же самое, но генератор списков сначала создаст целый список в памяти, в то время как выражение-генератор будет создавать элементы на ходу по мере необходимости. Выражения-генераторы могут быть использованы в большом или даже бесконечном количестве последовательностей. А генерирование значений по требованию обеспечивает повышение производительности и снижение использования памяти. Однако следует отметить, что стандартные методы списков list в Python могут применяться на результатах выполнения генератора, но не на самом генераторе.

В чём разница между списком и кортежем?

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

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

Отладка кода и тестирование

Какой подход вы используете для модульного тестирования в Python?

Фундаментальный ответ на этот вопрос относится к использованию фреймворка Python — unittest.

Собеседование Python. Интервьюер и интервьюируемый

Я работаю Python-программистом 2,5 года и прошел через 10-ки собеседований. Я был интервьюируемым и был интервьюером, смотрел на этот процесс с двух сторон. За это время у меня накопился опыт, которым я хотел бы с вами поделиться.

На вебинаре я покажу примеры Python-задач, с помощью которых работодатели отсеивают кандидатов на должность «программист Python». А ещё я дам рекомендации, чего ожидать от собеседования, и отвечу на ваши вопросы.

20 вопросов и ответов из интервью на позицию Python-разработчика

Новости собираются с мира по нитке на совершенно безвозмездной основе.
Ты легко можешь посодействовать проекту, добавив ссылку на интересную новость, статью, интервью или проект о python.
А еще можно форкнуть код этого проекта на Github и помочь в развитии его функциональности.
И еще один вариант — проголосовать рублем

Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»

За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.

Экспериментальная функция:

Ниже вы видите текст статьи по ссылке. По нему можно быстро понять ссылка достойна прочтения или нет

Просим обратить внимание, что текст по ссылке и здесь может не совпадать.

Введение

За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.

Общие идеи

Это действительно так. Это связано с тем, что многие тимлиды/тех.директоры не знают, что именно они хотят видеть в middle-разработчике. Поэтому на таких собеседованиях обычно просят

«написать сортировку пузырьком на любом языке»

Так же мало кто понимает, чем junior-разработчик отличается от middle-разработчика. Кто-то говорит, что middle – это разработчик с опытом от полутора лет, а кто-то — от трёх. В моём понимании middle-разработчик — это тот разработчик, которому можно смело отдать небольшой проект или какую-либо часть крупного проекта, и чтобы именно он был за неё ответственен. Также важным критерием для middle-разработчика является умение быть наставником для кого-либо или просто умение помогать внедриться новому сотруднику в проект.

Собеседование — это не экзамен, а возможность выявить насколько компания и кандидат подходят друг другу.

Это важное правило часто не понимают сами работодатели. Однажды я был на собеседовании, где меня заставили тянуть билет и отвечать перед собеседующим на листочке. При этом на протяжении всего этого собеседования мы общались десять минут. Такое же поведение часто прослеживается со стороны кандидата. Часто кандидат хочет на всё ответить и ведёт себя как отличница с первой парты. Но тут тоже важно понять, что работодателю не особо интересно насколько хорошо Вы знаете

«отличие Python2 от Python3»

. Гораздо важнее для работодателя понять в целом как ты держишься на собеседовании, как рассуждаешь, как реагируешь на неудачи и т.д.

Middle-разработчиком нельзя стать без опыта.

Конечно, можно, но это повлечёт через какое-то время огромные неприятности как для начальника этого разработчика, так и для проекта. Для слишком одарённых кандидатов без опыта у HR-специалистов есть свой термин – «strong junior-разработчик». Скорее всего таким разработчикам будет предложена неплохая денежная компенсация, но обязанности у них будут как у junior-разработчиков. Возвращаясь к middle-разработчикам хочется отметить, что middle — это тот, кто хоть какое-то время проработал в разработке и понимает из каких процессов она состоит. Также middle умеет работать с различными инструментами(мониторинг, деплой, профилирование, тестирование) с которыми человек без опыта вряд ли сталкивался в учебных целях.

На позицию Middle-разработчика soft skills становятся важным фактором.

Чем выше должность, тем с большим количеством людей приходится взаимодействовать. Поэтому очень часто при приёме на позицию middle-разработчика создаются дополнительные собеседования с HR-специалистом для составления психологического портрета будущего сотрудника. К этому собеседованию надо относиться также серьёзно, как и к техническому. Надо понимать, что Вам дальше работать с этими людьми. И если Вы чувствуете, что Ваши будущие коллеги Вам не очень подходят, то лучше сразу отказаться от дальнейшего сотрудничества.

На позицию middle-разработчика реже дают тестовые задания .

Это утверждение достаточно субъективное. Лично я действительно столкнулся с таким фактом. Связываю это с тем, что работодателя больше интересует твоё резюме. Если резюме составлено неважно, то скорее всего следует ждать тестового задания.

Вопросы

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

1. Как дела с тестированием? Какие тесты вы пишете? Какие библиотеки для тестирования вы используете? (фабрики, моки и т.д.)

Тестирование – очень важная часть любой разработки. В моём понимании, тесты должны писать все разработчики хотя бы в каком-то виде. Единственное, кому можно простить отсутствие тестов – это стартапы. В стартапах часто меняется

из-за чего старые проекты обычно бывают никому не нужны. А значит обеспечение качеством таких проектов было впустую потраченным временем. Для всех остальных компаний пощады в этом вопросе быть не должно. Нужно понимать, что внедрение нового сотрудника в проект на первых порах будет приводить к различным ошибкам в коде. И тесты в данном случае является его личной перестраховкой и перестраховкой того, кто будет выливать его решения в production.

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

Стоит отметить, что на этом вопросе технические специалисты часто начинают теряться. Кто-то иногда говорит, что команда только начала заниматься написанием тестов и еще не знакома со всеми тонкостями этого ремесла. Но иногда я слышал вот такой ответ:

«Тестами должны заниматься тестировщики, а разработчик должен творить».

Это абсолютно неверно.

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

2. Что делает разработчик с кодом перед тем, как отправить его в репозиторий?

Под этим вопросом понимается локальная проверка своего кода по различным параметрам. Вот небольшой список того, чем обычно проверяют код перед отправкой в репозиторий:

  • Flake8 – анализ кода на соблюдение PEP8,
  • Pylint – статический анализ кода,
  • Coverage – анализ кода на тестовое покрытие,
  • Tox – проверка кода на совместимость с различными версиями отдельных пакетов и с разными версиями Python.

Отсутствие данного кейса в разработке не является критичным. Также во многих компаниях этот кейс используется непосредственно в CI, и разработчик локально у себя ничего не запускает. Даже если это не используется в разработке, то было бы неплохо, чтобы люди, которые Вас собеседуют имели базовые представление об этих инструментах.

3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?

Этот вопрос не имеет никаких подводных камней и задаю я его чтобы получше понять устройство компании. Если в проектах нет CI/CD и DevOps-инженер тоже отсутствует, то есть вероятность что именно Вы будете этим заниматься. Поэтому этот момент тоже лучше обсудить на собеседовании.

4. Есть ли Code Review? Как оно проходит?

Первую часть вопроса можно оставить без комментариев, потому что все понимают важность этого мероприятия. Но стоит отметить что лично меня интересовало как именно оно проходит. Чаще бывает так, что каждый из команды ревьюит разработчика который сделал Merge Request. Но иногда встречается, что над любым разработчиком есть ментор/наставник и именно он ревьюит разработчика. Первый подход считаю более правильным, так как чем больше людей ревьюит код, тем лучше для проекта и для команды. Здесь сразу затрагиваются такие аспекты, как командное взаимодействие, коллективная ответственность, увеличение

5. Какую систему контроля версий Вы используете?

На данный момент в России существует немало компаний, которые до сих пор использует

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

и особого удовольствия мне это не доставило.

6. Используете ли вы git/hg-flow или какую-либо определенную методологию при работе с git/hg?

Данный вопрос вытекает из предыдущего вопроса о системах контроля версий. Поэтому если команда не использует

, то и задать его нет смысла. Если же компания использует

, то этот вопрос Вам сможет показать насколько хорошо отлажен процесс разработки.

7. Используете ли Вы методологию разработки (scrum, kanban и т.д.)?

В разработке важно придерживаться какого-то определённого подхода(методологии). Самый популярный подход в разработке – итеративный. Такой подход позволяет определить Ваш вклад в проект. В моём понимании, если в команде используется какая-то методология – это однозначно хорошо. Это позволяет Вам определить Вашу эффективность. Также это помогает понимать Вам сроки выделенные на задачи. Это всё равно что у школьников есть 4 четверти в году, где им выставляют отметки, чтобы потом определить итоговую оценку за год.

8. Используются ли системы мониторинга в проектах(Sentry, NewRelic и т.д.)?

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

9. Используется ли в проекте система для хранения логов и работы с ними(ELK-технология и прочее)?

Для меня это тоже является важным показателем. Если ELK отсутствует, то очень трудно определить причину появления сложной ошибки в системе. Данный вопрос не настолько важен, как вопрос №8, но его тоже стоит задать чтобы понять насколько богат опыт у команды в профилировании сложных ошибок.

10. Какие БД используются в проекте? Почему именно такие?

Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Такой ответ считаю неуместным. Технический специалист должен понимать минусы/плюсы используемой им БД. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.

11. Какая версия языка Python используется в проектах? Если используется версия Python2.x, то планируется ли переход на Python3.x? И как будете происходить миграция с одной версии на другую?

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

Мастер Йода рекомендует:  29 Python-проектов, оказавших огромное влияние на разработку

12. Компания ищет fullstack-разработчика или backend-разработчика?

Этот вопрос я задаю только в том случае, если компанию это сама не уточнила перед собеседованием. Вакансии fullstack-разработчика на рынке труда можно встретить довольно часто. Многие компании считают это выгодным для себя. Мой личный опыт говорит мне что fullstack-разработчиков не бывает, так как frontend и backend стали слишком разными направлениями с того момента как появился Веб. Иными словами, «На двух стульях не усидишь».

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

13. Используется ли технология контейнеризации в проектах?

Этот вопрос является дополнением к вопросу №3.

14. Немного поспрашивать собеседующего о том, чем он занимался до этого проекта и давно ли он в проекте.

Этот вопрос очень важен. Чем богаче опыт вашего собеседующего, тем больше это отразится на ваших умениях и навыках через какое-то время. Особенно хорошо задавать такой вопрос в небольшой компании, где медленная текучка кадров.

15. Существует ли в компании годовая/квартальная оценка сотрудников и как она происходит?

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

16. Есть ли у в компании переработки? Если есть, то компенсируются ли они и как часто они происходят?

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

17. Насколько в компании сильна бюрократия? (Оцените от 1 до 10)

Многие разработчики даже не догадываются о присутствии бюрократии в IT-сфере, но, к сожалению, она есть. Особенно это относится к крупным старым компаниям или к компаниям, которые работают с гос. заказами. Степень бюрократии в компании зависит только от фантазии руководства. Обычно бюрократия заключается в различных формальных заявках, визированиях, доступах, конфликтах интересов между несколькими подразделениями компании и написании скучной сырой документации в Word. Главная проблема такой бюрократии – это очень сильное торможение процесса разработки. То что в нормальной компании делается за один рабочий день, тут на это будут уходить недели. Проще говоря, чем сильнее бюрократия в компании, тем медленнее развитие продукта и Ваше развитие как специалиста.

18. Как обстоят дела с выбиванием ресурсов?

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

19. Как собеседующий относится к новым внедрениям в проекте?

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

20. Является ли компания участником каких-либо IT-конференций и есть ли у компании публикации на IT-темы?

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

21. Есть ли митапы внутри компании?

Здесь речь пойдет о митапах у разработчиков внутри команды или между командами. Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших

22. Есть ли в компании стажёры и развита ли система наставничества?

Стажёры – это потенциальное будущее компании. Если в компании есть стажёры, то возможно Вы сможете быть для них наставником и делиться своим личным опытом. Наставничество – это тоже одно из направлений где Вы сможете развиваться.

Заключение

Всё вышесказанное является моими мыслями, основанными на личном опыте и не является 100-процентно верной информацией. Главная мораль статьи заключается в том, что проверять надо не только кандидата, но и работодателя. Также не стоит нервничать перед собеседованиями или на собеседованиях. Надо понимать что собеседующие такие же люди как и Вы, которые тоже ошибаются или чего-то не знают или не понимают.

15 вопросов по Python: как джуниору пройти собеседование

Готовитесь к собеседованию на позицию Python-джуниора? Сайт proglib.io опубликовал подборку важных вопросов по Python с объяснением и полезными ссылками вам поможет.

Python надежно занял место в пятерке самых популярных языков программирования. Кажется, в ближайшее время он не собирается сдавать позиции. Число разработчиков растет быстрее, чем количество рабочих мест для них. Чтобы получить должность джуниора в хорошей компании, важно отлично показать себя на собеседовании. Итак, что же должен знать начинающий Python-программист по мнению работодателя.

О Питоне в двух словах

Разумеется, отправляясь на интервью по Python, соискатель должен иметь общее представление об этом языке программирования.

Мировые IT-лидеры, такие как Google и Dropbox, активно используют Python в своих проектах. Причина популярности кроется в его простоте и мощности.

Прежде всего, язык эффективен в активно развивающихся сферах веб-разработки, машинного обучения и big data. На нем создаются игры и научные модели. Также он с успехом применяется в системном администрировании и автоматизации задач.

Python относится к интерпретируемым языкам и не требует компиляции. Обработчик проходит по Python-коду построчно и сразу его выполняет. Это облегчает отладку, но может негативно отражаться на скорости работы. Самый известный интерпретатор называется CPython.

Официально язык поддерживает ООП. Но в то же время в нем имеются средства для функционального программирования. Так что Python не ограничивает разработчика в парадигмах.

10 базовых вопросов по Python

Прежде всего, программист должен хорошо знать свой рабочий инструмент и его возможности. В противном случае придется изобретать велосипеды и тратить время на поиски очевидных решений. Чтобы показать себя в лучшем свете на собеседовании, просмотрите еще раз справочники по Python.

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

Все данные относятся к одному из двух типов – неизменяемые или изменяемые. Очевидно, что первые в конце программы выглядят точно так же, как и в начале. К ним относятся числа, строки и кортежи. С другой стороны, списки и словари могут измениться в процессе работы. Например, добавятся или удалятся элементы.

Когда данные передаются в функцию, способ их обработки зависит от типа. Например, для неизменяемых чисел создается независимая копия. Следовательно, любое преобразование внутри функции не повлияет на исходное число. И наоборот, вместо изменяемого списка передается указатель на то место в памяти, где он хранится. Таким образом, все трансформации повлияют на внешний объект.

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

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

Хеширование

Хеш-таблицы – это особые структуры данных, подобные ассоциативным массивам. Ключами в них могут выступать не только числа, но и другие объекты. Однако есть одно важное условие. Для каждого ключа требуется вычислить особый уникальный код. Этим занимаются специальные функции.

Хеш-функции получают на входе данные разного объема, а возвращают хеш фиксированной длины. Набор данных может пройти через такую функцию много раз, но результат для него будет одинаковым. И наоборот, для наборов, отличающихся хотя бы одним символом, коды всегда разные.

Не каждую порцию данных можно хешировать. Возьмем, например, список, изменяющийся в процессе работы программы. В разные моменты времени его хеш будет разным.

Часто говорят, что изменяемые объекты Python в принципе нельзя хешировать, а неизменяемые – всегда можно. На самом деле, возможность хешировать объект и его неизменяемость – понятия разные.

Лучше разобраться в концепции поможет видео:

Виды строк

Оперировать строками в Python – одно удовольствие, так как язык предоставляет для них множество удобных методов. Также имеется поддержка «сырых» строк и строковых литералов.

Чтобы строка стала «сырой», перед ней необходимо поставить символ r в любом регистре:

В такой строке отключается экранирование. Это значит, что обратная косая черта считается самостоятельным символом. Основное применение сырых строк – работа с регулярными выражениями.

Строковые литералы заключаются в тройные кавычки или апострофы. С их помощью удобно обрабатывать большие блоки текста, например, HTML-код, так как их можно разбить на несколько строк. Экранирование кавычек внутри литерала не требуется.

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

Лямбда-выражения

Лямбды пришли в Python из языка Lisp. Это простые анонимные функции, записанные в одну строку. Их можно объявить даже там, где нельзя воспользоваться инструкцией def . Например, эти выражения часто используются в методах filter и map .

Списки

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

Вот небольшая задачка по python-спискам для тренировки мозга:

Определите, что находится в каждой переменной, и сравните свои предположения с ответом.

Если эти преобразования вам непонятны, потратьте на них немного времени.

Итераторы и генераторы

Итератор – это интерфейс, который позволяет перебирать элементы последовательности. Он используется, например, в цикле for . in . , но этот механизм скрыт от глаз разработчика. При желании итератор можно получить «в сыром виде», воспользовавшись функцией iter() .

Чтобы получить следующий элемент коллекции или строки, нужно передать итератор функции next() .

Под капотом функциональность реализуется в методах __iter__ и __next__ .

Пример простого итератора:

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

В этом примере из списка чисел отбираются четные, а в финальную коллекцию вносятся их квадраты.

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

Очевидно, что генераторы могут выполнять работу функций map и filter . Более того, они справляются с этой задачей эффективнее.

*args и **kwargs

Иногда нельзя предсказать, сколько аргументов получит функция. Чтобы обработать их, используются специальные конструкции *args и **kwargs.

На самом деле, названия переменных – args, kwargs – это просто соглашение. Важны здесь только звездочки. Они обозначают сборку аргументов в коллекцию (список или словарь). Одна звездочка предназначена для обычных аргументов, две – для именованных.

Можно заменить *args на *vars, а **kwargs на **options или другое слово. Программа будет работать так, как ожидается. Однако, другие разработчики могут вас не понять.

Конструкции *args и **kwargs можно использовать как самостоятельно, так и в комбинации с любым количеством обычных аргументов. Например, в коде выше первый параметр farg обрабатывается отдельно, а все остальные собираются в коллекцию.

Декораторы

Функции и классы в Python – объекты удобные. Они сами могут быть входящими и исходящими аргументами функций. Это свойство можно использовать, чтобы сделать жизнь разработчика немного приятнее.

Смысл паттерна Декоратор заключается в том, что некоторая функция заворачивается в другую функцию, приобретая от нее новые возможности. Например, так можно вести логи, вводить пред- и постусловия, добавлять методы для классов.

Декораторы в Python – это, по сути, синтаксический сахар. Для их обозначения используется символ @ .

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

Изначально функция sandwich только печатает начинку, а затем она становится полноценным бутербродом. То же самое можно сделать чуть проще:

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

В Python есть несколько встроенных декораторов, например, @classmethod , @staticmethod , @property .

Исключения

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

В Питоне определен главный класс BaseException, от которого наследуются все остальные классы ошибок. У него есть четыре прямых наследника:

  • SystemExit – произошел выход из программы.
  • KeyboardInterrupt – пользователь прервал выполнение программы (комбинация Ctrl+C).
  • GeneratorExit – завершена работа объекта generator.
  • Exception – родительский класс для пользовательских исключений.

От класса Exception наследуется больше десятка различных ошибок, которые может обработать программист. Вот лишь некоторые из них:

  • IOError – ошибка ввода-вывода, например, «файл не найден».
  • ImportError – ошибка импорта модуля.
  • IndexError – обращение к несуществующему индексу последовательности.
  • OSError – ошибка системы.
  • SyntaxError – синтаксическая ошибка.
  • TypeError – ошибка типа данных, например, функция вызывается с неподходящим по типу аргументом.
  • ZeroDivisionError – деление на ноль.

Чтобы поймать и обработать исключения, нужно использовать конструкцию try – except – finally .

В блоке try размещается код, который должен быть выполнен. Блок except дает возможность поймать и обработать нужные ошибки. При необходимости можно добавить еще инструкцию finally , которая выполнится в любом случае.

В Python изначально заложена поддержка ООП, метаклассов, наследования, включая множественное, и инкапсуляции.

Пример наследования в Python:

В коде определяется родительский класс Animal с базовой реализацией методов say() и swim() . У Animal есть два наследника: Cat и Dog .

Дочерние классы дополняют методы родителя собственным поведением. Чтобы сделать это, им приходится вызывать метод суперкласса с помощью функции super() .

Класс CatDog демонстрирует пример множественного наследования в Python. Он берет лучшее от обоих родителей: плавает как Dog и говорит на двух языках.

5 вопросов о Python-технологиях

Потоки

Вопрос о потоках – один из самых животрепещущих в сообществе. Поэтому вполне можно ожидать, что он прозвучит на собеседовании по Python.

Работа нескольких потоков иногда заканчивается конфликтом. Чтобы защититься от этого, CPython использует технологию Global Interpreter Lock.

Глобальный блокировщик следит за тем, чтобы активен был всегда только один поток. По сути, он просто запрещает параллельность. Хотя такой подход очень упрощает работу, он фактически убирает все преимущества многопоточной модели. Например, нельзя ускорить программу, разделив один поток на несколько. Python-сообщество неоднократно просило убрать GIL, однако, создатель языка решил оставить все как есть.

Впрочем, иногда потоки нужны. Например, на них можно переложить загрузку файлов с сервера. Для этого в Python используется модуль threading.

Код ниже демонстрирует добавление функции clock в поток.

Асинхронность

Асинхронность – еще один способ выполнения нескольких задач сразу. Она предлагает решать проблему с помощью функций обратного вызова (callback).

Встретив в коде блокирующий запрос, интерпретатор вешает на него сигнальный маячок и идет дальше. Когда запрос завершится, маячок подаст сигнал. В этот момент обработчик вернется, получит результат и вызовет коллбэк.

В Python есть несколько асинхронных библиотек. Самые популярные из них – стандартная AsyncIO и Tornado.

В последних версиях языка появились новые синтаксические конструкции async и await.

Тестирование

В Python есть стандартный модуль unittest. Он позволяет объединять тесты в группы, настраивать и автоматизировать их. Дополнение Mock дает возможность использовать mock-объекты, что облегчает тестирование.

Отладка

Python-код можно и нужно отлаживать. Для этого в языке есть специальный интерактивный дебаггер pdb.

Расширения на C/C++

Интерпретатор CPython позволяет внедрять в программы расширения, которые написаны на C и C++. Разработчик может оптимизировать код и пользоваться библиотеками языка C. Кроме того, можно управлять ресурсами на низком уровне.

Другие вопросы

Список из 15 вопросов по Python не является исчерпывающим.

Многое зависит от специфики компании, которая проводит интервью. Где-то требуется знание популярных фреймворков, например, Django. В другом месте важно понимать основы взаимодействия с базами данных.

Тем не менее вопросы охватывают большую часть знаний, которые нужны разработчику. Разобравшись в них, вы улучшите свои шансы на успех.

Вероятно, вам предложат задачи по Python. Чтобы решить их, нужна не только хорошая теоретическая подготовка, но и практика. Начните с простых упражнений и постепенно поднимайте свой уровень.

Вопросы на собеседовании программисту Python

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

НИКОГДА НЕ ДАВАЙ СИНТЕТИКУ И НЕ СУДИ ПО АЛГОРИТМУ! Исключение — простейшие алгоритмы(фазз-базз). Человек может растеряться, забыться и много где ошибиться и наговорить чуши. Помните главное: программисту всегда нужен интернет. Если он решает задачу с интернетом, значит и решит в реальных условиях. Твоя задача — посмотреть на конечное решение, на код, его качество, анализ кода самим программистом, считает ли он, что функцию нужно переписать и как срочно, какие у него мысли. Он может говорить чушь и бред, потому как гики застенчивы и на собеседовании врубают /dev/brain > /dev/voice, твоя задача — понять что да как, создать нормальную обстановку etc.

Мастер Йода рекомендует:  Копирайтер - новая профессия в Интернет

О чем спросить питониста

Введение

Пару месяцев назад я сменил работу в московском офисе на удаленную работу в Toptal. Это был абсолютно новый для меня опыт, потому что мне еще не доводилось работать с американскими клиентами. Больше всего меня беспокоил языковой барьер, но по прошествии времени могу сказать, что навыки коммуникации быстро приобретаются при наличии практики и желания.

Подробнее об этом я наверно напишу в другом посте, а сейчас я хотел бы поделиться списком понравившихся мне вопросов с собеседований в различным московских компаниях. Я отобрал самые каверзные, многие из них вызвали у меня затруднения (наверное поэтому-то они мне и запомнились 🙂), так что будем считать это работой над ошибками.

Что такое meta-классы в Питоне и зачем они нужны?

Metaclasses are deeper magic than 99% of users should ever worry about. If you wonder whether you need them, you don’t.

— Tim Peters

Я, пожалуй, не буду копировать Интернеты и просто оставлю здесь несколько ссылок (потому что мне больно говорить об этом) :

  • Первым на помощь нам спешит Хабр: Метаклассы в Python
  • Хабровчане по своей старой привычке не указывают ссылки на оригиналы статьей. Вот она: All about the metaclasses in Python!
  • Очень хороша статья на PyPix: Metaprogramming in Python, она посвежее и лучше оформлена, а в конце есть множество ссылок на другие статьи по данной теме.
  • А началось все с вопроса на StackOverflow!

Да, и не путайте meta-классы в Питоне с классом Meta в Django…

… как это сделал я!

Декораторы методов и классов в Python

Декораторы методов выступают в качестве “патчей”, который позволяют расширять поведение метода новыми возможностями. Звучит очень похоже на наследование, но технически все реализовано немного по другому.

Про декораторы классов информации мало, хотя они мало чем отличаются от декораторов методов и функций.

Вообще, про декораторы меня спрашивали практически везде, потому что это один из основных элементов языка, поэтому советую вам детально и ними разобраться.

Генераторы, итераторы и оператор yield

В питоне есть возможность итерировать объекты не загружая их все в память. Хорошим примером здесь являются функции близнецы range и xrange :

В данном случае range вернул нам список из чисел от 0 до 2, а xrange вернул нам генератор чисел от 0 до 2. Преимущество генераторов в том, что мы можем загружать объекты в память по мере необходимости, а не все сразу.

  • Jeff Knupp написал отличную статью на эту тему.
  • Старая, но еще актуальная статья на Хабре.

__slots__ для экономии память

В одном месте меня спросили про то, как можно сэкономить память при создании множества однотипных объектов. Как выяснилось, речь шла о переменной класса __slots__. Статей толковых про __slots__ я не встречал, потому что на практике это редко встречается.

Суть __slots__ можно продемонстрировать следующим примером:

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

Вот что есть из доступных статей на эту тему:

Помимо __slots__ есть еще named tuples. Такой подход более распространен.

Модули threading and multiprocessing

Вопросы про потоки и процессы я слышал неоднократно, поэтому советую обратить на них особое внимание. Вопрос состоит из двух частей: понимание потоком и процессов в Unix в целом и интерфейс для работы с ними в Python.

Unix лучше изучить весь и стразу, потому что фундаментальные знания тоже очень важны. На английском языке могу посоветовать Linux System Programming: Talking Directly to the Kernel and C Library, эта книга имеет вменяемый объем и покрывает все основные аспекты.

Об интерфейсах в Python лучше читать в официальной документации:

В чем отличие open and fopen?

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

Что такое менеджеры контекста и как ими пользоваться?

Менеджеры контекста впервые появились в Python 2.5 с добавлением нового ключевого слова with (PEP 343). with можно сравнить с декоратором, который применяется для блоков кода. Суть этого оператора демонстрирует следующий пример:

На практике очень прижился вариант с open для работы с файлами:

Сам я писал свои менеджеры контекста всего пару раз, это не что то встречается повсеместно. Вот пара ссылок с их развернутым описанием:

Какие структуры данных в питоне вы знаете и применяли на практике?

Тема про структуры данных, конечно, безграничная. В Python есть базовые структуры данных, типа tuple, list, dict, set, они используются везде и наверняка вы с ними знакомы. Сложность различных операция над этими структурами данных можно посмотреть здесь.

Еще есть стандартная библиотека, и модуль collections в частности, там есть deque, Counter, OrderedDict, defaultdict и др. Ну и разумеется, никто не запрещает написать что-нибудь свое или стащить чужое (GitHub вам в помощь) :).

Если говорить о более продвинутых структурах данных, то могу порекомендовать эту статью. Также, настоятельно рекомендую почитать Кормана, что бы лучше понимать откуда ноги расту. Эта книга очень популярна у Javистов и Сишников, а вот питонисты её незаслуженно обходят стороной. А зря, очень хорошая книга! …хотя местами нудная

Что нового в Python 3?

Версия питона 2.7 является завершающей и дальнейшее развитие второй версии языка не планируется, поэтому многие компании начинают активно присматриваться к третьей версии. Именно присматриваться, потому что реально на третью версию питона перешли единицы. Сам я только пару раз использовал Python 3, причем это всегда были небольшие тестовые проекты.

В Python 3 появились новые структуры данных, print стал функцией, input() убрали совсем, все строки теперь в Unicode и многое другое, но самое важное это то, что третья версия не имеет обратной совместимости со второй. Поэтому…

Первым делом лучше проверить Python 3 Wall of Superpowers, там находится список популярных библиотек, которые уже портированы на Python 3. Многие уже портированы, но вот некоторые зависли в неопределенном положении. Если вы не нашли своей любимой библиотеки, то придется искать аналог.

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

  • Полный список изменений доступен в официальной документации
  • Видео доклад Павла Зановкина, Миграция на Python 3
  • Знакомство с Python 3: Часть 1. Что нового в новой версии
  • Отдельно хочется отметить модуль asyncio и оператор yield from , который появился в версии 3.4
  • Видеодоклад Feihong Hsu Asynchronous I/O in Python 3 )

Цепи Маркова и машинное обучение

На собеседовании в Mail.RU меня попросили написать генератор бреда. Для этого нужно было использовать Цепи Маркова N-го порядка. С проектом я успешно справился и даже выложил его в открытый доступ.

Это был самый запоминающийся проект, ведь не каждый день интересуются твоими знаниями в машинном обучении и теории вероятности.

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

Протокол HTTP

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

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

Как вводная, очень хороша статья на tuts+ HTTP: The Protocol Every Web Developer Must Know (Part 2). Подробное описание протокола можно прочесть в RFC2616, сам я правда его так и не прочел.

Еще есть довольно старая книга HTTP: The Definitive Guide с хорошими отзывами. Мне её тоже пару раз рекомендовали к прочтению.

Заключение

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

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

Ну и на последок еще одна ссылка на книгу Cracking the Coding Interview: 150 Programming Questions and Solutions, которая напрямую рассказывает о всех хитростях прохождения технических собеседований.

Вопросы на python-собеседовании

Накидайте вопросов, которые вам задавали или вы задаёте при собеседовании на python-программиста.

Вопросы с собеседований нужны чтобы получить представление и готовиться. Хотел бы освоить python (скорее подтянуть, т.к. что-то я уже знаю) и походить по себеседованиями.

Я не совсем тот, кого ты ищешь, но на, поготовься:

Разверни строку ‘pylesos’.

Поменяй местами значения двух переменных.

Выведи все простые числа менее N, N вводится с клавиатуры. Сократи теперь решение до одной строки ★★★★★ ( 16.03.19 12:41:51 )
Последнее исправление: t184256 16.03.19 12:43:04 (всего исправлений: 1)

Мы Вам перезвоним.

«вывести все спряжения французского глагола, не имеющие с оригинальным глаголом ни единой общей буквы»

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

во-первых, что значит «оригинальный»? во-вторых, всегда казалось, что форму неправильного глалога по определению невозможно синтезировать программно. на то он и irregulier. в-третьих, если во французском языке есть глагол, ни одно из спряжений которого не имеет ни одной буквы, общей с инфинитивом этого глагола, то проще бы этот назвать всё таки назвать.

Согласен, фигню сочинил. Имелось в виду «с введенной формой глагола», но и инфинитивная сойдет. Вопрос не о том.

форму неправильного глалога по определению невозможно синтезировать программно.

Вопрос как раз об этом. Я заказчик, такова моя задача, и мне плевать на твои «невозможно». Твои действия?

если во французском языке есть глагол, ни одно из спряжений которого не имеет ни одной буквы, общей с инфинитивом этого глагола

Не то. «Если во французском языке есть спряжения, не имеющие ни одной буквы, общей с инфинитивом этого глагола». Есть.

то проще бы этот назвать всё таки назвать.

М? Типа это уже кто-то подметил и запостил? А мне вот интересно, как эти pieces of trivia найти не вручную, причем побольше.

Держи с собеседования на сисадмина в известную ИТ компанию в России. Питон сисадмина надо знать на уровне «помнить все методы всех встроенных типов», множества и работа со словарями.
1. Найти дубликаты в массиве. Переписать с циклами. Переделать с линейной сложностью алгоритма.
2. Найти максимальные длины последовательностей одинаковых символов.
3. Даётся массив с именами файлов. Сортировка, если числа в названии, по убыванию, а потом буквы по возрастанию.
4. В файле заменить последовательности пробелов и табуляций одним пробелом — без регулярок.
5. Есть массив состоящий из кортежей положительных целочисленных координат. типа [ (2,5), (1,6), (1,8), . ]. Нужно определить, существует ли вертикаль, которая делит все точки на плоскости. Сделать линейную сложность алгоритма.
6. Есть 2 массива, состоящие из кортежей — отрезков времени нахождении в сети 2-х пользователей, массивы отсортированы по возрастанию. Нужно найти отрезки времени, когда они в сети были одновременно. Сделать линейную сложность алгоритма.
Все задачи на время по 10-15 минут.

Программистов наверно спрашивают серьёзнее.

Накидайте вопросов, которые вам задавали или вы задаёте при собеседовании на python-программиста.

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

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

Для меня непринуждённость собеседования стала определённым маркером адекватности конторы. Не единственным и не решающим, но весомым. Подумай об этом на досуге.

Так иди же. Сразу получишь представления о том, что спрашивают, от первых лиц, а не на форуме через сарафанное радио.

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

гнали какую-то пургу, или ментально прессовали

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

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

также не без помощи испытуемого, собеседующий смог таки со второго раза сформулировать вопрос по-русски.

лол, да такие есть и что, тоже мне открытие.

Накидайте вопросов, которые вам задавали или вы задаёте при собеседовании на python-программиста.

1. Почему вы выбрали Python в качестве языка программирования? Как давно вы на нём пишете?

2. Какие ещё языки вы знаете? На каких писали?

3. Какие особенности Python по сравнению с другими языками?

4. Для каких задач Python подходит, а для каких нет, по вашему мнению?

5 Что вы любите в Python? А что не любите?

Это если собеседование на программиста, а не макаку, конечно.

нужно на 100% знать грамматику французских глаголов (причем формализовано, как лингвист, а не как франкофон). тогда можно разработать корректную программу, которая это покажет. (мое знание ограничивается годовым курсами французского когда-то очень давно. не буду претендовать на истину.)

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

это знают только те, кто пишет и продаёт французские конжугаторы. т.е. это сумма
1) программной логики, основанной на формализованной грамматике языка
плюс 2) вручную формируемой БД, которую кстати компания считает активом
плюс 3) рутин синтеза нужный формы.

ты не прав. ты не имеешь права спрашивать такое на собеседовании у программиста. тут можно вежливо заканчивать и уходить от самоуверенного мудака.

Не, в молоко. Спрашивают более-менее близко к тому, что набросал t184256 . Хоть он местами и серьёзно перефантазировал.

Я давно уже научился просто вставать и уходить с таких собеседований.

Да, вероятно, это самый правильный сценарий развития такого собеседования. Была одна контора с офисом в моей деревне, специализирующаяся на разработке игр. Сначала я резюме им выслал, потом тестовое задание на юнити сделал, потом пришёл на собеседование. И как-то вот разговор зашёл про то, какие я pet-проекты делал. И я рассказал про один из них, про то, что он был на OpenGL 1.1 (давно дело было) и как там рендер был устроен. На что мне собеседующий говрит, мол, так нельзя было делать, оно работать не будет. Я ему на это отвечаю, мол, ну почему же, вот такие-то и такие-то доводы, можете погуглить, а вот на моём ноуте смотрите работает и не только на моём и не только на ноуте, а вот вам ещё исходники — гляньте, говорю. А он ничего смотреть не хочет, рогом упёрся и утверждает, что оно так работать не может и всё. Ну ок, говорю, не может так не может.

Имелось в виду «с введенной формой глагола», но и инфинитивная сойдет.

собеседующий сам понял, что имел ввиду инфинитив.

и этот человек будет рассуждать о понимании.

лол, да такие есть и что, тоже мне открытие.

я и не претендую на Нобелевку в лингвистике, я спрашиваю у ТС, как найти их на Python.

ты не прав. ты не имеешь права спрашивать такое на собеседовании у программиста. тут можно вежливо заканчивать и уходить от самоуверенного мудака.

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

20 вопросов и ответов из интервью на позицию Python-разработчика

Новости собираются с мира по нитке на совершенно безвозмездной основе.
Ты легко можешь посодействовать проекту, добавив ссылку на интересную новость, статью, интервью или проект о python.
А еще можно форкнуть код этого проекта на Github и помочь в развитии его функциональности.
И еще один вариант — проголосовать рублем

Мастер Йода рекомендует:  Как узнать по каким запросам находят мой сайт в поисковых машинах

Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»

За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.

Экспериментальная функция:

Ниже вы видите текст статьи по ссылке. По нему можно быстро понять ссылка достойна прочтения или нет

Просим обратить внимание, что текст по ссылке и здесь может не совпадать.

Введение

За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.

Общие идеи

Это действительно так. Это связано с тем, что многие тимлиды/тех.директоры не знают, что именно они хотят видеть в middle-разработчике. Поэтому на таких собеседованиях обычно просят

«написать сортировку пузырьком на любом языке»

Так же мало кто понимает, чем junior-разработчик отличается от middle-разработчика. Кто-то говорит, что middle – это разработчик с опытом от полутора лет, а кто-то — от трёх. В моём понимании middle-разработчик — это тот разработчик, которому можно смело отдать небольшой проект или какую-либо часть крупного проекта, и чтобы именно он был за неё ответственен. Также важным критерием для middle-разработчика является умение быть наставником для кого-либо или просто умение помогать внедриться новому сотруднику в проект.

Собеседование — это не экзамен, а возможность выявить насколько компания и кандидат подходят друг другу.

Это важное правило часто не понимают сами работодатели. Однажды я был на собеседовании, где меня заставили тянуть билет и отвечать перед собеседующим на листочке. При этом на протяжении всего этого собеседования мы общались десять минут. Такое же поведение часто прослеживается со стороны кандидата. Часто кандидат хочет на всё ответить и ведёт себя как отличница с первой парты. Но тут тоже важно понять, что работодателю не особо интересно насколько хорошо Вы знаете

«отличие Python2 от Python3»

. Гораздо важнее для работодателя понять в целом как ты держишься на собеседовании, как рассуждаешь, как реагируешь на неудачи и т.д.

Middle-разработчиком нельзя стать без опыта.

Конечно, можно, но это повлечёт через какое-то время огромные неприятности как для начальника этого разработчика, так и для проекта. Для слишком одарённых кандидатов без опыта у HR-специалистов есть свой термин – «strong junior-разработчик». Скорее всего таким разработчикам будет предложена неплохая денежная компенсация, но обязанности у них будут как у junior-разработчиков. Возвращаясь к middle-разработчикам хочется отметить, что middle — это тот, кто хоть какое-то время проработал в разработке и понимает из каких процессов она состоит. Также middle умеет работать с различными инструментами(мониторинг, деплой, профилирование, тестирование) с которыми человек без опыта вряд ли сталкивался в учебных целях.

На позицию Middle-разработчика soft skills становятся важным фактором.

Чем выше должность, тем с большим количеством людей приходится взаимодействовать. Поэтому очень часто при приёме на позицию middle-разработчика создаются дополнительные собеседования с HR-специалистом для составления психологического портрета будущего сотрудника. К этому собеседованию надо относиться также серьёзно, как и к техническому. Надо понимать, что Вам дальше работать с этими людьми. И если Вы чувствуете, что Ваши будущие коллеги Вам не очень подходят, то лучше сразу отказаться от дальнейшего сотрудничества.

На позицию middle-разработчика реже дают тестовые задания .

Это утверждение достаточно субъективное. Лично я действительно столкнулся с таким фактом. Связываю это с тем, что работодателя больше интересует твоё резюме. Если резюме составлено неважно, то скорее всего следует ждать тестового задания.

Вопросы

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

1. Как дела с тестированием? Какие тесты вы пишете? Какие библиотеки для тестирования вы используете? (фабрики, моки и т.д.)

Тестирование – очень важная часть любой разработки. В моём понимании, тесты должны писать все разработчики хотя бы в каком-то виде. Единственное, кому можно простить отсутствие тестов – это стартапы. В стартапах часто меняется

из-за чего старые проекты обычно бывают никому не нужны. А значит обеспечение качеством таких проектов было впустую потраченным временем. Для всех остальных компаний пощады в этом вопросе быть не должно. Нужно понимать, что внедрение нового сотрудника в проект на первых порах будет приводить к различным ошибкам в коде. И тесты в данном случае является его личной перестраховкой и перестраховкой того, кто будет выливать его решения в production.

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

Стоит отметить, что на этом вопросе технические специалисты часто начинают теряться. Кто-то иногда говорит, что команда только начала заниматься написанием тестов и еще не знакома со всеми тонкостями этого ремесла. Но иногда я слышал вот такой ответ:

«Тестами должны заниматься тестировщики, а разработчик должен творить».

Это абсолютно неверно.

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

2. Что делает разработчик с кодом перед тем, как отправить его в репозиторий?

Под этим вопросом понимается локальная проверка своего кода по различным параметрам. Вот небольшой список того, чем обычно проверяют код перед отправкой в репозиторий:

  • Flake8 – анализ кода на соблюдение PEP8,
  • Pylint – статический анализ кода,
  • Coverage – анализ кода на тестовое покрытие,
  • Tox – проверка кода на совместимость с различными версиями отдельных пакетов и с разными версиями Python.

Отсутствие данного кейса в разработке не является критичным. Также во многих компаниях этот кейс используется непосредственно в CI, и разработчик локально у себя ничего не запускает. Даже если это не используется в разработке, то было бы неплохо, чтобы люди, которые Вас собеседуют имели базовые представление об этих инструментах.

3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?

Этот вопрос не имеет никаких подводных камней и задаю я его чтобы получше понять устройство компании. Если в проектах нет CI/CD и DevOps-инженер тоже отсутствует, то есть вероятность что именно Вы будете этим заниматься. Поэтому этот момент тоже лучше обсудить на собеседовании.

4. Есть ли Code Review? Как оно проходит?

Первую часть вопроса можно оставить без комментариев, потому что все понимают важность этого мероприятия. Но стоит отметить что лично меня интересовало как именно оно проходит. Чаще бывает так, что каждый из команды ревьюит разработчика который сделал Merge Request. Но иногда встречается, что над любым разработчиком есть ментор/наставник и именно он ревьюит разработчика. Первый подход считаю более правильным, так как чем больше людей ревьюит код, тем лучше для проекта и для команды. Здесь сразу затрагиваются такие аспекты, как командное взаимодействие, коллективная ответственность, увеличение

5. Какую систему контроля версий Вы используете?

На данный момент в России существует немало компаний, которые до сих пор использует

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

и особого удовольствия мне это не доставило.

6. Используете ли вы git/hg-flow или какую-либо определенную методологию при работе с git/hg?

Данный вопрос вытекает из предыдущего вопроса о системах контроля версий. Поэтому если команда не использует

, то и задать его нет смысла. Если же компания использует

, то этот вопрос Вам сможет показать насколько хорошо отлажен процесс разработки.

7. Используете ли Вы методологию разработки (scrum, kanban и т.д.)?

В разработке важно придерживаться какого-то определённого подхода(методологии). Самый популярный подход в разработке – итеративный. Такой подход позволяет определить Ваш вклад в проект. В моём понимании, если в команде используется какая-то методология – это однозначно хорошо. Это позволяет Вам определить Вашу эффективность. Также это помогает понимать Вам сроки выделенные на задачи. Это всё равно что у школьников есть 4 четверти в году, где им выставляют отметки, чтобы потом определить итоговую оценку за год.

8. Используются ли системы мониторинга в проектах(Sentry, NewRelic и т.д.)?

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

9. Используется ли в проекте система для хранения логов и работы с ними(ELK-технология и прочее)?

Для меня это тоже является важным показателем. Если ELK отсутствует, то очень трудно определить причину появления сложной ошибки в системе. Данный вопрос не настолько важен, как вопрос №8, но его тоже стоит задать чтобы понять насколько богат опыт у команды в профилировании сложных ошибок.

10. Какие БД используются в проекте? Почему именно такие?

Данный вопрос направлен на то, чтобы оценить компетентность собеседующего. Очень часто при использовании старых БД слышу что-то вроде «так сложилось исторически». Такой ответ считаю неуместным. Технический специалист должен понимать минусы/плюсы используемой им БД. Этот вопрос следует задавать только в том случае, если Вы сами неплохо разбираетесь в различных БД и их отличиях.

11. Какая версия языка Python используется в проектах? Если используется версия Python2.x, то планируется ли переход на Python3.x? И как будете происходить миграция с одной версии на другую?

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

12. Компания ищет fullstack-разработчика или backend-разработчика?

Этот вопрос я задаю только в том случае, если компанию это сама не уточнила перед собеседованием. Вакансии fullstack-разработчика на рынке труда можно встретить довольно часто. Многие компании считают это выгодным для себя. Мой личный опыт говорит мне что fullstack-разработчиков не бывает, так как frontend и backend стали слишком разными направлениями с того момента как появился Веб. Иными словами, «На двух стульях не усидишь».

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

13. Используется ли технология контейнеризации в проектах?

Этот вопрос является дополнением к вопросу №3.

14. Немного поспрашивать собеседующего о том, чем он занимался до этого проекта и давно ли он в проекте.

Этот вопрос очень важен. Чем богаче опыт вашего собеседующего, тем больше это отразится на ваших умениях и навыках через какое-то время. Особенно хорошо задавать такой вопрос в небольшой компании, где медленная текучка кадров.

15. Существует ли в компании годовая/квартальная оценка сотрудников и как она происходит?

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

16. Есть ли у в компании переработки? Если есть, то компенсируются ли они и как часто они происходят?

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

17. Насколько в компании сильна бюрократия? (Оцените от 1 до 10)

Многие разработчики даже не догадываются о присутствии бюрократии в IT-сфере, но, к сожалению, она есть. Особенно это относится к крупным старым компаниям или к компаниям, которые работают с гос. заказами. Степень бюрократии в компании зависит только от фантазии руководства. Обычно бюрократия заключается в различных формальных заявках, визированиях, доступах, конфликтах интересов между несколькими подразделениями компании и написании скучной сырой документации в Word. Главная проблема такой бюрократии – это очень сильное торможение процесса разработки. То что в нормальной компании делается за один рабочий день, тут на это будут уходить недели. Проще говоря, чем сильнее бюрократия в компании, тем медленнее развитие продукта и Ваше развитие как специалиста.

18. Как обстоят дела с выбиванием ресурсов?

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

19. Как собеседующий относится к новым внедрениям в проекте?

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

20. Является ли компания участником каких-либо IT-конференций и есть ли у компании публикации на IT-темы?

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

21. Есть ли митапы внутри компании?

Здесь речь пойдет о митапах у разработчиков внутри команды или между командами. Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших

22. Есть ли в компании стажёры и развита ли система наставничества?

Стажёры – это потенциальное будущее компании. Если в компании есть стажёры, то возможно Вы сможете быть для них наставником и делиться своим личным опытом. Наставничество – это тоже одно из направлений где Вы сможете развиваться.

Заключение

Всё вышесказанное является моими мыслями, основанными на личном опыте и не является 100-процентно верной информацией. Главная мораль статьи заключается в том, что проверять надо не только кандидата, но и работодателя. Также не стоит нервничать перед собеседованиями или на собеседованиях. Надо понимать что собеседующие такие же люди как и Вы, которые тоже ошибаются или чего-то не знают или не понимают.

Дзен питона на русском

Разработчики языка Python придерживаются определённой философии программирования, называемой «The Zen of Python» («Дзен Питона», или «Дзен Пайтона»). Её текст выдаётся интерпретатором Python по команде import this (работает один раз за сессию).

В целом она подходит к программированию на любом языке.

Текст философии

  • Красивое лучше, чем уродливое.
  • Явное лучше, чем неявное.
  • Простое лучше, чем сложное.
  • Сложное лучше, чем запутанное.
  • Плоское лучше, чем вложенное.
  • Разреженное лучше, чем плотное.
  • Читаемость имеет значение.
  • Особые случаи не настолько особые, чтобы нарушать правила.
  • При этом практичность важнее безупречности.
  • Ошибки никогда не должны замалчиваться.
  • Если они не замалчиваются явно.
  • Встретив двусмысленность, отбрось искушение угадать.
  • Должен существовать один и, желательно, только один очевидный способ сделать это.
  • Хотя он поначалу может быть и не очевиден, если вы не голландец [^1].
  • Сейчас лучше, чем никогда.
  • Хотя никогда зачастую лучше, чем прямо сейчас.
  • Если реализацию сложно объяснить — идея плоха.
  • Если реализацию легко объяснить — идея, возможно, хороша.
  • Пространства имён — отличная штука! Будем делать их больше!

Автор этой философии — Тим Петерс. Оригинал на английском:

Отсылка к нидерландскому программисту, создавшему язык Python, Гвидо ван Россуму (нидерл. Guido van Rossum).

Добавить комментарий