Где взять шаблон и сделать резюме

Что нужно знать о позиции Младший Python-разработчик / Junior Python Developer

Виды компаний

• Стартапы Это новые, совсем маленькие компании, часто до 10 или даже до 5 человек. Бывают и больше по размерам, но духом, смыслом и уровнем процессов остаются такими же. Смысл существования такой компании — получение следующего раунда финансирования, запуск продукта или выпуск следующей версии. И нет никакого точного прогноза, получится ли это и будут ли у компании деньги через месяц, полгода или год. Маленькой командой стартап старается выдать на рынок нечто сложное, что не всегда физически по силам такому количеству сотрудников. Поэтому стартапы ищут людей, которым понравится идея — и которые готовы будут вкладывать в неё силы, нервы и время. Если предлагаемая стартапом идея (то, что он в итоге выпустит или уже даже выпустил на рынок) вас не вдохновляет, вы вряд ли подружитесь. К плюсам стартапов относятся: семейная ламповая атмосфера; отсутствие бюрократии — откуда ей быть у трёх человек; обычно новый модный стэк (набор применяемых технологий); команда энтузиастов, как правило, работающих 24х7. Минусы тоже растут из самой сути стартапов. Семейная атмосфера может быть слишком семейной — и конфликт с техдиром при код-ревью закончится увольнением. Когда все договоренности на словах, а деньги отправляют по номеру карты, уволить могут одним днём и без выходного пособия — это другая сторона полного отсутствия бюрократии. Или может быть просто полный хаос в рабочих процессах, приоритетах и постановке задач. В конце концов, команда энтузиастов будет ожидать энтузиазма и от вас — готовьтесь к переработкам. Но если проект действительно крутой, пока финансирование есть (и/или у вас есть финансовая подушка на случай неудачи), а вы любите приключения — можно и попробовать.
• Небольшие продуктовые компании. Это выросшие стартапы. Общая обстановка становится стабильнее: компания кормит сама себя, а не ждёт финансирования. А ещё копится легаси во всех его видах: древний бесхозный код, технический долг, недокументированные части продукта. Все то, что оставила после себя спешная антибюрократическая разработка стартапа. Легаси осложняет разработку нового функционала и требует поддержки. Когда продукт разрастается, ранее написанные «костыли» самым непредсказуемым образом ломаются, и регулярно приходится всё чинить. Отдел разработки растёт, зарплата в компании — белеет. Бюрократии ещё немного, но она уже есть. Рабочие процессы и подходы ещё настраиваются и могут быть специфичны или даже вызывать отторжение. Таким компаниям нравятся те, кто думает про бизнес и обеспечивающих его существование пользователей. Как сделать лучше? Почему так, а не эдак? Что это нам принесёт? Как обеспечить баланс между пожеланиями пользователей, задачами бизнеса и техническими нуждами продукта? Если вам подходит такая работа с постоянной оглядкой на уже сделанное и постоянное заглядывание в будущее, если сердце греет мысль о фидбеке от пользователей (спойлер: как правило, он не очень позитивный) — вам в продуктовую разработку.
• Большие продуктовые компании. Уже обросли бюрократией, зато точно полностью обелились и всё, что касается персонала, делают максимально по закону. Вместе с компанией растут и требования: нужно уметь ещё больше, быть ещё лучше, знать ещё глубже. Вместо одного продукта большие компании делают или несколько продуктов, или разрабатывают ответвления основного: не просто Google, а Google Картинки и Google Видео. При этом в одной команде Google могут быть интересные задачи и крутая команда — а в другой наоборот. И так же для других ответвлений продукта. В этом специфика любой крупной компании, не важно, аутсорсинговой или продуктовой: пока не попадёшь на конкретный проект и в конкретную команду — не знаешь до конца, как там работается. Различаются процессы, размеры команд, их состав, значение и важность ролей в команде, масштаб задач. Различаться может даже оформление — в разные юридические лица, с разными условиями (просто оклад или оклад и бонусы).
• Студии. Это небольшие компании, разрабатывающие на заказ. К ним приходит клиент и заказывает сайт, даёт все вводные, макеты и все ТЗ, какие у него есть. А студия по ТЗ этот самый сайт и делает — и тратить бюджеты на отступления от ТЗ, как правило, у заказчика нет ни времени, ни желания. После приёмки работ исходный код передаётся заказчику, а команда берётся за следующий проект. Поэтому в студии улучшайзингом заниматься так много, как в продуктовой разработке, просто не получится. Зато проекты постоянно сменяются, опыт можно получить очень разнообразный. Но часто и поверхностный, потому что нет времени погрузиться в тот или иной стэк, не говоря о тонкостях проекта. Сами по себе развиваются софт-скиллы от общения с условными индийскими субподрядчиками или упёртым заказчиком. И даже есть шанс не поддерживать легаси, а постоянно делать что-то новое и с нуля. В отличие от продуктовой разработки, заказчик тут не внутренний, а внешний — и установленные им сроки не сдвигаются, потому что кто-то заболел. Из-за этого чаще, чем в продукте, случаются переработки и авралы. Зачастую они оплачиваются, но всё же такая работа подходит не всем.
• Интеграторы. Когда продуктовой компании не хватает рук на все задачи по своему продукту, она отдаёт их на аутсорс. Когда их не хватает большой продуктовой компании, она отдаёт их интегратору — большому аутсорсу. Интеграторы имеют длительные контракты с одними и теми же заказчиками, а значит, у разработчиков есть время углубиться в конкретный проект. Иногда это новые проекты и задачи, на самостоятельный запуск которых не хватило рук у заказчика прямо сейчас. Иногда — поддержка именно легаси в работоспособном состоянии и работа третьей линии поддержки. Команды, люди и проекты постоянно тасуются, из-за переходящих архитекторов и лидов плавает туда-сюда уровень технической квалификации. Зато проекты в крупнейших интеграторах уже международные, можно поработать на проекте с именем (правда, закрытым NDA для резюме и обсуждений), с командами из разных стран. И есть всё та же специфика больших компаний, описанная в пункте выше.

