К основному контенту

Сообщения

Рекомендации начинающему докладчику

Последнее время статьи в блоге появляются только благодаря тому, что хочется как-то изложить письменно то, что приходится часто повторять устно. Сегодня подошла очередь к рекомендациям начинающим докладчикам. Будет немного про сам контент и про оформление презентации. Ничего уникального, просто те давно известные моменты, которые кажутся мне ценными и полезными. Так получилось, что уже как 4 года я приобщился к такому процессу, как ревью докладов. Началось это благодаря моему участию в работе программного комитета конференции Heisenbug , а потом продолжилось уже на обычной работе, когда мы у себя в Semrush замутили техническое демо . Поэтому приходится частенько повторять одни и те же мысли, а я переживаю, что что-то полезное забываю сказать. Пусть будет тут, заодно может кому еще пригодится. Итак, погнали. Про что рассказывать и зачем оно вообще нужно? В этом месте воспользуюсь помощью зала и просто отправлю вас к хорошим материалам других. Рома Поборчий "Как найти в своей работе

Нетехническое собеседование - зачем, полезные вопросы

Что может быть целью такого собеседования (или такой части в общем собесе): знакомство с командой, оценка того, насколько человек подойдет в культуру команды и ее процессы, как развивается, что его драйвит, что угнетает. Но подход можно использовать и для затравки на технической части собеседования, когда отмечают себе вопросы для дальнейшей беседы. Простой алгоритм: просим кандидата рассказать про текущие задачи/проекты/команду внимательно слушаем, записываем полезные для дальнейших вопросов штуки Что может быть полезными штуками (примеры): использование им “терминов” ("отвечаю за качество", "я - devops инженер", "настраиваю CI/CD" и тп) части рабочего процесса ("описываю все в документации", "менторю новичков", "помогаю команде") рассказ о элементах взаимодействия, поставки задач ("сам себе пишу баги, чтобы не забыть", "задачи на описывание кейсов использования") Дальше по этим записям задаем вопрос начин

Flaky тесты (они же моргающие или "случайно успешные")

Недавно поучаствовал в Heisenbug Piter 2021 в роли эксперта на очередной серии доклада Андрея Солнцева про flaky тесты. Люблю эту тему. Кажется, это своего рода "дебаг", только для тестов. Иногда расследование похлеще приключений Шерлока. Тема flaky тестов древняя, как сама отрасль. Первое найденное упоминание термина в традиционных интернетах (типа блогов, твиттеров) в 2008 году в блоге гугла . Мне больше нравится называть их “моргающие” или, что четче отражает проблему, случайно успешные. Давайте еще раз зафиксируем то, что поможет меньше попадать в историю, когда тесты у нас "случайно успешные" и что делать, если уже "вляпались". Итак, что делать, чтобы "моргающих" тестов было меньше: тесты должны быть написаны в правильном слое " той самой пирамиды ": чем ближе слой к модульным тестам (а лучше именно в них), тем меньше шансов на моргания, потому что зависимостей меньше. в ту же тему: чем меньше UI-тестов, тем лучше. Открывая в оче

Через призму менеджера про "Никаких правил. Уникальная культура Netflix."

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

"The Ongoing Revolution in Software Testing" by Cem Kaner (2004) - разбор общепринятых утверждений о тестировании/тестировщиках

Благодаря давнишнему твиту Alan Page  узнал про чудесную статью Cem Kaner , который еще в 2004 году разобрал популярные утверждения (мифы?) про тестирование и роль тестировщиков. Что именно так разбирается: The Role of Testers • The primary reason to test is to find bugs? • The primary reason to test is to prove the program works correctly? • Testers are THE advocates of quality on a project. • Test groups should evolve into quality assurance groups. • The test group should have the power to block release if product quality is too low. • Testers and programmers have conflicting interests. • The test group should work independently of the programmers. • Testers should push their project teams to follow "appropriately professional development models," like the Waterfall, that require people to THINK before they act. • Testers should base test cases on documented characteristics of the program. If the software documentation is inadequate for this, testers should assert a quality

Обычные и не очень вопросы к собеседованию на позицию Engineering Manager

Навеяно тредом под вопросом Charity Majors , своими собеседованиями и собеседованиями меня :) Может кто найдет что-нибудь интересного себе. Кстати, многие из этих вопросов можно задавать нанимающему менеджеру. Disclaimer: Порядка, приоритета в вопросах ниже нет.  Необходимость и момент их вопрошания зависит от течения беседы.  На полноту и ценность для вас список определенно не претендует. Этот список не значит, что на собеседовании со мной вы услышите именно эти вопросы. 1. Что мотивирует людей вообще (немного теории, а-ля Маслоу, Герцберг, RAMP и тдтп в том числе просто "своими словами"). Что мотивирует вас? Ну и дальше про то, как использовалось в работе. Как работали с так называемыми "underperformance" товарищами? 2. Лидерство vs "быть начальником" - что это для вас? Как вы определяете лидерство? 3. Карьерный рост для разработчиков в ваших командах. Как они растут? Что для вас этот рост, что вы думаете о грейдах (уровнях)? Какой процесс оценки уровня

Тимлид - таинственная роль в реальном мире или фантастические твари среди нас

Черновик с набором ссылочек долго мариновался и вот дождался потребности в себе.  Пусть теперь лежит публично. История началась год назад (твою ж дивизию, вот я торопыга...) с обсуждения в комментах того, что это за роль/должность такая "тимлид". Пересказывать обсуждение тут смысла не вижу, кому интересно - велком в тред. Спустя год тема получила свое продолжение в твиттере Никиты Макарова лайкни оригинальный твит Я думал описать свое видение этой роли, но кому это может быть интересно: жизнь не черно-белая, у всех разные ситуации, забил короче. А вот полезных ресурсов чуток накопилось, поэтому пусть нанесут пользу кому-нибудь. Но какой либо системности просьба не ожидать. Disclamer : если вы только рассматриваете для себя роль лида, технического менеджера и тп, подумайте, оно вам действительно надо, обратно пути может не быть. Ну и опять же, я б учитывал такой забавный момент: лайкни оригинальный твит Ну, если не передумали, то начнем. А начинать я бы рекомендовал с этой кн