Русский
Русский
English
Статистика
Реклама

Интервью

Расшифровка эфира с Джоном Ромеро байки о том, как создавался DOOM

29.08.2020 12:21:18 | Автор: admin

10 августа в наших соцсетях прошел стрим с Джоном Ромеро создателем игр Doom, Quake и Wolfenstein 3D. Это был вечер теплых ламповых историй по заявкам: вы задавали вопросы в комментариях, а Джон рассказывал, как все было.

Вопросы задавал автор телеграм-канала и подкаста Запуск завтра Самат Галимов.

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

Тебя знают во всём мире как создателя DOOM и Dangerous Dave. Это очень популярные игры, а какую игру ты создал первой?


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


Ты прогал прямо на настоящем мэйнфрейме с доступом по телетайпу?


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

Это была текстовая игра?


Да, текстовая игра, как Zorg или Adventure.

Разве интересно было играть в собственную текстовую игру? Ты же знал все ответы



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

Кто-нибудь еще играл в неё?


Нет, только я.

Как ты заполучил доступ к этому первому компьютеру?


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

Это было законно или не совсем?


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

Вас кто-нибудь выгонял оттуда?


Нет, ни разу не выгоняли.

У тебя был свой компьютер?


Нет, компьютер у меня появился только через три года. Значит, на мэйнфрейме я программировал в 1979 году.

Джон, а какую игру ты опубликовал первой?


Она называлась Scout Search, в 1984 году ее напечатали в журнале.

В журнале? Как это?


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

Сколько же это строк кода?


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

Итак, как мы выяснили, первым компьютером, который ты увидел, был этот мэйнфрейм, а какой был первый нормальный компьютер, на котором ты работал?


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

И сколько удавалось поработать в магазине за один заход? По моему опыту, оттуда довольно быстро выгоняют


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

Не думаю, что если ребенок программирует, это так уж просто. Дети очень упорны. А какая игра была у тебя любимой в детстве?


Безусловно, Pac-Man.

Прямо настоящий, на игровом автомате?


Да.

И ты играл за настоящие монеты?


Да, я потратил три года и несколько тысяч долларов на игровые автоматы. Тогда автоматы были повсюду, мир был полон ими. Их больше нет, даже представить невозможно, что автоматы были везде, куда ни глянь. В Pac-Man играло столько народа, что в Японии и США начался дефицит монет.

Давай переместимся на 15 лет вперед и поговорим о DOOM. У DOOM было три создателя: ты, Джон Кармак и Дэйв Тейлор. Как вы все познакомились?


DOOM мы делали впятером: я, Джон, Том, Адриан и Кевин. Мы познакомились, когда работали вместе в компании SoftDisk в 1990 году.

Вы были там программистами?


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

Когда же вы спали?


В два часа ночи ложились спать, а в десять утра возвращались на работу. Так что мы работали с 10:00 до 18:00, а затем принимались за создание новой игры. Работали по 16 часов в сутки.

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


Дело в том, что Джон Кармак придумал способ сделать на ПК плавную прокрутку, как у Nintendo. Такой революционной технологии не было ни у кого. Мы чувствовали, что у нас есть огромный секрет, который разом всё перевернёт. И мы были невероятно воодушевлены, что можем использовать эту технологию для создания собственных игр, а затем выпустить ее в мир в виде ПО.

То есть, вы, по сути, знали, что сидите на мешке с золотом, но не в денежном смысле, а в смысле создания чего-то выдающегося


Да. Меньше чем за три месяца мы сделали три игры, где использовали эту технологию, а потом выпустили их. Это был Commander Keen. Первая трилогия.

Я должен сознаться, я каждый день играю в нее в DOS-боксе


Если у тебя Mac, можно загрузить Commander Genius это замечательная версия всех игр Commander Keen специально для Mac, но внутри нее изначальная DOS игра.

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

Я знаю, что ты участвовал в работе над демо Super Mario III. Можешь рассказать нам об этом?


Когда мы придумали этот технологический приём, первое, для чего была использована демоверсия, это создание первого уровня Super Mario III, но без использования самого Марио. Мы двигались по миру Марио, а один из моих персонажей, Опасный Дейв, прыгал в этом мире. Это было просто изначальное демо под названием Опасный Дэйв и нарушение авторских прав. Это выглядело потрясающе. Сразу же возникла идея сделать первые два уровня Super Mario III со всеми монстрами, Марио и всем остальным и отправить их в Nintendo. Вот почему мы сделали эту демку чтобы узнать, заинтересована ли Nintendo в издании нашей версии Super Mario III для ПК.

И они, видимо, не были заинтересованы?


Они посчитали, что версия действительно отличная, но решили, что не хотят переносить свою собственность на чужую платформу, поэтому мы сделали Commander Keen.

И эта игра гораздо лучше, на мой взгляд. Говорят, что создание DOOM было риском, прыжком веры. Но действительно ли это так? У вас же уже была эта уникальная технология. Или это было раньше?


Wolfenstein. Мы сделали Wolfenstein в 1992 году, это был наш третий шутер. До этого у нас было ещё два, они помогли нам отработать технологию и понять, что вообще делают в играх от первого лица. К тому времени, как мы сделали Wolfenstein, мы поняли, что использование оружия делает игру интересной. Сразу после этого мы выпустили приквел к Wolfenstein, Spear of Destiny. Мы сделали его довольно быстро, всего за два месяца. А затем начали планировать DOOM. Технически нужно было всё делать заново, с нуля, потому что мы не могли использовать ничего из Wolfenstein, так как планировали написать совершенно другой движок. Еще до того, как начать работу на DOOM, мы знали, чего сможем достичь в игре, и были очень воодушевлены этим знанием. Мы не думали, что рискуем, потому что знали, какие проблемы надо решить, и знали, что дадим себе столько времени, сколько понадобится на их решение. Получается, создание Wolfenstein от идеи до выпуска заняло четыре месяца, и нас было четверо. После Wolfenstein мы наняли еще двоих. Всего получилось шесть человек, один из которых был бизнес-менеджером и не участвовал в разработке, так что нас было пятеро.

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

Это из-за того, что нарисовать кривую линию сложнее?


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

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

Это очень серьезный прогресс в технологии, он потребовал больших вложений


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

У нас было практически сколько угодно времени. С того момента, как мы выпустили Commander Keen в декабре 1990 года, у нас не было проблем с деньгами. За Commander Keen в первый месяц мы заработали наши первые 10 500 долларов. Через год мы зарабатывали уже 50 000 долларов в месяц, и нас по-прежнему было всего четверо. Понятно, что мы тратили не всё. Мы просто продолжали вкладывать деньги в компанию, но наш банковский счет продолжал расти. Благодаря этому у нас было много времени для создания игр, нам никогда не приходилось ускорять разработку. На разработку Wolfenstein мы потратили четыре месяца, а на создание DOOM ушёл целый год. Когда вышел Wolfenstein, денег стало больше как минимум в пять раз.

Люди, не испытывающие внешнего давления, обычно рассказывают о проблеме расползания проекта

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

Мы знали, что именно пытаемся сделать. Скажем, с Wolfenstein мы действительно добавили в игру больше, а затем, поиграв в нее, быстро убрали добавленные нами функции, потому что они мешали самой сути игры, а суть была динамичная игра, в которой надо во всё палить. Если приходится останавливаться в коридоре, чтобы обыскать тело, вы останавливаете сущность игры. Игра была весьма скоростной, и это стало сутью. Суть заключалась в том, чтобы стрелять во всё подряд, получать ключи, открывать двери, продолжать во всё стрелять, собирать всё, что видишь, но никогда не останавливать игрока, за исключением момента, когда он добрался до двери, и ему надо ее открыть. Вот, в принципе, и всё останавливаешься только если наткнулся на дверь. Чем больше мы добавляли в игру того, что могло бы замедлить игрока, тем больше мы понимали, что игра не об этом: не о том, чтобы быть незаметным, не о том, чтобы шарить по чужим карманам или таскать трупы. Мы снова всё убрали, потому что суть игры не в этом. Не в том, чтобы перекладывать тела и со всем этим возиться. Она в том, чтобы нестись на всех парах через этот замок со скоростью 70 кадров в секунду и, по сути, мочить всех направо и налево. Мы убрали из игры всё, что этому не соответствовало. С DOOM было то же самое. Пока мы делали DOOM, у нас было много элементов, которые мы потом убрали. В Wolfenstein надо было подбирать предметы, за которые давали очки. Потом мы начали играть в DOOM, и поняли, что это не аркадная игра, не должно быть очков, нас не волнует счет. Нас волнует Твоя задача в том, чтобы убить всех демонов, выбраться с уровня, чтобы перейти на следующий, уничтожить всех демонов там и спасти оставшихся людей. Смысл не в том, чтобы набрать побольше очков. Больше того, DOOM не наказывает игрока за смерть. То есть, тебе не говорят, что у тебя три жизни: их столько, сколько хочешь. Если умираешь, то оказываешься в начале уровня или загружаешься с сохраненной игры и пробуешь снова. Ты не теряешь пройденные уровни, у тебя нет количества жизней, как в аркаде. Так что мы убрали жизни, убрали счёт и все предметы, дававшие очки.

Получается, что не было строгого плана. Всё постоянно пересматривалось. Вы что-то добавляете, потом понимаете, что это не работает, потом


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

Вы проверяли все это на ком-то или принимали решения внутри команды?


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

То есть вы показали её кому-то ещё только перед самым выходом?


У нас всё-таки было несколько тестировщиков со стороны, так как не было своих. Мы посылали игру им на проверку. Эти люди сотрудничали с нами много лет. Потом они рассказывали нам об обнаруженных проблемах. Если что-то всплывало.

Их замечания касались только найденных проблем, а не идей, да?


Чего угодно. Они делились с нами всеми своими соображениями. Обычно они находили ошибки, которые мы уже обнаружили и исправили. Круто, если им удавалось заметить баг, который мы пропустили. Это случалось редко, потому что мы играли постоянно, тысячи раз, так что мы видели всё.

Правда, что для создания текстур вы сканировали сапоги из змеиной кожи и содранные коленки? Что там за история с этим?


Да! В DOOM много чего отсканировано и оружие, и Думгай, и Кибердемон, и Барон ада. Все это отсканированные 3d-модели, которые мы создали

Постой-ка, 3d-модели? В девяностые? Ты о чем?


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

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

Все это делалось внутри компании? Все эти ребята сидели там?


Их было только двое, два художника.

Правда, что после выхода DOOM люди увольнялись с работы, бросали университеты, школы, колледжи и целыми днями играли? Это правда?


О да, это был невероятный хит.

Ты не чувствуешь себя виноватым?


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

Вы сами играли после релиза?


Да, постоянно играли.

Но вы ведь сотни раз играли в процессе разработки


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

Значит, игре нет конца


Угу.

Вы сидели в одной комнате или использовали локальную сеть побольше?


У нас в компании была своя сеть, каждый был к ней подключен, так что все могли играть. Это была проводная сеть, поэтому скорость была отличной. Если я хотел поиграть с Шоном [Грином], который сидел за стенкой, в соседнем кабинете, то он просто заходил в игру, мы подключались и звонили друг другу по телефону, чтобы удостовериться, что оба подключены.

По проводному телефону, да?


Ага, по проводному телефону.

Кто играл лучше всех? У вас в компании были чемпионы?


Да, я. У нас было не так много людей, наша компания была очень маленькой. Играли в основном я, Американ [Макги] и Шон [Грин]. Остальные почти не играли. Они играли, только чтобы убедиться, что их текстуры работают правильно, дизайн работает, но смертельный бой их не интересовал. Играло только три человека, потому что всего в компании нас было восемь, включая секретаря девять, включая Американа.

Расскажи о смертельном бое, потому что на твоей вики-странице написано, что ты отец этого слова. Как это случилось?


Как только нам удалось запустить многопользовательский режим, где можно было видеть другого персонажа на экране и стрелять в него, мы сразу поняли: именно этим мы и будем заниматься. Мы уже не просто стреляли по монстрам, мы могли убивать других игроков ракетами настоящее веселье. Ты будто бьешься на ринге, ты не можешь покинуть уровень, но смертельная схватка звучит гораздо круче. Это бой не на жизнь, а на смерть. Это смертельный бой!

Итак, представим, что сегодня 10 декабря 1993 года. Игра только что вышла. Что ты чувствуешь?


Мы страшно устали, мы работали 30 часов, начали накануне, а загрузили игру в два часа дня. Мы просто Некоторые уже спали, лежа на полу у них кончились все силы. Джей, наш генеральный директор, смог выспаться, потому что он не занимался программированием. Так что он чувствовал себя хорошо и был готов разобраться с загрузкой игры. В два часа дня ее загрузили на ftp-сайт Висконсинского университета и на BBS с программным обеспечением в Массачусетсе, чтобы люди, использующие BBS и модемы, могли загрузить игру оттуда, а пользователи интернета могли скачать ее с университетского сайта. Как только игру выложили, мы все пошли домой спать и проспали до следующего дня. Мы невероятно устали. Но мы знали, что игру ждет успех.

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


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

Всё-таки кое-что ты в финансах понимал


Ага. Кстати, Quake мы выпустили в июне, как только доделали. Это произошло летом, а лето самое плохое время для продажи игры.

Одна из причин огромной популярности DOOM возможность создавать моды


Вам не было страшно? Вы не боялись, что люди создадут что-нибудь безумное?

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

Нужно будет обязательно заценить.


Да, заходите на doomworld.com.

Кстати, перед этим интервью мы связались с самым популярным геймерским сайтом в российском интернете


Он называется Канобу, они подготовили список вопросов путем голосования

Итак, первый вопрос: тебе правда нравится DOOM 2020 и DOOM 2016?


Да, я играл в обе игры, они отличные, просто супер. Я очень рад, что DOOM осовременили, потому что нельзя просто взять и воссоздать оригинал. Они сделали именно то, что нужно было сделать для современной аудитории.

Где стримы, Джон? :)


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

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


Наверное, стоит попробовать [смеется].

Ты планируешь какие-нибудь неофициальные дополнения для DOOM 2 или, может, для SIGIL?


Да, SIGIL это эпизод, который я сделал на 25-летнюю годовщину DOOM. Это пятый эпизод DOOM. Круто, что софту он понравился и его официально добавили в DOOM. Так что если у вас есть DOOM на Switch, на айфоне или на приставке, то у вас есть и SIGIL. SIGIL один из редких эпизодов для DOOM I. Обычно дополнения и новые уровни разрабатывают для DOOM II, но в честь юбилея я решил выпустить эпизод для оригинальной версии.

Ещё какие-нибудь дополнения планируешь?


Да! Не могу сказать, что именно я делаю, но планирую кое-что сделать.

Ты сказал, что играешь, но не стримишь игры с друзьями. Речь идет об играх, которые разработал не ты? Расскажешь, во что ты любишь играть?


В основном в Ghost Recon Breakpoint, иногда в Wildlands.

Сколько часов в неделю ты играешь?


Играю где-то раз в неделю по 6 часов вместе с другом. Начинаем где-то в 9 вечера, а заканчиваем в 3 часа ночи или позже.

Будет ли переиздание Daikatana? Текущая версия очень далека от того, что ты планировал изначально


Я не собираюсь перевыпускать Daikatana. Проблема в том, что эту игру практически уничтожили во время релиза еще в 2000 году. Так что 20 лет назад люди просто Столько статей написано о том, насколько она плоха. У нее и в самом деле много недостатков. У этой игры такая плохая репутация, что мне незачем тратить время на ее перевыпуск.

Насколько для тебя важно то, нравится ли твоя игра людям или не очень?


Сколько радости испытываешь от того, что делаешь игру для себя, а сколько от того, что люди в восторге от твоей игры?

В идеале ты делаешь игру для себя и людям она нравится. Если ты вкладываешь много времени и сил в игру, которую любишь, тогда и людям она придется по душе. Когда я делал уровни для SIGIL, мне они очень нравились. Я потратил на них кучу времени, и, когда они вышли, многие были ими довольны.

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


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

Так, давай закончим с вопросами от Канобу. Это очень сложный вопрос [оба смеются].

Скоро выйдет Cyberpunk 2077. В ней показана модель будущего, которое ждет человечество



Что ты, Джон Ромеро, думаешь о будущем игровой индустрии через 30-50 лет?

Ммм, господи Ну, думаю, что-то должно произойти с приставками, потому что телефоны становятся все мощнее, в какой-то момент они заменят приставки. Думаю, что концепция Switch когда у тебя есть портативный девайс, который проецирует игру на большой экран показывает нам, как будут выглядеть игры для тех, кто предпочитает сидеть перед большим экраном с телефоном в качестве контроллера. Возможно, к телефону нужно будет что-то подключить, чтобы можно было быстрее нажимать кнопки. Sony и Microsoft сделают что-то в этом духе. Потому что телефоны настолько мощны, что, возможно, они выпустят телефон, который захочет купить каждый, и он заменит приставку. Ведь телефоны настолько мощные, что могут транслировать сигнал на экран телевизора с помощью беспроводной сети. Так что же делать, если все сидят в телефонах? Мобильные устройства это другой сегмент рынка, новая техника позволяет играть в крутые игры, в которые не поиграешь на телефоне, только потому, что экран слишком маленький. Так что, на мой взгляд, это совсем разные вещи сидеть на диване с контроллером в руках, глядя на большой экран, скажем, в 4K, и сидеть с телефоном, играя во что-то попроще.

Ты играешь в игры с Apple Arcade?


Я подписался на этот сервис, так что кое в какие играю.

Что посоветуешь?


Grindstone, наверное, я в нее еще не играл, но я знаю, что она хороша.

Круто, спасибо, и второй короткий вопрос. У тебя есть Switch?


Да, обожаю Switch. Раньше я много играл в The Legend of Zelda. Мне страшно понравилась Breath of the Wild. Играл в Animal Crossing: New Horizons. Но сейчас у меня мало времени на игры.

Над какими проектами ты сейчас работаешь?


Прямо сейчас работаю над игрой Empire of Sin. Мы разрабатываем ее уже больше трех лет. Она должна выйти в этом году. Можете просто зайти на empireofsingame.com, посмотреть видео и вы увидите, что это стратегия о мафии 1920-х годов.

Ты все еще работаешь по ночам?


Да, конечно [смеется].

Стоит ли ждать от тебя шутер?


Надеюсь!



Если вам не хватило общения с Джоном, можно посмотреть наше предыдущее интервью с Ромеро Упрости и вырежь необходимое, где вопросы задавал управляющий партнер RUVDS ntsaplin



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма

Подробнее..

Анонс спикеров на сентябрь

06.09.2020 18:16:25 | Автор: admin

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

Итак, встречайте спикеров сентября!

Путь от джуна до исполнительного директора в Сбербанке




Алексей пришел в Сбербанк в 2014 году на позицию Junior-разработчика. Сейчас он исполнительный директор: Product Owner и Teamlead платформенной команды Sberbank Investor и занимается МП Сбербанк Инвестор и Школами Разработки Сбербанка.

Леша расскажет на примере своего пути: как расти и развиваться в крупной компании, каких ошибок стоит избегать и как инициировать изменения. Поговорим про вызовы и возможности, про work-life balance, про то, как не выгореть и вернуться, если все же выгорел.

7 сентября, в 20:00



Как Data Science продает вам рекламу




Никита закончил ФКН ВШЭ, во время последнего курса получил стипендию Эразмуса и съездил на семестр по обмену в Финляндию. Несмотря на то, что он получил оффер на работу в Токио, Никита решил поступить в магистратуру университета Аалто, но не закончил ее и ушел работать дата-сайентистом в Unity Ads, где улучшает алгоритмы конверсии.

Никита расскажет о том, как устроен IT-рынок Финляндии, что там есть интересного и какие задачи решают дата-саентисты в Unity.

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

14 сентября, в 20:00



Вечер теплых ламповых историй с Робом Аткинсом одним из создателей легендарных игр от Duke Nukem до Counter Strike




Роб в гейм-индустрии уже больше 23 лет, за его плечами работа над такими проектами, как Quake, Duke Nukem, Tomb Raider, Counter Strike. Он участвовал во многих сторонах создания игр, от маркетинга до разработки. Работал плечом к плечу с Джоном Ромеро, Томом Холландом и Ричардом Левелордом Греем. Поэтому мы просто не могли не попросить его рассказать свои любимые истории о коллегах, работе и создании легендарных игр.

Сейчас Роб является CEO собственной компании Balanced Media Technology, которая создает игры и объединяет вычислительные мощности игровых устройств геймеров для их использования в вычислениях в области медицинских исследований.

21 сентября, в 20:00



Как я переехал в Лондон с Revolut




Мы не могли обойти стороной одну из самых популярных тем выступлений: IT-эмиграцию и переезд.

Дмитрий продуктовый разработчик, он решает продуктовые задачи в Revolut, являясь при этом Senior Backend разработчиком. Полтора года назад он переехал в лондонский офис и готов поделиться историей, как это происходило, как проходит карантин в UK, а также несколькими инсайдами о том, как устроен один из самых интересных финтех проектов.

28 сентября, в 20:00



До встречи в эфире!

Подробнее..

Мечтают ли голосовые ассистенты о электропоэзии? Интервью с Татьяной Ландо лингвистом-аналитиком Google

13.09.2020 14:09:40 | Автор: admin

24 августа мы поговорили в прямом эфире с Татьяной Ландо, лингвистом-аналитиком в Google. Татьяна работает над Google-ассистентом и занимается проектами между продакшеном и рисерчем. Она исследует, как люди разговаривают друг с другом и какие стратегии используют, чтобы использовать это в обучении ассистента более человеческому поведению. В Google пришла работать над ассистентом для русского рынка и русского языка. До этого 8 лет работала в Яндексе. Занималась лингвистическими технологиями, извлечением фактов из неструктурированного текста. Татьяна одна из основателей конфернции AINL: Artificial Intelligence and Natural Language Conference.

Делимся с вами расшифровкой эфира.




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

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

До того, как переехать в Лондон и начать работать в Google, я 7.5 лет работала в Яндексе, где тоже занималась компьютерной лингвистикой. Задачи, которыми я занималась в Яндексе, покрывали довольно широкий спектр задач компьютерной лингвистики. Мы занимались морфологией, синтаксисом то, как слова изменяются, то, как слова сочетаются; русский язык в этом плане сложнее английского, так как в английском нет падежей, есть только две формы существительных, все сравнительно просто (в русском 6-9 падежей, странное образование множественного числа ну, все носители языка знают эти особенности). Поэтому, когда я перешла в Google, меня взяли как специалиста по русскому языку, хотя теперь я уже занимаюсь другим.

Есть ли вакансии, связанные с разработкой русской версии Google-ассистента? Как попасть к вам на работу, связанную с Google-ассистентом?


Специальных вакансий, связанных с русской версией Google-ассистента, нет. Google старается разрабатывать методологии, направленные на максимальное количество языков сразу, и специфика языков должна решаться с помощью данных, а не с помощью специальных методологий. То есть, алгоритмы для русского, английского, немецкого, китайского всех поддерживаемых языков сделаны одинаково, хотя и с нюансами. Там очень много общих частей, и люди, которые занимаются определенным языком, в основном следят за качеством данных и добавляют специальные модули для отдельных языков. Например, для русского и других славянских языков нужна морфология (это то, о чем я только что говорила падежи, образование множественного числа, сложные глаголы). А в турецком языке еще более сложная морфология если в русском языке только 12 форм существительных, то в турецком намного больше. Поэтому нужны какие-то специальные модули, которые обрабатывают языкозависимые части. Но это делается с помощью лингвистов, которые знают свой родной язык, и языковых инженеров широкого профиля, которые пишут алгоритмы с помощью данных; мы вместе работаем над качеством этих алгоритмов и данных. Соответственно, специальных вакансий для русского языка у нас нет, но есть вакансии в разработке Google-ассистента, в основном, в Цюрихе, в Калифорнии, в Нью-Йорке, совсем немного Лондоне.

Почему Лондон, а не Европа или США?