Формы занятости

• Удалённая работа. Может встретиться в любой компании. Требует высокого уровня самоорганизации: нужно делать задачи в срок и рабочее время. И быть на связи, а не чесать пузо коту или смотреть ютуб (начальник же не видит!) Кому-то такой формат не подходит из-за одиночества, кому-то приходится оборудовать домашний офис или арендовать место в коворкинге. При удалённой работе тяжелее с коммуникациями: вы не можете просто подойти или подсесть к коллеге и за 3 секунды решить вопрос, на котором застряли. И очень важно, как строит процесс работы с удалёнщиками сама компания, особенно если основная команда находится в офисе. В общем, удалённую работу сложно готовить, но иногда получается круто.
• Фриланс. Это временные проекты, которые, как правило, выполняются удалённо. Начинающие фрилансеры вынуждены «соревноваться» за каждый заказ на биржах фриланса с более опытными или вообще ботами, которые автоматически откликаются на заказы по ключевому слову. Часто попадаются не очень адекватные заказчики, чаще всего это люди не из IT и даже не рядом, которым нужно спарсить какой-нибудь сайт. Желательно сделать его позавчера и с функционалом, который невозможно реализовать. Фрилансеров часто обманывают или пытаются обмануть с оплатой. Набравшись опыта на мелких заказах, можно повстречать заказчика-мечту и годами поддерживать его проекты, но обычно до встречи с ним проходит от года работы на фрилансе с нестабильным заработком.
• Аутстафф. Это как бы следующий уровень аутсорса: вы не просто делаете проект стороннего заказчика, вы даже сидите у него в офисе. В большинстве случаев аутстафф используют на своих проектах банки. Плюс: один и тот же проект (это могут быть сменяющиеся его подчасти, но глобально один и тот же) в работе, потом при желании и наличии вакансий в штате самого банка можно перейти к ним. Минус: как правило, штатные сотрудники всё равно не считают вас частью команды, а проект может оказаться очень скучным. И ещё один важный минус: вы не определяете, над чем работать, даже на уровне того, над продуктами какого банка трудиться. То есть в один день контракт поддержки банка А может закончиться, и уже на следующий день вы, всё бросив, обнаружите себя в офисе банка Б.