Ты скорее всего не умеешь задавать вопросы

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

Еще в далеком 2017 году, когда я устроился на свою первую работу джуном, мое первое задание было такое - "Научись гуглить и задавать качественные вопросы". Это очень сильно отпечатолось в моей памяти)

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

- "Не работает"
- "Я не понимаю"
- "Что за фигня?"
- "Почему ручка не возвращает 200?"
- "Почему ловлю panic? "

И дальше — тишина, раздражение и ощущение, что «я тупой».

❌ Почему такие вопросы — плохие

Не потому что ты глупый. А потому что в вопросе нет данных. Все просто ;)

Когда ты пишешь:

"У меня не работает хендлер"

Ты на самом деле говоришь:

"Угадай, что у меня в голове, коде и контексте"

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

🧠 Что на самом деле хотят видеть, когда ты задаёшь вопрос

Хороший вопрос — это не просьба «дай ответ». Это демонстрация мышления и четкого структированного алгоритма действий, который ты проделал, чтобы прийти к этому вопросу

Человек, которому ты пишешь, должен увидеть:

1) что ты передал ему контекст задачи(что нужно сделать/итоговая цель?)

2) что ты попробовал варианты

3) где именно ты застрял

4) какие гипотезы у тебя есть по решению проблемы

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

❌ Пример плохого вопроса

- "Почему у меня падает сервис в Go? "Уже устал дебажить, все надоело!"

На такой вопрос невозможно ответить.Потому что вариантов — сотни, это как спросить, какой сегодня год?
В разных календарях он может быть разный

✅ Пример нормального вопроса

Есть HTTP-хендлер, под нагрузкой часть запросов висит. Логи показывают, что горутины не завершаются.

Проверил: контекст не отменяется, mutex не используется.

Подозреваю, что проблема в канале или отсутствии таймаута на такой-то строчке в таком-то файле

Подскажи, пожалуйста:

- Хватает ли тебе исходных данных? Если да, то в какую сторону копать и были ли у тебя такие кейсы?

Даже если гипотеза неверная, уже есть стартовая точка с которой можно начать отвечать.

Ниже подготовил для тебя мини-чеклист как задать хороший вопрос, проходись перед тем как задать кому-либо(даже LLM)

Перед тем как задать вопрос, проверь:

1)❓Что я хочу понять? (конкретно)

2)📍Где именно проблема? (код / место / шаг)

3) 👀 Что я уже пробовал?

4) 🧠 Какая у меня гипотеза?

5) ⛔️ Где я застрял и почему дальше не могу?


🎯 Главный инсайт

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

- Скорость твоего роста как программиста
- Качество принимаемых тобою решений
- Впечатлению о тебе как инженере - да-да, 1 из ключевых по моему мнению отличий Junior/Middle/Senior как раз в том как и какие они задают вопросы

Хорошие вопросы ускоряют тебя. Плохие — делают зависимым от решения других людей


И важный момент напоследок.

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

В следующем посте разберём, что такое декомпозиция задач на самом деле:

1) Почему без неё не работает ни обучение, ни работа,

2) Почему большинство «я не понимаю» — это не проблема знаний, а проблема структуры мышления.

Почему декомпозиция задач поможет тебе уже прямо сейчас в учебе

Возвращаясь к посту выше, большинство проблем в обучении складывается из-за плохо поставленных вопросов, либо расфокуса, либо из-за неспособности "сьесть слона" aka декомпзировать(разбить) задачу

Типичные реплики, которые говорят о проблеме:

- "я не понимаю задачу"
- "слишком сложно"
- "не знаю, с чего начать"
- "я застрял"

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


Что такое декомпозиция на самом деле

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

✖️ Пример из жизни без декомпозиции:

"хочу устроиться Go разработчиком на зп от 300к"

В голове:

🟢"рынок сложный"

🟢"вакансий мало"

🟢"я не готов"

🟢 "надо ещё учиться"

Результат:

🟢курсы за курсами

🟢хаотичное чтение статей

🟢вечная подготовка

🟢ноль офферов


✔️Пример с грамотной декомпозицией


1️⃣ Куда именно я хочу устроиться?

1.1) Junior или middle?

1.2) Продукт или аутсорс?

1.3) Go как основной язык или «один из»?

2️⃣Что от меня реально ждут на собеседованиях?

2.1) Какие темы по Go спрашивают чаще всего?

2.2) что проверяют помимо языка?

2.3) какие инструменты must-have?

3️⃣Где у меня пробелы прямо сейчас?

3.1) Concurrency?

3.2) SQL?

3.3) Прохождение System Design?

3.4) Не могу объяснять решения вслух?

4️⃣Что мне нужно учить, а что — нет?

