Третье видео про парсинг Авито.

В этом видео, бедет рефакторинг кода, добавление запуска по расписанию, добавление возможности при помощи одного скрипта отслеживать несколько объявлений

https://youtu.be/uvb7e8VfH1k

Мои методы повышения продуктивности

Недавно я публиковал пост, про особенности работы любых методов повышения продуктивности.

Несколько человек написали мне в личку, с просьбой рассказать про эти методы. Просили? Отвечаю)

Канбан доска в Trello

В трелло у меня есть личная доска, которая по сути состоит из 3-х колонок: «Входящие», «Сделать сегодня», «Сделать на неделе». Любая карточка попадает в колонку входящие, а потом либо делается сразу (если на это требуется меньше 2 минут), либо делается в течении дня, либо на этой неделе, либо вообще не делаются, поскольку их актуальность теряется (да, такое тоже бывает)

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

Что это дает?

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

Вообще система у меня сильно сложнее, и подробнее о ней я рассказывал в этом видео.

Колл-стек в тетради

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

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

И если с молоком и цветочком все более или менее понятно, то вот «Запилить фичу» звучит максимально абстрактно. Если фича не большая, но мне на что-то проверить на боевом окружении, мне надо

- написать код
- закомитить + запушить его
- собрать в CI (это занимает минут 5)
- проверить

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

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

- поставить дебаггер
- закомитить
- запушить
- собрать
- зайти на сборку и посмотреть что пришло в функцию

Что это дает?

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

Пропуск всех паразитных мыслей через канбан доску (отложенное прокрастинирование)

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

Это самая настоящая прокрастинация.

Запрещать себе прокрастинировать — бесполезно. Сколько я не запрещал, сколько я не блокировал почту, социальные сети, и тд все-равно я находил как это обойти.

Тогда я договорился с собой. Я обязательно это посмотрю, но позже. Сейчас я занят задачей. Потому я завожу себе задачу в трелло, мол надо посмотреть последние новости, и возвращаюсь к задаче.

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

Что это дает?

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

Продолжение следует…

Вторая часть моих советов по продуктивности. Первая тут

Постоянная смена рабочего места (перемещение по комнате/городу)

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

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

Что это дает?

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

Постановка целей на день

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

Всегда беру по минимуму, но при этом очень стараюсь выполнить запланированное.

Что это дает?

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

Телефон в другой комнате

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

Каждые 1,5-2 часа я все-равно встаю, и можно дойти до другой комнаты и посмотреть пришло что-то или нет.

Что это дает?

Тем самым я сокращаю возможности для себя отвлечься во время работы.

Медитация

Медитация помогает привести мысли в порядок и немного притормозить. Я называю это зазземлиться. По сути я ничего не делаю, просто сижу и слежу за дыханием 5-10 минут в день.

Если интересно, то вот некоторые материалы на медитацию для начинающих

Сон

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

Спорт

Это тоже очевидно, и все об этом знают. И еще стоит помнить, что не сколько важен вид спорта, сколько важно наличие спорта в жизни.

Пользуйся, тем, что создаешь

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

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

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

И это хорошо, если ты работаешь над клиентским продуктом. Тогда у тебя есть шанс попробовать его, а если нет?

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

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

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

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

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

Не все ошибки надо исправлять

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

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

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

Тут сразу вспоминается мем «Это не баг — это фича».

Возвращаясь к мыли, что не все ошибки надо править. Если команда смиряется с мыслью, что ее продукт не идеален, и принимает тот факт, что не все ошибки надо править, встает вопрос: «Какие ошибки нужно править, а какие нет?» Именно для этого был придуман подход zero bug policy.

Zero Bug Policy (ZBP) — это политика обработки ошибок, основанная на правиле:

«При появлении новой ошибки надо сразу принять решение исправить ее в ближайшее время, либо закрыть как “Won’t Fix”».

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

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

Теперь о плюсах данного подхода:

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

А есть минусы? Есть…

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

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

Еще одно видео в котором я пишу Парсер для Авито. В этом видео внес небольшие доработки, и исправил проблему которая возникла в предыдущем видео, после того, как я добавил возможность отслеживать больше одного объявления

https://youtu.be/_g98377s7RQ

О социальной активности в IT

Сегодня мне бы хотелось поговорить немного о социальной нагрузке в IT. Мне иногда кажется, что программирование — сродни магии в современном мире. Зная определенное заклинание можно собрать какую-то информацию, или помочь человеку решить его проблемы.

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

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

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

