Русский
Русский
English
Статистика
Реклама

Рынок труда в ит

Премии, льготы и бонусы в IT результаты исследования Хабр Карьеры

18.06.2020 16:09:14 | Автор: admin


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

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

Из полученных ответов мы сделали наглядные диаграммы и хотим поделиться полученными инсайтами.

Кто принял участие в опросе
В опросе приняли участие 1200 человек пользователи Хабра и Хабр Карьеры. 58% из них разработчики, 85% имеют квалификацию middle и выше, 55% работают в продуктовых IT-компаниях. 56% в возрасте от 25 до 35 лет, 82% мужчины.

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














Насколько распространены премии, льготы и бонусы


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

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

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

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


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

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


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

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




Что со льготами


Какие льготы предлагают своим сотрудникам компании? Что они готовы компенсировать полностью или частично? И что может влиять на удовлетворенность получаемыми льготами?

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

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

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

Следом идёт компенсация услуг фитнеса, но в нетехнических компаниях такая льгота встречается заметно реже, чем у других.


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




У некоторых компаний есть возможность самостоятельно выбирать льготы, это называется кафетерием льгот. Эта практика не сильно распространена, так как требует от работодателя дополнительных как финансовых, так и организационных издержек. Как видим, не более 20% компаний практикуют такую систему.


Возможность выбирать льготы, довольно сильно влияет на удовлетворенность ими.




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



Что с премиями


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

Как видим, премии в среднем составляют порядка 20% в общем годовом доходе айтишника. В продуктовых компаниях эта доля повыше, в нетехнических пониже.


Чаще всего премии составляют 10% от годового дохода сотрудника, далее с одинаковой частотой идут премии, составляющие 5, 15, 20 и 30%.


Заметно выше среднего доля премии у менеджеров и администраторов, заметно ниже среднего у дизайнеров. Но всё равно разница со средним не сильно большая.


Доля премии в их годовом доходе у руководителей чуть выше, чем у специалистов.




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


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




Премии могут быть персональными и коллективными. В IT распространены и те, и другие, персональные заметно чаще.


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




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


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




Результат премируется реже других у менеджеров и дизайнеров. Более того, последние чаще премируются предустановленной суммой, чем по результату.

Личные достижения чаще других премируются у администраторов и тестировщиков.

Перевыполнение KPI чаще других премируется у эйчаров, менеджеров и аналитиков.




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

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


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

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




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


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




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


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




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


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




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


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




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



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

Коллеги, вы меня огорчаете

02.10.2020 16:05:32 | Автор: admin
В июле и августе 2020 года я, с подачи Григория Петрова, проводил для компании Evrone технические интервью на позицию Senior Golang Backend developer. И, видимо, буду вынужден продолжать проводить, о чём ниже.

Задача формулировалась как найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go. То есть, сформулирована она была по-человечески, перевод на канцелярит мой. Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько лет старый был с жестким закосом под DevOps. Методику, которой я пользуюсь для создания опросников и количественной оценки соответствия кандидатов, я излагал в своем докладе Техническое интервью как инженерная задача на конференции Saint TeamLead 2019.

И вот что я хочу сказать вам, коллеги: вы меня огорчаете.



Благодаря усилиям хэдхантеров Evrone Екатерины Тхоржевской и Анны Кудряшовой спасибо им! до меня добираются только резюме интересных кандидатов. Я их читаю и вижу вполне релевантный, а зачастую интересный профессиональный путь. Сложные и интересные проекты, ответственные должности. Слушая обязательный Расскажите о себе этап интервью, я вижу упорную и плодотворную работу. Прям бери и нанимай!

Но когда дело доходит до технической части и опросника, перспективы найма начинают выглядеть уже не так радужно. Кисло они начинают выглядеть, честно говоря! Смотрите: средний балл по опроснику 3.3 по шкале 0-9. 3.3, Карл! 3.3 это, с моей точки зрения, уровень junior. Middle должен набирать, я считаю, 5+. Senior 8+.

Почему так? Почему опытные, квалифицированные разработчики набирают такой низкий балл? У меня есть, конечно, предположение, и я им поделюсь в конце статьи. А пока вернемся к тому, о чем я хочу с вами поговорить к моему огорчению. Эта статья имеет своей целью ни много ни мало, исправить ситуацию. Я хочу пройтись по своему опроснику и рассказать, какие именно неправильные ответы мне приходится выслушивать, а после этого задать вам наводящие вопросы, поиск ответов на которые поможет вам в следующий раз получить на моем интервью 9.

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