4.1) Внутрянка компилятора - 👎

4.2) Как работает бинарный поиск - 👎

4.3) Работа планировщика Golang - 👍

4.4) Указатели в Go - 👍

5️⃣ Как я пойму, что готов идти на рынок?

5.1) Могу ответить на типовые вопросы?

5.2) Могу решить простые задачи?

5.3) Могу внятно рассказать о своём опыте?

Как видишь после декомпозиции, появляется множество вопросов/ответов и становится не так уж и сложно

Внезапно:

🟢Цель становится конечной

🟢Появляется план

🟢Становится понятно, что делать сегодня, а не «когда-нибудь»


И главное — исчезает иллюзия, что:

"Сначала нужно выучить Go целиком"

"Почему «я ещё не готов» — самый безопасный способ никогда не выйти на рынок"

Задавался ли ты себе вопросом или были ли в твоей голове такие мысли:

- "я еще не готов, вот нужно еще пару недель подготовиться и тогда точно буду готов"?

Будем честны - "да".

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

Ты себе ее говоришь, чтобы не столкнуться с реальностью, получить отказы(это любому неприятно), увидеть в чем реально у тебя пробелы

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

Как понять, что ты "болен" этим:

1) Когда тебя говорят - "Иди на собес", ты придумываешь оправдания

2) От одной мысли что завтра собес - у тебя тряска

3) Если даже тебя форсят пойти на собес - ты его бесконечно переносить в надежде "Чуть-чуть еще и пару дней подготовлюсь"

4) Ты судорожно реагируешь на отказы как не на процесс поиска работы, а как на приговор в суде - "ТЫ ВИНОВЕН"

И итогово после появления таких симптомов все обычно заканчивается следующим образом:

◾️1. У тебя страх потратить попытку впустую» → не делаешь отклики и аутричи, ждёшь более подходящий момент или когда тебя сами напишут

◾️2. Проходит 2 недели → кажется, что рынок сейчас «не лучший», надо ещё подкачаться

◾️3. Проходит еще 2 недели → планка ожиданий растёт: раз так долго готовился, результат должен быть идеальным, же? + друзья спрашивают - "Ну что там со своим айти?"

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


Но это все лечится через следующие способы:

✅ ШАГ №1 - Признать себе, что ты первые 3-5 собесов ты завалишь

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

Новые действия делать всегда страшно, но это будет эффективнее 10-ки прочитанных статей теории

✅ ШАГ №2 - Понять что статистика и вероятность на твоей стороне - 1/10 технических собесов в среднем оффер

Математика на нашей стороне. Рано или поздно ты все равно получишь оффер, вопрос только времени и качества твоей воронки(но это уже тема для отдельного поста)

✅ ШАГ №3 - Осознать, что ошибки, которые ты извлекаешь на собесах - датасет для твоего развития

Ходим на собесы → Отсматриваем собесы и анализируем → Подучиваем/Практикуемся на своих слабых местах → Идем на собес → Получаем оффер

✅ ШАГ №4 - После 5-10 собесов у тебя формируется иммунитет к отказам

Понимаешь, что это часть пути роста, у тебя уже нет страха собеседований и тряски. Воспринимаешь как данность и неизбежность, поэтому понимаешь - "Понял, посмотрю что не так сделал, поработаю над этим, тк у меня еще 5 собесов за эти 2 недели"

Вывод:

Надо просто начать и лажануть, тк это тоже часть учебы и неизбежный процесс. И все через это проходили :)

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

Получилось достаточно обьемно, но полезно)


👉 ССЫЛКА ЗДЕСЬ 👈

Контекст в Go: зачем он нужен, если «и так работает»

Контекст в Go часто воспринимают как формальность: его нужно прокинуть, потому что так требует стандартная библиотека или "Ну так принято, зачем нужно добавлять, работает же?" . От части правда, по сервис маленький, нагрузка небольшая, все ок. Но проблемы начинаются не тогда, когда что-то не работает, а тогда, когда ты потерял контроль над временем жизни операции — запросами, горутинами, блокирующими вызовами. Именно для этого в Go появился пакет context и он стал стандартом для всех реальных бекендов.

🔘1. В Go контекст — это интерфейс:

type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key any) any
}

Он не выполняет работу, а сообщает условия, в которых работа имеет смысл:

- можно ли продолжать,

- есть ли дедлайн,

- почему операция завершилась,

- какие метаданные относятся к запросу.

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

🔘2. Контекст —по своей сути это контракт.

Он определяет условия выполнения операции и транслирует их через границы API и между горутинами. Важно понимать, что сам по себе он ничего не делает — но весь код, который его использует, становится управляемым, за счет того что у тебя есть возможность вызвать методы отмены, таймаута и тд.

