Senior что это

Junior, Mid- и Senior-ы – в чем разница?

В мире IT-специалистов принято делить уровень подготовки и профессионализма разработчиков на три уровня: Junior-разработчик (младшего уровня), Middle-разработчик (среднего уровня) и Senior-разработчик (старший разработчик). На первый взгляд, эти термины очевидны, но на практике оказывается, что все понимают их по-разному. Порой сами разработчики не всегда уверены, как определить свой уровень или уровень коллег из команды. Но если провести аналогию, все становится сразу понятнее. Давайте попробуем сравнить разработчиков с… водителями! Ведь каждый день многие из нас садятся за руль и хорошо понимают эту «кухню» и правила игры на дороге.

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

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

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

На следующий уровень выйдет Junior, который:

Стремится к саморазвитию
Энергичен и целеустремлен
Умеет с холодной головой воспринимать критику

Обычный водитель легко доставит вас из пункта А в пункт Б, хорошо справится с повседневными маневрами и ситуациями на дороге. Middle-разработчик — это уже полноценный разработчик. У него есть определенный опыт, он может самостоятельно решать большинство проблем и не нуждается в наставничестве.

Важные качества Middle-разработчика:

Понимание функций и структуры продукта
Опыт разработки в нужной отрасли
Уверенное владение стандартными инструментами и шаблонами и умение их применять
В ходе разработки он учитывают не только свои интересы и предпочтения — «мидлы» понимают, что работают в команде, и умеют взаимодействовать с коллегами

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

Как понять, каким уровнем навыков обладает разработчик? Существуют ли какие-либо формальные критерии?

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

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

Например, не может быть старшего разработчика с 2-летним опытом работы. С другой стороны, есть много младших разработчиков с опытом работы более 5 лет. Стоит отталкиваться от Soft и Hard Skills разработчика. Но сухие теоретические знания — это не ключевое отличие, а лишь один из факторов. Программировать — это не общаться с компьютером. Программировать — общаться с людьми и отдавать указания компьютерам.

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

Senior-программисты пишут легко. Зачастую, взглянув на такой код, можно подумать: «А где остальное?» Такой код понятный и прямолинейный. Этот подход крайне важен для дальнейшей поддержки кода и его масштабируемости в будущем. Важен для тех, кто будет работать с кодом дальше.

Заключение

Разница между Junior, Middle- и Senior-специалистом основывается не только на годах опыта. Да, Senior-разработчики знают значительно больше остальных, но также важно обладать несколькими другими умениями.

Опытные программисты пишут простой код, опираясь на масштабируемость и дальнейшую работу с ним. Такие разработчики имеют развитые Soft Skills: умеют общаться с командой и всегда остаются в тренде разработки. Опыт Senior-а поможет прогнозировать разработку и риски и найти решение в любой ситуации.

Junior-разработчику нужно учиться писать «легкий» для восприятия код. Важно вырваться из рутины и творить код, словно художник. Junior должен не бояться брать сложные задачи на себя и совершать ошибки (это неотъемлемая часть карьеры). Для поднятия до уровня Middle следует полностью овладеть своим техническим стеком и развивать Soft Skills. Также опытные разработчики стараются помогать своим коллегам стать более грамотными и тоже набираться опыта. Ведь суть команды — это помощь, поддержка, общение и, конечно, создание первоклассного продукта!

Junior, Middle, Senior — разбираемся, кто есть кто в разработке

Разработчики разделяются на три ступени: Junior, Middle, Senior. Четкого разделения нет, все зависит от компании и вашего опыта. Если в одной компании вы — Middle, то переходя в другую, можете снова занять роль Junior. Чтобы понять, в чем их различие, какие у каждой ступени обязанности, читайте статью. Junior — начальная ступень Это младший разработчик, его […]

Подготовлено_выпускником —>

Junior, Middle, Senior

Получите востребованную профессию бесплатно. Обучение от 1 до 4 месяцев

Junior — начальная ступень

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

Junior специалист

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

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

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

Зарплата варьируется от 40 000 до 100 000 рублей.

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

Middle — крепкое среднее звено

Вы научились выполнять задачи без ошибок, повысили личностные качества и навыки программирования и вас из джуна повысили до мидла. Middle буквально переводится как середина. Опыт мидла от 2 до 7 лет.

Middle специалист

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

Какие задачи выполняет мидл:

Досконально знает языки программирования, на которых работает проект
Понимает как изнутри работает фреймворк (программная платформа, которая упрощает разработку программного продукта, определяет структуру проекта и помогает удобно объединять в нём разные компоненты)
Теоретически знает, как работать со стандартными библиотеками
Изменять сервис, добавлять новые страницы интерфейса или функции API (протокол обмена информацией между программами)

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

Зарплата варьируется от 100 000 до 300 000 рублей.

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

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

Senior — самый опытный специалист

Это самая серьезная ступень разработки. Вы уже можете с нуля написать код и разработать приложение, учитывая специфику компании и аудитории, на которую оно рассчитано. Можете дать задачи команде разработки, умело работать в кругу коллег и контролировать разработку продукта. Его опыт составляет 5-7 лет.

Senior специалист

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

Такой специалист понимает риски кода, работает над их снижением, так как понимает внутрянку всего процесса.

Какие задачи у сеньора в проекте:

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

Ответственность сеньора намного выше чем на остальных уровнях: он отвечает за эффективность работы команды и скорость и чистоту кода, за то, будут ли решены задачи бизнеса.