4 года назад, когда я переезжала, Лондон все еще был Европой. Собственно, он и сейчас Европа, хотя и не ЕС. Мне очень нравится Лондон, все говорят по-английски, не нужно учить другой язык. Не то чтобы мне не хотелось учить другой язык, но вхождение в переезд было минимальным. Еще здесь отличные театры, я очень люблю ходить в театр. Конечно, сейчас этот все плюсы Лондона с культурой и развлечениями несколько нивелируются, но будем надеяться на лучшее. К тому же, с визой здесь гораздо проще, чем в Цюрихе в Швейцарии почему-то регулярно меняется визовое законодательство. Оказалось гораздо проще посадить меня и еще нескольких ребят в Лондон, и мы тут осели. Мне здесь нравится, никуда не хочу переезжать. Командировки в Калифорнию меня вгоняют в тоску там нужно брать машину, огромные расстояния. Хотя карьерных возможностей там больше.

Сложный ли русский язык?


Он сложнее, чем английский. Собственно, почти все языки сложнее, чем английский. У этой сложности есть две разных стороны. Во-первых, та самая сложная морфология. Кроме того, в русском языке свободный порядок слов, что усложняет работу при построении алгоритма. Если он фиксирован, то для условного мама мыла раму нужно одно предложение, чтобы научить систему понимать подлежащее-сказуемое-дополнение. Но если эти слова могут стоять в любом порядке, данных нужно больше. При этом для английского языка есть очень много готовых ресурсов; весь научный мир занимается английским языком, все корпорации занимаются английским языком, потому что конкурируют на американском рынке. А другими языками занимаются гораздо меньше, там меньше финансирования, меньше компаний. Если для немецкого или французского еще есть готовые куски или готовые данные, которые можно переиспользовать, то с русским языком хуже. Готовые корпуса есть, но они небольшие и не для всего подходят. То есть, данных для русского языка требуется гораздо больше, чем для английского, но их меньше доступно. Плюс дополнительные грамматические слои; ту же морфологию можно пытаться понимать отдельно, тогда можно сократить количество данных, которые нужны для качественной работы парсера на русском (по сравнению с английским).

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

Может ли компьютерная лингвистика восстанавливать непонятные места, например, в переговорах пилотов с землей?


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

Расскажите про акустику и очищение звукового сигнала в голосовых ассистентах


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

Какой язык самый сложный в плане обработки и понимания?


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

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

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

Почему для русского языка мало данных?


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

Я не знаю. Может, в русской науке просто мало денег, и поэтому для русского языка делается мало данных. Конференции в России в целом немного устаревшие; есть конференции по прикладной лингвистике, по автоматической обработке естественного языка, но очень мало больших коллективов, которые этим занимаются. Ученые уходят в большие компании Яндекс, ABBYY, сейчас МТС тоже нанимает лингвистов; профессия стала более востребована с появлением голосовых ассистентов. За рубеж тоже уезжают; лингвистов много в стартапах, в Amazon и Google.
Единственный большой корпус это Национальный корпус русского языка. Есть еще корпус, который сделали мои приятели Открытый корпус русского языка; но, в целом, под это очень сложно получить финансирование, и это мало кому интересно.

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

Какой подход в обработке языка больше используется Google? Нейросети или алгоритмы?


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

Самые исторически старые подходы это подходы, основанные на правилах. Лингвисты руками пишут правила, практически как язык программирования. Допустим, в воспринимаемом тексте сначала стоит подлежащее, потом глагол, потом сказуемое; если сказуемое в одном падеже, тогда один вывод, и так далее. Например, для случаев, когда пользователь говорит что-то вроде окей Гугл, поставь будильник на 7 утра, можно сделать такое правило: поставь любое слово будильник на цифра утра. Это шаблон, который можно описать и научить систему: если ты применяешь такой шаблон, и он срабатывает, то надо поставить будильник на указанное в виде цифры время. Конечно, это очень примитивный шаблон, можно делать гораздо сложнее. Они могут комбинироваться: например, один шаблон извлекает дату и время, потом поверх него пишется шаблон для установки будильника.

Это очень старый подход, ему лет 70 уже так была написана Элиза, первый чат-бот, притворявшийся психоаналитиком, в 1966 году. Тогда люди очень удивлялись. Ходили байки, что создатели этого чат-бота показывали его коллегам, и те выгоняли их из комнаты, чтобы поговорить с настоящим психоаналитиком. И этот бот был написан только на правилах тогда это был прорывной подход. Сейчас, конечно, мы не хотим так делать, потому что правил нужно очень много представьте, сколько разных фраз можно использовать только для того, чтобы ставить будильник, при использовании чистых правил приходилось бы описывать каждую из них вручную. Мы давно перешли на гибридные системы: они могут воспринимать шаблоны, но в целом мы стараемся использовать нейронные сети для машинного обучения и применять supervised-подходы к обучению с учителем. То есть, мы размечаем данные и говорим: ок, в этом массиве того, что может сказать пользователь, эта часть время, и она нормализуется так-то; эта часть девайс, на котором пользователь хочет поставить будильник, а эта допустим, имя будильника. Чтобы можно было конкретно на iPhone поставить будильник на 7 утра с названием Школа. Дальше мы задаем большой корпус, обучаем на нем парсер, дальше парсер применяется к запросам пользователей, и мы таким образом их распознаем. Так сейчас работает Google-ассистент, и такой подход мы сейчас используем.

Это звучит примитивно, сейчас в литературе и новостях часто проскакивает информация про то, как нейронные сети обучаются сами на огромных корпусах, на все отвечают и поддерживают беседы. Это, конечно, так, и это классно, но подобные подходы бесполезны в случаях, когда нужно, чтобы система не только ответила, но и изменила свое состояние хотя бы с установкой будильника. Все равно требуется внутреннее представление, к которому надо как-то привести то, что сказал пользователь. Даже если у нас будет огромный массив текстов, в которых пользователь просит поставить будильник, и он не будет размечен, то мы не сможем так обучить парсер, чтобы он менял систему. Мы сможем обучить его так, чтобы он впопад ответил Да, я ставлю будильник и ничего не сделал. Но обучить систему так, чтобы она меняла свое состояние, с использованием неразмеченных данных, пока невозможно. Поэтому то, что недавно выпускали OpenAI и DeepMind часть Alphabet, родительской компании Google это круто, это хорошие методики для чат-ботов, которые отвечают человеку, но методик, исключающих ручной труд для изменения состояния системы, нет. Поэтому, к сожалению, сейчас в индустрии довольно низкие стандарты в этом смысле применительно не только к Google-ассистенту; все ассистенты работают на приблизительно одинаковых подходах с большим количеством ручной работы либо по обработке данных для парсеров, либо по написанию правил (чего мы не хотим делать). Ручную работу мы стараемся делать с помощью партнерских компаний.

Расскажите о перспективных направлениях в разработке Google-ассистента.


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

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

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

Отдельно стоит гибридное изучение, которым я занимаюсь больше всего сейчас в последний год я перешла с русского языка на эту тему. Я занимаюсь проектами по тому, как сделать Ассистента более разговорным, более естественным. Мы смотрим, как люди разговаривают друг с другом. Здесь важно не только то, какие слова используются (поставь/сделай будильник); собственно, эта части примитивна и уже решена, хотя осталось доделать много рутины. Нерешенные задачи это, например, когда пользователь говорит в разных формах: Поставь мне будильник, Можешь поставить будильник?, Ты не мог бы поставить будильник?. Примерно одно и то же, но в одном случае применяется команда, в других вопросы. Мы смотрим на этот уровень лингвистики прагматику, то есть то, что идет над смыслом семантикой. Для тех, кто занимался лингвистикой или языком, семантическая разметка в тексте это не новый термин, но прагматика добавляет к ней дополнительный контекст; то есть, не только что говорят, но и как говорят, зачем говорят. Грубо говоря, если пользователь говорит ассистенту ты что, глупый?, он не хочет ответа да/нет это другой сигнал, и надо спросить, что до этого было не так в поведении системы; это надо классифицировать не как вопрос, а как жалобу.

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

Как насчет количества переспросов и выходов на заглушки по отношению к вопросу в постановке задачи?


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

В общем очень много маленьких фишек, которые сложно учесть в количественных измерениях.

Существует ли промежуточный, общий язык для упрощенной обработки с последующим переходом на нужный язык?


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

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

Можете ли вы привести примеры задач, над которыми работаете в Google? Какое процентное соотношение интересных и рутинных задач?


Когда я запускала русского Ассистента, было очень много рутинных задач просто потому, что алгоритмы универсальны, и большая часть работы сводилась к ручной правке багов и подготовке данных русского языка. Мы проверяли качество, иногда руками писали данные; это звучит очень грустно, но мы не могли использовать пользовательские данные, а брать их откуда-то надо было. Для того, чтобы взять данные, можно было еще написать правило и сгенерировать данные; или открытые данные. Из интересного можно было разбираться с морфологией, смотреть, чтобы генерация и понимание текста были поумнее и не нужно было в столбик выписывать все формы слова будильник. К сожалению, было очень много циклов прогнать-посмотреть качество-исправить-снова прогнать-исправить данные-и так далее; поначалу это было весело, но быстро стало рутиной. Сейчас, так как я больше в research (исследованиях), мы сами себе составляем повестку, в некотором смысле. Я занимаюсь как раз созданием новых данных, которые в будущем могут быть полезны для метрик, и исследованием того, как люди разговаривают друг с другом и с ассистентами, чтобы понять, какие сигналы можно использовать для обучения моделей. Мы анализируем качество. Часть работы, которой я сейчас занимаюсь продуктовая, мы пытаемся создать дорожную карту проблем в диалоговых взаимодействиях между человеком и ассистентом, понять, как это расклассифицировать, понять, что мы можем решить сейчас, что потом. То есть, сейчас у меня рутинных задач почти не осталось, и я довольна своим сетапом.
У разных лингвистов этот баланс выглядит по-разному. Недавно у нас был юбилей 100 лингвистов в компании, сейчас уже немного больше. Это круто, потому что, когда я приходила в компанию 4 года назад, нас было человек 30. Наша востребованность однозначно растет.

Используете ли вы определение контекста для анализа текстов?


Я не знаю, смотрит ли еще автор вопроса переформулируйте, пожалуйста, я не поняла.
Конечно, мы используем контекст; без него не бывает никакого диалогового взаимодействия. Конечно, мы пытаемся решать проблемы, чтобы пользователь, например, не каждый раз говорил будильник, а мог использовать естественные местоимения (поставь будильник на 7, нет, поменяй его на 8). Для английского это уже хорошо работает; не помню, запустили ли уже для русского.

Почему не запущена колонка для русского языка?


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

Есть ли открытые библиотеки распознавания и генерации речи, массивы данных для тренировки нейросетей? Насколько эта технология открыта?


Да, полно открытых алгоритмов. Google выпустил недавно Bert это супер-новая библиотека; теперь конференции полны апдейтов к ней, которые называют разными смешными словами, внутри которых есть Bert (Albert). Это все open source, сделали наши прекрасные ученые в Берлине. Можно тренировать что угодно; в научных сообществах есть данные, на которых можно тренировать нейронные сети и смотреть, что получается. Как я уже говорила, для русского этих данных мало, для английского больше, поэтому все развлекаются с ним.

То есть, у вас нет текстов пользовательских логов?


Мы не можем читать пользовательские логи. Единственное исключение это те случаи, когда пользователи жалуются, и у них специально запрашивают разрешение на то, чтобы расшарить последние столько-то высказываний. Но даже в таких случаях мы видим только пересказ проблемы от специально обученных саппортов и агрегированную статистику вида ассистент ответил, что не понимает, такой-то процент раз. Google очень внимательно относится к пользовательским данным. Часть того, чем занимается моя команда это как раз думать над тем, как можно было бы генерировать реалистичные данные или собирать их со специально оплаченных людей. Это важное направление для всех индустриальных команд, потому что privacy ни в коем случае нельзя нарушать. Нам приходится искать новые методы сбора данных, писать новые инструменты; последние полгода я довольно плотно занимаюсь этим. К сожалению, детали пока не подлежат публикации. Мы хотели написать статью для конференции, но эпидемия помешала. Когда ты работаешь в компании, статья тебе, в принципе, нужна только для того, чтобы за счет компании поехать на конференцию и потусить. А теперь все конференции перешли в онлайн, и потусить не получится реально пропала мотивация писать статью. Сейчас вот эпидемия закончится, и мы все-таки это сделаем.

Можете рассказать, как проходит собеседование в вашу команду, и показать примеры тестовых заданий?


Тестовых заданий не буду показывать, но рассказать про собеседование могу. Как я говорила, у нас сейчас 100 лингвистов, и собеседования теперь проходят в известном инженерам формате собеседование в пул. Мы подряд собеседуем лингвистов, и, когда есть хороший лингвист, смотрим, где есть вакансия, и распределяем по командам. У нас есть лингвисты разных профилей; кто-то программирует, кто-то практически не программирует. Я из второй категории: я больше в исследовательской части, модели я сама не тренирую в команде есть ребята, которые этим занимаются. У нас сейчас 8 команд лингвистов разного размера, и еще есть команда интернализации, в которой я была специалистом по русскому языку: это люди, которые следят за качеством ассистента (сейчас я просто лингвист-исследователь и занимаюсь задачами, не связанными с конкретным языком). В зависимости от своего профиля, лингвисты попадают в одну из этих команд.

Там, где задачи под конкретный язык, нужны носители конкретных языков; они получают специальные задания по этому языку мы пытаемся выяснить, хорошо ли человек понимает особенности. Например, если бы мы нанимали на позицию с русским языком (сейчас её нет, правда), мы бы спрашивали, чем русский сложнее английского, какие существуют методы преодоления этих сложностей, как устроена русская морфология, что нужно чтобы компьютер это понимал, как это влияет на объем данных. Если роль общая, то мы будем спрашивать про то, насколько человек хорошо понимает текущие реалии лингвистики, насколько он может обдумывать алгоритмы. Хотя я сама почти не программирую, я хорошо понимаю, как устроен Machine Learning, что нужно, чтобы тренировать систему, про сигналы, supervised / unsupervised learning и так далее. Собственно, это то, что я обычно спрашиваю на собеседованиях. Самый банальный пример: Как бы вы сделали исправление опечаток? Есть бесконечное количество денег и разработчиков, но продукта еще нет как построить его с лингвистической точки зрения, какие будут шаги? В целом, можно спрашивать про любой компонент, который включает в себя естественный язык. Как он построен, по мнению опрашиваемого? Как человек собирается строить аналогичный, какие проблемы видит? Как перенести опыт с английского языка на китайский, с китайского на русский, с русского на хинди? Как он будет выстраивать работу с языком, которого он не знает? Вариантов очень много.

Мониторите ли вы пользовательское поведение: какую команду дал пользователь, какое действие выполнилось устройством?


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

Каким образом отслеживается контекст беседы? Много ли для этого используется памяти? Есть ли персистентность между сессиями?


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

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

Сейчас мы умеем понимать местоимения внутри одной сессии (поставь будильник, сделай его на 8 утра). Мы работаем на тем, чтобы расширить этот контекст, и отдельно ведем исследования, чтобы понять, какой контекст полезен, сколько его нужно, где и сколько его хранить. Конечно, у Google много серверов, поэтому экономить нам не нужно, но хочется, чтобы ассистент не обрабатывал каждый запрос по 3 часа. Сейчас он довольно быстр, но работает не идеально; и, если мы сделаем его идеальным, хотелось бы, чтобы он продолжал работать быстро.

Есть ли у вас конкуренция между командами?


И да, и нет. Конечно, по тому, как устроена работа внутри Google, можно делать отдельный эфир. У нас много инициативы на местах; люди могут пробовать делать прототипы чего угодно, предлагать это начальству начальство всегда очень открытое, и оно будет предлагать высшему начальству. Довольно много проектов возникает из того, что кто-то что-то попробовал сделать, у него получилось, и было решено делать в качестве, пригодном для выпуска. Конечно, бывают ситуации, когда в 5 местах одновременно людям приходит одна и та же идея в голову, и получается 10 прототипов. В такой момент иногда приходится выбрать какой-то из прототипов, но обычно стараются объединять людей в команду, чтобы они могли вместе разработать новую фичу, выпустить в продакшн, и все были довольны.

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

Что быстрее произойдет сделают умный голосовой ассистент, который будет понимать не хуже человека, или Илон Маск изобретет нейроинтерфейс?


Я ничего не знаю про то, на какой стадии находится нейроинтерфейс. Но умный голосовой ассистент, который будет понимать не хуже человека это еще очень нескоро. Пока никто не понимает, как сделать так, чтобы ассистент понимал. Все болталки на мощных нейронных сетях это имитация. Я видела вопрос про тест Тьюринга это же тоже тест на имитацию, на то, насколько система хорошо притворяется человеком и притворяется, что она понимает, но ведь ни одна система ничего не понимает. Был чат-бот Eugene Goostman, который выиграл один из тестов прошел какой-то процент судей, которых нужно было обмануть. Он притворялся 15-летним мальчиком из Одессы с папой-гинекологом и морской свинкой (не шутка он про себя это рассказывал). Бот чуть-чуть держал контекст, спрашивал: Вы откуда? и запоминал город из ответа, а потом использовал запомненное через какое-то время, вызывая вау-эффект. Хотя сейчас вызвать вау-эффект с голосовыми помощниками не слишком сложно; они не идеальны. Кроме того, так как конкурс был на английском языке, шероховатости в речи бота списывались на то, что он из Одессы в мальчика-иностранца верили.

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



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
  14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
  15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности



Подробнее..

Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым

19.09.2020 12:19:21 | Автор: admin

7 сентября мы поговорили в прямом эфире с Алексеем Левановым, исполнительным директором в Сбербанке. Леша пришел в Сбербанк в 2014 году на позицию Junior-разработчика. Сейчас он исполнительный директор: продакт и тимлид платформенной команды Сбербанк Инвестор и занимается МП Сбербанк Инвестор и Школами Разработки Сбербанка. Леша рассказывал на примере своего пути: как расти и развиваться в крупной компании, каких ошибок стоит избегать и как инициировать изменения. Поговорили про вызовы и возможности, про work-life balance, про то, как не выгореть и вернуться, если все же выгорел. Делимся с вами расшифровкой эфира.



Меня зовут Алексей Леванов. Мы поговорим о том, как в сфере IT, как мне кажется, стоит строить свою карьеру тем, кто находится в начале пути. Я расскажу то, что мне удалось узнать, и подсвечу ошибки, которые я делал. Может быть, через такую призму это будет восприниматься чуть ярче. Я бы хотел, чтобы наше общение помогло вам расти в большой компании, не перегорать и двигаться в светлое завтра.

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

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

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

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

Сделаем ремарку. Все говорят про хард/софт скиллы, и на этот счет есть много разных мнений. Я считаю так: если вы в начале карьерного пути (только начинается ваша история как разработчика ПО или вообще как IT-специалиста) делайте упор на хард скиллы. Вышеописанные принципы будут работать, если вы хороший специалист. Вы можете быть хорошим человеком, обладать эмпатией и развитым умом, даже стараться доводить дела до конца и быть стрессоустойчивым; но, если вы не делаете руками то, что должны делать тоже грош вам цена, как специалисту. В дальнейшем, с развитием, чем прокачаннее вы становитесь, тем большую роль начинают играть софт скиллы это правда. На определенном этапе они могут стать такими же важным, или важнее, чем хард скиллы. Но, если мы говорим о начале построении карьеры делайте упор на хард скиллы, без них никуда.

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

Вы исполнительный директор или product-owner (PO)?


Это разные вещи: одно это должность, а второе роль. По должности я исполнительный директор, а по роли product-owner и тимлид. То есть, одна вещь условно записана в трудовой, а вторая то, что я делаю.

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


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

Как много времени сейчас вы занимаетесь именно разработкой?


Хороший вопрос к этому я хотел дойти постепенно через историю. Если коротко примерно часа 3 в день уделяю разработке (код, проверка пулл-реквестов и так далее). Понятно, что есть рабочие встречи, которые отнимают время, есть условный бэклог или нарезка задач, но, в целом, разработку хардкорную никто не отменял, и это здорово.

Как взять ответственность product-owner и получить должность?


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

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

Насчет изменений. Я начал заниматься разработкой в далеком 2011 году, и меня помотало по разным темам. Сначала я писал под Android. Пришел я в разработку так: мы с другом увидели, что на Хабре периодически появляются статьи о том, как очередной человек разработал клон тетриса и заработал миллиарды; собственно, чтобы заманить студента, ничего другого и не надо. Я читал их и думал я в деле. Макбук появился у друга, поэтому вначале я писал на Android; прошло несколько фрилансов и несколько мест в других компаниях, и в 2014 году я пришел в Сбер. В этот момент у меня уже были приложения в AppStore, некоторые достаточно успешные, о них написали на Iphones.ru, AppleInsider; я заработал некоторое количество денег и думал, что это вершина мастерства и карьеры, а другие разработчики мне не нужны. Конечно, когда я пришел в команду разработки, я оказался в ней самым слабым, хотя потребовалась пара дней, чтобы это осознать.
Это было замечательное время. Все общение с бизнесом и другими специалистами шло через нашего project-менеджера, но среда была замечательной для того, чтобы расти. Когда ты один пишешь код, ты в какой-то момент решаешь, что все уже отлично; а потом ты узнаешь, что есть правильные подходы к разработке, паттерны, о которых ты даже и не думал. В среде крутых профессионалов растешь гораздо быстрее.

В какой-то момент наша команда начала не просто расти, а переходить в agile. До этого все разработчики были в одной команде. Это было здорово каждый работает над разными частями приложения; сегодня эта, завтра другая. Было сложно, но интересно. Я помню, что это был мой выпускной год, надо было делать диплом, отрабатывать практику и кое-как ходить на пары помимо полного рабочего дня. Это было сложно, я тогда подсел на кофе гляссе перед входом в офис стало утренним ритуалом. Тем не менее, это был невероятный опыт, было очень круто. Сама возможность работать над таким продуктом это было замечательно. Потом мы стали переходить в agile, и от платформенной команды, сконцентрированной только на разработчиках, мы перешли к команде, в которой были специалисты всех отраслей то есть, к кросс-функциональной команде. С одной стороны, это очень круто и интересно: у вас появляются коллеги смежных направлений, аналитики, дизайнеры, тестировщики, разработчики других платформ и мобильных операционных систем. Но от концепции вы делаете все приложение вы переходите к концепции вы отвечаете за направление в приложении, за какую-то часть. Чем дальше, тем больше таких частей: приложение растет, функционал дробится.

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

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

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

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

Бывает такая история, что вы хотели бы остаться в этой же команде. Вам нравится продукт, команда, у вас замечательный product-менеджер все хорошо, но только не хочется больше писать код распознавания номеров. В кросс-функциональных командах здорово то, что есть возможность переключиться и стать тем самым T-shaped-специалистом, о которых много говорят. Для вас это хорошо тем, что вы учитесь новому. Вы продолжаете развиваться в своей области хотя и чуть медленнее, изучаете смежные области и повышаете свою ценность как специалиста. Для работодателя тем, что уменьшается buzz-фактор.

T-shaped-специалист это эволюция I-shaped-специалиста, обладающего глубокими познаниями в одной определенной области. Допустим, человек учился в школе и решил стать программистом; нравится ему писать на C# или в Unity, допустим. Он не пошел в университет, но он стал экспертом в своей области, и делает игры. Он I-shaped-специалист; на работу его, скорее всего, уже возьмут. Если этот же человек изучит интеграцию с бэкендом, будет способен подключаться к различным вопросам хотя бы аналитически, будет смыслить в тестировании (наверно, в базовых основах авто-тестирования и написания тест-кейсов), то он будет T-shaped-специалистом. То есть, это человек, который может помочь в смежных компетенциях внутри кросс-функциональной команды.

Buzz-фактор это выдуманная метрика, которая показывает количество людей, которых можно куда-то далеко отправить на автобусе, но команда при этом продолжит хоть как-то работать. У идеальной T-shaped-команды он равен N-1 (N размер команды): даже если из такой команды останется один человек, он сможет продвигать работу вперед, пусть и очень медленно. Конечно, это предельный пример, такого в жизни почти не бывает; тем не менее, создание такой команды это хорошая практика.

Став T-shaped-специалистом, вы остаетесь в том продукте и с теми людьми, с которыми вам комфортно, вы продолжаете развиваться, и вашему работодателю это на руку, потому что вы закрываете узкие места проекта.