Например, если клиент закрыл соединение, весь код ниже по цепочке тоже получает сигнал «уже не нужно продолжать».

🔘3. Виды контекстов

3.1 Context.Background()

context.Background()

Пример:

func main() {
    ctx := context.Background()
    runApp(ctx)
}

По практике используется для каких-то фоновых воркеров или при инициализации сервиса

3.2 Context.TODO()

context.TODO()

Из названия очевидно, что это временная заглушка. На практике либо такое не делают, либо делают, но крайне редко.

Она означает: «контекст нужен, но архитектурное решение ещё не принято». В продакшене это почти всегда технический долг.

4. context.WithCancel() — ручное управление остановкой

Используется, когда момент остановки определяется логикой, а не временем.

Пример:

ctx, cancel := context.WithCancel(parentCtx)
defer cancel()

go workerA(ctx)
go workerB(ctx)

// если нашли результат или произошла ошибка
cancel()

Важно:

- cancel() не убивает горутины

- он лишь закрывает ctx.Done()

- если код не проверяет контекст — отмены не будет

5. context.WithDeadline() — жёсткий момент во времени

Используется, когда есть конкретное время, после которого операция теряет смысл.

Пример:

deadline := time.Now().Add(2 * time.Second)
ctx, cancel := context.WithDeadline(parentCtx, deadline)
defer cancel()

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

6. context.WithTimeout() — самый практичный вариант

Обёртка над дедлайном, когда важна максимальная длительность ожидания.

ctx, cancel := context.WithTimeout(parentCtx, 500*time.Millisecond)
defer cancel()

7. context.WithValue() — самый опасный инструмент

Пример:

ctx = context.WithValue(ctx, key, value)

Типичные кейсы использования:

1) HTTP-запросы

2) БД

3) Вызов внешних сервисов

❗️Базовые правила использования Context ❗️

1) Контекст передаётся первым аргументом и называется ctx, потому что он задаёт условия выполнения операции.

2) Контекст нельзя хранить в структурах — его время жизни почти всегда короче, чем у объекта.

3) Контекст должен пробрасываться по всей цепочке вызовов, иначе управление жизненным циклом ломается.

4) nil-контекст запрещён. Если не знаешь, что использовать — используй context.Background()


Итого:

context.Context — это не формальность и не «обязательный аргумент». Это набор методов, который помогает управлять жизненным циклом запроса.

P.S В следующих постах рассмотрим типовые вопросы на собесах

Рост в грейде начинается с новых действий, а не с новых знаний

Как-то раз, когда я рабол в Окко, мой руководитель сказал фразу, которую я запомнил

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

К примеру если ты middle разработчик => тебе нужно делать то что делают senior разработчики и тд.

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

Типичные фразы:

- «Мне бы ещё подучить…»
- «Вот это выучу и точно сеньора дадут...»
- «На следующем перфоманс ревью точно повысят...»

Но по факту:

Проходит время.
Знаний стало больше.
Грейд — тот же.
Деньги — те же.
Роль — та же.

А почему?

Потому что знания не примененные на практике без достижения результат = мусор

Тоесть ты что-то выучил, к примеру как работает Saga, но если ты не применил на практике и это не дало никакой профит для компании, то наврядли тебя апнут, that's easy.

Ниже кейсы, на которые можно посмотреть с разных ракурсов и понять подход


Кейс №1 - Kafka consumer отстаёт

❌

Наверное, Kafka лагает, увеличим партиции

✅

Ты: Оповещаешь команду, смотришь lag по consumer group, понимаешь, что сообщения обрабатываются по одному, сделал параллельную обработку и понял что очередь перестала расти. И как результат фикса фиксируешь это в документацию у себя в тикете или в чате


Кейс №2 - Упал прод ночью

❌ -

«Ну упало и упало, починили же»

✅

Ты: Оповестил команду, поставил в известность дежурного, рестартанул сервис, начал мониторить логи/метрик/трейсы, после этого нашел по логам проблему, определил приоритет по ZBP и пофиксил. Далее после фикса затестировал это все и катнул на stage/prod и смотришь метрики/лог. Убеждаешься что все ок и заводишь LSR

Кейc 3. Код-ревью

❌ -

«У нас плохой процесс код-ревью и не понятно что и когда смотреть»

✅

Ты: Подсветил и обозначил проблему среди команды на очередном созвоне, далее предложил 3-ух уровневый процесс code review, внедрение системы поиска мертвого кода, линтинга, предложил AI Agent Reviewer. С командой попробовали новый формате в течение пары спринтов и убедились что улучшилось: качество ревью и скорость. В следствии чего лид доволен, тк спринты закрываются, метрика lead time улучшилась


