Привет.
Меня зовут Сунгат.
Я родом из Павлодара. Бедная семья, маленький город, много вопросов к жизни и никаких гарантий.
С детства понял простую вещь: если хочешь чего-то, то никто не придет и не сделает это за тебя.
Поэтому работал, учился, развивался.
Смешно, но до сих пор живу так же.
Сейчас я в Алматы.
Технический директор, системный архитектор, человек, который может сам поднять сервис от инфраструктуры до бизнеса.
Но это не “успех”.
Это просто результат дисциплины, ошибок и постоянного движения вперед.
Я “человеком-энциклопедия”. Читаю, изучаю, анализирую от истории и географии до AI, экономики и архитектуры систем.
Мне интересно все, что даёт силу и понимание мира.
В этом канале я буду писать по-человечески:
• мысли о жизни и развитии
• инженерный взгляд на мир и работу
• истории из опыта, которые формируют характер
• вещи, которые помогают стать сильнее
Если ты не боишься расти и видеть реальность без фильтров, то оставайся.
Добро пожаловать!
Меня зовут Сунгат.
Я родом из Павлодара. Бедная семья, маленький город, много вопросов к жизни и никаких гарантий.
С детства понял простую вещь: если хочешь чего-то, то никто не придет и не сделает это за тебя.
Поэтому работал, учился, развивался.
Смешно, но до сих пор живу так же.
Сейчас я в Алматы.
Технический директор, системный архитектор, человек, который может сам поднять сервис от инфраструктуры до бизнеса.
Но это не “успех”.
Это просто результат дисциплины, ошибок и постоянного движения вперед.
Я “человеком-энциклопедия”. Читаю, изучаю, анализирую от истории и географии до AI, экономики и архитектуры систем.
Мне интересно все, что даёт силу и понимание мира.
В этом канале я буду писать по-человечески:
• мысли о жизни и развитии
• инженерный взгляд на мир и работу
• истории из опыта, которые формируют характер
• вещи, которые помогают стать сильнее
Если ты не боишься расти и видеть реальность без фильтров, то оставайся.
Добро пожаловать!
👍11❤2
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
А у вас какой самый абсурдный опыт собеседований был?
Последние несколько лет наблюдаю одну и ту же картину: компании средней руки пытаются изображать из себя 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
А у вас какой самый абсурдный опыт собеседований был?
Сунгат Арынов
Проблемы IT-собеседований: как не терять кандидатов (2025)
Узнайте, как избежать потерь времени и кандидатов на IT-собеседованиях! Эффективные методы найма помогут вам создать сильную команду. Читайте →
🔥4
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
Типичная история: стартап из пяти человек решает «сделать правильно с самого начала». Разворачивают 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
❤1
Питер Левелс: $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
Один чувак без инвесторов, без команды, на «устаревшем» стеке делает то, о чём мечтают стартапы с миллионными раундами.
Его стек (бомба!):
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
❤1
Микросервисы убивают стартапы
Каждый второй стартап начинает с микросервисов. Потому что "так делают 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
Каждый второй стартап начинает с микросервисов. Потому что "так делают 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
Сунгат Арынов
Микросервисы убивают стартапы: почему монолит лучше (2025)
Узнайте, почему монолит — лучший выбор для стартапов в 2025 году. Разберем реальные кейсы и критерии, когда дробить систему. Читайте →
❤2
🧨 Анти-паттерны, которые убивают стартапы изнутри
Команда сожгла $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️⃣ Упрямый техлид
Когда лидер глух к рынку, метрикам и команде, стартап теряет гибкость.
Лучшие техлиды меняют мнение, когда факты говорят обратное, а не продавливают своё решение ценой продукта.
❌ Краткий чеклист провала:
– старт с микросервисов и тяжёлой инфраструктуры без юзеров
– выбор стека по хайпу, а не по задачам
– абстракции «на будущее», которое никогда не наступит
– изобретение велосипеда там, где есть готовые решения
– полировка архитектуры вместо проверки гипотез
– игнор обратной связи от юзеров и команды
✨ Итог
Простота, скорость и честное внимание к проблеме клиента выигрывают у архитектурного перфекционизма.
Пользователю всё равно, на чём вы построили сервис. Его волнует только одно: решает ли ваш продукт его боль.
Не стройте космический корабль там, где сейчас нужен самокат 🚀
Команда сожгла $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️⃣ Упрямый техлид
Когда лидер глух к рынку, метрикам и команде, стартап теряет гибкость.
Лучшие техлиды меняют мнение, когда факты говорят обратное, а не продавливают своё решение ценой продукта.
❌ Краткий чеклист провала:
– старт с микросервисов и тяжёлой инфраструктуры без юзеров
– выбор стека по хайпу, а не по задачам
– абстракции «на будущее», которое никогда не наступит
– изобретение велосипеда там, где есть готовые решения
– полировка архитектуры вместо проверки гипотез
– игнор обратной связи от юзеров и команды
✨ Итог
Простота, скорость и честное внимание к проблеме клиента выигрывают у архитектурного перфекционизма.
Пользователю всё равно, на чём вы построили сервис. Его волнует только одно: решает ли ваш продукт его боль.
Не стройте космический корабль там, где сейчас нужен самокат 🚀
❤1
Почему «сеньор в своём деле» тонет, а универсал вытягивает стартап
Классический сценарий:
Сеньор-инженер 10+ лет в своей технологии запускает стартап и через год понимает, что его deep-скилл почти ничего не решает. Потому что:
он не умеет продавать, нанимать, говорить с клиентами и инвесторами.
Маркетолог попадает в ту же ловушку:
умеет лить трафик, но не может объяснить разработчикам, что именно строить и зачем.
Оба продолжают думать как специалисты, а не как фаундеры. И стартап стоит на месте.
Сэм Альтман это формулирует жёстко:
Лучшие фаундеры это универсалы от начала и до конца!
В реальности фаундер на ранней стадии выглядит так:
- утром – продукт/инженер,
- днём – продажник и интервьюер клиентов,
- вечером – финансовый директор, который считает runway и юнит-экономику,
- параллельно – HR, маркетинг и саппорт.
И вот почему универсалы выигрывают:
- видят весь бизнес, а не только свой кусок кода или воронки;
- быстро вникают в новые области (от AI до юристов и налогов);
- умеют делать пивоты, не влюбляясь в исходную идею;
- экономят ресурс – вместо 10 узких спецов у тебя 2–3 человека, которые тянут всё.
Золотая модель здесь T-shaped фаундер:
одна–две области, где ты реально глубоко в теме,
и широкая «полка» навыков вокруг, чтобы не только сделать продукт, но и построить компанию.
Если ты хочешь быть фаундером, а не вечно «старшим специалистом» в чужом проекте, то придётся выйти за пределы своей роли и научиться собирать всё воедино.
В длинной статье я разобрал:
- почему универсалы особенно сильны на ранних стадиях;
- как меняется их роль по мере роста компании;
- где универсальность превращается в ловушку;
- как прокачать в себе этот режим, не потеряв глубину.
Полный разбор здесь 👉 ссылка
А ты сейчас кто: узкий спец, универсал или T-shaped в процессе прокачки? 🤔
Классический сценарий:
Сеньор-инженер 10+ лет в своей технологии запускает стартап и через год понимает, что его deep-скилл почти ничего не решает. Потому что:
он не умеет продавать, нанимать, говорить с клиентами и инвесторами.
Маркетолог попадает в ту же ловушку:
умеет лить трафик, но не может объяснить разработчикам, что именно строить и зачем.
Оба продолжают думать как специалисты, а не как фаундеры. И стартап стоит на месте.
Сэм Альтман это формулирует жёстко:
Лучшие фаундеры это универсалы от начала и до конца!
В реальности фаундер на ранней стадии выглядит так:
- утром – продукт/инженер,
- днём – продажник и интервьюер клиентов,
- вечером – финансовый директор, который считает runway и юнит-экономику,
- параллельно – HR, маркетинг и саппорт.
И вот почему универсалы выигрывают:
- видят весь бизнес, а не только свой кусок кода или воронки;
- быстро вникают в новые области (от AI до юристов и налогов);
- умеют делать пивоты, не влюбляясь в исходную идею;
- экономят ресурс – вместо 10 узких спецов у тебя 2–3 человека, которые тянут всё.
Золотая модель здесь T-shaped фаундер:
одна–две области, где ты реально глубоко в теме,
и широкая «полка» навыков вокруг, чтобы не только сделать продукт, но и построить компанию.
Если ты хочешь быть фаундером, а не вечно «старшим специалистом» в чужом проекте, то придётся выйти за пределы своей роли и научиться собирать всё воедино.
В длинной статье я разобрал:
- почему универсалы особенно сильны на ранних стадиях;
- как меняется их роль по мере роста компании;
- где универсальность превращается в ловушку;
- как прокачать в себе этот режим, не потеряв глубину.
Полный разбор здесь 👉 ссылка
А ты сейчас кто: узкий спец, универсал или T-shaped в процессе прокачки? 🤔
Сунгат Арынов
Мастер на все руки: Как победить узких специалистов (2025)
Узнайте, почему универсалы выигрывают в стартапах! Разберем секреты успеха и как стать многофункциональным основателем. Читайте сейчас!
❤1
«Он же senior, он лучше знает»
Каждый раз, когда слышу эту фразу - жду провала.
И обычно дожидаюсь.
Реальный кейс: технический директор из «колёс» два года не мог довести продукт до MVP.
Уважаемый, авторитетный. Его ум никто не оспаривал (кроме меня).
Я переписал и поднял всё за три недели. Без пафоса и теоретических баталий.
Проблема не в сеньорах. Проблема в том, что мы верим в титулы больше, чем в результат.
Настоящий эксперт объясняет сложное просто и признаёт границы знаний.
Пустышка прячется за жаргоном и боится «потерять лицо».
Разобрал тему в статье. Почему авторитет не равен экспертизе и как это исправить 👇
https://ginkida.dev/ru/posts/avtoritet-vs-rezultat-pocemu-gromkii-titul-ne-garantiruet
Каждый раз, когда слышу эту фразу - жду провала.
И обычно дожидаюсь.
Реальный кейс: технический директор из «колёс» два года не мог довести продукт до MVP.
Уважаемый, авторитетный. Его ум никто не оспаривал (кроме меня).
Я переписал и поднял всё за три недели. Без пафоса и теоретических баталий.
Проблема не в сеньорах. Проблема в том, что мы верим в титулы больше, чем в результат.
Настоящий эксперт объясняет сложное просто и признаёт границы знаний.
Пустышка прячется за жаргоном и боится «потерять лицо».
Разобрал тему в статье. Почему авторитет не равен экспертизе и как это исправить 👇
https://ginkida.dev/ru/posts/avtoritet-vs-rezultat-pocemu-gromkii-titul-ne-garantiruet
Сунгат Арынов
Авторитет vs результат: как избежать когнитивных ловушек
Узнайте, как отличить реального эксперта от пустышки с громким титулом. Читайте о том, почему авторитет не всегда гарантирует успех! Читайте →
❤1
По образованию я географ. Код не писал вообще.
Сейчас уже разработчик, свои проекты, карьера в IT. Всё через самообучение: ошибки, откаты, снова попытки.
Но это только часть истории 👇
Самостоятельно разобрался с ремонтом машин. Починил свою тачку, от которой отказались все сервисы в городе. Просто сел, изучил, сделал.
Освоил вокал. Путь был тот ещё, но результат есть.
Откуда это всё?
Одна привычка после школы: каждый день узнавать что-то новое. Не "стараюсь", а просто живу так уже много лет.
Принцип простой: мне нравится учиться. У людей, по книгам, руками - без разницы.
Недавно глубоко копнул тему, как вообще работает самообучение у взрослых. Нейробиология, психология, методы.
И обнаружил интересное:
- Мозг пластичен всю жизнь, "затвердевание после 25" — миф
- Циолковский за 3 года в библиотеке освоил университетскую программу
- Маск выучил ракетостроение по книгам
- Элла Фицджеральд никогда не брала уроков вокала
Возраст не барьер. Отсутствие диплома не барьер.
Барьер это мысль "мне уже поздно".
Собрал всё в статью - наука, методы, истории, антипаттерны. Если резонирует, то читай!
Сейчас уже разработчик, свои проекты, карьера в IT. Всё через самообучение: ошибки, откаты, снова попытки.
Но это только часть истории 👇
Самостоятельно разобрался с ремонтом машин. Починил свою тачку, от которой отказались все сервисы в городе. Просто сел, изучил, сделал.
Освоил вокал. Путь был тот ещё, но результат есть.
Откуда это всё?
Одна привычка после школы: каждый день узнавать что-то новое. Не "стараюсь", а просто живу так уже много лет.
Принцип простой: мне нравится учиться. У людей, по книгам, руками - без разницы.
Недавно глубоко копнул тему, как вообще работает самообучение у взрослых. Нейробиология, психология, методы.
И обнаружил интересное:
- Мозг пластичен всю жизнь, "затвердевание после 25" — миф
- Циолковский за 3 года в библиотеке освоил университетскую программу
- Маск выучил ракетостроение по книгам
- Элла Фицджеральд никогда не брала уроков вокала
Возраст не барьер. Отсутствие диплома не барьер.
Барьер это мысль "мне уже поздно".
Собрал всё в статью - наука, методы, истории, антипаттерны. Если резонирует, то читай!
Сунгат Арынов
Самоучки: Как взрослые осваивают навыки быстрее (2025)
Узнайте, как взрослые самоучки осваивают сложные навыки быстрее профессионалов! Откройте для себя методы, которые изменят ваше обучение. Читайте →
❤1
Программисты которые говорят «ИИ это хайп» напоминают таксистов которые смеялись над Uber в 2015.
Каждый раз когда заговариваю с коллегами про вайбкодинг:
— Это хайп, через год забудут
— ИИ пишет говнокод
— Настоящие программисты так не работают
— Пузырь скоро лопнет
Я никогда так не думал. С первого ChatGPT взял инструмент в работу.
Сейчас ИИ - часть ежедневного стека.
Рутина ушла на него: тесты, формы, шаблонный код, рефакторинг по 20 файлам.
Я занимаюсь архитектурой и ревью - тем, что требует мозгов.
«Но ИИ ошибается!»
Джуниоры тоже. Только джуниору платишь зарплату и объясняешь 10 раз. Модель адаптируется на лету и стоит $20 в месяц.
Пессимизм понимаю. Страшно признать что часть твоих навыков автоматизируется. Но игнорировать реальность - не стратегия.
Половина кода в мире уже пишется с помощью ИИ. Это статистика 2025 года.
Через 3 года «опыт с AI-ассистентами» будет в каждой вакансии.
Вопрос - ты среди первых или догоняющих?
Написал большой разбор: инструменты, практики, грабли, что реально работает 👇
https://ginkida.dev/ru/posts/kak-ia-perestal-pisat-kod-i-nacal-im-upravliat
Каждый раз когда заговариваю с коллегами про вайбкодинг:
— Это хайп, через год забудут
— ИИ пишет говнокод
— Настоящие программисты так не работают
— Пузырь скоро лопнет
Я никогда так не думал. С первого ChatGPT взял инструмент в работу.
Сейчас ИИ - часть ежедневного стека.
Рутина ушла на него: тесты, формы, шаблонный код, рефакторинг по 20 файлам.
Я занимаюсь архитектурой и ревью - тем, что требует мозгов.
«Но ИИ ошибается!»
Джуниоры тоже. Только джуниору платишь зарплату и объясняешь 10 раз. Модель адаптируется на лету и стоит $20 в месяц.
Пессимизм понимаю. Страшно признать что часть твоих навыков автоматизируется. Но игнорировать реальность - не стратегия.
Половина кода в мире уже пишется с помощью ИИ. Это статистика 2025 года.
Через 3 года «опыт с AI-ассистентами» будет в каждой вакансии.
Вопрос - ты среди первых или догоняющих?
Написал большой разбор: инструменты, практики, грабли, что реально работает 👇
https://ginkida.dev/ru/posts/kak-ia-perestal-pisat-kod-i-nacal-im-upravliat
Сунгат Арынов
Как я управляю кодом с ИИ: Вайбкодинг в 2025
Узнайте, как управлять кодом с помощью ИИ и повысить продуктивность. Откройте для себя эффективные инструменты для современного программирования! Читайте →
❤1
Недавно меня чуть не развели на паспорт 🎭
Схема красивая: европейская компания, нашли на джоб-борде, написали в личке, созвонились.
Один созвон - и "You're hired, welcome aboard!"
Я такой: круто, что дальше?
Они: пришлите скан паспорта и proof of address на почту, потом дадим контракт.
Я: э, а можно сначала контракт?
Они: нет, так не работает, сначала документы.
Я проверил компанию:
- Домен свежий
- Отзывов ноль
- Сотрудников не найти
- Админка публично открыта
Написал, что не готов отправлять паспорт без договора.
В ответ прилетело: "How do you expect anyone to hire an unknown and undocumented person?"
Ну я и послал. Но не паспорт 😅
А теперь серьёзно. Паспорт + proof of address - это всё что нужно для:
→ Кредитов на ваше имя
→ Регистрации фирм-однодневок
→ Дубликата сим-карты
→ Криминальных схем
Написал большую статью о том, как распознать мошенников при найме и что делать если уже отправили документы.
🔗 https://ginkida.dev/ru/posts/pocemu-ia-poslal-rabotodatelia-kogda-on-poprosil-pasport
Сталкивались с таким?
Схема красивая: европейская компания, нашли на джоб-борде, написали в личке, созвонились.
Один созвон - и "You're hired, welcome aboard!"
Я такой: круто, что дальше?
Они: пришлите скан паспорта и proof of address на почту, потом дадим контракт.
Я: э, а можно сначала контракт?
Они: нет, так не работает, сначала документы.
Я проверил компанию:
- Домен свежий
- Отзывов ноль
- Сотрудников не найти
- Админка публично открыта
Написал, что не готов отправлять паспорт без договора.
В ответ прилетело: "How do you expect anyone to hire an unknown and undocumented person?"
Ну я и послал. Но не паспорт 😅
А теперь серьёзно. Паспорт + proof of address - это всё что нужно для:
→ Кредитов на ваше имя
→ Регистрации фирм-однодневок
→ Дубликата сим-карты
→ Криминальных схем
Написал большую статью о том, как распознать мошенников при найме и что делать если уже отправили документы.
🔗 https://ginkida.dev/ru/posts/pocemu-ia-poslal-rabotodatelia-kogda-on-poprosil-pasport
Сталкивались с таким?
Сунгат Арынов
Почему я послал работодателя: красный флаг 2025
Узнайте, почему просьба о паспорте до контракта — это красный флаг! Защитите свои данные и проверьте работодателя. Читайте наш опыт!
Почему токсики в IT получают повышение, а нормальные люди уходят
Недавно в Threads один программист пытался убедить меня, что коллеги - не причина выгорания в IT.
Мол, проблема не в среде.
Розовые очки крепко сидят 😅
Вот только статистика:
→ 37% уходят из tech из-за несправедливого обращения
→ 78% испытывали токсичное поведение на себе
→ 85% наблюдали его у коллег
→ 1 из 10 женщин - нежелательное внимание на работе
Это не "единичные случаи чувствительных людей". Это система.
Как это работает?
Индустрия не любит токсиков на словах. Но вознаграждает условия, где токсичность = выигрышная стратегия:
- Давишь сроками вместо прояснения → ты "эффективный"
- Тащишь пожары вместо системы → ты "герой"
- Унижаешь на код-ревью → "поддерживаешь стандарты"
- А кто задаёт вопросы и не играет в доминирование - "не тянет".
Дальше естественный отбор. Кто адаптировался - растёт.
Кто нет - уходит.
Личное наблюдение
После многих лет в индустрии понял одну вещь: иногда с AI работать комфортнее, чем с некоторыми начальниками 🤷
- AI не самоутверждается за твой счёт.
- Не закатывает глаза на вопросы.
- Не саботирует идеи, потому что не он их предложил.
Это не комплимент технологиям. Это диагноз культуре.
Хорошая новость
Токсичность - управляемый риск, а не "характер отрасли".
Google это доказал: psychological safety - главный фактор эффективности команд.
Вопрос не в том, можно ли изменить.
Вопрос - готовы ли мы.
Полная статья в блоге:
https://ginkida.dev/ru/posts/pocemu-toksiki-v-it-polucaiut-povysenie-a-normalnye-liudi
Недавно в Threads один программист пытался убедить меня, что коллеги - не причина выгорания в IT.
Мол, проблема не в среде.
Розовые очки крепко сидят 😅
Вот только статистика:
→ 37% уходят из tech из-за несправедливого обращения
→ 78% испытывали токсичное поведение на себе
→ 85% наблюдали его у коллег
→ 1 из 10 женщин - нежелательное внимание на работе
Это не "единичные случаи чувствительных людей". Это система.
Как это работает?
Индустрия не любит токсиков на словах. Но вознаграждает условия, где токсичность = выигрышная стратегия:
- Давишь сроками вместо прояснения → ты "эффективный"
- Тащишь пожары вместо системы → ты "герой"
- Унижаешь на код-ревью → "поддерживаешь стандарты"
- А кто задаёт вопросы и не играет в доминирование - "не тянет".
Дальше естественный отбор. Кто адаптировался - растёт.
Кто нет - уходит.
Личное наблюдение
После многих лет в индустрии понял одну вещь: иногда с AI работать комфортнее, чем с некоторыми начальниками 🤷
- AI не самоутверждается за твой счёт.
- Не закатывает глаза на вопросы.
- Не саботирует идеи, потому что не он их предложил.
Это не комплимент технологиям. Это диагноз культуре.
Хорошая новость
Токсичность - управляемый риск, а не "характер отрасли".
Google это доказал: psychological safety - главный фактор эффективности команд.
Вопрос не в том, можно ли изменить.
Вопрос - готовы ли мы.
Полная статья в блоге:
https://ginkida.dev/ru/posts/pocemu-toksiki-v-it-polucaiut-povysenie-a-normalnye-liudi
Сунгат Арынов
Токсичность в IT: Почему уходит нормальный персонал?
Узнайте, почему токсики в IT поднимаются по карьерной лестнице, а нормальные люди уходят. Погрузитесь в проблемы культуры и выгорания! Читайте →
🔬 Анатомия AI-видео хайпа: разбираю метрики Higgsfield
$50M Series A, 11 млн пользователей за 5 месяцев, министр говорит о конкуренции с OpenAI. Красиво звучит. Но давайте считать.
Что не сходится:
📊 ARPU ~$4.5 в год на пользователя. У Netflix — $140, у Spotify — $55. Либо массово не платят, либо сидят на минимальных тарифах.
🔧 Нет собственных моделей. Veo — Google, Kling — Kuaishou, Sora — OpenAI. Higgsfield — красивая обёртка над чужими API. Маржа тонкая, зависимость полная.
💰 Цены в 2-3 раза выше Runway и Kling. При тех же моделях под капотом — за что премия?
🏢 Ноль публичных enterprise-кейсов за 5 месяцев. Runway показывает Lionsgate и A24, Synthesia — BBC и Xerox. У Higgsfield — тишина.
Это не приговор. Команда сильная, рынок растёт, $50M хватит на 2-3 года экспериментов. Но 75% венчурных компаний не возвращают деньги инвесторам, и AI-видео — один из самых жёстких секторов для этой статистики.
Полный разбор со сценариями развития: https://ginkida.dev/ru/posts/anatomiia-ai-video-xaipa-cto-skryvaetsia-za-metrikami
$50M Series A, 11 млн пользователей за 5 месяцев, министр говорит о конкуренции с OpenAI. Красиво звучит. Но давайте считать.
Что не сходится:
📊 ARPU ~$4.5 в год на пользователя. У Netflix — $140, у Spotify — $55. Либо массово не платят, либо сидят на минимальных тарифах.
🔧 Нет собственных моделей. Veo — Google, Kling — Kuaishou, Sora — OpenAI. Higgsfield — красивая обёртка над чужими API. Маржа тонкая, зависимость полная.
💰 Цены в 2-3 раза выше Runway и Kling. При тех же моделях под капотом — за что премия?
🏢 Ноль публичных enterprise-кейсов за 5 месяцев. Runway показывает Lionsgate и A24, Synthesia — BBC и Xerox. У Higgsfield — тишина.
Это не приговор. Команда сильная, рынок растёт, $50M хватит на 2-3 года экспериментов. Но 75% венчурных компаний не возвращают деньги инвесторам, и AI-видео — один из самых жёстких секторов для этой статистики.
Полный разбор со сценариями развития: https://ginkida.dev/ru/posts/anatomiia-ai-video-xaipa-cto-skryvaetsia-za-metrikami
Сунгат Арынов
AI-видео хайп: анализ метрик Higgsfield (2025)
Разберитесь в AI-видео хайпе стартапа Higgsfield! Узнайте о рисках и возможностях, скрывающихся за впечатляющими метриками. Читайте →