Connect with us

Статьи

Пользовательское тестирование игры: зачем это нужно и как его провести своими силами

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

Playtestix

Опубликовано

/

     
     

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

Playtestix-logo-BW-no-bck

playtest

Антон Ульяненков, аналитик Playtestix

Ожидания и реальность

Вот уже два года я занимаюсь изучением пользовательского опыта в играх, работая аналитиком в компании Playtestix. Инструментом в моей работе чаще всего выступает плейтест. Плейтест (или пользовательское тестирование игры) не имеет ничего общего с тестированием игры на баги. Он может решить задачи юзабилити тестирования, но это не является его основной задачей. Игра генерирует у игрока определенный опыт, который очень тщательно продумывается разработчиками игры, у них есть определенные ожидания, желаемый сценарий поведения игрока. Разработчики в большинстве случаев делают игру не для себя, в идеале это аудитория с определенными демографическими характеристиками и предпочтениями в играх. Очень часто я сталкиваюсь с тем, что наши заказчики делают предрелизный плейтест, чтобы удостовериться, что у них все хорошо, и мой вопрос о целевой аудитории вводит их в ступор. Если вдруг вы делаете игру, но еще не знаете, на кого она рассчитана, самое время определиться – провал игры без целевой аудитории неминуем.

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

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

Допустим, мы осознали полезность проведения пользовательского тестирования, что делать дальше? Я попытаюсь поэтапно расписать процесс подготовки, проведения и анализа результатов плейтеста.

Формулировка целей и задачи

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

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

  • Какие ожидания формирует подготовленная маркетинговая продукция (скриншоты, видео, описание игры)?
  • Мы хотим, чтобы за первую игровую сессию игрок успел ознакомиться со всеми основными возможностями игры, без ожидания – хватает ли игрокам начального запаса энергии?
  • Есть предположение, что текущая реализация туториала недостаточно наглядно объясняет предназначение различных ресурсов, помогает ли обучение разобраться игроку с предназначением различных ресурсов?
  • Сейчас не реализовано обучение по интерфейсу магазина, это критично или он является для игрока интуитивно понятным?
  • Как воспринимается игроком нарратив? Удачно ли сюжетные вставки формируют глобальные цели или игрок концентрируется лишь на выполнении отдельных заданий?
  • По задумке главный персонаж должен восприниматься игроками как мужественный, наделенный лидерскими качествами, но в тоже время добрый и веселый. Какие эмоции вызывает у игрока главный персонаж? Какими качествами он его наделяет?

Кого тестировать?

Как только определились с задачами, можно начинать думать, кто будет тестировать вашу игру. Лучше всего выбрать людей, которые никак не связаны с разработкой вашей игры, разработчики знакомы с игрой слишком близко и это может впоследствии искажать их мнение об игре. Друзья и члены семьи также скорее всего не откажут вам в просьбе поучаствовать, но велика вероятность того, что они не захотят вас расстраивать, если им что-то не понравится, или изначально будут расположены очень положительно к тому, что вы им предоставите.  Не ищите легких путей, уделите поиску нужных людей больше времени. Определитесь с целевой аудиторией вашей игры и попытайтесь привлечь “независимых” тестеров, игровые сообщества и форумы дают сегодня такую возможность. Например, для нашей игры в жанре ферма, это могут быть женщины возрастной группы 30+, пользующийся устройством Android, игравшие в Hay Day или Farmville и достигшие в одной из этих игр 10 уровень.  Тестеров можно мотивировать подарками, но все же основной их мотивацией должна быть любовь к играм. Остерегайтесь профессиональных респондентов.

Выбор методов сбора фидбека от игры

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

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

  • Метод анкетирования: на различных этапах игровой сессии мы задаем игрокам вопросы исходя из того, какой опыт он получил на данном этапе в игре. Например, чтобы понять насколько обучение справляется с возложенными на него задачами,  нужно спросить у игрока о обучении непосредственно после его окончания.
  • Метод наблюдения: продумываем структуру бланка исходя из сценария плейтеста, заполняет бланк наблюдатель непосредственно по ходу плейтеста. Ферма обычно ведет игрока, давая ему различные задания – мы можем взять очередность заданий как основу бланка наблюдателя. Обязательно нужно учитывать, что игрок с самого начала может начать игнорировать задания, отклоняясь от задуманного сценария.
  • Интервью дает возможность соотнести наблюдения и ответы, задать уточняющие вопросы. Есть много видов интервью по степени формализации, но я бы советовал вам заранее определиться со списком вопросов, выбрать из них самые важные, требующие детального, развернутого ответа от игрока.
  • Видеозапись дает возможность членам команды в дальнейшем возвращаться к каким-либо моментам, пересматривать ситуации описанные в наблюдении.

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