После таких активностей и самое главное подходу что ты:

1) Находишь проблему, проявляя инициативу и проактивность
2) Предлагаешь сам решение и еще с разными вариантами, взвесив + и -
3) И реализуя это все в срок

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

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

Важная мысль

Грейды повышают не за то что ты выучил фреймворк X и не за количество прочитанных статей, а за поведение действия, которые привели тебя к результату Y, в процессе которых ты выучил что-то

Учиться — безопасно.
Действовать — страшно.

Но когда говоришь:

«Я не уверен на 100%, но беру и делаю»

вот здесь происходит трамплин вверх 🚀

Что по итогу?

📞 Новые знания без действий — это имитация роста

😡 Комфорт — главный враг грейда

😆 Ответственность всегда опережает повышение, а не наоборот

Какой минимальный минимум реально нужен Golang-инженеру для первой работы?

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

Путь разработчика можно разбить на этапы. В каждом есть и техничка, и софты. Посмотри, где ты сейчас и что мешает перейти дальше.


1) «Глохнешь - бросаешь сцепление» 😠

Ты вроде за рулём, но машина постоянно глохнет. Руки и голова не синхронизированы, много нервов и неуверенности. Каждый отказ на собесе воспринимается как приговор и подтверждение мысли «оффер невозможен».

Техничка

Go живёт своей жизнью: slice растёт неожиданно, map «падает», pointer receivers — «где-то видел», panic и error почти одно и то же. Про горутины знаешь, но как их корректно останавливать - туманно. HTTP, context, Postgres, Redis - знакомые слова без цельной картины.

Софты

Страх ошибки, желание молчать, если не уверен на 100%. Постоянное ощущение «ещё рано» и «я хуже других». Ошибка = доказательство некомпетентности.

Сигналы

Постоянно гуглишь базу, боишься рефакторить, отвечаешь «ну так принято», теряешься на простых вопросах.
Если ответы похожи на 50/50 в «Кто хочет стать миллионером» - ты здесь.


2) «Уже поехал, но едешь осторожно и неуверенно» 💃

Ключевая стадия для первой работы. Машина едет, но ты напряжён, иногда путаешься и периодически глохнешь.

Техничка

Язык больше не враг. Понимаешь структуры данных, где sync, где каналы, как ловятся гонки. Осознанно используешь горутины. HTTP-хендлеры без магии, context по назначению. Postgres и Redis - инструменты: индексы, транзакции, N+1, explain analyze.

Ты можешь объяснить решение, но своё придумывать пока тяжело.

Софты

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

Сигналы

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

Ключевое - не заучивание, а понимание и практика.

3) «Уже едешь уверенно» 😎

Это уже не про первую работу, а про зрелость. Ты понимаешь, зачем правила существуют.

Техничка

Видишь систему целиком: GC, аллокации, гонки. Kafka, гарантии доставки, дедуп.
System design - про компромиссы: stateless vs stateful, репликация, шардинг, балансировка, CDN.
Логи, метрики, трейсы - инструменты управления SLO.

Софты

Берёшь ответственность, объясняешь трейд-оффы, спокойно работаешь с неопределённостью. Умеешь договариваться и выбирать «проще сейчас, лучше потом».

Сигналы

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


Вывод

Готовность к первой работе в backend - это не идеальная техничка и не отсутствие ошибок.
Это момент, когда ты уже едешь, иногда косячишь, но понимаешь, что происходит и как вырулить.
Если ты узнаёшь себя во второй стадии - тебе уже пора выходить на рынок. Остальное добирается по дороге, а не на парковке.

ТЫ ВКАТУН!? 👀 Или что выдает в тебе накрутчика на собеседовании? (Ч1)


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

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

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

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

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

🚩Маркер №1 Нет конкретики - один набор несвязанных предложений воедино

Кандидат начинает рассказывать про свой опыт так, как будто он хочет как можно больше назвать ключевиков и стреляет словами по типу - "Kafka", "PostgresSQL", "Redis", "k8S", но не может все связать в единую историю.

📌 Пример:

Кандидат: «Ну мы использовали микросервисы, Kafka, Postgres, Redis…»
Интервьвер: «Почему именно микросервисы у вас были?», "В каких кейсах у вас использовался Redis?" «Как поняли что нужно использовать Redis, смотрели ли в сторону альтернативных решений?», «Какой результат в итоге получился?»

❓Как исправить?

Оформи свой опыт в рассказ по фреймворку:

1. Кто я
├─ Кто я по роли сейчас
│ └─ "Backend Go-разработчик"
├─ В каком домене и стеке
│ └─ "b2b / b2c, высоконагруженные сервисы"
└─ Что ищу дальше
└─ "Хочу больше ответственности и влияния, а не просто тикеты"