Хуже бывает ситуация, когда вы выгораете, не рассчитав силы. Допустим, вам очень нравится проект, вы горите им. Он очень интересен. Вместо того, чтобы понимать, что эта история долгая, вы пытаетесь ее пробежать в спринтерском темпе. На какое-то время вас хватает. Может быть, вы выгорите после финиша, но скорее на середине; и то и то плохо. В моем случае мне безумно нравился продукт, над которым я работал; меня очень драйвило его создавать и видеть результат, но вот отдыхать у меня не получалось. Я как бы слышал про work-life balance, но он не действовал. Даже если вечером я оставлял незавершенную задачу и шел с девушкой в кино или с друзьями в бар, в мыслях я все равно оставался в задаче; вроде бы и время хорошо проводил, но не отдыхал по-настоящему, и задачу не делал. Поэтому я решил наплевать на work-life-balance и стал просто работать работал, работал, работал, а потом что-то щелкнуло. Очень повезло, что само явление щелчка произошло после завершения проекта и перед моим отпуском. Я уехал в отпуск, много думал, а, вернувшись, поговорил с руководителем сказал, что я сейчас не могу писать этот код. Руководитель у меня был замечательный; он спросил, чем бы мне было интересно заниматься.

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

Стандартные истории про выгорание говорят, что нужно полежать на пляже и посмотреть в небо, пока не отойдете. В моем случае помогло переключение сферы деятельности. С одной стороны я понял, что work-life balance все-таки работает; вернувшись из отпуска, я понял, что те задачи, над которыми я сидел, я могу делать быстрее с одной стороны. С другой стороны эта новая сфера оказалась безумно интересной, и мы сделали очень многое. Запустили новые направления программы, взяли новых людей, запустили партнерства с университетами, стали выдавать сертификаты об окончании успешный большой перезапуск. После этого я сумел вернуться в разработку, но вся эта история о том, что не надо доводить до крайностей. Если вы чувствуете, что что-то идет не так, что вы работаете больше, чем можете это не хорошо ни вам, ни работодателю. Вы у себя один, а для работодателя это сложно прогнозируемая история, непонятно, когда вы не сможете идти дальше.

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

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

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

Насчет того, нужно ли сейчас идти в мобильную разработку этот вопрос я слышу часто. То, о чем я рассказывают, актуально для IT в целом, но для мобильной разработки в частности. Вы можете сказать, что сейчас разработчиков слишком много, рынок насыщен и новые устройства не покупаются. Я скажу, что в среднесрочной перспективе это направление точно останется актуальным. Хотя количество смартфонов подходит к линии насыщения, впереди нас ждут носимые устройства; умные часы уже многие таскают я тоже, кстати. Я почти уверен, что крупные компании скоро выпустят что-то новое. Нас ограничивает емкость аккумуляторов, но она медленно растет последние N лет. Люди, единожды попробовав не сидеть на одном месте ради решения задач и решать их с помощью носимых устройств, мобильников и других средств, вряд ли вернутся к этому паттерну поведения. Количество устройств будет увеличиваться, и разработчиков будет требоваться больше. Если вы ощущаете, что мобильная разработка это ваше, то в нее стоит идти. Если вы уже состоявшийся разработчик, то вы сможете прийти к нам; нам состоявшиеся разработчики всегда нужны. А если вы хотите, но еще не умеете для вас открыты наши школы. Мы не смотрим на ваши знания Objective C / Swift / Kotlin / Javascript; мы смотрим на базовые вещи, вроде знания алгоритмов и структур данных, понимания принципов ООП, умения писать алгоритмы типа сортировки и объяснять их сложность то есть, на простые вещи, которые изучают в универе. Это та самая шляпка для T вам остается только получить хорошие знания.

Добавлю про университеты. Признавая и принимая проблемы высшего образования я все-таки 6 лет учился и 5 лет преподавал, будучи в аспирантуре я считаю, что ВУЗ, хотя и не обязателен, очень желателен. Хотя ВУЗ и не даст специфических знаний то есть, если вы захотите быть крутым DevOps-специалистом или разработчиком мобильных приложений, то вам придется самому получать нужные знания вы сможете получить, помимо базовых вещей (вроде стрессоустойчивости и желания получать новые знания) широкое знание того, что в IT происходит. Вы выйдете тем самым T-shaped-специалистом.

В конце сентября или в октябре у нас начнется новый набор. Приходите к нам, пишите мне; буду очень рад ответить на вопросы.

По идее, проект надо менять каждый год-два, иначе застой.


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

Насколько распространена практика у product-менеджеров устанавливать приложения конкурентов и брать оттуда идеи новых фич?


Напрямую такого не делается, но говорить, что банки и другие IT-игроки совсем не смотрят друг на друга, нельзя. Понятно, что они смотрят; но прежде, чем что-то копировать, надо провести исследования. Хотя бы понять: конкурент это сделал, подумав, или просто так выкатил? И вести собственные исследования, конечно. Прежде, чем продукт будет разработан, проходит несколько этапов от дизайн-мышления и построения CJM. Нужно понять, нужен ли этот продукт пользователю, какие проблемы он решает. А просто копировать эта история больше про инди-разработчиков, когда они решают, что могут скопировать и сделать дешевле что-то успешное. Крупные компании все-таки идут своим путем, хотя и смотрят друг на друга.

Возможно, что будущее за дополненной реальностью?


Возможно. Я сам тоже считаю так последние несколько лет тот же Apple на своих конференциях для разработчиков (WWDC) делает упор на AR Kit / Reality Kit, движки работы с дополненной реальностью. И все это выглядит как переход от простого MVP к добавлению надстроек на него. Пользоваться этим в телефонах пока неудобно, и стоит дожидаться более удобных форм-факторов.

Как в Сбере происходит перевод сотрудника на уровень выше?


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

Как часто вы проходите обучение и курсы?


Надо сделать ремарку: я начинал заниматься разработкой в то время, когда нормальных курсов, к сожалению, почти не было. То есть, я вижу два способа обучения разработке: мой и правильный.
Правильный это через курсы, школы разработки (хорошо бы наши, но может быть любая школа с наставником, съевшим в этой технологии пуд соли). А вот мой вариант просто биться головой об эту тему, делать ошибки, смотреть варианты на StackWorkflow. Это тоже рабочий вариант, ты будешь получать готовые продукты, но в голове останется каша, с которой потом придется разбираться.

Я до сих пор не очень люблю курсы. Это у меня пошло со школы из общеобразовательной я перешел в лицей информационных технологий, где было круто, но я не дотягивал по уровню. У нас в школе не было программирования, а в лицее оно уже подразумевалось. Под угрозой двойки я обложился книжками и стал разбираться; этот паттерн, собственно, и остался у меня. Я тяготею больше не к курсам, а к набору книг. Могу потом приложить в комментариях.
Сейчас я прохожу MBA-программу от Сбера, она включает в себя множество курсов: очных, заочных, виртуальных. Но все эти курсы объединены в единый продукт; чтобы самостоятельно выбирать какие-то направление и учиться в нем такого не было давно. Хотя я смотрю образовательные сессии с WWDC, больший упор у меня именно на литературу и статьи.

Какие мысли про Dart / Flutter, стоит ли тратить время?


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

MBA от Сбера что из себя представляет? Очное обучение внутри Сбера или во внешнем университете?


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

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

Достаточно ли внутренних курсов Сбербанка, или внешние тоже необходимы?


Это зависит от того, что вы хотите. Если нужно поддерживать свой уровень в том, чем вы занимаетесь (в разработке, допустим), то, во-первых, надо успешно решать рабочие задачи; во-вторых, комьюнити устроено так, что вы априори будете поддерживать свой уровень и развиваться, если захотите. В этом один из плюсов большой компании: это большое сообщество. Я сейчас не могу назвать другую компанию в России, где есть по 200 разработчиков на iOS и Android; такое комьюнити создает свою культуру наставничество, обучение. В целом, этого может быть достаточно: нужно тянуться к тем, кто впереди.

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

Удобно ли ездить в центр на работу и еще в Подмосковье в КоУ?


Ну, сейчас я нахожусь на удаленке так же, как и вся команда. Проблемы выезда из центра пока нет; когда мы выйдем с удаленки, я буду ездить в центр из Москвы. А в КоУ мы ездим не так часто: в рамках MBA-программы я бываю там примерно три раза в неделю.

Как много времени тратите сейчас на разработку, на каких языках?


Я сам разработчик мобильных приложений под iOS (изначально только iPhone и iPad, потом появились часы). Изначально мы писали на Objective C старом, с примесью 1.0, с использованием MRC). Сейчас у нас отдельный новый проект, в его рамках мы пишем на чистом Swift; то есть, MVVM с координаторами и сервисами, отсутствие реактивщины мы биндим все через делегаты. Насчет времени я уже говорил: стараюсь тратить побольше, но есть определенное количество важных рабочих встреч особенно на этапе старта продукта, поэтому получается часа 3-4 в день. Разработка мне все еще нравится, я стараюсь выкраивать, как могу.

Расскажите про Стэнфорд.


Однажды в рабочей почте было сообщение о том, что есть программа Stanford USRussia Forum, и сотрудники Сбербанка могут попробовать податься на нее. Я подался, прошел 3 или 4 этапа отбора, итоговое собеседование на английском, и попал в рабочую группу с еще тремя сотрудниками Сбера. Суммарно там каждый год 10-15 человек из России и 10-15 из Штатов. Программа направлена на улучшение взаимоотношений между странами; создаются смешанные группы из наших и американцев, которые работают над научными проблемами. Наш год был первым, когда появились конкретные технические проблемы: до этого были социальные и правовые вещи. Наша группа была FinTech (финансы и технологии). Год мы делали исследование, а потом защищали его в Стэнфорде. Были на ужине с профессором Зимбардо, который провел знаменитый эксперимент (к нему есть вопросы, но опыт-то классный). В целом, замечательный кейс, который позволял окунуться в другую сферу. Оставаясь в области финтеха, мы исследовали децентрализованные технологии на примере блокчейна, например, и встретились с кучей выдающихся людей, которые этим занимаются как в России, так и в Штатах.

Бэкендом не занимаетесь? Часто ли проводите собеседования?


Собеседования проводим часто. Я участвую собеседованиях как в Сбербанк-Онлайн, так и в новый проект Сбербанк-Инвестор. Плюс, когда речь идет о школах, в собеседованиях на прием и на выпуск я тоже стараюсь участвовать. В скольких именно зависит от нагрузки: может быть и 0, и 10 в неделю, но обычно 1-2. Бэкендом я не занимаюсь, но интересуюсь. Хотел бы попробовать, когда MBA завершится и станет больше свободного времени.

Как выбираете стек для разработки? Требования формирует заказчик?


Это зависит. Если мы говорим про отдельный модуль для Сбербанк-Онлайн, то стек ограничен существующим продуктом. Если продукт новый, то стек выбирает, наверно, не бизнес-заказчик, а IT-специалист, подсвечивая плюсы и риски для бизнеса. Например, если взять одну технологию она удобная, классная, быстра, но она отсечет некоторый процент аудитории. Итоговое решение примет, конечно, представитель заказчика, но стек формируют IT-специалисты. В целом, мы смотрим на то, чтобы стек был удобным, достаточно новым, но не хайповым; так, сейчас брать Swift UI на enterprise-проект преждевременно это не отменяет того, что нужно опробовать эту технологию, но она должна устояться. То есть, не надо брать то, что только вышло, хайпово и явно будет менять API в ближайшие несколько лет, а также то, что уже полумертво.

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

Что нужно, чтобы попасть в команду беспилотных автомобилей?


Надо просто подать заявку. Я видел вакансию в направление, связанное с беспилотными автомобилями, у себя в Facebook. Это не какая-то секретная информация; если организаторы потом передадут мне этот вопрос, я поделюсь ссылкой.

Что является Сбербанк-Онлайн, а что подпроектом?


Сбербанк-Онлайн например, на платформе iOS это проект, состоящий из подпроектов (подмодулей). За каждый из них отвечает команда или группа команд. Внутри себя они могут, не отходя сильно от гайдов разработки Сбера, некоторые вещи определять самостоятельно например, архитектурный подход внутри этого модуля. Важно, чтобы, например, API этого модуля все еще позволял к нему обращаться, но в остальном все, что происходит внутри него (если оно не идет вразрез с гайдами Сбербанк-Онлайн и базовыми подходами) остается на усмотрение его главных разработчиков. Из таких модулей и собирается итоговый проект.

То есть, все платежи и переводы это Сбербанк-Онлайн?


Да, всё СБОЛ. И кредиты, и депозиты. СБОЛ это большой дом из разных кирпичиков: процессов (например, оплаты) и продуктов (например, депозитов). И их разработка может идти параллельно.

Из СБОЛ можно зайти в Око?


Да, но вы попадете в другое приложение. Все, что внутри Сбербанк-Онлайн это одна история, это части Сбербанк-Онлайн; когда вы переходите в другое приложение, вы переходите в другую часть экосистемы. Например, из СБОЛ можно зайти в Око, Доставку посылок, Инвестиции; все это отдельные приложения из экосистемы Сбербанк-Онлайн. То есть, хотя они и самостоятельны, между ними осуществляется нормальная навигация, они интегрированы с СБОЛ, в часть из них можно заходить по универсальному Сбербанк-ID.

Как в Сбере запускается новый продукт, и как в нем стать PO? Например, если идея твоя не факт, что ты будешь PO.


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

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

Какие крутые книги посоветуете?


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



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
  14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
  15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
  16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению



Подробнее..

Радик Ананян Вычислительную машину я не видел, пока мы не сделали ее сами

25.08.2020 20:14:31 | Автор: admin

Радик Оганесович Ананян один из первых сотрудников открывшегося в 1956 году Ереванского НИИ математических машин. В интервью музейному проекту DataArt он вспоминает, как работал новый институт, как создавались первые ЭВМ и как снимался короткометражный фильм Короткое замыкание, выигравший первое место на кинофестивале в Москве.

На фото Радика Ананяна работники института с коллегами на демонстрации 1 мая 1960 года. Сам фильм Короткое замыкание и еще одна лента Радика Оганесовича ниже в статье.

Фотограф и радиолюбитель


Родился я в 1934 году в Ереване. В школьные годы увлекся радиолюбительством. У моего школьного товарища был сосед Сергей Шахазизян. Он тогда то ли в институте учился, то ли уже работал. Сергей мне и объяснил, как устроены радиолампы тогда все делалось на них. С Сергеем мы сдружились, наверное, я ему понравился своими техническими наклонностями. Потом он работал в Доме радио и первым придумал устройство, которое позволяло при выключении микрофона избежать щелчка. Никто не мог от этого звука избавиться, а он это сделал. Очень талантливый парень, его давно уже нет с нами.

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


Ереван в 1940-х, площадь Ленина, теперь площадь Республики

В радиолюбительский кружок вы не ходили?

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

Как в семье относились к вашему увлечению?

Нормально, наверное. Я всегда чем-то занимался, что-то чинил, строил.

Куда идти учиться после школы, вопросов не возникало?

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


Радик Ананян

Это был сложный процесс?

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

НИИ математических машин


Что было после того, как вы не поступили в архитектурный?

Отслужил в армии и пошел работать в Институт физики радистом. Затем, перешел в НИИ математических машин. Параллельно стал заочно учиться в МЭИ, а с 3-го курса перевелся на очное отделение Ереванского политехнического института на факультет кибернетики. Т. к. учился на очном отделении, пришлось работать на полставки. Тогда же я организовал любительскую киностудию.


Кадр из фильма Короткое замыкание, реж. Радик Ананян, Ереванский НИИ математических машин, 1967 г.

Получив диплом, вы вернулись к прежней работе в НИИ?

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

Когда вы перешли в НИИ математических машин?

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

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


Разработка ЭВМ Арагац велась во втором отдела ЕрНИИММ, 1958 г.

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

Расскажите о первых днях работы в ЕрНИИММ.

Большинство принятых на работу сотрудников сразу отправляли на стажировку в разные города Союза Пензу, Ленинград, Минск. В Пензе, например, был завод вычислительной техники, если не ошибаюсь, выпустивший М-3 одну из первых машин в СССР мы ее потом копировали. Те, кто не уехал набираться опыта, читали книжку японского автора Ицхоки Импульсная техника. Чем мы будем конкретно заниматься, тогда мало кто понимал. Потом мы получили первый осциллограф. Черный, большой. Позже появились маленькие, СИ-1.

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


Коллега Радика Ананяна Сурен Айрапетян собирает блок питания. ЕрНИИММ, 1960 г.

Когда вы впервые увидели вычислительную машину?

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


Восхождение на Арагац, 01.08.1958 г. Второй справа Радик Ананян

Архитектуру машины разработали в вашем институте?

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

Наш отдел занимался внешними устройствами. Колоссальное достижение большой куб на ферритовых кольцах (каждый бит), который мог хранить 4 килобайта.


Накопитель на магнитной ленте (НМЛ) для первых ЭВМ, ЕрНИММ, 1960 г.

Для памяти использовали два вида магнитных носителей магнитные ленты и магнитные барабаны. В дальнейшем применяли магнитные диски пензенского завода. Диски друг на друга ставились штук по 1020, смотря, какая конфигурация устройства, а магнитные головки между ними считывали и записывали. Когда начинались сбои, диск доставали и чистили спиртом. Под это дело командированные сотрудники все время у меня просили спирт. У меня было два вида нормальный спирт и технический. Когда нормальный кончился, говорю: Технический не дам отравитесь. Они: Если бы травились, половины бы завода уже не было! Оказалось, они его тоже пили.


Ячейка усилителя и формирователя ЭВМ Арагац. ЕрНИИММ, 1958 г.

Вы помните, как запустился первый Арагац?

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

Были нормативы по времени работы без перебоев?

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


В конструкторском бюро ЕрНИИММ, 1960-е гг.

Полупроводниковые машины тоже ваши собственные разработки?

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


Перед испытанием накопителя на магнитной ленте. Второй слева Радик Ананян, Ереванский НИИ математических машин, 1960 г.

ЕС ЭВМ


Ваш институт занимался и ЕС ЭВМ. Как это было? Координация шла из Москвы?

В то время по всем отраслям создавались головные институты. Головным по вычислительной технике для нас был НИЦЭВТ. Они заведовали всем хозяйством где что будут делать. Каждый институт в Союзе разрабатывал свою систему. На наш институт была возложена разработка средних машин: ЕС1030, ЕС1045.

За основу ЕС брали IBM. Они у вас были?

Нет, вначале мы исключительно книгами пользовались. Когда в СССР вышла книга IBM-360, в Армении ее сразу раскупили. Кроме нашего института, стали появляться другие организации, которые занимались вычислительной техникой и смежными отраслями. В 90-е все это грохнулось.


Торжественное заседание, посвященное 10-летию ЕрНИИММ, 1966 г.

Каким было отношение к проекту ЕС в Армении?

У нас его нормально воспринимали. Мы настолько отстали, что нужен был какой-то прототип. Невозможно было самостоятельно идти в этом направлении, не зная, что делается в Америке. У них прогрессивные технологии, мы вынуждены были их заимствовать. Это не только в вычислительной технике было во всех отраслях. Всегда у нас был девиз Догнать и перегнать. Но книга, которую у нас выпустили об IBM неполная. Некоторые главы остались для нас секретом. То есть сделать машину по ней было нельзя пришлось додумывать самим. Поэтому ЕС не идентичны IBM, переработаны в собственном соку, так скажем. Много изменений сделали наши ребята, естественно, к лучшему. Всегда, когда берешься что-то делать, стараешься, чтобы получилось лучше прототипа.

Когда вы занимались разработками, на каком языке велась документация?

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

Досуг и спорт



Каким был обычный рабочий день в институте?

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


Сотрудники ЕрНИИММ на демонстрации, 7 ноября 1959 г.

После сдачи перед отдыхом был праздник?

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

Каким еще был в институте совместный отдых?

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


Восхождение на Арагац, сентябрь 1958 г. Слева Радик Ананян

Был у нас и радиокружок учили азбуку Морзе, играли в Охоту на лис. Это такой радиолюбительский спорт. Каждый делал себе усилитель, который работал на направленную антенну. Лиса это передатчик, спрятанный где-то в горах и дающий сигнал через какой-то интервал времени. Ты его ищешь. На старте соревнований 1030 охотников, потом они разбегаются по разным направлениям, потому что у каждого прибор показывает свое. Кто первый найдет лису, тот выиграет.


В радиоклубе ЕрНИИММ, 1960 г.

Создание вычислительного центра


Почему вы ушли из ЕрНИИММ?

В 1976 году Совету министров Армении понадобился инженер, знакомый с вычислительной техникой. Меня рекомендовали туда на должность заведующего отделом. В то время в СССР организовывалась сеть Вычислительных центров. Головной Вычислительный центр правительства Советского Союза, также ВЦ стали открывать во всех республиках, потом во всех министерствах и разных крупных управлениях.

Сначала я был начальником пункта информации и связи. Потом создал отдел с этим пунктом и стал заведующим. Так и работал до 1993 года.

Когда вы перешли на новое место, работа оказалась заметно другой?

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

Т. е. у вас была модемная связь с московской машиной?

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

Что было после 1993 года?

Разочаровавшись во всех новшествах после развала СССР, я подал заявление и уехал за границу. С 2000 до 2004 года жил в Питере, потом еще 4 года в Канаде. Вернулся в Ереван и больше не хочу уезжать.


Ненужные блоки ячеек, 1963 г.

Первые персональные компьютеры



В монтажном секторе ЕрНИИММ, 1963 г.

Когда вы впервые познакомились с персональным компьютером?

Помню, купил сыну БК. Он без экрана, надо было подключать к телевизору и кассетному магнитофону. Клавиатура была своя, и больше ничего. Сын играл, когда был маленьким. Первые нормальные компьютеры мы получили в 1988-м, когда случилось землетрясение. Тогда нам все помогали, и фирма IBM прислала 10 современных компьютеров с принтером. Их распределили по большим городам в зоне землетрясения. Через них мы получали сведения по всем работам, касающимся восстановления страны.

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

Короткое замыкание и награды



С коллегами на демонстрации 1 мая 1962 г.

Как развивалась вычислительная техника в Армении времен СССР? Было что-то свое?

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

В заграничных командировках бывали?

Я нет. Один раз поехал из-за кино в Чехословакии был фестиваль по 16-миллиметровым фильмам.

Расскажите про киностудию в институте.

Я ее создал, потому что меня очень интересовало кино. Сначала в ней было три человека, потом немного больше. Маленьким коллективом снимали фильмы. Артист, которого вы видели в Коротком замыкании, работал у нас ведущим конструктором. Этот фильм мы сняли к 10-летию института, но он не был первым. Один из наших ребят был в Японии и оттуда привез 8-миллиметровый киноаппарат. На нем мы сняли фильм, который назывался Я, он, она. В нем тоже играли институтские работники. Сюжет такой. Человек в лотерею выиграл машину, абсолютно не понимая, как на ней ездить. Он пишет объявление, что ищет инструктора по вождению. Наш конструктор как будто безработный и немного аферист, который как бы все умеет, но не умеет ничего. Он говорит, что научит, хотя сам не знает, как ехать. В результате у них авария происходит.

Героя, который хотел научиться, играл как раз парень, ездивший в Японию. У него была своя Волга. Требовалась вторая машина. В институте их было очень мало, всего у нескольких человек. И вот свой старый Москвич предоставил наш главный инженер, ему сейчас 102 года. Сделали сцену столкновения обратная съемка там была. Потом по сценарию герой понимает, что его обманывают, бежит за аферистом, чтобы его побить. Оказалось, на улице эту сцену не снять толпа собралась. Рядом Дом моды, в котором меня знали я там когда-то фотографировал. Пошел к ним, попросил сделать как бы показ моделей. Аферист вбегает туда, снимает пиджак и ходит по подиуму, будто сам одежду показывает.

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


Фильм Короткое замыкание, реж. Радик Ананян, 1967 г.

За Короткое замыкание вы получили какие-то награды?

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

Когда сокращал, много драматичных моментов было резать жалко. Но сделал на 20:17 минут даже эпизод с участием директора НИИ вырезал. Я и режиссером был, и руководителем. Сам проявлял, делал звук. В итоге мы получили диплом за первое место среди 16 мм фильмов, а конструктор Саркисов за лучшую роль.

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


Гангстеры против ЭВМ вфильме Радика Ананяна Ограбление произойдет вполдень. Лента участвовал вконкурсе 16-мм фильмов вБрно в1968г. Из-за недавнего подавления Пражской весны обстановка была напряженной, поэтому Радик Ананян оказался одним извсего лишь двоих представителей СССР нафестивале. Вторым был один изчленов жюри. Вкадре можно увидеть ЭВМ Арагац иНаири.
Подробнее..