Зарплата: от 2500 000 рублей и выше.

Куда может развиваться сеньор

У сеньора больше возможностей, чем у мидла или джуниора. Дальнейшее продвижение в карьере зависит от его возможностей и желания самого человека. Сеньор может стать техническим директором, руководителем команды (тимлид), IT-архитектором или создать свою компанию разработки продуктов и сервисов.

Переход на должность Tech Lead. Это самый сильный разработчик в команде. Именно он предлагает, какие использовать определенные фреймворки, технологии и библиотеки и проверяет код. Например, принимает решение об автоматизации работы с облачным провайдером и рассчитывает окупаемость инвестиций (ROI).

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

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

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

Возраст и опыт в годах — далеко не главное

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

Обычно картина: джуниоры — молодые ребята, мидлам около 35, а сеньорам больше 40 лет. Но бывает и так, что человек в возрасте устраивается на позицию джуниора, а его наставником становится сеньор, которому около 30 лет.

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

Получите профессию разработчика уже сейчас

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

Выбирайте, в какой профессии вы хотите стартовать:

«Тестировщик программного обеспечения: с нуля до первых проектов»
«Web-программист: с нуля до первых проектов»
«1С программист»
«Аналитик данных:с нуля до разработки прикладных решений для бизнеса»
«Профессия Product Manager в IT»
«Разработчик чат-ботов с использованием готовых конструкторов»
«Project manager в IT: старт карьеры руководителя ИТ проектов»
«Data-аналитик: старт карьеры»

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

После окончания программы вы получите документ установленного образца и возможность пройти оплачиваемую стажировку в компаниях-партнерах проекта. Сейчас «Содействие занятости» сотрудничает с крупными компаниями: Литрес, МТС, Яндекс, Кинопоиск, ВТБ, банк «Открытие», Теле2 и другими. Чтобы вам было легче и комфортнее найти работу после обучения, чувствовать поддержку и получать помощь и ответы на вопросы, обращайтесь в Центр карьеры . Специалисты помогут разобраться в вакансиях на должность, подскажут, где лучше искать работу по вашей специальности. В Центре вам расскажут, на какую зарплату можете претендовать и составят подробный план поиска работы. Вы научитесь создавать продающее резюме, оформлять портфолио, писать сопроводительные письма.

Бесплатно помогаем найти работу мечты

Лучшая инвестиция — это инвестиция в себя, в свои знания и будущее. Оставьте заявку на бесплатное обучение прямо сейчас и станьте участником проекта.

Получите востребованную профессию бесплатно. Обучение от 1 до 4 месяцев

Junior, Middle, Senior, Lead — в чем разница и куда дальше?

Привет всем! Меня зовут Александр Демура, в IT я работаю с 2004 года, сейчас руковожу центром разработки DataArt в Одессе. В мои непосредственные обязанности входят найм и развитие наших специалистов, поэтому рассуждения на тему «синьорности» сотрудников и качеств, необходимых для той или иной роли, для меня актуальны и привычны.

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

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

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

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

Интерн

В DataArt есть практикантская программа, куда мы берем людей даже без опыта работы. У них есть три месяца, чтобы под руководством опытного ментора дорасти до уровня «джуниор». Для позиции интерна есть два основных требования:

Хороший английский.
Понимание выбранного инструмента и умение им пользоваться.

Требование к знанию английского у нас, на самом деле, общее для всех. DataArt — международная организация, большинство заказчиков находятся в США и Западной Европе, и даже внутренние коммуникации уже все больше на английском. Если человек — грамотный технический специалист, мы поможем ему разговориться и подтянуть язык — для этого есть корпоративные курсы и куча дополнительных инициатив. Но если человек без технического опыта (а интерн — как раз такой) еще и слабо знает английский, ему нужно обладать уникальными качествами, которые перекроют оба этих недостатка.

Про инструмент мысль тоже, мне кажется, простая. Если вы приходите на роль программиста, инструмент для вас — язык программирования со средствами разработки, которыми нужно уметь пользоваться. Если потенциальный интерн хочет разрабатывать на .NET, но не может объяснить, что делает CLR, чем «Equals» отличается от «==» или реализовать простейший алгоритм — шансов у него нет никаких. Приходить с нулевыми знаниями и надеяться, что всему научат на месте, параллельно выплачивая зарплату, бесполезно — слишком большой конкурс. За плечами многих кандидатов профессиональные курсы, они с легкостью отвечают на все теоретические вопросы и даже имеют опыт программирования «для себя». Конечно, таких людей берут в первую очередь.

Junior

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

Для джуна важны следующие качества:

Желание развиваться и учиться (а на своих ошибках — особенно).
Энергия и целеустремленность.
Способность спокойно относиться к критике.

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

Middle

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

Мидл-разработчик понимает, что именно делает приложение. Это позволяет глубже понять задачу, а, значит, точнее ее оценить и качественнее реализовать. Если требования не полностью покрывают какой-то сценарий, хороший разработчик обратит на это внимание на этапе планирования. А не когда приложение начнет валиться при любом нестандартном действии пользователя.
Мидл-разработчик знаком со стандартными шаблонами и решениями при построении приложения в своей области, понимает, зачем они нужны, и умеет их применять. Стандартизация решений имеет большое значение при коллективной разработке кода, т. к. позволяет новому человеку быстрее разобраться, что к чему, и минимизирует количество ошибок. Понимание структуры типового приложения делает задачу его построения с нуля достаточно тривиальной, позволяет рассуждать о принципах правильной реализации и отличать хороший код от плохого.
Мидл-разработчик понимает, что работает не один. Он умеет взаимодействовать с другими членами команды: может обсудить сложный момент с дизайнером, уточнить у бизнес-аналитика неполные требования или согласовать какое-то важное техническое решение с архитектором проекта (если такой есть) и, конечно, владеет соответствующими инструментами коллективной разработки.