Следите за нашими новостями!

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Разработка

“Крутись и уворачивайся”: история разработки Circle vs Spikes

Немного о себе: 30 лет, программированием начал заниматься относительно поздно, всего 2 года назад. Имелся технический бэкграунд, но в целом от программирования был далек. Знакомых кодеров тоже не было, пришлось самому набивать шишки, пытаясь понять, что и как делать. Привлекла идея делать мобильные приложения, так как хотелось работать на себя. Ну а что может быть интереснее геймдева. Таким образом была поставлена цель – научиться делать мобильные игры.

AppTractor

Опубликовано

/

Автор:

Но сначала нужно было изучить основы. Решил взяться за фундаментальные вещи: теория, алгоритмы, проектирование и т.д. Промучившись месяца два понял, что нужно ставить практические задачи, а теорию изучать уже по мере надобности. Стал изучать Java, которая повсеместно используется для Android. Да и фреймворк LibGDX, о котором я уже тогда начал думать, был на Java.

Освоив на достаточном уровне Java и LibGDX, я захотел пройти весь путь от идеи игры до публикации. Хотелось начать с чего-то простого. Пришла мысль сделать 2D-аркаду, в которой надо уворачиваться от препятствий, двигаясь при этом по сложной траектории.

Итак, у меня была неплохая цель – сделать в короткие сроки простую игру, довести ее до публикации в Google Play и, таким образом, набраться опыта. В итоге “короткие сроки” растянулись более чем на полтора года. Частенько я переделывал все с нуля, тратил много времени на каждый этап, добавлял или убирал функционал. Много времени было вложено и в создание редактора уровней. Если игра будет нравится людям, включу его в игру в одном из обновлений. Вот так он выглядит сейчас.

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

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

Крутись и уворачивайся

В игре вы управляете кругом, который движется по орбите. При этом орбита вместе с кругом движутся вперед. Таким образом соединяются две траектории: круговая и прямолинейная. Это делает механику интересной, заставляет просчитывать наперед это сочетание. Кругом надо уворачиваться от множества разных препятствий (шипов, маятников, лазеров, блоков…). Управление при этом предельно простое – касанием экрана можно менять направление вращения по орбите.

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

На то, чтобы сменить направление вращения (другими словами – на каждое касание) требуется 1 заряд. Уровень вы начинаете, имея 100 зарядов. Цель – истратить как можно меньше зарядов за уровень. То есть нельзя бездумно тыкать по экрану, нужно просчитывать траекторию и использовать заряды с умом.

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

Имеется поддержка Google Play Игр:

  1. Достижения – за каждое из которых открывается новый скин или цветовая тема.
  2. Лидерборды
  3. Сохранения и синхронизация между устройствами

Музыку мне сделал друг, специально для игры, за что я ему очень благодарен. Кому интересно, вот ссылка на его страничку в Soundcloud: https://soundcloud.com/octonick.

Также я постоянно делаю новые уровни, так что пройдя все – не спешите удалять игру. Я планирую часто выпускать обновления.

Если у вас есть какие-либо вопросы, пишите, постараюсь ответить всем: ibragames.com@gmail.com.

Комментарии
Продолжить чтение

Маркетинг и монетизация

Информационное обжорство. Как сесть на диету?

Сегодня для многих людей мобайл стал чем-то сродни шведского стола, на котором мы съедаем 3080 калорий за один присест. Мы знаем, что насытимся и двумя тысячами, но ничего не можем с собой поделать. Социальные сети. Бесконечные всплывающие уведомления. Время, потраченное на просмотр видео. Netflix. YouTube. И так далее.

Джей лаб

Опубликовано

/

Автор:

По данным последнего исследования Мэри Микер, каждый взрослый мобильный пользователь тратит 3,3 часа в день на мобильные устройства. Согласно данным NPD Group, средний пользователь смартфонов потребляет в общей сложности 31,4 ГБ данных ежемесячно (включая Wi-Fi и мобильный интернет). Использование безлимитного мобильного трафика на 67% выше, чем трафика с лимитом.