Netflix за 45 минут Краткий рассказ о system design-интервью, чего ожидать подборка полезных ссылок

26.08.2020 22:07:35 | Автор: admin


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

Итак, что такое system design и как пройти интервью такого типа?

Что это такое


В современном мире ИТ-системы стали крайне сложными. Каждая новая фича в продукте должна соответствовать множеству требований, всегда есть ограничения, между которыми приходится балансировать инженерам. То, что для обычного пользователя выглядит супер-просто как например, отправка поискового запроса через Google или Яндекс на самом деле несет в себе огромный уровень сложности.

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

Грубо говоря, интервью по system design это что-то типа сессии мозгового штурма, где человек мыслит вслух, перебирает возможные решения и анализирует недостатки каждого из них в режиме реального времени. В этом трудность, но и главный плюс мыслительный процесс здесь важнее результата. Как правило, такие интервью проводят крупные компании, разрабатывающие масштабные системы (FAANG и подобные).

Как же проходить интервью по проектированию систем? Ниже несколько практических советов.

Чтобы попасть на интервью в компании, где инженеры действительно проектируют масштабные системы, используйте бота @g-jobbot. Это сервис, который найдет и бесплатно пришлет вам прямо в Telegram вакансии, которые подходят вам лучше всего в том числе удаленная работа, в том числе с релокацией.


Самое важное четко разобраться с задачей


Поскольку в интервью по system design самое важное это то, как вы решаете задачу, крайне важно на самом первом этапе четко ее для себя уяснить. Бывший инженер Microsoft и Facebook в своей статье на практическом примере показывает важность этого факта.

Обычно задача звучит примерно как Как бы вы спроектировали Netflix за 45 минут? На первый взгляд, такие вопросы полный бред. Подобные масштабные системы проектируют и реализуют сотни и тысячи инженеров на протяжение многих лет. Сорока пяти минут будет недостаточно даже чтобы начать обсуждать хоть один из компонентов такого продукта!

Как раз здесь очень важно понимание задачи. Нужно понять, чего хочет интервьюер. А он очевидно хочет, чтобы ему:

  1. дали ответ формата обзор с вертолета всей системы,
  2. затем разложили ее на компоненты
  3. описали, зачем нужен каждый из них (вычислительный центр, хранение данных, фронтенд, бэкенд, кеширование, работа с очередями, нетворкинг и балансировка нагрузки и т.п.)



Изображение: system-design-primer

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

Задавайте уточняющие вопросы


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

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

Это позволит интервьюеру понять сразу несколько вещей:

  • как кандидат подходит к оценке задачи?
  • оценивает ли он сразу возможные ограничения и узкие места системы?
  • продумывает ли сразу оптимизацию решений и обход ограничений?

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

Вопросы могут быть такими:

  1. Что точно должна уметь делать система (сколько предметов влезает в коробку, каковы они по размерам)?
  2. Кто целевая аудитория продукта?
  3. Каковы ожидания пользователей продукта?

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

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



Изображение: freecodecamp.com

Не пытайтесь произвести впечатление


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

Во-первых, на интервью по системному дизайну наверняка будет не просто рекрутер, а инженер, который ищет человека себе в команду. Такому человеку недостаточно просто услышать слова вроде No-SQL, Mongo DB и Hadoop. Он явно начнет задавать уточняющие вопросы, и если у вас на самом деле нет особого опыта в работе с упоминаемыми технологиями, это все очень быстро станет ясно.

Будьте честными


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

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

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

Вот прекрасный вымышленный диалог на интервью по проектированию систем, который показывает, как НЕ надо делать:

Интервьюер: Давайте сделаем свой Twitter. Как вы будете хранить твиты?

Кандидат: Я использую NoSQL-базу MongoDB.

Интервьюер: Почему не MySQL?

Кандидат: СУБД не масштабируются. Для нашей задачи точно понадобится MongoDB или BigTable.

Интервьюер: Но мы тут в Twitter храним все твиты в MySQL, все нормально масштабируется.

Кандидат: Ну, тогда, возможно, у вас просто еще пока недостаточно большой объем. По-настоящему огромные системы типа Facebook используют NO-SQL.

Интервьюер: Но Facebook также использует MySQL.

Кандидат: Хм, не знаю, как они его масштабируют, надо разобраться. Возможно, у них MySQL только на фронтенде, а на бэке BigTable.

Интервьюер: Неважно. А где будем хранить аналитические данные?

Кандидат: Очевидно, что в MySQL.

Интервьюер: Но не слишком ли их много для MySQL? Сейчас у нас для этого HDFS.

Кандидат: Похоже, что вы начали разрабатывать Twitter еще до того, как MongoDB достаточно развился. MongoDB может легко вместить и твиты и аналитические данные.

Интервьюер: Супер, спасибо за ваше время. Было приятно пообщаться.

Как подготовиться к интервью: полезные ссылки


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

Подробнее..

Что такое soft skills для инженера в 2020 году, зачем и как компании их проверяют на собеседованиях

27.08.2020 22:12:02 | Автор: admin


Недавно один из моих знакомых инженеров устраивался на работу в Facebook. Он успешно прошел несколько кругов собеседований, его позвали на собеседование в офис, и уже там на этапе leadership and drive что-то пошло не так. Как признавался знакомый позднее, отвечать на вопросы в виде как вы сработались со сложным коллегой или как вы добивались целей в токсичной обстановке он был не очень готов.

Именно подобные вопросы позволяют оценить так называемые гибкие навыки (soft skills) инженеров. История собеседования в Facebook меня сильно заинтересовала, поэтому я решил изучить тему soft skills, их проверки и тренировки поподробнее. Бонусом прикладываю список полезных ресурсов и статей, на которые наткнулся в процессе подготовки материала. Поехали!

Что такое soft skills


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

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

Согласно исследованию, проведенному LinkedIn, в 2020 году работодатели больше всего ценят следующие мягкие навыки:

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

Мягкие навыки проверяют в ходе так называемых поведенческих интервью (behavioral interview). Существует более десятка аспектов, которые в ходе них могут анализировать рекрутеры, среди них:

  • Склонность к активным действиям, способности к самомотивации.
  • Способность адаптироваться к меняющимся условиям.
  • Коммуникационные навыки.
  • Умение разрешать конфликты.
  • Креативность и способность генерировать идеи.
  • Процесс принятия решений.
  • Умение ставить цели.
  • Навыки по донесению позиции, убеждению в своей правоте.
  • Планирование, расстановка приоритетов, тайм-менеджмент.
  • Решение проблем.
  • Работа в команде.
  • Работа под давлением.

Как все это устроено


Компании анализируют мягкие навыки по-разному. К примеру, Amazon в том числе использует для этого свои знаменитые Leadership Principles, и некоторые из них к кандидату примеряют уже на телефонном собеседовании.

Некоторые, начинают проверку уже на этапе отклика на вакансию. К примеру, мы разработали бота @g_jobbot, который позволяет кандидатам получать вакансии релевантные их опыту, прямо в Telegram. Компании же иногда размещают вакансию не только в боте, но и на других площадках, но в итоге отдают предпочтение тем, кто пришел через g-mate это достаточно новый способ поиска работы, те кандидаты, что им пользуются показывают себя как людей, которые не боятся экспериментов и открыты к новым технологиям.

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

В крупных ИТ-компаниях, особенно в США, обычно поведенческие собеседования становятся частью так называемого onsite loop серии разговоров в офисе компании для кандидата, прошедшего телефонные скрининги.

На таких интервью мягкие навыки проверяются с помощью вопросов вида:

  • Расскажите мне о ситуации, в которой вы..
  • Поделитесь примером того, как вы...
  • Представьте, что вы оказались в ситуации, где вам нужно...
  • Вспомните, как вы действовали в ситуации, когда...

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

Ниже запись полезного вебинара по теме soft skills с практическими примерами и на русском языке:


Например, способности к коммуникации можно проверить с помощью вопроса: Расскажите о ситуации, когда вам нужно было рассказать о какой-то сложной технической проблеме человеку, который далек от ИТ и не владеет сленгом? Как вы убедились, что собеседник вас понял?

А о способности работать в команде многое скажет ответ на такой вопрос: Случалось ли в вашей практике, что кто-то из членов команды не работал достаточно эффективно? Что вы делали в этой ситуации: обсудили ее с коллегой, руководителем, как прошла беседа, и каковы были результаты?

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

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

Как подготовиться к проверке soft skills на собеседовании


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

  • Собрать побольше информации о вопросах, которые могут задать в интернете есть множество подборок с вопросами по behavioral interview (несколько таких в списке в конце статьи). Внимательно их прочитайте, подумайте, случались ли описываемые в вопросах ситуации в вашей карьере, как вы реагировали на них.
  • С этими знаниями, еще раз изучите описание вакансии подумайте, какие вопросы по мягким навыкам вам могут задать, исходя из позиции, на которую вы претендуете. Уделите особое внимание подготовке ответов на эти вопросы.
  • При подготовке ответов используйте технику STAR во многих американских компаниях, например в Amazon, очень ее любят. Работает это так в начале идет описание ситуации и задачи (ST = Situation, Task), затем описываются действия (A = Actions), все завершается результатами (R = Results) ее альтернативой является фреймворк SCORE.
  • Особенное внимание стоит уделить результатам поднять цифры, что и как улучшилось в проекте по итогам вашей работы.
  • Попрактикуйтесь в ответах ответы на вопросы по soft skills больше похожи на презентацию, так что придется потренироваться. Начать можно с проговаривания ответов перед зеркалом, затем лучше пригласить коллегу или кого-то из родственников, а если попросить некого воспользоваться сервисом типа Pramp, где инженеры практикуются в прохождении интервью.
  • Будьте кратким тот факт, что на таком интервью не нужно писать код, а просто рассказать что-то, еще не значит, что рассказы должны быть очень длинными. Старайтесь сделать так, чтоб ответ на любой вопрос из вашего списка не превышал 2-3 минуты. Засекайте с секундомером, это полезно.

Заключение: ссылки и инструменты для подготовке к поведенческим интервью


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

Подробнее..

Как оценить и выбрать оффер разработчику на что смотреть, к чему готовиться, какие вопросы задавать

29.08.2020 20:22:07 | Автор: admin


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

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

Этап #1: узнаем себе цену и определяемся с пожеланиями


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

Этот подход подходит для вакансий на родине или с релокейтом, в случае удаленной работы на зарубежную компанию, есть свои нюансы. В общем и целом решить эту задачу помогают аналитические материалы. Данные по зарплатам российских айтишников можно найти на ресурсах вроде Levels. К примеру, по информации этого сервиса большинство зарплат разработчиков в нашей стране находятся в промежутке между 1,69 3,69 млн рублей в год (140,8 307,5к в месяц)



Если вы задумываетесь о переезде в другую страну, то стоит изучить самые свежие отчеты по зарплатам в нужном регионе. Конечно же, стоит обратить внимание на исследования порталов вроде StackOverflow, там можно получить данные по США и некоторым другим странам.

К примеру, в исследовании за 2020 год собраны данные о самых прибыльных технологиях, а также дана корреляция между зарплатой и опытом в определенной специальности:



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



Еще один важный этап подготовки определиться с интересными технологиями и траекторией карьеры. Хотите вы расти вертикально или горизонтально? Развивать знания в рамках текущего стека или попробовать его сменить? Все это важные вопросы, ответы на которых серьезно повлияют на оценку будущих офферов.

Для сравнения, вот, как ранжировали разные факторы по их влиянию на выбор работы опрошенные StackOverflow разработчики:



Этап 2: сбор информации о компании


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

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

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

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

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

Этап 3: переговоры


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



Статистика g-mate по локациям найма: сегодня кандидатам во всех категориях ИТ-специализаций больше всего интересны варианты с релокейтом

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

Итак, вот на какие аспекты будущей работы стоит обратить внимание в ходе обсуждений:

Как будет выглядеть онбординг и есть ли он


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

Каков подход к work-life balance


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

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

Что с премиями


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

Какая финансовая мотивация помимо зарплаты есть в компании


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

Какие еще бонусы предоставляет компания


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

Полезные статьи о поиске работы и собеседованиях в ИТ:


Подробнее..

Илья Трепачко о курсе Продакт-менеджер от ProductStar

03.09.2020 14:17:53 | Автор: admin

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

С каким бэкграундом ты пришел на курс Как быть продактом? Кем ты работал на момент старта?

Я работал бизнес-аналитиком в продуктовой компании на Awario. Мы с главной девочкой по маркетингу выполняли задачи product owner и вместе были тем самым продактом. Сам продукт мы делали с нуля.

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

За последний год нам удалось вывести продукт на окупаемость, и я покинул компанию в марте 2020.

Какие у тебя были ожидания от курса?

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

Над каким продуктом ты работал в качестве дипломного проекта? Было ли это полезно для тебя?

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

Работа над дипломным проектом и домашки в целом, на мой взгляд, были полезны, чтобы попробовать многие моменты на практике.

Что для тебя было особенно полезным на курсе?

Иерархия метрик. Я потом сделал на Awario около 100 метрик очень увлекательно. Выбрал группу метрик для улучшения и распределил их на квартал, но могу сказать, что пока не понятно, подходят ли метрики для генерации больших фичей (killer features). Кстати, на новом продукте в новой компании тоже начал с метрик, т.к. тут их почти совсем не было.

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

Расскажи, кем ты работаешь сейчас?

В апреле я устроился продактом в Evolution Gaming. Это продуктовая компания, которая делает платформу для онлайн-казино. Это, наверное, самая крутая в мире компания в области live casino online. У них очень много студий со столами, дилеры, видеостримы со всего этого. Это реально впечатляет. Здесь много продуктов и продактов. Я работаю с продуктом Lobby. Это площадка, где пользователь выбирает игры (это как Netflix в видео стримминге).

С какими трудностями и интересными нюансами ты столкнулся на собеседованиях?

Я делал тестовое и проходил два собеседования на английском языке, чтобы попасть в Evolution Gaming. Некоторые аспекты из курса мне, кстати, помогли для тестового (тема про AB тесты) и даже на самом собеседовании (тема про метрики и Awario). Самые большие трудности при собеседовании были, наверное, связаны с языком, т.к. до этого разговорный английский мне особо не требовался в работе: я был аналитиком в белорусской продуктовой компании.

Что ты можешь посоветовать начинающим продактам и текущим студентам курса?

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

Хочешь стать продакт-менеджером, как Илья?

Оставляй заявку на наш годовой курс Профессия: Продакт-менеджер и прокачивай свои навыки!

Подробнее..

Личный опыт Из соискателя в наниматели продакт советует, как проходить интервью в США

06.09.2020 22:19:56 | Автор: admin
Привет! Меня зовут Анна Наумова, сейчас яработаю старшим менеджером попродукту (Senior Product Manager) вкомпании Zello вОстине, штат Техас. Сначала ясама прошла 110 собеседований вАмерике, атеперь сижу подругую сторону стола ипомогаю подбирать инженеров вкоманду. Хочу рассказать прото, скакими трудностями столкнулась, икчему быть готовым вовремя интервью спродактами вСША.



Это я!

Начала карьеру яв2006 году вОдноклассниках как маркетолог. Через шесть лет получила роль менеджера попродукту иразвивала проект Подарки, аеще несколько лет спустя запустила снуля два мобильных приложения: конструктор подарков иприложение для мемов.

Вообще отсутствием предложений поработе яникогда нестрадала. НовРоссии 10лет работала иросла водной компании, мне это нравилось. Ихотя хедхантеры мне регулярно звонили мотивации менять работу небыло, так что насобеседования ходила только для поддержания тонуса. Было единственное по-настоящему интересное предложение: позиция вBooking.com срелокейтом вАмстердам. Новтот момент (2014год) уменя было все плохо санглийским так что интервью яблагополучно завалила.

Какое-то время спустя мой уже бывший муж выиграл влотерею гринкарт (Diversity Visa Lottery), имыпереехали вштаты. Атак как ячеловек технологий, былобы странно непопробовать изведать американский IT-рынок.

Тогда яприсоединилась кFasten райдшеринг-сервису вБостоне, ачерез год нахайпе криптовалют уехала вДолину искомпанией Bitclave провела успешное ICO. Теперь яживу вТехасе иразвиваю Zello приложение, которое делает измобильного телефона рацию.

Как получить оффер вАмерике? Можно искать вакансии самому наагрегаторах, аможно подключить вТелеге @g_jobbot. После того, как настроите параметры какая сфера вам интересна, какие локация (релокейт) изарплата предложения будут падать вчатбот.



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

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

Взгляд состороны соискателя: какие трудности бывают, когда выустраиваетесь вАмерике


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

  • Язык. Какойбы хороший английский увас нибыл, вштатах все равно придется многому учиться. Надо понимать множество акцентов, разбираться вофразеологизмах иустойчивых оборотах, разговаривать живо, анекак робот покнижке, учитывать культурные особенности: например, поддерживать small talk.
  • Предыдущий опыт. Американцам важен местный опыт даже если вРоссии выработали вочень крутых проектах. Потому что, во-первых, российский бэкграунд сложно проверить: наврать можно что угодно. Аво-вторых, скорее всего это значит, что выеще неадаптировались ккультурным особенностям работы вСША особенно это касается soft skills.

    Другие принципы найма буду говорить, как продакт.
  • Крайне важны коммуникационные навыки. Смотреть будут ненато, как тыдома молча сделал тестовое задание ипринес готовый ответ. Интервьюерам интересно, как тырешаешь задачу налету прямо насобеседовании, как тыпрезентуешь свой мыслительный процесс. Они дают какую-то проблему, иутебя есть 30минут, чтобы еерешить вслух.
  • Много этапов собеседований. 56 этапов норма итипичный путь отбора. Сделано это для того, чтобы посмотреть накандидата сразных сторон. Зачастую интервьюирует чутьли невся команда, всете, кто потенциально будут работать скандидатом. Поэтому понравиться надо всем, анетолько руководителю.
  • Процесс найма это надолго. Онзанимает много времени как для работодателя, так идля соискателя из-за серьезной конкуренции ибольшого количества этапов. Так что надо запастись терпением ирассчитывать, что устройство вкомпанию займет 36месяцев. Плюс чем выше позиция, тем этот процесс дольше. Ктомуже надо быть готовым, что отказов будет больше офферов.
  • Работодателям очень важно резюме. Плохое просто небудут смотреть! Основные принципы составления хорошего резюме: умещается наодном листе, описаны только достижения непроцессы, иникаких личных данных типа возраста, хобби ифотографии.
  • Все вопросы наинтервью известны вотличие отРоссии. Уменя поэтому поводу неоднозначное мнение. Хорошо, что тызнаешь, чего ожидать: можно подготовиться. Плохо, что эти вопросы знают все. Поэтому при выборе кандидата решающим является нето, насколько онумный, опытный или талантливый, анасколько хорошо презентовал свои знания.
  • Питч. Питч это короткий рассказ осебе на1минуту, ондолжен отскакивать отзубов.
  • Работодатели недают фидбек. Очень сложно понять, что конкретно имвтебе непонравилось, из-за этого замедляется процесс получения оффера.



Так выглядит Zello: регистрируетесь инастраиваетесь начастоту каналов

Как готовиласья?


Решила применить свои скиллы продуктового менеджера, построила воронку: резюме питч рекрутеру собеседование 1 собеседование 2итак далее, аконверсию улучшала экспериментальным путем. Наначальном этапе, когда ятолько приехала вАмерику, было примерно так. Из100 отправленных резюме, мне перезванивал один рекрутер. Тоесть конверсия была очень низкая, условно 1%.

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

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

Тут мне очень помогли mock-interview это тренировочные собеседования сдрузьями или такимиже, какты, менеджерами попродукту. Выинтервьюируете друг друга идаете честный отзыв, как все прошло. Это полезный опыт икогда тыотвечаешь навопросы, икогда, наоборот, задаешь: замечаешь ошибки других, стараешься исправить ихусебя. Уменя было около 50таких интервью. Кто-то берет коучей янебрала, уменя денег небыло.

Натренировочные интервью хожу досих пор. Сама использую Stellarpeers, ноесть еще Pramp иExponent.

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

Яидальше планирую тренироваться впрохождении собеседований. Слышала, что это частая практика постоянно собеседоваться или проходить mock-interview. Пригодится ичтобы быть втонусе, ичтобы понимать требования рынка.

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


Наша команда Zello :)


Взгляд состороны нанимателя: какие вопросы задают наинтервью ичто хотят узнать


Теперь уже уменя есть опыт интервьюирования как людей изРоссии, так иизСША. Язаметила, что российские ребята плохо говорят освоих достижениях. Они обычно скромничают, даже если заспиной много хороших завершенных проектов. Думаю, это связано скультурными особенностями: нас сдетства приучали невыпендриваться. ВАмерике обратная проблема: все умеют подать себя ирасхвалить. Ноесли копнуть глубже, точасто немогут ответить ничего дельного.

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

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

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

Что обычно продуктовые менеджеры спрашивают уинженеров:

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


5советов инженерам: что спрашивать насобеседовании


Разумеется, кандидаты непассивные персонажи. Совпадение повсем параметрам должно быть исостороны соискателя, исостороны проекта. Поэтому именно наэтом этапе отбора выможете оценить атмосферу вкоманде: насколько вам комфортно будет работать вместе. Япредлагаю задать менеджеру попродукту несколько вопросов.

Узнайте:

  1. Как продакт ставит задачи. Естьте, кто любит давать свободу разработчикам, изадачи ставятся достаточно высокоуровнево. Это подходит сплоченным командам ссильными разработчиками, укоторых глубокое знание продукта, инужен определенный уровень свободы. Есть, наоборот, те, кто любит сильно вдаваться вдетали. Это хорошо подойдет там, где разработчики непривязаны копределенной фиче, игде много джунов.
  2. Вкаком виде приходят задачи. User/job stories, PRD (product requirements), скетчи, прототипы итак далее.
  3. Как онрешает конфликты внутри коллектива.
  4. Как продакт приоритезирует задачи. Потому что никто нехочет быть перегруженным из-за продакта, который хочет завтра сделать все исразу.
  5. Какой онвидит идеальную команду, вкоторой хочет работать. Сравните стем, что увас есть сейчас.


Вобщем, выбирайте томесто, что вам подуше!

Что будет после интервью


Видеале, кандидат должен уйти ссобеседования вхорошем настроении. ВАмерике вкрупных компаниях типа Facebook или Google высылают обратную форму, где тыможешь оценить интервьюера. Есть сервисы вроде Glassdoor, Indeed, Comparably: тут кандидаты делятся мнением оработодателе. Нельзя допустить, чтобы обиженный соискатель пошел, написал гадости ипонизил рейтинг компании. Нетолько компании выбирают людей, ноилюди выбирают компании, вкоторых работать.

Долго икропотливо иэто только первый этап при найме вАмерике. Еще есть много тонкостей вкоммуникации между компанией ивозможным сотрудником. Ямогу рассказать про процесс получения офферов ито, как надо торговаться. Или про отказы: как сними работать икак отказывать самому. Могу больше рассказать про резюме, какие вопросы задают продактам икак ихнанимают вFacebook или Google. Былобы вам интересно? Пишите вкомментариях.

В Телеге можно настроить бот g-mate (@g_jobbot) будете получать вакансии по своему профилю прямо в чат. А компании могут опубликовать первые 3 вакансии бесплатно вот здесь.
Подробнее..

Как работают и отдыхают ИТ-специалисты в пост-карантин?

09.09.2020 10:06:55 | Автор: admin
В марте из-за пандемии COVID-19 Русфинанс Банк (РФБ) и целый ряд других компаний перешли на дистанционный режим работы. После снятия ограничений многие организации возвращаются к работе в офисе, однако РФБ и его ИТ-подразделение продолжает работать удалённо (подробнее о переходе на удалёнку можно прочитать тут).

Мы решили выяснить, как изменилась работа сотрудников после перехода в home office, и заодно познакомить вас с нашими ИТ-экспертами системными аналитиками, бизнес-аналитиками, разработчиками, тестировщиками.

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

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



Чем ты занимаешься в Русфинанс Банке? За что отвечаешь?