Senior

Синьор — опытный разработчик, повидавший много кода, набивший кучу шишек и сумевший сделать из этого правильные выводы. Основная задача синьора — принимать правильные технологические решения в проекте. «Правильные» — это такие, которые приносят максимальную пользу бизнесу и минимизируют затраты. Хороший синьор не только понимает, что разрабатывает команда, но думает, какие задачи должно решить готовое приложение. Разрабатывая площадку для аукциона, синьор всегда задается вопросом о пиковой нагрузке и старается предусмотреть попытки конкурентной записи в таблицы БД. Он заранее думает об узких местах системы, о возможности ее масштабирования, помнит об уязвимостях и проблемах, вызванных неправильным использованием инструментов.

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

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

Способность решать несколько более сложные задачи, делать это быстрее или лучше, чем средний разработчик, не имеет практически ничего общего с синьорностью. В нашей классификации человек, который это умеет, называется «Strong Middle».
Звание синьора невозможно получить быстро. Нужно наработать обширный опыт и понять, что отличает хорошо сделанный продукт от тяп-ляп-разработки, как проявляет себя технический долг, сколько стоит рефакторинг, зачем на самом деле нужны паттерны и так ли необходимы бесконечные уровни абстракции. Необходимо самостоятельно принять важные решения и дать им пройти испытание временем, иначе оценить их не получится.
Синьору необходимы хорошие коммуникативные навыки, потому что он должен не только предложить правильное решение, но и убедить в своей правоте заказчика и команду. Если вы не смогли отстоять хорошее решение и вместо него было принято плохое, винить в этом придется самого себя. Вариант «я же говорил» на уровне Senior уже не работает. С командой то же самое — мало знать, как надо, нужно еще и уметь это доходчиво объяснить. Тогда команда быстро растет и набирается опыта, избегая болезненных ошибок. Авторитарный подход («делайте, как я сказал») зачастую приводит к внутренним конфликтам, и ситуацию на проекте отнюдь не улучшает — нужно стараться этого избегать.
Синьор не может обойтись без понимания устройства библиотек и фреймворков. Если инструмент разработки для вас — черный ящик, и вы составляете приложение из готовых частей, не зная, что у каждой из них под капотом, продукт всегда будет неустойчивым и непредсказуемым.

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

Что дальше?

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

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

Куда же развиваться синьорам? Многие программисты любят рассуждать о «потолке» — когда внутренний рейт (т.е. деньги, которые вы получаете за заработу) приближается к внешнему (счету, выставленному клиенту) с минимальной маржинальностью. Они считают, что в этом случае дальнейший рост специалиста становится нецелесообразным для работодателя. Однако это не так, есть множество способов и дальше увеличивать свою ценность. Поэтому позицию Senior Developer стоит рассматривать не как карьерное плато, а как плацдарм для дальнейшего развития, например, в одном из следующих направлений:

Технический эксперт

Статус технического эксперта подразумевает глубокое знание отдельной и специфической области. Например, можно быть экспертом в Azure/AWS и знать разнообразные сервисы, которые предоставляют эти платформы. Уметь делать Machine Learning или Computer Vision, знать все про уязвимости в вебе, понимать, как работают криптовалюты или правильно готовить Sharepoint. Такие задачи встречаются не каждый день, но когда появляются, наступает звездный час технических экспертов. Без них подобные проекты были бы просто невозможны, и компания зачастую готова доплачивать за эти уникальные знания.

Индустриальный эксперт

DataArt старается развиваться в определенных доменных областях (путешествия, финансы, здравоохранение и т. п.). В каждом проекте программисты не только приобретают собственно технические знания, но и получают возможность заглянуть в бизнес заказчика, понять, как устроена индустрия, узнать характерные для нее проблемы и решения. Чего стоит построить свою платежную систему вроде PayPal? Зачем нужна система Sabre? Или что такое HIPAA и какие ограничения она накладывает на разработку решений в области здравоохранения в США? Люди, которые обладают подобными знаниями, зачастую формируют костяк проекта и приносят компании и клиенту огромную дополнительную пользу. Поэтому их компенсация (т. е. деньги, которые они получают за работу) может превышать внешний рейт — компании сами готовы доплачивать таким людям сверх счета, выставленного заказчику проекта.

Фронтмен

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

Тимлид

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

Архитектор

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

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

Дополнительно: работа без посредников

Я хочу отдельно написать о работе без посредников, которую некоторые воспринимают как Святой Грааль для программиста. Казалось бы, все логично: находим заказчика, предоставляем ему свои услуги напрямую, весь рейт забираем себе — профит! Однако нужно понимать, что, кроме прибылей, на программиста в этом случае падают все сопутствующие риски. Нужно внимательно читать пункт контракта об ответственности сторон, знать законодательную и налоговую базу, придумывать механизм получения денег, действовать, если клиент не заплатил или неожиданно свернул работу.

