Вот, я все ждал когда уже начнут появлятся первые новости о гонке вооружений в области собеседований.
Не представляю как изменятся собеседования в индустрии в следующие 5 лет. Мало того, что волков становится все больше, так еще теперь любой школьник может сделать систему, которая будет перехватывать аудиопоток, вычленять вопросы и отправлять в LLM генерирующую подробный ответ.
По тому, что я сейчас вижу, есть ощущение, что происходит более сильный перевес в найме через рефералку и знакомых, нежели через отклики в HH.
Не представляю как изменятся собеседования в индустрии в следующие 5 лет. Мало того, что волков становится все больше, так еще теперь любой школьник может сделать систему, которая будет перехватывать аудиопоток, вычленять вопросы и отправлять в LLM генерирующую подробный ответ.
По тому, что я сейчас вижу, есть ощущение, что происходит более сильный перевес в найме через рефералку и знакомых, нежели через отклики в HH.
😁10👍5🔥1
Последнюю неделю выпал из ведения канала, пытаюсь закончить рабочий проект до конца апреля. Поэтому пока поразгоняем более простые темы.
Самая противоречивая тема в разработке — это сроки. Есть куча аргументов от сторонников и противников. Я лично считаю, что точно рассчитать сроки вы можете только на функционал, который реализовали несколько раз. В противном случае попытка рассчитать точный срок равносильна консультации таролога — примерно одинаковая эффективность будет. Потому что тут работает базовый принцип: мы очень плохо предсказываем будущее, и может всплыть очень много неочевидных проблем.
При этом мы все работаем на бизнес. Бизнесу всегда так или иначе нужны какие-то сроки, например, для маркетинговой кампании. Есть очень интересный метод, который я услышал от Бобука, как можно прикинуть сроки для проекта, чтобы свести промахи к минимуму.
Работает следующая формула. В начале мы рассчитываем срок, исходя из нашего прошлого, на глазок. Затем мы умножаем это число на π и добавляем две недели. Почему на π, спросите вы? Исходим из того, что мы двигаемся от начала проекта к его концу.
Оптимистичное мышление подсказывает нам, что мы двигаемся по прямой. Однако в реальности, даже в лучшем случае, мы будем двигаться по окружности из-за разного рода проблем. Длина окружности у нас — это 2πr. Нам нужно пройти половину окружности, значит, πr, где r — это срок, который мы насчитали в начале.
Две недели нужно добавить вот для чего: даже если мы максимально проебались и ничего не делали весь срок, двух недель хватит, чтобы создать хоть какой-то MVP, который можно показать заказчику.
UPD: меня в комментах ткнули носом что формула: πr/2 - ведь срок у нас это не радиус а диаметр
Самая противоречивая тема в разработке — это сроки. Есть куча аргументов от сторонников и противников. Я лично считаю, что точно рассчитать сроки вы можете только на функционал, который реализовали несколько раз. В противном случае попытка рассчитать точный срок равносильна консультации таролога — примерно одинаковая эффективность будет. Потому что тут работает базовый принцип: мы очень плохо предсказываем будущее, и может всплыть очень много неочевидных проблем.
При этом мы все работаем на бизнес. Бизнесу всегда так или иначе нужны какие-то сроки, например, для маркетинговой кампании. Есть очень интересный метод, который я услышал от Бобука, как можно прикинуть сроки для проекта, чтобы свести промахи к минимуму.
Работает следующая формула. В начале мы рассчитываем срок, исходя из нашего прошлого, на глазок. Затем мы умножаем это число на π и добавляем две недели. Почему на π, спросите вы? Исходим из того, что мы двигаемся от начала проекта к его концу.
Оптимистичное мышление подсказывает нам, что мы двигаемся по прямой. Однако в реальности, даже в лучшем случае, мы будем двигаться по окружности из-за разного рода проблем. Длина окружности у нас — это 2πr. Нам нужно пройти половину окружности, значит, πr, где r — это срок, который мы насчитали в начале.
Две недели нужно добавить вот для чего: даже если мы максимально проебались и ничего не делали весь срок, двух недель хватит, чтобы создать хоть какой-то MVP, который можно показать заказчику.
UPD: меня в комментах ткнули носом что формула: πr/2 - ведь срок у нас это не радиус а диаметр
👍27😁21👏5🗿4🥰1
Наконец-то опубликовали мою статью про robolectric, немного вернулся к темам android.
Я кстати начал понимать, почему большая часть статьей корпоративных блогов такие пресные. Редактор порезала все мои агрессивные шутки и даже запретили мне обращаться к читателю на "ты", ведь не дай бог мы заденем чьи то чувства.
Благо пока канал мой не трогают. Короче вот статья, старался писать не душно https://habr.com/ru/companies/tbank/articles/902180/
Я кстати начал понимать, почему большая часть статьей корпоративных блогов такие пресные. Редактор порезала все мои агрессивные шутки и даже запретили мне обращаться к читателю на "ты", ведь не дай бог мы заденем чьи то чувства.
Благо пока канал мой не трогают. Короче вот статья, старался писать не душно https://habr.com/ru/companies/tbank/articles/902180/
Хабр
Что скрывает Robolectric и почему это важно знать?
Представьте, что можно тестировать android-код без эмулятора, запуская тесты за секунды вместо минут. Именно это обещает Robolectric — библиотека, которую либо любят, либо ненавидят, но точно не...
👍17❤11🥰1
На этапах системного дизайна любят задавать вопрос: "Что такое архитектура?" Вопрос интересный и сразу показывает, насколько кандидат широко мыслит при ответе.
Если кандидат отвечает, что архитектура позволяет проще изменять код, то это показывает, что он мыслит исключительно на уровне кода, а это значит, что он максимум мидл. Поэтому я постараюсь дать ответ на этот вопрос, который, как показывает практика, нравится всем интервьюерам.
База такая: архитектура — это инструмент, который позволяет быстрее доносить ценность как для пользователя, так и для заказчика. Хорошая архитектура дешевле и быстрее доносит ценность, плохая — медленнее и дороже.
Из этой базы исходит то, что архитектура должна решать следующие задачи:
• 💰 Сохраняет стоимость внедрения фичей. Бизнесу важно, чтобы стоимость внедрения новых фичей, которые по сложности не отличаются от предыдущих, не росла в цене. Если в начале проекта стоимость внедрения фичи X, а через полгода 2X — это проёб архитектуры, который реально может сильно ударить.
• 👥 Параллелизация работы. Представьте, что на проекте один разработчик, и у него весь проект в нескольких основных файлах. Пока он один, он, возможно, даже хорошо справляется и делает всё в срок. Однако с ростом бизнеса вам нужно открывать новые направления, и одного разраба уже не хватит. Вам нужно нанять ещё 2-3. В этом случае параллелизация работы практически невозможна, вы умрёте в конфликтах. Поэтому важная часть архитектуры в том, что она должна обеспечивать разделение работы.
• 🧪 Тестирование. Это может проявляться на уровне кода, когда вы забили на DI, и нельзя никак подменить зависимость для тестов, и никак нельзя протестировать отдельную фичу, не задев ничего другого. Также может проявляться на уровне всей системы, когда у вас нет возможности поменять конфиги для QA контура, и тестировать можно исключительно на проде — это, кстати, проблема как бэка, так и фронта.
• 🚀 Развёртывание. Не актуальный пункт для мобилок, но очень важный для бэка. Архитектура должна помогать в поднятии новой версии приложения. Если у вас приложение спроектировано так, что может работать только один инстанс и при этом много пользователей, то у вас проблемы. Ведь про zero downtime можно забыть.
• 🔄 Деградация. Хорошая архитектура должна отвечать на вопрос: "А что будет, если у нас отъебнёт база?" или, если мы говорим про мобилку: "Что будет, если инет пропадёт?"
• 👁 Observability. Это уже больше про SRE, однако каждому важно понимать, что архитектура должна давать возможность трекать состояние каждого элемента системы, чтобы быстро понимать, где именно проблема.
Мне очень нравится выражение Иванова: не бывает плохих архитектур, бывают дорогие.
Если кандидат отвечает, что архитектура позволяет проще изменять код, то это показывает, что он мыслит исключительно на уровне кода, а это значит, что он максимум мидл. Поэтому я постараюсь дать ответ на этот вопрос, который, как показывает практика, нравится всем интервьюерам.
База такая: архитектура — это инструмент, который позволяет быстрее доносить ценность как для пользователя, так и для заказчика. Хорошая архитектура дешевле и быстрее доносит ценность, плохая — медленнее и дороже.
Из этой базы исходит то, что архитектура должна решать следующие задачи:
• 💰 Сохраняет стоимость внедрения фичей. Бизнесу важно, чтобы стоимость внедрения новых фичей, которые по сложности не отличаются от предыдущих, не росла в цене. Если в начале проекта стоимость внедрения фичи X, а через полгода 2X — это проёб архитектуры, который реально может сильно ударить.
• 👥 Параллелизация работы. Представьте, что на проекте один разработчик, и у него весь проект в нескольких основных файлах. Пока он один, он, возможно, даже хорошо справляется и делает всё в срок. Однако с ростом бизнеса вам нужно открывать новые направления, и одного разраба уже не хватит. Вам нужно нанять ещё 2-3. В этом случае параллелизация работы практически невозможна, вы умрёте в конфликтах. Поэтому важная часть архитектуры в том, что она должна обеспечивать разделение работы.
• 🧪 Тестирование. Это может проявляться на уровне кода, когда вы забили на DI, и нельзя никак подменить зависимость для тестов, и никак нельзя протестировать отдельную фичу, не задев ничего другого. Также может проявляться на уровне всей системы, когда у вас нет возможности поменять конфиги для QA контура, и тестировать можно исключительно на проде — это, кстати, проблема как бэка, так и фронта.
• 🚀 Развёртывание. Не актуальный пункт для мобилок, но очень важный для бэка. Архитектура должна помогать в поднятии новой версии приложения. Если у вас приложение спроектировано так, что может работать только один инстанс и при этом много пользователей, то у вас проблемы. Ведь про zero downtime можно забыть.
• 🔄 Деградация. Хорошая архитектура должна отвечать на вопрос: "А что будет, если у нас отъебнёт база?" или, если мы говорим про мобилку: "Что будет, если инет пропадёт?"
• 👁 Observability. Это уже больше про SRE, однако каждому важно понимать, что архитектура должна давать возможность трекать состояние каждого элемента системы, чтобы быстро понимать, где именно проблема.
Мне очень нравится выражение Иванова: не бывает плохих архитектур, бывают дорогие.
👍27❤11😁5🗿3🤡1
Почему все так хейтят Сбер последнее время? В некоторых каналах заметил тенденцию, что HR к работникам Сбера относятся с таким же пренебрежением, как Яндекс к ребятам, которые долго сидели на php.
При этом речь не только про Сбер, а про любой крупный банк или компанию. С одной стороны можно понять, действительно в крупной компании, есть много команд где за тебя уже все сделано, и работаешь в полмозга. С другой, есть команды в которых ты работаешь в режиме семирукий-восьмихуй, где нужно и код пописать, и разрабов опросить, и идею продвинуть и свой небольшой сервис написать.
Наверное стоит каждого в отдельности рассматривать, а не клеймить разработчика исключительно за компанию, в которой он работал.
При этом речь не только про Сбер, а про любой крупный банк или компанию. С одной стороны можно понять, действительно в крупной компании, есть много команд где за тебя уже все сделано, и работаешь в полмозга. С другой, есть команды в которых ты работаешь в режиме семирукий-восьмихуй, где нужно и код пописать, и разрабов опросить, и идею продвинуть и свой небольшой сервис написать.
Наверное стоит каждого в отдельности рассматривать, а не клеймить разработчика исключительно за компанию, в которой он работал.
👍45👎3❤1
Последнее время от знакомых слышу, что на рынке все стало гораздо сложнее.
Вакансий гораздо меньше, вопросы стали сложнее и поиск новых мест может затянутся на несколько месяцев, против того, что раньше уходило пару недель. Какие у вас ощущения?
Вакансий гораздо меньше, вопросы стали сложнее и поиск новых мест может затянутся на несколько месяцев, против того, что раньше уходило пару недель. Какие у вас ощущения?
Final Results
30%
Искал недавно, да все правда сложнее
8%
Искал недавно, все также как и пару лет назад
1%
Искал недавно, все стало проще
61%
Не искал уже пару лет
Основная идея, вокруг которой строится успешный продукт, — это взять одну проблему, сосредоточиться только на ней и решить её лучше всех конкурентов. Яркий пример — Telegram, который зашёл на рынок мессенджеров и вытеснил всех просто потому, что был удобнее и быстрее.
Однако после того, как компания разрастается, все начинают добавлять фичи, о которых никто не просил. Тот же Telegram в какой-то момент сказал: "Я теперь не просто мессенджер — я теперь социальная сеть нахуй, держи сторисы, ну а ещё я криптокошелёк, звезды брать будешь?".
Среди таких компаний верх неадекватности — казахстанские банки. В Казахстане два основных крупных банка — это Kaspi и Halyk. Открыв приложения этих банков, ты обнаружишь, что это не банки с функцией маркетплейса, а маркетплейсы с функцией банка. Причём доходит до абсурда — в рандомный момент тебе приходит пуш от банка с текстом: "Брат, корм для кошек будешь брать?"
Это пост без какой-то умной мысли, просто крик души.
Однако после того, как компания разрастается, все начинают добавлять фичи, о которых никто не просил. Тот же Telegram в какой-то момент сказал: "Я теперь не просто мессенджер — я теперь социальная сеть нахуй, держи сторисы, ну а ещё я криптокошелёк, звезды брать будешь?".
Среди таких компаний верх неадекватности — казахстанские банки. В Казахстане два основных крупных банка — это Kaspi и Halyk. Открыв приложения этих банков, ты обнаружишь, что это не банки с функцией маркетплейса, а маркетплейсы с функцией банка. Причём доходит до абсурда — в рандомный момент тебе приходит пуш от банка с текстом: "Брат, корм для кошек будешь брать?"
Это пост без какой-то умной мысли, просто крик души.
👍34🤡19😁17❤6🔥1
Жёсткая у меня неделя была перед отпуском, я всеми силами пытаюсь закончить проект, с которым занимаюсь сексом (в плохом смысле этого слова) уже полгода. Поэтому периодически пропадаю, так как я что-то подзаебался.
Ну да ладно, пока все на чиле, я решил накидать пару советов, которые давно в голове крутятся и охото с ними поделиться:
👉Когда вам скидывают доку, сразу же переходите в нее. С высокой долей вероятности у вас не будет доступа и вы сразу об этом напишете, чем покажете свой профессионализм. Представьте лицо вашего лида, который уверен, что вы делаете задачу, а прям перед дедлайном вы заявляете, что у вас доступа к доке нет.
👉 Скопление ошибок, делал про него отдельный пост. Когда фиксите баг, проверяйте соседние фичи, очень вероятно, что в них вы также обнаружите баг.
👉 Когда делаете МР, пробегайтесь по нему глазами, как будто не вы его делали. Часто на этом этапе можно найти пару косяков.
👉 Часто лучший дебаг — это сходить прогуляться на воздухе минут 20. У этого метода даже есть научная база.
👉 Три гвоздя. Сразу предупрежу, совет сомнительный, и применяйте его аккуратно. Бывало у вас такое, что просят сделать мелкую задачу, а потом оказывается, что она уже не нужна? Совет помогает защититься от таких задач. Вот вас просят сделать какую-то штуку, вы отвечаете: "Да, конечно, сейчас сделаем" и забиваете на нее, это был первый гвоздь. Потом вас спрашивают про статус задачи, это уже второй гвоздь, тут мы все еще не трогаем задачу. Затем нас торопят уже в третий раз, это третий гвоздь, и вот тут мы уже начинаем ее делать, т.к., скорее всего, это нужная задача.
Ну да ладно, пока все на чиле, я решил накидать пару советов, которые давно в голове крутятся и охото с ними поделиться:
👉Когда вам скидывают доку, сразу же переходите в нее. С высокой долей вероятности у вас не будет доступа и вы сразу об этом напишете, чем покажете свой профессионализм. Представьте лицо вашего лида, который уверен, что вы делаете задачу, а прям перед дедлайном вы заявляете, что у вас доступа к доке нет.
👉 Скопление ошибок, делал про него отдельный пост. Когда фиксите баг, проверяйте соседние фичи, очень вероятно, что в них вы также обнаружите баг.
👉 Когда делаете МР, пробегайтесь по нему глазами, как будто не вы его делали. Часто на этом этапе можно найти пару косяков.
👉 Часто лучший дебаг — это сходить прогуляться на воздухе минут 20. У этого метода даже есть научная база.
👉 Три гвоздя. Сразу предупрежу, совет сомнительный, и применяйте его аккуратно. Бывало у вас такое, что просят сделать мелкую задачу, а потом оказывается, что она уже не нужна? Совет помогает защититься от таких задач. Вот вас просят сделать какую-то штуку, вы отвечаете: "Да, конечно, сейчас сделаем" и забиваете на нее, это был первый гвоздь. Потом вас спрашивают про статус задачи, это уже второй гвоздь, тут мы все еще не трогаем задачу. Затем нас торопят уже в третий раз, это третий гвоздь, и вот тут мы уже начинаем ее делать, т.к., скорее всего, это нужная задача.
🔥35👍9🥰1
Меня в комментариях поправили, что правильнее называть ПР (pull request) а не МР (merge request). Смотрите, вот в чем разница. Если у вашей компании дохуя денег и она рот топтала хостить у себя git, то у вас ПРы. Если же у компании мало денег или она хочет хостить git на своих серверах то у вас МРы.
😁60👏10🤔5👍2🥰1
Compose для iOS перестал быть бета-версией. Для тех, кто не в теме: Compose — это нативный React в мире Android.
JetBrains громко заявляет, что теперь это не просто технология для pet-проектов, а полноценное бизнес-решение, которое можно и нужно использовать в продакшене. Так как моя основная специализация все еще Android разработка в душе меня эта новость радует, но при этом кажется сомнительной.
Compose даже на Android не всегда работает корректно и по многим параметрам всё ещё уступает View по производительности. Наша команда по перформансу сделала дашборды с метриками отрисовки по каждому экрану, и по ним видно, что экраны на Compose часто отрисовываются дольше, чем аналогичные на View. Оно и ожидаемо, View разрабы Google оптимизировали лет 10, а Compose еще очень молодая технология.
Compose как и flutter использует Skia для отрисовки. Это значит, что по производительности он будет уступать нативным технологиям, которые напрямую работают с Metal, а не через прослойку в виде Skia.
Посмотрим что из этого получится, но как мне кажется нативный UI все равно никуда не уйдет. Как минимум потому что Apple оптимизирует все свои решение именно под Swift UI и UIKit. Какое бы крутое не было бы кроссплатформенное решение, оно все равно не приблизится к нативному.
Плюс это дикий риск для компании, если у тебя приложение на Swift UI, то ты быстрой найдешь крутых разрабов. Если же ты завязался на Kotlin, ну удачи найти разрабов именно под iOS специфику.
JetBrains громко заявляет, что теперь это не просто технология для pet-проектов, а полноценное бизнес-решение, которое можно и нужно использовать в продакшене. Так как моя основная специализация все еще Android разработка в душе меня эта новость радует, но при этом кажется сомнительной.
Compose даже на Android не всегда работает корректно и по многим параметрам всё ещё уступает View по производительности. Наша команда по перформансу сделала дашборды с метриками отрисовки по каждому экрану, и по ним видно, что экраны на Compose часто отрисовываются дольше, чем аналогичные на View. Оно и ожидаемо, View разрабы Google оптимизировали лет 10, а Compose еще очень молодая технология.
Compose как и flutter использует Skia для отрисовки. Это значит, что по производительности он будет уступать нативным технологиям, которые напрямую работают с Metal, а не через прослойку в виде Skia.
Посмотрим что из этого получится, но как мне кажется нативный UI все равно никуда не уйдет. Как минимум потому что Apple оптимизирует все свои решение именно под Swift UI и UIKit. Какое бы крутое не было бы кроссплатформенное решение, оно все равно не приблизится к нативному.
Плюс это дикий риск для компании, если у тебя приложение на Swift UI, то ты быстрой найдешь крутых разрабов. Если же ты завязался на Kotlin, ну удачи найти разрабов именно под iOS специфику.
🔥21👍8🤡3🗿3🥰1
Как я попал в команду инфраструктуры?
Начну с того, что это вообще за команда. Наша основная задача — сделать так, чтобы пайплайны проходили максимально быстро, а также чтобы разработчики своими изменениями не смогли случайно сломать полмира. Из этого вытекает, что мы занимаемся:
👉 самими пайплайнами;
👉 автоматизацией проверок;
👉 оптимизацией Gradle (рот его еб%#*);
👉 автоматизациями, связанными с релизами;
👉 разработкой подходов к тестированию;
👉 иногда — изменениями в архитектуре проекта;
👉 очень иногда — патчами кода раннеров для тестов.
Помимо этого, периодически появляются идеи в духе "а давайте подключим нейронку к логам пайплайна и посмотрим, что будет". Поэтому это уже не совсем Android-разработка, но всё ещё где-то рядом. В этой команде широкий спектр задач, которыми можно заниматься, но есть и минус — у тебя нет чётких требований. К тебе приходит тимлид и говорит: "Сделай заебись! Требований нет, чёткого плана тоже. Всё, давай."
Я попал в эту команду просто потому, что хотел сделать импакт-анализ. В тот момент она еще не называлась командой инфры, а называлась просто tech и занималась всем подряд, что не связано с бизнессом: перфоманс, архитектура, пайплайны и т.д. В любом большом проекте рано или поздно появляется такая команда. В последствии она разделилась еще на несколько. Чувак, который до меня этим занимался, увольнялся, и я напросился занять его место. Плюс у меня уже был опыт работы с пайплайнами ещё до Т-банка.
Это сыграло со мной злую шутку. Заниматься просто Android-разработкой в ближайшее время я уже не смогу — там всё стало слишком скучно. При этом полностью переключиться на бэкенд я пока тоже не готов. Вот и застрял между молотом и наковальней.
Начну с того, что это вообще за команда. Наша основная задача — сделать так, чтобы пайплайны проходили максимально быстро, а также чтобы разработчики своими изменениями не смогли случайно сломать полмира. Из этого вытекает, что мы занимаемся:
👉 самими пайплайнами;
👉 автоматизацией проверок;
👉 оптимизацией Gradle (рот его еб%#*);
👉 автоматизациями, связанными с релизами;
👉 разработкой подходов к тестированию;
👉 иногда — изменениями в архитектуре проекта;
👉 очень иногда — патчами кода раннеров для тестов.
Помимо этого, периодически появляются идеи в духе "а давайте подключим нейронку к логам пайплайна и посмотрим, что будет". Поэтому это уже не совсем Android-разработка, но всё ещё где-то рядом. В этой команде широкий спектр задач, которыми можно заниматься, но есть и минус — у тебя нет чётких требований. К тебе приходит тимлид и говорит: "Сделай заебись! Требований нет, чёткого плана тоже. Всё, давай."
Я попал в эту команду просто потому, что хотел сделать импакт-анализ. В тот момент она еще не называлась командой инфры, а называлась просто tech и занималась всем подряд, что не связано с бизнессом: перфоманс, архитектура, пайплайны и т.д. В любом большом проекте рано или поздно появляется такая команда. В последствии она разделилась еще на несколько. Чувак, который до меня этим занимался, увольнялся, и я напросился занять его место. Плюс у меня уже был опыт работы с пайплайнами ещё до Т-банка.
Это сыграло со мной злую шутку. Заниматься просто Android-разработкой в ближайшее время я уже не смогу — там всё стало слишком скучно. При этом полностью переключиться на бэкенд я пока тоже не готов. Вот и застрял между молотом и наковальней.
👍24🔥5🤯5❤4🥰1
Самый забавный собес в моей карьере
Собеседовался я как-то в компанию, которая занималась форексом, да, эдакое легальное казино. Было четыре основных этапа: HR, техсобес, разговор с CEO и секретный этап, о котором позже.
Первая вещь, которая меня смутила, — все этапы нужно было обязательно записывать на камеру. В тот момент для меня это было просто странно, а позже стало практически красным флагом.
Первые три этапа прошли нормально, даже сказать особо нечего: дефолтные вопросы от HR, очень базовые вопросы по Android и что-то вроде «behavior-интервью» с CEO. Но вот последний этап... уф. Готов поспорить, я вас удивлю.
В 99,9% случаев финальный этап — это командный фит. Созваниваетесь с будущими коллегами, обсуждаете, кто какие сериалы любит, и довольные расходитесь. HR про этот этап говорила очень расплывчато, но я был уверен, что будет именно фит.
Подключаюсь я к созвону — и вижу только одну женщину в возрасте, которую раньше не встречал. Она, обращаясь ко мне на «вы», говорит:
— Добрый день. У нас финальный этап — разговор с психологом. Мы составим ваш психотип чтобы понять, подходите ли вы команде.
И тут, как у Лавкрафта, мой ахуй был неописуем. Уже в этот момент я понял: хоть в оффере и мелькали цифры выше рынка, но этого явно недостаточно. Из чистого любопытства решил пройти этап до конца — интересно же, куда это приведёт.
По факту — ни о чём. Она задавала какие-то рандомные вопросы. Из забавного — попросила описать алгоритм приготовления яиц. Возможно, позиция предполагала готовку завтраков, кто знает. Потом она обратила внимание на мою футболку — с Шляпником и Котом из «Алисы».
Начала рассуждать, что мой выбор футболки многое говорит: «Алиса» — жанр абсурда, это указывает на высокий интеллект... Кто читает меня давно, понимают насколько она промахнулась. Футболку, если честно, надел просто потому, что не было других чистых вещей — ведь я, как и положено тру-айтишнику, стираюсь раз в год.
Короче, закончив этот карнавал кринжа, я написал HR, что ничего не выйдет — я полюбила другого. Как я слышал у этой компании в итоге дела были не очень, и очень многих сократили. На данный момент — пожалуй, моя самая забавная история с собесов.
А у вас были похожие?
Собеседовался я как-то в компанию, которая занималась форексом, да, эдакое легальное казино. Было четыре основных этапа: HR, техсобес, разговор с CEO и секретный этап, о котором позже.
Первая вещь, которая меня смутила, — все этапы нужно было обязательно записывать на камеру. В тот момент для меня это было просто странно, а позже стало практически красным флагом.
Первые три этапа прошли нормально, даже сказать особо нечего: дефолтные вопросы от HR, очень базовые вопросы по Android и что-то вроде «behavior-интервью» с CEO. Но вот последний этап... уф. Готов поспорить, я вас удивлю.
В 99,9% случаев финальный этап — это командный фит. Созваниваетесь с будущими коллегами, обсуждаете, кто какие сериалы любит, и довольные расходитесь. HR про этот этап говорила очень расплывчато, но я был уверен, что будет именно фит.
Подключаюсь я к созвону — и вижу только одну женщину в возрасте, которую раньше не встречал. Она, обращаясь ко мне на «вы», говорит:
— Добрый день. У нас финальный этап — разговор с психологом. Мы составим ваш психотип чтобы понять, подходите ли вы команде.
И тут, как у Лавкрафта, мой ахуй был неописуем. Уже в этот момент я понял: хоть в оффере и мелькали цифры выше рынка, но этого явно недостаточно. Из чистого любопытства решил пройти этап до конца — интересно же, куда это приведёт.
По факту — ни о чём. Она задавала какие-то рандомные вопросы. Из забавного — попросила описать алгоритм приготовления яиц. Возможно, позиция предполагала готовку завтраков, кто знает. Потом она обратила внимание на мою футболку — с Шляпником и Котом из «Алисы».
Начала рассуждать, что мой выбор футболки многое говорит: «Алиса» — жанр абсурда, это указывает на высокий интеллект... Кто читает меня давно, понимают насколько она промахнулась. Футболку, если честно, надел просто потому, что не было других чистых вещей — ведь я, как и положено тру-айтишнику, стираюсь раз в год.
Короче, закончив этот карнавал кринжа, я написал HR, что ничего не выйдет — я полюбила другого. Как я слышал у этой компании в итоге дела были не очень, и очень многих сократили. На данный момент — пожалуй, моя самая забавная история с собесов.
А у вас были похожие?
😁88❤2🔥1🥰1
За всё время существования HTTP есть один спор, который, к моему удивлению, не прекращается до сих пор. В протоколе есть коды ошибок, которые возвращает сервер:
👉 200-е — всё ок,
👉 300-е — редиректы,
👉 400-е — косяк клиента,
👉 500-е — косяк сервера.
Спор всегда идёт о 400-х ошибках. Вот, например, у нас есть ресурс
На моей первой работе архитектор говорил, что 404 нужно возвращать только если мы обратились к endpoint-у, которого не существует, например, к
Меня вот что поражает. Группа очень умных людей разработала протокол, в котором учли всё, что можно. Чётко описали, какой код когда использовать. Написано широкую на широкую, ебанные волки, но нет — давайте спорить о фигне, которую уже давно решили.
Потому что если подумать, то обращение по несуществующему id и к неправильному endpoint-у — это одно и то же. В обоих случаях вы обращаетесь по неверному идентификатору, и в обоих случаях нужно возвращать 404.
Другой, самый ублюдский подход — это всегда возвращать 200, а ошибку описывать в теле ответа. Таких ребят я не в коем случае не виню, все таки писать код с лишними хромасомами тяжело. Наверное, есть мнение, что при ошибке нельзя вернуть тело, в котором можно описать, что за ошибка, поэтому будем использовать 200 хз.
Короче, не усложняйте там, где не нужно. Все библиотеки для работы с HTTP по умолчанию умеют обрабатывать коды ошибок — если они указаны как ожидается, а не когда мы возвращаем 500 если немного ошиблись в полях при запросе.
👉 200-е — всё ок,
👉 300-е — редиректы,
👉 400-е — косяк клиента,
👉 500-е — косяк сервера.
Спор всегда идёт о 400-х ошибках. Вот, например, у нас есть ресурс
users/{id}. Если мы попытаемся обратиться по id, которого нет, что должен вернуть сервер: 404 или 400 со специальным описанием, что ресурс не найден?На моей первой работе архитектор говорил, что 404 нужно возвращать только если мы обратились к endpoint-у, которого не существует, например, к
persons/{id}, а не к users/{id}. Я с ним что тогда был не согласен, то и сейчас.Меня вот что поражает. Группа очень умных людей разработала протокол, в котором учли всё, что можно. Чётко описали, какой код когда использовать. Написано широкую на широкую, ебанные волки, но нет — давайте спорить о фигне, которую уже давно решили.
Потому что если подумать, то обращение по несуществующему id и к неправильному endpoint-у — это одно и то же. В обоих случаях вы обращаетесь по неверному идентификатору, и в обоих случаях нужно возвращать 404.
Другой, самый ублюдский подход — это всегда возвращать 200, а ошибку описывать в теле ответа. Таких ребят я не в коем случае не виню, все таки писать код с лишними хромасомами тяжело. Наверное, есть мнение, что при ошибке нельзя вернуть тело, в котором можно описать, что за ошибка, поэтому будем использовать 200 хз.
Короче, не усложняйте там, где не нужно. Все библиотеки для работы с HTTP по умолчанию умеют обрабатывать коды ошибок — если они указаны как ожидается, а не когда мы возвращаем 500 если немного ошиблись в полях при запросе.
👍32😁9👎5🥰4❤2🤡1
Forwarded from Банки, деньги, два офшора
В Москве изобрели программу, которая собирает досье на всех сотрудников и прогнозирует увольнения. Компания Infowatch уже запатентовала свою разработку. Проект анализирует действия каждого специалиста, затем фиксирует его стандартное поведение и любые аномалии. Программа учитывает, какие сайты посещает работник, что пишет на корпоративной почте, как часто опаздывает и даже матерится ли он в чате. В итоге детектор увольнений может сказать заранее, когда человек потерял эффективность, стал нелояльным или готовится уйти. Софт уже начали продавать компаниям. @bankrollo
🤡54😁3🔥1🥰1
Forwarded from Denis Sexy IT 🤖
Я обещал написать, как я готовился к интервью в JetBrains обвешавшись нейронками – я не забыл, делюсь
Прохождение интервью, немного другой скилл, нежели реальная работа – это про структурную презентацию прошлых достижений, в максимально сжатой форме и чем больше у вас достижений, тем больше нужно сжимать резюме и знать как презентовать
Я уже писал, что мне было интересно найти работу не как мини-инфлюенсеру через этот канал, а пройти собеседование на основе моего резюме – метил я в позиции где доступно принятие решений в продукте и робот Computer Use, как раз пошуршав на линкедине принес ссылку, что JetBrains ищет Group Product Manager в Амстердаме
Я решил попробовать откликнуться, и после того как назначили дату интервью, начал готовиться – попробую описать коротко шаги, вдруг кому-то поможет:
💬 1. Я поискал русскоязычные ТГ-каналы, которые ведут люди причастные к продакт менеджементу и наткнулся на канал @productdo; его ведут ребята из Booking, и много там рассказывали как проходит найм в Booking
💬 2. Искать посты или читать ВЕСЬ канал в 2025 уже не принято; поэтому я скачал весь их канал (сорри, чуваки!) через ТГ приложение Windows в формате JSON (Нужно нажать на ⋮ в канале и выбрать скачать JSON)
💬 3. После этого, я пошел на AI Studio от Google и прописал там:
системный промпт эксперта-суммаризатора знаний для собеседований (сделал его тут, иконка с бейджиком), в
Какая идеальная структура собеседования, для прохождение интервью в Booking, используй текст ниже:
<я тупо вставил JSON текст который скачал в пункте 3, никак его не обрабатывая>
💬 4. Выбрал модель Gemini Flash (берите последнюю доступную) и выставил температуру 0, чтобы модель не креативила ничего и запустил. Кстати, с тех пор вышла бесплатная Gemini Pro 2.5, можете ее брать.
💬 5. Модель шуршала своим гигантским контекстом в миллион токенов минуты две и после этого выдала структурный текст идеального флоу прохождения интервью – как правильно презентовать свои достижения, как правильно выбрать важные части и не важные и тп
💬 6. Естественно, первому ответу модели верить не стоит, поэтому в этом шаге тупо пишем ей:
Убедись, что ты не допустила ошибок, перепиши ответ если ошибки есть
💬 7. И все, получаем новую версию вопросов для интервью, которая почти не содержит галлюцинаций – в тексте было описана как условный Booking тестирует людей при найме, какие вопросы задает и тп.
💬 8. Дальше, создаем новый чат и выбираем в той же Google AI Studio модель Gemini Pro, в системный промпт прописываем «Эксперта по прохождению интервью» (опять же, тут генерируем системный промпт для этой роли)
💬 9. Дальше, вставляем в
Покажи как идеальный кандидат на позицию X, прошел бы интервью и ответил на эти вопросы:
<тут вставляем вопросы для интервью>
При учете что резюме кандидата выглядит так:
<тут вставляем свое резюме в виде текста>
💬 10. Выставляем температуру на 0.3, запускаем модель
💬 11. В итоге получаем ПРИМЕРНОЙ сценарий того, как могло бы выглядеть интервью, какие вопросы могли бы задавать, как ответы могли бы звучать – все это не совсем релевантно, но позволяет очень быстро начать готовиться к конретике правильно адаптируя свой спич под привычный для найма флоу
💬 12. Дальше, вы можете показать этот текст приложению ChatGPT (тупо включив режим с видео, наведя на монитор камеру и скролля текст) и попросить вас пособеседовать, позадавать вопросы, оценить ответы
⚠️ Важно:
Этот способ не гарантирует успех прохождения интервью, но это самый лучший способ, что я пробовал – потому что после него я был уверен в себе, вопросах и тому как правильно презентовать весь этот зоопарк проектов к которым я был причастен
Успехов и меньше нервов – все проблемы всегда возникают от волнения, потому что у вас скорее всего тоже синдром самозванца, а этот метод позволяет его победить
Прохождение интервью, немного другой скилл, нежели реальная работа – это про структурную презентацию прошлых достижений, в максимально сжатой форме и чем больше у вас достижений, тем больше нужно сжимать резюме и знать как презентовать
Я уже писал, что мне было интересно найти работу не как мини-инфлюенсеру через этот канал, а пройти собеседование на основе моего резюме – метил я в позиции где доступно принятие решений в продукте и робот Computer Use, как раз пошуршав на линкедине принес ссылку, что JetBrains ищет Group Product Manager в Амстердаме
Я решил попробовать откликнуться, и после того как назначили дату интервью, начал готовиться – попробую описать коротко шаги, вдруг кому-то поможет:
системный промпт эксперта-суммаризатора знаний для собеседований (сделал его тут, иконка с бейджиком), в
User Message вставил текст в стиле:Какая идеальная структура собеседования, для прохождение интервью в Booking, используй текст ниже:
<я тупо вставил JSON текст который скачал в пункте 3, никак его не обрабатывая>
Убедись, что ты не допустила ошибок, перепиши ответ если ошибки есть
User Message: Покажи как идеальный кандидат на позицию X, прошел бы интервью и ответил на эти вопросы:
<тут вставляем вопросы для интервью>
При учете что резюме кандидата выглядит так:
<тут вставляем свое резюме в виде текста>
Этот способ не гарантирует успех прохождения интервью, но это самый лучший способ, что я пробовал – потому что после него я был уверен в себе, вопросах и тому как правильно презентовать весь этот зоопарк проектов к которым я был причастен
Успехов и меньше нервов – все проблемы всегда возникают от волнения, потому что у вас скорее всего тоже синдром самозванца, а этот метод позволяет его победить
Please open Telegram to view this post
VIEW IN TELEGRAM
👍40🔥6🗿6❤1🥰1
Интересные вайбы возникают, когда уходишь в отпуск в 2025. На секунду отвернулся, а там уже вышло 48 новых агентов, которые угрожают тебя заменить.
😁36👍6🔥3
Зинатутин у себя в твиттере написал про свой SaaS, который они пилят с другом. Кто не знает, Зинатулин это топовый инфраструктурщик в мире Android.
Это очень показательный пример того, как крутой инженер пытается запустить свой продукт. Он очень много описывал про то, как у них все круто покрыто тестами, что они все сразу оптимизируют под ARM, чтобы все летало, про то, что у них уже 8 (восемь КАРЛ!) микросервисов.
Когда же спросили, а что делает то продукт, какую проблему он решает? В ответ было, ну мы там запустимся соберем фидбек, короче позже отвечу.
Я бесконечно уважаю Зинатулина, но пока это выглядит очень потешно)
Это очень показательный пример того, как крутой инженер пытается запустить свой продукт. Он очень много описывал про то, как у них все круто покрыто тестами, что они все сразу оптимизируют под ARM, чтобы все летало, про то, что у них уже 8 (восемь КАРЛ!) микросервисов.
Когда же спросили, а что делает то продукт, какую проблему он решает? В ответ было, ну мы там запустимся соберем фидбек, короче позже отвечу.
Я бесконечно уважаю Зинатулина, но пока это выглядит очень потешно)
😁45👎1🥰1