Привет.
Меня зовут Сунгат.

Я родом из Павлодара. Бедная семья, маленький город, много вопросов к жизни и никаких гарантий.

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

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

Но это не “успех”.
Это просто результат дисциплины, ошибок и постоянного движения вперед.

Я “человеком-энциклопедия”. Читаю, изучаю, анализирую от истории и географии до AI, экономики и архитектуры систем.
Мне интересно все, что даёт силу и понимание мира.

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

Если ты не боишься расти и видеть реальность без фильтров, то оставайся.

Добро пожаловать!

IT-собеседования превратились в театр абсурда 🎪

Последние несколько лет наблюдаю одну и ту же картину: компании средней руки пытаются изображать из себя Google. Шесть этапов интервью, алгоритмические задачки, live-coding под прицелом пяти человек и всё это ради позиции, где человек будет клепать формы и дёргать API.

Недавно наткнулся на исследование Microsoft, которое подтвердило то, что разработчики знали интуитивно 👇

Live-coding снижает результаты кандидатов на 50%. Не потому что люди глупые или не знают материал. А потому что стресс. Когда трое незнакомцев смотрят на каждый твой символ и ждут идеального решения за 20 минут, то мозг переключается в режим выживания. Мы проверяем не умение кодить, а умение выступать на сцене.

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

Отдельная боль это теоретические вопросы 🧠

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

Откуда это взялось? Компании тупо копируют процессы FAANG без понимания контекста. «Ребята знают, что делают» - думают они. Но то, что работает для Google с потоком в тысячи кандидатов в день, не имеет смысла для стартапа в 30 человек.

Когда я сам начал нанимать, то делал всё наоборот 🔄

Перед встречей изучал резюме, LinkedIn, GitHub. Если у человека есть публичные проекты, то зачем давать тестовое? Лучше обсудить его реальный код: почему принял такие решения, с чем столкнулся, что бы сделал иначе.

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

Никаких алгоритмов, если они не нужны в работе. Никакого live-coding под стрессом. Никаких шести этапов.

Результат? Сильные люди в команде. Закрытые вакансии за дни, а не месяцы. Люди, которые работали годами, а не сбегали через испытательный срок.

Собрал весь опыт в большую статью 📝

Разобрал главные проблемы найма, привёл исследования и цифры, описал антипаттерны и альтернативный подход. Если устал от собеседований-марафонов с любой стороны стола, то будет полезно.

👉 https://ginkida.dev/ru/posts/problemy-it-sobesedovanii-kak-perestat-teriat-kandidatov-i

А у вас какой самый абсурдный опыт собеседований был?

Kubernetes это дорогая игрушка 🚛

Типичная история: стартап из пяти человек решает «сделать правильно с самого начала». Разворачивают K8s, три месяца пилят инфраструктуру, нанимают девопса.

А потом выясняется, что их три сервиса отлично жили бы на Docker Compose.

Что не говорят на конференциях:
- Средний кластер загружен на 30-50%, остальное простаивает
- Для прода нужны ещё CI/CD, Prometheus, Grafana, ELK, Ingress — и каждый настраивай отдельно
- Автоскейлер без лимитов раздует счёт так, что финдир прибежит.

Docker Swarm закрывает 80% задач. Одна команда, тот же Docker CLI, встроенный балансировщик.

Arbuz.kz начинали на Swarm - K8s взяли только когда реально выросли.

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

Разобрал подробно: когда K8s оправдан, когда нет, как выбирать → https://ginkida.dev/ru/posts/kubernetes-eto-dorogaia-igruska-pocemu-vasemu-startapu

Питер Левелс: $3M/год на PHP и jQuery 🚀
Один чувак без инвесторов, без команды, на «устаревшем» стеке делает то, о чём мечтают стартапы с миллионными раундами.

Его стек (бомба!):
PHP (старых версий!)
SQLite (один файл = вся база)
jQuery + vanilla JS
Дешёвый VPS + Cloudflare

Его философия:
Запустил MVP для Photo AI - просто HTML-страница + Stripe. Бэкенда нет. Вручную скачивал фотки и прогонял через модель.

1000 оплат за 24 часа → только тогда начал писать код.

Nomad List начался как Google-таблица. Когда она доказала спрос — превратил в сайт.

Результат (2022):
Remote OK: ~$1.6M/год
Nomad List: ~$900K/год
70-90% — чистая прибыль

Главные принципы:
Сначала спрос - потом код
Делай то, что не масштабируется
Простые технологии > модные фреймворки
Build in Public - прозрачность = доверие

Пока все гонятся за React/Next.js/микросервисами - Левелс доказывает, что сложность ≠ успех.