2. Опыт (по последнему / ключевому месту работы)
├─ 2.1 Компания
│ ├─ Тип
│ │ └─ продукт / аутсорс / стартап
│ ├─ Стадия
│ │ └─ рост / прод / легаси
│ └─ Домен
│ └─ финтех / e-commerce / etc
│
├─ 2.2 Проект / продукт
│ ├─ Что делает продукт
│ │ └─ "Сервис обработки платежей"
│ ├─ Кто пользователь
│ │ └─ бизнес / конечные юзеры
│ └─ В чём ценность
│ └─ стабильность / SLA / скорость
│
├─ 2.3 Команда
│ ├─ Размер
│ │ └─ 5–8 человек
│ ├─ Роли
│ │ └─ backend / frontend / QA / DevOps
│ └─ Принятие решений
│ └─ тимлид / совместно
│
└─ 2.4 Достижения (итерация по каждому кейсу)
├─ Достижение №1
│ ├─ Situation
│ │ └─ Что болело на проекте
│ ├─ Task
│ │ └─ Какая была цель
│ ├─ Action
│ │ └─ Что сделал ТЫ (не команда)
│ ├─ Result
│ │ └─ Цифры или эффект
│ └─ Reflection
│ └─ Что понял / что сделал бы иначе
│
├─ Достижение №2
│ ├─ Situation
│ ├─ Task
│ ├─ Action
│ ├─ Result
│ └─ Reflection
│
└─ Достижение №N
├─ Situation
├─ Task
├─ Action
├─ Result
└─ Reflection

А если уж совсем упростить, то просто возьми и соблюдай алгоритм:

✔ «Была проблема → предложил решение → сделали → получили результат».

🚩Маркер №2. Тряска, как перед защитой диплома

Прямое проявление страха, от страха провала или неизвестности. Ты заходишь на собес, сердце стучит, ладони уже в поту, по лбу льется пот, и пулсь за 200+, как будто ты сейчас пробежал олимпийский марафон. Знакомо?

📌 Пример:

Любой уточняющий вопрос = паника, извинения, оправдания, покраснения и желание ливнуть.

❓Как исправить?

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

10 пройденных собесов и страх уйдет.

Что дальше?

Телеграм ограничил длину поста, поэтому следующие советы будут в следующих постах

Ставь 🔥- если ждешь дальше маркеры
Ставь ❤️ - если вкатун

ТЫ ВКАТУН!? 🤡 Или что выдает в тебе накрутчика на собеседовании? (Ч2)

Продолжаю накидывать еще мысли и флаги, которые замечал

🚩Маркер №3. Не можешь обьяснить в глубину

Данный маркер - это не 100% знак наличие у тебя "fake" опыта, но согласись странно когда кандидат с минимум 3-мя годами опыта приходит и не может рассказать как работают syscall в планировщике?

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

Пример:

Интервьювер: «Где в Go-приложении ты видел реальные проблемы с производительностью?»
Кандидат : «Ну там в авторизациия»
Интервьювер: «Это было CPU, память или I/O?»
Кандидат: «Росли метрики при нагрузках»
Интервьювер: Как вы это обнаружили? Что поменяли в коде что привело к этому?»
Кандидат: «Точно не знаю/не помню»

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

➡️Хорошо проработанная легенда
➡️Скилл "слиться с таких вопросов"


🚩Маркер №4. Теория без шрамов — что это вообще значит


Проблема не в том, что человек знает теорию. Проблема в том, как он её знает.

Есть два типа знания.

Первый — книжный. Он аккуратный, чистый, правильный. Ответы звучат как документация или статья на Medium. Всё логично, всё верно, всё без единой запинки. В этом нет ничего плохого, это нужно.

Второй — прожитый. Он неровный, иногда с паузами, иногда с «мы тогда облажались», но в нём всегда есть следы реальности: ограничения, костыли, компромиссы, последствия. Часто транслируется через фразы по типу «Помню вот такой случай», «Есть история с использованием этогого подхода»


Как это выглядит со стороны интервьюера

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

Пример. Спрашивают про каналы в Go.
Ответ — безупречный: что такое, зачем, как работают, когда закрывать.

А потом уточняют:
«Были случаю когда паники ловил с использованием каналов?»
И начинается зависание.

Не потому что человек глупый.
А потому что он не связывал знания с болью.

Для интервьюера это звучит так:

«Я знаю, как должно быть. Но я не знаю, как бывает на самом деле.»

😵‍💫

Поэтому ключевой инсайт из этого - что если рассказываешь про что-то постарайся в свой речевой аппарат встроить фразы по типу «У нас вот такой было Y, использовал это в X, как-то была опция тестировать в проекте это и закончилось это W»