Как мы дошли до этого и что это значит для маркетологов?

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

Теперь Google и Apple, операционные системы которых находятся на 99% мобильных устройств, прилагают усилия, чтобы помочь пользователям, которые хотят ограничить свое пребывание в виртуальном мире. На своей конференции в мае Google сообщила, что 70% пользователей нуждаются в помощи и представила инструменты, которые помогут им найти нужный баланс. Одновременно с выходом iOS 12 этой осенью, Apple представит функцию Screen Time, которая будет предоставлять информацию о приложениях и устройствах и позволит пользователям ограничить доступ к ним, если они захотят сократить количество потраченного на них времени. Функция Screen Time будет включать в себя отчеты о работе устройств, ограничение доступа к приложениям, блокировку уведомлений, а также новый элемент управления «не беспокоить», призванный помочь клиентам «уменьшить количество отвлекающих факторов и контролировать время, проведенное у экрана смартфона для себя и своих близких».

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

Screen Time создает подробные ежедневные и еженедельные отчеты, которые фиксируют общее время, которое человек проводит в каждом приложении, какие категории приложений посещаются чаще, сколько уведомлений получают пользователи и как часто они берут в руки свой iPhone или iPad. Люди могут контролировать, сколько времени они тратят на определенное приложение, веб-сайт или категорию приложений. Функция ограничения приложений позволяет пользователям установить определенное время, которое они готовы потратить на приложение, и когда оно будет подходить к концу, уведомление сообщит о том, что пора закругляться.

Apple представляет iOS 12

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

Таким образом, маркетинговые кампании все же будут затронуты. По данным Adobe, за девятимесячный период, закончившийся в марте этого года, бренды отправили на 300% больше push-уведомлений, чем в предыдущие девять месяцев. Когда вскоре у потребителей появится возможность убрать уведомления с главного экрана, нужно будет уделить особое внимание тому, чтобы сообщения, отправляемые потребителям, были просмотрены своевременно и имели нужный эффект.

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

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

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

Комментарии
Продолжить чтение

Обучение

Как не застрять в обучении

Это один из самых популярных постов на Medium, получивший уже более 22 тысячи аплодисментов с начала месяца. Тони Мастрорио, со-основатель Whiteboardfree.com, рассказывает о том, как перейти от туториалов к разработке.

AppTractor

Опубликовано

/

Автор:

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

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

Добро пожаловать в учебное чистилище

Итак, вместо того, чтобы создавать собственные проекты, я застрял в том, что я называю «учебным чистилищем». Поскольку я понимал, что учиться –  это хорошо, я читал и смотрел каждый туториал, который мог найти, который казался интересным, который, как я думал, я смогу в один день применить в собственном проекте. Я проводил так месяц за месяцем, заполняя ночи бесконечными видео на YouTube, Udemy и на всех других сайтах, которые я только мог найти. Я многому научился, но забыл чуть ли не больше в процессе.

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

Например, когда я только начинал, я купил и посмотрел курс The Web Developer Bootcamp на Udemy – 43 часа видео по таким темам, как HTML, CSS, Bootstrap, JavaScript и jQuery. Я думал, что курс вышел отличный, но когда я закончил, я все еще не был готов делать собственные проекты.

Вместо этого я вернулся на сайт и купил еще The Complete Web Developer Course 2.0. И посмотрел еще 30 часов видео, охватывающих большинство тех же тем, что и первый курс!

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

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

Нет инструкций – нет проблем

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

Я решил сделать сайт вроде Stack Overflow, где пользователи могли бы регистрироваться, публиковать вопросы, отвечать, добавлять комментарии и даже вставлять видео непосредственно в свои сообщения.

Это казалось амбициозным проектом, но мне было все равно. Я хотел сделать что-то, что было вызовом для меня. И так как я недавно начал изучать Ruby on Rails и действительно наслаждался этим, я решил использовать Rails в качестве фреймворка для моего побочного проекта.

Было много всего, что я не знал, когда начал делать этот первый проект (так же, как и сейчас с каждым новым проектом, который я начинаю). Я не знал, как создать систему авторизации, реализовать разбиение на страницы или использовать AJAX в приложении Rails. Я не знал, как использовать рекурсию для реализации системы комментариев. На самом деле, я даже не знал, что такое рекурсия!

Начните с того, что вы знаете

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

