Уже пару лет как найм через собеседование превратился в лютый ад как для новичков, так и для профи.
Если раньше мне называли цифры 15-20 собесов до офера на должность джуна, то сейчас это уже 30-50, а завтра, наверное, будет все 100. Причём это кейсы успешного найма, что там у тех кто не прошёл долину смерти я не знаю. После 50ти неудачных попыток наверное даже самые упорные опускают руки.

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

Интересно послушать ваши истории прохождения собесов, насколько мои ощущения совпадают с вашими.

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

1. Нехватка фундаментальных знаний, понимания как устроены технические процессы под капотом. Кандидат в своем опыте где-то и что-то сделал непонятного качества и так теперь везде делает - «оно же работает». Сюда же относится поверхностное изучение фреймворков - нахватался терминов, смог связать их воедино в своем пет-проекте, но объяснить не может, хотя претендует на ‘владение темой’, не может решить известные проблемы. Здесь высокие риски того, что с человеком нельзя сварить каши.

2. Беспорядок в коде и голове, отсутствие документации (и даже иногда воинствующее нежелание писать её), неспособность набросать общий дизайн, план масштабирования, верхнеуровневое содержание итераций. Нет минимального понимания (и желания узнать) архитектурного слоя - зачем мы ту или иную модель эксплуатируем конкретно в этой сфере, какие у этого плюсы/минусы, каких подводных камней ожидать. Это воспринимается как некомпетентность.

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

4. «Залетные». Человек часто меняет работу, в индустрию пришел ‘ради лучшей жизни’. Резюме в котором нет фактуры, чем именно занимался, человек не может вспомнить чем полезным он занимался или какой фичей гордится, хотя на прошлых проектах «делал все за всех и вообще чуть ли не один там работал». За последний год также сильно выросло количество «волков», которые натаскиваются на прохождение собеседований - врут, увиливают, пытаются манипулировать диалогом, не могут дать конкретный ответ, всегда уводят вопросы в сторону. Сюда же в категорию ребята «я прошел курсы», но на курсах учили не работать, а зарабатывать.

На boosty делаю зеркало записей стримов, размещенных на soer.pro, сегодня перенес запись Реактивная архитектура на уровне кода.

SOER | PRO | Boosty

В выпуске:
- как нетворкинг помог развить мой ютуб и телеграм
- проблемы собесов
- несколько конкретных советов
- почему может не сработать

SOER | PRO | Boosty

Ребята, хочу сделать честный стрим про валютную удаленку с реальными людьми, которые в теме.
Если вы работаете (или пробовали устроиться) на валютной удаленке, то расскажите о своём опыте в комментариях.

Интересно узнать следующее:
1. Уровень английского
2. Сколько времени искали, сколько собесов прошли, прежде чем нашли
3. Как оформлены (ООО/ИП)
4. На какой схеме налогообложения (патент, упрощёнка и т.д.)
5. Как работаете с валютным контролем
6. Как сейчас выводят деньги в РФ
7. Пенсионные/ больничные
8. Кредиты/ипотеки насколько просто получить
9. Мысли от себя

Если не хочется отвечать, то можешь просто проголосовать поставив эмоджи на пост
❤️ - работаю в РФ
😎 - работаю на валютной удаленке

Если наберём интересный материал, то проведём стрим со всеми желающими выступить.

Задача: выбрать способ передачи сообщений в API для сервисной архитектуры

Обычно выбор делается из двух решений:
- REST
- gRPC

это сильное упрощение, потому что REST - это архитектурный стиль, а gRPC - это фреймворк. Но если рассмотреть gRPC как некий стиль, то можно выделить моменты по которым делается выбор:

- использование HTTP/2
- обмен бинарными данными (+ сжатие данных, позволяющее увеличить скорость обмена данными)
- кодогенерация
- RPC ориентированность (в том числе stream-based)

Со стороны REST кроме требований самой архитектуры обычно выделяют:
- простота
- текстовый формат обмена (удобство)

Таким образом gRPC отлично подходит для организации взаимодействия внутри сервисной (микросервисной) архитектуры, а для внешних API хорошо подходит REST стиль.

Важно отметить, что gRPC немного "тяжелее" во внедрении и сопровождении, но унифицирован, так как фреймворк. А вот REST - это всегда какая-то своя реализация, которая может сильно меняться между проектами.

SOER | PRO | Boosty

Набор в NarisApp

Всех кто хочет принять участие в разработке проекта NarisApp приглашаю принять участие.

Если коротко:
- участие бесплатное
- делаем платформу обучения и развития
- в этом наборе решаем два эпика: "интеграция с бусти" и "интеграция с телеграм"
- как принять участие написано в конце статьи (см. ссылку выше)

Подробное описание смотри по ссылке выше.

Запись техтока про валютную удаленку. Поговорили про:
- какой английский язык должен быть
- как выводить деньги
- как оформлять и где искать валютную удаленку

Дублирую на boosty архив стримов с soer.pro сегодня перенес Проектирование API

SOER | PRO | Boosty

Опубликовал статью Как определить какая доля багов/ошибок допустима и является следствием сложности программного кода?

Несколько основных мыслей (полный текст см. в статье):

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

- Основная проблема заключается в создании нездорового климата внутри коллектива, что приводит к увеличению цены ошибки и замедлению работы;

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

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

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

SOER | PRO | Boosty

Часы идут - программист работает

Как вы относитесь к системе контроля времени? Вот раньше, до ковида, это делалось очень просто: приложил пропуск - таймер запущен, вышел из офиса и таймер остановился. По итогу суммы часов нахождения в офисе должно накапать 40 часов в неделю. Если меньше - звоночек. Если систематически меньше, то подключаются HRы и руководитель. Если после нет изменений - на вылет с пляжа.

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

Но бизнес всегда хочет контроллировать работу айтишников. Это аксиома. Если вам говорят обратное - вам врут.

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

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

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

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

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

И это печально.