Формула: Отвечаю на вопросы 👉Сразу привожу пример из жизни(даже выдуманный 😁)

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


Подытожим:

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

Многие менторы учат отвечать на то как надо, но не учат тому "А что у меня было такого, из чего я извлек урок и могу об этом поделить на собеседовании" 😏


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

Как подготовиться к реальному Golang Interview без оплаты от 5-15к за мок-собес с помощью AI-напарника/интервьювера?

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

Ниже подготовил для тебя ❤️ подборку приемов, которые можно использовать в связки с AI для подготовке к собесу:

1) ChatGPT Voice mode + промпты под конкретный этап собеседования

🔗 HR-скрининг:

AI — HR. Прогоняет самопрезентацию, мотивацию, причины смены работы. Убирает воду и клише из ответов.

Промпт:

Ты — HR из продуктовой IT-компании.
Ты проводишь первичный скрининг Go-разработчика.

Твоя задача — проверить:
мотивацию,
адекватность ожиданий,
умение рассказывать о себе,
причины смены работы.

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

🔗 Технического этапа:

AI — жёсткий интервьюер. Задаёт вопросы по Go, копает вглубь, давит прод-контекстом, не подсказывает. Ты отвечаешь структурировано, учишься держать мысль и не теряться.

Промпт:

Ты — опытный senior Go-разработчик и интервьюер из продуктовой компании
(высокие нагрузки, прод, реальные инциденты).

Твоя задача — проводить техническое интервью по Golang в формате живого диалога
(voice live mode), постепенно углубляясь в тему.

Правила интервью:
1. Начинай с одного базового вопроса по Go.
2. После каждого моего ответа:
- если ответ поверхностный — копай глубже
- если ответ неточный — задавай уточняющий вопрос
- если ответ хороший — усложняй контекст (прод, edge cases, компромиссы)
3. Не подсказывай и не объясняй, пока я не отвечу.
4. Дави вопросами вглубь: ownership, lifecycle, concurrency, prod-баги.
5. Задавай вопросы так, как на реальном senior-собесе, без воды и учебников.
6. Иногда проси привести реальный кейс из продакшена.
7. Если я говорю «не знаю» — предложи рассуждать вслух, а не давай ответ.
8. Общайся устно, короткими фразами, как на живом собеседовании.
9. Не хвали. Максимум — «ок, идём дальше».

🔗Soft-skills этап:

AI — тимлид/нанимающий менеджер. Проверяет конфликты, ответственность, ошибки, давление сроков.

Промпт:

Ты — тимлид продуктовой команды.
Ты проводишь soft-skill собеседование с senior Go-разработчиком.
Твоя цель — понять, как кандидат думает, спорит, берет ответственность и работает с неопределенностью.

Задавай вопросы про:
конфликты в команде,
несогласие с архитектурными решениями,
ошибки в продакшене,
давление сроков,
обратную связь от бизнеса и коллег.

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

Как все это использовать?

1. Зайди в ChatGPT
2. Cоздай чат
3. Выбери Voice Mode
4. Вставь туда выбранный промпт
5. Profit ✅

Рекомендую идти по этапам начиная с HR скрининга, как только будешь чувствовать себя уверенно и отвечать на 80% вопросов идешь к этапам дальше

2. Использование кастомного GPTs для подготовки по вопросам

GTPs - это кастомно настроенный chatgpt с упором на подготовку с Golang интервью. Не долго искав, нашел хороший GPTs тут

Механика просто как 2 + 2. Ты задаешь ему правило работать с 2-ух режимах:

◾️Он задаёт тебе вопросы — ты отвечаешь. Важно еще сказать, чтобы сложность вопросов линейно росла с уровнем правильности твоих ответов
◾️Ты сам задаёшь ему вопросы, но не просишь «объяснить», а просишь оценить твой ответ или рассуждение. Ценность такого подхода в том, что ты шлифуешь свои ответы.


А что дальше?

Теперь у тебя есть способы подготавливаться к собесам по Go с ИИ, но теперь нужно рассмотреть, а как можно разобрать уже пройденное собеседование. 🍿

Один простой шаг после собеседования, который резко повышает шанс на оффер🤑

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

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

У тебя есть несколько вариантов:

1) Обратиться к ментору, чтобы он разобрал персонально, но есть свои плюсы и минусы:

➕ Плюсы:

➡️Индивидуально разберет твои собесы с точки зрения своего опыта, что не может AI

➖Минусы:

➡️ Дорого и надо найти ментора - помним, что в среднем 1ч мок-собес стоит от 5к, но можно найти дешевле, ну и как договоришься, но это будет точно не бесплатно и не быстро, если это не твой знакомый конечно