Google стал моим лучшим другом. Это привело меня к Devise и oAuth Rails, которые я бы мог объединить для создания системы авторизации. Devise позволил бы моим пользователям создавать новые учетные записи и входить с ними в систему, а oAuth предоставил бы им возможность входить с использованием существующих учетных записей Google или Facebook.

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

Когда я застревал на чем-то, я перешагивал через вопросы и ответы на Stack Overflow и искал статьи и туториалы, которые бы помогли мне решить проблему. Я постоянно использовал обучающие материалы, но теперь я использовал их только для изучения того, что я немедленно мог применить к проекту.

Нормально просить о помощи

В редком случае, когда таким образом я не мог найти ответы, которые мне были нужны, я попросил о помощи на Stack Overflow. На некоторые из моих вопросов даже ответили (например, на этот, где я попросил о помощи с вложенными комментариями).

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

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

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

Вы никогда не узнаете, как делать всё (никто не знает), и вам всегда нужно будет искать что-то в Интернете (все ищут). Просто не позволяйте этому мешать вам делать вещи.

Комментарии
Продолжить чтение

Разработка

Трудоустройство Android-разработчиков в России и за рубежом: собеседования, знания, деньги

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

AppTractor

Опубликовано

/

Автор:

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

Денис: Как все устроено на рынке мобильной разработки? Что у нас в России с количеством мобильных разработчиков и соотношением iOS и Android? Насыщен ли рынок мобильными разработчиками?

Евгения: Мы актуализировали специально к этому выпуску свои данные. Если смотреть глобально, всего разработчиков в России около 200 тысяч. Если смотреть на мобильную разработку в целом (iOS и Android), то это в районе 11 тысяч человек на всю Россию. Это, действительно, не очень много. И если смотреть именно большую разбивку по направлениям, то Android сейчас в России занимается  примерно 7,5 тысяч человек. И примерно 5 тысяч iOS-разработчиков.

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

Из этих 11 тысяч человек большая часть приходится на Москву. В Москве мобильных разработчиков в районе 45% от общего количества. На втором месте по региону стоит Петербург, здесь где-то 25%. И уже дальше, в порядке убывания, регионы идут – Новосибирск, Казань и Нижний Новгород. Это самые лидеры. Все остальные уже  равномерно размазаны. Томск, Омск, Пермь. Все наши любимые города.

Денис: Расскажи про компании. Ведь это же как раз потенциальные работодатели.

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

Во-вторую уже идут аутсорс разработки и студии.

Если выделять поток работодателей по количеству команд, которые представлены, то тут однозначно лидируют все наши крупняки, которых мы знаем. Это и Яндекс, и Mail, и СберТех, и Тинькофф, и Рамблер. По аутсорсу больше видны EPAM, Redmadrobot, Agora, Hyperboloid. То есть тоже все знакомые компании.

Денис: Продукты больше платят, чем аутсорсеры своим ребятам или зарплаты на одном уровне?

Евгения: Смотря какие. Мы еще хотели с тобой сегодня подробно обсудить тему зарплат, но забегая вперед честно скажу, что у всех разные денежные составляющие. Понятно, что если ты работаешь на аутсорс, тем более если это не российские заказчики, то, скорее всего, на сегодняшний день зарплата у тебя будет больше. Но если смотреть на перспективу в 2-3 года, то продуктовые компании выигрывают так или иначе — со своим всем соцпакетам и по тому, как у них зарплаты устроены.

Денис: Давай пока поговорим про оплату по уровням разработчиков. Сколько же в Москве, Питере и регионах зарабатывают разработчики?

Евгения: Я готовила цифры по Москве, именно по «вилкам», потому что регионы уже зависят от уровня жизни. Соответственно, говорить буду про цифры, которые получают сейчас на руки.

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

Мидлы в Москве по верхней границе где-то до 160 на руки.

Соответственно, сеньоры уже где-то до 230.

И тим-лиды до 280 потолок.

Но это такая, очень «средняя температура по больнице». Понятно, что есть компании, которые платят выше рынка, и есть компании, которые, может быть, платят чуть ниже рынка, хотя их уже практически не осталось. Это средние цифры.

Денис: А куда деваются такие компании? Они закрываются или приходится им платить выше, иначе невозможно нанять?

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

Денис: Зато многие сидят на старых местах и говорят: «Ну, и что, что мало платят, зато я здесь всех знаю».

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

