Приходи с решением, а не с проблемой
Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».
Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.
Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.
Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.
Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».
Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.
Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.
Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.
Post mortem
Большие ребята, которые работают с инженерами, после крупных аварий всегда пишут post mortem — начиная с гугля и амазона, и заканчивая более «консьюмерскими» сервисами вроде circle ci или гитхаба. Самый известный post mortem, который наверное читали все — эпичный проеб данных в гитлабе.
Обычно в таких документах на более или менее понятном языке объясняют причины произошедшей аварии и рассказывают про выводы и изменения в командных процессах.
Существует даже целая коллекция post mortem, можно читать прям с пивом и попкорном.
Помимо интересного чтива, подробные и интересные отчеты об ошибках служат важной задаче — оздоровлению культуры в команде. Самое главное, что устраняют внутрикомандные post mortem — боязнь ошибиться.
Это прям наша национальная черта — еще со школы всех приучают, что ошибаться — плохо. Пофиг, что ты ошибся потому, что делаешь сложную работу, жизнеспособность которой зачастую лежит вне круга твоего влияния: в мозгу многих ребят застряла формула «ошибка = косяк, штраф, публичный ататат и профессиональная смерть». А что серьезного может сделать программист, который боится написать даже сложную дата-миграцию?
В mtrl.ai принято писать подробные письма о крупных ошибках. Вот к примеру про недавнюю проблему, которую спровоцировал я (ПДФ, чтобы картиночки сохранить).
Большие ребята, которые работают с инженерами, после крупных аварий всегда пишут post mortem — начиная с гугля и амазона, и заканчивая более «консьюмерскими» сервисами вроде circle ci или гитхаба. Самый известный post mortem, который наверное читали все — эпичный проеб данных в гитлабе.
Обычно в таких документах на более или менее понятном языке объясняют причины произошедшей аварии и рассказывают про выводы и изменения в командных процессах.
Существует даже целая коллекция post mortem, можно читать прям с пивом и попкорном.
Помимо интересного чтива, подробные и интересные отчеты об ошибках служат важной задаче — оздоровлению культуры в команде. Самое главное, что устраняют внутрикомандные post mortem — боязнь ошибиться.
Это прям наша национальная черта — еще со школы всех приучают, что ошибаться — плохо. Пофиг, что ты ошибся потому, что делаешь сложную работу, жизнеспособность которой зачастую лежит вне круга твоего влияния: в мозгу многих ребят застряла формула «ошибка = косяк, штраф, публичный ататат и профессиональная смерть». А что серьезного может сделать программист, который боится написать даже сложную дата-миграцию?
В mtrl.ai принято писать подробные письма о крупных ошибках. Вот к примеру про недавнюю проблему, которую спровоцировал я (ПДФ, чтобы картиночки сохранить).
В эту субботу закрывается старая версия CircleCI.com
Вторая версия Серкла — это не эволюция, а революция: вместо того, чтобы фокусироваться на создании универсальной среды сборки для вашего кода, они создали среду для сборки среды — вы можете просто развернуть все, что вам привычно из внутренних докер-образов.
Много времени вложили и в ускорение сборки — на самом медленном нашем проекте мы снизили время сборки в 8 раз, просто перейдя на вторую версию.
Наверное, что-то похожее есть у гитлаба, но все три раза, когда я пробовал их облачную инфраструктуру, у них были какие-то жуткие тормоза в выделении контейнеров, что замедляло CI до такого уровня, что он превращался из помощника в процессе разработки в тупой автоматизатор деплоя.
Цены у circle вполне демократичные — 50$ за контейнер. В комплекте — еще один бесплатный контейнер, который умеет собирать приватные проекты.
Вторая версия Серкла — это не эволюция, а революция: вместо того, чтобы фокусироваться на создании универсальной среды сборки для вашего кода, они создали среду для сборки среды — вы можете просто развернуть все, что вам привычно из внутренних докер-образов.
Много времени вложили и в ускорение сборки — на самом медленном нашем проекте мы снизили время сборки в 8 раз, просто перейдя на вторую версию.
Наверное, что-то похожее есть у гитлаба, но все три раза, когда я пробовал их облачную инфраструктуру, у них были какие-то жуткие тормоза в выделении контейнеров, что замедляло CI до такого уровня, что он превращался из помощника в процессе разработки в тупой автоматизатор деплоя.
Цены у circle вполне демократичные — 50$ за контейнер. В комплекте — еще один бесплатный контейнер, который умеет собирать приватные проекты.
Сервисы: dependabot
Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.
Если на проекте не обновлять зависимости, то он создает ощущение легаси еще до первого запуска. К примеру, тестовое задание, которое я даю бекендерам, содержит снимок проекта с начала 2016 года, и периодически находятся ребята, которые просто не могут его развернуть. А прошло всего два года.
Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?
Важная часть гигиены кодовой базы — актуализация зависимостей. Устаревшие зависимости приводят к мелким незаметным проблемам, которые вместе съедают кучу времени — на 5 минут дольше разворачивается проект; появляются свой код, который дублирует то, что давным-давно есть в апстриме; код не работает на новой убунте и т.д.
Если на проекте не обновлять зависимости, то он создает ощущение легаси еще до первого запуска. К примеру, тестовое задание, которое я даю бекендерам, содержит снимок проекта с начала 2016 года, и периодически находятся ребята, которые просто не могут его развернуть. А прошло всего два года.
Dependabot решает эту проблему методом брутфорса: он постоянно мониторит зависимости и делает пулл-реквест с новой версией сразу после выхода. Первое внедрение становится тяжелым — вам упадет 20–30 ПР, с которыми как-то нужно будет разобраться. Зато потом вы получаете гарантию, что ваши зависимости не застрянут в каменном веке — просто нажимайте на зеленую кнопку: у вас же наверняка хорошее покрытие, и вы не боитесь обновляться, правда?
Самый первый дедлайн
Любая долгая работа — это отношения. Я знаю совсем немного компаний, которые довольны своей разработкой. И вторая причина недовольства, после банального отсутствие опыта у программистов — их неумение строить отношения.
Представьте ситуацию — к вам пришел новый подрядчик\операционный директор\кто угодно, кто в терминологии скрама входит в группу куриц. Вы обсуждаете с ним несколько задач, обещаете их сделать «на неделе» и расходитесь.
В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.
Даже самый опытный заказчик, которого наебывали по срокам уже пятьдесят раз, верит, что вы — тот единственный, кто не нарушает обещания.
Как только вы нарушаете обещание — вы становитесь «обычными» программистом. И тут же получаете весь букет стандартной менеджерской хуйни: вас просят оценить задачи в часах, работать по скраму с ежедневными стендапами, быть онлайн с 9 до 18. С вами торгуются по срокам — все равно вы не выдержите, почему бы не отжать побольше?
Не проебывайте первый дедлайн. Договоритесь об ФФФ, срежте 90% работ, но решите задачу полезно для бизнеса. Даже маленький результат за спиной позволит управлять ситуацией, а не созерцать, как все катится под гору из-за недоверия.
Любая долгая работа — это отношения. Я знаю совсем немного компаний, которые довольны своей разработкой. И вторая причина недовольства, после банального отсутствие опыта у программистов — их неумение строить отношения.
Представьте ситуацию — к вам пришел новый подрядчик\операционный директор\кто угодно, кто в терминологии скрама входит в группу куриц. Вы обсуждаете с ним несколько задач, обещаете их сделать «на неделе» и расходитесь.
В этот период вас оценивают. Ваши будущие отношения будут построены не по тому, как вы вели себя на встрече, а по тому, как вы поведете себя в эту неделю.
Даже самый опытный заказчик, которого наебывали по срокам уже пятьдесят раз, верит, что вы — тот единственный, кто не нарушает обещания.
Как только вы нарушаете обещание — вы становитесь «обычными» программистом. И тут же получаете весь букет стандартной менеджерской хуйни: вас просят оценить задачи в часах, работать по скраму с ежедневными стендапами, быть онлайн с 9 до 18. С вами торгуются по срокам — все равно вы не выдержите, почему бы не отжать побольше?
Не проебывайте первый дедлайн. Договоритесь об ФФФ, срежте 90% работ, но решите задачу полезно для бизнеса. Даже маленький результат за спиной позволит управлять ситуацией, а не созерцать, как все катится под гору из-за недоверия.
Микроменеджмент ←———→ доверие
Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».
Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном времени, не влезаете в рабочие процессы и детали реализации. У вас даже общего чатика нет (или чат состоит только из мемасиков, как у нас).
Вместо этого вы помогаете — интересуетесь как дела, следите за тем, чтобы у ребят все было удобно: формулировки задач, инфраструктура, отношения в коллективе.
А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?
Для меня всегда слово «микроменеджмент» был антонимом слова «доверие».
Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном времени, не влезаете в рабочие процессы и детали реализации. У вас даже общего чатика нет (или чат состоит только из мемасиков, как у нас).
Вместо этого вы помогаете — интересуетесь как дела, следите за тем, чтобы у ребят все было удобно: формулировки задач, инфраструктура, отношения в коллективе.
А если вы занимаетесь микроменедментом, значит вы не доверяете коллегам. Насколько вообще имеет смысл работать с людьми, которым нельзя доверять?
Работа мечты: Сделать домашнюю работу
В последние несколько месяцев мы быстро растем и проводим много собеседований. Для меня это способ понаблюдать и поделать выводы о состоянии рынка труда программистов, вернее той его части, которую еще не съели крупные ребята типа Яндекса и Мейл.ру.
Я потихоньку начинаю делиться этими наблюдениями в формате «что сделать, чтобы попасть на работу мечты». Предупреждаю — мои советы точно работают при найме к нам в mtrl.ai, и вероятно больше не пригодится нигде.
Начнем с самой важной части процесса — домашней работы. Хорошо проделанная домашняя работа гарантирует быструю встречу с CTO, а ее отсутствие — встречу с HR и тестовое задание до собеседования.
Чтобы сделать домашнюю работу:
— Прочитайте вакансию.
— Прочитайте вакансию полностью.
— Подготовьте примеры работ на стеке, который требуется в вакансии. Приведите их в сопроводительном письме: «видел, что вы используете пайтест, вот у меня целый проект на нем — ссылка». Желательно, чтобы работы были с исходниками.
— Если нет релевантных работ — дайте какие-нибудь другие, хоть чуть-чуть похожие по стеку на требуемый.
— Если и таких работ нет, то лучше всего пойти и что-нибудь сделать, а затем откликаться.
Примеры работ — это самый обычный скрининг: люди на той стороне так же берегут время как и вы, и не хотят встречаться с теми, кто 100% не подходит по измеримым критериям.
Важный вопрос: а что делать, если домашняя работа кажется бессмысленной? Думаю, стоит устраиваться в ту компанию, ради которой есть смысл делать домашнюю работу.
#работамечты
В последние несколько месяцев мы быстро растем и проводим много собеседований. Для меня это способ понаблюдать и поделать выводы о состоянии рынка труда программистов, вернее той его части, которую еще не съели крупные ребята типа Яндекса и Мейл.ру.
Я потихоньку начинаю делиться этими наблюдениями в формате «что сделать, чтобы попасть на работу мечты». Предупреждаю — мои советы точно работают при найме к нам в mtrl.ai, и вероятно больше не пригодится нигде.
Начнем с самой важной части процесса — домашней работы. Хорошо проделанная домашняя работа гарантирует быструю встречу с CTO, а ее отсутствие — встречу с HR и тестовое задание до собеседования.
Чтобы сделать домашнюю работу:
— Прочитайте вакансию.
— Прочитайте вакансию полностью.
— Подготовьте примеры работ на стеке, который требуется в вакансии. Приведите их в сопроводительном письме: «видел, что вы используете пайтест, вот у меня целый проект на нем — ссылка». Желательно, чтобы работы были с исходниками.
— Если нет релевантных работ — дайте какие-нибудь другие, хоть чуть-чуть похожие по стеку на требуемый.
— Если и таких работ нет, то лучше всего пойти и что-нибудь сделать, а затем откликаться.
Примеры работ — это самый обычный скрининг: люди на той стороне так же берегут время как и вы, и не хотят встречаться с теми, кто 100% не подходит по измеримым критериям.
Важный вопрос: а что делать, если домашняя работа кажется бессмысленной? Думаю, стоит устраиваться в ту компанию, ради которой есть смысл делать домашнюю работу.
#работамечты
Вопрос: куда пойти работать начинающему веб-программисту: в студию или продуктовую команду?
У каждого из направлений свои плюсы.
В студии скорее всего выше будет рабочая нагрузка: вы лучше научитесь управлять собственным временем, быстрее поймете, как выглядит результат в глазах клиента.
Продуктовая команда работает более вдумчиво: там следят за качеством кода, больше времени тратят на оплату техдолга, в целом дают больше времени на задачи.
Если вы джуниор, то лучший выбор — это студия. Только посмотрите внимательно на используемые технологии: в провинциях до сих пор встречаются динозавры, которые клепают лендинги на джумле и джей-квери, их лучше избегать.
Когда станете мидлом и выше — в какой-то момент сами придете к варианту с продуктовой командой.
Есть #вопрос? Присылай на @fedor_borshev
У каждого из направлений свои плюсы.
В студии скорее всего выше будет рабочая нагрузка: вы лучше научитесь управлять собственным временем, быстрее поймете, как выглядит результат в глазах клиента.
Продуктовая команда работает более вдумчиво: там следят за качеством кода, больше времени тратят на оплату техдолга, в целом дают больше времени на задачи.
Если вы джуниор, то лучший выбор — это студия. Только посмотрите внимательно на используемые технологии: в провинциях до сих пор встречаются динозавры, которые клепают лендинги на джумле и джей-квери, их лучше избегать.
Когда станете мидлом и выше — в какой-то момент сами придете к варианту с продуктовой командой.
Есть #вопрос? Присылай на @fedor_borshev
Самый частый ответ на вопрос «почему вы не пишете тестов» — «ну, нам не дают времени, чтобы делать все хорошо».
Парадокс — заказчик жмет время на то, чтобы команда работала спокойно и без регрессий, зато щедро отсыпает ресурсы на проебаные сроки, неработающий код и починку багов в продакшене.
Может ему просто дихотомию никто не смог объяснить?
Парадокс — заказчик жмет время на то, чтобы команда работала спокойно и без регрессий, зато щедро отсыпает ресурсы на проебаные сроки, неработающий код и починку багов в продакшене.
Может ему просто дихотомию никто не смог объяснить?
Работа мечты: Резюме
Банальные советы про резюме:
— Лучшее резюме — это гитхаб. Покажите работодателю сразу, как вы умеете отрывать жопу от кресла.
— Круче гитхаба может быть только профессиональный блог, в котором больше 5 заметок.
— В текстовом резюме перечисляйте только релевантный опыт: всем пофиг, как вы в 16 лет целое лето проработали эникейщиком в ООО «Вектор-Инвест».
— Пишите о результатах, а не перечисляйте должностные обязанности. Не «разрабатывал о поддерживал внутреннюю ЦРМ», а «интегрировал систему с Альфа-банком и SalesForce». Первое не говорит ни о чем, а второе вполне может оказаться созвучным с текущими проблемами работодателя.
— Напишите кратко о себе: чем вы отличаетесь от усреднённого коллеги из прошлого офиса? Что цените в работе? Чем можете быть полезны для будущей команды?
В маленьких компаниях такое резюме позволит вам сразу пробиться к CEO и CTO, и даст фору перед другими кандидатами.
#работамечты
Банальные советы про резюме:
— Лучшее резюме — это гитхаб. Покажите работодателю сразу, как вы умеете отрывать жопу от кресла.
— Круче гитхаба может быть только профессиональный блог, в котором больше 5 заметок.
— В текстовом резюме перечисляйте только релевантный опыт: всем пофиг, как вы в 16 лет целое лето проработали эникейщиком в ООО «Вектор-Инвест».
— Пишите о результатах, а не перечисляйте должностные обязанности. Не «разрабатывал о поддерживал внутреннюю ЦРМ», а «интегрировал систему с Альфа-банком и SalesForce». Первое не говорит ни о чем, а второе вполне может оказаться созвучным с текущими проблемами работодателя.
— Напишите кратко о себе: чем вы отличаетесь от усреднённого коллеги из прошлого офиса? Что цените в работе? Чем можете быть полезны для будущей команды?
В маленьких компаниях такое резюме позволит вам сразу пробиться к CEO и CTO, и даст фору перед другими кандидатами.
#работамечты
FEDOR BORSHEV pinned «Микроменеджмент ←———→ доверие Для меня всегда слово «микроменеджмент» был антонимом слова «доверие». Если вы доверяете людям, то вы их не менеджерите — не «спускаете сверху» сроки, а просите их самих распланировать время. Вы не требуете отчетов о затраченном…»
Сервисы: mailjet.
У команды любого приложения, которое шлет больше, чем один вид транзакционных писем, есть вечная боль — верстка и редактирование шаблонов этих самых писем.
Сложность верстки состоит в том, что в мире существуют десятки почтовых клиентов, каждый из которых имеет свои, понятные только ему, стандарты отображения HTML. Outlook, gmail, thunderbird, Apple mail, Protonmail — по хорошему, каждое письмо нужно проверять в каждом из них.
Даже если вы каким-то чудом сверстали себе работающий шаблон, приходит вторая боль — чтобы поправить запятую в тексте, обычно приходится писать тикет в разработку. А там никто особо вашими запятыми не интересуется — у них там докер, нагрузки, прод упал и все такое.
Mailjet сразу решает обе эти проблемы: транзакционные письма у него собираются мышкой, прямо в интерфейсе. Чтобы отправить письмо через мейлджет, достаточно указать ИД шаблона, который собрал имейл-маркетолог, и прокинуть туда контекст — переменные, которые нужны в письме, вроде имени покупателя или номера заказа.
Для маленьких объемов mailjet бесплатен, тарифы для больших тоже вменяемые.
У команды любого приложения, которое шлет больше, чем один вид транзакционных писем, есть вечная боль — верстка и редактирование шаблонов этих самых писем.
Сложность верстки состоит в том, что в мире существуют десятки почтовых клиентов, каждый из которых имеет свои, понятные только ему, стандарты отображения HTML. Outlook, gmail, thunderbird, Apple mail, Protonmail — по хорошему, каждое письмо нужно проверять в каждом из них.
Даже если вы каким-то чудом сверстали себе работающий шаблон, приходит вторая боль — чтобы поправить запятую в тексте, обычно приходится писать тикет в разработку. А там никто особо вашими запятыми не интересуется — у них там докер, нагрузки, прод упал и все такое.
Mailjet сразу решает обе эти проблемы: транзакционные письма у него собираются мышкой, прямо в интерфейсе. Чтобы отправить письмо через мейлджет, достаточно указать ИД шаблона, который собрал имейл-маркетолог, и прокинуть туда контекст — переменные, которые нужны в письме, вроде имени покупателя или номера заказа.
Для маленьких объемов mailjet бесплатен, тарифы для больших тоже вменяемые.
Я — старый фанат учета времени и, хотя и использую телефон по 20 минут в день, давно мечтал считать и это время тоже.
Мои прошлые попытки учитывать время на мобилке закончились на необходимости каждую неделю фотографировать какую-то дальнюю вкладку в настройках батарейки для Moment, так что я очень сильно обрадовался письму о мобильной версии RescueTime.
Казалось, что разработчики (ребята неторопливые, судя по интерфейсу из начала двухтысячных) напряглись и интегрировались с новой фичей iOS 12. Но нет, они просто записывают время, которое телефон включен, без деления на продуктивное и непродуктивное:
Note about iOS and the Productivity Pulse: Because we can only capture total screen time on iOS instead of individual applications, we don’t feel that time can accurately impact your productivity pulse. It would just be too much of a guess. Therefore, while your iOS time will show up in your reports under the total time, that time will not impact your productivity pulse.
Интересно, в чем ценность такой версии для пользователей RescueTime, единственная фича которой — измерять, насколько продуктивно вы проводите время за компьютером?
Буду ждать тех, кто первым интегрируется со встроенным учетом времени, и уйду, видимо, к ним.
Мои прошлые попытки учитывать время на мобилке закончились на необходимости каждую неделю фотографировать какую-то дальнюю вкладку в настройках батарейки для Moment, так что я очень сильно обрадовался письму о мобильной версии RescueTime.
Казалось, что разработчики (ребята неторопливые, судя по интерфейсу из начала двухтысячных) напряглись и интегрировались с новой фичей iOS 12. Но нет, они просто записывают время, которое телефон включен, без деления на продуктивное и непродуктивное:
Note about iOS and the Productivity Pulse: Because we can only capture total screen time on iOS instead of individual applications, we don’t feel that time can accurately impact your productivity pulse. It would just be too much of a guess. Therefore, while your iOS time will show up in your reports under the total time, that time will not impact your productivity pulse.
Интересно, в чем ценность такой версии для пользователей RescueTime, единственная фича которой — измерять, насколько продуктивно вы проводите время за компьютером?
Буду ждать тех, кто первым интегрируется со встроенным учетом времени, и уйду, видимо, к ним.
Работа мечты: собеседование
Мне всегда странно слышать от знакомых программистов фразу «нервничал на собеседовании». Собеседование, по крайней мере у программистов — наименее важный этап устройства на работу. Вся работа уже сделана: вы уже где-то поработали с заявленными технологиями, показали свои работы и даже, возможно, выполнили тестовое задание.
Цель хорошего собеседования — понять насколько вы совместимы с новым рабочим местом: знаете библиотеки/языки, подходите к команде и процессам.
Если вы хорошо знакомы со стеком, технические вопросы долго не продлятся: человек напротив так же, как и вы, бережет свое время. Если не уверены глубине своих знаний в какой-то определенной области — просто говорите об этом сразу, разговор пойдёт гораздо легче.
Вторая серия вопросов — «личные». Это проверка на совместимость с командой. Где-то важна железная дисциплина, кто-то больше ценит неформальные отношение и ваше участие в жизни команды.
«Личные» вопросы — не экзамен, а именно проверка совместимости: есть команды, в которых вам будет комфортно работать, а есть те, из которых вы сбежите через месяц. Это как с кухней — если вы ненавидите острую еду, то зачем идти в китайский ресторан?
Ну и самое главное — не стесняйтесь сами задавать вопросы (желательно такие, на которые нельзя ответить «да» или «нет»). Собеседование — это знакомство с компанией, и ни в коем случае не экзамен.
Другие заметки: #работамечты
Мне всегда странно слышать от знакомых программистов фразу «нервничал на собеседовании». Собеседование, по крайней мере у программистов — наименее важный этап устройства на работу. Вся работа уже сделана: вы уже где-то поработали с заявленными технологиями, показали свои работы и даже, возможно, выполнили тестовое задание.
Цель хорошего собеседования — понять насколько вы совместимы с новым рабочим местом: знаете библиотеки/языки, подходите к команде и процессам.
Если вы хорошо знакомы со стеком, технические вопросы долго не продлятся: человек напротив так же, как и вы, бережет свое время. Если не уверены глубине своих знаний в какой-то определенной области — просто говорите об этом сразу, разговор пойдёт гораздо легче.
Вторая серия вопросов — «личные». Это проверка на совместимость с командой. Где-то важна железная дисциплина, кто-то больше ценит неформальные отношение и ваше участие в жизни команды.
«Личные» вопросы — не экзамен, а именно проверка совместимости: есть команды, в которых вам будет комфортно работать, а есть те, из которых вы сбежите через месяц. Это как с кухней — если вы ненавидите острую еду, то зачем идти в китайский ресторан?
Ну и самое главное — не стесняйтесь сами задавать вопросы (желательно такие, на которые нельзя ответить «да» или «нет»). Собеседование — это знакомство с компанией, и ни в коем случае не экзамен.
Другие заметки: #работамечты
О чем я пишу в этом канале:
— Рассказываю про софт-скиллы программистов: как отличить процесс от результата, сдавать работу с первого раза, работать быстро и почему важно успевать в срок.
— Делюсь опытом управления проектами:
как делать, чтобы планы сбывались;
какие фичи брать в работу, а какие — ни в коем случае; как избегать закона Паркинсона и не микроменеджить коллег.
— Иногда углубляюсь в специфичные вопросы: как писать понятный код; избавиться от говнокода, доставшегося в наследство; как объяснить важность тестирования коллегам и руководителю.
— Даю подсказки, как устроиться на работу мечты: оформить резюме, попасть сразу к СTO и пройти собеседование. #работамечты
Ну и конечно, я всегда готов взять на работу питонистов с любым уровнем знаний и фронтендеров (vue.js).
— Рассказываю про софт-скиллы программистов: как отличить процесс от результата, сдавать работу с первого раза, работать быстро и почему важно успевать в срок.
— Делюсь опытом управления проектами:
как делать, чтобы планы сбывались;
какие фичи брать в работу, а какие — ни в коем случае; как избегать закона Паркинсона и не микроменеджить коллег.
— Иногда углубляюсь в специфичные вопросы: как писать понятный код; избавиться от говнокода, доставшегося в наследство; как объяснить важность тестирования коллегам и руководителю.
— Даю подсказки, как устроиться на работу мечты: оформить резюме, попасть сразу к СTO и пройти собеседование. #работамечты
Ну и конечно, я всегда готов взять на работу питонистов с любым уровнем знаний и фронтендеров (vue.js).
FEDOR BORSHEV pinned «О чем я пишу в этом канале: — Рассказываю про софт-скиллы программистов: как отличить процесс от результата, сдавать работу с первого раза, работать быстро и почему важно успевать в срок. — Делюсь опытом управления проектами: как делать, чтобы планы сбывались;…»
Страх ошибиться — самый большой враг хорошего кода
Есть много людей, которым лучше не ошибаться — к примеру пилоты самолета или сердечные хирурги. Программистам повезло — им ошибаться можно.
Ошибки программистов проходят через очень хороший контроль: автотесты, отделы QA, фиче-флаги.
Даже когда ошибка добирается до продакшена, у нас есть множество инструментов быстрого отката: k8s не заведет больной контейнер, дежурный инженер откатит непрошедшую миграцию. Если ни один инструмент не подошел, всегда можно просто накатить хотфинкс поверх выложенной кодовой базы.
Но, несмотря на внушительный набор инструментов, мы все еще боимся рефакторинга, «потому что может сломаться». На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.
Давайте не бояться ошибок — мы не пилоты самолета, в конце концов. Хотя и пилоты занимаются на тренажере именно для того, чтобы ошибаться и отрабатывать исправление этих ошибок.
Есть много людей, которым лучше не ошибаться — к примеру пилоты самолета или сердечные хирурги. Программистам повезло — им ошибаться можно.
Ошибки программистов проходят через очень хороший контроль: автотесты, отделы QA, фиче-флаги.
Даже когда ошибка добирается до продакшена, у нас есть множество инструментов быстрого отката: k8s не заведет больной контейнер, дежурный инженер откатит непрошедшую миграцию. Если ни один инструмент не подошел, всегда можно просто накатить хотфинкс поверх выложенной кодовой базы.
Но, несмотря на внушительный набор инструментов, мы все еще боимся рефакторинга, «потому что может сломаться». На таких страхах вырастают неуклюжие, плохо пахнущие классы с копипастой, которые постепенно превращаются в легаси.
Давайте не бояться ошибок — мы не пилоты самолета, в конце концов. Хотя и пилоты занимаются на тренажере именно для того, чтобы ошибаться и отрабатывать исправление этих ошибок.
Выбрать фреймворк для нового проекта
Многие ребята, выбирая инструменты для нового проекта, начинают строить таблицы, сравнивая фичи. Серьезно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.
Если вы выбираете инструменты для «домашнего» проекта — это вполне ок: подобрать приятный тулинг в этом случае настолько же важно, как и запустить проект.
А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта _сейчас_. Подумайте лучше о том, каким будет ваш фреймворк _тогда_. Удержит ли он комьюнити? Успеет ли за быстроизменяющейся средой? Будет ли адекватное предложение на рынке труда?
Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends.
И да, если вы выбираете фреймворк для фронтенда, то берите любой — все равно он протухнет через год.
Многие ребята, выбирая инструменты для нового проекта, начинают строить таблицы, сравнивая фичи. Серьезно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.
Если вы выбираете инструменты для «домашнего» проекта — это вполне ок: подобрать приятный тулинг в этом случае настолько же важно, как и запустить проект.
А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта _сейчас_. Подумайте лучше о том, каким будет ваш фреймворк _тогда_. Удержит ли он комьюнити? Успеет ли за быстроизменяющейся средой? Будет ли адекватное предложение на рынке труда?
Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends.
И да, если вы выбираете фреймворк для фронтенда, то берите любой — все равно он протухнет через год.
Юнит-тесты и фронтенд
Самое сложное место для автоматизированного тестирования — интерфейсы. Сложность тестирования проистекает от их асинхронной природы — ты никогда не поймешь, почему в тесте не нажимается кнопка: потому что она еще не загрузилась из-за задержки в браузере, или потому, что ее действительно сломали в последнем коммите.
С юнит-тестами тоже все плохо — фронтовый код сложно разбивать на вменяемые куски, которые приятно тестировать. Спасает только TDD и хорошие библиотеки типа vue.js, которые сводят количество процедурного кода к минимуму.
Сложность тестирования обостряет извечную проблему для проектов с плохим покрытием — регрессии.
Мой любимый способ борьбы с плохим покрытием на фронте — писать поменьше кода. Серьезно — максимум логики из фронтенда нужно уносить на бекенд: там живут достаточно взрослые и удобные технологии, на которых тесты писать легко и приятно.
Мы в mtrl.ai прямо запрещаем писать бизнес-логику на фронте. Если код в интерфейсе ходит в один эндпоинт, а в зависимости от результатов ходит в другой эндпоинт — это уже не очень хороший код. Если эндпоинта три — мы этот код не пропускаем.
Самое сложное место для автоматизированного тестирования — интерфейсы. Сложность тестирования проистекает от их асинхронной природы — ты никогда не поймешь, почему в тесте не нажимается кнопка: потому что она еще не загрузилась из-за задержки в браузере, или потому, что ее действительно сломали в последнем коммите.
С юнит-тестами тоже все плохо — фронтовый код сложно разбивать на вменяемые куски, которые приятно тестировать. Спасает только TDD и хорошие библиотеки типа vue.js, которые сводят количество процедурного кода к минимуму.
Сложность тестирования обостряет извечную проблему для проектов с плохим покрытием — регрессии.
Мой любимый способ борьбы с плохим покрытием на фронте — писать поменьше кода. Серьезно — максимум логики из фронтенда нужно уносить на бекенд: там живут достаточно взрослые и удобные технологии, на которых тесты писать легко и приятно.
Мы в mtrl.ai прямо запрещаем писать бизнес-логику на фронте. Если код в интерфейсе ходит в один эндпоинт, а в зависимости от результатов ходит в другой эндпоинт — это уже не очень хороший код. Если эндпоинта три — мы этот код не пропускаем.