2) Обратиться к нейронке:

➕ Плюсы:

➡️Выдаст много инфы по собесу(в завимости от качества и настройки промпта)
➡️Неограничен количеством записей собесов, можно загрузить сразу 10 собесов и все разобрать, найдя систематические ошибки, а они точно есть

➖ Минусы:

➡️Нет персонализации и основы реального опыта, не даст жизненные лайфхаки и фишки


Теперь переходим конкретно к самому чек-листу как реализовать ревью твоего собеса от AI буквально за 30 мин

1. Записываем собеседование на видео через OBS или аналог

Первое, что здесь нужно сделать — начать фиксировать реальность, а не полагаться на память. Для этого проще всего использовать OBS Studio. Это бесплатный и легальный инструмент, который ставится за 5 минут. После установки достаточно добавить источник «Захват экрана», выбрать нужное окно (например, Zoom или Google Meet), проверить микрофон и нажать «Start Recording». Важно писать не только экран, но и звук😁 — именно в голосе, паузах и формулировках чаще всего кроются проблемы, которые ты не замечаешь в моменте.

2. Транскрибируем видео в текст

Когда запись готова, следующий шаг — превратить видео в текст.

Читать и анализировать себя в txt-файле в разы эффективнее, чем пересматривать часовое видео. Представь сколько часов видео ты бы мог сэкономить с этим

Для этого подойдут сервисы автоматической транскрибации:

🟢Otter.ai
🟢Evernote
🟢VideoTransriber - бесплатный транскрайбер без лимитов
🟢TurbosScribe - использую его, подписка для безлимитных загрузок и транскрибаций стоит $20

Механика простая, загружаешь видео собес и получаешь транскрибацию видео в текст с таймкодами, а также с кратким содержанием и mind map. Далее этот текст мы грузим в ChatGPT/Claude и готовим вот такой промпт:

Ты - Senior Golang разработчик и интервьюер/карьерный ментор.

Проанализируй транскрипт собеседования кандидата.

1. Выдели сильные стороны: где ответы были уверенными, структурированными и по делу.

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

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

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

Отвечай максимально конкретно, с примерами из текста.

На этом этапе обычно происходит самое болезненное, но полезное открытие: ты начинаешь видеть, что проблема часто не в «сложных вопросах», а в том, как ты думаешь и говоришь под давлением. Кто-то отлично знает хорошо Go, но разваливается на объяснениях, кто-то наоборот красиво рассуждает, но путается в базовых вещах. Но самое главное, что ты теперь понимаешь свои ошибки и можешь исправляться

Вывод:

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

Собеседования в IT или какие там обычно этапы 📞


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


1️⃣ HR screening — это короткий созвон, где проверяют базовые вещи: опыт, мотивацию, ожидания по зарплате/формату работы, английский, адекватность коммуникации.

Тут же часто просят рассказать “кто ты и что делал”, какие у тебя есть достижения и смотрят, умеешь ли ты понятно упаковать свой опыт в 2–3 минуты(самопрезентация зашла в чат), без хаоса и лишних деталей, плюс задают вопросы про проекты и ответственность, чтобы понять, что ты реально делал руками.

Цель этапа: отсеять токсиков и кто не может связать 2-ух слов и первично опознать в тебе потенциального вкатуна, а также понять, тратить ли драгоценное время и деньги компании на последующие этапы

2️⃣ Алгоритмическая секция(опционально) - здесь обычно дают пару задачек на алгоритмы и структуры данных: массивы/слайсы, строки, мапы, стеки/очереди, деревья/графы, сортировки, бинарный поиск, два указателя, sliding и вот это все. Решается через LLM либо через натаскивание себя на leetcode.com. Обычно таким страдают бигтехи, тк не придумали еще варианта как можно отсеять "неподготовившихся"

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

3️⃣ Livecoding - в бигтехах это отдельный этап, но во многих low-medium tier это последующий этап hr скрининга.

Из названия очевидно, что здесь ты будешь писать код/решать задачки.

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

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

4️⃣ System design - обычно дают на сеньора и этап необязательный, но последнее время стали часто давать.

Это про этап порисовать схемы в miro.com или в excalidraw.com. Будешь выяснять требования по проектированию системы, покажешь как ты проектирешь систему, как сделаешь взаимодействие между микросервисами, расскжаешь про очереди, масштабированию, observability и тд. От тебя не ждут идеальную архитектуру, которую завтра же нужно будет зарелизить

Цель этапа: понять что ты зрелый инженер и можешь спроектировать систему им видеть с учетом текущих ограничений что можно реализовать