Подробнее:
https://ginkida.dev/ru/posts/piter-levels-milliony-na-ustarevsem-php-pocemu-odin

Микросервисы убивают стартапы
Каждый второй стартап начинает с микросервисов. Потому что "так делают Netflix". Потому что монолит это "устаревшее legacy".

Только Netflix перешёл на микросервисы когда у них появились сотни инженеров и миллионы пользователей. А вы пытаетесь повторить это с командой из 5 человек.

Что получается на практике:
Команда разбила PHP-монолит на микросервисы. Штат вырос в 4 раза, скорость фич упала на 40%. Четыре человека стали работать медленнее шестнадцати.

А вот как бывает с монолитом:
Ghost Explore на Laravel - один разработчик, сервер с 1 GB памяти, 14 миллионов запросов в месяц. Без Kubernetes и армии DevOps.

Cookpad на Rails - 50 млн пользователей, 15К запросов в секунду. Монолит.

GitLab, Amazon, Netflix - все начинали с монолитов.

Когда микросервисы реально нужны:
→ После 100+ инженеров
→ Независимые команды с разделёнными зонами
→ Стабильные доменные границы
→ Явная потребность масштабировать части системы по-разному

До этого момента микросервисы создают больше проблем: каждый сервис требует своего мониторинга, CI/CD, логирования. Сеть добавляет латентность. Дебаг превращается в детектив.

Что делать вместо этого:
Модульный монолит. Изоляция кода без сетевых вызовов и распределённых транзакций. Когда модуль упрётся в потолок, то вынесете. Границы уже готовы.

90% стартапов не доживают до масштаба, где микросервисы нужны. Инвестируйте в продукт, а не в инфраструктуру ради резюме.

Подробнее с примерами и антипаттернами в статье 👇
https://ginkida.dev/ru/posts/mikroservisy-ubivaiut-startapy-pocemu-monolit-eto-lucsii

🧨 Анти-паттерны, которые убивают стартапы изнутри

Команда сожгла $200k и полгода на «масштабируемую архитектуру» из 7 микросервисов, 5 БД и 3 очередей. Количество платящих клиентов на запуске: 0.
Это не редкий случай. Это системная ошибка.

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

Вот самые токсичные из них 👇

1️⃣ Преждевременные микросервисы
Стартовать с микросервисов, Kubernetes и service mesh, когда у тебя нет ни трафика, ни юзеров – это не «профессионализм», а добровольный хардкор.
Монолит одной командой из 3–5 человек разворачивается и меняется быстрее. Сначала нужен product-market fit, а не service mesh.

2️⃣ Overengineering и культ «чистого кода»
Чистая бизнес-логика, размазанная по 5 слоям абстракций и 42 интерфейсам – это не архитектура, а лабиринт.
Если чтобы понять код, нужна диаграмма, вы уже проиграли по скорости. В стартапе порядок такой:
сначала «работает», потом «надёжно», потом (если дожили) «красиво».

3️⃣ Хайповый стек вместо здравого смысла
Выбирают модный фреймворк, который никто в команде не знает. В итоге больше времени уходит на обучение и борьбу с багами, чем на фичи.
Вопросы, которые нужно задавать себе честно:
• решает ли технология мою реальную задачу лучше простых альтернатив?
• есть ли у команды экспертиза?
• не убьёт ли поддержка это решение через год?

4️⃣ Синдром велосипедостроения
«Своё логирование, свой ORM, свой фреймворк, свой всё».
Сообщество годами пилит библиотеки, а вы клепаете сырой аналог между митингами. В итоге баги, отсутствие документации и зависимость от одного автора.
В стартапе главное – не объём написанного кода, а минимальная сложность решения.

5️⃣ Код вместо продукта
Вылизанный до идеала код не спасёт, если:
• никто не понимает, какую боль решает продукт
• гипотезы не валидируются
• обратную связь юзеров игнорируют
Запускать нужно «достаточно хорошо», а не «идеально когда-нибудь». Мир не ждёт ваш идеальный релиз.

6️⃣ Упрямый техлид
Когда лидер глух к рынку, метрикам и команде, стартап теряет гибкость.
Лучшие техлиды меняют мнение, когда факты говорят обратное, а не продавливают своё решение ценой продукта.

❌ Краткий чеклист провала:
– старт с микросервисов и тяжёлой инфраструктуры без юзеров
– выбор стека по хайпу, а не по задачам
– абстракции «на будущее», которое никогда не наступит
– изобретение велосипеда там, где есть готовые решения
– полировка архитектуры вместо проверки гипотез
– игнор обратной связи от юзеров и команды