У меня был в анамнезе Android-разработчик, который пришел и сказал, что ему 4 года не повышали заработную плату. За 4 года Android-разработка ушла вперед такими семимильными шагами, что я вообще не понимаю, как он сидел тогда за свою зарплату, которая у него была 4 года назад.

Денис: Я хочу дать ребятам маленький совет.

Запомните слово «перформанс-ревью». Когда вы придете к начальству говорить о деньгах, говорите не о том, что надо пересмотреть зарплату. Это выглядит неловко. Надо говорить  «Давайте посмотрим мою производительность» — это звучит гораздо приятнее. И вот на основе производительности уже нужно делать выводы.

Многие, кстати, неуверенны в себе. Они хорошие ребята, они хорошо делают — но есть комплекс, что где-то на свете есть гораздо круче ребята, которые знают больше, и поэтому ничего, что мне платят не так много. Но все равно не бойтесь говорить: «Давайте устроим перформанс-ревью». Это и вам в плюс всегда. Вы будете знать, что каждые полгода у вас есть проверка, которая будет показывать, насколько хорошо вы работаете. И на основе этого, можно сделать выводы – стоит ли вам повышать зарплату или нет. И вы тоже этими выводами сможете оперировать.

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

Евгения: Основное отличие все-таки в требованиях и в том, что спрашивают. То есть со стартапами – это совсем непредсказуемая история. С одной стороны, вы можете нарваться на выходцев из крупных IT-компаний, которым не давали спуска на собеседовании, и которые под копирку привыкли у всех входящих спрашивать алгоритмы. Но в целом стартапы больше все-таки ориентируются на тот опыт, который у вас уже был, то есть больше на практику – что вы уже реализовывали, что вы уже умеете, в чем вы уже навострились, и можно ли вас быстро подключить к тем задачам, которые есть, потому что все горит, и нужно делать. Плюс еще, действительно, смотрят на то, сколько у вас гибкости, то есть сможете ли вы быстро влиться в развитие проекта.

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

Денис: А вообще крупные компании хантят просто разработчиков, software engineers? Или они все-таки редко когда так делают, и в большинстве своем, если человек хорошо знает Android, то они его берут на Android?

Евгения: Если смотреть на глобальный мировой рынок – в мире есть команды в крупных компаниях, в которых разработчики такие универсальные солдаты, которые действительно software engineers. И они могут и бэк, и под мобилу, и под фронт, и вот куда их ни посади, они смогут примерно все написать.

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

Многие компании готовы действительно переучивать. Например, сейчас есть ребята, которые были ксамаринщиками, но они хотят перейти, например, в iOS или в Android. У них хорошая теоретическая база, они прекрасно пишут код на C#. Но это очень редкие истории. Обычно все-таки работодатели хотят, чтобы у вас уже был опыт, и чтобы вы подтверждали свою квалификацию, подтверждали финансовые ожидания своими навыками. Хотят, чтобы вы, так или иначе, имели опыт и понимали, что как работает.

Александр: Я довольно часто смотрю резюме, потому что занимаюсь постоянно наймом. И когда ты видишь, что в резюме Xamarin или другие  кроссплатформенные фреймворки, то это часто очень демотивирует. То есть я даже могу посоветовать, наверное, не указывать это в первую очередь. Например, если вы еще и гуру Xamarin, кроме того, что хорошо шарите в Android, то, наверное, лучше его немного придержать. Или рассказать об этом на непосредственном собеседовании, когда вас позовут и вы уже докажете свою квалификацию, потому что, к сожалению, так часто получается, что когда человек занимается и тем, и другим, когда у него очень-очень много баззвордов написано, то на самом деле он не знает ничего нормально. Но это у меня такое ощущение сложилось, по тому, насколько я с кандидатами общался.

Евгения: Я могу только поддержать. И здесь многих действительно Xamarin и кроссплатформенность будут отталкивать, потому что на рынке очень много сейчас нативной разработки, и на нее идет основная упор. В целом ребята, которые сейчас кроссплатформенные разработчики, ксамаринщики, я их вижу очень редко. Я вижу в основном уже таких ребят, у которых эта история в прошлом, но у них действительно не всегда хорошая бывает настоящая нативная база. Они могут хорошо разбираться в платформе, они очень хорошо пишут код на C#, как правило, но как только ты начинаешь копать в Java или в Objective-C, или в Swift, или во что-то еще, то у них начинаются очень большие пробелы, с которыми не всегда готовы мириться текущие команды.

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

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

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