Я начальник отдела разработки систем, отвечающих за интеграцию с партнёрами в рамках процесса автокредитования. Мы разрабатываем сервисы для интеграции наших систем с внешним миром, начиная с форм для самостоятельной отправки анкеты клиентом через наши или партнёрский сайты и заканчивая брокерским софтом, CRM-системами партнёров. И, в целом, двигаем процесс оформления автокредитов всё дальше и дальше в онлайн.

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

Опиши, пожалуйста, одним словом/ фразой (метафорой, эпитетом), твой девиз в работе.

Поспешишь людей насмешишь.

Какие гаджеты (компьютеры, планшеты, смартфоны) ты используешь в работе/ для личного пользования? Изменились ли они с переходом на удалёнку?

Рабочий ноутбук + домашний компьютер + смартфон + умные часы. С уходом на удалёнку ничего не поменялось. У меня смартфон Huawei Honor 8, исторически пользуюсь Androidом.

Какие операционные системы тебе нравится использовать вне работы? С какими OS было бы интересно познакомиться для себя? Почему интересны именно они?

Использую Windows 10, на *nix никогда не планировал переходить, так как иногда играю в игры, а в те времена, когда я начинал (~20 лет назад), было немало проблем с совместимостью, поэтому так и остался на Windows. И хотя сейчас хобби уже практически сошло на нет, так как перестало затягивать и цеплять, инерция сохранилась.

Изредка собираемся с друзьями на сессионные игры (аналоги настольных игр типа Armello или MOBA типа Heroes of the Storm). Из однопользовательских игр последними меня зацепили Persona 5, Cuphead, Disco Elysium и Horizon: Zero Dawn.

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

В целом для домашнего пользования мне достаточно Windows.
Скучаю по привычному Windows XP

Каким таск-менеджером/ таск-трекером ты пользуешься для работы/ для себя? Почему выбрал именно их?

У меня личного таск-менеджера как такового нет, рабочие дела записываю в физические/ электронные блокноты. Некоторые свои нерабочие дела веду в Google Keep отдельными заметками с перечнем планируемых действий.

В целом ретроградски предпочитаю что-то офлайновое, не завязанное на соединение с Интернетом. К сожалению, хотя сейчас уже далеко не 2000-е, когда половина сервисов имела открытую наружу админку со стандартными логинами/ паролями, и информационная безопасность сделала миллион шагов вперёд, утечки данных случаются в том числе и у крупных компаний. Мне бы не хотелось, чтобы это случилось с моими личными заметками (улыбается).

В рабочем процессе используем Jira. По завершении процесса Discovery (бизнес-анализ, исследование актуальности и окупаемости той или иной фичи) задача заводится в бэклоге Delivery (системный анализ, разработка, тестирование, внедрение). Задачу декомпозируем на подзадачи, берём в работу, включаем в нужный релиз. У типовой задачи будет движение между аналитиком, Oracle-разработчиком, Java-разработчиком, тестировщиком и менеджером приложения (роль, которая в том числе отвечает за внедрение).

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

Не могу сказать, что мы на 100% с этим справляемся, но определённо движемся в этом направлении. У нас очень большая команда, и мы только учимся эффективно работать все вместе, поэтому предстоит огромное количество работы в том числе и над прозрачностью наших процессов.

Confluence мы преимущественно используем как базу знаний. Пока вопрос лицензий ещё не решён окончательно. Тем не менее, мы очень надеемся, что сможем собрать в единое удобное для чтения и редактирования место все знания, разбросанные по инструкциям, письмам, головам и так далее. Амбициозно рассчитываю стать одним из основателей процесса управления знаниями в компании (улыбается). Пока мы наполняем базу не слишком активно, так как контрибьютить могут не все участники команды.

Какие фреймворки, языки, IDE и другие инструменты тебе нравится использовать больше всего? Почему?

Сам разработкой не занимаюсь, с кодом работаю в основном в рамках чтения, написания проверочных скриптов. Для этих небольших нужд использую Pl/Sql developer.

Моделированием мы занимаемся не слишком часто, но когда необходимость возникает, использую Visio и Visio-совместимые приложения (например, draw.io).

Какое место в твоей жизни занимает тайм-менеджмент? Какие инструменты/ методики ты используешь для управления своим временем (если есть)?

За время карьеры делал несколько подходов к изучению и применению на практике различных методологий. Честно говоря, по моему мнению, для эффективного менеджмента рабочего времени необходимо, чтобы ежедневно у тебя было сколько-то этого самого времени для планирования (улыбается).

Рабочий график руководителя очень редко даёт возможность полноценно планировать более 3-4 часов в день. При этом, конечно же, речи нет о том, чтобы они шли подряд. Здесь критически важна автономность каждого сотрудника: чем больше вопросов команда может затащить самостоятельно (неважно, подключиться ли к решению критического бага с прода, не дожидаясь просьбы свыше, или самостоятельно найти и прочитать документацию по нужному административному вопросу), тем больше времени останется на те задачи, где моё участие и правда необходимо.

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

А для того, чтобы максимизировать эффективность работы над конкретной задачей, когда для неё наконец нашлось время, лучше всего, на мой взгляд, использовать метод помодорро (ставите таймер 15-25 минут на конкретную задачу и запускаете, это дисциплинирует). И тогда становится психологически сложнее отвлекаться на новые письма, сообщения в мессенджерах часики-то тикают.

Слушаешь ли ты что-то во время работы/ в перерывах между работой (музыку, аудиокниги и т.д.)? Была ли у тебя такая возможность/ желание до перехода на удалёнку?

В офисе (в open space) постоянно приходилось ставить музыку фоном, чтобы не отвлекаться и сосредоточиться на работе. На удалёнке наоборот: в основном пользуюсь возможностью спокойно сосредоточиться в полной тишине, музыку включаю только под настроение, для творческих задач, вроде ответов на вопросы данного интервью (улыбается).

Какую профессиональную литературу ты читаешь? Что можешь порекомендовать?

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

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

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

Какие полезные профессиональные привычки помогают тебе в работе?

Всегда перепроверять любую свою работу (документацию, код) незамыленным взглядом после паузы.

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

Дожать задачу до конца это очень ценный навык, который будет работать не только на качество, но и на вашу репутацию (улыбается).

Какой важный совет, который ты когда-либо получал, можешь передать начинающим специалистам в твоей профессиональной области?

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

1. Всегда старайтесь узнать чуть больше, как в технической, так и бизнесовой части.

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

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

2. Не бойтесь задавать глупые вопросы.

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

*Статистика собрана эмпирическим путём

В целом важные на мой взгляд советы:

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

2. Совет, который мне давали мои руководители ещё в самом начале работы в РФБ, когда я был специалистом, а не менеджером. Тогда я к нему не прислушался, потому что он внутренне показался мне неверным. Я смог по-настоящему его оценить только на дистанции. Хотя обоих советовавших я безмерно уважал и уважаю. И в целом всегда старался следовать всем их рекомендациям.

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

Разрешите себе уйти в офлайн, сосредоточиться на своей задаче. Если случится что-то критичное вас обязательно найдут (улыбается). Давайте себе какое-то время (например, с утра и до обеда), в которое вы не реагируете на внешние раздражители. Даже на короткие вопросики на пять минут максимум.

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

Баги не самый удачный пример, конечно, но, тем не менее, немалое количество вопросов рассасываются самостоятельно в течение часа-двух по тем или иным причинам.

О самоизоляции


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

Елена Мышенкова о курсе Продакт-менеджер от ProductStar

09.09.2020 14:04:11 | Автор: admin

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

Продакт это универсальная профессия, даже ваша жизнь это тоже своего рода продукт, в котором есть условный бэклог, пути развития, критерии оценки

Елена Мышенкова

Кем вы работаете?

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

А что из этого, по-вашему, относится к продакт-менеджменту?

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

Вы упоминали, что хотели сменить место работы, но после прохождения курса решили этого не делать. Почему?

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

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

У вас было такое, что прохождение какого-то урока из курса заставило вас посмотреть на свою работу с другой стороны?

Мы изучали большое количество разных тем и многое из пройденного я так или иначе уже затрагивала в работе, поэтому мне сложно выбрать какую-то конкретную лекцию. Но благодаря учебе я начала иначе смотреть на продукт, который в итоге у меня должен получиться на работе. Что мне понравилось, еще когда я выбирала курсы в ProductStar, так это то, что мы затрагивали практически все ключевые направления. Не просто как управлять командой и ставить задачи, но в том числе deeplink-и, прототипирование, A/B-тесты и много чего еще.

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

Как долго вы работали в этой области до прохождения курса?

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

Какую книгу или несколько книг вы могли бы порекомендовать к прочтению людям из той же сферы?

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

Последний вопрос: что вы можете посоветовать тем, кто только начинает проходить курс?

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

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

Хочешь стать продактом, чтобы получить знания, которые тебе точно пригодятся?

Оставляй заявку на наш годовой курс Профессия: Продакт-менеджер и прокачивай свои навыки ? Узнать подробности!

Подробнее..

Подборка Полезные статьи о релокации в США выбор визы, поиск работы, зарплаты и налоги

09.09.2020 22:19:00 | Автор: admin

Одна из самых популярных тем в нашем блоге релокация. А самым популярным направлением для переезда русскоговорящих инженеров остаются США. Это легко объяснимо в этой стране наиболее развита IT-отрасль, FAANG, тысячи стартапов, передовые технологии и вот это все.

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

Подготовка переезда: виза, стоимость жизни, выбор штата

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

Вот несколько полезных статей, которые помогут собрать побольше информации о визах и адаптации на новом месте в целом:

Работа: собеседования, зарплаты и налоги

Карьера это именно то, для чего в США едут разработчики. Ниже подборка из нескольких материалов, которые позволят начать поиск вакансий, дадут представления о том, как готовиться к собеседованиям, какую зарплату просить, и сколько придется отдать на налоги.

В эту пятницу 17.00 Мск запускаем новый для g-mate формат вебинаров будем рассказывать про секреты найма в tech и особенности релокейта в разные страны.

В этот раз Анна Наумова, Senior Product Manager @ Zello расскажет, как пройти путь от отклика до оффера в США.

Еще немного полезных ссылок

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

Если вы хотите найти вакансии с возможностью релокации в США прямо в Телеграме подключайте бот g-mate (@g_jobbot) он будет присылать вакансии по вашему профилю прямо в чат. А компании могут опубликовать первые 3 вакансии бесплатно вот здесь.

Подробнее..

Однодневный спринт реальность или вымысел?

10.09.2020 10:11:09 | Автор: admin

Зная, как я люблю экспериментировать, иногда на конференциях меня коллеги спрашивают: "Ну, какой у тебя теперь минимальный спринт?"


Я и сам сейчас задумался с этой самоизоляцией и работой на дому да на даче, какой у меня реальной длительности спринт.


И с удивлением понял: один день.



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


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


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


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


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


Мы провели курс для Scrum-мастеров Профессия SCRUM-мастер. И уже можем поделиться результатами с него и наблюдениями.


N.B. редактора: Это не рекламная и не продающая статья. Курс уже прошёл. В этой статье никто и ничего не предлагает купить, подписаться, зарегистрироваться. Просто обдумать то, что получилось, какие инсайты пришли за время процесса.

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


И это хороший вопрос. Как раз в рамках прошедшего курса. Давайте попробуем сформулировать.


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


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


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


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


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


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


Но есть и опасность переусердствовать. Многие сейчас ринулись в Аgile, как будто пандемия их подтолкнула и не только начали трансформацию снизу-вверх, или там слева-направо, а совсем не сверху-вниз, как и должно быть. Не изменятся топы, дела не будет. Будет чистый карго-культ.


Если вы прочитаете книжку про Билла Гейтса и узнаете, что он встает в 6:00 утра и вы почему-то решили, что он поэтому миллиардер. Если встать в 6:00 утра, то вы миллиардером не станете примерно никогда. То, это как раз такое классическое применение карго-культа. А Scrum или Agile, поскольку он имеет большое количество церемоний, хорошо прописанных в Scrum-гайд там очень легко описанные методологии и задачи пробовать скопировать. И получить из всего этого реальный Agile карго-культ очень легко. Скорее он с большей вероятностью у вас получится, чем реально действующий Agile. Попытаться тупо и без огонька, без трансформации "сверху-вниз", от топов к линейным сотрудникам, просто как написано в Scrum Guide, в надежде, что у вас случился Scrum, попросту бесполезно.


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


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


Когда в сознании в правильном направлении построены все ценности, все эти практики и мероприятия появятся естественным путем. Потому что, примерно так они и появились в своё время. Потому что люди поменяли свое сознание, сделали клиента центром своей Вселенной, а не наоборот и всё начало крутиться вокруг него, и начали появляться те мероприятия, процессы, которые способствовали появлению Agile и Scrum. Это как раз к извечному вопросу: Что появилось первым курица или яйцо. Само клиентоцентричное отношение или Agile.


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


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


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


Таким вот образом это всё просто эволюционно образовалось. Были компании, которые дошли до Scrum своим собственным опытом. И оказалось, что у них получился Scrum, когда Scrum стал мейнстримом. Поэтому Scrum это такая естественная штука, когда ты немножко меняешь свой мейнстрим, в основе которого лежит понятие, что ты вокруг клиента крутишься, а не наоборот.
И он, естественным образом, сам у вас и образуется. Поэтому, если начинать с копирования мероприятий, то, скорее всего, вы в карго-культ и свалитесь. А вот когда изменится мышление в компании от топов для команд разработчиков вы сами свалитесь в Scrum.


Секретом Полишинеля по спринту длиной в 1 день поделился Алексей Куксёнок, Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в нескольких десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK).

Подробнее..

Практический опыт Есть ли смысл IT-профессионалу участвовать на ТВ-шоу или давать интервью федеральным каналам?

12.09.2020 14:11:18 | Автор: admin

Порой у владельца IT-бизнеса или опытного IT-специалиста может появиться шальная мысль: А не поучаствовать ли мне на ТВ в каком-нибудь шоу или дать интервью, чтобы пропиарить свой продукт или компанию? Так сказать, воспользоваться федеральным медийным ресурсом и выйти на широкую аудиторию.


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


Антон Первушин, известный писатель и журналист, популяризатор и исследователь космоса и истории космонавтики (книги Последний космический шанс, 108 минут, изменивших мир, Юрий Гагарин: один полёт и вся жизнь, Космическая мифология. От марсианских атлантов до лунного заговора) согласился поделиться личным опытом, что бывает, если дать длинное и научно-адекватное интервью телеканалу, как телеканал его использует, и какую пользу профессионал любой области может получить, если свяжется с современным ТВ. Здесь и далее личное мнение и оценки Антона Первушина.



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


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


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


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


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


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


Мне думается, мы сейчас вошли в фазу стремительного и глубокого обуржуазивания российского общества. Но, как ожидалось, этот процесс сопровождается и негативными последствиями деградацией качества информационного поля. Ещё один фактор возникновение хайп-экономики, когда ценностью становится даже заведомо недостоверная информация, если она вызывает ажиотаж. Никто не несёт ответственности за вбросы, зато имеет свою копеечку с рейтинга. Дном я (и не только я) считаю канал Рен-ТВ. Но и другие, похоже, стремятся к той же славе. Например, ТВ-3, который я когда-то уважал, превратился в лженаучного клона. Лучше бы они оставались каналом фантастического и остросюжетного кино возможно, в таком случае я его смотрел бы.


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


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


Я помню ты крепко схлестнулся с Игорем Прокопенко. Расскажи, пожалуйста, как развивалась борьба ТВ со здравым смыслом.


История такая. В лучшие времена я довольно охотно сотрудничал с телевидением. Соглашался бесплатно давать интервью, причём сам дурак такой! за свой счёт ездил из Петербурга в Москву на съёмки. Мне, конечно, думалось, что участие в документальных фильмах и телепередачах поспособствует росту моей популярности как писателя, опять же новый необычный опыт и так далее.


В декабре 2011 года я имел неосторожность дать интервью Анне Колодезневой для фильма о Луне: её загадках, происхождении, изучении. Мне было сказано, что речь идёт о научно-популярной программе, и я без колебаний согласился. Колодезнева загодя прислала мне вопросы, и я нормально подготовился. Запись шла в форме интервью и заняла где-то около часа. По предшествующему опыту я знал, что в фильм войдёт всего несколько фрагментов. Так и получилось: режиссёр оставил шесть небольших высказываний, два из которых касались американской программы Аполлон.


Фильм вышел в эфир в начале февраля 2012 года под названием Апокалипсис Луна и мне не понравился. Он поверхностный, в нём на полном серьёзе обсуждается множество сумасбродных и давно отвергнутых гипотез. Например, в нём заявлено, что на Луне есть база инопланетян, а американские астронавты вступили с ними в контакт, поэтому подробности экспедиций Аполлон были засекречены. В общем, я не горжусь участием в этом фильме, но он, по крайней мере, не оскорблял меня как эксперта. Снялся в нём и ладно можно забыть и заняться более интересными делами.


Однако в январе 2016 года я узнал, что фрагменты интервью, которое давал Колодезневой те самые, которые касались программы Аполлон появились в фильме Игоря Прокопенко День шокирующих гипотез. Как американцы Луну украли.


Даже из названия видно, что известный телеведущий выступил здесь, как сторонник теории лунного заговора, то есть взялся доказывать, что американцы не летали на Луну. Мои коллеги по цеху популяризаторов космонавтики, конечно, не упустили повода позлословить и посмеяться в мой адрес. С Прокопенко к тому моменту им было всё ясно, но никто из коллег не ожидал, что я соглашусь сниматься в таком кино. Я почувствовал себя не просто дураком, а дураком в квадрате, но не видел способа как-то повлиять на Рен-ТВ, ведь я всё же согласился сняться у них. В то же время фрагменты интервью продолжали размножаться делением, появляясь то в одном фильме на канале Рен-ТВ, то в другом. Терпение моё лопнуло после того, как известный популяризатор Александр Соколов ехидно прислал мне скан страниц из книги Прокопенко Тайны древних цивилизаций 2015 года издания, в которых опять цитировались те же фрагменты, что и в фильме. При этом они были помещены в контекст, из которого становилось ясно: эксперт лжёт!


Вот тут я разозлился по-настоящему. Пошёл в Буквоед у станции метро Чёрная Речка, рядом с которой живу, и пролистал там книги Прокопенко. И обнаружил, что он использовал те же фрагменты ещё и в книгах, изданных в 2016 году под названиями Великие тайны Вселенной. От древних цивилизаций до наших дней, Солнце, Луна, Марс и Тайны космоса, Потом с помощью интернет-поисковика я установил, что Прокопенко вставил те же фрагменты в свои поздние книги Тайны человека и Тайны космоса, но теперь без указания авторства, то есть пошёл на прямой плагиат!


В общем, коллеги помогли мне найти и нанять юриста, который от моего имени подал в Октябрьский районный суд Санкт-Петербурга иск на Игоря Прокопенко и ОАО Петропечать, которое управляет магазинами Буквоед. Я потребовал убрать названные книги из магазинов и выплатить мне компенсацию за нарушение авторского права и нанесение морального ущерба.
Мы, кстати, сразу подозревали, что по первому пункту я вряд ли получу удовлетворение. Российская версия закона об авторском праве очень запутанная и на самом деле позволяет многое, поэтому решение в нашу пользу может быть принято только при определённой благосклонности судьи. В то же время требование компенсации за моральный ущерб казалось нам железобетонным, но увы. Суд продолжался очень долго: состоялось восемь заседаний. С движением дела вы сами можете ознакомиться по ссылке.


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


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


Скажи, ты веришь, что на современном российском ТВ могут появиться передачи В мире животных, Международная панорама, Хочу всё знать, Это вы можете, Очевидное невероятное с Сергеем Петровичем Капицей. Если ли ещё такие специалисты?


Вполне верю. У нас хватает достойных популяризаторов, которые умеют и любят выступать перед публикой. Владимир Сурдин и Сергей Попов хорошо рассказывают о Вселенной. Братья Александр и Георгий Соколовы создали прекрасный фестиваль Учёные против мифов и занимаются развитием замечательного портала Антропогенез.ру. Станислав Дробышевский и Александр Марков всегда готовы поговорить о проблемах и достижениях эволюционной теории. Александр Панчин весело воюет с мракобесием.


Все они могли бы стать ведущими, авторами или соавторами просветительских программ на ТВ. Что касается моей любимой космонавтики, то тут спикерами могли бы стать сами космонавты они все весьма симпатичные, коммуникабельные и красноречивые люди. Например, лётчик-космонавт Сергей Рязанский очень хороший спикер; ему можно было бы доверить программу типа Хочу всё знать!. Есть и блогеры с хорошими научно-популярными каналами. Но вопрос: захотят ли они сами прийти на ТВ, если репутация федеральных каналов катится за плинтус?


Как думаешь, то, что сейчас происходит: камеди-клабы, замуж за бузовых, домы-2, большие стирки, пусть говорят, время покажет, 60 минут, воскресные вечера это запрос аудитории? Или это насаждение аудитории сверху такой мыслительной парадигмы?


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


Какую бы ты сам хотел вести передачу на федеральном ТВ?


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


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


Есть у тебя прогнозы, какие дны и донышки мы ещё пробьём?


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


Как ты думаешь, почему пропали передачи о звёздах?


Они не пропали. Наоборот, их стало больше. Только астрономию в них заменила астрология. Или ты о некогда популярном шоу Звёзды на льду? :-)


Как ты считаешь, есть ли смысл профессионалу сейчас участвовать в ток-шоу?


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


Что можно обсуждать с такой публикой? Я помню, что воспринимал на таком шоу как победу даже небольшое доказанное утверждение в пользу научной точки зрения, но битва на самом деле была проиграна в тот момент, когда я вошёл в студию. Ведь участвовать в публичной дискуссии с деятелями, выступающими с антинаучных или лженаучных позиций, это значит придавать им легитимность. Сегодня нам надо бороться за возвращение авторитета и престижа науки, заново создавать институт репутации. Хватит! Наигрались! Пора лженауке указать подобающее ей место.


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

Подробнее..

Перевод Планка найма для инженеров что это за зверь?

14.09.2020 00:19:13 | Автор: admin
Последние пять лет Рекурсивный Кактус трудился фулстек-разработчиком в топовой технологической компании, но сейчас решил сменить работу.

За последние полгода Рекурсивный Кактус (так он представился при регистрации на нашем сайте) готовился к будущим собеседованиям, выделяя каждую неделю минимум 20-30 часов на упражнения LeetCode, учебники по алгоритмам и, конечно, практику интервью на нашей платформе для оценки своего прогресса.

Типичный рабочий день Рекурсивного Кактуса:


Время Занятие
6:30 7:00 Подъём
7:00 7:30 Медитация
7:30 9:30 Решение задач по алгоритмам
9:30 10:00 Путь на работу
10:00 18:30 Работа
18:30 19:00 Путь с работы
19:00 19:30 Общение с женой
19:30 20:00 Медитация
20:00 22:00 Решение задач по алгоритмам

Типичный выходной день Рекурсивного Кактуса:


Время Занятие
8:00 10:00 Решение задач по алгоритмам
10:00 12:00 Физкультура
12:00 14:00 Свободное время
14:00 16:00 Решение задач по алгоритмам
16:00 19:00 Ужин с женой и друзьями
19:00 21:00 Решение задач по алгоритмам

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

Одна мысль не даёт уснуть: Что, если я не пройду собеседование? Что, если всё это время было потрачено напрасно?

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

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

Чтобы соответствовать планке, он выбрал конкретную тактику: соответствовать общепринятым ожиданиям для инженера, а не просто быть тем профессионалом, которым является в реальности.

Кажется глупым намеренно притворяться кем-то, кем ты не являешься. Но если мы хотим понять поведение Рекурсивного Кактуса, желательно разобраться, что же это за планка такая. И если немного подумать на эту тему, то кажется, что у неё нет такого чёткого определения.

Определение планки


Давайте посмотрим, как компании FAANG (Facebook, Amazon, Apple, Netflix, Google) определяют планку. В конце концов, именно к этим компаниям приковано наибольшее внимание практически всех, включая соискателей.

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

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

Говоря о технологических гигантах в исторической перспективе, Алина (наш основатель) в прошлом посте упомянула книгу 2003 года Как сдвинуть гору Фудзи?, которая рассказывает о процессе собеседований в Microsoft в то время, когда эта компания была выдающимся технологическим гигантом.

Чтобы собрать дополнительную информацию, как компании оценивают кандидатов, я также изучил Взлом собеседований по программированию Гейла Лакманна Макдауэлла, это фактически Библия по интервью для потенциальных кандидатов, а также Партизанское руководство по интервьюированию 3.0 Джоэла Спольски, написанное влиятельной и хорошо известной фигурой в технических кругах.