В IТ-компаниях эти вопросы решают специально обученные люди (продавцы, юристы, бухгалтеры), и даже если заказчик разорился и вышел из бизнеса с сумасшедшими долгами, разработчики, во всяком случае в DataArt, все равно получат деньги в срок и спокойно перейдут в следующий проект. При работе напрямую — каждый оказывается сам за себя. Кроме того, большинство компаний тратят весьма осязаемые бюджеты на привлечение новых клиентов, поэтому прямые отношения с заказчиками, которых нашла компания, запрещены контрактом с той и другой стороны.

По этому поводу можно отдельную статью писать, но не привести мою любимую цитату с «Баша» я просто не могу:

Вы мне напоминаете моего домашнего кота. Он страшно переживает, что не умеет открывать банки с кошачьим кормом. День, когда он научится это делать, и станет независим от хозяина (а он так считает) — будет самым счастливым днём в его жизни. Вот только о том, откуда в квартире берутся банки с кормом, он не задумывается.

На этом мне хочется закончить на сегодня, если есть новые идеи для статей — пишите!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

�� Подобається Сподобалось 2

До обраного В обраному 3

Схожі статті

Як IT-спеціалісти першу роботу здобували. Сисадмін на заводі, Junior C++ за $200 і працівник НДІ

Анна Соха 22 червня 2020

Шлях стажера: Microsoft

Oleksandr Sochka 13 червня 2017

Шлях стажера: ELEKS

Ostap Kharysh 21 лютого 2018

Найкращі коментарі пропустити

Ничто не выдавало в авторе «погонщика». кроме последнего абзаца.

Дополнительно: работа без посредников

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

Хорошо, что я его тогда не послушал.

Суспільство без кольорової диференціації штанів не має цілі.

В дополнение к абзацу «Дополнительно: работа без посредников» — bash.im/quote/268537 =)

А вам не кажется, что требование к джуну

способность самостоятельно выполнять технические задачи

немножко перебор. Тем более, что вы нигде не пишете «под контролем старших товарищей».

101 коментар

Serhii Vasylenko Developer Experience Engineer в Grammarly 25.06.2019 17:09

Александр, спасибо за статью! Мне кажется, что она подходит и для градации operation engineers (или как нас еще называют — devops — хотя мы и не методология).

Все это ерунда. Автор выдает желаемое за действительное. По собственному опыту и не только, со всей ответственностью заявляю, что когда контора нанимает сениора, она даже не думает зачем и для чего. Видать для них это круто и модно. Никто его не слушает, ни ПМ ни заказчик. Относятся к нему примерно так же, как и к джуну. Когда ты уже окончательно достаешь руководство со своими предложениями/предостережениями и доказательствами, то в лучшем случае тебе скажут, чтобы ты заткнулся, мол тебя наняли не думать, а код писать. А в худшем случае, тебя уволят на хрен, при чем мгновенно и будут на твое место искать уже мидла, а то и джуна. Пока господа ПМ и всякие там СЕО и СТО не поймут, что вся ответственность по всем вопросам лежит на них, а не на на программистах, то всегда и будут «талантливые менеджеры» чмырить технарей. И эта статье прямое этому подтверждение. Поэтому многие толковые сениоры, которые не хотят идти на конфликт и что-то кому-то доказывать и объяснять, через пару месяцев своей работы на вопрос коллеги, что ты думаешь о нашем проекте, отвечает «мне по..уй!». И это реальность, а не фантазии и теоретические измышления.

Сергій Несходовський Chief Technology Officer в Sweet Stack digital 11.05.2019 12:03

Странная у вас контора, однако.

Совершенно верно описал.
И, причем, так везде и есть в реале.

Щодо останнього речення, схожі аргументи знайомому наводили коли він хотів покинути держ установу, а я рекомендував все ж таки спробувати аутсорсинг))

Oleg Kariakin Senior Java Developer 05.02.2018 13:25

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

Хотя по определению все трое являются разработчиками и если в JIRA написана херня, а PO нет, то и толку не будет. Разработчик не бизнес-аналитик и не будет вдумываться в тонкости бизнеса и сферы, он делает то, что написано в задаче.

Ок, допустим senior такой инициативный и будет предлагать свои задачи по масштабируемости/расширяемости и тд. как это затащить в борд? Согласится ли менеджер и PO с этим? В этом случае senior должен доказать целесообразность тех или иных задач и трат. Оно ему надо? Проект не его, прибыли он ему не приносит — нафига создавать себе лишние проблемы. Вдобавок, как правило, существует лобби со стороны заказчика, которые яро сопротивляются любым изменениям. Т.е. хотят ничего не менять, но запилить новые фичи побыстрее.

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

Євген Козлов Front-end developer в SoftServe 05.02.2018 13:42

Оно ему надо? Проект не его, прибыли он ему не приносит — нафига создавать себе лишние проблемы.

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

Oleg Kariakin Senior Java Developer 05.02.2018 14:16

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

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

Поэтому считаю разумным спокойно грести и не выступать.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 05.02.2018 23:27

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

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

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 01:48

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

Как насчёт конторы Интел? Достаточно ли крупный игрок? Мелкософт? Аппле? ХП? Циско? Нокия? Фольксваген? Тойота? Кого-то ещё забыл? Имя им легион все «созданные специально для освоения бюджета отдельно взятого» (к) (тм)

Євген Козлов Front-end developer в SoftServe 06.02.2018 09:29