5️⃣ Soft skills aka финалка - финальный босс, когда все технически этапы закончены и тебе нужно показать насколько ты "командный игрок". Показывай как ты общаешься, принимаешь фидбек, умеешь отстаивать свою позицию, объясняешь сложное простым, признаёшь “не знаю”, но предлагаешь план, как разобраться.

Часто спрашивают про конфликты, фейлы, дедлайны, работу с неопределённостью, взаимодействие с продуктом/дизайном/QA, инициативность и ответственность - потому что сильный Go-разработчик в команде почти всегда влияет на качество процессов и технических решений, а не просто “пишет код”.

Цель этапа: не допустить человека в команду с отличающимися взглядами от видения руководителя/команды


Как видишь, все не так страшно, если понимать что хотят на каждом этапе ;)

Профдеформация программиста: 12 симптомов, которые я у себя заметил спустя столь долгого бытия в IT (Ч1)

Дисклеймер: Сказаное, личный опыт 😅

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


1) Трудоголизм и невозможность “отпустить ситуацию”

Самая вишенка на торте. Каждый раз, когда я уезжаю в отпуск(неважно куда), то в голове крутится одна и также шарманка по рабочим сценариям. За все свое время в IT привык, что нужно что-то делать и ты тупо не можешь успокоиться, не потому что горит, а потому что так привык.Внутри сидит ощущение, что если я отвлекусь, то что-то обязательно пойдёт не так - и проще оставаться включённым, чем реально отдыхать.

2) English words in речь - Какой fabrics, какой details?

В какой-то момент замечаешь, что вставляешь английские слова даже там, где можно спокойно сказать по-русски. “Созвон”, “апрув”, “фича”, “дедлайн”, “перфоманс”, “контекст” - и это уже не стиль, а привычка. Иногда это ускоряет, но иногда выглядит так, будто ты всё ещё в рабочем чате, даже когда говоришь с друзьями. А с поколением по-старше приходится пытаться перефразировать слова

3) Синдром самозванца: неприятие себя, если ты не знаешь всё

Есть ощущение, что “нормальный разработчик” обязан знать ответы на любые вопросы. И если ты чего-то не знаешь - это не “окей, разберусь”, а “я недостаточно хорош”. Хотя по факту в разработке постоянно сталкиваешься с тем, чего раньше не видел - просто мозг это воспринимает как угрозу статусу.

- "Ты что не знаешь"?
- "Ты че не сеньор?"

4) Алгоритмическое мышление в жизни: if/then/else

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

В итоге трачу кучу энергии на построение “идеального сценария”, хотя реальность часто требует не расчёта, а гибкости и принятия неопределённости.

Особенно, когда слова по типу - "Roadmap", "Планирование", "OKR", "KPI" тебя окружают 24/7. В этой системе и парадигме начинаешь жить.


5) Любовь к гайдам : “дайте доку”

Первое, что просит разработчик перед реализацией действия - это документация или спека. Обязательно надо найти документацию, “правильный путь”, best practices. Это помогает не изобретать велосипед, но иногда превращается в ловушку: вместо действия - вечное чтение, поиск “самого верного решения”, откладывание старта.


6) Страх быть плохо оценённым: режим performance review

Недавно услышал фразу на работе:

"Некоторые люди спать спокойно не могут, потому что бояться итогов Performace Review"

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

Даже когда никто тебя не оценивает, внутри как будто всегда идёт ревью. Сидит этот жук в голове, который не отпускает.


Резюмируя:

Описал только часть профдеформаций программиста, пережитые на личном опыте :)

Ставь 🔥- если ждешь 2-ую часть

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

Не прошёл собес? Пойду на джуна - худшее, что ты можешь сделать

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

Этот пост родился именно из таких наблюдений: не потому что “джун - плохо”, а потому что "откат" часто становится эмоциональной заменой работе над ошибками. В сам такое попадал, потому что ведь хочется устроиться уже хоть как-то. 🙈. Но давай разберем по порядку, что происходит.

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

“может тогда на джуна?”

И чаще всего это не стратегия, а попытка сказать себе:

“я всё попробовал, не идёт - значит надо просто понизить планку требований”.

Но рынок не устроен как лестница “не прошёл туда - держи ступеньку ниже”.

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

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

Ты отваливаешься на скрининге?
На лайвкодинге?
На самопрезентации?
На вопросах по базе?

Пока ты не отрефлексировал и не разложил свои собеседования по этапам, решение “пойду на джуна” - это реакция на эмоциях.

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

Вывод простой: тебе не нужен "откат на джуна", тебе нужна диагностика своей воронки и честная работа над ошибками. Как только ты начинаешь анализировать собеседования и точечно чинить то, что ломается на конкретном этапе, уровень перестаёт быть драмой - он становится просто выбором, а не побегом.