Саша чуть позже ответит, я пока по первому вопросу. На Yii написаны очень старые куски бэкенда, еще на 1.1, их давно никто не трогал из принципа «if it works don't fix it». Потом пришли новые разработчики и стали писать новые участки бэкенда на Symfony (потому что работали с ним), ну и теперь надо старые довести до текущего стандарта. Когда я причесывал интервью, оно подсократилось, вот из удаленного в тему:
Будешь рефакторить старый код?
Я работал в компаниях, где слово «рефакторинг» — ругательное. Там было принято четко определяться, на что надо тратить время, и какие задачи это решает. Поэтому я привык что-то переделывать по мере поступления задач. Просто закладываю на них чуть больше времени и исправляю все, до чего дотягиваются руки, по ходу работы. Так ты вникаешь в проект, понимаешь задачи, и со временем код становится лучше. Мы будем понемногу переделывать некоторые части бэкенда, все-таки Yii 1.1 – заслуженный старичок; скорее всего на Symfony, ничего не имею против.
Была идея с видео, но показалось негуманным настаивать, чтобы ребята его сделали — у разработчиков традиционный осенний завал, им не до игрушек (по той же причине пока не выложили эту штуку в открытый доступ). Но понятно, что это не Crysis — мы не геймдев, у нас вау-порог низкий, и эта игра графически очень выделялась на фоне других проектов хакатона . Для нас главная фишка этого проекта — выявление возможности сделать нечто трехмерное своими силами, раньше это было совсем не очевидно. То, что в комментарии ниже — «низкий порог вхождения и быстрое прототипирование». Именно этой идеей хотелось поделиться с другими не-геймдев компаниями.
Да, в планах есть, мы собираем пожелания от конкурсантов и партнеров. К сожалению, у этой задачи пока не самый высокий приоритет, но, думаю, к следующему конкурсу методов и возможностей добавится. В том числе и Ваши 1) и 2).
1) сейчас берутся все слова из всех наборов. Очевидно, что с ростом числа внешних приложений будет необходимо добавить возможность видеть наборы и брать слова не из всех.
2) слова добавляются в набор «Внешние приложения». Я думаю, мы сделаем «полу-открытый» метод API для создания наборов, который будем давать сторонним разработчикам, которым он действительно нужен. Пока мало кто пользуется возможностью добавлять слова.
Некоторое время не мог понять, почему некоторые люди не понимают простого, вроде, факта, что опыт работы != опыт работы в конкретном фреймворке, с конкретным инструментом, да даже с конкретным языком. Ну или что парсинг базы хедхантера != к нам пришел разработчик. А потом коллеги подсказали ссылку. Чакры открылись, дзен постигнут. Спасибо!
Случится то, что следующий кандидат решит «правильно», не отдавая себе отчет в том, почему это правильно. Ну вот как ЕГЭ, если все знают ответы, то в чем смысл? sergey-s — наш глава разработки, именно он придумывает задачи и смотрит кандидатов. У него, как у head of development, нет времени выдумывать новые задачи каждую неделю.
Но! Мы с ним договорились сделать осенью текст про требования и распространенные ошибки — как только он обновит тестовый задачник. Будет с примерами и всем-всем-всем, надеюсь, вам понравится. И, кстати, спасибо за активность и подсказку для темы новой статьи.
Опыт от 6 лет стажа по специальности — это не критерий для отсеивания кандидатов, а критерий для парсинга и личных рассылок. Если к нам придет крутой разработчик с 2-летним опытом Ангуляра — мы его возьмем. Но у нас не настолько огромный HR-отдел, чтобы общаться со всеми соискателями, указавшими AngularJS в резюме. Кого-то мы, конечно, из-за этого упускаем.
Хочется все-таки уточнить, что в процитированном тексте речь идет о junior'ах, т.е. разработчиках без опыта, которых нам еще предстоит учить и продвигать. Люди, с которыми им предстоит работать, смотрят код и решают, готовы они принять такого «падавана», или нет. И эти люди хотят понять, что человек умеет сам, без подсказок в виде «критериев»; увидеть ход его мысли.
Что касается потенциальных middle и senior, найденных по объявлениям, то с ними важно в первую очередь проверить, правда в резюме или фантазии. Но это отдельная история, к цитате про критерии отношения не имеющая.
Критерии — это 60% решения. Способов решить одну и ту же задачу очень много. Мы же хотим посмотреть, какое решение разработчик выберет самостоятельно, на основе своего опыта и взглядов на разработку.
У нас прямо сейчас открыта Junior-позиция, кликните на «вакансии компании». При этом мы рассчитываем найти туда человека, который сам будет хотеть повысить свой статус в сжатые сроки, а уж мы поможем-научим.
В данный момент мы не готовы ответить на этот вопрос, т.к. юристы готовят лицензионное соглашение, которое полностью покроет все правовые вопросы по всему контенту, часть которого произведена нами, часть куплена, чаcть — public domain с разными формами лицензирования; это долгий процесс, поэтому мы даже сроков конкурса пока не называем. Мы написали статью и открыли доступ для того, чтобы все желающие могли посмотреть, разобраться и научиться пользоваться. Если вы уже прямо сейчас хотите выкатить что-то коммерческое — пожалуйста, свяжитесь с нами через «Заявку», мы попробуем сориентировать по срокам.
У нас 3%, если честно, взяты с потолка. Была задача: настроить коммуникации таким образом, чтобы экономить _как минимум_ 3%. Мы видим, что эта задача решена: все стало получаться заметно быстрее. Сколько там процентов в реальности (наверняка значительно больше) — ну, нет просто сейчас возможности считать, люди заняты другими задачами.
Я в команде Skyeng скорее отношусь к «старперам» (у меня клиенты IRC стоят на всех компьютерах), мне лично удобно и понятно, что интервью я делаю в Скайпе, а вопросы решаю в Слаке. А так я вижу, что народ активно пользуется, например, интеграцией с Hangouts. Лично мое старперское мнение — не нужно все вообще засовывать в один продукт, чтобы не повторять историю Nero, если кто вообще сейчас его помнит. Ну вот будет в Слаке видео и шаринг рабочего стола — он обрастет жиром и начнет тупить. Зачем выдумывать свой велосипед, если можно взять готовый и интегрировать?
Мы не стали подробно расписывать инструменты Слака, которыми пользуемся, просто потому, что таких текстов — вагон; на один есть ссылка — он небольшой и по делу. Кроме того, задачи рекламировать Слак у нас не было — если в вашей компании прижился ХипЧат, то почему и нет, главное, максимально использовать его полезный для работы функционал. У Скайпа этого функционала в принципе нет, поэтому у нас он почти исключительно применяется для общения один на один и видеоконференций. Кроме того, Скайп у людей обычно используется и для рабочих, и для личных контактов, что добавляет сумятицы.
Будешь рефакторить старый код?
Я работал в компаниях, где слово «рефакторинг» — ругательное. Там было принято четко определяться, на что надо тратить время, и какие задачи это решает. Поэтому я привык что-то переделывать по мере поступления задач. Просто закладываю на них чуть больше времени и исправляю все, до чего дотягиваются руки, по ходу работы. Так ты вникаешь в проект, понимаешь задачи, и со временем код становится лучше. Мы будем понемногу переделывать некоторые части бэкенда, все-таки Yii 1.1 – заслуженный старичок; скорее всего на Symfony, ничего не имею против.
1) сейчас берутся все слова из всех наборов. Очевидно, что с ростом числа внешних приложений будет необходимо добавить возможность видеть наборы и брать слова не из всех.
2) слова добавляются в набор «Внешние приложения». Я думаю, мы сделаем «полу-открытый» метод API для создания наборов, который будем давать сторонним разработчикам, которым он действительно нужен. Пока мало кто пользуется возможностью добавлять слова.
Но! Мы с ним договорились сделать осенью текст про требования и распространенные ошибки — как только он обновит тестовый задачник. Будет с примерами и всем-всем-всем, надеюсь, вам понравится. И, кстати, спасибо за активность и подсказку для темы новой статьи.
Что касается потенциальных middle и senior, найденных по объявлениям, то с ними важно в первую очередь проверить, правда в резюме или фантазии. Но это отдельная история, к цитате про критерии отношения не имеющая.