Мой рекорд — 3 месяца с момента первого контакта с рекрутером. Да, добиться общения с живым человеком не так просто. А дальше — оффер, документы, релокация, но это уже другая история.

В целом, считаю норм в текущих условиях. Но любимый мем на эту тему у меня успел появиться⬆️

А что из relatable мемов про IT есть у вас? Кидайте в комментарии ⬇️

Признайтесь, вы тоже приукрашиваете своё резюме?

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

Нет, не когда человек не знает какой-то алгоритм с LeetCode. Это как раз норма. Удивляет, когда резюме выглядит как мечта, а в реальности — просто набор слов, который мало соотносится с соискателем.

Помню, как-то собеседовал кандидата. У него в резюме — 4 года опыта с PostgreSQL. Я не спрашиваю про индексы B-tree, не пытаю про тонкости MVCC. Я просто спрашиваю: «А когда PostgreSQL ломается?». И тут наступает неловкое молчание. Лицо собеседника меняется, а у меня в голове: «4 года и ни разу ничего не пошло не так?». Извини, но не верю.

И дело не в том, что кандидат должен быть энциклопедистом. Понятно, что для CRUD-приложения это некритично. Но разработчик, который реально работал с инструментом, знает его больные места. Он знает, когда стоит использовать Postgres, а когда лучше взять что-то другое. Он видит его ограничения.

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

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

🐈 Котятки, давайте как на духу — ваше резюме на 100% честное? Или пара пунктов всё же выглядит более внушительно, чем есть на самом деле?

Самый сложный проект в моей практике

Вчера отвечал на вопросы для рубрики телеграм-канала «Слёрм» и один из вопросов меня зацепил. Звучит он так:

🟣 Какой был самый сложный проект в твоей практике и почему?

И мне кажется, здесь не всё просто. Потому что смотря что понимать под сложными проектами. Сложно, например, когда:

▶️ есть много внешних зависимостей
Ты разбираешь инцидент и понимаешь, что снаружи, даже не в твоей компании, от чего-то зависишь, и нужно сначала добиться от них признания, что проблема на их стороне. Потом, чтобы они починили проблему. И ты не можешь ничего сделать сам, потому что даже не имеешь доступ, просто ходишь по APIшке.

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

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

Всё 3 кейса встречал за свою карьеру. Некоторые — более 1 раза. Наверное, это как раз самое сложное в проектах для меня.

Какой самый сложный кейс (не обязательно технический) вам приходилось решать ?

Вы уверены, что ваш Pod — это готовый сервис? Именно эта мысль часто отделяет джуна от миддла

27-28 сентября состоится воркшоп «С нуля в прод за 2 дня». Забудьте про сухую теорию. Здесь вы за два дня прокачаетесь от «поднял контейнер» до «запустил отказоустойчивый сервис в продакшене»

Вас ждёт не скучная лекция, а полный цикл на реальном стеке (Next.js + Go):
➡️ Спроектируете инфраструктуру, которая не развалится после первого деплоя
➡️ Настроите CI/CD-пайплайн, который не стыдно показать коллегам
➡️ Перейдёте от мышления контейнерами к мышлению сервисами и их взаимодействием

🔥 Ведущий — Павел Минкин, DevOps-инженер в FinTech, который знает, как строить системы, не падающие под нагрузкой.

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

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