Итак, опросник:
1. Go императивный или декларативный? А в чем разница?
  • Что я хочу оценить: знакомство с разными подходами к реализации бизнес-логики.
  • Самый популярный неправильный ответ: Я не силен в теории. Очень жаль, что ты не силен в этой теории, %USERNAME%. Если бы ты был в ней силен, ты бы знал, почему некоторые вещи на Go получаются очень легко и хорошо, а некоторые надо прям вымучивать.
  • Наводящие вопросы: SQL императивный или декларативный? А Dockerfile? А файл настройки github actions?

2. Что такое type switch?
  • Что я хочу оценить: знакомство с нашим (скудным) инструментарием работы с системой типов в runtime.
  • Самый популярный неправильный ответ: Я не знаю. Очень странно информация о type switch есть даже в Go tour.
  • Наводящие вопросы: как реализовать в Go тип-сумму, который может содержать в себе значения int64|float64|complex? Как реализовать для такого типа метод Add(int64)?

3. Как сообщить компилятору, что наш тип реализует интерфейс?
  • Что я хочу оценить: хорошо ли кандидат понимает, на чем основана концепция интерфейсов в Go.
  • Самый популярный неправильный ответ: Я не знаю. Справедливости ради, именно этот вопрос редко вызывает затруднения. А когда вызывает, сам кандидат весьма этим удивлен: Я же миллион интерфейсов написал. Как компилятор понимает, что именно я реализовал?... Ну он умный, компилятор. И внимательный.
  • Наводящие вопросы: что такое duck typing? К чему он применяется в Go?

4. Как работает append?
  • Что я хочу оценить: знаком ли кандидат с базовыми концепциями управления памятью в Go. Самыми базовыми.
  • Самый популярный неправильный ответ: Он увеличивает capacity. Если продолжать настойчиво спрашивать: Как он это делает?, кандидат довольно быстро приходит к правильному ответу. Видимо, эти подробности настолько шокирующие, что забыть их трудно.
  • Наводящие вопросы: как бы вы реализовали разреженный массив в Go? А без использования map?

5. Какое у slice zero value? Какие операции над ним возможны?
  • Что я хочу оценить: помнит ли кандидат, что вообще можно делать со слайсом, и как ведут себя операции на граничных значениях. Почему это важно? Почему это важно? был бы отличный вопрос для интервью, если бы я придумал, как его корректно задавать.
  • Самый популярный неправильный ответ: Можно делать len () и cap () наверное Операций со слайсами существенно меньше 10. И мы все 100% применяем их в своей повседневной работе. Надо просто пересчитать их в уме...
  • Наводящие вопросы: каков будет результат append([]string(nil), "")? А append([]string(nil), []string(nil)...)? А почему? А range append([]string(nil), []string(nil)...) как отработает?

6. Как устроен тип map?
  • Что я хочу оценить: насколько интересно кандидату, как именно ложатся в память наши байтики. Map, возможно, самая важная из стандартных структур данных, и весьма замысловато устроенная. Она сложная, она эффективная, она обладает встроенным race condition детектором Неужели не любопытно?!
  • Самый популярный неправильный ответ: то хеш-таблица. Да, это хеш-таблица. Как устроена хеш-таблица?
  • Наводящие вопросы: какая hash-функция используется в map в Go? Что такое bucket?

7. Каков порядок перебора map?
  • Что я хочу оценить: понимает ли кандидат, как отражается устройство структуры данных на ее свойствах. Ну или читал ли кандидат документацию на базовые типы и запомнил ли неочевидно-важное из нее
  • Самый популярный неправильный ответ: В порядке вставки. Хеш-таблица, которая сортирует элементы в порядке вставки, ага. А как в ней происходит выборка по ключу в таком случае?
  • Наводящие вопросы: как получить одно случайное значение из map?

8. Что будет, если читать из закрытого канала?
  • Что я хочу оценить: читал ли кандидат документацию или сразу бросился кодить. Если читал запомнил ли очевидно-важное.
  • Самый популярный неправильный ответ: Вернется ошибка. Ну да, ну да Вы помните синтаксис чтения из канала? Интересно, что синтаксис помнят почти все, но вопрос: И как вернется ошибка?, зачастую вводит кандидата в ступор.
  • Наводящие вопросы: сколько значений возвращает одно чтение из канала? А почему range-чтение из канала возвращает одно?

9. Что будет, если писать в закрытый канал?
  • Что я хочу оценить: читал ли кандидат документацию или сразу бросился кодить. Если читал запомнил ли очевидно-важное.
  • Самый популярный неправильный ответ: Вернется ошибка. Да, вернется. Как она это сделает?
  • Наводящие вопросы: можно ли закрывать канал со стороны читателя? А если очень надо как быть?

