Python-разработчик: что должен знать и как им стать
Кто такой Python-разработчик? Рассказываем все о сфере Python-разработки: вникаем в процессы и задачи специалиста, какие навыки нужны для каждого грейда и как стать Python-разработчиком с нуля.
Python является популярным и активно развивающимся языком программирования. Придуманный нидерландским программистом Гвидо ван Россумом более тридцати лет назад, Python, на сегодняшний день возглавляет рейтинг языков программирования по данным индекса популярности TIOBE.
В чем заключается секрет его популярности?
По сравнению с другими языками, Python считают простым для понимания, дружелюбным языком даже для новичков, совершающих первые шаги в области программирования. Одним из главных принципов Python является легко читаемый синтаксис, позволяющий изучить его быстро.
Несмотря на гибкие и понятные инструменты, Python остается многофункциональным языком, на котором можно создавать сложные проекты и сервисы с высокой нагрузкой. Такие компании, как Intel или HP, используют Python для тестирования аппаратного обеспечения, а Pixar – для создания анимации в мультипликационных фильмах.
В связи с популярностью языка Python в различных областях и компаниях, рынок труда наполнен предложениями для Python-разработчиков, даже Junior специалисты сегодня могут рассчитывать на стартовую зарплату в 100 тысяч рублей.
В первую очередь Python-разработчику необходимо владеть синтаксисом языка, правилами и командами, также важно изучить хотя бы одну, а лучше несколько библиотек, использующихся в интересующей для разработчика сфере (например, Django для веб-разработки). Большим преимуществом будет и понимание принципов ООП, так как Python является объектно-ориентированным языком.
Как и для любого другого языка, задачи для Python-разработчика и навыки, необходимые для их решения, зависят от квалификации. Давайте познакомимся с навыками для каждого грейда ближе:
Junior (начинающий специалист с опытом от 0 до 12 мес)
Как мы уже писали ранее, Python – язык программирования с низким порогом входа, поэтому базовых навыков владения языком, будет достаточно, чтобы претендовать на должность Junior-разработчика и начинать работать. На начальном этапе разработки задачи касаются сферы, которую начинающий разработчик выбрал для старта карьеры.
Middle (специалист среднего уровня с опытом от 2 до 3 лет)
От претендентов на должность Middle-разработчиков ожидают тех же базовых навыков с более высоким уровнем владения Python. В процессе работы также могут потребоваться дополнительные навыки и языки, зависящие от выбранной IT-сферы (например, применение метода статистического анализа в области аналитики данных или знание другого языка программирования в области веб-разработки).
Senior (специалист с опытом от 5 лет)
Помимо знания языка Python в претендентах на должность Senior-разработчиков ожидают увидеть и лидерские качества, так как нередко такие специалисты распределяют задачи между членами команды, принимают стратегические решения и выстраивают проекты с нуля. На продвинутом этапе разработки требуются самый высокий уровень владения языком Python и другими языками, а также более глубокие познания в выбранной сфере (например, знание матанализа, теории вероятностей и статистики для аналитики данных).
Владение языком Python даёт возможность работать в маркетинге, веб-разработке, бизнес-автоматизации и аналитике данных, ставшей крайне популярной среди разработчиков в 2022 году. Работа и задачи Python-разработчика в первую очередь зависят от выбранной им сферы.
Аналитик данных на языке Python структурирует информацию, тестировщик ПО – создаёт автотесты, повышая скорость своей работы, а веб-разработчик – создает сайты и приложения. Стоит отметить, что с Python чаще работают для backend-разработки, хотя многофункциональность этого языка программирования позволяет пользоваться им и для frontend-разработки.
Python отлично подходит для начала карьеры в области программирования. Как мы уже писали выше, знания синтаксиса языка и хотя бы одной библиотеки достаточно для карьерных начинаний в некоторых крупных компаниях, среди которых, например, «СберБанк» и «МТС».
Количество предложений для Python-разработчиков продолжает расти, начинающие специалисты могут выбрать привлекательную для них сферу. В 2022 году сайт hh.ru предлагает более 1,5 тысяч вакансий, помимо тех, в которых владение Python не является единственным основным запросом для работы.
Зарплата Python-разработчика зависит от опыта и региона. В Москве и Санкт-Петербурге зарплаты выше, однако и регионы не отстают, средняя зарплата по всей стране, согласно исследованию «Хабр.Карьеры», составляет 140 тысяч рублей. Разработчики уровня Senior могут претендовать на заработную плату в 300-450 тысяч рублей, уровня Middle – в 200 тысяч, стартовая зарплата Junior-разработчика может составлять 100 тысяч рублей.
Профессия Python-разработчика скорее всего уже заинтересовала многих читателей. Как им стать?
В первую очередь необходимо получить и закрепить первичный набор навыков, уметь правильно писать команды, разбираться в коде языка, продолжать осваивать библиотеки и фрэймворки. Большим плюсом для начинающего Python-разработчика станет портфолио. Его можно составить даже из самых простых проектов, выполняя, например, тестовые задания на собеседованиях и дополнительных курсах. Владение английским языком упростит, как изучение языка программирования, так и дальнейшую работу с ним, поэтому начинающим специалистам стоит прокачивать английский язык.
Специалисты выделяют 3 основных пути получения необходимых навыков для Python-разработчика:
- Обучение в ВУЗе
В связи с высоким спросом на профессию программиста российские ВУЗы увеличивают количество мест по IT-направлениям, в том числе бюджетных. Этот путь, наиболее комплексный и фундаментальный, подходит для тех, у кого есть, как минимум, 4 года на изучение языков программирования и разработки. Стоит также отметить, что обучение в ВУЗе зачастую обеспечивает только поверхностное знание некоторых языков, поэтому для более глубокого изучения придётся заниматься самообразованием.
- Самостоятельное обучение
Изучить Python можно и самостоятельно, этот язык часто хвалят за его «простоту». Для начинающих разработчиков сейчас существует множество путей получения информации: видео-пособий и статей, книг. Этот путь подходит для тех, кто готов потратить свои ресурсы на пытливый поиск информации об интересующем языке, так как зачастую информация не систематизирована.
- Обучение на онлайн-курсе
Онлайн-курсы дают возможность изучить Python наиболее быстро, совмещая обучение разработке с постоянным местом работы и яркой личной жизнью. Этот путь подходит для тех, кто получает дополнительное образование с перспективой смены сферы деятельности, или для углубления уже имеющихся знаний в программировании. Современное разнообразие онлайн-курсов позволяет выбрать комфортный ритм изучения языка и финальные цели обучения, например, в онлайн университете ProductStar на курсе “Профессия: Python-разработчик” эксперты из Центра Карьеры начинают подбирать стажировки, опираясь на пожелания, уже во время обучения и гарантируют дальнейший оффер.
100+ вопросов по Python для Junior, Middle и Senior
Редакция DOU пообщалась с разработчиками, которые проводят технические собеседования Python-специалистов для различных уровней, и собрала примерный список вопросов к кандидатам. Конечно, он не является исчерпывающим, однако содержит типичные вопросы.
Вопросы для Junior
От джуниоров требуют знать и уметь применять базовые структуры данных и модули, простейшие запросы к базам данных, знать простейшие команды системы контроля версий и тому подобное.
Общее по Computer Science и Web Development:
1. Что такое инженерия и процесс разработки в целом?
2. Какие знаете принципы программирования?
3. Чем отличаются процедурная и объектов-ориентированная парадигмы программирования?
4. Какие основные принципы ООП (наследование, инкапсуляция, полиморфизм)?
5. Что такое множественное наследование?
6. Какие есть шесть этапов разработки продукта в Software Development lifecycle и какая разница между Agile и Kanban?
7. Какие есть методы HTTP-запросов и какая между ними разница?
8. Как выглядят HTTP-request / response?
9. Что такое авторизация и как она работает?
10. Что такое cookies?
11. Что такое веб уязвимость?
12. Какие знаете классические базы данных?
13. Как читать спецификацию в конкретном языке (например, PEP8 в Python)?
14. Как происходит взаимодействие клиента и сервера?
15. Какие есть подходы к проектированию API?
16. Как использовать паттерны программирования?
17. Что такое Acceptance Testing и зачем его используют?
18. Что такое модульные и интеграционные тесты, API-тесты?
19. Как писать unit-тесты?
20. Какие есть best practices в написании автотестов?
21. Какие базовые команды системы контроля версий?
22. Как использовать Git?
23. В чем разница между хешированием и шифрованием?
Ответы на некоторые из этих вопросов вы можете найти в видео курсах Python Базовый, Python Углублённый, Основы работы с Git.
Python:
24. Python — интерпретируемый язык или компилируемый?
25. Какие есть меняющиеся и постоянные типы данных?
26. Что такое область видимости переменных?
27. Что такое introspection?
28. Разница между is и ==?
29. Разница между __init __ () и __new __ ()?
30. В чем разница между потоками и процессами?
31. Какие есть виды импорта?
32. Что такое класс, итератор, генератор?
33. Что такое метакласс, переменная цикла?
34. В чем разница между итераторами и генераторами?
35. В чем разница между staticmethod и classmethod?
36. Как работают декораторы, контекстные менеджеры?
37. Как работают dict comprehension, list comprehension и set comprehension?
38. Можно ли использовать несколько декораторов для одной функции?
39. Можно ли создать декоратор из класса?
40. Какие есть основные популярные пакеты (requests, pytest, etc)?
41. Что такое lambda-функции?
42. Что означает *args, **kwargs и как они используются?
43. Что такое exceptions, <try-except>?
44. Что такое PEP (Python Enhancement Proposal), какие из них знаете (PEP 8, PEP 484)?
45. Напишите hello-world сервис, используя один из фреймворков.
46. Какие есть типы данных и какая разница между list и tuple, зачем они?
47. Как использовать встроенные коллекции (list, set, dictionary)?
48. В чем заключается сложность доступа к элементам dict?
49. Как создается объект в Python, для чего __new__, зачем __init__?
Тема связана со специальностями:
50. Что знаете из модуля collections, какими еще built-in модулями пользовались?
51. Что такое шаблонизатор и как в нем выполнять базовые операции (объединять участки шаблона, выводить дату, выводить данные с серверной стороны)?
52. Как Python работает с HTTP-сервером?
53. Что происходит, когда создается виртуальная среда?
Ответы на некоторые из этих вопросов вы можете найти в видео курсах Python Стартовый (урок 2, урок 4-8), Python Базовый (урок 1, урок 6, урок 7, урок 9), Python Углублённый (урок 1, урок 4).
Базы данных:
54. Какие есть базовые методы работы с SQL- базой данных в Python?
55. Что такое SQL-транзакция?
56. Как сделать выборку из SQL-базы с простой агрегацией?
57. Как выглядит запрос, который выполняет JOIN между таблицами и к самим себе?
58. Как отправлять запросы в SQL-базу данных без ORM?
Ответы на некоторые из этих вопросов вы можете найти в видео курсе SQL Базовый.
Алгоритмы:
59. Что такое алгоритмы (например, Big-O notation)?
60. Какие есть базовые алгоритмы сортировки?
61. Что такое Bubble Sort и как это работает?
62. Что такое линейная сложность сортировки?
Вопросы для Middle
Если джуниору все надо подсказывать и помогать, то мидл может самостоятельно взять что-то новое и быстро его изучить и понять. У него накоплено достаточно знаний и опыта, чтобы быстро овладевать новым. Он может прийти и обсудить с опытным разработчиком, проконсультироваться, но окончательных решений не принимает.
Обычно у мидлов спрашивают:
63. Ориентируетесь ли в *nix, можете ли написать скрипты/автоматизацию для себя и коллег?
64. Что такое многопоточность?
65. Что такое архитектура веб сервисов?
66. Как работает современное нагруженное веб приложение (нарисовать и обсудить примерную архитектуру, например, Twitter или Instagram)?
67. Что нужно для сайта / сервиса среднего размера (redis \ celery \ кэш \ логирование \ метрики)?
68. Как написать, задеплоить и поддерживать (микро) сервис?
69. Как масштабировать API?
70. Як проводить Code review?
71. Что такое абстрактная фабрика, как ее реализовать и зачем ее применяют?
72. Что такое цикломатическая сложность?
Python:
73. Async Python: как работает, зачем, что под капотом?
74. Сравнить асинхронные web-фреймворки.
75. Что такое модель памяти Python?
76. Что такое SQLAlchemy (Core и ORM частей) и какие есть альтернативы?
77. Принципы работы и механизм Garbage collection, reference counting?
78. Как работает thread locals?
79. Что такое _slots_?
80. Как передаются аргументы функций в Python (by value or reference)?
81. Что такое type annotation?
82. Для чего используют нижние подчеркивания в именах классов?
83. Статические анализаторы: Flake8, Pylint, Radon.
Ответы на некоторые из этих вопросов вы можете найти в видео курсе Python Углублённый (урок 3).
Базы данных:
84. Разница между SQL и NoSQL?
85. Как оптимизировать SQL-запросы?
86. Какие есть уровни изоляции транзакций?
87. Какие есть виды индексов?
88. Точечные вопросы по выбору БД, движков БД?
89. Front-end: есть ли опыт работы с «современным» JS (Babel, Webpack, TS, ES)?
90. DevOps: работали ли с Docker-контейнерами, объяснить основные термины K8s (кластер, pod, node, deployment, service), что такое Kibana?
91. Алгоритмы: что такое временная сложность алгоритма (time complexity)?
92. Углубленные знания Linux: как зайти на внешний сервер, работать с пакетами, настроить среду и выполнять операции?
93. Специфично для Data Science: как работать с пакетами для обработки и визуализации данных (NumPy, Pandas и другие)?
Ответы на некоторые из этих вопросов вы можете найти в видео курсе SQL Базовый.
Вопросы для Senior
На собеседованиях с Senior`ами обычно мало говорят о теоретической стороне технологии, больше обсуждают конкретный опыт разработчика. Поэтому формализованных вопросов здесь нет. Однако, примером могут быть:
94. Что такое @property?
95. Каким образом можно запустить код на Python параллельно?
96. Как работать с stdlib?
97. Какие задачи решали с помощью метаклассов?
98. Что такое дескрипторы?
99. Знания других языков, кроме Python (опыт).
Видео курсы по схожей тематике:
Создание проекта на Python и Flask
100. Какие технологические особенности реализации распределенных систем?
101. Какие есть низкоуровневые особенности языков и фреймворков?
102. Способы и методы управления памятью.
Бонус. Практические задания
1. Спроектировать клон Instagram. Это сервис, который понятен практически любому кандидату, даже если у него нет аккаунта. На высоком уровне он очень прост: картинки, описания, комментарии. Поэтому что-то минимальное сможет описать и джуниор. Если кандидат претендует на высшие позиции, можно бесконечно копать вглубь, касаясь API, тротлинга запросов, защиты от фрода, построения фидов пользователя и тому подобное.
2. Дано рекурсивное определение чисел Фибоначчи, надо написать функцию, которая реализует это определение.
3. Есть база данных из трех таблиц — стандартная many-to-many схема. Нужно написать запрос, который объединяет три таблицы и возвращает определенный результат.
4. Даем ТЗ какого-то полезного микросервиса (сокращалка url-ов, поиск дубликатов картинок, поиск тегов в текстах) или функции (rate limiter). Просим кандидата рассказать, как бы он его реализовал. Это дает возможность узнать, что привык использовать специалист, насколько глубоко он знает и понимает различные технологии.
5. Написать какой-то несложный декоратор (выводит аргументы функции на экран или, например, измеряет сколько времени выполнялась функция).
6. Junior`у можно предложить реализовать задачу FizzBuzz test.
7. Для Middle+ я люблю давать несложные задачки на рекурсию. Например, есть вложенный список чисел и нужно что-то на нем посчитать (скажем, найти максимум). Также, можно предложить написать аналог deepcopy для конкретной структуры данных (tree, graph).
8. Для Senior — игра «спроектировать за 5 минут. ». Это может быть Google, FB, Twitter, высоконагруженный интернет-магазин, сервис поиска, продажи и бронирования билетов, сайт новостей и тому подобное. Такая задача помогает понять, как кандидат решает проблемы, ход его мыслей, умеет ли он отделять главное от второстепенного, понять, какого он типа ( «в глубину» или «в ширину»).
9. Игра «у юзера что-то не работает». На примере спроектированной системы собеседователь придумывает ошибку с «дикими симптомами», которую очень сложно понять, воспроизвести. Но нужно быстро решить проблему.
10. Задание, которое демонстрирует знание и понимание list и dict comprehensions.
11. Задача, в которой есть три функции, в них выполняются базовые операции (сортировка, фильтрация, поднесение массива к квадрату). Нужно упорядочить эти три функции в порядке возрастания времени, которое уходит на их выполнение.
Place the following functions below in order of their efficiency. They all take in a list of numbers between 0 and 1. The list can be quite long. An example input list would be [random.random () for i in range (100000)]. How would you prove that your answer is correct? — profiling?
def f1 (lIn):
l1 = sorted (lIn)
l2 = [i for i in l1 if i <0.5]
return [i * i for i in l2]
def f2 (lIn):
l1 = [i for i in lIn if i <0.5]
l2 = sorted (l1)
return [i * i for i in l2]
def f3 (lIn):
l1 = [i * i for i in lIn]
l2 = sorted (l1)
return [i for i in l1 if i <(0.5 * 0.5)]
Бесплатные вебинары по схожей тематике:
Создаем нейронную сеть на Keras с нуля.
Объектно-ориентированное программирование в Python.
Создание социальной сети с помощью Python
То есть, на входе все функции имеют одинаковые данные, на выходе выдают одинаковый результат. Но из-за того, что внутри операции выполняются в разном порядке, время выполнения будет отличаться. Здесь нужно разбираться в алгоритмах и понимать, что происходит с твоими данными в процессе. Эту задачу может решить Junior, а может не решить и Middle. Казалось бы, такая мелочь, но когда мы работаем с большим количеством данных, важно, чтобы код был оптимизирован и программа выполнялась максимально быстро.
12. Простые задачи на статистику или логику. Например, определить угол между стрелками часов, которые показывают 8:40.
Вопросы не мальчика, а джуна. 22 вопроса работодателю на собеседовании на позицию «Middle Python-разработчик»
За 2 года мне посчастливилось посетить более сорока собеседований в качестве кандидата на позицию «Middle Python-разработчик». На последних пятнадцати собеседованиях я понял необходимость задавать вопросы работодателю, чтобы в дальнейшем не столкнуться с неожиданностями по работе. Помимо базовых вопросов, которые обычно задают кандидаты работодателю я решил сформировать свои вопросы. Когда я задавал эти вопросы на собеседованиях, я получал самые различные реакции со стороны собеседующих. Кто-то говорил, что я дотошный, кто-то считал эти вопросы слишком банальными, а кто-то даже начинал нервничать(краснеть) и немедленно прерывать собеседование с нелепой отговоркой о том, что у него совещание. В этой статье я хотел бы рассказать об общих идеях посещения таких мероприятий а также привести мои 22 вопроса, которые я задаю на собеседовании работодателю.
Общие идеи
Собеседование на middle-разработчика часто выглядит так же как собеседование junior-а.
Это действительно так. Это связано с тем, что многие тимлиды/тех.директоры не знают, что именно они хотят видеть в 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. Что делает разработчик с кодом перед тем, как отправить его в репозиторий?
Под этим вопросом понимается локальная проверка своего кода по различным параметрам. Вот небольшой список того, чем обычно проверяют код перед отправкой в репозиторий:
-
– анализ кода на соблюдение PEP8, – статический анализ кода,
- Coverage – анализ кода на тестовое покрытие, – проверка кода на совместимость с различными версиями отдельных пакетов и с разными версиями Python.
3. Есть ли в проектах CI/CD? Есть ли DevOps-инженер?
Этот вопрос не имеет никаких подводных камней и задаю я его чтобы получше понять устройство компании. Если в проектах нет CI/CD и DevOps-инженер тоже отсутствует, то есть вероятность что именно Вы будете этим заниматься. Поэтому этот момент тоже лучше обсудить на собеседовании.
4. Есть ли Code Review? Как оно проходит?
Первую часть вопроса можно оставить без комментариев, потому что все понимают важность этого мероприятия. Но стоит отметить что лично меня интересовало как именно оно проходит. Чаще бывает так, что каждый из команды ревьюит разработчика который сделал Merge Request. Но иногда встречается, что над любым разработчиком есть ментор/наставник и именно он ревьюит разработчика. Первый подход считаю более правильным, так как чем больше людей ревьюит код, тем лучше для проекта и для команды. Здесь сразу затрагиваются такие аспекты, как командное взаимодействие, коллективная ответственность, увеличение bus-фактора.
5. Какую систему контроля версий Вы используете?
На данный момент в России существует немало компаний, которые до сих пор использует hg, svn и прочие древние системы контроля версии. Особенно это относится к компаниям, которые на рынке больше 10 лет. Этот вопрос больше проверяет насколько старая компания восприимчива к новым технологиям. Также стоит отметить, что я недолгий период времени принимал участие в разработке используя hg и особого удовольствия мне это не доставило.
6. Используете ли вы git/hg-flow или какую-либо определенную методологию при работе с git/hg?
Данный вопрос вытекает из предыдущего вопроса о системах контроля версий. Поэтому если команда не использует git/hg, то и задать его нет смысла. Если же компания использует 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. Есть ли митапы внутри компании?
Здесь речь пойдет о митапах у разработчиков внутри команды или между командами. Митапы – очень важны. Они позволяют узнать кто и чем именно занимается в данный момент времени. Если у Вас проблемы с публичными выступлениями, то это также поспособствует развитию Ваших soft skills.
22. Есть ли в компании стажёры и развита ли система наставничества?
Стажёры – это потенциальное будущее компании. Если в компании есть стажёры, то возможно Вы сможете быть для них наставником и делиться своим личным опытом. Наставничество – это тоже одно из направлений где Вы сможете развиваться.
От стажера до миддла: как вырасти Python-разработчику
Мидл — следующий этап развития разработчика после стажёра или джуна. Ему доверяют больше интересных проектов и ответственных задач, у него чаще спрашивают совета, ему больше платят. Илария Белова, ведущий python-разработчик отдела качества рекламы Яндекса и преподаватель Школы анализа данных, рассказывает, что отличает хорошего мидла от стажёра.
Необходимый минимум
Когда стажёр только начинает работать, ему достаточно владеть базовыми инструментами и навыками:
- знать базу языка и устройство структур данных в нём;
- уметь работать в командной строке;
- уметь работать с системой контроля версий.
После устройства на работу стажёр сначала учится работать в экосистеме проекта с выполнением всех best practices: пишет тесты и документацию, работает с трекером задач, собирает, принимает и выкатывает изменения. Обычно этому учит ментор, который сопровождает стажёра. И когда всё это усвоено, стажёр становится полноценной боевой единицей — джуном.
Как быстрее перейти в мидла
Однажды к нам в Яндекс пришёл стажёр, которого быстро подняли до мидла без стадии джуна. Его отличало то, что он сам инициировал задачи, которые нужно сделать: «Здесь у вас плохо. Можно сделать вот так, и станет лучше». Мы отвечаем: «Хорошо. Если это не мешает твоим основным задачам — делай». И он всё успевал делать в рабочее время и разумные сроки — не было такого, что взялся за что-то и не сделал.
Ещё из важных качеств — он адекватно реагировал на критику и быстро вносил правки. Некоторые стажёры могли тратить на небольшие исправления два-три дня. Но этот парень приносил исправления уже через пару часов. И даже если он снова что-то делал не так, то оперативно всё менял.
Он не боялся переписать собственный или чужой код, чтобы получить результат. Был самостоятельным и инициативным, доделывал всё до конца, и его не надо было пинговать. В итоге через полгода после начала стажировки мы его сразу подняли до мидла, а спустя два года он уже претендует на старшего разработчика. Хотя до нас он был бывшим студентом, который где-то поработал всего полгода.
Таких примеров мало, и чаще всего стажёры не понимают, чего на самом деле от них ожидают. Поэтому я расскажу о ключевых навыках, которые помогут быстрее вырасти в джуна или даже сразу в мидла.
Разбираться в структуре проекта
Начинающий разработчик ещё не может охватить весь проект целиком и выделить зоны ответственности разных частей кода. Например, он может задублировать уже существующую в проекте функциональность. Если это так и оставить, то в будущем правки придётся вносить в двух местах, почти наверняка про это будут забывать — и код начнёт разъезжаться.
Другая проблема — добавление ненужных зависимостей. Часто начинающие разработчики импортируют лишние библиотеки, порождают неявные связи и циклические зависимости. Чтобы сделать небольшую легковесную утилиту, не нужно добавлять в зависимости половину внутренних библиотек Яндекса. Всё это замедляет сборку и усложняет структуру проекта.
Умение разбираться в экосистеме проекта приходит с опытом. Чем больше разработчик погружается в проект, тем лучше он понимает его структуру. Но важно не просто «работать над проектом», а интересоваться им, пытаться понять, почему сделано именно так и для чего нужна та или иная штука. Также помогает участие в разных проектах: чем больше проектов видит разработчик, тем быстрее он учится разбираться в них.
Не бояться править чужой код
Если начинающего разработчика попросить написать функцию, он сделает ровно то, что сказали. Не посмотрит соседний код, а просто реализует то, что от него просили, даже если это будет криво вписываться в существующее решение. Стажёры боятся править чужой код, ведь его писал «гуру программирования, который разбирается в этом лучше». И даже если стажёр чувствует какую-то проблему, всё равно он боится взять на себя ответственность за исправление.
Опытный разработчик смотрит чужой код и пытается понять, какой смысл в нём заложен и как его поправить так, чтобы ничего не сломать и красиво вписать своё решение. Начинающему сделать это тяжело, но он может подсветить проблему или пообщаться с автором кода и обсудить возможную модификацию. Главное — не пытаться молча «закостылить» своё решение.
Писать чисто
Важно думать о тех, кто будет читать код после вас. Чаще всего наши стажёры — бывшие студенты, а в университете не
заморачиваются с долгоживущим кодом: там можно выполнить задачу, сдать и забыть. Из-за этого стажёры не придерживаются code style, не пишут документацию к функциям, оставляют в коде много мусора, а ошибки обрабатывают с текстом «Sorry, fail». На код-ревью приходится от этого отучать.
Мы прививаем следующий подход: сделал функциональность — напиши на неё тесты, обнови документацию, поправь аннотации, сделай user-friendly тексты ошибок. Если сделал костыль и он правда нужен, то напиши об этом подробный комментарий и объясни своё решение.
Не делать фичи «на всякий случай»
Иногда стажёры хотят сделать максимум функциональности и побольше фич. Они создают ненужные методы и классы, добавляют обработку множества опций и параметров «просто на всякий случай». Но если ни сейчас, ни в обозримом будущем эта функциональность не нужна, то и делать её не нужно. Этот «случай» может никогда и не наступить, а поддерживать этот код придётся всё время.
Брать на себя ответственность
Есть несколько видов ответственности: за принятие решений и за доставку конечного продукта.
Когда во время ревью мы находим ошибки, то спрашиваем: «Почему ты сделал это именно так?» Частый ответ: «Не знаю» или «А как надо было?». Это показывает, что разработчик не пытался оценить разные варианты решения и выбрать из них. Опытный разработчик прорабатывает в голове все возможные варианты и corner-кейсы, выбирает самое целесообразное решение и несёт ответственность за свой выбор. Разница между начинающим и опытным в том, что второй перебирает больше вариантов и делает более осмысленный выбор.
Я часто предлагаю стажёрам несколько вариантов решения проблемы и объясняю плюсы-минусы каждого. Но финальное решение оставляю за самим разработчиком, и важно, чтобы он сумел его объяснить. Даже ответ «Я выбрал этот вариант, потому что его реализовать быстрее, а у нас горит дедлайн» — хорошее обоснование.
У нас были начинающие разработчики, код которых разваливался после запуска в продакшен. Но проблема была не в том, что он разваливался, а в том, что разработчики даже не интересовались, как их код доехал до прода. Опытный разработчик сопровождает свой код с момента написания до доставки: выясняет, на какие графики нужно смотреть, какие логи проверить, и удостоверяется, что в продакшене всё заработало.
Развивать критическое мышление
Бывает, ставишь стажёру задачу, а он молча начинает её делать. Если потом спросить его: «Ты понимаешь, над какой проблемой работал? Для кого ты делал задачу? Что она должна решать?», то, скорее всего, внятного ответа не будет. Это может быть чревато тем, что задачу сделали, но никакой проблемы она не решает. Например, если формулировка была неполной или не учли подводные камни. Также в голове не образуется связки, которая учит в будущем идентифицировать проблемы и подбирать адекватные решения.
Ещё нередкая ситуация, когда извне прилетают задачи, которые на самом деле делать не нужно. В таких ситуациях нужно посмотреть на задачу, понять её суть и сказать: «Тебе поможет не эта фича, а вот эта. Такое решение есть, и тебе лучше обратиться к другому отделу, вот к этому». Это отличает начинающего разработчика от опытного: смотришь на задачи, отсекаешь ненужное и фокусируешься на важном.
Изучать и следовать best practices
Для развития начинающего разработчика очень важно хорошее код-ревью. Например, в ШАД ревьюеры тщательно смотрят код, оставляют подробные комментарии, делятся своим опытом и объясняют, почему что-то не сработает. Не просто «Поправь тут», а «Это важно с точки зрения потребления памяти. Сейчас здесь мало данных, и код работает нормально. Но когда объём возрастёт в 10 раз, это может выстрелить».
Не во всех командах можно найти хорошего ревьюера и наставника. У меня его тоже не было, поэтому я просила помощи у друзей и знакомых, которые рассказывали мне best practices. Для тех, кто привык работать самостоятельно, лучше всего читать документацию и PEP.
К статьям на «Хабре» и к видео с конференций стоит относиться критически, потому что при нехватке опыта тяжело выделить полезные доклады. Идентифицировать хорошую статью можно по тем же критериям, что и новую фичу: есть ли в ней хорошие ответы на вопросы, какую проблему решает, правда ли решаемая проблема актуальна, какие альтернативные решения были?
Что почитать, послушать и посмотреть
Курс «Язык Python» от ШАД. Мы рассказываем про устройство языка, структуры данных, тестирование, документирование, а также затрагиваем прикладные темы: MapReduce, асинхронность, работу с сетью. На каждую тему есть много заданий, решения которых мы затем разбираем. Курс поможет не только освоить все необходимые навыки, но и разобраться в различных сферах применения языка, выбрать себе специализацию, подготовиться к собеседованию. Это задаст необходимый вектор роста.
«Чистый код» и «Чистая архитектура» (Роберт Мартин), «Совершенный код» (Стив Макконнелл). Эти три книги будут полезны для всех разработчиков. Они не привязаны к конкретному языку, но объясняют основные принципы хорошего и компактного кода. Такого, который принято использовать в промышленной разработке для упрощения поддержки и масштабирования.
«Head First Design Patterns» (Эрик Фримен, Элизабет Робсон). Это весёлая книга для тех, кто хочет узнать
больше про паттерны, но с трудом понимает академический текст. В книге собраны проверенные временем паттерны, которые используют разработчики для создания гибкого кода.