Transcription
Я очень долго там, когда был совсем мелкий, ещё до универа там увлекался. Там была такая философия Криса Касперски. Это не тот, который антивирус разрабатывал, а это другой, а там, скажем, такой хакер, короче. И мне тогда казалось очень круто, не знаю, взломать какой-то Пентагон, но мне тогда мелком казалось.
И я помню, что у нас были эти ещё диалап-модемы. Мы разбирались, разрабатывали. Ну, как мы разобрались в протоколах, которыми они связываются. И там какие-то первые приложухи у меня были, которые взламывали этот протокол и позволяли мне подсоединяться, не знаю, там тогда к универу и так далее, а, и тырить оттуда данные. Ну, было достаточно легко, но каким-то таким богом себя ощущал.
И с тех пор, наверное, да, какой-то кайф остался, что когда ты пишешь сначала э какие-то строчки кода, которые для тебя выглядят вообще как непонятно что, но в целом, а потом вдруг они работают. Это момент, наверное, какой-то такой магии, который меня, ну, долго здесь держал, [музыка] да.
С тех пор я, соответственно, пошёл в универ, пошёл по специальности. Я обучался под специалист по безопасности защиты информации. Ну, в принципе, всё с айтишкой связано. И после, да, я, в принципе, по айтишке двигался. Вот и надо сказать, что все хают обучение в университете, но он дал мне две вещи, которые потом мне пригодились в жизни. И сравнивая себя с другим, я понимал, что, наверное, ну, кроме как в универе я не получил.
Но мне повезло с преподавателем. У меня был очень хороший преподаватель по криптографии, и он мне объяснил всякие закрытые подписи, открытые подписи, все особенности там RSA-протоколов, все особенности шифрации, которые так или иначе мы все касаемся и видим. И реально очень часто бывает, что касаешься там какого-то протокола, там, не знаю, при посылке электронной почты, а как нужно сделать так, чтобы, грубо говоря, данные, если перехватили, то ничего с ними не могли сделать, а то ты уже понимаешь, какие инструменты у тебя есть, какие из них более как бы безопасны, какие более трудозатратные, какие более эффективные. Мм, без универа у меня бы этого не было. Но там у меня был такой заряженный преподаватель, он очень всё клёво объяснял. Я до сих пор помню на огурцах и помидорах. Ну то есть на каких-то таких очень базовых вещах и очень сам горел от этой темы. А поэтому было клёво.
А после остальные знания, кстати, мало пригодились. И всё остальное, наверное, да. Просто читать книги. Книги — важная штука, потому что очень хорошие книги прокачивают хорошо. Второе — это постоянно быть как бы войти. Если ты хочешь быть на месте, должен постоянно бежать, э-э, то есть постоянно, не знаю, читать все, в том числе хайповые гайды, пробовать все, в том числе хайповые языки программирования, э, функциональный там, не знаю, стиль, архитектуру и так далее, прыгать с одного на другое, но а не для того, чтобы всё это использовать у себя, а просто для того, чтобы понять. Ага, здесь идёт речь об этом. Ага, здесь я вот это вот не понимаю, там на досуге ознакомлюсь, возможно, возьму себе в тулсет. А, возможно, нет. Возможно, буду использовать что-то другое, и я вообще не вижу за этим будущее. А, и возможно потом ты ошибёшься и будешь возвращаться заново учить. Но так или иначе, да, это такой широкий взгляд, в принципе, на всю сферу, э, и местами глубокий, там, где нужно прямо изучать глубоко.
А-а, сказать так, чтобы меня кто-то обучал за всё это время. Не, я встречал людей, которыми, ну, как бы я так восхищался, у которых брал опыт и так далее. Вот. Но было порой тяжело, потому что когда я работал, допустим, когда я был сам джуниором и медлом и работал с синьорами, и теперь я понимаю, не знаю, если там на заводах, наверное, платят за то, чтобы синьоры воспитывали медлов и джинов, то меня зачастую там тоже сейчас, э, как и сейчас я лид считаюсь и архитектор периодами работы. Вот. А и меня тоже просят, что помочь кого-то чему-то научить, чему-то рассказать и так далее. Я понимаю, что на самом деле это сложно. То есть помимо самого понимания технологии, нужно уметь как бы работать с людьми и уметь учить. Это две разные профессии. И она тяжёлая.
И вот также я был только с другой стороны, когда я был женом, там медлом приходил, там приходил мне синьор, говорит: "Ну что ты паришься, там надо сделать вот так-то". И он делал сидел, думал: "Какая-то магия, я ничего не понимаю". И потом мне приходилось самому как бы копать, понимать, откуда вообще это знание возникло, как оно мм там было построено. Что изначально это, ну, как, допустим, многие сейчас приходят, такие говорят: "ООП, надо выкинуть, его не нужно использовать, потому что оно плохое. Все книжки говорят о том, что есть у нас другие. Но фишка в том, что понять хорошо функциональное программирование можно только понять, что оно отрицает. Отрицает оно объектно-ориентированное. И нужно понять сначала объектно-ориентированные, понять его все проблемы, а только потом ты очень хорошо поймёшь функциональное ориентированное программирование. Если ты будешь, а, сразу прыгать на функциональный объект, ну, стиль программирования, ты очень много вещей упустишь и будешь применять их бездумно и как такую заученную мантру.
И точно также для меня в самом начале, ну, очень много вещей там было там тогда сигналами на Линуксе. Я долго не понимал, использовал это просто типа мне надо этот кусок кода вставлять, он будет как-то работать. и какие-то вещи тогда по архитектуре не совсем догадывался, какие там контроли должны быть, толстые, тонкие, не знаю, там модели. Э тогда были все эти Symphony и Rest, ой, Symphony и ZН на PHP. тогда не до конца понимал все эти истории, но опыт, книги, переосмысление своего опыта, конференции очень хорошо помогают. Конференции, особенно когда попадаешь на заряженных людей, а-э, понимаешь, в принципе, куда стоит развиваться, что нужно затронуть. Ну и да, нужно постоянно бежать, бежать и бежать. Наверное, в IT-сфере если ты остановишься, то технологии очень быстро тебя обгонят, очень быстро двигается прогресс. И ты можешь даже не найти места, потому что стек изменился и таких вакансий больше не осталось. А либо просто ты перестанешь понимать, о чём вообще люди вокруг говорят.
Это как бы программирование, но другое. Да, это действительно хороший вопрос. И я сам до поры думал, зачем вакансии называют инженерами. Аа, но теперь, не знаю, у меня в голове сложился образ и особенно в связи с тем, что часто беседуешь тоже, ну, не часто, но приходится, а то ты понимаешь, чем они отличаются от бэкэнд-инженеров обычных классических, понимаешь, чем они отличаются от data scientist. А-а, кратко я бы сказал, что AI-инженеры где-то посередине. А если датасатисты, им в основном нужно разработать, соответственно, нейронку, а именно нейронную модель, нейронную сеть. Нужно прямо на вот этом датасете понять, какая модель в какой конкретной конфигурации будет выдавать лучше перформанс, перформанс по каким-то определённым метрикам. То есть они сначала там выбирают метрики, э, понимают этот датасет, разбирается в нём, составляет какие-то инструменты для более глубокого погружения в тему, потом запускает, не знаю, бейзлайн на этом, то есть модель какую-то простую базовую, э, которая от которой можно уже будет отталкиваться. Потом выбирает модель посложнее, потом понимает, насколько можно пойти посложнее. Но, в общем, их цель простая — это добиться того перформанса, которых они требуют. А в рамках тех метрик, которые им поставили на том датасете, который у них есть. А иногда у них, возможно, бывает задача чуть посложнее, когда датасет изменчивый, то есть он меняется там в зависимости от сезона, м в зависимости от времени дня, м, не знаю, какой-то потоковый идёт, но в целом это всё равно датасет.
А-а, AI-инженеры — это больше про то, как это всё внедрить в продакшн и сделать так, чтобы пользователи с этим работали и радовались, потому что ты не сможешь просто дать пользователям нейронку. И даже там чат GPT — это не просто нейронка. Там, грубо говоря, есть некий а интерфейс текстовый, в который что-то вписывается, вы что-то получается, есть куча ошибок, не связанных вообще с нейронками, которые нужно обработать, э, закрыть и изменить. А есть куча проблем в плане перформанса, потому что нейронка одна. А что будет, если её раскопировать? Что будет, если с этим быть? Ну, в общем, очень много проблем, которые возникают и в принципе там и обычных бэкэнд-инженеров, когда мы разворачиваем нейронки, а какие-то другие сервисы, когда мы, не знаю, там стучимся за получением, не знаю, там каких-то показаний погоды, прогноза погоды, ставок, э, я не знаю, курса валют и так далее. Мм, может произойти всё, что угодно, связь обвалиться. Мм, э, и мы должны что-то сделать в этом случае, вернуть предыдущие данные, мм, как-то экстраполировать с временного ряда, полученным ранее, мм, что-то с этим сделать. А-а, всё это огромные задачи, которые в том числе и бэкэнд-инженер решает. Но здесь добавляются AI-инженеры, потому что нужно знать новый стек. Это стек, которым работает нейронки. Он другой, он имеет часть проблем. И, наверное, самая главная проблема здесь для AI-инженеров это в том, что нейронки, в отличие от кода, который раньше был на бэкэнде, они не постоянны по самой природе. Имеется в виду, что их результат, который выдают, очень случайный, очень, э, ну, как бы изменяется в зависимости не просто от инпута, от того, что он вводил, а в зависимости от того, ну, что конкретная нейронная модель, которая лежит под всем этим, в данный момент решила придумать, решила выдать на вывод. И зачастую из этого вылазят очень тонкие проблемы, м, с которыми нужно разбираться и сделать.
А, кроме того, важно, что сейчас часто используют LLM — большие языковые модели, э, under the hood. И, а-а, ну, самое главное здесь программирование такое типа как бы промт-инжиниринг, но промт-инжиниринг это шёл всё-таки тоже на задний план, не стал такой хайповый, а потому что автогенерация промтов достаточно хорошо работает в последнее время, есть много методик для этой темы. Но зачастую мы внедряем ещё очень много агентов, где разные нейронки должны между собой разговаривать. И каждая из нейронок специализируется на своём. Например, одна нейронка специализируется на том, чтобы м вот этот конкретный тип данных табличный, а по нему выдавать следующую строку. Другая нейронка очень хорошо обрабатывает результат этого, и им нужно. А третья нейронка вообще как бы план для них выдаёт, что им нужно делать между собой, и периодически заставляет их пересматривать эти результаты. В результате мы получаем в этих же промтах всякие циклы, а, всякие условия, кондишены и довольно сложную логику, которая ещё завязана на случайностях. И ещё нам здесь нужно обрабатывать ошибки. И всё это не делали раньше бэкэнды. У них не было таких историй. Э, наверное, были какие-то варианты у текстовиков, ну, так скажем, те, кто раньше работали с обработкой текста, естественного текста, потому что это, в принципе, работа похожа над тем, что сейчас работает с большой языковой моделью, а там были какие-то статистические вероятностные модели, по которым там из текста выдавали. Но здесь вот, как я вижу, основная сложность в том, что тебе мало знать data science, мало знать статистику, мало уметь с этим работать, мало хорошо создавать промты, инлайны, а тебе ещё всё время нужно как бы бежать, как этот газель между двумя быстрыми поездами. Одним из них — перформанс, потому что пользователь хочет получить ответ быстро. Второй из них — качество. Пользователь хочет получить качественный ответ. И зачастую на это не хватает ресурсов, не хватает мощностей и так далее. и ты должен что-то изобретать, что-то как-то выкручиваться в этой ситуации. Всё это делает AI-инженер. То есть он больше не про сам Data Science, не про то, как создать там новую нейронку, даже не то, что новую нейронку, а разработать какую-то модель нейронки. И он не про то, чтобы в целом аа сделать какую-то архитектуру бэкэнда, которая будет работать и так далее, а он про то, как вот эти нейронки на какой-то инфраструктуре, а, заставить работать, а, связать их, э, не знаю, через REST, GUI, что угодно, с каким-то фронтендом и сделать так, чтобы этот результат устраивал пользователя и бизнес, конечно, в первую очередь.
У нас датасаентист пишет только на Python, и все свои результаты они скидывают нам именно, а, на Python. Нам так или иначе с этим работать. Аа зачастую часто мы это переводим напрямую вообще, м, ну, точнее, мы используем это как отдельный микросервис, написанный на Python, к которому мы обращаемся через какую-то опишку. И дальше уже всю остальную логику мы реализуем на TS, где-то на Python и так далее. А Rust у нас используется во всех местах, к сожалению, иногда их становится очень много, где нам прямо важна перформанс. А он из-за того, что у него нет garbage collector, возможно, вообще главное, он, конечно, по скорости обгоняет всех остальных. Плюс он очень хорош в тех задачах, где нужно быстро подняться, что-то выполнить и сдохнуть. А просто потому, что ему не нужно поднимать тот самый garbage collector, ему не нужно поднимать ещё огромное количество библиотек. у него готовый скомпилированный результат и поднять. Плюс, конечно, мне крайне нравится, что а есть пропаганда того, что строго типизированный язык и он не раз он если он скомпилировался, ты с высокой долей вероятностью скажешь, что он выполнится. Конечно, это не так, но определённые проблемы он ловит лучше, чем другие языки. Плюс моё мнение, он как раз хорош мультитрейдинг, ну, то есть многопоточной части, где нам нужно очень много остальных вещей задействовать, но где нам не сильно нужно, допустим, шарить память, где мы можем позволить себе обойтись без каналов, потому что тогда нужно было лучше работать на Go. А а где нам нужно просто распараллелить работу, потом куда-то её положить на общехранилище. А вот ну моё мнение Rust тут крайне хорош, потому что Python с его одним потоком, и TS с его Node с его одним потоком, ну прямо мы видели, где проигрывает на больших данных, а у нас зачастую бывают очень большие данные. У нас аа ну есть базы, которые в биллионах исчисляются, и это всё нужно обработать. А там часто за бам типа MapReduce каких-то используется потоков в общем архитектуры. Вот. Но это надо обработать, с этим надо жить. Это надо как-то делить, м, обрабатывать, мёржить, сохранять куда-то перенаправлять, а поточно блокироваться. И, ну, я считаю, всё-таки, что на данный момент, Rust — победитель. Его, понятно, ещё больше может обойти чистый C, наверное, C++, C#, но опять же я в них именно не силён, в C я как бы разбираюсь, но там очень многого не хватает. На Расте очень много добавили инструментов за последнее время. Он стал намного сильно стабилен, с ним удобно работать, с ним удобно разрабатывать. И он, на самом деле, очень хороший для новичков, потому что это для людей, которые переходят с каких-то других языков, м, с Java, с, а, с Python, с PHP, не знаю, JS, TS. А-а, Rust, может быть, в начале там будет довольно тяжёл определёнными вещами, ну, дальше, в принципе, он, моё мнение, не такой супер сложный, как о нём говорят другие. Вот. Ээ, в принципе, всё, что я рассказал по стеку.
М, я хотел бы только единственное здесь добавить, что в других компаниях, в которые лично я собеседовался, а-а, я, в принципе, вижу тот же самый стек, тоже Rust, Python, Go, TS. И я так понимаю, это большей связь связано. Python понятно, с чем связан, потому что на нём написан весь Data Science. Так или иначе, а даже мы сталкивались с ситуацией, когда есть, соответственно, известная библиотека Pandas, а Pandas на Python, которая очень хорошо и производительно работает с таблицами. Есть эта же библиотека Polars, которая написана на Rust, и она в Rust работает. Так вот, а мы прямо сталкивались с ситуацией, где, а, одни операции на Rust, которые, ну, вот просто в идее должен быть быстрее Python, а работает хуже чем те же операции на Pandas в Python. И когда мы погружались в эту тему, выясняли просто, что внутри определённые математические абстракции на Pandas написаны лучше, потому что их просто писали давно. Возможно, там ситуация в последнее время изменилась. Это мы где-то год назад наблюдали. А-а, но мы сталкивались с такими проблемами, поэтому понять, где какой язык лучше, сложно. И я, когда собеседовался, в принципе, видел понимание, что если человек разбирается в нескольких из этих языках, и он в принципе синьор, у него есть долгий опыт работы, он в принципе разбирается в основном, то ему прощается незнание каких-то основ того стека, на который переходит, с пониманием, что если этот человек очень хорошо matches с компанией, с её опытом, с её бизнесом, с его идеями и задачами, то, скорее всего, он этот стек ну там за ближайший полгода освоит, а остальное освоит за другое время и будет большую пользу приносить компании.
Поэтому, мм, наверное, вот стек, который я озвучил, он такой есть, но всё зависит, как выглядит моё интервью. Оно выглядит довольно просто. То есть я начинаю сначала человека спрашивать по его резюме уже более глубоко, где он работал, как он пришёл аа на конкретную вакансию, почему он хочет здесь работать. А-а, в момент я примерно понимаю его стек, я примерно понимаю, где он хорошо плавает и так далее. У меня составляется картина. И дальше я начинаю прыгать по стеку, опрашивать, понимая, а насколько он вообще понимает какую-то теорию, практику, насколько действительно у него есть опыта. Моё мнение, это довольно хорошо определяется, когда ты начинаешь чуть вправо, чуть влево уходить. А в конце я обычно ставлю какую-то практическую задачу, а на покодить. А обычно мы делаем каким-то лайф-кодингом, но я сам его не очень люблю, потому что он трудозатратен. А поэтому обычно я говорю, что мне не нужно разрабатывать во всех деталях и так далее. Просто есть какая-то вот практическая задача. И у меня это не теоретическая, не алгоритмическая, а именно вот прямо простая. Не знаю, там, допустим, мм, нам нужно через определённый таймер, а, запускать какой-то процесс, э, который будет собирать, э, мусор, который у нас происходит, допустим, м, от нейронки, и на основании этого, а, выкатывать стрим, который будет куда-то уходить с основными вещами, которые человек может не знать, потому что на инженеров очень стек разный и действительно там прямо очень много всё разрабатывается, тут же теряется там, грубо говоря, Все сейчас говорят о LangChain, но у нас LangChain не применяется. У нас применяется Microsoftская, э, toolset Dynamic Script. И это понятно, что человек в этом не разбирается, но основные вещи я ему даю и дальше смотрю, как он в этом разбирается, потому что дальше уже идёт понимание того, на что мы можем упереться, понимание того, где возникнут проблемы перформанса, где могут возникнуть ошибки, где мы столкнёмся с тем, что нейронка выдаёт не те результаты, которые мы бы хотели, которые хотел бы пользователь, который хотел бы бизнес. И а понимание того, что нам нужно предоставить в том числе, а что случилось с нейронкой и датасатистом, чтобы они с этим разобрались, как мы поступим, как мы справимся. Ну вот, в общем, возникает очень много вопросов, в каждой из которых можно погружаться довольно глубоко и узнавать уровень человека, уровень его познаний и, главное, уровень понимания его текущих технологий.
Основное, м, что я спрашиваю — это так или иначе пришедшему человеку нужно хорошо знать базы данных. Потому что так или иначе основа, с чем мы работаем — это данные. Данные, которые лежат в разных форматах, данные, которые куда-то направляются. Ну, то есть, во-первых, он это смешно, но тем не менее он должен знать базовые вещи. Он должен понимать, что такое объектно-ориентированные базы вообще, как они работают, э, что это под собой понимается, а-а, что такое SQL, NoSQL, что такое нормализация, как с этим быть, а как её использовать, аа он должен понимать все части SQL-запроса, как с ними вообще взаимодействовать, как что делать, если запрос медленный, как его ускорять и так далее, потому что всё это всё на практике встречается. А то же самое с NoSQL. Иногда у нас вообще там нету SQL, иногда есть. А как с этим быть? Как его ускорять? А кроме того, здесь нужно понимать, в том числе, инфраструктурные задачи, а именно, а что делать, если нам базу нужно разбить а на какие-то шарды? А как поступить в этой ситуации? Как её обработать, как быть с индексами? Ну там, ну то есть в каждый, если доходить совсем до конкретики, то и изобретается в голове прямо в этот момент какая-то простейшая задача, типа, ну у меня есть какие-то написаны, надо просто их доставать. Аа что там типа вот у нас есть пользователи и мы пишем логи, а логи всех действий этого пользователя. А, например, у нас конкретно в приложении пользователь отмечает, вот он принял лекарство, не принял лекарство, что-то сделал, не сделал, и к нам это поступает, ээ, в общем, потоком. А нам необходимо этот поток разобрать, а-а, запустить часть нейронки на этом деле, но мы к этому не будем касаться, потому что сложная штука, и её ответ, соответственно, вернуть в другой поток. А-а, и здесь основная проблема в том, что, ну, как бы хранилище, с которым мы работаем, оно SQL-ское, чтобы было быстро. И в нём данные разбиты, допустим, по ключу пользователя. И вот тут я спрошу: "А как лучше этот ключ пользователя разбить? Как лучше обращаться? Как это сделать более м как бы нагрузочно тестирование, ну, в общем, более перформансо выгодно? М и при этом, чтобы с точки зрения формата хранения данных это подходило.
А потом, возможно, по SQL, ну, я спрошу, самое просто напишем какой-нибудь запрос с джойнами и сабселектами, subquery. И я спрошу: одной таблице очень много записей, а она джойнится с другой, более маленькой таблицей. И ещё джойнит третью, которая тоже огромное количество записей. А везде созданы индексы, всё отлично, но вот она глючит. А почему? И посмотрю, как человек будет действовать в этой ситуации, как будет разбираться. А, грубо говоря, если бы я отвечал на этот вопрос, ну, там понятно, основные ответы простые, возможно, индексов очень много пересоздали и вообще просто мы не попадаем в них. Возможно, нужно от чего-то отказаться и так далее. Возможно, нужно вообще запрос перестроить и сделать его в два запроса. Это даст результат. А-а, возможно, нужно поиграться действительно с данными, передвинуть их на какое-то другое хранилище. Ну, это уже такой более глубокий вопрос.
А кроме баз данных и все вещи, связанные с данными, я спрашиваю, а-а, ну, типа у нас есть несколько, потому что зачастую всё, что связано с, в том числе AI-инженерами, ну, и по крайней мере той практики, которую я применял, так или иначе связано с микросервисами. И сам их не люблю, но мы их применяем. И поэтому я зачастую спрашиваю про распределённые транзакции, как с ними справляться, как нам сделать так, что мы из одного, ну, классическую задачу, мы в банке из одного места данные взяли, а, деньги взяли в другое место и должны положить, но при этом мы не можем сделать одной, э, транзакции на одной базе данных, потому что мы используем несколько баз данных. И как мы с этим будем справляться? А применительно к нашему случаю у нас это зачастую история такая, что нам нейронка выдала, ну вот пример прямо из практики, выдала SQL-код, который мы должны выполнить, но результат его как бы не должен примениться, потому что может быть, потому что после этого пойдёт наша проверка, а, и только в ходе этой проверки мы этот результат применим. Но проверку мы будем делать совсем в другом сервисе, который не здесь лежит и не на этой базе данных. Как, соответственно, мы с этим будем справляться?
А кроме этого, что ещё зачастую спрашивается? Ну, так или иначе тоже происходит погружение в языки. Спрашиваются языки, какие-то вещи, чтобы понять, человек плавает или не плавает. А по архитектуре, да, спрашивается, тем так или иначе м какие-то особенности объектно-ориентированной, функционально-ориентированной архитектуры, какие-то особенности вообще, а, написания кода, раскидывания данных, ну, и вообще понимание того, как работать с мониторингом, с логами, м как смотреть, как делать так, чтобы, если у нас много микросервисов, понять, что этот запрос прыгал от одного микросервиса к другому, он остался в конце концов. как вытащить данные, как в них разобраться, как писать правильно логи. Какие-то такие вещи тоже спрашиваются.
А, ну, в принципе, всё просто. Пот я везде спрашиваю внутрянку основным образом, чтобы понимать, что человек вообще понимает, что язык — это не семантика, а что-то за этой семантикой стоит. А, то есть в TS я спрашиваю про движок Node. Как он работает, как там обрабатывают события. почему он однопоточный и как при этом он может, а, асинхронно работать, а-а, что такое промисы, что под ними скрывается, как они работают. Ну, немножко, конечно.
Спрашиваю э, семантики ТСа, типа дженерики. А-а, как мы это будем использовать? Но при этом, а, в целом, если я вижу, что человек, как и я, если меня сейчас простить все типы в Тайпскрипте или там в любом другом языке, я, наверное, не вспомню. Ну, просто потому что там понятно, что я знаю там були инт там, а флот там, но потом дальше идут всякие проблемы. Где-то рей считается типом, где-то не считается, где-то референс считается типом, где-то не считается, где-то есть умные поинтеры, где-то их нету. Ну, в общем, очень много там дальше возникает вопросов, но это нормально, если человек на это не отвечает. То есть мне просто нужно понимать, что он в целом понимает, откуда это строится, что стоит за этими типами, мм, какие проверки стоит, как это проверяется, как делается Type inference, а в Тайпскрипте.
И опять же, лично я против и сам никогда не применяю. Мне не нравится на собеседованиях, когда спрашивают какие-то secret tips в духе того, что будет, если сложить, а, пустую строку плюс единицу в разных языках. Ну, действительно, если на практике кто-то так пишет, то он изначально плох. А-а, поэтому, но я всегда касаюсь вопроса, потому что моё мнение, человек в общих хотя бы чертах должен понимать, почему там, ну, стандартная вещь 0,1 + 0,1 не равно 0,3. Ну, то есть, а мне нужно понять, что человек понимает, что флот тот, которым его знает человек, отличается от флота, который его понимает компьютер в двоичной системе. Он хранится по-другому, преобразуется по-другому, и отсюда растут все, соответственно, проблемы.
И причём касаемо нашей специфики, я это спрашиваю именно потому, что мы сталкивались с такими проблемами, где для нас важна точность precision, а причём на больших знаках после запятой. И вот тут выбор нужного типа, а зачастую это вообще не известные нам типы, какие-то дестичные типы или хранение только знаменателя и, соответственно, делимого. М, ну вот это понимание у человека должно быть. Опять же, мне не нужно знать в те тонкости, мне не нужно, чтобы мне всё объяснили, мне просто нужно. То есть я зачастую даже так скажу, если человек ээ путается, я даю какие-то подсказки, говорю: "А как вот так и так?" И он говорит: "А я бы здесь вот так сделал". И если он говорит: "Я бы, я знаю, что есть вот библиотека, которая делает вот так". И я вспоминаю, что он общими чертами описывает то, что мне нужно, и там из нампая какую-то функцию, но понятно не вспоминает, я говорю: "О'кей".
А-а, что ещё? Я также спрашиваю ээ по языкам. Ну, дальше, если отходить от ТСА, переходить Гошки. Ну, я говорю, я в гошке в гом суперсильный, но обычно, конечно, всё равно спрашиваю корутины, как они работают, а как работают каналы, как работает блокировка на каналах, мм, как передаются данные из одного, ну, по каналам, из одной стороны в другую и обратно, как, соответственно, что под этим стоит в GO, аа как там потокер, как, ну, то есть мне важно, чтобы человек понимал, что, грубо говоря, какой рутины там распределять. По процессам, по потокам, как они распределяются, какой за этим более-менее стоит механизм, как происходит переключение корутин, чем оно отлично от ТСА, если там Evвентлуop, как он работает, ну вот какие-то такие вещи тоже типа посинку немного.
Аа, в том числе я здесь немного спрашиваю и про габачко коллектор обязательно, чтобы человек просто понимал, он есть, как он работает и как при необходимости, ну, хакать его. Потому что, опять же, вот здесь мы на практике, я иногда даже привожу пример, потому что люди зачастую, и я не сталкивался с этим синьорами, но ну вот на больших перформансах, на больших объёмах с этим сталкиваешься. И поэтому зачастую привожу пример. Вот то-то и то-то случилось, мы видим по логам так-то и так-то, и мы понимаем, что наш код ни при чём. Что ещё может быть? Ну, я пытаюсь вместе с человеком довести, что габариш коллектор мне бы хотя бы, чтобы он понимал, как это в целом в теории работает. Дальше понятно на практике у нас есть свои тулсеты, где мы расскажем всё, как с этим работать.
А-а, то, что касается Пайтона и Раста. А на Пайthне я тоже спрашиваю стандартные вещи, что такое GIL, соответственно, как там появляется Syncate, как это всё работает, чем отличается опять же от тестовского подхода. Как работает теперь новомодные типы в Пайthне? Немножко спрашиваю, чтобы человек понимал, что за Пайтоном что-то скрывается, что это не только Pйthon, что есть части Пайthнаписа на Пайthне, есть части Пайthна, большая часть написана на Cthне, м как они возникают, как это всё между собой связано. А по типам, ну, буквально просто прохожу так, чтобы просто видеть, что у человека есть понимание, как с этим справляться. И спрашиваю несколько основных именно базовых библиотек, опять же, потому что нам на них пишут датасатисты, нам на них приходят алгоритмы, нам с этим справляться. И, э, основное это понятно Torch, а TENOR flow, а, кес, нам пай, а, пандас. В принципе, если человек знает эти четыре вещи и немножко может разобраться, как там работает, а-а, градиент, а, как составляется й дерево, как оно обратно проходится, как его отключить, как включить, мм, как нам с тем же градиентом на определённых переменных переставить, как он рассчитывается в целом. А-а, в принципе, всё это так бегло спрашиваю, но обычно, если человек в этой сфере, то он это знает. Нано Нампае я не спрашивают там какие-то функции, как друг от друга отличаются. Я просто спрашиваю базовые вещи. А как там, грубо говоря, что такое фигура, шейп каких-то векторов, а как нам из одного шейпа преобразовать в другие? А что значит, что они не стыкуются между собой? Чем нам это плохо а в том же пайторче, когда мы сойдёмся, не сойдёмся? М, ну и как там, допустим, работать со статистикой? Как нам получать, а, рандомное, там, рандомное на какой-то статистике, там, не знаю, э, на юниформе, на geometrial и так далее. Ну, опять же, это обычно базовые вещи все знают.
Вот, ээ, на Расте тут чуть сложнее, потому что Раст достаточно новый язык, и зачастую люди приходят, которые, э, захватили его, ну, относительно недавно, там, год или два назад, но у них очень богатый сеньорский опыт другой. Они, в принципе, понимают сферу, и мы готовы их принять. Аа здесь мне просто понимание, что человек понимает раз м понимает всю особенность работы с mutable и inmutable референсами. А и так как у нас очень часто используется мультиadдин, то, ну, много поточность, то я немножко таскаю его по этой теме, спрашиваю, чем, соответственно, именно здесь отличается от аа многопоточности. Немножко спрашиваю про зелёные потоки, про токио, которые мы используем. Ну, опять же, человек не знает, Токио - это о'кей. Аа про крейты спрашивают библиотеки на Расте, как и где, э, как их загрузить, как посмотреть, как разобраться, как писать тесты. Аэ, какой-то код показываю на Расте, который у нас запускается. Но у меня есть какие-то примеры кода. А как с ними справляться?
Ну, в основном, да, наверное, основное, а, я всегда спрашиваю по Пайthну, это какие-то вещи такие датасатистские больше, но обычно человек в сфере их знает, не суперглубокие. А, и точно также на Расте есть подобные библиотеки перетащенные. Я обычно те же самые вопросы так или иначе задаю. И я обычно спрашиваю, чем асинхронность отличается от соответственно конкурентности. И немножко мы погружаемся в эту тему и проходим. Если я вижу, что человек в этом хорошо плавает, скорее всего, дальше мы перейдём к конкретным задачам.
Я помню, что раньше я постоянно спрашивал, особенно когда собеседовал на PHP, а когда-то, когда с него переходил на Джеси, на P JS. Вот это все вопросы по ОП, три основных кита ПОП, там полиморфизм, капсуляция, а за открытость. А сейчас вообще практически никогда такое не спрашиваю, но а не могу сказать, что от того, что это прямо совсем плохой вопрос, тупой, а, наверное, потому что кажется, что человек, ну, то есть я уже мало встречал людей, которые не знают этого. А второе, языки немножко так это всё повернули мм с тех форматов, которые я когда-то знал там смолки, там в Си, как меня учили там в Паскале и так далее. Потом на Яве там PHP и тому подобное. Вот что нужно как-то по-другому это всё интерпретировать, так как и в том же Расте, и в том же Пайтоне, и в том же ТСе, что у нас тек, а вся эта инкапсуляция и наследование работает вообще по-разному и на разных языках по-своему. Ну, в общем, я не спрашиваю этот вопрос и считаю его неактуальным.
А также я не спрашиваю вопросы, которые раньше очень много акцентировался. Это вопросы, которые сам когда-то брал с книги Стива Мартина, собственно, совершенный кот. Считал её долгое время своей Библией. Я вообще считаю, что её всё равно нужно знать, нужно понимать все эти принципы, но просто м они не мантра, они не серебряная пуля. А нужно поменнимать, когда их применять, когда их не применять. Просто, ээ, не знаю, как-то в моё время, когда я рос Медла до синьора, это всё было навизнаю, мне кажется, очень мало людей их знали, а сейчас как будто собеседуешь, очень много людей это всё знает, но знают на уровне какой-то заученности, как Библию, я не знаю, или Тору там, или Коран. И а применяет бездумно. То есть ты приходишь, человек просто реально, как когда-то мне рассказывали про Яву, в которой фабрика, фабрика, фабрика, а так и здесь я смотрю мне человек реально кот недавно, который смотрел просто на Pйthны надел фабрику, которая создаёт ещё одну фабрику, которая создаёт ещё одну фабрику и только в которой уже создаётся соответствующий объект. И логики в этом никакой. Э, ну просто потому что там создание создание казалось, поэтому человек сделал эту фабрику. Но, э, нет. А, но это отдельный мой больной вопрос. Я не очень люблю вот эти, когда приходят с люди с заученными паттернами и начинают просто весь код превращать, а, в галерею того, а как они хорошо знают паттерны, и с этим со всем разбираться. Вот я это не спрашиваю.
Не спрашиваю, соответственно, всякие solid принципы, всякие драй принципы, аа не спрашиваю, соответственно, все паттерны синглтон и так далее, но опять же не потому, что они глупые или потому, что они потеряли актуальность, а просто потому, что я за час не успею это спросить. А у меня есть другое, что спрашивать. И кажется, что человек уж к этому времени с этим должен разобраться. А вот что, наверное, совсем глупо. Я раньше спрашивал, ну, у меня просто, я работал до этого в других компаниях, где передо мной, если я собеседовал, обычно был HR, который спрашивал совсем простые вопросы. У меня не было, как на этой работе кто-то, кто собеседовает передо мной алгоритмы, кто-то, кто спрашивает какие-то тоже базовые технические вещи, совсем базовые. А, и поэтому раньше я тоже спрашивал там, какие вы знаете алгоритмы сортировки, а какие вы знаете алгоритмы поиска, как там обходить, а, деревья по графу, там всё это известное нам ещё с университетских времён. А-а, как там время отматывать, что такое unкстайм? Ну, какие-то такие вещи. Всё, их сейчас не спрашиваю. И, наверное, я бы их не спрашивал никогда и вообще не знаю, то есть на моём этапе нужно ли их спрашивать. Вот.
Глупые вопросы. Лично я считаю, это вопросы, сколько типов в языке и перечисли их все. Ну, блин, не знаю. Мне кажется, вот сейчас мой два моих основных инструмента RAS Python TS. Я даже на них не знаю все основные типы. Я просто понимаю, где что использовать, а что из них является типом, что не является. Ну, я всегда могу подсмотреть. А-а, вот также глупо спрашивать какие-то совсем вот эти secкретпы, а, хинты и [музыка] такие узкие особенности, которые работают в какой-то очень детальной проблеме. Ну, типа как там, я не знаю, сложить на Джесси там, а, строку с массивом, что получится или два массива, что получится, а, два пустых массива аа или там, я не знаю, там, а что будет, если на Расте мы сделаем unsaй код, который обращается к региону аа через поинтер, а, которым мы передали туда значение, и мы оттуда вытащим. Ну, понятно, что там, в конце концов это где-нибудь пойдёт и свалится, но типа а зачем писать такой код? И если уж пришла необходимость писать такой код, ну действительно, его надо несколько раз проверить, но это не то, на основе чего я буду принимать решение приёма человека на работу. А-а, ну и понятно, что в целом человек должен разбираться, что такое двоичная система исчисления дестичная, какие бывают другие. Но обычно тоже я это не спрашиваю, потому что, ну, как бы человек к этому времени должен знать.
Но меня самого зачастую спрашивали какие-то суперхаки. Когда, ну, это больше относится к алгоритмам, но когда там нужно через логическое и, логическое не ксорам, а, что-то вернуть, перевернуть, засвапать и так далее. И часть из этих хаков я знаю, но я не люблю их сам применять на работе и не очень люблю, чтобы другие применяли, потому что чтение такого кода очень затрудняется. То есть мы должны чётко понимать, что мы это делаем только тогда, когда нам нужно это по перформансу. Тогда, да, тогда о'кей. Но опять же, в этих случаях всегда можно этому научиться, это не супер сложно. Ну и точно также касается регулярки. Я сам использую регулярки, вообще к ним привык, ищу Вими и так далее, но в коде их крайне не люблю. Использую тогда вот, когда нам прямо это конкретно надо. И если человек не понимает регулярки, ну, моё мнение их может освоить.
Ну, я люблю вопросы задавать, которые непосредственно связаны с опытом моей компании. Вот, чтобы в них покопаться и видеть человек как есть. Основное на самом деле, потому что мне кажется, это 100% этой работы. Это возникла багатно какая. А код не твой написан. Ну как-то написан. А ещё у нас несколько потоков разных микросервисов, и данные непонятно где лежат. А как ты будешь с этим справляться? И вот тут мне очень интересно, как потому что нет никакого правильного ответа на эту ситуацию вообще. Ну то есть я не не могу сказать, что вот правильно ответить так. Но мне, в принципе, интересно, какое конкретное решение предложит человек, потому что иногда, аа, по этому решению я узнаю действительно человека. Ну, то есть мне так кажется, по крайней мере, я узнаю его, в том числе, психологию, мм, то, как он работает, то, какой у него опыт, аа то, насколько действительно ему нравится программировать, насколько он действительно мэчит с нашим опытом.
Наверное, мой вообще самый любимый вопрос. Я всегда задаю. Мы у нас зачастую собеседание на английском, поэтому зачастую, да, это типа what you do if you fall in this situation. Ну что ты делаешь, если ты попал вот в эту ситуацию? И зачастую типа ты понимаешь, человек сейчас подумает. Это прикольно видеть, как кто-то начинает отвечать прямо сразу, а не думая. Кто-то думает и отвечает, э кто-то прям, ну, то есть речь у человека начинает отличаться. И это прикольно. Ну, то есть это какой-то такой, может быть, плохой психологический инструмент и, но надо мной его, скорее всего, тоже ставят другие собеседующие, когда я собеседуюсь в другую компании. Но он действительно очень мне даёт очень много. Я иногда, если вижу, что человек ээ с этим вопросом хорошо справился, прямо готов много ему простить в дальнейших кусках, которые просто на знание каких-то инструментов.
На самом деле я оптимист. Людей хороших много и качественных тоже. А, но найти хорошего человека сложновато. А, и в нашей сфере тоже. А, а найти человека, который смачится вот с этой компании, надо по-русски слово подобрать, ну, в общем, подойдёт этой компании идеально, аа очень сложно. А-а, вот в этом проблема, потому что нас много, мы все не в одной точке и мы все приходим по чуть-чуть. У меня проблема обычно в другом. а-а, в том, что люди врут. Мм, ну, как бы этому и учат, если посмотреть сейчас какая-то такая вот мне немножко не нравится состояние сейчас в отрасли, что из-за того, что очень большие стоят при приёме на работу а-а так скажем, метрики, то люди свои резюме подгоняют под них, подвирая, потому что иначе их даже не возьмут. Но с другой стороны, так как и количество резюме, которые подходят, становится огромное количество, то и а-а начинают среди них выбирать опять идеальных, идеальных, и люди ещё больше начинают врать. И я сам грешен этим, что определённый свой опыт, определённые свои цифры подрисовываю, потому что, да, кто его знает, там, особенно из этих всех NDA, а сколько именно там процентов вырос у меня перформанс за внедрение той или этой технологии? А, конечно, лучше об этом сказать, потому что там на американском рынке, по крайней мере, на международном рынке тебя лучше воспринимать с цифрами, а, чем просто со словами. А-а, поэтому это о'кей, но бывает, что человек просто соврал, ну, моё мнение во всём. То есть он приходит, он пишет про себя, что он разработчик баз данных. Я думаю: "О, о'кей, мы нашли человека, который сейчас, наверное, идеально ляжет аа на вакансию нам нужно было поддерживать базы данных. там не совсем поддерживать, но помогать, в общем, а инженерам а определённые тонкости делать. А он вообще, ну, то есть он не знает SQL, как бы он не знает нормализацию, он не разбирается в индексах, он B3 деревья не знает, он не знает там стандартные какие-то вещи, которые пишется, которые моё мнение должно быть знать. У него написано 5 лет, а как он там работал 5 лет? А-а и такое прямо встречается. Или у меня встречало, что человек пишет Раст, приходит, а я вижу, что этот человек прочитал просто его в книге. Ну, не знаю, какой-то раз, то есть, ну, просто опыт, моё мнение, его, ну, как бы не пропьёшь, а его ну его не выучишь, его не заучишь. Опыт всегда виден, особенно человеку, который тоже этот опыт имеет. То есть ты всегда, ну, как бы немножко знаешь, как человека повращать вопросиками, чтобы вытащить его с заученных истин, книжных истин, чтобы он своими словами что-то сказал и как бы поплавал в неизвестном море. И тут ты поймёшь, а умеет он плавать или он просто заучил как плавание выглядит в голове. Ну, то есть там я где-то такую читал синоним, что есть люди, которые никогда не плавали, но так хорошо и много видео посмотрели про плавание и так часто дома этим занимались, что казалось, им знают. Но вывести оченьхо очень легко. А им нужно спросить, как бы они вплавали в неизвестном направлении. И вот тут-то вот у них не получится, потому что они на деле это не чувствуют. Точно так же у человека. Я его вожу на неизвестную почву, иногда даже самому мне, чтобы увидеть, как он будет применять инструменты там, где законы немножко отличаются от книг, от практики и так далее. И вот тут будет видно, а насколько человек в этом опыте. И вот тут зачастую видно, что приходят люди с ну, у них есть опыт, но в других сферах. Видно, они перепрыгнули. А так как они перепрыгнули, у них, в принципе, нормальный базовый уровень. У них хороший английский, у них, в принципе, хорошие софтскилы, но они плохо разбираются в этом стеке. И тут уже вопрос, который, как я и говорил, что иногда и мне дают такое задание, я сам готов простить человеку что-то, если он готов как бы вот в этой новой сфере плавать. Но иногда он не готов плавать, и ты видишь, что он просто он не знает какие-то вещи, которые нужно осваивать и которые нужно пропускать через себя. Поэтому лично моё мнение, очень хороших спецов много. Я очень много знаю спецов, которые круче там меня в несколько раз, и мне точно есть за кем стремиться. И вообще это круто. Вот. А часть из них очень токсичные, очень плохие, некоммуникативные. Это плохо, а потому что плохо шарится их опт. А они очень закрытые. Но часть из них очень кайфовые люди по жизни. С ними приятно общаться. Я горд, что знаю часть из них, и, ну, это очень клёво. Вот. А в целом не я оптимист по сфере. Я считаю, что нам очень много требуется ещё программистов. Я считаю, что как раз моё личное мнение, датасайнсов на требуется не так много в будущем, а потому что в основном глубокие сложные нейронки будет разрабатывать несколько компаний. Аа всё остальное - это про внедрение это в жизнь, про внедрение это в дело. И вот внедрять требуется огромный человеческий потенциал, а, возможно, намного больше, чем текущая армия программистов. И часть из них это будет именно, возможно, в будущем это будет не а инженер называться. Ну, в общем, это люди, которые способны, а, разработать систему, которую применить здесь и сейчас для данной технологии, для данной задачи с использование нейроной сети, которая будет работать и выдавать то, что нужно бизнесу, то, что нужно пользователю. Yeah.