10. Как вы отсортируете массив структур по алфавиту по полю Name?
  • Что я хочу оценить: насколько кандидат склонен к написанию велосипедов.
  • Самый популярный неправильный ответ: Методом пузырька. Пузырек прекрасный алгоритм, но есть сегодня и поэффективнее. Например quicksort. Не можете с ходу имплементировать quicksort? Так ведь и не надо!
  • Наводящие вопросы: какой стандартный пакет предназначен для сортировки любых слайсов? И заодно как сделать из массива слайс? Отсортируется ли массив при сортировке слайса?

11. Что такое сериализация? Зачем она нужна?
  • Что я хочу оценить: глубину осознания связи простых повседневно используемых приемов с глобальными задачами разработки.
  • Самый популярный неправильный ответ: Для превращения бинарных данных в текстовые. Строго говоря, не всегда этот процесс можно считать сериализацией, и уж точно это не единственное её применение.
  • Наводящие вопросы: почему нельзя для сериализации какой-либо переменной просто взять дамп занимаемой ею памяти?

12. Сколько времени в минутах займет у вас написание процедуры обращения односвязного списка?
  • Что я хочу оценить: помнит ли кандидат институтский курс информатики. А если серьезно это золотой вопрос программистского собеседования. Если бы мне позволили, я бы задавал его первым, и 70% интервью можно было бы на этом месте заканчивать. Один мой друг, который работает в JetBrains, так и поступает, кстати. Так вот, связанный список это один из базовых элементов computer science, и один раз узнав, как он устроен, забыть это невозможно. Если программист не может развернуть односвязанный список, это свидетельствует о серьёзных пробелах в базовых знаниях. И это повод насторожиться а что еще из базового он пропустил?.
  • Самый популярный неправильный ответ: А что такое односвязанный список?. Это такая структура данных...
  • Наводящие вопросы: какие тесты вы бы написали для своей процедуры разворачивания односвязного списка?

13. Где следует поместить описание интерфейса: в пакете с реализацией или в пакете, где этот интерфейс используется? Почему?
  • Что я хочу оценить: степень готовности кандидата использовать средства реализации модульной архитектуры, предлагаемые Go.
  • Самый популярный неправильный ответ: Рядом с реализацией. Вариантов 2, и кандидаты выбирают, похоже, наугад. На вопрос: Почему? ответить затрудняются.
  • Наводящие вопросы: что такое tight coupling? Почему это плохо? В каком варианте связанность слабее?

14. Предположим, ваша функция должна возвращать детализированные Recoverable и Fatal ошибки. Как это реализовано в пакете net? Как это надо делать в современном Go?
  • Что я хочу оценить: насколько глубоко кандидат осмыслил эту непростую тему обработку ошибок в Go.
  • Самый популярный неправильный ответ: Я не знаю. Обработка ошибок в Go одновременно и проста, и сложна. Проста потому, что в крайней степени тупа. Сложна потому, что до недавнего времени, любая дифференцированная обработка ошибок не была стандартизована, и каждый справлялся, как мог. Ситуация изменилась, и знать об этом прямая обязанность ответственного разработчика.
  • Наводящие вопросы: что нового и важного в плане обработки ошибок появилось в Go 1.13? А чего не появилось, хоть мы и ждали?

15. Главный недостаток стандартного логгера?
  • Что я хочу оценить: критерии выбора кандидатом 3-party зависимостей для проекта. Логгер просто самый одиозный случай, когда стандартная библиотека не предоставляет нам необходимой функциональности.
  • Самый популярный неправильный ответ: Я не пользуюсь стандартным логгером. И никто не пользуется, сюрприз! Но почему?
  • Наводящие вопросы: каково основное применение информации из логов?

16. Есть ли для Go хороший orm? Ответ обоснуйте.
  • Что я хочу оценить: количество и качество усилий, которые кандидат приложил к выбору инструментов, ускоряющих и облегчающих повседневную деятельность.
  • Самый популярный неправильный ответ: Gorm, вроде, неплох. Конкурирует с ответом Я всё пишу руками. Я даже согласен с обоими ответами, но давайте обсудим подробнее как устроен gorm, и почему вдруг руками.
  • Наводящие вопросы: что означает буква M в аббревиатуре ORM? Что на эту букву M есть в gorm? А что такое DAL и зачем он нужен?