✨ Итог
Простота, скорость и честное внимание к проблеме клиента выигрывают у архитектурного перфекционизма.
Пользователю всё равно, на чём вы построили сервис. Его волнует только одно: решает ли ваш продукт его боль.

Не стройте космический корабль там, где сейчас нужен самокат 🚀

Почему «сеньор в своём деле» тонет, а универсал вытягивает стартап

Классический сценарий:
Сеньор-инженер 10+ лет в своей технологии запускает стартап и через год понимает, что его deep-скилл почти ничего не решает. Потому что:
он не умеет продавать, нанимать, говорить с клиентами и инвесторами.

Маркетолог попадает в ту же ловушку:
умеет лить трафик, но не может объяснить разработчикам, что именно строить и зачем.

Оба продолжают думать как специалисты, а не как фаундеры. И стартап стоит на месте.

Сэм Альтман это формулирует жёстко:
Лучшие фаундеры это универсалы от начала и до конца!

В реальности фаундер на ранней стадии выглядит так:
- утром – продукт/инженер,
- днём – продажник и интервьюер клиентов,
- вечером – финансовый директор, который считает runway и юнит-экономику,
- параллельно – HR, маркетинг и саппорт.

И вот почему универсалы выигрывают:
- видят весь бизнес, а не только свой кусок кода или воронки;
- быстро вникают в новые области (от AI до юристов и налогов);
- умеют делать пивоты, не влюбляясь в исходную идею;
- экономят ресурс – вместо 10 узких спецов у тебя 2–3 человека, которые тянут всё.

Золотая модель здесь T-shaped фаундер:
одна–две области, где ты реально глубоко в теме,
и широкая «полка» навыков вокруг, чтобы не только сделать продукт, но и построить компанию.

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

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

Полный разбор здесь 👉 ссылка

А ты сейчас кто: узкий спец, универсал или T-shaped в процессе прокачки? 🤔

«Он же senior, он лучше знает»

Каждый раз, когда слышу эту фразу - жду провала.
И обычно дожидаюсь.

Реальный кейс: технический директор из «колёс» два года не мог довести продукт до MVP.

Уважаемый, авторитетный. Его ум никто не оспаривал (кроме меня).

Я переписал и поднял всё за три недели. Без пафоса и теоретических баталий.

Проблема не в сеньорах. Проблема в том, что мы верим в титулы больше, чем в результат.

Настоящий эксперт объясняет сложное просто и признаёт границы знаний.

Пустышка прячется за жаргоном и боится «потерять лицо».

Разобрал тему в статье. Почему авторитет не равен экспертизе и как это исправить 👇
https://ginkida.dev/ru/posts/avtoritet-vs-rezultat-pocemu-gromkii-titul-ne-garantiruet

По образованию я географ. Код не писал вообще.

Сейчас уже разработчик, свои проекты, карьера в IT. Всё через самообучение: ошибки, откаты, снова попытки.

Но это только часть истории 👇

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

Освоил вокал. Путь был тот ещё, но результат есть.
Откуда это всё?

Одна привычка после школы: каждый день узнавать что-то новое. Не "стараюсь", а просто живу так уже много лет.

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

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

И обнаружил интересное:
- Мозг пластичен всю жизнь, "затвердевание после 25" — миф
- Циолковский за 3 года в библиотеке освоил университетскую программу
- Маск выучил ракетостроение по книгам
- Элла Фицджеральд никогда не брала уроков вокала

Возраст не барьер. Отсутствие диплома не барьер.

Барьер это мысль "мне уже поздно".

Собрал всё в статью - наука, методы, истории, антипаттерны. Если резонирует, то читай!

Программисты которые говорят «ИИ это хайп» напоминают таксистов которые смеялись над Uber в 2015.

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

Я никогда так не думал. С первого ChatGPT взял инструмент в работу.

Сейчас ИИ - часть ежедневного стека.

Рутина ушла на него: тесты, формы, шаблонный код, рефакторинг по 20 файлам.

Я занимаюсь архитектурой и ревью - тем, что требует мозгов.

«Но ИИ ошибается!»

Джуниоры тоже. Только джуниору платишь зарплату и объясняешь 10 раз. Модель адаптируется на лету и стоит $20 в месяц.

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

Половина кода в мире уже пишется с помощью ИИ. Это статистика 2025 года.

Через 3 года «опыт с AI-ассистентами» будет в каждой вакансии.

Вопрос - ты среди первых или догоняющих?

Написал большой разбор: инструменты, практики, грабли, что реально работает 👇

https://ginkida.dev/ru/posts/kak-ia-perestal-pisat-kod-i-nacal-im-upravliat