Александр: Можно посоветовать, если вы собеседуетесь в продукт, то у вас могут спросить обязательно: «Что в нашем продукте не так? Что вы считаете нужным улучшить?» и т.д. Если вы идете собеседоваться в продуктовую компанию, то обязательно посмотрите их приложения, сервисы.

Денис: Да, обязательно попробуйте приложения и продукты перед тем, как идти, однозначно. Это правда. Мы до этого обсуждали кроссплатформенный Xamarin. А можно еще пару слов про React Native? Мне кажется, если у человека опыт React Native, то нужно понять — он вообще больше web-разработчик, фронтенд, или он все-таки больше из мира мобильного, с мобильным бэкграундом, потому что если у него опыт React Native, то, скорее всего, это выходец из web.

Евгения: Да, все так. Здесь я даже мало что смогу добавить. У рынка очень большой запрос на нативную разработку, пока что без React Native. То есть да, он появляется, но пока что объемы сравнительно небольшие

Мы, рекрутеры, смотрим и не всегда бывает понятно. React Native для нас пока что еще это про фронтенд история, не про мобилку.

Александр: Я ребят попросил, что бы они выбрали, какие баззворды чаще всего встречаются для Android-разработчика. И вот, как ни странно, в них нет ни Flutter, ни React Native. В основном это всякие RX, Java, Android, Git.

Евгения: Я сегодня посмотрела: Flutter на LinkedIn в России сейчас у шести человек написан, на Хедхантере у других тоже у шести человек написан. Вакансий с Flutter вообще ни одной еще нет. Технология новая, оно и понятно. Так что кажется, что это такие действительно очень редкие технологии, которых на рынке практически еще нет.

Денис: Я еще хотел сказать про кроссплатформенные приложения.

Когда мы смотрим человека с React Native, то ощущения примерно такие же, как и с  Xamarin — лучше постесняться. И вообще любой нативщик считает любую кроссплатоформу чем-то за гранью добра и зла. Поэтому отношение у тех, кто собеседует, к кроссплатформе не самое благоприятное. Имейте это в виду. Возможно, часто это необъективно. Но если не хотите добавить лишнюю отрицательную оценку, то лучше не пишите об этом.

А чем отличается собеседование за границу? И какую заграницу? Что под заграницей понимается?

Евгения: Давай брать глобальную историю все-таки. Здесь разные абсолютно подходы могут быть. Понятно, что пункт номер один для всех ребят, которые хотят попробовать поработать не с рынком СНГ – это английский на уровне Fluent. Вот однозначно это самый первый скил, который будут проверять, и нужно много уметь разговаривать на английском, и разговаривать хорошо. Нужно для себя принять, что это в России ты можешь быть звездой, и тебя может знать каждый второй разработчик, и ты можешь быть супер классным. Но когда ты выходишь за пределы СНГ, ты встаешь уже в соревнование с немножко другим потоком людей, и таких как ты там довольно много. Поэтому рекруты того же самого, например, Google, все равно будут обращать внимание на ключевые вещи.

Это и образование, чтобы был ВУЗ, который входит в топ-100 мировых. И предыдущие компании. Не все компании захотят с вами разговаривать, если они никогда раньше не видели продуктов этой компании за пределами России. Вы можете делать бесконечно прекрасный продукт в какой-нибудь компании «Цветочки» в какой-нибудь Перми. Если про этих «Цветочки» никто нигде не знает за пределами России, то, скорее всего, многие компании даже не заходят с вами разговаривать, потому что для них нужно понимать, что у вас, грубо говоря, мозги на месте. В компаниях, условно, типа Яндекса, есть хорошая школа разработки, и всю дурь из всех уже выбили к тому моменту, как ребята оттуда собираются уходить.

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

Денис: Я должен тоже немножко добавить.

Ребята, не бойтесь ничего. Женя вас чуть-чуть напугала, что Fluent английский должен быть. Я все-таки, как уехавший и общающийся с большим количеством ребят, которые уехали, могу добавить, что язык – да, очень важен, но даже если вы плохо разговариваете, но вы топ-кодер, решаете задачи на лету, у вас очень сильное резюме, вы работали в каком-то очень крутом проекте, с какой-то очень узкой, но очень важной потенциальному работодателю технологией, даже без языка вас заберут.

Заберут и будут с вами на пальцах общаться через Google Translate, потому что вы нужны, потому что таких, как вы, нету.