17. Какой у вас любимый линтер?
  • Что я хочу оценить: уровень знакомства с современными практиками поддержки разработки.
  • Самый популярный неправильный ответ: Встроенный в Goland. Come on!, там нет линтера, там тривиальный syntax checker!
  • Наводящие вопросы: какое отношение линтеры имеют к CI? Зачем нужен CI в процессе разработки?

18. Можно ли использовать один и тот же буфер []byte в нескольких горутинах?
  • Что я хочу оценить: понимает ли кандидат принципы, по которым мы выбираем использовать общую структуру данных или локальную для горутин.
  • Самый популярный неправильный ответ: Можно, если защитить его мьютексом. Я признаю, это плохой вопрос, недостаточно показательный. Но зачем же давать на него хоть и формально правильный, но бесполезный ответ? К сожалению, в рабочей обстановке нам тоже прилетают плохие задачи, но надо уметь адекватно на них реагировать. Адекватно это не Что за чушь?!, а Сформулируйте, пожалуйста, цель, кстати.
  • Наводящие вопросы: а зачем и правда может понадобиться использовать один и тот же буфер []byte в нескольких горутинах параллельно? Что именно мы будем в нем защищать мьютексом?

19. Какие типы мьютексов предоставляет stdlib?
  • Что я хочу оценить: насколько глубоко кандидат разобрался в теме конкурентного доступа к данным. Да, по второму разу, но это ключевая тема. На этот раз я захожу со стороны практики.
  • Самый популярный неправильный ответ: Не помню. На самом деле, это ответ: Не считаю это важным. Ну и зря!
  • Наводящие вопросы: что именно и от чего защищает мьютекс?

20. Что такое lock-free структуры данных, и есть ли в Go такие?
  • Что я хочу оценить: насколько глубоко кандидат разобрался в теме конкурентного доступа к данным.
  • Самый популярный неправильный ответ: Нет.
  • Наводящие вопросы: что такое atomic? А что такое sync.Map? Sync.Map lockfree или нет?

21. Способы поиска проблем производительности на проде?
  • Что я хочу оценить: степень знакомства с этой малоприятной, но постоянно возникающей задачей.
  • Самый популярный неправильный ответ: Пишу в логи. Коллеги, да такие логи сами по себе создают проблемы производительности!
  • Наводящие вопросы: какие проблемы производительности вы знаете? Может ли быть так, что потребление ресурсов (CPU, RAM, disk/net bandwidth) вполне умеренное, а пользователи жалуются на тормоза? А на что, собственно, жалуются пользователи, и как это связано с тем, что вы видите в системе?

22. Стандартный набор метрик prometheus в Go -программе?
  • Что я хочу оценить: степень готовности использовать лучшие практики современной разработки. И дело тут не столько в самом прометее, сколько в готовности следовать за тенденциями в индустрии. Это, как ни странно, важно сохранять тесную связь с мейнстримом.
  • Самый популярный неправильный ответ: Я не пользуюсь прометеем. А пора бы, уже несколько лет как пора!
  • Наводящие вопросы: оставив прометей в стороне что вообще Go-программа способна о себе рассказать? Метрики runtime что это, и откуда берется?

23. Как встроить стандартный профайлер в свое приложение?
  • Что я хочу оценить: на каком уровне кандидату приходилось решать проблемы недостаточной производительности.
  • Самый популярный неправильный ответ: Я не пользуюсь профайлером. Два варианта: или вы никогда не сталкивались с проблемами производительности, или вы по неизвестным причинам игнорируете одно из самых мощных средств борьбы с такими проблемами. И то, и другое снижает вашу ценность как кандидата, и второе сильнее первого.
  • Наводящие вопросы: а он нужен, профайлер? Что там есть вообще полезного? И почему его надо встраивать, а не запускать из-под него приложение?

24. Overhead от стандартного профайлера?
  • Что я хочу оценить: тупо читал ли кандидат документацию. И, если читал, что понял?
  • Самый популярный неправильный ответ: Ну, заметный.
  • Наводящие вопросы: что такое семплирующий профайлер и почему это хорошо?

25. Почему встраивание не наследование?
  • Что я хочу оценить: общее знакомство с ООП-парадигмой и границами ее применения в Go.
  • Самый популярный неправильный ответ: Наследование позволяет переопределять методы. Но, коллеги, встраивание тоже, тоже!
  • Наводящие вопросы: Что означает буква L в аббревиатуре SOLID?