Определения планки

Источник Критерии оценки
Apple Не публиковались публично
Amazon Соответствие принципам лидерства Amazon
Facebook Не публиковались публично
Netflix Не публиковались публично
Google 1. Общие когнитивные способности
2. Лидерство
3. Гугловость
4. Профессиональные знания
Взлом собеседований по программированию Гейла Лакманна Макдауэлла Аналитические навыки
Навыки программирования
Технические знания / основы информатики
Опыт
Культурное соответствие
Джоэл Спольски Быть умным
Успешно делать своё дело
Microsoft (около 2003 года) Целью интервью Microsoft является оценка общей способности решать проблемы, а не конкретной компетенции
Скорость мышления, изобретательность, способность к творческому решению проблем, нестандартное мышление
Нанимайте за то, что люди могут сделать, а не за то, что они сделали
Мотивация

Определение понятия интеллект


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

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

Источник Определение когнитивных способностей
Google Общие когнитивные способности. Неудивительно, что нам нужны умные люди, способные учиться и приспосабливаться к новым ситуациям. Помните, что речь идёт о понимании того, как кандидаты решают трудные задачи в реальной жизни и как они учатся, а не о проверке GPA и SAT
Microsoft (около 2003 года) Цель интервью в Microsoft оценить общую способность решать проблемы, а не конкретную компетенцию Редко бывает ясно, какой требуется тип рассуждений или каковы точные границы проблемы. Но человек должен продолжать попытки до тех пор, пока не сможет довести анализ до своевременного и успешного завершения
Джоэл Спольски По какой-то причине большинство людей, кажется, рождаются без той части мозга, которая понимает указатели
Гейл Лакманн Макдауэлл Если вы способны решить несколько сложных задач (возможно, с некоторой помощью), вы, вероятно, довольно хороши в разработке оптимальных алгоритмов. Вы умны

Все эти определения напоминают теорию психолога начала XIX века Чарльза Спирмена, самую общепринятую теорию интеллекта. Проведя серию когнитивных тестов на школьниках, Спирмен обнаружил, что те, кто хорошо справлялся с одним типом теста, как правило, также хорошо справлялись и с другими тестами. Это понимание привело Спирмена к теории, что существует единый базовый общий фактор способностей (g или g-фактор), влияющий на все показатели, независимо от конкретных, специфичных для данной задачи способностей (s).

Если вы верите в существование g (многие верят, некоторые нет есть разные теории интеллекта), то поиск кандидатов с высокими показателями g чётко согласуется с критериями интеллекта в компаниях.

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

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

Измерение общего интеллекта


В книге Бока упоминается статья Фрэнка Шмидта и Джона Хантера 1998 года Обоснованность и полезность методов отбора в психологии персонала. Она пытается ответить на этот вопрос, анализируя широкий спектр из 19 критериев отбора кандидатов. Задача в том, чтобы определить, какие из них лучше всего предсказывают будущие результаты работы. Авторы пришли к выводу, что общие умственные способности (тест GMA) лучше всего предсказывают производительность труда (прогностическая валидность).



В этом исследовании тест GMA считается тестом IQ. Но Microsoft примерно в 2003 году использовала для оценки IQ головоломки вроде Сколько в мире настройщиков пианино?. Их объяснение:

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

Как сдвинуть гору Фудзи?, стр. 20

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

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

Мы измеряем конкретные способности или общий интеллект?


Но может быть, как утверждали Спольски и Макдауэлл, традиционные алгоритмические и компьютерные вопросы на интервью сами по себе являются эффективными тестами на общий интеллект. Исследование Хантера и Шмидта содержат некоторые подтверждения этой теории. Среди всех однокритериальных инструментов оценки наибольшей прогностической валидностью обладали тесты с образцами работы. Кроме того, при изучении самого высокого результата регрессии валидности двухкритериального инструмента оценки (тест GMA плюс тест с образцом работы) стандартизированный размер эффекта на оценку рабочей выборки оказался больше, чем у рейтинга GMA, что свидетельствует о более сильной связи с будущей производительностью кандидата.

Исследование предполагает, что традиционные интервью по алгоритмам предсказывают будущую производительность, возможно, даже больше, чем тест GMA/IQ.

Рекурсивный Кактус не верит, что такая связь есть:

Есть небольшое совпадение между знаниями, полученными на работе, и решением алгоритмических задач. Большинство инженеров редко имеют дело с графами или динамическим программированием. В прикладном программировании наиболее распространёнными структурами данных являются списки и словарные объекты. Однако вопросы интервью, связанные с ними, часто рассматриваются как тривиальные, поэтому основное внимание уделяется другим категориям проблем

По его мнению, вопросы алгоритмов похожи на вопросы-головоломки от Microsoft: вы изучаете задачки с собеседований, которые никогда не встретите в реальной повседневной работе. Если так, то это на самом деле не соответствует исследованию Хантера и Шмидта.

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

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

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

Джоэл Спольски

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

Таким образом, если вы не верите, что компьютерный интеллект это и есть общий интеллект, то Макдауэлл предлагает следующее:

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

Гейл Лакманн Макдауэлл

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

На данный момент мы не говорим об измерении общего интеллекта, как его первоначально определил Спирмен. Скорее, мы говорим о специфическом интеллекте, определяемом или распространяемом теми, кто вырос или участвует в традиционном компьютерном образовании, в объединении с общим интеллектом (Спольски, Макдауэлл, Билл Гейтс из Microsoft и четыре из пяти основателей FAANG изучали компьютерные науки либо в каком-то университете Лиги плюща, либо в Стэнфорде).

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

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

Планка субъективна


На нашей платформе interviewing.io люди тренируются в прохождении технических интервью онлайн, с интервьюерами из ведущих компаний, и анонимно. Вопросы для интервью аналогичны тем, какие вы можете услышать во время телефонного скрининга на позицию разработчика бэкенда, а интервьюеры обычно приходят из таких компаний, как Google, Facebook, Dropbox, Airbnb и др. Вот примеры таких собеседований. После каждого собеседования интервьюеры оценивают кандидатов по нескольким параметрам: технические навыки, коммуникативные навыки и навыки решения проблем по шкале от 1 до 4, где 1 плохо, а 4 восхитительно!. Так выглядит форма обратной связи:



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

Наблюдая за самыми активными интервьюерами, мы заметили разницу в проценте кандидатов, которых бы нанял этот человек (коэффициент прохождения). Этот коэффициент колеблется от 30% до 60%. Некоторые интервьюеры кажутся гораздо жёстче, чем другие.



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

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

Этот результат можно интерпретировать несколькими способами:

  • Более строгие интервьюеры систематически недооценивают кандидатов
  • Кандидаты настолько измучены строгими интервьюерами, что склонны совершенствоваться между собеседованиями, стремясь соответствовать более высокой планке первоначального интервьюера

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



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

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

Это различие между интервьюерами заставило нас пересмотреть собственное определение планки, которое фильтрует кандидатов при допуске к интервью с нашими компаниями-партнёрами. Наше определение сильно напоминало бинарные критерии Спольски (будь умным), переоценивая мнение интервьюера и недооценивая остальные три критерия, что привело к бимодальному, верблюжьему распределению, которое показано на диаграмме ниже.



Хотя существующая система подсчёта баллов достаточно хорошо коррелирует с результатами будущих интервью, мы выяснили, что оценка интервьюера не так сильно коррелирует с будущими результатами, как другие наши критерии. Мы уменьшили её вес, что в итоге повысило точность прогнозирования[4]. Как в фильме Рики Бобби: Король дороги Рики Бобби узнал, что кроме первого и последнего есть и другие места в гонке, так же и мы узнали, что полезно выйти за пределы бинарной конструкции нанять не нанять, или, если хотите, умный не умный.

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

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

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

  • Задать два вопроса. Если ответит на оба, то тест пройден
  • Задавать вопросы разной сложности (лёгкие, средние, трудные). Если ответит на средний, то тест пройден
  • Большое значение имеет скорость ответа. Тест пройден, если ответы быстрые (понятие быстрые чётко не определено)
  • Скорость не имеет большого значения. Тест пройден, если есть рабочее решение
  • Кандидаты начинают с максимальной оценки. За каждую ошибку снимаются баллы

Разные критерии оценки не обязательно плохо (и на самом деле совершенно нормально). Просто они вносят большой разброс в наши измерения, то есть оценки кандидатов получаются не совсем точными.

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

Часто советуют нанимать только кандидатов высочайшего уровня.

Хорошее эмпирическое правило нанимать только тех, кто лучше вас. Без компромиссов. Всегда

Ласло Бок

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

Джоэл Спольски

В подразделении Macintosh у нас была поговорка: Игрок А нанимает игроков А; игроки B нанимают игроков C это означает, что отличные сотрудники тоже нанимают отличных

Гай Кавасаки

Каждый нанятый сотрудник должен быть лучше, чем 50% тех, кто в настоящее время выполняет аналогичные роли это поднимает планку

сообщение в блоге программы Bar Raiser в Amazon

Всё это хорошие советы. Однако они предполагают, что качество можно надёжно измерить. Но мы уже видели, что это не всегда так.

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

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

Если вам трудно определиться, есть очень простое решение. НЕ НАНИМАТЬ НИКОГО. Просто не нанимайте тех, в ком не уверены

Джоэл Спольски

Оценка кандидатов не является полностью детерминированным процессом, но многие считают её таковой.

Почему планка так высока


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

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

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

Джоэл Спольски

Хантер и Шмидт подсчитали цену плохого найма: Стандартное отклонение составляет минимум 40% от средней годовой зарплаты, что в сегодняшних условиях соответствует $40000, если предположить, что средняя зарплата инженера составляет $100000.

Но если установить планку слишком высоко, есть вероятность, что вы пропустите несколько хороших кандидатов (ложноотрицательные срабатывания). Макдауэлл объясняет, почему компании на самом деле не против большого количества ложнотрицательных срабатываний:

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

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

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

Поскольку все расчёты делаются на глаз, мы можем сделать то же самое и привести аргументы в пользу того, что планку не следует устанавливать так высоко.

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

С другой стороны, затраты на рекрутинг могут оказаться выше, чем предполагалось, потому что кандидатов становится всё труднее подбирать по мере роста их квалификации. По определению, чем выше планка тем меньше таких людей. Расчёт ущерба от плохого найма Шмидта и Хантера сравнивает кандидатов только в пределах пула. Исследование не учитывает относительную стоимость привлечения высококачественных кандидатов в пул, а это серьёзная проблема для многих технических рекрутинговых команд в наше время. А если другие IT-компании используют ту же стратегию найма, то конкуренция увеличивает среднюю вероятность, что кандидат отклонит предложение. Это увеличивает время на заполнение вакансии.

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

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

Однако при найме редко думают о развитии сотрудников (Ласло Бок местами упоминает об этом, но в основном эти темы обсуждаются отдельно друг от друга). Но если всё-таки учесть его, то между наймом и развитием сотрудников можно установить связь. Можно рассуждать о разных методах повышения эффективности труда: или оплата обучения существующих сотрудников, или найм новых.

Вы даже можете считать это компромиссом. Вместо того, чтобы развивать сотрудников внутри компании, почему бы не передать это развитие на аутсорсинг? Пусть другие выясняют, как развивать необработанные таланты, а вы позже заплатите рекрутерам, чтобы они нашли уже готовых профессионалов. Зачем закупаться в продуктовом отделе Whole Foods и готовить дома, когда вы можете заплатить за доставку готовых блюд? Зачем тратить время на управление и обучение, если вы можете заняться реальной работой (т.е. инженерными задачами)?

Возможно, планка установлена так высоко, потому что компании не умеют эффективно развивать сотрудников.

Так что компании снижают риски, переложив бремя карьерного роста на самих кандидатов. В свою очередь, у кандидатов, таких как Рекурсивный Кактус, не остаётся выбора, кроме как тренироваться в прохождении интервью.

Сначала я думал, что Рекурсивный Кактус исключение из правил. Но оказалось, что он не одинок.

Кандидаты тренируются перед интервью


В прошлом году мы опросили кандидатов, сколько часов они потратили на подготовку к интервью. Почти половина респондентов сказали, что потратили на подготовку 100 и более часов[5].



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


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

Пересмотр планки


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

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

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

И это помогает понять, почему Рекурсивный Кактус тратит так много времени на тренировку. Частично это объясняется тем, что его нынешняя компания не развивает его навыки. Он готовится к мириаду возможных вопросов и интервьюеров, с которыми он может столкнуться, потому что критерии найма сильно различаются. Он изучает темы, которые не обязательно будут использоваться в его повседневной работе всё для того, чтобы сойти за тех, кого считают умными.

Такова нынешняя система, которая оказала значительное влияние на его личную жизнь.

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

Рекурсивный Кактус

Это влияет на его нынешнюю работу и на его коллег.

Процесс отнимает немало сил, так что я больше не могу работать на 100%. Я хотел бы справляться лучше, но не могу одновременно и заботиться о своём будущем, практикуя алгоритмы четыре часа в день, и хорошо выполнять свою работу.

Это не очень приятное ощущение. Мне нравятся коллеги. Я чувствую ответственность. Я знаю, что меня не уволят, но понимаю, что на них ложится дополнительная нагрузка

Рекурсивный Кактус

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

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

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

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



[1] Существует некоторый потенциал для предвзятости, особенно в связи с временем, которое кандидаты выбирают для тренировки. Поверхностный анализ показывает, что связь не такая уж значительная, но мы изучаем этот вопрос (возможно, в будущем напишем на эту тему в блоге). Также на сайте можно выбрать между традиционным алгоритмическим интервью и интервью по проектированию систем, но подавляющее большинство выбирает традиционное. Показанные коэффициенты прохождения соответствуют традиционным интервью. [вернуться]
[2] Вы можете задаться вопросом об относительном уровне кандидатов на interviewing.io. Хотя истинный уровень трудно определить (что является основной темой данной статьи), наши интервьюеры-практики говорят, что в среднем уровень кандидатов на interviewing.io соответствует уровню, с которым они сталкиваются в процессе собеседований в собственных компаниях, особенно в процессе телефонного скрининга. [вернуться]
[3] Сюда входят только кандидаты, которые соответствуют нашей внутренней планке найма и приходили на собеседование в наш офис. График не отражает всю совокупность кандидатов, которые проходили интервью. [вернуться]
[4] Возможно, вы помните, что раньше у нас был алгоритм, который корректировал статистику с учётом строгости интервьюеров. При дальнейшем рассмотрении мы обнаружили, что этот алгоритм неожиданным образом вносит дисперсию в баллы кандидатов. Поэтому теперь мы не так сильно полагаемся на него. [вернуться]
[5] Всплески на 100 и 200 часов произошли из-за ошибки в формулировке и максимальных значениях опроса. Были заданы следующие три вопроса: 1)Во время вашего последнего поиска работы, сколько часов вы потратили на подготовку к собеседованию? 2)Сколько часов вы потратили на подготовку к интервью перед регистрацией на interviewing.io? 3)Сколько часов вы потратили на подготовку к собеседованию после регистрации на interviewing.io (не включая время на сайте)? Ответы на каждый вопрос были ограничены максимальным значением 100 часов, но у многих респондентов сумма ответов 2 и 3 превышала 100. Медиана ответов на вопрос 1 составила 94, что почти идентично медиане суммы ответов 2 и 3, поэтому мы использовали эту сумму для распределения, превышающего 100 часов. Ключевые уроки: устанавливайте максимальное значение больше, чем ожидаете, и дважды проверяйте свой опрос. [вернуться]
[6] Я немного затрудняюсь оценить это исследование, потому что я не психолог и методы вроде метаанализа мне немного чужды, хотя в основе лежат знакомые статистические инструменты. Вопрос не в том, верны ли эти инструменты, а в том, что трудно рассуждать об исходных данных исследования. Подобно спагетти-коду, валидация базовых наборов данных распределена по десятилетиям предшествующих научных работ, что затрудняет анализ. Вероятно, такова природа психологии, где труднее получить полезные данные, если сравнить с естественными науками. Кроме того, к методологии возникают и другие вопросы, которые более подробно обсуждаются в этой статье. [вернуться]
Подробнее..

Программирование как вид спорта что делать, чтобы побеждать на соревнованиях

16.09.2020 18:22:11 | Автор: admin
Привет, Хабр! Сегодня я хочу познакомить вас с Андреем Чумаченко, руководителем сообщества по спортивному программированию в Иркутске и титулованным участником соревнований по программированию, в том числе ICPC и Всесибирской олимпиады имени И.В. Поттосина.

Мы поговорили с Андреем про спортивное программирование, подготовку к соревнованиям и про его работу тренером. Под катом полезные и вредные советы участникам соревнований, вопросы мотивации, истории с соревнований, отношение к ЕГЭ и школе спортивного программирования в Иркутске.


Финал студенческого командного соревнования по программированию ICPC, 2016 год (источник: ICPC Live)

Андрей Чумаченко основатель и руководитель сообщества по программированию в Иркутске, студент магистратуры ИГУ по фундаментальной информатике, призер полуфинала студенческого чемпионата мира по программированию ICPC 2018, 2019 (среди стран СНГ), призер Всесибирской олимпиады имени И.В. Поттосина 2018, 2019 (среди стран СНГ), победитель четвертьфинала студенческого чемпионата мира по программированию (среди студентов Восточной Сибири) 2018, 2019, победитель Универсиады Алтая по программированию 2019 (среди студентов и школьников России), финалист чемпионата БГУИР по программированию 2018, 2019.

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


С чем его едят


Что такое спортивное программирование и какие задачи там сейчас решают?

Для меня это в первую очередь соревнования, подготовка к ним и, конечно, особенное сообщество людей.

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

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


2016 год, студенты УрФУ только что выиграли международный чемпионат по программированию Challenge 24 в Будапеште. Тогда в десятку лидеров вошли семь команд из России (источник: codeforces.com)

Какой язык сегодня самый популярный в спортивном программировании? Моя подруга в московском Политехе на прикладной информатике (janka2330) изучала спортивное программирование как предмет и сдавала зачет. Говорит, было круто. Они соревновались с однокурсниками и сдавали задачи на spoj.pl (spoj.com), а писали на Ruby on Rails.

Язык сильно зависит от соревнований. Чаще всего я встречаю С++, также популярны Java, Python. Еще новичок Kotlin в последнее время набирает обороты. Ruby on Rails, да и просто Ruby, редко используют, но на некоторых соревнованиях они были в списке поддерживаемых языков. Я сам всегда пишу на C++, и мои ученики тоже. Мне он кажется наиболее удобным, когда надо быстро что-то закодить.


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


Как готовиться, чтобы победить


Расскажите про подготовку к соревнованиям. У вас наверняка есть свои секреты.

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

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

Затем мы отслеживаем прогресс, сравниваем результаты и устраиваем разбор задач, чтобы в следующем раунде быть более успешными.


Архив олимпиадных задач codeforces.com

Еще заглядываем на acm.timus.ru крупнейший в России архив задач по программированию с автоматической проверяющей системой. На YouTube сейчас много чего появилось, но на постоянной основе мы его пока не используем. Если интересно, могу посоветовать оттуда крутого польского программиста под ником Errichto, у него свой канал, там можно накопать кучу полезностей.


Второй канал польского программиста под ником Errichto на YouTube

Ну и книги, конечно, как без них: Искусство программирования Дональда Кнута, например. Или Олимпиадные задачи по программированию. Руководство по подготовке к соревнованиям Стивена Скиены и Мигеля Ревиллы.

Лайфхаки для участника


Ок, а что может помешать выиграть на олимпиаде по спортивному программированию?

Наверное, враг всех студентов лень (шучу). А если серьезно, то нужно быть сосредоточенным на задачах и ненадолго отключить ту часть мозга, которая отвечает за всякие насущные дела.

Еще очень вредно тренироваться в ночь перед соревнованиями, тем более если не готовился в течение года.

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

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

А чтобы победить, что нужно делать?

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

Когда идти в программисты


Расскажите про свой путь в спортивном программировании.

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


Андрей разбирает одну из олимпиадных задач на августовских сборах в Иркутске

Вы считаете, что в старших классах поздно начинать? Неужели программирование и вправду можно сравнить с профессиональным видом спорта, в который детей отдают чуть ли не с трех лет?

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

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

Поэтому чем раньше, тем лучше.

ЕГЭ больная тема


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

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

Что же касается ЕГЭ, то это больная тема. Тут я могу наговорить материала на еще одну статью.

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

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

Сейчас в вузы можно поступать и по результатам олимпиад. И это круто для топовых школьников, для 10%. А что делать с остальными? Только ЕГЭ.

Да, есть простые олимпиады третьего уровня из перечня, но они часто еще более несуразны или содержат задачи из ЕГЭ.

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

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

А вы не видите аналогичную шаблонность в оценивании знаний на олимпиадах по программированию? Или там все по-другому?

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

Почему школьники учат спортивное программирование


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

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

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

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

Что вы делаете в рамках своего сообщества спортивного программирования?

Сегодня я тренирую студентов, и мы ездим на олимпиады и соревнования по спортивному программированию. Среди моих учеников призеры четвертьфинала студенческого чемпионата мира по программированию (среди студентов Восточной Сибири) 2019 года, призеры сибирской площадки полуфинала студенческого чемпионата мира по программированию ICPC 2019 года, призеры Универсиады Алтая по программированию 2019, финалисты олимпиады имени Поттосина 2018 и 2019 годов.

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

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

Плюс мы организуем соревнования по программированию, а не так давно провели интенсив, который длился 11 дней. Почти каждый день были пятичасовые соревнования, за которыми следовал разбор задач так называемая работа над ошибками, и лекции (немного теории про алгоритмы). В качестве тренеров выступали я и мой товарищ из МИФИ. Участниками интенсива были школьники из центра олимпиадной подготовки ENTER из Улан-Удэ (Республика Бурятия) и студенты из Иркутска, которые регулярно участвуют в олимпиадах по спортивному программированию.


Августовский интенсив по спортивному программированию в иркутской Точке

Был у меня такой случай


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

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

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

Поделитесь интересными историями с соревнований.

Все наши забавные истории обычно связаны с задачами. Например, я однажды долго мучился над решением, потому что не заметил, что фразу no solution нужно было вывести с переставленными в одном месте буквами no soluiton.

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



Минутка рекламы про наш акселератор AI-проектов

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

Отбор и программа преакселерационной подготовки бесплатные. А если вы пишете о своем проекте на Хабре вам плюс в отборочный рейтинг! О самых интересных проектах расскажем в нашем блоге.

Подробнее..

Пётр Соболев Мы просто смотрели, как что-то там летает, и тащились от того, как это сделано

16.09.2020 20:14:52 | Автор: admin


Демосцена разновидность творчества на стыке компьютерной графики, музыки и, собственно, программирования, а также сложившаяся вокруг него субкультура. Первые демоэксперименты относятся к 1980-м времени, когда в Европе и США появилось достаточное количество домашних компьютеров, обладатели которых стремились заставить машину выполнять несвойственные ей задачи. Обычно это были короткие интро к взломанным компьютерным играм, созданные на Commodore 64, Amiga, ZX Spectrum. Расцвет демосцены пришелся на 1990-е, тогда же она пришла и в Россию.

Пётр Соболев, также известный как frog, один из организаторов компьютерного фестиваля ENLiGHT первой в России демопати. В первой части интервью музейному проекту DataArt он вспоминает компьютеры 1980-х и рассказывает, как в нашей стране появились первые интро и демо.

Начало


Я родился в Ленинграде в 1973-м. Мать и отец были инженерами-конструкторами в оборонке. В детстве я увлекался всякими железками, что-то паял по мелочи какие-то простые схемы. Семья никакого отношения к вычислительной технике не имела, но в середине 1980-х в СССР возникла идея, что надо форсировать все, что связано с ЭВМ, и внедрять на производстве. У отца на заводе тоже стали этим заниматься. Закупили ЭВМ Искра 226 аналог Wang 2200, что-то среднее между домашней и профессиональной машиной. Она на микропроцессорных секциях собрана, такая специфическая архитектура, не похожая ни на что, в качестве основного языка там был Бейсик. Отец стал в этом участвовать, потому что на заводе в вычислительной технике никто не разбирался и любой, кто проявлял инициативу, мог взяться за это дело.


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

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