Если вы более заурядны, по вашей собственной оценке, то, конечно, делайте акцент на язык и решайте задачи. Практически все за рубежом, даже маленькие компании, больше спрашивают задачи. Да и в России тоже уже стали достаточно много спрашивать задач алгоритмических. Поэтому алгоритмы – наше все. Покупайте книжки по подготовке. Не бойтесь этих задачек. А, может быть, вы уже в ВУЗе много занимались, вы – олимпиадник. И это тоже вам очень сильно на руку. Но и это, опять же, не обязательно. Как карта ляжет. Возможно, вы супер просто без английского и без алгоритмов попадете в какой-нибудь блокчейн-стартап “Что-то там LLC” там на Кипре. И будете с русскими общаться, никогда не пересекаясь с иностранцами, но живя за границей. Такое вполне вероятно и с более дальними странами.

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

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

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

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

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

А с сеньорами, соответственно, все вышеперечисленное, но при этом очень много самостоятельности и умение уже писать приложения с нуля, так или иначе, чтобы в опыте это уже было, и плюс уже множество «шишек», которые человек набил за время своего опыта. Потому что сеньоры – это, как правило, ребята, которые в разработке от трех лет, а то и больше. И понятно, что они сталкивались с очень многими проектами, с очень разными заказчиками, структурами и всем остальным. Им есть что рассказать. И они спокойно приходят на проекты, они уже видят, какая там архитектура, они понимают, что делать. И, по сути дела, ты им даешь задачу, и можно дальше уже не мучиться вообще, в принципе.

От лидов бизнес уже хочет какой-то опыт менторства джунов хотя бы (если мы говорим о лидах, которые без опыта работы, то есть это такие хорошие сеньоры, которые хотят уже лидами стать). Либо это уже уверенные лиды, у которых были команды в подчинении, хотя бы от трех человек, если это совсем маленькое что-то. Тут ребята много смотрят на понимание бизнеса, умение работать с продуктовым направлением и с продуктовыми аналитиками, и с продакт-менеджерами и  т.д… И умение договариваться с бизнесом, и понимание вообще, как продукт строится, какие бизнес-процессы, куда что идет.

Денис: Тут еще нужно отметить то, что лид – это не то, чтобы прям ступенька над сеньором. Некоторые ребята не хотят это делать или не умеют. И это нормально вполне.

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

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

Александр: Нужно отметить: у мидлов часто есть такой синдром сеньоров, то есть часто сеньоры считают себя мидлами, а мидлы – наоборот, сеньорами. Когда они приходят на собеседование — это типичная ситуация. Человек сидел три года, занимался своим проектом. И вот он вроде все делает, все фичи, которые ему приходят, он их реализует довольно быстро. Он приходит на собеседование, и при этом не подготовился, потому что он считает: «Я уже сеньор». И при этом у него, получается, такая не очень хорошая теоретическая база, и он очень сильно валится. Поэтому, если вы чувствуете себя таким мидлом, почти сеньором, то перед собеседованием обязательно повторите теорию, потому что могут неплохо завалить.

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

Денис: Да. Послушайте наш выпуск про то, что нужно знать интернет-разработчикам на собеседованиях. У нас тоже было, по-моему, даже два выпуска «Что нужно знать новичкам?». Там прям мы все пункты обходили.

Android Dev Подкаст. Выпуск 37. Android для новичков. Часть 1

Дальше у нас подготовка к интервью. Мы уже проговорили, что нужно порешать задачки, повторить теоретическую базу, попросить товарища, чтобы он вас пособеседовал, коллегу по профессии. Потому что ничего нет лучше интервью. Особенно если вы на английском интервью готовите, попросите русскоговорящего товарища по-английски вас погонять. А если есть иностранец, то это вообще идеально. И это очень сильно поможет. И вы сразу с ним пройдете и посмотрите, что было не так, что так. А если запишете и посмотрите, вообще придете к совершенству потом на реальном собеседовании. Что вы еще, Жена, Саша, добавите?

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

Денис: Да. Может быть, вы еще потом в эту компанию работать пойдете. Она окажется не такой уж и плохой. А компания вашей мечты вам откажет или вам не понравится. Вообще будьте осторожны со словами «компания мечты», потому что вы начнете ее бояться, бояться идти в нее собеседоваться и думать, что там все идеально, приукрашивать, а все остальные компании – недооценивать И как раз вот собеседование в других компаниях в качестве подготовки откроет вам глаза на многое.