Не хочу спекулировать почему так получается, но с этим сталкивались все кто так или иначе реально работает над доступностью. Так вот к чему я это все?

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

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

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

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

В общем последние несколько дней я очень активно писал под это дело бота. И вот первое видео:

https://youtu.be/Jynmr1tgh38

Ну и как всегда материалы

Репо бота

Репо бойлерплейта

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

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

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

Собеседовали меня 2 человека. Один из них, видимо, лидил фронтовое направление, а второй был бэкендером — тимлидом в команду в которую меня планировали взять.

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

Перед собеседованием я спросил какие вопросы будут на собеседовании, на что hr мне ответила, что будут общие вопросы.

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

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

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

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

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

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

Вообще нет ничего сложно в том, чтобы найти специфические вопросы и валить или собеседника.

Мы долго разговаривали про Typescrit и Webpack, поговорили про теорию типов, про модуль федерейшен, поговорили про устройство Vue, про реактивность во 2 и 3 версии. А когда технические вопросы закончились, начались вопросы от тимлида.

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

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

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

продолжение поста


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

Итог.

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

Почему люди увольняются из Google?

На заре своей карьеры, я мечтал работать в Яндексе. Для меня это была компания мечты, апогей карьеры программиста. В теории еще существовал гугл, но это было где-то за гранью понимания человека, всю жизнь прожившего на Урале. И когда я встречал людей, работавших в Яндексе, я не мог понять, как можно было от туда уйти? Собственно это касается не только Яндекса или Гугла, а любой компании, условия которой для не IT-шника кажутся сказочными.

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

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

👉 Приходя на новую работу у тебя обязательно есть ожидания от нее. Даже если ты о них никогда не задумывался, они все-равно есть. Если ожидания не оправдываются люди разочаровываются и уходят.

👉 На любой работе приходится работать, как бы это странно не звучало. И иногда рабочие задачи никак не матчатся с тем, что тебе хотелось бы делать. Конечно, есть идейные люди, которые так любят то, что делают, что «не работают ни дня». Но таких очень мало. Остальным же иногда приходится принимать решения/выполнять задачи, которые вызывают неприязнь.

👉 Люди не умеют отдыхать. Я знаю людей, которые работают в двух местах, или просто работают по 12 часов или не ходят в отпуск. А потом устают, теряют интерес к работе (а это нормальная реакция организма я рассказывал об этом в видео про выгорание), и поэтому уходят.

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

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

Знакомо? Может быть есть что добавить из личного опыта?

В следующем посте расскажу про то, как с этими проблемами бороться.

Что делать, чтобы не уволиться с идеальной работы?

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

Небольшой дисклеймер. Могло показаться, что я агитирую идти работать в условный Гугл. Нет, совсем нет, я приводил в пример Яндекс потому что для меня это была и во многом остается компания мечты. Мне комфортно работать в больших IT компаниях. Если тебе больше нравятся стартапы, или маленькие компании — это тоже круто, все причины, что я описал будут работать и там.

Что же делать чтобы самому не уйти с работы мечты?

1️⃣ Примем за аксиому, что любая работа имеет недостатки. И если концентрироваться на них, то можно дойти до отдела кадров. И первое что приходи в голову, не концентрироваться на негативе. Это легко сказать, сложно сделать, и у меня ни разу не получилось. Можно отвлечься на день, неделю, месяц, но все-равно негатив потом догонит.

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

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

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

2️⃣ Вторым пунктом я говорил про то, что на работе мы все-таки работаем. А рабочие задачи иногда идут в разрез с внутренним чувством прекрасного. Вот тут как раз отлично работает совет не концентрироваться на плохом, конечно, если твоя работа не состоит из бесконечной чреды неприятных тебе задач. Стоит помнить, что иногда неприятные решения для тебя — выгодны для компании.
Так например иногда нужно писать говно-код, потому что он позволит зарабатывать здесь и сейчас, а потом он будет и не нужен.

3️⃣ Третьей причиной увольнения я назвал отсутствие отдыха. Уметь отдыхать, уметь переключаться и расслабляться — это целиком задача работника. Про ворк-лайф баланс сейчас не говорит только ленивый, поэтому я просто перейду к ледущему пункту.