а шо с ними? ну, кроме теорий заговора, типа «каждая следующая винда требует всё больше ресурсов»(на самом деле нет)?

Іван Довгай PHP Developer 13.02.2018 16:12

Когда то давно читал о том что майкрософт вставляла то ли в винрар то ли в какой то другой архиватор пустые циклы. Зачем — непонятно

Іван Довгай PHP Developer 14.02.2018 09:03

Нет, они потом ещё сами признали что так сделали.

Artem Trofimov Software development engineer в Oracle 05.02.2018 11:01

Спасибо, Александр, за подготовленный материал. Добавлю ссылку на замечательное выступление (2017г.) Рэндала Кутника из нетфликса о пути становления разработчика вообще и значении senior в частности www.youtube.com/watch?v=yIPbE7BssOs

Dima Meshkov Sr Developer в K+K 05.02.2018 10:56

Хаха, такое мог написать только теоретик, который к разработке ПО имеет никакое отношение:
— Если в проекте выстроена архитектура, он должен без задержки реализовать очередной кусок типовой логики приложения.

Max Shnurenok .NET Architect в LogiqApps AS 05.02.2018 12:17

Почему? Если логика типовая, то действительно должен.

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

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 05.02.2018 23:05

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

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 01:53

на практике продавать клиенту джунов под видом миддлов — верный путь угробить проект и навсегда испортить отношения с клиентом.

И заработать денег. Даже здесь на ДОУ были статьи из которых написано что на синьорах не зарабатывают.

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

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

Хотя таки да чисто технически проект видимо таки угробят опыт это фактами подтверждает.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 06.02.2018 08:59

Зачем их в таком случае вообще берут?

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

Добавлю — вчорашній джун може стати завтрашнім мідлов, на котрих вже заробляють

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 11:54

а може і не стати (к) (тм)

Lev Pasichnyi Senior DevOps Engineer в Avenga 03.02.2018 22:35

можно закончить owner-ом, сделать компанию и стричь купоны.

Oleksandr Merkulov asterisk guru 03.02.2018 07:29

А вам не кажется, что требование к джуну

способность самостоятельно выполнять технические задачи

немножко перебор. Тем более, что вы нигде не пишете «под контролем старших товарищей».

Александр Липских Oracle Developer в UNITY-BARS 03.02.2018 15:44

немножко перебор.

Чего вдруг?
Вопрос разве что в сложности задач.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 05.02.2018 12:48

А вам не кажется, что требование к джуну
способность самостоятельно выполнять технические задачи
немножко перебор. Тем более, что вы нигде не пишете «под контролем старших товарищей».

Честно? Ну вот не кажется. У нас джуниоры работают в реальных проектах, вместе со всеми, их работа также оплачивается клиентом. Заказчики и так зачастую пугаются фразы «джуниор разработчик», и убедить их хотя бы попробовать — не так легко. Поэтому джуниор, который хочет чего-то добиться, должен постоянно превосходить ожидания. А в такой формулировке, как вы говорите. Какую пользу проекту может принести разработчик, неспособный самостоятельно выполнить хотя бы простые технические задачи? Зачем он такой нужен?
Понятное дело, задачи у джуна совсем не такие, как у миддла и синьора. Конечно же, его никогда не закинут на проект, где вокруг сплошь незнакомые технологии. Разумеется, всегда есть люди, готовые помочь и подстраховать. Но бесконечно рассчитывать на помощь «старших товарищей» — это очень слабая стратегия. Поэтому лучше я немного завышу планку, чтобы люди, ориентируясь на неё, легче справлялись с реальными задачами, чем создам ложное ощущение, будто к джуну особых требований нет.
Если человек хороший, но немного не дотягивает — у нас есть практикантская программа как раз для этого, где опытный ментор всегда научит и подскажет, но это по нашей классификации — интерн.

Влад Соломенюк Senior UI/UX Designer в EProcurement 06.02.2018 16:24

Разумеется «завышу планку», ведь на джунов в компании на подобии вашей берутся мидлы, которым выплачивается пай джунов. Всё очень просто)

если есть новые идеи для статей — пишите!

Да, есть. Напишите про работу без посредников. А то вы так написали, как-будто надо столько всего знать, особенно какие-то «механизмы», а по факту — сиди и работай.

Pavlo Bida Test Automation Engineer 02.02.2018 23:40

А як же роки досвіду, мінімально необхідні для того чи іншого тайтлу?
Чи то все видумки компаній для стримання надто амбітних хлопців та дівчат?

Eugene Nyukers IT Professional 02.02.2018 18:35

Помогите меня определить в классификацию. Опыт есть, но другой. Английский средний, но не профильный. Кем я могу?

Victor Musienkо Senior Engineer в Noibu.com 02.02.2018 18:35

кем-то другим можете быть

Дмитро Python Tech Lead в Amplio 02.02.2018 18:04

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

Апворк забирает Механизмов для получения денег придумывать не нужно.
Сколько забирает датаарт? 60%?

Victor Musienkо Senior Engineer в Noibu.com 02.02.2018 18:35

а сколько Intellias?

Дмитро Python Tech Lead в Amplio 02.02.2018 18:43

думаю столько же

Дмитрий Мирошник Lead QA Automation Engineer 04.02.2018 04:02

