Ищем Unity-разработчика к нам в Bioneers
Всем привет! Наш проект растет, в связи с этим ищем активного и талантливого разработчика к нам в команду
Описание вакансии:
Unity-разработчик (Middle) — Bioneers
Мы делаем Bioneers — игру про живые клетки и биологические системы. Вдохновлялись Factorio и Spore: строишь клеточные организмы, настраиваешь цепочки ресурсов, наблюдаешь как всё работает (или ломается). Это не мобилка и не казуалка — это настоящий PC-проект с глубоким геймплеем.
Мы стартап. Маленькая команда из 6 человек: CTO, 2 программиста, дизайнер, геймдизайнер и маркетинг-менеджер. Платим честно, но не как корпорация. Зато у нас:
— Возможность реально влиять на продукт, а не закрывать тикеты
— Работа с современным стеком (Unity 6, ECS/DOTS, R3, UniTask)
— Менторство и профессиональный рост. Очень сильная команда разработки
— Удалёнка
Что будешь делать:
— Геймплей на DOTS (Unity DOTS): системы, компоненты, аспекты
— UI на MVVM + R3
— Писать чистый, поддерживаемый код в модульной архитектуре
— Участвовать в code review
— Придумывать решения, а не только реализовывать чужие
— Возможность влиять на геймдизайнерские решения
Что нужно:
— Unity + C# (2+ года коммерческого опыта)
— Понимание ECS концепций (или готовность быстро вникнуть)
— Опыт с UI: Canvas, привязка данных, реактивность
— Умение читать чужой код и работать в команде
— Желание учиться — это главное
Будет плюсом:
— Опыт с Unity DOTS
— Знание R3 / UniRx / реактивного программирования
— Опыт с ScriptableObject-based архитектурой
— Git (merge, rebase, code review через PR)
Очень желательно:
— Наигранность в Factorio, Satisfactory, Shapez, Dyson Sphere Program или другие игры в жанре автоматизации. Если ты понимаешь кайф от идеально работающей конвейерной линии — нам по пути.
Условия:
— Полная удалёнка
— Full-time
— Оплата по результатам собеседования (стартап, не корпорация — но растём вместе)
Писать: @romanchikov
Приложите CV к отклику — так мы быстрее ответим
Всем привет! Наш проект растет, в связи с этим ищем активного и талантливого разработчика к нам в команду
Описание вакансии:
Unity-разработчик (Middle) — Bioneers
Мы делаем Bioneers — игру про живые клетки и биологические системы. Вдохновлялись Factorio и Spore: строишь клеточные организмы, настраиваешь цепочки ресурсов, наблюдаешь как всё работает (или ломается). Это не мобилка и не казуалка — это настоящий PC-проект с глубоким геймплеем.
Мы стартап. Маленькая команда из 6 человек: CTO, 2 программиста, дизайнер, геймдизайнер и маркетинг-менеджер. Платим честно, но не как корпорация. Зато у нас:
— Возможность реально влиять на продукт, а не закрывать тикеты
— Работа с современным стеком (Unity 6, ECS/DOTS, R3, UniTask)
— Менторство и профессиональный рост. Очень сильная команда разработки
— Удалёнка
Что будешь делать:
— Геймплей на DOTS (Unity DOTS): системы, компоненты, аспекты
— UI на MVVM + R3
— Писать чистый, поддерживаемый код в модульной архитектуре
— Участвовать в code review
— Придумывать решения, а не только реализовывать чужие
— Возможность влиять на геймдизайнерские решения
Что нужно:
— Unity + C# (2+ года коммерческого опыта)
— Понимание ECS концепций (или готовность быстро вникнуть)
— Опыт с UI: Canvas, привязка данных, реактивность
— Умение читать чужой код и работать в команде
— Желание учиться — это главное
Будет плюсом:
— Опыт с Unity DOTS
— Знание R3 / UniRx / реактивного программирования
— Опыт с ScriptableObject-based архитектурой
— Git (merge, rebase, code review через PR)
Очень желательно:
— Наигранность в Factorio, Satisfactory, Shapez, Dyson Sphere Program или другие игры в жанре автоматизации. Если ты понимаешь кайф от идеально работающей конвейерной линии — нам по пути.
Условия:
— Полная удалёнка
— Full-time
— Оплата по результатам собеседования (стартап, не корпорация — но растём вместе)
Писать: @romanchikov
Приложите CV к отклику — так мы быстрее ответим
👍10🔥1
Почему 80% разработчиков не доходят даже до интервью?
Обратил внимание, что у меня много новых подписчиков после того, как я разместил вакансию к нам в Bioneers, поэтому хотел бы по горячим следам поделиться своими мыслями насчёт процесса интервью.
В отличие от моего основного места работы, где всю подготовительную часть делает HR, а я уже делаю code review и тех интервью, тут я решил провести всё самостоятельно от и до. И скажу честно, это очень ценный опыт, и я стал гораздо лучше понимать ответственность HR.
Процесс интервью:
1. CV
2. Опросник
3. Тестовое задание
4. Интервью
5. Тех интервью
На мою вакансию откликнулось 70 человек, что превзошло мои ожидания в 3 раза. Поэтому, мне пришлось максимально автоматизировать процесс и подключить своего бота OpenClaw для помощи.
Этап CV. 70 человек
На просмотр CV кандидата я тратил менее 1 минуты. Сами понимаете, 70 человек — это уже 70 минут, поэтому правду говорят HR, что без грамотного CV на вас могут просто не обратить внимание. Далее я отдавал CV нейронке для автоматического ревью и создания страницы кандидата. Нейронка ставила скор от 1 до 5 на основе CV. Те кандидаты, что получали менее 2 баллов или у кого не было 2-х лет опыта, сразу получали отказ, остальные проходили на следующий этап.
Также я присылал информацию о проекте и о компании, и часть людей сами отказывались, так как наши условия им не подходили.
Этап опросника. 40 человек
Поскольку откликов было много, я принял решение сделать опросник. В опроснике просил оценить уровень от 1 до 5 по техническим навыкам, а также задавал несколько релевантных для нас вопросов, например, ожидаемый уровень ЗП и наигранность в игры автоматизации.
На основе опросника нейронка генерировала скор от 1 до 5. У кандидатов, которые сами себе поставили менее 3 баллов, спрашивал, точно ли они хотят делать тестовое, так как по их оценке есть шанс не пройти тех интервью.
Удивительно, но у многих кандидатов уровень в опроснике совпал с уровнем, который я поставил при code review.
Этап тестового задания. 30 человек
Тут стоит отметить, что всего 5 человек отказались делать тестовое задание сами, и ещё 5 человек отказались по результатам опросника. Правда, на этапе CV я предупреждал, что тестовое задание обязательно.
Тестовое задание я также прогонял через нейронку, которая формировала черновой отчёт и на основе моих критериев оценивала кандидатов. Далее я самостоятельно проводил ревью тестовых и корректировал отчёт уже на основе своего опыта. По результатам оценил кандидатов от 1 до 5, и те, кто получили 3.5 балла, не прошли на дальнейший этап.
Этап интервью. 16 человек
На этапе интервью я оценивал софт-скиллы кандидата, давал информацию о компании и спрашивал подробнее про опыт. На этом этапе я также подробно изучал CV кандидата.
Этап тех интервью. 8 человек
Тут всё по классике. Задаю технические вопросы и оцениваю уровень кандидата от 0 до 100%.
Если было полезно, то ставьте ❤️
Если наберем хорошее количество лайков, то сделаю пост с рекомендациями по оформлению CV и как подготовиться к интервью
Обратил внимание, что у меня много новых подписчиков после того, как я разместил вакансию к нам в Bioneers, поэтому хотел бы по горячим следам поделиться своими мыслями насчёт процесса интервью.
В отличие от моего основного места работы, где всю подготовительную часть делает HR, а я уже делаю code review и тех интервью, тут я решил провести всё самостоятельно от и до. И скажу честно, это очень ценный опыт, и я стал гораздо лучше понимать ответственность HR.
Процесс интервью:
1. CV
2. Опросник
3. Тестовое задание
4. Интервью
5. Тех интервью
На мою вакансию откликнулось 70 человек, что превзошло мои ожидания в 3 раза. Поэтому, мне пришлось максимально автоматизировать процесс и подключить своего бота OpenClaw для помощи.
Этап CV. 70 человек
На просмотр CV кандидата я тратил менее 1 минуты. Сами понимаете, 70 человек — это уже 70 минут, поэтому правду говорят HR, что без грамотного CV на вас могут просто не обратить внимание. Далее я отдавал CV нейронке для автоматического ревью и создания страницы кандидата. Нейронка ставила скор от 1 до 5 на основе CV. Те кандидаты, что получали менее 2 баллов или у кого не было 2-х лет опыта, сразу получали отказ, остальные проходили на следующий этап.
Также я присылал информацию о проекте и о компании, и часть людей сами отказывались, так как наши условия им не подходили.
Этап опросника. 40 человек
Поскольку откликов было много, я принял решение сделать опросник. В опроснике просил оценить уровень от 1 до 5 по техническим навыкам, а также задавал несколько релевантных для нас вопросов, например, ожидаемый уровень ЗП и наигранность в игры автоматизации.
На основе опросника нейронка генерировала скор от 1 до 5. У кандидатов, которые сами себе поставили менее 3 баллов, спрашивал, точно ли они хотят делать тестовое, так как по их оценке есть шанс не пройти тех интервью.
Удивительно, но у многих кандидатов уровень в опроснике совпал с уровнем, который я поставил при code review.
Этап тестового задания. 30 человек
Тут стоит отметить, что всего 5 человек отказались делать тестовое задание сами, и ещё 5 человек отказались по результатам опросника. Правда, на этапе CV я предупреждал, что тестовое задание обязательно.
Тестовое задание я также прогонял через нейронку, которая формировала черновой отчёт и на основе моих критериев оценивала кандидатов. Далее я самостоятельно проводил ревью тестовых и корректировал отчёт уже на основе своего опыта. По результатам оценил кандидатов от 1 до 5, и те, кто получили 3.5 балла, не прошли на дальнейший этап.
Этап интервью. 16 человек
На этапе интервью я оценивал софт-скиллы кандидата, давал информацию о компании и спрашивал подробнее про опыт. На этом этапе я также подробно изучал CV кандидата.
Этап тех интервью. 8 человек
Тут всё по классике. Задаю технические вопросы и оцениваю уровень кандидата от 0 до 100%.
Если было полезно, то ставьте ❤️
Если наберем хорошее количество лайков, то сделаю пост с рекомендациями по оформлению CV и как подготовиться к интервью
❤32👍5🔥2👌2👎1💅1🗿1
Сопроводительное письмо как способ выделиться
Мой прошлый пост собрал рекордное количество реакций. Это радует и реально мотивирует делать новые посты.
Начал писать пост про CV, но понял, что сначала сделаю пост про сопроводительное письмо.
Отнеситесь к нему как к единственному тексту, который вообще кто-то будет читать.
Самое ужасное сопроводительное письмо за мой опыт найма выглядит так:
Скажу честно, я даже не отвечаю таким кандидатам.
А вот пример одного из лучших сопроводительных писем на мою вакансию в Bioneers:
Давайте разберу его по частям:
1. Одно сообщение, сразу CV в формате PDF в аттаче.
Нет потока сообщений, а всю информацию можно легко добавить на страницу кандидата.
2. Текст разбит на абзацы.
Такое письмо легко читать, и сразу видны ключевые моменты.
3. Немного конкретики про проект, плюс информация о том, что человек видел проект ранее.
Как минимум мне приятно, что это не просто отклик, а что человеку интересен мой проект. Пусть в реальности это не так и вам просто нужна работа, но это ведь цепляет.
4. Сразу коротко указан техстек.
Можно понять, с чем кандидат уже работал, а что ему придётся подучить.
Ставьте ❤️и я выпущу следующий пост про CV
Пишите в комментариях варианты как можно еще улучшить сопроводительное письмо
Мой прошлый пост собрал рекордное количество реакций. Это радует и реально мотивирует делать новые посты.
Начал писать пост про CV, но понял, что сначала сделаю пост про сопроводительное письмо.
Отнеситесь к нему как к единственному тексту, который вообще кто-то будет читать.
Самое ужасное сопроводительное письмо за мой опыт найма выглядит так:
Здарова. Вакансия актуальна?
Скажу честно, я даже не отвечаю таким кандидатам.
А вот пример одного из лучших сопроводительных писем на мою вакансию в Bioneers:
Привет! Увидел вакансию Unity-разработчика и заинтересовался проектом
Мой техстек кажется релевантным вашим требованиям, а сам проект я раньше видел на Reddit.
У меня 5+ лет опыта работы Unity-разработчиком. В своё время любил играть в детище Уилла Райта — Spore. Про Factorio слышал, но не играл (но это легко исправить, так как я с детства плотно подсел на игры :D).
Было бы клево поработать вместе =)
Техстек:
Unity, C#, ООП, SOLID
ECS (Morpeh), Zenject
REST API (BestHTTP)
Git, Rider, Addressables, Profiler, Unit Tests
Firebase, AppsFlyer, Crashlytics
Подробнее в CV: «ссылка»
Давайте разберу его по частям:
1. Одно сообщение, сразу CV в формате PDF в аттаче.
Нет потока сообщений, а всю информацию можно легко добавить на страницу кандидата.
2. Текст разбит на абзацы.
Такое письмо легко читать, и сразу видны ключевые моменты.
3. Немного конкретики про проект, плюс информация о том, что человек видел проект ранее.
Как минимум мне приятно, что это не просто отклик, а что человеку интересен мой проект. Пусть в реальности это не так и вам просто нужна работа, но это ведь цепляет.
4. Сразу коротко указан техстек.
Можно понять, с чем кандидат уже работал, а что ему придётся подучить.
Ставьте ❤️и я выпущу следующий пост про CV
Пишите в комментариях варианты как можно еще улучшить сопроводительное письмо
❤25👍5👨💻2💘1🦄1😎1
Всем привет! Не теряйте. Пост про CV почти дописал, в ближайшее время опубликую
👍17🫡6❤4😴1
Как оформить CV разработчику. Часть 1
Хочу начать с важной ремарки: я не профессиональный HR, поэтому воспринимайте эти советы как личное мнение человека, который регулярно смотрит CV разработчиков.
Я могу быть не прав или обращать внимание не на те вещи, на которые обращает внимание профессиональный HR. Но я тоже участвую в оценке кандидатов и часто смотрю CV уже с позиции CTO / техлида / нанимающего менеджера.
Главная задача CV — не рассказать всю вашу биографию, а быстро убедить человека, что вас стоит позвать на интервью.
CV должно за короткое время ответить на несколько вопросов:
Кто вы как специалист?
Какой у вас релевантный опыт?
С каким стеком вы реально работали?
Какие задачи вы решали?
Почему вам можно доверить работу?
Когда ваше CV смотрят:
1. Во время отклика на вакансию
2. Перед или во время HR-интервью
3. Перед или во время технического интервью
4. Перед или во время финального интервью
Соответственно, ваше CV должно быть понятно не только HR, но и техлиду, менеджеру проекта, CTO или CEO.
У каждого из них разный фокус. HR хочет быстро понять, подходите ли вы под базовые требования. Техлид смотрит на стек, опыт и уровень самостоятельности. Менеджер или CEO оценивает, насколько вам можно доверить проект, команду или важный участок работы.
Что происходит после того, как ваше CV попало к HR?
Обычно есть два варианта.
Первый вариант — CV автоматически импортируется в HR-платформу. Например, в DS мы используем HuntFlow. Такие системы вытаскивают информацию из CV и раскладывают ее по блокам: опыт работы, ключевые навыки, образование, контакты и так далее.
Это удобно для ревьюера, потому что все кандидаты отображаются в едином формате. Также такие платформы хорошо импортируют данные из LinkedIn, hh.ru и похожих сервисов.
Например, у меня иногда нет доступа к оригинальному PDF-файлу. Я вижу только информацию, которая была импортирована в HR-платформу. Поэтому важно, чтобы CV было не только красивым, но и нормально парсилось.
Второй вариант — человек смотрит ваш PDF-файл напрямую. И вот тут уже огромное значение имеет форматирование. CV должно быть легко читать и быстро сканировать глазами.
На мой взгляд, LinkedIn и hh.ru из коробки дают достаточно удобный и читаемый формат. Я бы советовал завести LinkedIn, регулярно его обновлять и использовать как основу для CV.
Первое чтение CV часто занимает не несколько минут, а 20–30 секунд. Поэтому самое важное должно быть видно сразу: ваша роль, стек, годы опыта, последние проекты, достижения и контакты.
На что я обращаю внимание в CV разработчика
1. Общая читаемость
CV должно быть простым, структурированным и понятным.
Мне не нужно видеть сложный дизайнерский шаблон, три колонки, иконки, диаграммы навыков и декоративные элементы. Мне нужно быстро понять ваш опыт.
Хорошее CV легко просканировать глазами. В нем понятные заголовки, нормальные отступы, аккуратные списки и нет огромных полотен текста.
2. Фотография
Фотография не обязательна, но если вы ее добавляете, она должна работать на ваш профессиональный образ.
Лучше нейтральное или полуофициальное фото, чем случайная фотография с вечеринки, отпуска или бара.
CV может смотреть CEO, CTO или будущий руководитель. Это люди, которые оценивают не только навыки, но и общее впечатление: можно ли доверить человеку работу, команду, проект или коммуникацию с заказчиком.
Если есть возможность, я бы рекомендовал один раз сделать несколько нормальных профессиональных фотографий и использовать их в CV, LinkedIn, Telegram, рабочих аккаунтах и так далее.
3. Опыт работы
Самый важный блок в CV — это опыт.
Я бы рекомендовал подробно описывать последние 2–3 места работы, а более старый опыт оставлять коротко.
По последним местам работы важно показать:
чем занималась компания или проект;
какая была ваша роль;
за какую часть работы вы отвечали;
с каким стеком работали;
какие конкретные задачи решали;
какого результата достигли.
Очень хорошо, когда CV выглядит как понятная профессиональная история: человек работал в одной компании, получил опыт, вырос, перешел дальше, взял более сложные задачи.
Хочу начать с важной ремарки: я не профессиональный HR, поэтому воспринимайте эти советы как личное мнение человека, который регулярно смотрит CV разработчиков.
Я могу быть не прав или обращать внимание не на те вещи, на которые обращает внимание профессиональный HR. Но я тоже участвую в оценке кандидатов и часто смотрю CV уже с позиции CTO / техлида / нанимающего менеджера.
Главная задача CV — не рассказать всю вашу биографию, а быстро убедить человека, что вас стоит позвать на интервью.
CV должно за короткое время ответить на несколько вопросов:
Кто вы как специалист?
Какой у вас релевантный опыт?
С каким стеком вы реально работали?
Какие задачи вы решали?
Почему вам можно доверить работу?
Когда ваше CV смотрят:
1. Во время отклика на вакансию
2. Перед или во время HR-интервью
3. Перед или во время технического интервью
4. Перед или во время финального интервью
Соответственно, ваше CV должно быть понятно не только HR, но и техлиду, менеджеру проекта, CTO или CEO.
У каждого из них разный фокус. HR хочет быстро понять, подходите ли вы под базовые требования. Техлид смотрит на стек, опыт и уровень самостоятельности. Менеджер или CEO оценивает, насколько вам можно доверить проект, команду или важный участок работы.
Что происходит после того, как ваше CV попало к HR?
Обычно есть два варианта.
Первый вариант — CV автоматически импортируется в HR-платформу. Например, в DS мы используем HuntFlow. Такие системы вытаскивают информацию из CV и раскладывают ее по блокам: опыт работы, ключевые навыки, образование, контакты и так далее.
Это удобно для ревьюера, потому что все кандидаты отображаются в едином формате. Также такие платформы хорошо импортируют данные из LinkedIn, hh.ru и похожих сервисов.
Например, у меня иногда нет доступа к оригинальному PDF-файлу. Я вижу только информацию, которая была импортирована в HR-платформу. Поэтому важно, чтобы CV было не только красивым, но и нормально парсилось.
Второй вариант — человек смотрит ваш PDF-файл напрямую. И вот тут уже огромное значение имеет форматирование. CV должно быть легко читать и быстро сканировать глазами.
На мой взгляд, LinkedIn и hh.ru из коробки дают достаточно удобный и читаемый формат. Я бы советовал завести LinkedIn, регулярно его обновлять и использовать как основу для CV.
Первое чтение CV часто занимает не несколько минут, а 20–30 секунд. Поэтому самое важное должно быть видно сразу: ваша роль, стек, годы опыта, последние проекты, достижения и контакты.
На что я обращаю внимание в CV разработчика
1. Общая читаемость
CV должно быть простым, структурированным и понятным.
Мне не нужно видеть сложный дизайнерский шаблон, три колонки, иконки, диаграммы навыков и декоративные элементы. Мне нужно быстро понять ваш опыт.
Хорошее CV легко просканировать глазами. В нем понятные заголовки, нормальные отступы, аккуратные списки и нет огромных полотен текста.
2. Фотография
Фотография не обязательна, но если вы ее добавляете, она должна работать на ваш профессиональный образ.
Лучше нейтральное или полуофициальное фото, чем случайная фотография с вечеринки, отпуска или бара.
CV может смотреть CEO, CTO или будущий руководитель. Это люди, которые оценивают не только навыки, но и общее впечатление: можно ли доверить человеку работу, команду, проект или коммуникацию с заказчиком.
Если есть возможность, я бы рекомендовал один раз сделать несколько нормальных профессиональных фотографий и использовать их в CV, LinkedIn, Telegram, рабочих аккаунтах и так далее.
3. Опыт работы
Самый важный блок в CV — это опыт.
Я бы рекомендовал подробно описывать последние 2–3 места работы, а более старый опыт оставлять коротко.
По последним местам работы важно показать:
чем занималась компания или проект;
какая была ваша роль;
за какую часть работы вы отвечали;
с каким стеком работали;
какие конкретные задачи решали;
какого результата достигли.
Очень хорошо, когда CV выглядит как понятная профессиональная история: человек работал в одной компании, получил опыт, вырос, перешел дальше, взял более сложные задачи.
💯10👌1
Как оформить CV разработчику. Часть 2
Если коммерческого опыта мало, можно указать pet-проекты, учебные проекты, open-source, свои игры, прототипы, GitHub, Steam-страницы, видео геймплея. Это не полностью заменяет коммерческий опыт, но точно лучше, чем пустое место.
4. Достижения, а не только обязанности
Одна из частых проблем CV — человек описывает только обязанности.
Плохо:
Работал над мультиплеером.
Фиксил баги.
Делал UI.
Участвовал в разработке проекта.
Лучше:
Отвечал за мультиплеерный модуль в Unity-проекте: переработал сетевую архитектуру, вынес логику в отдельные сервисы, добавил тесты на ключевые сценарии и снизил количество критичных багов перед релизом.
Или:
Ускорил разработку фич за счет внедрения базовой архитектуры, код-ревью и переиспользуемых компонентов UI.
Важно писать так, чтобы было понятно и HR, и техническому специалисту. Не нужно превращать CV в техническую документацию, но и слишком общие формулировки не помогают.
5. Ссылки на проекты
Если у вас есть GitHub, LinkedIn, портфолио, Steam-страница, App Store, Google Play, видео геймплея, статьи или посты — добавляйте.
Скажу честно, я очень редко смотрю портфолио, так как мне проще выяснить все информацию на интервью, но иногда глаз может зацепиться за что-то интересное. Плюс вас могут собеседовать компании в которых не настроен процесс, тогда они могут посмотреть ваше портфолио и позвать вас на интервью
6. Желтые флаги
Желтые флаги — это не автоматический отказ. Это повод задать уточняющий вопрос.
К таким вещам я бы отнес:
частую смену работы;
очень короткие периоды в компаниях;
длинные перерывы;
фриланс;
несколько работ параллельно;
непонятные роли и зоны ответственности.
Все это не обязательно плохо. У каждого может быть свой контекст. Но если такой контекст есть, лучше объяснить его в CV или быть готовым спокойно объяснить на интервью.
Например, если был перерыв — можно написать, чем вы занимались: учеба, свой проект, релокация, семейные обстоятельства, запуск стартапа.
Если был фриланс — объясните почему совмещали его с основной работой и какие есть гарантии, что фриланс не помешает основной работе в компании
Если было несколько коротких мест работы — важно объяснить, что произошло, чтобы это не выглядело как риск конфликтности или нестабильности.
7. Что точно должно быть в CV разработчика
Минимальный набор, который я ожидаю увидеть:
ваша специализация;
ключевой стек;
коммерческий опыт;
последние 2–3 места работы с подробным описанием;
конкретные достижения;
ссылки на проекты или портфолио;
уровень английского;
локация и желаемый формат работы;
актуальные контакты.
10. Что лучше убрать
Я бы убирал из CV все, что не помогает принять решение пригласить вас на интервью.
Например:
слишком общие качества вроде “ответственный”, “стрессоустойчивый”, “коммуникабельный”;
нерелевантный опыт, расписанный слишком подробно;
огромные описания старых проектов;
визуальный шум;
устаревшие технологии, если они не важны для вакансии;
навыки, которыми вы на самом деле не владеете.
Если хотите написать про soft skills, лучше показывать их через опыт.
Не “коммуникабельный”, а “синхронизировал работу команды из 5 разработчиков, проводил code review и помогал джунам с декомпозицией задач”.
И главный совет: смотрите на CV не как на формальность, а как на инструмент продажи вашего опыта.
Хорошее CV не гарантирует оффер. Но плохое CV может не дать вам даже дойти до интервью, хотя по навыкам вы могли бы отлично подойти.
Если вы хотите проверить свое CV, то самый лучший вариант показать его другу/знакомому, дать ему 30 секунд на ознакомпление и спросить на что он обратил внимание
Надеюсь пост был полезен, а если у вас есть вопросы или свои лайфхаки, то делитесь ими в комментариях
Если коммерческого опыта мало, можно указать pet-проекты, учебные проекты, open-source, свои игры, прототипы, GitHub, Steam-страницы, видео геймплея. Это не полностью заменяет коммерческий опыт, но точно лучше, чем пустое место.
4. Достижения, а не только обязанности
Одна из частых проблем CV — человек описывает только обязанности.
Плохо:
Работал над мультиплеером.
Фиксил баги.
Делал UI.
Участвовал в разработке проекта.
Лучше:
Отвечал за мультиплеерный модуль в Unity-проекте: переработал сетевую архитектуру, вынес логику в отдельные сервисы, добавил тесты на ключевые сценарии и снизил количество критичных багов перед релизом.
Или:
Ускорил разработку фич за счет внедрения базовой архитектуры, код-ревью и переиспользуемых компонентов UI.
Важно писать так, чтобы было понятно и HR, и техническому специалисту. Не нужно превращать CV в техническую документацию, но и слишком общие формулировки не помогают.
5. Ссылки на проекты
Если у вас есть GitHub, LinkedIn, портфолио, Steam-страница, App Store, Google Play, видео геймплея, статьи или посты — добавляйте.
Скажу честно, я очень редко смотрю портфолио, так как мне проще выяснить все информацию на интервью, но иногда глаз может зацепиться за что-то интересное. Плюс вас могут собеседовать компании в которых не настроен процесс, тогда они могут посмотреть ваше портфолио и позвать вас на интервью
6. Желтые флаги
Желтые флаги — это не автоматический отказ. Это повод задать уточняющий вопрос.
К таким вещам я бы отнес:
частую смену работы;
очень короткие периоды в компаниях;
длинные перерывы;
фриланс;
несколько работ параллельно;
непонятные роли и зоны ответственности.
Все это не обязательно плохо. У каждого может быть свой контекст. Но если такой контекст есть, лучше объяснить его в CV или быть готовым спокойно объяснить на интервью.
Например, если был перерыв — можно написать, чем вы занимались: учеба, свой проект, релокация, семейные обстоятельства, запуск стартапа.
Если был фриланс — объясните почему совмещали его с основной работой и какие есть гарантии, что фриланс не помешает основной работе в компании
Если было несколько коротких мест работы — важно объяснить, что произошло, чтобы это не выглядело как риск конфликтности или нестабильности.
7. Что точно должно быть в CV разработчика
Минимальный набор, который я ожидаю увидеть:
ваша специализация;
ключевой стек;
коммерческий опыт;
последние 2–3 места работы с подробным описанием;
конкретные достижения;
ссылки на проекты или портфолио;
уровень английского;
локация и желаемый формат работы;
актуальные контакты.
10. Что лучше убрать
Я бы убирал из CV все, что не помогает принять решение пригласить вас на интервью.
Например:
слишком общие качества вроде “ответственный”, “стрессоустойчивый”, “коммуникабельный”;
нерелевантный опыт, расписанный слишком подробно;
огромные описания старых проектов;
визуальный шум;
устаревшие технологии, если они не важны для вакансии;
навыки, которыми вы на самом деле не владеете.
Если хотите написать про soft skills, лучше показывать их через опыт.
Не “коммуникабельный”, а “синхронизировал работу команды из 5 разработчиков, проводил code review и помогал джунам с декомпозицией задач”.
И главный совет: смотрите на CV не как на формальность, а как на инструмент продажи вашего опыта.
Хорошее CV не гарантирует оффер. Но плохое CV может не дать вам даже дойти до интервью, хотя по навыкам вы могли бы отлично подойти.
Если вы хотите проверить свое CV, то самый лучший вариант показать его другу/знакомому, дать ему 30 секунд на ознакомпление и спросить на что он обратил внимание
Надеюсь пост был полезен, а если у вас есть вопросы или свои лайфхаки, то делитесь ими в комментариях
🔥12
Почему никто не использует Test-Driven Development в геймдеве?
Разбирал тут наши старые документы и наткнулся на тест-кейсы, которые мы писали, когда я пытался внедрять TDD в разработку.
Забавно, что в какой-то момент я параллельно пробовал использовать Test-Driven Development сразу в двух сильно разных проектах: в Bioneers и в одном проекте в Datasakura — условно MMO RPG.
Изначально TDD казался мне почти идеальным подходом: сначала описываешь требования через тесты, потом пишешь код, который эти тесты проходит, а дальше спокойно рефакторишь архитектуру, не боясь всё сломать.
Но в геймдеве всё оказалось сложнее.
Игровая логика часто меняется на ходу, фичи зависят не только от кода, но и от ощущений, баланса, визуала, анимаций, таймингов и геймдизайнерских экспериментов. Поэтому классический TDD далеко не всегда ложится на разработку так красиво, как в книжках.
При этом я не считаю TDD бесполезным для игр. Наоборот, есть зоны, где он может работать очень хорошо: экономика, прогрессия, инвентарь, боёвка, расчёты урона, крафт, сохранения, симуляции и любая другая детерминированная логика.
В итоге продробнее расписал свои мысли в статье на Habr
Разбирал тут наши старые документы и наткнулся на тест-кейсы, которые мы писали, когда я пытался внедрять TDD в разработку.
Забавно, что в какой-то момент я параллельно пробовал использовать Test-Driven Development сразу в двух сильно разных проектах: в Bioneers и в одном проекте в Datasakura — условно MMO RPG.
Изначально TDD казался мне почти идеальным подходом: сначала описываешь требования через тесты, потом пишешь код, который эти тесты проходит, а дальше спокойно рефакторишь архитектуру, не боясь всё сломать.
Но в геймдеве всё оказалось сложнее.
Игровая логика часто меняется на ходу, фичи зависят не только от кода, но и от ощущений, баланса, визуала, анимаций, таймингов и геймдизайнерских экспериментов. Поэтому классический TDD далеко не всегда ложится на разработку так красиво, как в книжках.
При этом я не считаю TDD бесполезным для игр. Наоборот, есть зоны, где он может работать очень хорошо: экономика, прогрессия, инвентарь, боёвка, расчёты урона, крафт, сохранения, симуляции и любая другая детерминированная логика.
В итоге продробнее расписал свои мысли в статье на Habr
❤8👍6
Bioneers вышел в закрытое тестирование!
Ровно год назад началась разработка игры, а сегодня первые игроки наконец получили доступ к закрытой Demo.
Впереди сбор фидбека, исправление багов и много работы до публичного релиза.
Но важный milestone пройден и в Bioneers уже играют реальные игроки
А если тоже хотите получить ключик и поиграть, то напишите мне в личку @romanchikov и я дам вам один
Ровно год назад началась разработка игры, а сегодня первые игроки наконец получили доступ к закрытой Demo.
Впереди сбор фидбека, исправление багов и много работы до публичного релиза.
Но важный milestone пройден и в Bioneers уже играют реальные игроки
А если тоже хотите получить ключик и поиграть, то напишите мне в личку @romanchikov и я дам вам один
🔥19❤5👌1
Bioneers Closed Demo — финальные результаты первых 48 часов
Подвели итоги первых 48 часов Closed Demo. И результаты получились действительно сильными.
За это время у нас:
— 250 уникальных игроков
— 174 заполненных feedback form
— 3 ч 4 мин среднего времени игры
— 4.48/5 общая оценка игры
— 4.49/5 оценка core gameplay
— 4.89/5 желание вернуться
— +1000 новых Wishlist
Но самое интересное — что стоит за этими цифрами.
1. Среднее время игры — около 200% от количества контента
Для демо очень хорошим результатом можно считать среднее время игры около 80% от доступного контента. Для нас это было бы примерно 1 ч 15 мин. Фактический результат — 3 ч 4 мин.
То есть игроки проводят в Bioneers примерно 250% времени относительно объёма уникального контента.
И для меня это один из самых важных результатов тестирования.
Игроки не просто проходят доступный контент и закрывают игру. Они продолжают строить организмы, экспериментировать, перестраивать системы и запускать игру снова.
В среднем получилось 2.4 запуска на игрока.
Фактически люди уже готовы играть в наш core loop даже после того, как новый контент закончился.
2. Средняя оценка — 4.5/5
Для Demo оценка 4+ — уже хороший показатель.
У нас:
— 4.48/5 общее впечатление
— 4.49/5 core gameplay
— 4.89/5 желание вернуться
Причём 156 из 174 игроков поставили желанию вернуться 5/5.
Это не значит, что игра идеальна. Feedback довольно чётко показывает проблемы в game design, balance, UX и micromanagement.
Но самое важное — игроки позитивно оценивают сам фундамент игры.
Нам не нужно переделывать core gameplay. Нам нужно его улучшать, балансировать и развивать.
3. За время Demo мы получили +1000 Wishlist
И это особенно интересно, потому что Closed Demo было ограничено примерно 250 игроками.
То есть рост Wishlist значительно превышает количество участников тестирования.
Для нас это хороший сигнал органического распространения: люди играют, рассказывают об игре, делятся ей с друзьями и рекомендуют попробовать Bioneers.
При этом 99% участников feedback form уже добавили игру в Wishlist или собираются это сделать.
⸻
Вся аналитика первых 48 часов показывает очень хорошую динамику.
Это очень сильный результат для первого Closed Demo и высокий задел для будущего проекта.
Так что ждем продолжения! 🫡
Подвели итоги первых 48 часов Closed Demo. И результаты получились действительно сильными.
За это время у нас:
— 250 уникальных игроков
— 174 заполненных feedback form
— 3 ч 4 мин среднего времени игры
— 4.48/5 общая оценка игры
— 4.49/5 оценка core gameplay
— 4.89/5 желание вернуться
— +1000 новых Wishlist
Но самое интересное — что стоит за этими цифрами.
1. Среднее время игры — около 200% от количества контента
Для демо очень хорошим результатом можно считать среднее время игры около 80% от доступного контента. Для нас это было бы примерно 1 ч 15 мин. Фактический результат — 3 ч 4 мин.
То есть игроки проводят в Bioneers примерно 250% времени относительно объёма уникального контента.
И для меня это один из самых важных результатов тестирования.
Игроки не просто проходят доступный контент и закрывают игру. Они продолжают строить организмы, экспериментировать, перестраивать системы и запускать игру снова.
В среднем получилось 2.4 запуска на игрока.
Фактически люди уже готовы играть в наш core loop даже после того, как новый контент закончился.
2. Средняя оценка — 4.5/5
Для Demo оценка 4+ — уже хороший показатель.
У нас:
— 4.48/5 общее впечатление
— 4.49/5 core gameplay
— 4.89/5 желание вернуться
Причём 156 из 174 игроков поставили желанию вернуться 5/5.
Это не значит, что игра идеальна. Feedback довольно чётко показывает проблемы в game design, balance, UX и micromanagement.
Но самое важное — игроки позитивно оценивают сам фундамент игры.
Нам не нужно переделывать core gameplay. Нам нужно его улучшать, балансировать и развивать.
3. За время Demo мы получили +1000 Wishlist
И это особенно интересно, потому что Closed Demo было ограничено примерно 250 игроками.
То есть рост Wishlist значительно превышает количество участников тестирования.
Для нас это хороший сигнал органического распространения: люди играют, рассказывают об игре, делятся ей с друзьями и рекомендуют попробовать Bioneers.
При этом 99% участников feedback form уже добавили игру в Wishlist или собираются это сделать.
⸻
Вся аналитика первых 48 часов показывает очень хорошую динамику.
Это очень сильный результат для первого Closed Demo и высокий задел для будущего проекта.
Так что ждем продолжения! 🫡
🔥19❤6👌1
Media is too big
VIEW IN TELEGRAM
🛠 Как Astra меняет мой подход к разработке
В последнее время много экспериментировал с Astra. И, на мой взгляд, она довольно сильно меняет подход к работе.
Некоторые задачи, на которые раньше уходили недели документации, прототипирования и обсуждений, теперь получается разобрать за несколько подходов.
Покажу на двух примерах из Bioneers.
1. Прототип логистики за сутки
По отзывам игроков у нас была проблема с логистикой: она непонятна и плохо контролируется.
При этом готового референса под нашу задачу я не нашёл. В той же Factorio многое построено на конвейерах. У нас ресурсы должны передаваться между клетками напрямую, иначе визуально получится завод, а мы всё-таки строим организм.
Примерно неделю я расписывал систему в Miro. И каждый раз находил новые нюансы: ага, здесь не продумал, тут ресурса не хватит, а здесь несколько клеток одновременно хотят его получить.
В какой-то момент понял, что нужно делать прототип и щупать руками. Уже морально приготовился потратить на это несколько недель вместе с разработчиком.
Но решил попробовать Astra. И за сутки сделал рабочий прототип.
Да, съел все лимиты, купил подписку за $200 и даже там упёрся в ограничения 😅
Но проверил основные кейсы, потыкал разные варианты и определился с тем, как система должна работать. По моей оценке, сэкономил около двух недель.
После этого написал GDD и приложил прототип как референс. Теперь разработчик и QA могут сами собрать нужную ситуацию и посмотреть ожидаемый результат.
2. Древо эволюции до готовности механик
Мне нужно было спроектировать близкое к финальному древо эволюции: технологии, ресурсы, зависимости, баланс.
Раньше я бы ждал реализации, потом шёл в Unity и всё настраивал.
Сейчас сделал веб-прототип со всем деревом. Могу менять стоимость технологий, выстраивать порядок открытия и смотреть, где у игрока может быть затык, а где стоит дать больше возможностей.
Причём делать это можно ещё до того, как сами механики готовы в игре.
Финальный баланс, конечно, проверяется в геймплее. Но структуру прогрессии уже можно проработать и передать разработчику.
И для меня это ТЗ нового уровня.
Я сейчас рассказываю со стороны game design, но как разработчику мне такой формат тоже очень нравится.
Приходит геймдизайнер, даёт короткое описание и прототип: «Смотри, механика должна работать вот так».
Можно пощупать, поменять параметры, проверить разные ситуации. Уже гораздо проще понять взаимодействие сущностей, декомпозировать задачу и потом проверить результат в реальной игре.
Текст всё ещё нужен. Но сколько обсуждений и уточнений можно сэкономить, когда рядом есть работающий пример.
Пока это одно из самых полезных применений Astra, которое я нашёл для себя.
В последнее время много экспериментировал с Astra. И, на мой взгляд, она довольно сильно меняет подход к работе.
Некоторые задачи, на которые раньше уходили недели документации, прототипирования и обсуждений, теперь получается разобрать за несколько подходов.
Покажу на двух примерах из Bioneers.
1. Прототип логистики за сутки
По отзывам игроков у нас была проблема с логистикой: она непонятна и плохо контролируется.
При этом готового референса под нашу задачу я не нашёл. В той же Factorio многое построено на конвейерах. У нас ресурсы должны передаваться между клетками напрямую, иначе визуально получится завод, а мы всё-таки строим организм.
Примерно неделю я расписывал систему в Miro. И каждый раз находил новые нюансы: ага, здесь не продумал, тут ресурса не хватит, а здесь несколько клеток одновременно хотят его получить.
В какой-то момент понял, что нужно делать прототип и щупать руками. Уже морально приготовился потратить на это несколько недель вместе с разработчиком.
Но решил попробовать Astra. И за сутки сделал рабочий прототип.
Да, съел все лимиты, купил подписку за $200 и даже там упёрся в ограничения 😅
Но проверил основные кейсы, потыкал разные варианты и определился с тем, как система должна работать. По моей оценке, сэкономил около двух недель.
После этого написал GDD и приложил прототип как референс. Теперь разработчик и QA могут сами собрать нужную ситуацию и посмотреть ожидаемый результат.
2. Древо эволюции до готовности механик
Мне нужно было спроектировать близкое к финальному древо эволюции: технологии, ресурсы, зависимости, баланс.
Раньше я бы ждал реализации, потом шёл в Unity и всё настраивал.
Сейчас сделал веб-прототип со всем деревом. Могу менять стоимость технологий, выстраивать порядок открытия и смотреть, где у игрока может быть затык, а где стоит дать больше возможностей.
Причём делать это можно ещё до того, как сами механики готовы в игре.
Финальный баланс, конечно, проверяется в геймплее. Но структуру прогрессии уже можно проработать и передать разработчику.
И для меня это ТЗ нового уровня.
Я сейчас рассказываю со стороны game design, но как разработчику мне такой формат тоже очень нравится.
Приходит геймдизайнер, даёт короткое описание и прототип: «Смотри, механика должна работать вот так».
Можно пощупать, поменять параметры, проверить разные ситуации. Уже гораздо проще понять взаимодействие сущностей, декомпозировать задачу и потом проверить результат в реальной игре.
Текст всё ещё нужен. Но сколько обсуждений и уточнений можно сэкономить, когда рядом есть работающий пример.
Пока это одно из самых полезных применений Astra, которое я нашёл для себя.
🔥12👌1