Справочное руководство для специалистов и всех желающих использовать в своей деятельности возможности программно-управляемых ЭВМ, 1988 г.

Помню, в середине 80-х отец принес домой здоровенную распечатку по R-Base. Тогда это была достаточно популярная СУБД. В какой-то момент он позвал меня на завод, посмотреть на компьютеры. Но я интереса не проявил.

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

Недокументированные возможности


Следующим этапом моего знакомства с вычислительной техникой стали микрокалькуляторы. Шел где-то 1986-й год. Мне купили МК-54. Базовых программируемых калькуляторов в середине 80-х в СССР было два Б3-21 и Б3-34. На тот момент ни тот, ни другой уже не продавался. МК-54, что мы купили, был совместим с Б3-34.


Демонстрация работы программируемого микрокалькулятора Электроника МК-54

Надо сказать, что у Б3-21 и Б3-34 разные системы команд, разная архитектура, а все книжки, которые мне попадались, были, к сожалению, про Б3-21. Это стало большой проблемой, потому что программирование для калькуляторов было, по сути, в машинных кодах. Ты некие значки вводишь, получается программа длиной, допустим, 100 команд. Она какие-то расчеты производила, или можно было сделать простую игру типа крестиков-ноликов, где тебе выдается номер поля, в которое ты мысленно или прямо на бумаге ставишь крестик, а в какое нолик. Всё очень примитивно. Индикатор цифровой, никаких букв. Ну и никакой интерактивности в процессе работы программы.

В 1986-1987 гг. в журнале Техника молодежи начала публиковаться серия рассказов Михаила Пухова смесь научной фантастики и программ для калькулятора, чтобы читатель мог сам что-то запустить и попробовать. К примеру, посадка на Луну: вводишь цифрами тягу, направление, нажимаешь пуск, калькулятор считает и показывает, сколько осталось до поверхности. Сейчас это звучит смешно, а тогда было очень необычно и интересно.


Коллекционер и историк вычислительной техники Сергей Фролов рассказывает, как читатели с помощью микрокалькуляторов участвовали в игре через журнал. Из интервью Музейному проекту DataArt

Затем был куплен следующий калькулятор МК-61. Тогда это было целой проблемой из-за дефицита. Даже если есть деньги, ты не мог пойти в магазин и приобрести, что хочешь. Надо было ждать, искать. В какой-то момент мне повезло: зашли в Электронику на Гагарина единственный большой магазин такой тематики в Питере и купили этот калькулятор. Он был немного получше старого, на нем шло больше программ.


Магазин-салон Электроника на проспекте Гагарина в Ленинграде был еще и важным местом встречи радиолюбителей с перекупщиками деталей. Источник фото

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

Параллельно появилась еще одна тема. В журналах Радио, Моделист-конструктор, Юный техник стали публиковать статьи по сборке самодельных компьютеров. Выбор был не очень большой. В Юном технике, по-моему, о Микро-80 рассказывали. Помню точно, что была серия статей про какой-то модульный компьютер, где ты сначала собираешь что-то без подключения к телевизору, с индикатором простым и несколькими кнопками. Затем контроллер монитора, потом еще что-то. Там была нужна куча микросхем собрать это было для меня совсем нереально. В журнале Радио публиковалось описание Радио-86РК, со схемой попроще, но там было не достать микросхему контроллера дисплея 580ВГ75 тоже дефицит. Все остальное пожалуйста, а вот ее нет.


Тестовый образец персонального компьютера Радио-86РК, предназначенного для сборки радиолюбителями, из коллекции DataArt

Чуть позже, в журнале Моделист-конструктор стала публиковаться схема компьютера Специалист. Еще выходил профессиональный журнал Микропроцессорные средства и системы, уже не для радиолюбителей. Там печатали схему ещё одной ЭВМ Ириша более серьезной, чем вышеупомянутые. Как и предыдущие, она была основана на микропроцессоре 580ИК80, аналоге Intel 8080. Возможности впечатляли, но машина была очень сложная, с кучей микросхем, в том числе, редких.

В условиях дефицита


Еще один интересный момент. В то время каждое предприятие считало своим долгом изобрести собственный компьютер. Сейчас это кажется глупым, все думают о совместимости. Если соберешь свой компьютер, что будешь на нем запускать? Тогда этот вопрос не стоял, потому что программ не было никаких. Если соберешь и хорошо работает ты молодец. Отец приносил схему ЮКУ (Juku эстонский компьютер. Прим. ред.). Я пытался искать, что это вообще такое никаких следов. Тоже на 580ИК80, схема достаточно простая. Мне приносили платы, я пытался паять, но быстро забросил, потому что радиолюбитель из меня никакой. Что-то простое паял, но собрать компьютер, тем более редкий и непонятный конечно, не мог.


Juku E5101 персональный компьютер, производившийся на заводе Балтиец в Нарве в 19881991 гг. Из коллекции эстонского Музея компьютерной техники

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

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

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


Плата ZX Spectrum-совместимого компьютера такую же спаял и использовал прямо без корпуса Пётр Соболев. Источник фото

Информатика в спортивной школе


Году в 87-м у нас в школе начались уроки информатики. Это последние два класса 10 и 11. Компьютеров в школе не было никаких. Максимум несколько калькуляторов. И на первом уроке нам просто рассказывали о Бейсике, а мы смотрели на доску и записывали в тетрадку операторы. Потом нас стали водить в соседнюю спортшколу на Брянцева, в которой стояли компьютеры Commodore 64. Достаточно необычная тема для СССР, потому что тогда в образовании использовались в основном отечественные Корветы, Агаты, либо закупались Ямахи MSX-2 по договорам с японцами.


Компьютер Commodore 64 поступил в продажу в августе 1982 года. За 12 лет было продано более 15 млн компьютеров

Мне повезло, эти Commodore 64 хорошие машины. По тем временам для нас просто верх. Отличные цветные мониторы, клавиатура, звук. Значительно лучше, чем в Спектруме, и уж тем более в Радио-86РК и прочих. Соответственно и игры, в большинстве своём, были лучше.


Скрин отладки ассемблерного кода

Нас привели в класс, посадили по два человека за каждый компьютер, включили. Там сразу Бейсик и мигает курсор. Помню, на первом уроке мы просто гоняли курсор по экрану и радовались. Нам показали, как менять цвет курсора. Это нас, конечно, заворожило. Думаю, если бы компьютеры были чёрно-белые, скорее всего, мы бы так не заинтересовались. Но вот этот приятный синий экран с курсором любого из 16 цветов, нас, конечно, привлёк.

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


Справка о посещении факультатива по информатике. Из личного архива Петра Соболева

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


Игра Ghost'n'Goblins, выпущенная в 1985 году для аркадных автоматов и позднее портированная на другие платформы, в том числе и Commodore 64

Когда народ уходил, но оставался кто-то из учителей, мы, бывало, играли. В Arkanoid, который очень качественно был сделан в плане звука и графики. Я его потом много на каких машинах видел, могу сравнивать. Была игра Ghost'n'Goblins, где чувак ходил по кладбищу с привидениями. В трехмерной игре Driller надо было разбираться, куда пойти, что сделать, куда выстрелить, чтобы что-то переключилось и открылось. Типа квеста. Помню, мы рисовали карты на листах А4. Поскольку эта игра к нам не в коробке попала, а просто в виде файла, мы вообще не понимали смысл того, что там происходит. Когда нарисовали, и увидели додекаэдр, поняли, что это вроде планета какая-то. Ещё хорошая игра была Cauldron II: прыгал там такой колобок по комнаткам, где обитали привидения, всякие скелеты, и надо было что-то собирать. Стандартная игра тех времен. Сидели, разбирались, тоже рисовали карты. Играм и чему-то серьезному мы, наверное, 50 на 50 уделяли внимание.


Инструкция, как пропатчить код игры DRILLER, оставленная одним изнас вшколе наБрянцева ($EA инструкция NOP процессора 6502). Пётр Соболев

Лаборант


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

Подготовительные экзамены я провалил. По физике попался 19-й билет (как сейчас помню), на который я не ответил. Пошел сдавать обычные экзамены с потоком и провалил еще раз мне попался тот же самый билет. Ну, естественно, я его не стал учить кому попадается один и тот же билет дважды! Оказалось, мне. Я пролетел, но по возрасту до армии оставался год. Пошёл работать лаборантом в ЛИТМО. Тогда он не был так известен, как сейчас. Обычный технический вуз, как ЛЭТИ, ЛИАП и многие другие. Лаборантом я стал на кафедре вычислительной техники. В мои обязанности входило подпаивать на стендах провода, которые со всей дури выдергивали студенты, и раз в месяц выносить мусор из аудитории. Дальше я мог заниматься, чем хочу.

В аудитории, в которой я работал, стояла Искра-1030. Такая советская PC/XT с 512 килобайтами памяти и зелёным монитором ужасного качества, от которого очень уставали глаза. Я на ней пытался что-то делать. В соседней аудитории через коридор стояли Искры 226, как у отца на работе. По сравнению с Искрой 1030, они были еще хуже. На этой можно хоть какие-то вещи запускать, для PC предназначенные. А там вообще ничего только Бейсик, по сути.


Рабочая среда Turbo Pascal 4.0

На Искре 1030 я что-то писал на Turbo Pascal 4.0. Это первый Turbo Pascal, где появилась более-менее нормальная среда с менюшками. Про игры там говорить тяжело, потому что на такой машине нормальные игры не работали. Какие-нибудь Xonix, Тетрис, с трудом Prince.

Потом в той же аудитории появился болгарский Правец 16. Это тоже PC/XT, но повыше уровнем. Там уже шли многие вещи, но монитор тоже был черно-белым.


Игра Commander Keen 4 на Правец 16

Рядом с нашей аудиторией была аудитория заведующего лабораторией, основная на кафедре. Там стояла PC AT 386SX/16 очень крутая машина по тем временам. На ней шли игры, была хорошая графика, правда памяти там было, вроде, всего 1 MB. Когда машина была свободна, без проблем можно было за ней сидеть. Преподаватели сотрудники кафедры, видели, что я чем-то интересуюсь, а не просто пришел поиграть и не возражали.

Домашние компьютеры


Была при этом параллельная история, которая началась чуть раньше, до института. В годы перестройки мы начали мириться с США, пошли общие темы, и многие пытались делать какой-то свой бизнес, хотя никакого представления о бизнесе у советских людей не было. Почитали, посмотрели фильмы и вперед. Друг нашей семьи открыл совместное предприятие с американцами. Контора называлась Вабог, потому что его звали Валерий Боголюбов. Под это дело ему из Америки привезли компьютер PC/AT 286. 640 килобайт памяти, 20 МГц тогда это было очень круто, тогда даже PC/XT 8 Мгц считалась серьезной машиной. Компьютер был с цветным монитором, правда, CGA. Приехало это всё в большом, окованном по краям железом, сундуке, который у меня до сих пор дома лежит и все, кто видят, спрашивают, что это такое. Поскольку наш друг понятия не имел, что с этим компьютером делать, а я тогда как раз всем этим увлекался, он нам его на время отдал.


Тот самый сундук

Компьютер стоял у меня дома. Там был DOS. Ты компьютер включаешь, с дискеты загружаешься. Мигает курсор, написано MS-DOS, версия 3.10 и всё. Текстовый режим, никакой графики. Сначала я пытался команды изучать, потом кто-то дал пару дисков с играми, тот же Turbo Pascal, что-то еще. Затем, когда этот компьютер унесли, к тому времени я уже окончил школу, домой купили Commodore 128. Это такая странная, даже по тем временам, машина попытка фирмы Commodore усидеть на двух стульях. С одной стороны, они старались не потерять любителей Commodore 64, которые очень любили игры их для 64 было много написано. С другой стороны, пытались влезть в бизнес, чтобы текстовые редакторы с 80 столбцами нормально работали. Электронные таблицы вот это вот всё. Забегая вперед, это им не удалось. Не они одни были такие умные. То есть, фактически, они в один компьютер запихали целиком схему Commodore 64 и рядом присобачили Z80 и еще один видеоконтроллер, который на другой монитор выводил 80x25 текст. Ну или 640x200 монохромную графику. Фактически, это был двухпроцессорный компьютер, в котором работать параллельно процессоры, конечно, не могли. Ты должен был выбирать. И два видеовыхода на два монитора.


Телевизионная реклама Commodore 128, 1985 г.

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

Впрочем, полезного я ничего сделал. Ни одной демки или интры ничего. Всё, что я тогда писал это какие-то полуфабрикаты. Допустим, я разобрался, как цветные полоски рисовать красивые и, удовлетворенный, делаю что-то другое. То есть, фактически, написание сводилось к тому, чтобы просто разобраться с какой-то темой. Спрайты там, например, или как шрифты перепрограммировать. Разобрался и всё. С Commodore 64 и 128 дело обстояло так. Более-менее что-то законченное я стал писать, уже на PC.

После Commodore 128 следующей домашней машиной была Нивка. Очень странная отечественная PC/XT для применения в промышленности. В тот момент уже всё загибалось конец перестройки, поэтому такие вещи было сравнительно легко купить они особо никому не были нужны.

Это была PC/XT, мегабайт памяти, 4,77 МГц-тактовая, 8086-й процессор (не 8088!), с цветным CGA монитором. Фишка была в том, что эта машина была в форм-факторе Full Tower. Я долго развлекался с этим компьютером, разгонял его. То ли кварц поменял, то ли перемычки переставил, сделал 8 или 10 МГц. При этом контроллер дисковода стал смешно выскакивать из кроватки. Видимо, нагревался. Там кроватки советские были, из них выскакивало всё при любом удобном случае. Нитками примотал заработало стабильно.

Рейтрейсинг


В институте кроме Правеца и 386SX появились и другие машинки. В мою учебную аудиторию поставили PC/AT 286 c EGA адаптером. Еще там был Amstrad PC1640 с монохромным EGA. Интересно, что эта PC/AT 286 с цветным EGA была югославской, причём в военном исполнении. Серьезная вещь. Металлический корпус очень грубый, с ребрами охлаждения, монитор соответствующий, обрезиненный со всех сторон. Если ударят, чтобы амортизировал. Неплохая была машинка. 16 МГц, по-моему.

В комнате заведующего лабораторией поставили еще две штуки PS/2 модель 50. Это были PC/AT 286, по-моему, около 20 МГц с шиной Micro Channel (MCA). Графика у этих машин была MCGA (MultiColor Graphics Adapter). Это такое VGA, только без высокого разрешения. Можно было выводить 320x200, 256 цветов. Точнее, в нашем случае, 64 градации серого, т.к. мониторы были чёрно-белые. На PS/2 мы впервые пробовали развлекаться рейтрейсингом обсчитывали всякие красивые стеклянные сферы, которые друг в друге отражаются и преломляются.

Рейтрейсинг это один из алгоритмов получения фотореалистичного изображения. Ты пишешь программу, задаешь в ней простые примитивы: сферу, куб, плоскость, источник света. И она тебе долго и нудно рисует по точкам все отражения и как что преломляется. Получается красиво.

Тогда 3D пакеты типа, скажем, Maya, были только на дорогих и недоступных почти никому компьютерах типа Silicon Graphics. На PC же всё только начиналось. Обсчитать самому красивую картинку при помощи собственной программы это было круто и вполне адекватно.

Студент


После года работы лаборантом и развлечениями с компьютерами я решил, что логично поступить в тот же ЛИТМО. У ребят из моего класса, которые год отучились в Политехе, разговоры были только об учебе, ни о чем другом они даже думать не могли, что настораживало. Здесь тоже была не совсем халява, но поспокойнее. Поэтому я стал поступать в ЛИТМО на кафедру вычислительной техники, однако по баллам не прошел. Помню, пошел к замдекана, отвечавшего за приём. Взял с собой человека с нашей кафедры для авторитетности. Говорю: Я хочу на ВТ. Он показывает список: Это дочка одного, это сын другого. Извини, не могу!. В итоге я попал на только что созданную кафедру мехатроники, и процентов 60 людей на ней были вроде меня те, кто не прошел на ВТ.

Мехатроника это, грубо говоря, приборостроение, смесь электротехники, электроники и механики. Естественно, вычислительной техники там особо никакой не было. Было всякое ТОЭ, сопромат, конструирование, материаловедение По диплому я, в итоге, инженер-электромеханик. Что касается компьютеров, у нас были раз в несколько недель занятия по специальности прикладная математика на СМ-4. Стояла она в отдельной комнате за стеклом и мигала лампочками, как в фильмах. Очень модно. По другую сторону стекла стояли 6 терминалов с черно-зелёным текстом. Многопользовательская такая машина. Студенты пытались что-то вводить, но это была жесть. Чтобы написать программу, ты должен был запустить текстовый редактор. Он сколько-то запускается, у тебя появляется курсор. Вбиваешь эту программу, потом выходишь из редактора, запускаешь компилятор, линкер. При этом всё, как правило, периодически падает, ты начинаешь заново. Я там был один-два раза, потом понял, что больше не хочу. Романтики не ощутил совсем и стал думать, что делать.


ЭВМ СМ-4 с 1979 года выпускалась в СССР, Болгарии и Венгрии

Программы надо было писать на Фортране. Тогда это был достаточно популярный язык для вычислений. И я решил: пойду домой, сяду за нормальный PC (Нивку), напишу на Паскале. Там достаточно простой алгоритм задания. Потом распечатал результаты на принтере, взял книжку по Фортрану, полистал, посмотрел, какие там операторы есть. Взял программу на Паскале и поменял оператор на Фортрановский. Причем, я не понимал многих вещей. Например, что строки надо отделять в Фортране табами и так далее. В общем, заменил, чтобы похоже было. Распечатал результаты, пошел сдавать преподавателю. При этом не скрывал, что делал на PC. Тот посмотрел. Странно, говорит. Вроде на Фортране это не должно работать. Но результаты-то правильные! Прокатило. Такая была сдача зачета.


Университет ИТМО, Санкт-Петербург, переулок Гривцова. 2008 г.

Государство в государстве


ЛИТМО стал известен за счет парфёновской кафедры (В 1991 году по инициативе профессоров Парфёнова и Васильева в СПбГУ ИТМО начался проект по созданию системы для подготовки и трудоустройству одарённых школьников и студентов. Прим. ред.). Когда я поступал, ректором был Новиков. В последние годы моего обучения его сменил Васильев. Компьютеров у нас было очень мало, в учебном процессе их не задействовали вообще, кроме СМ-4. Парфёновская кафедра располагалась в подвале. Там отдельная дверь, в ней глазок с камерой. По тем временам прямо как банк иностранный. Однажды я туда пришел что-то забирать и был просто в шоке.


Основатели кафедры Компьютерные технологии: Владимир Васильев, Владимир Парфенов и Алексей Сигалов, на банкете выпускников ЛИТМО в 1990 г. Источник фото

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

Знакомство с демосценой


В соседней школе, куда нас водили в детстве на Commodore 64, у учителей был некий набор программ. Среди них попадались такие, которые ни для чего не были предназначены просто показывали под музыку красивые графические эффекты. Мы иногда ставили и смотрели, поскольку прикольно. Но мы, конечно, не знали, что такое демосцена и демки. Сейчас все ходят в интернет, читают иностранную прессу, книги, смотрят новости а тогда этого не было. Об иностранной культуре мы практически не имели представления. Всё, что знали, из фильмов, которые проходили цензуру, то есть достаточно нейтральных. Тоже самое касалось и музыки. Поэтому для нас многие вещи были в новинку.
В последний год хождения в школе на Commodore 64 у нас стали заводиться знакомства с людьми, у которых этот компьютер стоял дома. В основном, это ребята, у кого родители ездили в загранку. Дальнобойщики, моряки люди, которые оказывались за границей и могли там что-то покупать. Было 3-4 человека, у которых оказался Commodore 64. Мы ездили к ним домой, обменивались софтом. Сетей нет, модемов нет. Просто приходишь с пачкой дискет (по 300 кб) и говоришь: У меня есть то-то и то-то. Давай посмотрим. Ставили в дисковод, смотрели: О, это мне интересно. Копируем. Были программы-копировщики. Запускаешь, она пишет: Вставьте диск исходный. Вставляешь: Вставьте диск, куда копировать. Так несколько раз. На копирование одного диска уходило минут 10.

Так постепенно у нас появлялось что-то новое. Тогда я познакомился с одним человеком Кириллом Антоновым, никнейм GhostRider. Не знаю, куда он исчез, много лет назад растворился в воздухе. У него был Commodore 64, при этом он более-менее знал английский язык и переписывался с иностранцами. Он установил контакты с некоторыми группами, которые чисто для души занимались написанием программ: музыка, графические эффекты какие-то. Кирилл им писал, они ему присылали диски. Тогда мы начали проникаться понятием демосцена.


Hello GhostRider! Письмо Кириллу Антонову из-за границы, написанное на конверте с дискетой, содержащей программы

Что нам попадало в руки? Во-первых, программы, где что-то красивое показывается на экране под музыку. Во-вторых, программы-журналы. Запускаешь diskmag (disk magazine Прим. ред.) как исполняемый файл. Тебе выводится меню. Там статьи, интервью. Заходишь, читаешь. Были еще noters тоже исполняемые файлы. Типа diskmag'ов, только из одной статьи. Как сейчас в архивах кладут README-файлы. Тогда их не было. На Commodore 64 текстовых файлов, как таковых, не было вообще. Потому что не было единого формата текста, который могли бы читать все программы. Включаешь компьютер у тебя один Бейсик, можешь только загрузить и запустить что-то. Поэтому все эти readme были в виде исполняемых файлов и это был большой плюс в плане возможностей самовыражения. Люди писали такой исполняемый readme, запускали. Текст мог появляться разными шрифтами, разными способами. Иногда он появлялся постепенно, как будто от пишущей машинки. Имитировалось стирание будто человек прямо при тебе пишет. И под музыку. Были noter'ы специальные, когда ты мог не только прочесть текст, но и написать ответ. Нажимаешь кнопочку, у тебя появляется курсор, и ты это все можешь писать сам. Потом нажимаешь другую кнопочку, делается копия исполняемого файла, только с твоим текстом. Можешь добавить музыку свою, если хочешь.

История интро и демо


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


Cracktro конца 1980-х (короткое интро, предваряющее взломанные игры) группы Xadez Society для Commodore 64

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

Допустим, кто-то сломал игру, чтобы скопировать и нелегально распространить, потом кто-то следующий сделал в ней бесконечные жизни. Он тоже добавлял свое интро. Когда запускаешь такой диск, сначала одна интра показывается, потом другая, третья. До пяти бывало. В каждой команде были так называемые swapper'ы, которые занимались пересылкой дисков по почте. Таким вот образом это всё дошло до нас.


Cracktro 1990 года (короткое интро, предваряющее взломанную игру 3D International Tennis) группы IKARI для Commodore 64

Вопроса, зачем это делается, не возникало. Было очевидно, что это интересно. Ты сделал прикольную вещь, другие оценили. Потому что, если к тебе попал Commodore 64 в голом виде, без всего, только лишь со встроенным Бейсиком, ты ничего подобного не сделаешь даже близко. Надо писать на ассемблере, очень хорошо знать, как работает оборудование, как программировать видеочип, звуковой чип. Надо понимать, как все это оптимизировать и как запаковать в небольшой объем кода. Потому что, когда эти интры лепили к играм, сама игра ведь всё равно должна как-то влезать на диск и грузиться достаточно быстро.

Запаковывалась игра, к ней присобачивалась интра, тоже запакованная. Типа архивирования. При запуске интра распаковывала сначала себя, показывала. Потом ты нажимал пробел, она распаковывала игру или следующую интру. Использовалась вся доступная память, в том числе, экранная. Часто можно было видеть, как на экране что-то мельтешит, то есть, это код распаковывается прямо в экранную память. Это всё было очень необычно и интересно. Было видно, что каждый человек, который что-то делал, вложил часть своей души, потратил время, чтобы добиться цели какого-то эффекта, чего-то необычного. Он по-новому использовал оборудование, которое есть.

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


Демо Red Storm группы Triad для Commodore 64

Помню, меня впечатлила демка Legoland группы Fairlight. Там была такая часть при помощи рейтрейсинга летали зеркальные шарики вокруг какого-то столба, с отражениями. Понятно, что на Commodore 64 этого сделать было нельзя, просто потому, что там процессор был 6502 1 МГц. Авторы же просто взяли более мощную машину Commodore Amiga, все это сделали покадрово, потом собрали такой мультик. Но тогда нам это было неочевидно, складывалось впечатление, что это реально происходит.


Демо Legoland группы Fairlight для Commodore 64

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

Как выглядят интервью дизайнеров и UX-специалистов в топовых ИТ-компаниях

24.09.2020 20:09:56 | Автор: admin

В нашем блоге мы много пишем о карьере в сфере ИТ, но обычно раскрываем темы, связанные с поиском работы инженеров и программистов. Сегодня же речь пойдет о том, как устроен процесс собеседований дизайнеров в топовых ИТ-компаниях уровня FAANG (Facebook, Amazon, Apple, Netflix, Google). Поехали!

Как устроен процесс

В большинстве случаев процесс собеседований на дизайн-позиции во многом схож с тем, как интервьюируют разработчиков. Вот как описывает этапы бывший дизайнер Google Тони Аубе (он также проходил собеседования в Apple, Amazon и Facebook):

  • первый контакт;

  • созвон с рекрутером;

  • дизайн-челлендж;

  • on-site интервью;

  • принятие решения о предложении работы.

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

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

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

С помощью бота g-mate (@g_jobbot) вы сможете получить доступ к дизайн-вакансиям топовых ИТ-компаний в десятках стран мира. Просто укажите желаемую зарплату, локацию и профессию, чтобы получать подходящие именно вам вакансии прямо в Telegram.

Что такое Design challenge

Так называется тестовое задание, на которое могут выделять до нескольких дней. В случае Тони Аубе, Facebook и Amazon не предлагали делать такое задание, а в Apple и Google это было обязательным требованием. В обоих случаях оплаты задания не предполагалось. В Google на его выполнение давалась неделя.

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

В Apple задача была более конкретной нужно было придумать редизайн одного из приложений компании.

Главные советы по прохождению такого задания:

  • Важно очень постараться. Если рекрутер говорит, что задание занимает 8 рабочих часов, потратьте все 12. Если просят только вайрфреймы, отправьте полностью готовый UI. Если просят UI дайте интерактивный прототип. Превышение минимальных требований задания показывает мотивацию, а также тот факт, что кандидат сможет расти в компании.

  • Главное качество. Если интерфейс получился плохим, тот факт, что на его создание ушло 30 рабочих часов станет скорее большим минусом.

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

  • Решение должно отражать культуру компании. Аубе говорит, что выполняя задание для Apple думал о том, как в этой компании относятся к деталям. После того, как был готов сам UI, он потратил вдвое больше времени на полировку интерфейса. Кандидат даже сделал полностью анимированный прототип.

В каждом из двух случаев рекрутеры говорили Аубе, что были впечатлены качеством решения. Он прошел этап с design challenge как в Google, так и в Apple.

Помимо этого другой UX-специалист из Netflix в своем блоге на Medium поделился полезными ссылками для прохождения интервью на дизайн-позиции в крупных ИТ-компаниях:

Как проходят личные интервью

По словам Аубе, on-site интервью продлились почти целый день с 9-10 утра до 15:00-17:00. День включал в себя:

  • Презентацию портфолио (~1 час).

  • Общее интервью (45 минут).

  • Общение за обедом (~1 час).

  • Техническое интервью (45 минут).

  • Дизайн-ревью (45 минут).

  • Whiteboard exercise (45 минут).

Важно понимать, что от компании к компании порядок этапов может меняться, а некоторых из них может не быть вовсе.

Презентация портфолио

Для презентации портфолио отлично подходят советы Шэнцзе Чжан (Shengjie Zhang), которая проходила собеседования в Google, Facebook, Twitch, & Slack и в итоге работает в Google.

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

  • Вам будут задавать вопросы. Важно быть готовым ответить на них максимально детально, но не уходить в оборону. Вопрос может звучать так: Почему вы выбрали именно этот метод? Рассматривались ли другие опции, например xxx?

  • Очень важно показать влияние на продукт. Дизайнерам нравится влиять на продукт, так что когда они видят, как ваша работа принесла результат это им понравится. Стоит разделить влияние на 2-3 разных уровня детали дизайна, направление развития продукта, какие выгоды получили стейкхолдеры.

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

Дизайнер Кирилл Зима, который живет в Амстердаме, работает в Verifone, и ранее работал в Booking.com, а также проходил собеседования в ряд компаний из списка FAANG добавляет такие вопросы, к ответу на которые стоит подготовиться:

  • Как вы пришли к такому дизайн-решению?

  • Как проводились исследования?

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

  • Все ли в команде с ним были согласны, и если нет, то как вы их убедили?

  • Приведите пример вашего неудачного решения, как это произошло?

  • Какие уроки вы вынесли из этого?

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

Бонусный совет от Тони Аубе:

  • На интервью в Google используйте Google Slides, в Apple только Keynote.

Техническое интервью

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

  • Какой софт вы используете в работе?

  • Как вы передаете результат работы инженерам?

  • Насколько хорошо вы разбираетесь в технологии, с которой предстоит работать? (HTML/CSS, Swift, iOS, Android, Unity)

  • Есть ли у вас какие-то дополнительные навыки, вроде 3D, анимации, иллюстрации, фотографии и т.п.?

  • Также вас могут попросить открыть ноутбук и показать, как хранятся файлы по текущему проекту это показывает организованность кандидата. Может ли он легко найти нужный файл? Корректно ли он группирует и называет слои?

Дизайн-ревью

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

  • Каково ваше первое впечатление от дизайна?

  • Нравится ли онбординг?

  • Дизайн этого приложения хорош или нет?

  • Что думаете о цветовой палитре? Как вам лого и иконки?

  • Что бы вы улучшили здесь с точки зрения интерфейса и UX?

  • Как вы думаете, почему разработчики приложения сделали X именно так? Как бы вы улучшили это решение?

Совет: к такому интервью нужно готовиться. Для этого можно развить навык мысленно оценивать каждый встреченный в жизни интерфейс.

Whiteboard exercise

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

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

  • Не нужно сразу бросаться рисовать. Это ловушка. Задача будет специально сформулирована слишком широко. Чтобы предложить более-менее подходящее решение ее будет необходимо сузить с помощью дополнительных вопросов (именно этот подход подразумевает модель STAR). К примеру, вас могут попросить создать дизайн для превосходного процесса дарения подарка. Тут можно спросить кто будет использовать эту функцию, какие подарки можно будет дарить, кому они предназначаются, какие сейчас есть главные проблемы в процессе? И уже затем можно переходить, например, к решению одной из проблем, которую вам назовут. И решение это вовсе не обязательно мобильное приложение, не надо мыслить в жестких рамках.

  • Объясняйте свой ход мыслей. Задача будет иметь несколько решений. Выбрать будет тяжело поэтому думайте вслух. Расскажите о плюсах и минусах тех решений, что вы видите. Объясните, почему склоняетесь к какому-то из них. Скажите, что в работе бы вы провели тесты для всех из них, но прямо сейчас идеальным кажется вот этот вариант.

  • Важно исследовать культуру компании. Даже в рамках FAANG культура сильно разнится, важно понимать отличия, сразу соотносить их со своими пожеланиями. Тогда уже на собеседовании выше шансов не испытать негатив, а приобрести полезный опыт.

Используйте бот g-mate (@g_jobbot), чтобы получать вакансии по своему профилю от ИТ-гигантов и стартапов прямо в Telegram. Компании могут опубликовать первые 3 вакансии бесплатно переходите по ссылке.

Другие наши статьи о прохождении собеседований и поиске работы в ИТ-компаниях:

Подробнее..

Пётр Соболев В отличие от анимации, демосцена подразумевает написание кода

24.09.2020 22:04:44 | Автор: admin


Во второй части интервью музейному проекту DataArt Пётр Соболев, также известный как frog организатор фестиваля ENLiGHT вспоминает историю европейской демосцены и первую российскую демопати в коммуналке, переделанной под офис Федерации шейпинга.

Напомним, что в первой части речь шла о компьютерах 1980-х и знакомстве с первыми интро и демо.

Частичка души


Полноценную демку я ни разу в жизни не написал. Несмотря на то, что очень этим увлекаюсь и фестиваль организовывал. Фактически все вещи, которые я делал, были интро. Первую написал в 1994-95 гг. в связи с тем, что мы организовывали в Питере ENLiGHT'95 первую в России (и странах бывшего СССР) демопати. Не скажу, что та интро что-то собой представляла заняла она то ли последнее, то ли предпоследнее место. Но я на самом деле не особо и старался просто хотел, чтобы моя работа была на фестивале. Там у меня в хитром видеорежиме имитировалось сражение процессоров Pentium и 6502. Типа они летят друг на друга, в итоге 6502 стоит с копьём над Pentium, и кровь стекает.


Титры той самой интро, в которой 6510 Победоносец поражает Pentium

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

Кроме того, раньше каждый процессор, каждая архитектура, каждый видеоконтроллер, любой компьютер имели некую индивидуальность. Тот же Commodore 64. Его люди делали не потому, что маркетинговый отдел им сказал, будто компьютер с таким процессором и таким программным обеспечением будет продаваться. Они просто решили: так будет правильно. Процессор 6502 выбрали, потому что могли позволить себе по деньгам. Сделали такой звук, потому что человек, который его разрабатывал, начинал с синтезаторов. Он хотел, чтобы в Commodore 64 были реализованы схожие возможности никто не давал ему распоряжений. В каждой такой платформе была частичка души разработчиков. Это очень чувствовалось.

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


Интро No shaders размером 256 байт, созданная Петром Соболевым для игровой консоли 1977 года RCA II Studio. Заняла 4-е место в категории Tiny intro compo на фестивале СС2018

История демопати


Идею фестиваля мы подсмотрели за рубежом. В конце 80-х в Европе, в том числе Восточной, стали организовывать что-то типа copy party. Вот мы обменивались софтом, и то же самое делали они, только у них было гораздо больше людей и софта. Заодно пиво или что-нибудь покрепче. Постепенно на таких копипати стали возникать идеи: Давайте мы не просто соберемся и что-нибудь скопируем, а еще покажем, что умеем, что сделали сами. Стали приносить и показывать свои интро и демки. За пару лет это вылилось в то, что теперь называется демопати. То есть люди уже целенаправленно собирались в каком-то зале, показывали, кто что принес, кто что написал. Оценивали и восхищались.


Одна из европейских копипати. Конец 1980-х

Следующим шагом стали правила. Потому что глупо, если соревнуются демки, одна из которых занимает целый диск, а другая 1 Кбайт. Несопоставимо. Поэтому придумали и согласовали отдельные категории, например, в 256 байт, 1 Кб, 4 Кб, 64 Кб. Если у тебя ограничение 64 Кб, ты должен очень сильно извратиться, чтобы запихнуть туда достаточно впечатляющий сюжет и звуковой ряд. Тем более, если у тебя 4 Кб, или 1 КБ, или 256 байт. Понятно, что когда человек пишет работу в 256 байт, он в основном думает о коде, а не о том, чтобы музыка была хорошая.
Потом сделали отдельные номинации под музыку и под картинки. В результате с 1992 года появились уже вполне официальные международные демопати, где были совершенно чёткие правила, номинации графики, музыки, демо, интро.

Где-то в 1991 или 1992 году в Скандинавии начали проходить первые демопати. Почему именно там, а не в Америке большой вопрос, на который никто четкого ответа до сих пор не дал. Может, это связано с тем, что люди в странах Северной Европы не слишком парятся о завтрашнем дне и могут себе позволить заниматься чем хотят. В Штатах, несмотря на то, что там тоже были демопати и их пытаются проводить сейчас, демосцена представлена в очень ограниченном виде. Хотя другие, во многом похожие вещи радиолюбительство, например там очень распространены.


Впечатляющая демо на 256 байт от команды RSI. Желающие убедиться в его оригинальности могут скачать исполняемый файл в описании

О появлении демопати мы, конечно, узнали. В начале 1990-х у нас уже были PC, появилась сеть FidoNet, модемы. До нас всё это доходило, мы скачивали работы, смотрели и тоже восхищались. В какой-то момент захотели и сами сделать похожее мероприятие. Начали с эхоконференции FidoNet с названием DEMO.DESIGN своего рода офлайн-форума. Я там устроил, грубо говоря, открытый конкурс по переписке. Сначала это было соревнование типа кто сможет нарисовать треугольник, уложившись в меньший размер кода. Обозначено условие: процессор 286, VGA, например. Потом сделали поинтереснее. Надо было написать небольшое интро в каком-то ограниченном объеме. Народу понравилось нам присылали работы, в том числе, довольно интересные. Был такой Patson, который, как я помню, прислал впечатляющее интро с фейерверком что-то там разлеталось красивое. Часть этих людей, как и на Западе, раньше ломали софт и точно так же переквалифицировались, можно сказать легализовались.


Пётр Соболев в 1990-х. Слева над розетками виден модем USR Sportster (с апгрейдом до HST)

Мы с друзьями организовали группу Realm Of Illusion, от имени которой в 1994-1995 гг. вышло два номера электронного журнала Infused Bytes для PC. Безусловно делались они, с точки зрения как дизайна, так и контента под впечатлением электронных журналов, которые я видел на Commodore 64.


Электронный журнал (diskmag) Infused Bytes. Выпуск 1995 года

ENLiGHT95


В 1994 году мы решили, что надо у нас провести мероприятие по типу демопати. Денег не было в стране тогда были очень большие проблемы с экономикой, спонсоров реклама среди каких-то непонятных личностей интересовала мало. Нас спасло то, что в некоторых фирмах нашлись люди, которым эта тема просто нравилась. Они уговорили своё руководство помочь: не деньгами, а оборудованием и помещением. Один из организаторов, например, работал сисадмином в Российской федерации шейпинга и договорился, что нам на выходные отдадут их офис. Другой человек одолжил у фирмы LANCK два компьютера PC AT 486 с VGA. У кого-то взяли пару телевизоров, чтобы работы видело побольше людей видеопроекторов тогда не было. Ну, может, был один на весь город.

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

В коридоре стояла Сонька маленький контрольный монитор из телестудии. В большой комнате висел здоровый советский телевизор типа Фотон-716. Стояли колонки S-90 и какой-то усилок. Как на любой демопати, объявлялось: Сейчас будут показаны конкурсные работы в такой-то номинации. Дальше на двух телевизорах подряд показывали демки. Зрители запоминали работы, которые им понравились, и на листах бумаги голосовали за первое, второе и третье места по каждому конкурсу. У меня до сих пор эти листочки лежат с 1995 года всё сохранено.


ENLiGHT'95. Кадры с VHS кассеты

Еще был конкурс Real time coders compo. В два захода сажали людей за PC, давали им час времени и задание. Надо было написать код, который красиво преобразует одну заданную картинку в формате VGA в другую. У кого красивее, тот выиграл, размер не важен. Писали на Turbo Pascal, со вставками ассемблера. Участвовали Андрей Заболотный, Mad Max и еще кто-то третий. Написали достаточно впечатляющие вещи.

Так прошли эти два августовских дня. Мы запустили IRC-клиент и в чате писали, что происходит. Тусовка шла непрерывно, конкурсы занимали процентов 10 времени. Это был чуть ли не первый раз, может, за исключением сисопок на Комтеке, когда встречались люди, которые не просто интересуются IT, а конкретно пишут код или хотя бы регулярно смотрят демки. Причём, со всего Союза из Белоруссии, Молдавии, Украины, Москвы, Воронежа Все они общались. Были ребята, которые ломали софт это достаточно близко демосцене. Фидошники были, естественно. Сохранились кадры на VHS, на которых можно увидеть людей, позднее ставших известными.

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


Видеоролик с кадрами первой демопати в Петербурге. 1995 год

ENLiGHT96


На следующий год мы решили демопати повторить. Денег больше не стало, но удалось выбить помещение попросторнее в Кораблестроительном институте на Ленинском проспекте, где была приёмная комиссия. Повесили в холле несколько телевизоров, поставили несколько компьютеров, было больше конкурсов, Интернет поприличнее стал Появился Спектрум, он уже становился основным компьютером отечественной демосцены, много народу под него начало писать. В 95-м Спектрум в конкурсах еще не присутствовал, спектрумисты только присматривались, что это за зверь демопати. Но в 1996-м по полной программе. И организатор свой был у них Володя Ларьков и куча работ.

Иногда смотрю отснятое тогда видео такое впечатление, что на ENLIGHT и CC побывали буквально все, кто хоть как-то интересовался IT.


ENLiGHT'96. Кадры с VHS кассеты

Народу стало больше, может, под 300 человек, и уже появились проблемы с безопасностью. Обеспечить профессиональную охрану мы не могли, потому что денег не было. Народ напивался, спал на столах, местами буянил. Кого-то вывозили, кого-то выносили. Однажды Mad Max запустил трёхдюймовый диск и попал в машину на стоянке. Через 10 минут подъехали тонированные жигули, оттуда вылезли человек пять бандитов и сказали, что надо платить. Mad Max начал возбухать он приехал из Самары, там, видимо, так не было принято но ему объяснили, что будет хуже. Отделался в итоге то ли 200, то ли 300 баксами. Думаю, охранник стоянки позвонил, бригада и приехала. В принципе, она могла тут же фестиваль и прекратить, если бы мы дело не уладили.


Анкета для голосования на ENLiGHT'96. Из личного архива Петра Соболева

ENLiGHT97, последний


В 1996-м было много работ, всем понравилось, на следующий год мы опять решили повторить. В 1997-м демопати принимал Военмех благодаря моему шефу (я поступил туда в аспирантуру после ЛИТМО) нам дали актовый зал. Как и на двух первых фестивалях, была регистрация участников. Стоял стол, и каждый заполнял анкету. Все три года всё было бесплатно. Таким образом мы избегали проблем: до нас не докапывались, ну и вряд ли многие стали бы за это платить. Очередь на регистрацию выстроилась практически до метро Технологический институт. Только по анкетам пришло 1600 человек. И на всех лишь два добровольца, поддерживающих порядок.


Та самая очередь. Фото из личного архива Петра Соболева

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


ENLiGHT97, актовый зал Военмеха

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

После этого мы поняли, что надо что-то менять. Пытались искать спонсоров, но, к сожалению, на тот момент это было нереально. Те, кто были на выставке Инвеком-98 в Ленэкспо, могли видеть странный транспарант ENLiGHT98. Кто-то даже удивлялся: мол, показалось. Нет, не показалось. То была репетиция для небольшого количества человек. Но спонсоров в итоге мы тогда так и не нашли, так что ENLiGHT на этом закончился.

Chaos Constructions


В 1999 году совершенно другие люди, большинство из которых с нами знакомо не было, сделали практически то же самое своими силами. Правда, масштабом поменьше. В школьном актовом зале (по странному совпадению, в двух шагах от школы, где мы когда-то сидели за Commodore 64) они организовали демопати Chaos Constructions'99. Та же идея конкурсы: музыка, демки, графика, около сотни человек народу. Как ENLiGHT95, только проектор у них появился, и в целом поприличнее всё стало.



Публике понравилось, да и нам тоже было интересно. Потом они провели Chaos Constructions в 2000-м, 2002-м, 2003-м. Организаторы бывали разные, но в основном этим занимался Всеволод Потапов с друзьями. Я был на всех СС, два года они проходили в кинотеатре Восход. А перед 2004 годом мы организаторы ENLIGHT и CC договорились попробовать провести очередной фестиваль вместе.

Chaos Constructions'2004 мы провели в ЛДМ, и это был уже другой уровень. Большое помещение, нормальный проектор, первая выставка ретрокомпьютеров (позднее ставшая ежегодной). Приходилось решать достаточно серьезные организационные вопросы, в том числе такие, которые не были видны посетителям. Грубо говоря, все росли: кто-то как организатор, кто-то как программист, кто-то как админ. Никто никому из нас не платил, но люди очень много от этого получили. Кто-то благодаря новым знакомствам нашел работу, кто-то повысил свою квалификацию. С точки зрения организации опыт совершенно бесценный. Ты руководишь 20-30 людьми, которым не платишь и которые не обязаны тебе подчиняться. Исключительно за счет авторитета и того, что какие-то здравые мысли высказываешь.


Пётр Соболев пишет программу в машинных кодах для ПЭВМ Агат, представленной на выставке ретрокомпьютеров части фестиваля Chaos Constructions'2004

Я даже написал тогда полноценную систему для управления проектами именно для CC. А дружественная компания специально под нас писала 3D-движок, чтобы заставки и расписание показывать на большом экране.


Скриншот системы управления проектами для фестиваля Chaos Constructions, написанной Петром Соболевым

В 2005-м фестиваль там же в ЛДМ по смыслу был похож на предыдущий, а вот в 2006-м уже сильно отличался. Мы провели его около метро Лесная, в павильоне выставочного центра Евразия. Зал большой, и чтобы поднять уровень мероприятия и привлечь людей, мы решили добавить ещё тематики. Сетевая безопасность, игры всё подряд, вплоть до блогов. Разделили помещение на зоны для геймеров, хакеров и т. д. Некоторые направления потом отвалились, но другие оказались многим интересны.

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


Большой экран с пролетающими в эфире паролями Wi-Fi. Хакзона Chaos Constructions'2009

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


Задание одного из конкурсов на Chaos Constructions разобраться в схеме и разминировать бомбу с обратным отсчётом

Ещё важно, что CC'2006 был первым, куда довольно много народу пришло со своими компьютерами, как на западных demo party. Раньше подобное у нас было невозможно ноутбуков ни у кого толком не было, а для перевозки громоздких настольных компьютеров с мониторами мало у кого были личные автомобили.


Хроника с фестиваля Chaos Constructions2006

Демосцена сейчас


С 1996 по 1999 год, на мой взгляд, был кризис. Я говорю не про Россию, а про весь мир. Появились 3D-ускорители, и народ, вместо того чтобы подумать о сюжете, ринулся во всё это: Давайте покрутим бублик, покрутим 5 бубликов, а если 100 бубликов, вообще супер будет! Демки, которые занимали первые места на крупнейших мировых пати, были сделаны технически круто, но чаще всего смотреть их было совершенно неинтересно. Это затронуло и те платформы, с которых демосцена начиналась. Если на PC хотя бы есть 3D-ускорители т. е. было понятно, почему они стали эти бублики крутить, то на Commodore 64 и Amiga ускорителей не было, а бублики крутить многим там почему-то тоже хотелось. Выглядело это печально. То есть, когда на 6502 1 МГц с жутко медленным видеобуфером пытаются что-то крутить это, возможно, само по себе достойно уважения, но смысл неясен.

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


Футболка для фестиваля ENLIGHT'96 с напечатанным на ней кодом интро Cross (автор MadMax), занимающим всего 128 байт

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

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

Командная работа


На современной демосцене знаковых фигур, на мой взгляд, почти нет. Это не та область, где главную роль играет отдельная личность, здесь больше командная работа. Потому чаще известны именно названия команд. Возьмём какую-нибудь из известных демок, например, Second Reality 1993 года. Хотя она уже очень старая, на PC написанная, её успех определяется именно сочетанием графики, музыки и кода. Если что-то убрать, демка уже не будет такой. Это легко проверить, к примеру, просто выключив звук.



Финская команда Future Crew, которая эту демку написала, была знаменитой, я даже не могу назвать никого, сопоставимого с ними по известности в те годы. Из старых команд по-прежнему хороша та же Fairlight. Они начинали на Commodore 64, потом был Fairlight на Commodore Amiga частично с другими людьми, потом они перешли на PC. Но на всех трёх платформах Fairlight периодически выпускает очень приличные вещи.

Искусство и код


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

Что будет дальше вопрос сложный. В середине 1990-х или начале 2000-х мало кто мог предвидеть, что написание работ под старые платформы 19701980-х станет популярным, и что эта популярность будет только расти. Странно: железо всё лучше становится, добавляются возможности, но людям интереснее получать больше от старых платформ, а на новых платформах растёт популярность конкурсов с жёсткими ограничениями по размеру. Сейчас вроде очевидно, почему это так, но тогда было неясно. Так и в будущем совершенно непонятно, чего ждать. Мне кажется, что направление, в котором сейчас развиваются компьютеры не очень демосценерское. Это касается, в частности, ухода от привязки софта к конкретным платформам, эмуляции всего и вся и т. п. В отношении демосцены я скорее поверю, что старые платформы будут ещё более популярны, чем сейчас.

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

Категории

Последние комментарии

© 2006-2020, personeltest.ru