4️⃣ Ну и четвертой причиной я написал решение своих собственных проблем за счет смены работы. Не знаю насколько эта причина распространена, но она очень личная. Чувствуя неудовлетворенность от жизни, я пытался самоутвердиться за счет ощущения, что я очень классный специалист. Вместо того, чтобы решать проблему на работе, я записывался на очередное интервью. Очень мило общался с HR которая всеми силами пыталась показать, что очень ценит общение со мной. Поэтому секрет тут прост, нужно решать проблему а не убегать от нее.

Были ли у вас увольнения после которых вы жалели?

Продолжаем сериал по напмсанию бота для запоминания всего чего угодно. Второе видео уже на канале

Я всегда отказываюсь от тестовых заданий

Если мне предлагают его выполнить, я в 90 процентах отказываюсь от дальнейшего общения с компанией. Тем не менее иногда спрашиваю оплачивают ли они его выполнение (😱 да, нормальные компании платят за тестовые задания 😜).

Так почему я отказываюсь?

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

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

🫰Помимо этого, я заметил тенденцию, чем круче компания, тем меньше шансов, что они предложат тестовое задание. В Яндексе тестовое задание есть только для стажеров, а вот какой-нибудь «ООО ТехФинТорг» может просить выполнить его даже уборщицу, потому что такие у них протоколы.

🤌 Дальше, когда я отказываюсь, рекрутер, обычно просит меня привести пример моего кода, и этот вопрос всегда вводит меня в уныние. Потому что я не могу этого сделать из-за NDA. Думаю, ни одна компания не согласится чтобы ее работники показывали даже кусок кода во время собеседования. Так зачем об этом просить?

🖖 Поэтому следующий вопрос про пет-проекты и github. Раньше я пытался объяснить, что код на работе и код в личных проектах пишется по-разному. Что на работе я исхожу из того, что с моим кодом будут работать другие, а вот в личных проектах могу развернуться… А сейчас просто отправляю их на свой youtube, пусть смотрят ролики.

🫵 Ну и последнее, тестовое задание не отменяет тех интервью, так зачем тогда нужно тестовое задание? Убедиться что именно я его писал?

На что смотреть на тех собеседовании?

Почему-то далеко не все воспринимаю интервью как обоюдный процесс, для всех очевидно, что в процессе интервью (серии интервью) смотрит на кандидата, но и кандидат смотрит на компанию. Так вот сегодня я расскажу о том, на что я смотрю во врем собеседования.

1️⃣ Тестовое задание. Я как-то писал, что почти наверняка откажусь, если мне предложат его выполнить, поэтому тут повторяться не буду.

2️⃣ Гладкость прохождения этапов собеседования. Можно косвенно судить как обстоят дела с процессами в кампании. Ну например, если встречи переносятся (особенно на полчаса, час уже в день интервью), или рекрутер куда-то пропадает и перестает отвечать. Скорее всего процессы выстроены не очень.

Когда я собеседовался в Delivery Club от первого интервью до офера прошло 2 дня, а у меня было собеседование с HR, техническое собеседование, собеседование с лидером направления, и согласование офера с головной компанией (тогда mail.ru)

3️⃣ Вопросы которые мне задают. Из вопросов я пытаюсь понять, насколько интервьюер вообще понимает кого ищет. Если вопросы задаются шаблонные вопросы типа как из книги ты не знаешь Javascript, то я всегда спрашиваю интервьюера когда он последний раз применял такие вещи у тебя в проекте. И если недавно, то можно поговорить об этом, и выяснить а почему они используют разные хаки, а не пытаются сохранить код простым и читабельным. На эту же проблему укащываеи

4️⃣ Опирается ли интервьюер на мои ответы? Если мои ответы ничего не значат, то он даже не старается понять, насколько я подхожу для них.

5️⃣ На сколько вежливо и корректно ведет себя интервьюер. Если в компании не принято уважительно относиться к коллегам, то на собеседовании это будет очевидно.

6️⃣ Задаю вопросы.
Я никогда не задаю вопросы в открытой форме, например «Бывают ли у вас переработки?» или «Есть ли у вас проблемы с коммуникацией?». Вместо этого, я говорю о проблемах как о свершившемся факте «Когда ты последний раз перерабатывал?» или «Расскажи о последнем конфликте со своим руководителем».

При такой постановке вопроса человек сразу начинает думать в интересном для тебя ключе, и старается вспомнить, когда же он последний раз ругался с руководителем?

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