×

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

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

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

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

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

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

Интерн

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

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

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

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

Junior

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

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

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

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

Middle

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

Таким образом:

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

Senior

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

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

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

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

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

Что дальше?

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

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

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

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

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

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

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

Фронтмен

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

Тимлид

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

Архитектор

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

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

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

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

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


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

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

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

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

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному3
LinkedIn

Схожі статті




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

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

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

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

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

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

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

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

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

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

101 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но другой.

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

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

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

а сколько Intellias?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дякую.

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

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

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

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

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

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

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

  • В чому різниця між абстрактним класом та інтерфейом?
  • Не бачу особливо різниці
Як ви думаєте, який результат співбесіди буде?
  • Ви нам не підходите
Хоча це вони не підходять розробнику.

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

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

своїм ПВВ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проект — это по-хорошему 3-4 месяца. Дальше всё, следующий, от другого заказчика с другой бизнес-логикой.

Для проектов 3..4 месяца это, возможно, и излишне. За это время Вы просто не успеете набрать критическое количество знаний бизнес-домена, чтобы это стало полезным. Я говорил о проектах длительностью хотя бы от года. На микро-проектах синьоры не нужны, ИМХО. Там вполне хватит хороших миддлов и типовых решений из говна и палок, поскольку сложная архитектура, расширяемость и пр. такому приложению попросту не нужны. Тут идёт схема сдал — забыл, а над дальнейшей судьбой приложения пусть долбутся следующие аутсорсеры :)

Я говорил о проектах длительностью хотя бы от года. На микро-проектах синьоры не нужны, ИМХО. Там вполне хватит хороших миддлов и типовых решений из говна и палок, поскольку сложная архитектура, расширяемость и пр. такому приложению попросту не нужны.

Ошибаетесь.
Просто критерии «синьйорности» другие.
Тут это способность запихнуть в эти 3-4 месяца максимум функционала, наломав минимум дров (дабы потом за свой счёт фиксить минимум багов и быстрее получить аксептанс от клиента и инвойс). И для этого знания фреймворков, правильный выбор архитектуры и уместное использование паттернов — маст хэв.
К примеру, типичное приложение делает 20-30 разных рест-запросов. Без удобного фасада для них — не обойтись.
Решение из говна и палок создаст трудноразрешимые проблемы уже на этапе аксептанса. И затянет сроки с 3-4 месяцев до года и более. За те же деньги.

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

Некоторые компании так уже лет 10 делают. И даже вполне открыто запихивают «подкапотную» часть аппликухи в доморощенный фреймворк, ориентированный на решение определённого круга бизнес-задач. И даже зарабатывают на продажах этого фреймворка. Но за пределы своей бизнес-ниши им выйти сложно, что ограничивает их рынок сбыта.
Есть только пара проблем.
У меня за 6 лет было чуть более десятка проектов.
И только в паре из них некоторые части бизнес-логики были схожи настолько, что было возможно «выдернуть» модуль из одной аппы и впихнуть в другую.
И второй момент: 70-80% времени на разработку — это борьба с юаем. Как раз тем, который точно будет уникальным.

Я думаю вы зря считаете что программисты такие тупые и не понимают какой болью достаются клиенты)

почему сразу тупые? ) Если человек крут в ИТ не означает автоматом, что он крут во всём. У всех свои таланты. У меня много знакомых лансит или лансили, но по-настоящему крутые ребята, например в high load оказываются зачастую не имеют ни времени ни желания (читай таланта) заниматься продажами, маркетингом и банально даже толковым инвестированием заработанного :)

То, что они не занимаются или не могут заниматься этим, не значит, что они не понимают, что это сложно. Они не обязательно рассуждают как тот кот. :)

Имхо сильно урезано и размыто между джуниор и интерн. Интерн это «ученик на практике», такой себе выпускник ВУЗа или курсов вайти. Был на интернских программах в паре компаний Днепра. По сути это большей частью отсев лишних + всё-таки учеба. Насыщенная, толковая, порой через чур интенсивная. Именно обучение людей с «ненулевыми знаниями» под свои нужды конкретной компании и проекта. А джуниор — это человек, который уже может решать задачи но пока имхо далеко «не самостоятельно» )

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

ИМХО скипнут огромный кусок работы синьора и лида.

Для джуна важны следующие качества:
Желание развиваться и учиться (а на своих ошибках — особенно).

+1. А учит профессии, развивает и воспитывает их — кто ?

<Жарт>
Youtube та дедлайн :)
<*СЛЕШ*Жарт>

тогда я б сказал — «жисть научит» :8)

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

Такого бусту в навчанні я не мав вже з місяці 3-4

Про синьора и так написано подробнее, чем про кого-либо. И да, можно было написать еще в три раза больше. Вопрос глубокий, в Одессе даже IT Talk был на эту тему:
www.youtube.com/watch?v=6xka3Xveqq0
Что до обучения джунов — с моей персональной точки зрения, это, скорее, социально ожидаемое поведение от синьора, нежели прямо обязательное требование. Как не уступить место в общественном транспорте — все будут коситься, просить, упрекать, обязательно при случае припомнят, но формально состава правонарушения нет. Хороший синьор, разумеется, распространяет вокруг себя полученный опыт (и я про это писал), но если человек удовлетворяет всем остальным критериям, но по какой-то причине категорически не хочет возиться с джунами — является ли это поводом «срывать погоны»?..

Про синьора и так написано подробнее, чем про кого-либо.

Я раписывал в конторе служебные обязанности девов лет 6 тому взад, и категорически с Вами согласен: про синьоров таки приходится писать подробнее, чем про кого-либо :)

...но формально состава правонарушения нет.

Допустим, все синьоры так и подумали: состава нет, з-п нам не уменьшат, так зачем с салагами возиться !? Что дальше?

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

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

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

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

Ну английский-то у вас является поводом, не так ли? Так чем софтскилы хуже?

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

Но одно дело — объяснять команде ..., и другое — помогать джуну

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

Английский важен потому, что на нём ведется основное общение.

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

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

Да.

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

Учить английский и не претендовать пока на лидство :8). Это реально, и через полгода максимум он будет на планнинге не лишним. А софт-скилам, например преподаванию, не очень-то и научишься: как Вы говорите, или Бог дал, или «не очень» ... вот и задачка: что важнее найти при найме.

Нормальных решений вопроса много. Можно еще некоторое малое время жить надеждой, что «нам свой Education не нужен, позовем синьоров с других контор». В конце концов, можно, например доплачивать за преподавание. Но, во-первых, ИМХО важно — не хочет человек проявлять софт-скилы, или таки не умеет. Во-вторых, я уверен, что «погоны вешают» в первую очередь за профессиональные качества. И синьор может вполне быть отшельником. Или не уметь преподавать. Быть лишенным ораторского таланта. Ужос — не повляться на тим-билдингах :) Не знать английский на уровне advansed, но посещать занятия по этому уровню. Каждая контора, конечно, вольна выставить свои «весы» таким недостаткам, и прощать их все, или не прощать ни одного.
Так что мой интерес к вопросу возник элементарно потому, что Ваша контора уж слишком известна своим м-м-м преувеличенным вниманием к м-м-м только Вам известным навыкам английского :8), тем более мне странно, что Вы теоретически (наверно и практически) готовы жертвовать софтскилами. Спасибо.

Каждая контора, конечно, вольна выставить свои «весы» таким недостаткам, и прощать их все, или не прощать ни одного

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

Так что мой интерес к вопросу возник элементарно потому, что Ваша контора уж слишком известна своим м-м-м преувеличенным вниманием к м-м-м только Вам известным навыкам английского :8).

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

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

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

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

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

Не надо выпрашивать отпуска и нервничать из-за опозданий.

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

У меня есть — и че? У меня начальник сам спрашивает, когда я в отпуск пойду :)

у вас точно фриланс, а не ремоут?

Не было, но зачем брать контракт с таким ограничением, если есть другие контракты без ограничения?

полностью согласен.
собственно, как и

выпрашивать отпуска и нервничать из-за опозданий

это тоже вопрос внимательного выбора компании. а не только формы занятости.

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

вы говорите как будто это что-то плохое

Вы это сейчас о чём?

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

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

краткое содержание: «имярек должен уметь решать поставленные задачи»
как насчет шага вверх и в сторону — стать акционером?

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

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

Классика. Теплый, ламповый башорг 2007 года, еще с подонками)

Интересная статья, спасибо!

Підписатись на коментарі