26. Какие средства обобщенного программирования есть в Go?
  • Что я хочу оценить: знакомство с основными парадигмами современного программирования и границами их применимости в Go.
  • Самый популярный неправильный ответ: Интерфейсы. Коллеги, интерфейсы ничего не обобщают (внезапно). Однако программисты, пришедшие в Go с других языков, имеющих развитые средства обобщенного программирования, сильно тоскуют по ним и пытаются эмулировать эти самые средства с помощью интерфейсов. Создают при этом, простите за правду, кошмарных уродцев.
  • Наводящие вопросы: что такое map-reduce? Как его реализовать в Go? А без interface{}? А что такое кодогенерация и как ее можно использовать в этой задаче?

27. Какие технологические преимущества языка Go вы можете назвать?
  • Что я хочу оценить: глубину осознания кандидатом места языка Go в современной разработке. Для каких задач Go подходит идеально? Для каких не очень, но будет полезен? Преимущества существуют не сами по себе, а только в контексте задачи!
  • Самый популярный неправильный ответ: Читабельность. Коллеги, читабельность субъективная категория, она не может быть технологическим преимуществом. Это раз. Два читабельность Go довольно относительна. Килотонны boilerplate обработки ошибок и ручной раскрутки стека читабельность ни в коем разе не увеличивают!
  • Наводящие вопросы: чем отличается goroutine от OS thread? Как устроен сетевой ввод-вывод в Go?

28. Какие технологические недостатки языка Go вы можете назвать?
  • Что я хочу оценить: глубину осознания кандидатом места языка Go в современной разработке. Для каких задач Go совершенно не подходит?
  • Самый популярный неправильный ответ: Отсутствие generic types. Я пробовал спрашивать на этом месте: Для каких ваших текущих задач были бы полезны генерики?, и ни разу не услышал ничего внятного. И не услышу генерики критически важны для функциональных языков, а Go Об этом ниже.
  • Наводящие вопросы: их миллион, но я задам один. Как превратить []io.ReadWriter в []io.Reader?


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

Напоследок обещанное предположение о том, как и почему сложилась эта печальная ситуация. Наша индустрия, как бы мы это ни оценивали, уже давно живет по закону fail early, fail often, but always fail forward. Для нас это означает, что мы должны делать свою работу как можно хуже! Мы должны потратить как можно меньше сил, средств и времени, особенно времени! на предложенную задачу, ибо никто не знает, имеет ли текущая задача практический смысл. Собственно, большую часть задач мы решаем в режиме разведки, проверяя чужие смелые бизнес-гипотезы.

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

Моё скромное мнение так нельзя! Образование это игра в долгую, и подходить к нему надо с другими критериями, нежели к очередному Проверим идейку MVP.



Конференция Golang Live 2020 пройдёт онлайн 1417 октября. И в этом есть свои плюсы: нам не придётся вводить ограничения на количество гостей, и участником сможет стать каждый желающий. Забронировать билеты можно на все дни конференции, а благодаря генеральному партнеру компании Юла, первый день открыт для всех желающих. Смотрите расписание здесь.

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

Пообщаться, задать вопросы (и ответить на вопросы других) вы можете в этом telegram-канале. Посмотреть новости о конференции в другом, или на выбор: Facebook, VKontakte, Twitter, Youtube, если вы предпочитаете именно их.

До встречи на Golang Live 2020!
Подробнее..

Сынок, запрыгивай в вагон, я закину чемоданы! Экспресс-вход в индустрию когда почти прошел мимо

30.11.2020 22:22:08 | Автор: admin

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


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

В предыдущей серии упоминалась такая бодрая цель:


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

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



если вы понимаете о чем я


Пара слов обо мне, если интересно

Сейчас я вполне состоявшийся 35-летний middle Android-разработчик в крупном и вполне хипстерском финтехе. За плечами около 3 лет профильного опыта, работа в 4 компаниях и печальный скепсис к скрамам и аджайлам. И так вышло, что уже через пару лет я проводил технические собеседования, где лишний раз убедился в правильности выводов об устройстве индустрии.


Онлайн-курсы действительно работают, но есть нюанс


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


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


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

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


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


Всегда найдется десяток (если не сотня) конкурирующих джунов (Junior developer), полиставших на 20 мануалов больше вас, и добавивших еще десяток фреймворков просто для массовки. Потому что про них скорее всего не спросят, а резюме так выглядит "жирнее".


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


Поэтому лучше потратить время на прокачку навыка самопрезентации и полировку работы с базовыми SDK выбранной платформы (в моем случае это был Android SDK). Из двух джунов выберут не того, кто лучше помнит "алгоритмы и структуры данных", а того, кто больше запомнился и произвел лучшее личное впечатление.