Я думаю, тут немного другой расклад. В случае, если проекту не заплатили денег, вовлечённая в проект команда со стороны галеры получит денег с общего котла галеры. Вот именно с этих 60%, но другого проекта. По крайней мере, так стараются поступать все известные мне более-менее вменяемые крупные галеры.
В случае, если Васе Пупкину, работающему через апворк, не заплатили денег, пойдёт ли апворк забирать деньги у заказчика? Или просто предложит Васе лично разбираться с заказчиком, а в случае успеха отдать положенный % апворку?
Или, к примеру, как поступит апворк в случае claim’а типа «да он мне вообще не тот проект написал!» А исходнички уже, разумеется, у заказчика. Оплатит ли апворк Васе юриста в стране заказчика, чтобы доказать, что проект соответствует техзаданию и имело место нарушение контракта? Или опять-таки предложит бодаться самостоятельно и за свой счёт, а в случае победы перевести % за посредничество?

Slava Ruby on Rails developer 05.02.2018 05:58

Я думаю, тут немного другой расклад. В случае, если проекту не заплатили денег, вовлечённая в проект команда со стороны галеры получит денег с общего котла галеры. Вот именно с этих 60%, но другого проекта. По крайней мере, так стараются поступать все известные мне более-менее вменяемые крупные галеры.

Вы так говорите, как будто это ядерная физика какая-то. Вася Пупкин, точно также как и компания, покрывает риски засчет дополученных 60% с каждого из других нормальных заказчиков. А если работать только с западными клиентами и забыть о рынке СНГ, то таких заказчиков будет 95%, если не больше. В итоге денег Вася заработает намного больше. Так в чем прикол?

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

Євген Козлов Front-end developer в SoftServe 05.02.2018 12:52

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

Oleksandr Merkulov asterisk guru 05.02.2018 18:44

Фриланс не настолько рисковое дело. Если придерживаться неких правил вполне стандартных, то невыплаченные деньги составляют меньше 1%(по моей статистике)

Alex Fogol Software Developer, C/C++ Expert 06.02.2018 01:57

Говорят в соседнем районе погонщики нередко так или иначе задерживают и вообще удерживают последнюю з.п. итого исходя из среднего срока текущего погода 2 лет выходит риска порядка 4% на одной только з.п.

Oleksandr Merkulov asterisk guru 05.02.2018 18:41

Да, апворк заплатит. У меня вот сейчас странный клиент, у него постоянно не проходят платежи(каждую вторую-третью неделю). Апворк — платит, за почасовку. Вне зависимости от того, что они там обсуждают с клиентом насчет оплаты. Просто приходит письмо, что платеж неудался, не работайте временно.Потом письмо, что ваши часы elegible и оплачены апворком, потом приходит письмо о востановлении метода платежа и включении контракта.
Более того, даже если ваши часы совершенная ерунда, если вы соответсвуете формальным правилам — у вас корректное memo и activity, апворк вам заплатит. Другой вопрос, что потом будет в отзыве от клиента. И да, дальше апворк бодается с заказчиком своими юристами.

Апворк может и не самая дешевая биржа(до 20% комисии), но уж hourly protection у них работает. Кроме случая ворованной карты.

Ivan Voloshchuk сплавился по Днепру в Worldwide Downshifter Corp. 05.02.2018 19:12

Апворк может и не самая дешевая биржа(до 20% комисии), но уж hourly protection у них работает. Кроме случая ворованной карты.

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

Oleksandr Merkulov asterisk guru 05.02.2018 19:25

За последние годы мне не выплатили ВСЕГО — прошлый год 0.28% из них по моей вине 0.08%, позапрошлый год — 0.35%, по моей вине — 0. Для сравнения, биржевые проценты 8.5%/5.1%, коммисии вывода в этом году 2%+5%(налог на спрощенной)+курсовая разница порядка процента. Тоесть риски невыплат можно считать нулевыми.

Євген Козлов Front-end developer в SoftServe 05.02.2018 21:11

это первый год? или какой там стаж?

Oleksandr Merkulov asterisk guru 05.02.2018 22:11

15 лет в области, 10+ лет фриланса.

Як гадаєте — коли на Upwork (та йому подібні сайти) варто працювати для Additional income, а коли вже варто міняти фултайм на дистанційну роботу?

Oleksandr Merkulov asterisk guru 05.02.2018 22:13

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

«Коли» — мається на увазі в роках досвіду (приблизно).

Oleksandr Merkulov asterisk guru 06.02.2018 11:47

Как повезет. Но первые годы обычно швак. Думаю, без лет опыта соваться смысла нету.

Так і приблизно гадав 🙂

Как-то очень странно определили критериями миддла и сениора глубиной погружения в бизнес-процессы и бизнес-проблемы клиента.
То есть, уровень программиста определяется уровнем его знания конкретной предметной области?
Тогда он уже растёт в сторону бизнес-аналитика, а не программиста.
Если он не знает, чем отличается абстрактный класс от интерфейса и не понимает, что такое монитор потока, но при этом наизусть помнит все хитросплетения бизнес-логики какого-то конкретного зазказчика (и тот готов за него платить соответственно, не видя его кода) — это сениор?
Для этого заказчика — возможно. Но если он пойдёт на собеседование на другой проект/другую компанию — можно ли его представлять как сениора, или хотя бы миддла?
Технически — это программист-джун. По знанию бизнес-логики конкретного клиента — это миддл БА.

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 03.02.2018 10:38

