В Яндексе работают сотни программистов, и результаты их работы влияют на сервисы, которыми пользуются миллионы людей. Когда на тебе такая ответственность, нужно уметь остановиться и оценить, что можно сделать лучше, в чем ты сильнее всего и где эти твои навыки пригодятся еще. Для этого надо уметь оценить и свою работу, и работу людей, с которыми ты вместе что-то создаешь. О том, как это делать, мы и спросили наших коллег.
Андрей styskin Стыскин
В Яндексе — 8 лет.
Пришёл в Яндекс разработчиком на Java в группу поиска Маркета. Занимался классификацией товарных текстов и извлечением фактов из товарных описаний. Так началось его увлечение поиском и машинным обучением. Вне работы Андрей делал различные IR-игрушки: генератор стихов на языковых моделях, робота для прокачки социальных сетей. Сейчас Андрей руководит отделом ранжирования, в котором работает команда почти из 200 человек.
На самом деле, есть две важные характеристики. Первая, это насколько то, что делает программист, эстетически правильно: насколько его код красив, воспринимаем другими. И второе, что может как раз конфликтовать с первым, но при этом очень важно, это то, насколько он умеет своими действиями, своим кодом достигать результата по каким-то метрикам. Например, качества поиска.
Антон pg83 Самохвалов
В Яндексе — 9 лет.
Пришёл в Маркет программистом на C++. Работал над самыми разными задачами сервиса. Через несколько лет перешёл в поиск, где занялся надежностью и производительностью runtime поиска. Сейчас занимается системой сборки, которая позволит собирать всю нашу кодовую базу за несколько минут на большом распределенном кластере.
Мне кажется, самый правильный способ — когда тебя оценивают коллеги. Это как оценить, хорошая страничка в интернете или плохая. Если на нее заходят люди, значит она хорошая, если нет — плохая. То, что называется Page Rank. Также люди могут оценивать друг друга. Если большинство людей вокруг тебя считает, что ты хороший программист, значит, ты хороший программист. Если не считает, значит, это не так.
Андрей yafinder Плахов
В Яндексе — 6 лет.
Пришел в Яндекс старшим разработчиком. Первой его задачей было создание нового типа факторов ранжирования — доменных. Сейчас руководит службой функциональности поиска — в частности, разрабатывает поисковые подсказки.
А как оценивать работу художника? В некотором смысле это очень похожие вопросы. Есть две ступени — начинающий художник и профессиональный художник. Как оценить начинающего, понятно. Гораздо сложнее ранжировать между собой художников профессиональных. Начинается уже некоторая вкусовщина, критерии могут становиться плохо вербализуемыми. Но тем не менеее потом неожиданно оказывается, что действительно топовых художников все представляют себе приблизительно одинаково. Даже если в слепых тестах показывать картины великого художника и картины его учеников, то люди гораздо чаще будут выбирать картины мастера. Мне кажется, с программистами также — сложно вербализовать, но тем не менее внутренняя иерархия всегда выстраивается.
Степан stepancheg Кольцов
В Яндексе — 8 лет.
Руководитель группы разработки мониторинга в поиске. Стёпа из тех сотрудников Яндекса, которые уходили, но потом возвращались. Один из тех, кто пропагандирует Rust в Яндексе и не только.
Работу любого человека надо оценивать по результатам. Если человек решил поставленную перед ним задачу, он молодец, если не решил — не молодец. Но бывают разные задачи. Есть те, в которых можно все сделать кое-как — лишь бы работало. Тогда никому неважно, насколько криво и как это сделано. А бывают проекты, которые очень долго живут — годы. И там очень важно, чтобы после человека оставался качественный код, чтобы он мог передать его другому.
Александр sadovsky Садовский
В Яндексе — 11 лет.
Пришёл в Яндекс работать над проектами, связанными с поиском. Под его руководством были созданы поиск по блогам, Яндекс.XML, запущены новый алгоритм ранжирования и робот для оперативного индексирования свежей информации, создана служба асессоров и начато измерение качества поиска. Саша — автор множества публикаций в научных и популярных СМИ об алгоритмах поисковых систем и продвижении сайтов в интернете.
Это очень интересный вопрос, потому что программист — это, с одной стороны, вроде бы профессия интеллектуального труда, а с другой, она местами превратилась в ремесло. Есть элементы программирования, которые масштабируются, где достаточно легко передаются знания от одного программиста к другому. И оценивать здесь нужно по-разному. Там, где программирование превратилось в ремесло, где это стало более менеее понятным автоматизированным процессом, могут быть введены понятия, как в физическом труде — нормативы, выработка. Классика жанра — создание корпоративных сайтов, которые более-менее одинаковыми создают сотнями. А в интеллектуальной части необходимо оценивать сложность задачи. Скорее всего, это можно сделать путем разговора с самим программистом, с его коллегами, с тем, кто понимает суть работы. И решение об оценке в таком случае — достаточно сложное, основанное на здравом смысле. Его нельзя принять механически. И у нас, к счастью, этого более интеллектуального типа работы очень много, почему и интересна работа в Яндексе.
Михаил Парахин
В Яндексе — 1 год.
После окончания МИФИ начал работать в ЗАО НТЦ «Модуль». В 90-х это было почти единственное место в Москве, где занимались системами автоматического обучения. Потом ушел в компанию Parascript, которая фактически является монополистом в области распознавания рукописного и печатного текста. Долгие годы работал в США. Последние семь лет — в Microsoft, пять из которых возглавлял в Bing подразделение мультимедийных поисковых сервисов. Весной пришёл в Яндекс директором по поисковым технологиям.
Это сложный вопрос, и, думаю, никто не знает ответа на него. Но лучшее, что мы сейчас придумали, это спросить тех, кто много работает с человеком. Обычно люди вокруг, которые читают его код, общаются с ним, смотрят, как он работает, довольно хорошо представляют себе, кто хороший, а кто плохой программист. В системе ревью, которую мы сейчас создаем, упор в значительной степени сделан на опросы таких людей. А объективно оценить, конечно, есть много методов и попыток, но я не знаю, как в реальности сделать это точно.
Михаил Левин
В Яндексе — 5 лет.
Очень большая часть деятельности — работа в наших академических программах. Он преподает в Школе анализа данных, участвует в создании программы обучения на факультете Computer Science Вышки и Яндекса. Дважды завоевывал медали на ACM ICPC в составе команды МГУ им. М.В. Ломоносова.
Оценивать работу любого сотрудника нужно по результату. По результату как в бизнесе, так и, если его работа непосредственно на бизнес не влияет, в создании инструментов, инфраструктуры, внутренних каких-то вещах, в том числе отношениях с коллегами. Это целый комплекс. Программисты в этом смысле ничем не отличаются от всех остальных. Единственное, наверное, отличие в том, что в нашей компании, во многих IT-компаниях, они — это те, кто создает продукт. Поэтому об их работе можно судить по тому, насколько продукт хорош, насколько он успешен — настолько и их работа хороша. Конечно, они не единственные, кто эту ответственность разделяет. Есть те, кто решает, что вообще нужно делать в продукте. Они отвечают за то — как. Хороший программист, конечно, задается вопросом, а зачем делать именно это и отказывается от задач, которые поставлены просто с потолка.
Андрей Мищенко
В Яндексе — 10 лет.
Пришёл в Яндекс разработчиком на C++, долго был руководителем разработки Поиска по блогам и писал на Perl. Андрей — кандидат физико-математических наук. Сейчас работает над улучшением алгоритмов машинного обучения в поиске.
На каждом уровне свои требования. Если программист — стажер, то его нужно оценивать в основном по тому, как у него глаза горят, насколько ему хочется это все учить, как он умеет заставить себя не скучать, найти те задачи, которые ему будут интересны. Когда человек уже начинает расти, важнее, конечно же, насколько у него отдача большая, насколько он делает задачи быстро, насколько решения получаются качественные и их не приходится переделывать потом. Если еще выше пойти и говорить об архитекторе, то уже, естественно, его работу нужно оценивать не потому, как быстро он что-то сочинил, а по тому, сколько через год пришлось изменений в эту архитектуру вносить, и насколько она смотрела в будущее далеко.
Сергей svv Вавинов
В Яндексе — 6 лет.
Пришёл в Яндекс разработчиком в Яндекс.Видео. Был главным в разработке Музыки, потом — в службе медиасервисов. Сделал несколько проектов для Яндекс.Диска. Сейчас — руководитель группы технологий работы с большими данными. Одна из задач, над которой работает Сергей, — проекты Яндекса для ЦЕРНа.
Тут есть несколько факторов. Простой ответ, это, конечно, оценить по результату. Человек потратил столько-то времени, решил или не решил задачу. Но это только одна сторона. Код, который он написал, нужно поддерживать. Нужно, чтобы поддерживались определенные стандарты, он проходил ревью, чтобы были единые правила того, как ведется разработка, чтобы коллеги проверяли друг друга и оценивали код с точки зрения того, насколько он годится для долгосрочной работы над проектом.
Григорий bobuk Бакунов
В Яндексе — 10 лет.
Когда-то пришёл работать системным администратором, а сейчас — директор по распространению технологий.
Сложный вопрос. Мне кажется, по результату. На самом деле, у каждого программиста есть некоторая задача. И бывают такие программисты, у которых задача — провести интересный эксперимент. И тогда никакой оценки, кроме как изучения его результата, не сделаешь. А бывают программисты, задача которых — создать какой-то продукт. И тогда можно посмотреть на то, как правильно он функционирует.
Но мне кажется, правильно говорить о том, как плохо оценивать работу программиста. Мне кажется, оценивая работу программиста, категорически неправильно скатываться в детали. Например, говорить, что программист все сделал хорошо, а тестировщики не уследили. Или программист все сделал хорошо, а системные администраторы неправильно задеплоили. Эта манера свалить все на окружающих меня страшно раздражает. Мне кажется, в каждой точке наоборот нужно стараться как можно плотнее все взять под собственный контроль, потому что лучше проверить три раза, чем не проверить ни одного. И в этой ситуации мне кажется, что очевидно работу программиста оценивать по тому, насколько качественным получается продукт, которым он занимается. Даже если он делает маленькую шестереночку в этих часах, оценивать надо по тому, насколько точно работают эти часы.
Комментарии (47)
eaa
01.04.2015 17:56+15Вобщем, все ответили «по результату», т.е. критерий примерно как у дворника: число подметено — хороший дворник, плохо — плохой.
Точка зрения яндекса понятна.
f0rk
02.04.2015 12:54+3Что еще хуже, проскакивала фраза «по результату в бизнесе». То есть можно ставить программисту дурацкие задачи, а потом свалить вину на него же. Радует, что не все так считают.
kashey
01.04.2015 20:10Я вот точно что-то делаю с 7-10 лет, но это была переклейка касет и бейсик на Спектрумах.
К сожалению при такой выработке уже начинаются различные глюки, капризы и заскоки.
Я вот точно что-то пишу класса с пятого — дома появился «пентиум»
Я вот точно что-то кодю с десятого — у меня появился собственный компьютер
Программирую я не так долго — лет 15, с тех пор как это моя работа.
Правильно сравнили нас с ходожниками — каждый может обидеть, и не понять крадратуру Малевича.
ServPonomarev
02.04.2015 10:05+1Мнение сотрудников Яндекса, высказанное и тщательно отобранное отделом HR мы услышали. А вот каким образом на самом деле оценивается работа программиста в Яндексе? Вот пришёл к вам новичок, не стажёр, не доктор физ-мата, просто программист. На что будете смотреть в первые три месяца?
И как это коррелирует с вашей методикой отбора по «классическим алгоритмам»?
dance000
02.04.2015 10:45-1А по мне, так все упомянули о том, что оценивать работу программиста могут только коллеги или люди в «теме».
Но попробуем абстрагироваться от кода. Я считаю что для руководителей бизнеса «ковыряться» в коде и конструкциях которые написал программист — не правильно. Результатом работы программиста является программа, также как результатом работы монтажника является некая конструкция (к примеру амбар для хранения зерна).
Конечно программисты склонны к причислению своей работы к искусству (я и сам программирую на разных языках более 12 лет), но вернемся к результату.
Есть конечное ТЗ (в идеале) и результат работы должен ему соответствовать. В ТЗ конечно всего не пропишешь, как то сколько памяти максимально должно съедать или за какое максимальное время должна выполняться некая процедура, но это остается на совести исполнителя. Когда вы заказываете аранжировку на свадьбу или картину чтобы повесить в гостиной вы говорите об общем представлении которое хотите получить. Ритмичность, длина, размеры, цветовая гамма. Что это будет легкая весенняя трель соловьев или венский вальс. Если после заказа венского вальса композитор вам принес хардкорный трэк, то в независимости от идеальности музыки (читаем кода) вы не будете довольны результатом.
Поэтому еще раз вернусь — важен результат который может оценить непрофессионал в данной области. Конечно если проект сложный то при принятии работы следует пригласить специалиста, но и тот должен принимать работу согласно серьезному ТЗ. Личные предпочтения по табуляции, использованию тех или иных инструментов и методов — это всего лишь личные предпочтения.
FiresShadow
02.04.2015 11:03Первая, это насколько то, что делает программист, эстетически правильно: насколько его код красив, воспринимаем другими. И второе, что может как раз конфликтовать с первым, но при этом очень важно, это то, насколько он умеет своими действиями, своим кодом достигать результата по каким-то метрикам. Например, качества поиска.
Ну да, чем сложнее код, тем сложнее провести его декомпозицию. Но если сложность кода в большинстве случаев приводит к его нечитабельности, то это сигнал к тому что нужно или почитать книги по проектированию, или поизучать предметную область чтобы обогатить доменную модель новыми понятиями, или просто расставить комментариев с описанием в результате каких исследований было решено что эта строчка должна быть написана именно так. В общем, повысить понятность кода, чтобы фраза «чем сложнее код, тем меньше его понятность» превратилась в «чем сложнее код, тем сложнее сделать его понятным».
Если большинство людей вокруг тебя считает, что ты хороший программист, значит, ты хороший программист. Если не считает, значит, это не так.
Тут дело в заметности, в умении и желании объяснять людям какой ты молодец и какие хорошие вещи ты делаешь. Я бы сказал, что заметность = мастерство * квадрат от коммуникабельности. Тот подход при оценке, который вы описали, используют лишь управленцы с низкими познаниями в программировании.
И там очень важно, чтобы после человека оставался качественный код, чтобы он мог передать его другому.
А если автор никуда не уйдёт, и передачи кода другому человеку не будет, то, выходит, можно и не стараться? (irony)
Поэтому об их работе можно судить по тому, насколько продукт хорош, насколько он успешен — настолько и их работа хороша. Конечно, они не единственные, кто эту ответственность разделяет. Есть те, кто решает, что вообще нужно делать в продукте.
А вам не кажется, что тут логическое противоречие? Не всегда неверное решение аналитика само кричит о том, что оно не самое удачное, иначе на роль аналитиков можно было бы брать кого попало с улицы и не проводить никаких исследований при принятии решения. Точно также, гениальные бизнес-идеи аналитиков могут вытянуть продукт при посредственном исполнении программистами. Итого, удачность проекта = качество работы аналитиков * качество работы программистов. Иными словами, качество работы программистов = удачность проекта \ качество работы аналитиков. А вы вот заявляете, что качество работы программистов = удачность проекта.
Извините, если кого обидел.FiresShadow
02.04.2015 11:17забыл добавить, что в моих шуточных формулах всё измеряется в коэффициентах от 0 до 1.
ikirin
02.04.2015 11:04+7По мне так, ни один из участников видео толком не смог охарактеризовать параметры хорошего программиста. Поэтому, позвольте помочь. Хороший программист:
Пишет код, который легко поддерживать; Решает задачи с ориентацией на бизнес (т.е. не забывает, что проект не ради проекта); Решит любую возникшую проблему максимально быстро.
Вот.eaa
02.04.2015 11:09Это касается только программистов-ремесленников.
А есть еще программисты-исследователи, которых не касается напрямую бизнес, не нужно писать поддерживаемый код ну и много других отличий.
Про программирование как творчество вообще молчу, все-таки яндекс — это по большей части бизнес и как все сказали, оценивают по результату, а не по творчеству. Многие мечтают о творчестве, а дальше кодерства не ходят.
slava_k
02.04.2015 13:11Как оценивать работу ***? По соотношению решенных проблем к созданным.
eaa
02.04.2015 13:16+3Чем больше человек познает, чем больше создает всякой всячины, тем больше проблем и вопросов возникает.
Раньше была проблема — как убить мамонта на еду, сейчас проблема обратная — как мамонта восстановить из ДНК.
Artem_zin
02.04.2015 23:44+2Нормальный разработчик восстановил бы мамонта из системы контроля версий :)
questor
02.04.2015 16:36Ответ Антона Самохвалова переводит вопрос в область субъективных критериев. «Также люди могут оценивать друг друга. Если большинство людей вокруг тебя считает, что ты хороший программист, значит, ты хороший программист» — ну хорошо, ты не можешь оценить себя сам в каких-то объективных, измеряемых критериях (утрируя — количество строк кода), но кто-то другой ведь тоже должен объяснить свою оценку «этот — хороший программист, этот — тоже, а этот — нет». Особенно ярко это проявляется не когда «У Саши пять плюсиков от коллег, а у Вити — только три», а когда «Саша считает, что плюсик, который он поставил Пете больше плюсика, который поставил Игорю». И тут надо бы как-то перейти к списку «Саша всем ставит плюсики/минусики по двадцати шкалам» и снова упрёмся в наличие измеряемых, объективных критериев.
Об этом же — ни слова. Что предлагается? Фигурное катание, оценки нескольких судей; либо круговая система «каждый оценивает каждого». Нужно раскрывать детали — как оценивать, по каким критериям.
kentastik
04.04.2015 11:37Мне понравился ответ товарища bobuk, остальные поговорили, но не ответили :)
kidar2
Сергей Вавинов
Дата рождения:26 августа 1981
Программирует 28 лет.
Андрей Плахов
Дата рождения:13 августа 1980
Программирует 25 лет
Что за монстры такие в яндексе?
leschenko
Я фразу «Программирует 19 лет. В Яндексе — 9 лет.» прочитал как:
1. Программист.
2. 19 лет.
3. В Яндексе — 9 лет.
Подумал что Яндекс использует детский труд. Потом понял где ошибся.
Zalina Автор
Я спрашивала у участников, в каком возрасте они начали программировать. Отвечали все по-разному в зависимости от того, что считают уже программированием. В целом большинство начинало еще в школе. Сережа как раз из тех, кто начинал раньше всех, кого я опрашивала.
withoutuniverse
Я программировал на бейсике, на ПК Вектор-06Ц (данные на аудио-кассету записывались) в возрасте 4 лет.
Понимания особого не было, но над домиком у меня корзинки пролетали, из трубы дымом корзинки сбивались.
Мне сейчас 27 лет, но я никогда бы не сказал, что программирую вот уже 23 года.
Eltaron
Если переписал из книжки программу и запустил — это одно. Если писал с подсказками родителей — это другое. А если сам изучил язык, сам представил конечный результат работы, сам алгоритмизировал и сам реализовал программно — то уж простите, но тут никак не отвертеться — программировал.
Jukobob
Как раз в этот квант времени стоит разделить понятие «Кодит» и «Программирует». Взял открыл пример, переписал код, нашел пару ошибок, запустил — да, хорошо покодил. Но вот когда ты держишь в голове всю эту систему,
которая, порой не дает уснуть по ночам,просыпаешься ночью от «озарения музы» или находишь более оптимизированное решение задачи — вот тут оно наше ремесло «Программирование»!bay73
Сейчас в каждой школе в начальных классах информатику изучают. Так что таких программистов с 6 лет сейчас каждый первый. Вряд ли стоит придавать этому какое-то внимание. Даже момент зарабатывания первых денег не стоит реально считать началом карьеры программиста.
Но для первоапрельского поста сойдет.
vics001
Я думаю, стоит считать все время зарабатывания денег программированием. Если будучи школьником, делал сайты и этим зарабатывал, то это считается как «стаж», хотя тут возможно надо считать по 0.25 ставке опыта )
bay73
Понятно, что тут достаточно индивидуально. Можно ведь и не зарабатывая весьма серьезно программированием заниматься (например, в качестве научной работы у студента или в опенсорсных проектах). Но это в любом случае к шестилетним детям не относится.
Просто если мне кто-то на полном серьезе ответит, что у него стаж программирования с шести лет, то я не буду воспринимать такого человека всерьез — это либо непонимание программирования вообще, либо заоблачное самомнение.
Но не думаю, что к указанным в статье лицам это относится. Тут скорее всего вольность корреспондента — интерпретировать ответы опрашиваемых, как стаж. Ну и кстати, упоминания о стаже уже убрали :)
vics001
Тут тоже непонятно как судить «детский труд» никто не отменял. Школьники выигрывают «взрослые» олимпиады аж с 5-го класса. С другой стороны это наверняка идет в ущерб чему-то другому. В другом обществе такие школьники могли бы полноценно работать с 5-го класса. Так что считаю, что надо или считать «профессиональный» стаж по любому из критериев, либо вообще не считать. А то будет как с таким вопросом…
— С которого возраста вы начали петь?
А вообще дурацкая шаблонная метрика :) Опыт — это проще список компаний, учреждений, где работал и чем занимался
questor
По-хорошему, не всегда корректно брать разницу между «когда в первый раз начал программировать» и «текущая дата». Я, например тоже ещё в первых классах начал программировать на спектрумовском ассемблере, но потом был вынужденный перерыв в стаже… пока не сел за 286той. Стаж — это стаж, он в общем случае отличается от непрерывного стажа.
eyeofhell
Сильно. С 6 лет. С 1986 года. Что-то я сомневаюсь что 6-летнего, пусть даже вундеркинда, допускали к мейнфреймам и перфокартам. Может, родители — ученые, водили с собой к большим компам? В комментарии приглашается yafinder нам всем очень-очень интересно, правда. Может, тонкая первоапрельская шутка?
ctacka
Вообще в 1986 года были уже спектрумы, хт, не говоря про всякие ДВК.
Zalina Автор
Речь не о том, что они в этом возрасте работали, а о том, что начали учиться программированию.
eyeofhell
Залина, мы ни в коем случае не пытаемся как-то привратно истолковать ваши слова или целенаправленно искать неточности в таком большом объеме текста. Нам правда интересно кто из сильных программистов когда начинал. Ностальгия и все такое.
Опять же нам очень важно понимать, что когда в анкете написано «программирует 15 лет» — речь не о том, что человек в этом возрасте работал, а о том, что начал учиться программированию. Я, к примеру, часто нанимаю разработчиков, мне такие вещи при анализе анкет очень нужны. Статистика использования терминов, все вот это.
Zalina Автор
Григорий, спасибо за аргументы) На самом деле, когда мы начинали эту рубрику, хотелось донести, почему мы задаем такие вопросы этим конкретным людям. Один из факторов, который я взяла как авторитетный, — общий стаж программирования, потому что в видео подробный бэкграунд не дашь. Кажется, что эти цифры уже можно не указывать. Так что поправлю сейчас текст.
eyeofhell
Лучше Андрея пригласите, я думаю ему будет самому интересно кратко написать с чего он начинал разработку, как в те времена было с компьютерами, на чем учился, когда перешел в коммерческую разработку, все вот это.
propell-ant
Достаточно было бы просто изменить формулировку — «первую программу написал в 6 лет, в 1986 г.».
Это действительно дает некоторое представление о человеке, но без претензий на профессиональную деятельность.
«Программирует с 6-ти лет» вызывает кучу вопросов, а «первую программу написал...» — понятно всем.
eyeofhell
Тем более реквестируется Андрей — когда, где, на чем. Интересно же к таким древностям прикоснуться не в лице профессора MIT :). У меня самого первый спектрум только в 92-м появился, когда они получили хоть какое-то распространение. Скорпион там и все вот это вот…
vedenin1980
Насколько я помню спектрумы и иже с ними раньше 90-х в СССР были крайне редки и дороги, в 86 году скорее всего спектрумы у каких-нибудь дипломатов разве что были.
questor
Мне отец сам спаял — и Синклер, и Радио-86РК и Специалист. При этом нужно понимать, что жил я на Урале в маленьком военном городке — поэтому вполне верю, что в городах-миллионниках и столице ещё проще было и с деталями и с готовыми комплектами.
Sykoku
Искра-1030 (раз ДВК-1 / -2 вспомнился)
БК-0010 (из серии до ZX)
Электроника МК -52 (с блоком расширения для математического сопра + для хранения программ)
и т.д.
Или это в стаж не пойдет?
А я еще на аналоговых успел поработать…
ctacka
Я так понимаю, что это общий стаж, а не профессиональный. То есть начиная с первых потуг в бейсике на ХТшке или БК0010.
Но программирование с пяти лет это как-то даже слишком круто.
Zalina Автор
Да, вы правы — речь об общем стаже, начиная с того момента, когда человек начал учиться программированию.
ov7a
del
ivan4th
В Яндексе не работаю, да и не монстр, но в моём случае расклад такой: 1979 г.р., с 1990 кодил «для души», так что по меркам Яндекса можно считать, что 25 лет. Какое-то время назад на меня вышли рекрутеры Google. К своему удивлению (thinking under pressure — это не моё, олимпиады никогда не любил, например) я прошёл их телефонные/hangouts interview (SRE) и они решили свозить меня в Дублин on-site interview ближе к маю (на головокружительный успех не рассчитываю по вышеназванным причинам, но может хоть Гиннеса там попью :) В процессе общения с recruiting manager мне заметили, что в резюме я указал многовато опыта — 18 лет. Я ответил, что начал отсчёт с момента, когда начал писать используемый в production софт на благо ядерных физиков МГУ — на это мне возразили, что опыт надо считать с момента окончания института. Всё равно мол порядочно выходит, но тем не менее. Так что, видимо, каждый считает, как кому нравится.
Kano
В этом нет ничего удивительного, например я начал программировать до появления своего первого компьютера — в 9 лет (сразуже после того как увидел
первый компьютер у нас в городе на выставке). Сейчас мне 33. Кому то повезло больше.
petuhov_k
Я как раз лет в 10 или меньше из книжки в Panasonic бейсиковые тексты перепечатывал и радовался домикам и музыке. Кто-то, вполне мог в 5 лет игрушечный «Луноход» программировать. Что из этого можно учитывать в стаж, я затрудняюсь ответить.
Вероятно, шутят так.