О собеседованиях и найме

На днях прочитал отличную статью (https://vas3k.ru/inside/46/) о собеседованиях и найме. Написано в основном о том, как нанимать программистов, но озвученные мысли подходят и для остальных. Идеи близки мне по духу, потому что я считаю, что типичные собеседования это пустая трата времени. Вопросы о сложности алгоритмов или о бинарных деревьях не покажут ничего, кроме того, что человек об этом слышал и запомнил, а интервьюер тешит своё эго, потому что прочитал об этом 5 минут до интервью. А заставлять писать код на бумаге или на доске это вообще лютый зашквар.

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

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

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

Многие из нас находятся в стрессе

Многие из нас находятся в стрессе

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

Это неправильно. И так было не всегда.

Хочется, чтобы отпустило и стало снова хорошо.

Меня воротит от терминов типа “продуктивность” или, например, “стрессоустойчивость”, потому что вокруг них много хайпа и словоблудства, и лишь буквально толика хоть сколько-то годного и пременимого контента.

Один из спикеров, которого я рекомендую послушать — Анна Обухова.

Анна получила МВА в Манчестерской бизнес школе, закончила Neuroleadership институт и сейчас получает магистерскую степень по Applied Neuroscience. Также работает в ScrumTrek’e и специализируется именно на командной работе, стресс-менеджменте и лидерстве.

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

Так она провела двухчасовую (https://youtu.be/aYyNcSUZ8rg?t=175) лекцию (https://youtu.be/aYyNcSUZ8rg?t=175) с рассказом о «стретегиях стрессоусойчивости».

Тезис:
“Стрессоустойчивость — это действие выраженное во времени, когда мы возвращаем себе контроль” — ещё раз: это действие.

И дальше она предлагает такие варианты действий, чтобы вернуть себе контроль aka стратегии:

1. Запасай
2. Изучай
3. Советуй
4. Убирай
5. Готовь
6. Жуй, грызи
7. Выбрасывай
8. Наводи красоту
9. Делай вместе
10. Обнимай/Делай
11. Помогай
12. Структурируй
13. Пузырь реальность
14. Приоритезируй
15. Авторизуй результат
16. Всё равно делай
17. Считай
18. Вспоминай
19. Двигайся
20. Наблюдай
21. Чувствуй
22. Не игнорируй

Если вам удобнее воспринимать текстом, то Георгий Гаджиев сделал конспект (https://workflowy.com/s/13eee6c8591c/UNW3jIr62eyr2ovA?fbclid=IwAR2zw6QDCGncPEJxEuZjXMaor4Ms5_wf2StO-NmAH8lYnTzIJctdGkEQTu8).

Оказалось, что я пользовался некоторыми из них интуитивно.
Например, 4, 6, 12, 16, 19, 20, 21, 22.

Мне это кажется ценным, поэтому хочется, чтобы больше людей об этом узнали.

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

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

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

Про адаптацию стажеров и младших специалистов

Наш руководитель веб-направления Таня Аладина интересно написала про адаптацию стажеров и младших специалистов:

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

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

Сила комментария

Сила комментария

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

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

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

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

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.

Комментарий — элемент хаоса. Но с ним система устойчивее.

Кажется, неплохая статья о том, как анализировать данные

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

Вот несколько советов о том, что ж делать-то:

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

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

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

4. Проверьте, что контекст сбора данных был верным. Если вы собрали данных за два года, то половина из них может оказаться нерелевантной из-за изменившегося контекста (например, был проведён редизайн сайта).

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

6. Выделите свои основные KPI и смотрите на них. Так не потонете в пучинах таблиц и цифр.

7. …но сравнивайте их и с другими метриками, которые идут с KPI в противоречие.

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

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

10. Категоризируйте и кластеризируйте качественные и количественные данные — так с ними будет проще работать.

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

12. Используйте цветовое кодирование… очевидно. ✅

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

14. Используйте специальные тулы. (Тут в статье реклама видимо)

https://databox.com/how-to-analyze-data

Меня тут спрашивают, зачем нужны шпаргалки, о которых я написал постом выше

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

Например, вы знаете основы JS, но всё чаще встречаете в примерах непонятный новый синтаксис — ES6. Вы можете прочитать про него длинную статью (например: http://babeljs.io/learn-es2015/), но, скорее всего, сразу всё забудете. Тут вам и придёт на помощь шпаргалка https://devhints.io/es6

Или вы установили себе модный редактор кода Visual Studio Code, но не знаете ни одного хоткея в нём. Вот шпаргалка с ними: https://devhints.io/vscode

Или вы решили научиться верстать флексбоксами, но постоянно забываете синтаксис. Шпаргалка вам его быстро напомнит: https://devhints.io/css-flexbox