Одно из моих первых "пристрелочных" собеседований было сущим позором я вдруг забыл половину собственного проекта (игра по типу "2048"); начал путать хоткеи IDEA, когда меня попросили исправить тестовый код. Но обиднее всего было ответить лишь на 2 технических вопроса из 10, да и то "жиденько". Это было больно, позорно, но очень наглядно. И чтобы совсем вас добить, скажу что это сразу был собес в компанию с буквой "Я".

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


Джунов не должны нанимать слишком легко


Ажиотаж на профессию привел к тому, что джунов на рынке можно грузить лопатой и нанимать килограммами. Соответственно, конкуренция во все более-менее нормальные компании просто огромна. Помножьте это на отсутствие работы в регионах и популяризацию удаленки. Любой, кто предлагает вам оффер после первого же собеса и без дополнительных проверок/условий скорее всего планирует закрыть джуном какую-то дыру. В лучшем случае, получите часть обещанной ЗП; в худшем будете работать на домашнем ноутбуке, а вместо зарплаты получать "бесценный опыт".


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

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


Частые смены работы это хорошо


Несмотря на популярную в HR-кругах теорию о том, что меняющий работу чаще чем раз в N лет ненадежен и нежелателен, в ИТ индустрии это норма. Более того, средняя продолжительность работы разработчика в организации около 2 лет. Значит, что кто-то работает 4 года, а кто-то 6 месяцев. Пруфы привести не могу это комментарии знакомых HR-специалистов, подтверждающие собственные наблюдения.
У меня трудовая книжка уже с двумя вкладышами, так что будем считать такую позицию моей личной "деформацией". Однако, периодическая смена мест работы даст вам следующие преимущества в период прокачки себя как специалиста:


  • Смена контекста применяемых технологий и методик разработки. Работая 5 лет на одном предприятии, вы никогда не составите свое мнение о том, как лучше работать над задачами, какие паттерны не работают, и где та граница, за которой абстракции в коде превращаются в бессмысленный оверинжиниринг.
  • Работа в одном и том же коллективе не позволит составить собственное мнение о том, какие условия для вас действительно комфортны. Поработав в стартапе из 14 человек, и в огромном банке, я понял что больше не готов сидеть в опен-спейсе на 30 человек со всей России. Слишком разное у людей представление о приемлемом поведении в подобных условиях.
  • Может оказаться, что при всей крутости проекта вас будут каждый день раздражать отсутствие чайника и ресепшена. То есть, всякие простые вопросы вроде "нужна тетрадь" или "нужно отдать ноутбук в ремонт" будут порождать целый квест с вами в главной роли. В то же время, отсутствие кофе-машины легко нивелируется покупкой маленькой ручной Wacaco (не сочтите за рекламу, но уж очень полюбилась эта малышка).

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

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


  • Если чувствуйте, что прогресс на работе остановился или серьезно замедлился попробуйте влезть в новый проект. Если нельзя смело меняйте работу.
  • Отработали пол года и видите что за вами не нужно все переделывать, а руководство устраивает ваша работа заводите разговор о пересмотре ЗП. Реальная инфляция на порядки выше 3%, а спрос на более-менее вменяемых разработчиков не снижается.
  • Если новая работа вообще не дает прокачки навыка, и вместо этого вы занимаетесь какой-то ерундой меняйте работу. Это не та специальность, где запись в трудовой ценна сама по себе.

Большинство собеседований одинаковые, а ваше резюме или код никто особо не смотрит


По моим наблюдениям, 8 из 10 собеседующих получили ваше резюме за 10 мин до встречи. И да, им тоже лень всем этим заниматься, поэтому вас встретят списком найденных в сети вопросов по Java\Android\подставь_что_актуально. А значит, эти списки вы можете нагуглить самостоятельно и обстоятельно их разобрать. Это прибавит уверенности на встрече и поможет лучше сыграть свою партию.


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


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

Подробнее..

Сынок, запрыгивай в вагон, я закину чемоданы! Экспресс-вход в индустрию, когда почти прошел мимо

01.12.2020 00:06:56 | Автор: admin

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


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

В предыдущей серии упоминалась такая бодрая цель:


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

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



если вы понимаете о чем я


Пара слов обо мне, если интересно

Сейчас я вполне состоявшийся 35-летний middle Android-разработчик в крупном и вполне хипстерском финтехе. За плечами около 3 лет профильного опыта, работа в 4 компаниях и печальный скепсис к скрамам и аджайлам. И так вышло, что уже через пару лет я проводил технические собеседования, где лишний раз убедился в правильности выводов об устройстве индустрии.


