Карьера в IT-индустрии

Какие выгоды получает компания нанимая джунов и трейни

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

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

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

? Джуны и трейни  – потенциальный источник новых идей и подходов. Они с удовольствием освоят новое направление.

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

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

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

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

Что еще Вы бы добавили в этот список или убрали?

Собеседуйте работодателя

Собеседование всегда работает в обе стороны. Не только компания выбирает сотрудника, но и сотрудник выбирает компанию.

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

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

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

Генеральный директор Amazon начал угрожать сотрудникам на удалёнке санкциями. Энди Ясси заявил тем, кто не хочет возвращаться в офис: «У вас это не сработает». 

Работники Amazon должны посещать в офис три дня в неделю, начиная с мая. Однако некоторые удалёнщики ответили на принудительное возвращение в офисы забастовкой.

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

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

Как понять справедливую цену за свою работу

Есть один беспроигрышный вариант.

Надо просто повышать по чуть-чуть цену каждому следующему клиенту.

Написали текст за 5000 рублей, следующий пишем за 5500. Следующий за 6000, потом 7000. И так постепенно на 5-10% ползем вверх.

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

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

Прокачались — и снова ползем вверх по чуть-чуть.

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

Вопрос: Как джуну сейчас устроиться на работу?

Большая просьба поделиться вашим опытом о том как вы устраивались/искали/собеседовались на вашу первую работу (или если вы hr - собеседовали джуна).
Джунов (привет собратьям по несчастью) тоже приглашаю в комментарии задавать вопросы (буду помещать их в UPD).

Я сейчас учусь в вузе и пытаюсь найти свою первую работу (со школы прилично зарабатываю на фрилансе, но хочется иметь стабильный доход). У меня следующие вопросы:

• Сколько нужно иметь опыта? Считается ли фриланс? Какой лучший способ подтвердить опыт? Какие навыки необходимы?

• Сколько можно просить зп?

• Где лучше искать работу?

• Стоит ли идти в ноунейм компанию?

• Что обычно отпугивает hr-ов в резюме?

• Реально ли устроиться до 3го курса вуза(или вообще на первом)?

• Есть ли что-то принципиально отличающее постоянную работу от фриланса?

• Реально ли имеет значение вуз при приеме?

• Спрашивают ли литкоды и алгоритмы? (Если собеседуешься например на web-программиста)

• Сколько можно врать приукрашивать в резюме?

Компетенции технического продакт менеджера

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

Ну а как это проверить? Может, проверить что знает эту "технину", на уровне джун-разработчика? А еще надо чтобы что-то про структуры и хранение данных понимал, может, и SQL немного проверим?

Но такой подход приведет к тому, что наймем продакт менеджера, который может "hello world" написать. Ну, или логи прочитать. Но это ли нам нужно?

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

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

Телеграм канал Чуть больше продакта

Хотите расти — общайтесь с людьми

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

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

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

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

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

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

Проверено сотни раз и на моем опыте, и на опыте знакомых.

Привет! Приглашаем на бесплатный вебинар Практикума: Q&A-сессия о работе фронтендера 26 июня в 19:00

Кому будет интересно:

• Тем, кто выбирает профессию в IT. Узнаете, в чём особенности и преимущества работы фронтендера, примерите профессию на себя

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

Спикеры:

• Руслан Посевкин, фронтенд-разработчик в международной платформе для фрилансеров Toptal 

• Полина Бушкова, куратор на курсе «Фронтенд-разработчик» в Практикуме

Точно расскажем:

• почему фронтенд-разработка — хороший вариант для старта в IT;

• что особенного в работе фронтендера: технологии, инструменты, задачи;

• насколько реально новичку найти работу.

Спросите экспертов про: 

• задачи разработчиков,

• необходимые навыки, 

• вакансии, 

• зарплаты, 

• перспективы для новичков,

• что угодно ещё.

Регистрируйтесь по ссылке и задавайте вопросы прямо в этом посте — передадим их спикеру!

Что самое важное в сложном B2B

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

Не выйдет просто налить трафика, получить лиды и сконвертировать их в продажи.

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

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

А что тогда делать, чтобы получать клиентов?

Строить с ними отношения.

Знакомиться на конференциях. Френдиться в соцсетях и общаться. Вести блог, который интересен сотрудникам крупных компаний, и общаться с ними в комментах. Звать их на свои вебинары в качестве гостей. Просить текущих клиентов познаковать вас с кем-нибудь из коллег. Да хоть в бар вместе ходить.

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

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

Я задаю вопросы про паттерны на собесах

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

Но не вижу ничего противоестественного в этом вопросе для других категорий соискателей.

Во-первых, кто-то своей собственной рукой пишет "design patterns" в разделе "навыки". За язык никто не тянул, как говорится.

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

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

Возможно, неприятие вызывает сама форма вопросов. Я считаю, что трясти с кандидата UML-диаграммы или энциклопедические определения - такой же бред, как вращать деревья на доске. Мой обычный вопрос: "Хорошо, вы рассказали про @Transactional. А какую проблему в целом решает прокси?". Вопрос простой для тех, кто в работе мыслит за рамками "делал таски, правил баги".

Слушающий тебя да получит знания, не цифры

В последнее время почти весь фидбек, который я даю коллегам (преимущественно джунам) содержит следующий совет. Когда кому-то рассказываешь про что-то сложное, с кучей технических деталей, держи в уме вопрос «А какие знания слушающий меня получит?». То есть давай человеку знание и подкрепляй аргументы цифрами. Особенно, конечно, если слушающий тебя не очень технически подкован и вообще менеджер. В целом это про софт-скиллы: смотришь на реакцию слушающего тебя человека, если видишь, что человек начинает ерзать, проявлять нетерпение или (о ужас) параллельно проверять почту, наверное он не получает нужное количество информации в единицу времени (мне нравится термин low-bandwidth conversation). И тогда надо что-то менять в стиле подачи информации. 

