Пост в защиту HR

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

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

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

Отсев по годам? Потому что сказали так надо. Тоже самое и по остальным пунктам.

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

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

Небольшая ремарка. Складывается ощущение, что со стороны люди видят так, что позвать на собес или нет решают рекрутеры, но это не так. Они делают всего лишь первичный отбор, обычно по формальным признакам. Например у меня в компании это полное несоответствие вакансии. Типа когда бухгалтер откликается на маркетолога, а на редактора пишет devops (реальные случаи). А вот следующим этапом идет отбор от нанимающего менеджера. Но нанимающий менеджер никогда не дает ответ, его вообще не существует с точки зрения кандидата. В конечном итоге отказ приходит либо от системы либо от рекрутера. И это становится причиной, почему всех собак спускают на них.

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

Ссылки: Телеграм | Youtube | VK

Пятничный пост (В субботу)

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

Про язык и детей. Как дети погружаются в среду и за какое время учат язык? Вводные, когда мы переехали сюда 6 лет назад, дочке было 6, а сыну 2. У нее уже был очень хороший русский с падежами без ошибок (что не всегда бывает в этом возрасте), ну а сын еще только начинал говорить.

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

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

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

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

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

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

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

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

Ссылки: Телеграм | Youtube | VK

Выпуск про по мобильную разработку с Алексеем Гладковым. Смотрим и наслаждаемся https://youtu.be/Vfw1vVBFuIU?si=YUuzxDltkII8EgJn

Альтернативные ссылки: Аудио | vk

Восстановление состояния в тестах

И так, вы решили написать тесты на свой проект. Вопрос, как добиться изоляции тестов друг от друга, когда речь идет про интеграционные и функциональные тесты?

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

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

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

Ну и наконец вариант, который наиболее распространен и встроен во все богатые фреймворки (laravel, django, rails, spring boot, ...). В этих фреймворках до каждого теста стартует транзакция, которая в конце теста откатывается (и вложенные транзакции тоже хорошо обрабатываются). Это решение позволяет вообще не думать об очистке в процессе. Иногда делают по другому, включают автоматический truncate таблиц в базе при каждом старте тестов. Причем не ручками, а это фактически стратегия очистки, встроенная в некоторые фреймворки, где можно выбирать как чистить (или идет доп пакетом как в rails).

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

p.s. Как у вас? Мокаете или реальная база с откатом?

Ориентация на бизнес

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

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

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

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

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

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

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