Евгения: Я тут, скорее, добавлю именно, что когда будете прогоняться по техническим вопросам, не забудьте еще о себе хорошо, бодро кому-нибудь рассказать. Сначала подготовить, соответственно, какой-то self-speech о себе, о своем опыте. Он не должен быть большим, краткий, но его хорошо лучше оттренировать заранее, проговорить пару раз перед зеркалом, предварительно написав еще к тому же (это вообще в идеале). И потом уже дальше рассказать маме, еще лучше – бабушке, которая вообще не понимает в том, чем вы занимаетесь.

Александр: Еще лучше – коту.

Евгения: Пятилетнему ребенку. Ну, с котом сложно. Он не будет тебя спрашивать о том вообще «Что? Какой дагер? Чего происходит вообще?». Там не будет такого. Лучше всего найти небезразличных родственников. И плюс еще, действительно, возможно, стоит куда-то сходить, потренироваться, потому что с компанией мечты сложно. Но здесь еще хочется понимать, что можно, конечно, прийти в какой-нибудь сомнительный непонятный проект пособеседоваться, но это будет совершенно другого уровня вопросы.

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

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

Александр: А еще можете прямо смело спросить: «Что мне нужно знать вообще на собеседовании?». Может, даже сработает. Если бы меня спросили «Саша, что нужно, чтобы попасть в Хедхантер?», я бы сказал: «Изучите вот то, то, то». Это никакой не секрет, что я буду спрашивать. Главное, чтобы человек в этом ориентировался, и когда я копну в глубину, тоже все это понимал.

Евгения: Еще не нужно бояться. Иногда бывает, что ты говоришь человеку: «Тебе, чтобы хорошо пройти, нужно знать вот это, вот это и вот это». Человек уходит, на следующий день возвращается и говорит: «Нет. Спасибо. Давайте через полгода. Я немножко не могу». Он начинает бояться. И тут все-таки я бы сказала: не бойтесь пробовать. Большинство компаний понимает, что ставить крест на разработчиках, если кто-то с первого раза не прошел интервью, это вообще плохая история. Есть ребята, которые в некоторые компании заходят с четвертого раза просто потому, что, наконец, научились нормально отвечать на вопросы.

Денис: А есть какая-то средняя статистика, через сколько компании готовы рассмотреть того же кандидата повторно, если он подготовился и стал более уверенным?

Александр: Ты знаешь, в среднем, наверно, полгода-год.

Евгения: Тут есть ремарка одна большая. Можно ходить куда угодно раз в год. Каждый год мы с ребятами ходим в баню… Сколько угодно. Но если у вас за этот год ничего не изменилось, вы не отработали все те вопросы, которые у вас спрашивали… Условно, если вы хотите через полгода снова вернуться в компанию Х — подумайте, вы на те же вопросы, на которых вы завалились, ответите или нет? Если нет, лучше не идти. Как рекрутер могу сказать: мы смотрим еще на то, что произошло за эти последние полгода. Мы действительно спрашиваем: «А что ты делал, чтобы подтянуться?». Мы смотрим, перешел ли человек в какую-то другую компанию. То есть год назад он у нас был, за этот год он сменил место работы. Мы прекрасно знаем, какие на новом месте разработчики. Бывают ситуации, что человек вроде бы перешел в другую компанию, и вроде там ничего, но ты знаешь, как там устроено, и для тебя у него не появилось ответов на старые вопросы. То есть то, что он сменил место работы, на него никак особо не повлияло, на его знания.

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

Денис: Это правда. Женя, а у тебя есть какой-то чек-лист для подготовки к собеседованию?

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

Денис: Тут надо сказать, что в интернете очень много чек-листов – что нужно знать там по платформе, например. Если мы говорим про Android, то откройте эти листы и посмотрите. А дальше уже ваш скилл будет определяться глубиной знаний по каждой из тем.

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

Александр: Поход на собеседование – это, в принципе, такая же проектная деятельность. Сначала вы в ней не очень хорошо разбираетесь, а со временем начинаете шарить лучше. Поэтому не бойтесь ходить просто на собеседования, это отличная подготовка боем. Но при этом, если вы ничего не знаете, ничего не повторяли, то можно неплохо опозориться.

Ведущие

Денис Неклюдов
GDE

Александр Блинов
HeadHunter

Александр Ефременков
Яндекс

Евгения Остроумова
GMS

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.