Онлайн-курсы действительно работают, но есть нюанс


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


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


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

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


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


Всегда найдется десяток (если не сотня) конкурирующих джунов (Junior developer), полиставших на 20 мануалов больше вас, и добавивших еще десяток фреймворков просто для массовки. Потому что про них скорее всего не спросят, а резюме так выглядит "жирнее".


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


Поэтому лучше потратить время на прокачку навыка самопрезентации и полировку работы с базовыми SDK выбранной платформы (в моем случае это был Android SDK). Из двух джунов выберут не того, кто лучше помнит "алгоритмы и структуры данных", а того, кто больше запомнился и произвел лучшее личное впечатление.


Одно из моих первых "пристрелочных" собеседований было сущим позором я вдруг забыл половину собственного проекта (игра по типу "2048"); начал путать хоткеи IDEA, когда меня попросили исправить тестовый код. Но обиднее всего было ответить лишь на 2 технических вопроса из 10, да и то "жиденько". Это было больно, позорно, но очень наглядно. И чтобы совсем вас добить, скажу что это сразу был собес в компанию с буквой "Я".

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


Джунов не должны нанимать слишком легко


Ажиотаж на профессию привел к тому, что джунов на рынке можно грузить лопатой и нанимать килограммами. Соответственно, конкуренция во все более-менее нормальные компании просто огромна. Помножьте это на отсутствие работы в регионах и популяризацию удаленки. Любой, кто предлагает вам оффер после первого же собеса и без дополнительных проверок/условий скорее всего планирует закрыть джуном какую-то дыру. В лучшем случае, получите часть обещанной ЗП; в худшем будете работать на домашнем ноутбуке, а вместо зарплаты получать "бесценный опыт".


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

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


Частые смены работы это хорошо


Несмотря на популярную в HR-кругах теорию о том, что меняющий работу чаще чем раз в N лет ненадежен и нежелателен, в ИТ индустрии это норма. Более того, средняя продолжительность работы разработчика в организации около 2 лет. Значит, что кто-то работает 4 года, а кто-то 6 месяцев. Пруфы привести не могу это комментарии знакомых HR-специалистов, подтверждающие собственные наблюдения.
У меня трудовая книжка уже с двумя вкладышами, так что будем считать такую позицию моей личной "деформацией". Однако, периодическая смена мест работы даст вам следующие преимущества в период прокачки себя как специалиста:


  • Смена контекста применяемых технологий и методик разработки. Работая 5 лет на одном предприятии, вы никогда не составите свое мнение о том, как лучше работать над задачами, какие паттерны не работают, и где та граница, за которой абстракции в коде превращаются в бессмысленный оверинжиниринг.
  • Работа в одном и том же коллективе не позволит составить собственное мнение о том, какие условия для вас действительно комфортны. Поработав в стартапе из 14 человек, и в огромном банке, я понял что больше не готов сидеть в опен-спейсе на 30 человек со всей России. Слишком разное у людей представление о приемлемом поведении в подобных условиях.
  • Может оказаться, что при всей крутости проекта вас будут каждый день раздражать отсутствие чайника и ресепшена. То есть, всякие простые вопросы вроде "нужна тетрадь" или "нужно отдать ноутбук в ремонт" будут порождать целый квест с вами в главной роли. В то же время, отсутствие кофе-машины легко нивелируется покупкой маленькой ручной Wacaco (не сочтите за рекламу, но уж очень полюбилась эта малышка).

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

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


  • Если чувствуйте, что прогресс на работе остановился или серьезно замедлился попробуйте влезть в новый проект. Если нельзя смело меняйте работу.
  • Отработали пол года и видите что за вами не нужно все переделывать, а руководство устраивает ваша работа заводите разговор о пересмотре ЗП. Реальная инфляция на порядки выше 3%, а спрос на более-менее вменяемых разработчиков не снижается.
  • Если новая работа вообще не дает прокачки навыка, и вместо этого вы занимаетесь какой-то ерундой меняйте работу. Это не та специальность, где запись в трудовой ценна сама по себе.

Большинство собеседований одинаковые, а ваше резюме или код никто особо не смотрит


По моим наблюдениям, 8 из 10 собеседующих получили ваше резюме за 10 мин до встречи. И да, им тоже лень всем этим заниматься, поэтому вас встретят списком найденных в сети вопросов по Java\Android\подставь_что_актуально. А значит, эти списки вы можете нагуглить самостоятельно и обстоятельно их разобрать. Это прибавит уверенности на встрече и поможет лучше сыграть свою партию.


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


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