В контексте ML можно рассмотреть:

• Пример 1: «я обучил fasttext с 5-граммами в 3 эпохи, поучил 67.45% F1, голый SciBERT выдает 72.1%, далее я применил pseudo-labeling с GPL, вот простыня с результатами экспериментов»

• Пример 2: «В задаче классификации книг для заказчика X мы получили бэйзлайн с 75% F1, фидбек от заказчика положительный. Технические детали доступны по ссылке» 

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

Я даю тестовые задания

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

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

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

Само собой:

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

• техническое задание решается за 10 минут тем кто знает решение, либо за 1 час тем кто не знает но хочет

• у задания есть несколько разных по качеству решений

• в результате должна появиться примерно страничка написанного кода на пару методов

И нет, это не олимпиадное программирование с LeetCode, а обычно что‑то из наболевших рабочих вопросов.

Примеры таких тестовых тем:

1. нестандартный валидатор

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

3. пагинатор на больших таблицах

4. сложный запрос или несколько отдельных

5. интерфейс для классов, делающих то‑то (привет PSR)

6. есть такие данные, нужно найти вот это (привет алгоритмы)

Кто поопытнее, часто не пишут код а предлагаю решение текстом, вроде «собрать сводную таблицу из двух подзапросов по этим индексам, сагрегировать там и отсортировать тут.

Недавно заходил пить чай к коллеге IT-шнику из другой компании. Зашла речь о струкртуре рынка труда в IT. Коллега неожиданно в обсуждении сказал "Но ведь 99% всего программирования это сайты для продажи чего-то, а их легко автоматизировать, так что много программистов не нужно ... далее как водится речь пошла о ChatGPT"

Это напомнило мне разговор в начале 2000-х где другой коллега рассказывал мне что Delphi это вообще игрушка, на Delphi никто не пишет и все программы написаны на C++. Аргумент был такой - ну посмотри, вот из того что у тебя установленно на компьютере, все написано на С++. Я к тому времени уже успел посмотреть на внутреннее устройство IT нескольких крупных предприятий и звучало аргумент несколько смешно.

К чему я это - IT оно очень обширное и разнообразное. Но в силу несколько специфической надутости пузыря люди со стороны часто могут видеть наиболее надутую часть и соотвественно ориентироваться именно на нее.

"Плагины к Вордпрессу, вот где деньги! Я уже 2 года в IT все в совершенстве изучил и у меня есть плагин за 10 баксов который даже покупают, это дает мне пассивный доход и скоро я стану миллионером"(С) реальный персонаж.

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

Надо разработать класс который запоминает текстовые заметки к точкам на карте. Одна точка - одна заметка. Карта дискретная, 10,000 на 10,000 точек. Заметок всего ожидается несколько дюжин, максимум 100-200 штук.

Класс должен имплементировать следующий интерфейс

public interface MapService {

    void addLabel(int x, int y, String label);

    String fetchLabel(int x, int y);

}

addLabel - сохраняет заметку для точки на карте, перетирая предыдущую если она есть

fetchLabel - возвращает заметку для точки на карте, если заметки нет, возвращает null

Вопрос - какую структуру данных в памяти следует использовать для хранения данных

Уточнение которое надо задать после ответа на первый вопрос. Требования дополнились и теперь надо имплементировать еще один метод

List<String> fetchAllLabelsSorted();

Метод возвращает все заметки какие есть в порядке их близости к центру координат - точке (0,0)

Бонус: В плюс идет если кандидат спросит по какой метрике считать близость к центру.

Вопросы к собеседованию (#1)

Вопрос про реляционным БД. Уровень - продвинутый. Однозначно верного ответа на вопрос по ходу дела нет, но интересен ход мысли интервьюируемого.

Дано: трех звенная архитектура - клиент, load balancer, несколько stateless серверов, реляционная БД (пусть будет postgres, но критично)

В БД есть таблицы school и subject

У subject поле school_id может быть null - это значит, что предмет относится ко всем школам ассоциации школ. Если school_id не null значит предмет специфичен только для этой школы.

Надо реализовать ограничение:

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

Например:

1. У школы id:42 есть предмет "математика викингов" - нельзя создавать еще один предмет "математика викингов" для этой же школы. Но другие школы такой предмет создавать могут

2. Есть предмет "геометрия" у которого school_id is null. Т.е. предмет относится ко всем школам. В таком случае нельзя создать еще один предмет "геометрия" ни в ассоциации, ни в одной из школ. Это имя полностью уникально.

Вопрос: Как собственно такое ограничение реализовать. Какие есть возможные варианты.

Бонус: В плюс идет вопрос кандидата - "что делать если у школы есть предмет геометрия и теперь такой предмет надо сделать на уровне ассоциации".

Меня часто не спрашивают:

Как оценить грейд разработчика?

Всё очень просто:

• Может самостоятельно всё разработать? Это Middle

• Не может без помощи наставника? Тогда это junior

• Разработает лучше, чем просили? Ну это настоящий Senior!

• Сумеет спихнуть разработку на другого? Это уже LEAD.

Или короче, для тех, у кого нет времени читать этот лонгрид:

• Junior - учится работать.

• Middle - работает.

• Senior - учится не работать.

• Principal - не работает.

Картинок, сгенерированных нейросетью, добавьте по своему вкусу.