Я приведу пример. Допустим, у заказчика на фронтэнде испольуется какой-нибудь очень хитрый фреймворк, вокруг которого все построено. Человек с ним досконально разобрался, и замечательно решает все возникающие вопросы. Будет ли он там синьором? Скорее всего — да. А потом проект закончится, человек уйдет искать работу, и его будут оценивать на джуна, потому что он никогда не работал с реактом или ангуляром, а про тот хитрый фреймворк интервьюеры даже не слышали. Значит ли это на самом деле, что человек — джун? Ответ не так очевиден. С моей точки зрения, это, скорее, вопрос стратегии профессионального развития. Есть какая-то общая база знаний, которая везде используется. Таким знаниям легко найти применение, но очень много заработать на них сложно — собственно потому, что это умеет практически каждый. А есть узкие специальные навыки, которые сильно ценятся на конкретном проекте, но потом им может быть сложно найти применение где-то еще. Нахождение баланса между первым и вторым — задача, к решению которой нужно подходить ответственно и осознанно.
Что до погружение в бизнес-проблемы клиента, то я считаю это совершенно необходимым навыком. Разработчики, которые пишут код ради кода, не видят «большой картинки» и ценят в работе превыше всего изящность программных решений, превращаются со временем в «архитектурных астронавтов» (как их называл Джоэль Спольски). Знания интерфейсов, фреймворков и методов ничего не стоят, если не позволяют вам решать задачи бизнеса быстрее и лучше. Если человек не понимает, чем отличается интерфейс от абстрактного класса — значит его решения, скорее всего, будут слабыми и ненадежными, а, значит, он не решает проблемы бизнеса, а множит их — это никак не синьор.

Олександр Шпак Oarsman в Self Employed 03.02.2018 11:16

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

Реготнув трохи. Розробникам драйверів на Сі розкажіть, що вони не вирішують проблеми бізнесу та не сіньори а так собі. Або тим, хто пише ядра ОС.
Наприклад, я не бачу взагалі різниці між класом, інтерфейсом, абстрактним класом, прототипом. Це лише одні із способів організації різних абстракцій та взаємодії між ними. «Абстрактний клас» можна зробити навіть в не ООП мовах. Наприклад, в CSS можна використовувати аналогічний підхід. А «інтерфейс» то взагалі можна організувати на JSON або XML. Тому що інтерфейс — підхід, а не конкретна реалізація конкретної мови програмування.
А тепер уявіть собі діалог

В чому різниця між абстрактним класом та інтерфейом?
Не бачу особливо різниці

Ви нам не підходите

Max Shnurenok .NET Architect в LogiqApps AS 03.02.2018 11:59

Если человек, прекрасно понимая вопрос и контекст, начнёт показывать своё ЧСВ вместо того, чтобы по-человечески объяснить точку зрения, я б ещё и подтолкнул в направлении выхода бгг.

Олександр Шпак Oarsman в Self Employed 03.02.2018 12:20

Співбесіда — це місце, де покидьки міряються своїм ПВВ. Задача одних — довести своє звання сіньора, а інших — довести, що сіньори — паперові. 😉

Ievgen Safronenko Senior Software Engineer в zooplus 03.02.2018 13:34

вы как то не правильно написали МПХ

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 03.02.2018 12:18

Хороший интервьюер непременно постарается разобраться, что именно вы имеете в виду, когда даете тот или иной ответ. А если подход к делу такой, как вы описываете (не совпало с «ключом» — минус и «до свидания») — возможно, действительно не стоит работать в такой компании.

Реготнув трохи. Розробникам драйверів на Сі розкажіть, що вони не вирішують проблеми бізнесу та не сіньори а так собі. Або тим, хто пише ядра ОС.

Если кто-то оплачивает вашу работу — значит, есть план, как на этом заработать (даже если ПО с виду бесплатное). То есть это бизнес, и вы решаете какую-то его проблему 🙂 Чем лучше вы понимаете, какую именно, тем больше у вас возможностей увеличивать свою ценность. Разработка драйверов является неотъемлемой частью вывода устройства на рынок, поэтому каким образом вы пришли к выводу, что она не влияет на бизнес — непонятно.

Олександр Шпак Oarsman в Self Employed 03.02.2018 12:24

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

Ні, це ви спочатку поясність свої слова

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

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

Alexander Demura Head of DataArt’s R&D Center in Odessa в DataArt 03.02.2018 13:04

Ну так у нас, вроде как, даже никакого противоречия нет. Я уже выше писал, что

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

Поэтому заваливание кандидатов на собеседованиях каверзными вопросами о тонкостях внутреннего устройства той или иной библиотеки я считаю занятием бессмысленным. Но и сосредотачиваться исключительно на решении сиюминутных проблем «в лоб» тоже нельзя. Все-таки паттерны и подходы к разработке были придуманы не просто так. Если каждая решенная вами задача в перспективе превращается в две проблемы, которые придется решать позже — ваша ценность для бизнеса под большим вопросом (хотя можно теоретически придумать ситуацию, когда и это оправдано). Также это касается бездумной копипасты с какого-нибудь stack overflow. С виду-то оно работает, а потом неожиданно начинаются какие-то побочные эффекты, и без понимания, что там на самом деле внутри происходит, найти проблему может быть довольно трудно.

Допустим, у заказчика на фронтэнде испольуется какой-нибудь очень хитрый фреймворк, вокруг которого все построено. Человек с ним досконально разобрался, и замечательно решает все возникающие вопросы. Будет ли он там синьором? Скорее всего — да. А потом проект закончится, человек уйдет искать работу, и его будут оценивать на джуна, потому что он никогда не работал с реактом или ангуляром, а про тот хитрый фреймворк интервьюеры даже не слышали.