Подробнее..

Обзор рынка труда QAQC в Москве

07.01.2021 14:19:53 | Автор: admin
"Word cloud" на основе описаний вакансий из раздела "Тестирование" по Москве."Word cloud" на основе описаний вакансий из раздела "Тестирование" по Москве.

Я всегда с интересом читаю обзоры рынка труда, которые публикуются на Хабре. Но, после них у меня всегда оставалось чувство легкого голода: нехватало более подробного анализа по моему сегменту рынка и региону. Да и с регулярностью все было не то чтобы хорошо. Так пару лет назад, у меня появилась идея сделать что-то вроде дашборда по рынку труда QA специалистов Москвы на основе данных HH.ru. Результаты мне показались достаточно интересными, чтобы принести их сюда.

Начну с того, чего в этом отчете нет. Не буду отбирать хлеб у авторов с "Хабр Карьера" их опросы по зарплатам трудно превзойти по степени достоверности, поэтому в моих отчетах нет цифр по заработной плате. Также нет точности в абсолютных цифрах. Причины в том, что атрибуция вакансий на HH.ru сделана своеобразно и одна вакансия может публиковаться несколько раз под разными ID. С другой стороны, одно объявление может соответствовать нескольким открытым позициям в компании. Поэтому рассматривать абсолютные цифры следует с осторожностью. Но проводить сравнительный анализ эти данные все же позволяют. Для сбора вакансий использовалась открытая часть API HH.ru, которая отдает описание вакансий в формате JSON. Часть графиков построена на базе параметров переданных в JSON-формате, часть на основе анализа текстовых описаний вакансий. Наблюдение велось с марта 2019 по декабрь 2020 гг. в разделе "Тестирование" по г. Москве. Запрос был сужен до специалистов по тестированию, вакансии из этого раздела с другой специализацией отбрасывались.

Посмотрим как менялся совокупный спрос в этом году на фоне прошлого:

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

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

На HH.ru есть возможность указать и вид найма с выбором из списка: полная занятость, частичная, проектная или стажировка. Но, в сравнении с прошлым годом, по этим показателям изменения минимальные. Полная занятость по-прежнему превалирует с долей в 97%.

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

Есть еще одна причина по которой я не стал делать анализ абсолютных цифр заработной платы: при попытке выделить предложения зарплаты по категории "без опыта", я получил совершенно не реалистичные цифры. При просмотре ценовых аномалий стало понятно, что описания множества вакансий не совпадают с категорией в которой вакансия публиковалась. То есть под грифом "без опыта" регулярно попадались вакансии ведущих инженеров и тест-менеджеров с зарплатами от 150 т. р и выше. О причинах я могу только гадать. Первое что пришло мне в голову это банальная лень и невнимательность среди тех, кто вносит описания вакансий. Не исключено, что к этому их подталкивает и пользовательский интерфейс. Не знаю как выглядит форма создания вакансии на HH.ru, но не удивлюсь, если значение "без опыта" там предлагается по умолчанию.

Тем не менее, из параметров вакансий, можно выделить косвенный показатель, который описывает изменения в зарплатной политике. Это доли вакансий с указанной и не указанной зарплатой и доли вакансий в которых диапазоны зарплат открыты вверх или вниз. Доля вакансий в которых не указан размер оплаты труда выросла на вполне заметные 5%, причем за счет вакансий с "закрытым" диапазоном и тех, где диапазон был открыт в сторону повышения. Доля вакансий с указанием только верхней границы изменилась незначительно. Мой вывод: если есть возможность сэкономить на фонде заработной платы в ситуации всеобщей неопределенности, то желающие это сделать обязательно найдутся. К счастью, волны массовых сокращений не случилось, если не считать отдельных случаев, как, например, с Wildberries. Но, зато часть столичных компаний обнаружила, что можно использовать рабочую силу из провинции без релокации, а "удаленка" у нас традиционно была поводом для дисконта в пользу работодателя.

Остальные графики в отчете относятся к техническим средствам тестирования и делались на основе частоты упоминаний этих средств в текстовых описаниях вакансий. Например, вполне ожидаемая четверка лидеров среди языков программирования (в порядке убывания): Java, Python, C#, JavaScript. Сюрпризом стал только взлет языка Kotlin c восьмого места в 2019 году, на пятое в 2020-ом. В целом, в этой группе отчетов я не нашел особых откровений, лидеры было вполне ожидаемы. Но, думаю, что для тех кто выбирает сейчас "ветвь развития" в профессии такие графики будут полезны.

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru