Камиль:
Я немного перфекционист по натуре и ежедневно чувствую, что мне хотелось бы, чтобы все работало идеально и чтобы все можно было оценить, и когда этого не происходит, это вызывает у меня определенный стресс. Кроме того, приходится считаться с тем, что будет гораздо больше хаоса.
Другое дело, что в машинном обучении мы не просто создаем модели и анализируем данные, потому что вокруг задач машинного обучения тоже много чего еще. Позиция инженера машинного обучения, data scientist сегодня имеет множество определений, и каждой компании нужны совершенно разные навыки. В крупной компании, вероятно, будет проще подобрать человека под задачу, но небольшие компании сами иногда еще не знают, какие вещи нужно сделать, и продукт должен расти.
Нам приходится работать с данными, иногда писать ITIL для обработки этих данных, строить модели, проходить через весь этап исследований и разработок и в целом говорить, работает это или нет. Это своего рода смешение мира программирования с миром математики, статистики, анализа данных. Это смесь многих технологий в целом. Это тоже круто, потому что это больше развитие. В то же время, трудно дать хорошее определение Juniora, потому что если у нас много технологий, то Juniora-у трудно понять все. Конечно, порог вхождения может быть немного выше.
Другой аспект заключается в том, что вам нужно иметь большую осведомленность, отличное знание того, как работает и функционирует бизнес. Я не рекомендую такой подход в целом, но можно работать по Scrum на основе того, что приходит задача, и мы просто делаем ее, нажимаем на кнопку in testing, in review, done, конец, двигаемся дальше. В машинном обучении создаваемые вами решения должны каким-то образом влиять на бизнес.
Наши прогнозы будут напрямую влиять на производительность нашего продукта, на то, каким будет пользовательский опыт. Мы должны понимать последствия нашей работы в этом отношении. Более того, придется гораздо больше общаться с бизнес-командами. Вам, вероятно, придется научиться представлять свои идеи в содержательном ключе. То есть так, чтобы убедить людей в правильности наших идей. Такой навык презентации имеет здесь огромное значение.
У меня есть пример, который я люблю приводить - обращаю внимание, что он немного жестокий. В целом, работа специалиста по исследованию данных, инженера по машинному обучению может быть порой довольно неблагодарной. Если мы приходим в компанию, которая еще не до конца понимает, что такое машинное обучение, нам могут дать задание построить модель, потому что компании нужно решить какую-то проблему. Мы приходим, берем данные, анализируем их, и, конечно, это займет определенный период времени, то есть в нас уже вложены деньги.
Возможно, мы даже сменили работу, чтобы прийти в эту компанию и работать там. Мы создали прототип, он изначально работает, и мы продвигаем проект дальше. Мы все тщательно анализируем и в какой-то момент упираемся в потолок - например, технология, с которой мы работаем, имеет какой-то предел точности, или данные клиента недостаточно хороши для построения нужной модели, или его ожидания слишком высоки. Мы не можем оптимизировать бизнес KPI, и мы потратили много времени и труда на создание этой модели и этого решения. Теперь мы должны пойти к работодателю и сказать ему, что ничего не получится.
Теоретически мы сделали свою работу правильно, потому что мы построили модель наилучшим образом, проанализировали данные и пришли к выводу, что она не будет работать, и нас наняли для того, чтобы мы что-то сделали. В программировании обычно нет ничего невозможного, и относительно просто оценить, насколько те или иные вещи возможны.
При этом могут возникнуть ситуации, когда что-то в конце концов не сработает, а если и сработает, то недостаточно хорошо. Если в компании нет достаточной осведомленности, в этот момент работодатель может негативно воспринять ответ, что это невозможно сделать, в то время как на самом деле в теории за правильное выполнение работы полагалась бы похвала. Порой это может быть неблагодарным делом. В этом, как мне кажется, и заключается основное различие.