Во-первых, знание одного-двух фреймворков не делает разработчика сениором. Даже если он эксперт в этих фреймворках.
Если интервьюеры не слышали о популярных фреймворках — это говорит об уровне интервьюеров и их способности оценить уровень кандидатов. Я тоже не знаю досконально всех фреймворков в своей отрасли. Но хотя бы помню, как называются основные и что они примерно делают и какие дают плюсы. Человек, работавший со многими фрейморками, уже быстро разберётся с теми, которых не знал, т.к. поймёт, к какой группе новый фреймворк относится, какие задачи выполняет и какие имеет плюсы/минусы в сравнении с существующими аналогами.

Разработчики, которые пишут код ради кода, не видят «большой картинки» и ценят в работе превыше всего изящность программных решений, превращаются со временем в «архитектурных астронавтов» (как их называл Джоэль Спольски). Знания интерфейсов, фреймворков и методов ничего не стоят, если не позволяют вам решать задачи бизнеса быстрее и лучше.

Насчёт «большой картинки» согласен не вполне. Предметных областей много, задачи их часто диаметральны, проектов в жизни разработчика из разных областей может быть десятки.
Тут уже скорее задача продакт оунера прозрачно предоставить разработчику свои приоритеты, а не разработчику используя телепатию и эрудицию их угадать. Ну или не угадать.
Задача всех без исключения фреймворков — повысить велосити разработки без увеличения уровня технического долга. Это просто инструменты, которые позволяют программисту получать более стабильный результат более быстро. И умение их эффективно использовать — показатель уровня. А никак не знание «карате, бокса, кунг-фу и других страшных слов».
Скажем так: программист — это как автогонщик в ралли. Его задача настроить машину оптимальным образом, доехать максимально быстро в целости и сохранности. А вот КУДА доехать и КАК ехать — уже задача штурмана. Чтобы каждый мог максимально сфокусироваться на своей задаче и решить её наилучшим образом. И гонщик, постоянно сверяющийся с картой, всегда проиграет коллеге, которому надиктовывают все повороты и он может полностью сосредоточиться на управлении.

Дмитрий Мирошник Lead QA Automation Engineer 04.02.2018 04:28

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

Не соглашусь. Видите ли, PO не обязательно будет технически подкован и совсем уж необязательно он будет технически подкован в используемых фреймворках. Задача PO — сформировать пул приоретизированных user stories. Таким образом, PO говорит Вам ЧТО делать, но не КАК делать. Ответ на последний вопрос — исключительно в Ваших руках. Пользуясь Вашеми аналогиями, PO — это не штурман, который надиктовывает Вам повороты. Если у Вас есть такой PO — это счастье, поскольку Ваш проект в этом случае могут выполнить несколько джунов и неплохой миддл как тим лид и код ревьювер. Но обычно PO — это скорее человек, который каждый день ездил на работу по марштуту Вашей гонки. эдак лет 10 назад. Надиктовывать Вам повороты он не может, патамуша у него карты нет. Всё, что он может — это сказать «на этой развилке двигаемся прямо, тут дорога лучше. Ну или была когда-то лучше :)». То есть, его роль — скорее навигатор, который может подсказать Вам, где повернуть, чтобы Вы не заблудились в лабиринте бизнес-домена.
Пользуясь приведенным выше примером, PO скажет «нам нужно хранить данные о транзакциях в БД это приоритет № 1», а вот упомянуть, что эта БД должна, к примеру, поддерживать транзакционную модель и в случае неуспешной транзакции иметь возможность роллбэка, чтобы не испортить связность данных — об этом он не скажет, он и слов-то таких не знает. Это должны продумать Вы сами, пользуясь, в том числе, знаниями бизнес-домена, чтобы ответить себе на вопрос «а как повлияет на бизнес неуспешная транзакция? Что им важнее: сохранить хоть какую-то часть этой транзакции или сохранить связность данных, потому что БД нужна, чтобы в будущем иметь возможность получать сводные аналитические отчёты». Если Вы этот вопрос себе задали только тогда, когда PO вам сказал, что отчёты — это приоритет № 1 — Вы в лучшем случае потеряете несколько недель, пытаясь вычистить из разросшейся на несколько сотен гигов продакшен базы несвязные данные, переписывая код на другую модель хранения неуспешных транзакций, чтобы исключить несвязные данные в будущем, перестраивая индексы ну и т.д. В худшем случае — Вы завалите проект, потому что его архитектура попросту не предусматривает тех изменений, которые внезапно потребовались. It’s a scrum, baby 🙂
Поэтому хотя бы базовые знания бизнес-домена для программиста выше миддла — обязательны. Иначе получится набор майоров без маршала: свой участок фронта держим, а что на соседнем — без дупля, поэтому радостно попали в окружение, поскольку майор, отвечающий за соседний участок, абсолютно тактически оправданно приказал оставить данный участок. А тому, со своей колокольни, абсолютно неинтересно, что творится на Вашем участке фронта: зачем это ему, у него свой участок есть.
Узкое тактическое мышление — это прекрасно для миддла. А выше — необходимы хотя бы базовые навыки стратегического мышления. А в лиды без оного лучше вообще не соваться.

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

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

Поэтому хотя бы базовые знания бизнес-домена для программиста выше миддла — обязательны.

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