Ещё немного рефлексии по поводу навыков Python разработчиков. Я тут регулярно провожу технические собеседования дата инженеров к команду Dateno, в основном это русскоязычные разработчики/инженеры в разных странах и с разными запросами на ЗП.
Поделюсь некоторыми наблюдениями:
1. От многих собеседуемых есть ощущение что они свою ожидаемую ЗП оценивают по средней/верхней планки по рынку и по минимальной сумме при которой им комфортно жить, но никак не по собственным навыкам. С одной стороны это очень понятно, а с другой, в общем-то навыки часто не соответствуют запросу. Это такой естественный конфликт работодатель-работник, но в целом видно что не все могут оценить свою реальную рыночную ценность. Раньше тоже такое бывало, но что-то в этом году я наблюдаю это чаще чем раньше.
2. Мои задачи на технинтервью состоят из проведения ревью кода, либо старого кода одного из проектов, либо небольшого куска искусственно созданного примера кода с заведомыми ошибками. Часто оказывается что собеседуемый прекрасно говорит, идеально рассказывает про свой опыт, но с простым ревью кода не справляется.
3. Самые частые "затыки":
- непонимание приоритетов. Вместо поиска ошибок, которые вполне очевидны, увлечение стилем кода и форматированием. Это реально какое-то массовое явление, многие сбиваются в стилистику кода вместо фокуса на решении проблем.
- незнание асинхронности в Python. Для дата инженерных задач, особенно при работе наиболее популярными инструментами оркестрации конвееров данных хотя бы базовые принципы асинхронности надо если не знать, то уметь понимать.
- невнимательность. В каждом техинтервью есть задача в которой есть вполне понятные вводные на основе которых можно понять где могут быть ошибки и как их можно увидеть. Многие игнорируют существенную часть задачи и бегут смотреть код.
- недостаток архитектурного восприятия. У Python'а есть какое-то количество шаблонных способов решения задач (как и в большинстве языков) и хороших и плохих практик, например, использование глобальных переменных без четкого понимания зачем это делается - всегда плохо. Или же когда функции перегружены большим числом операций и выполняются долго то при выбросе исключения при отсутствии сохранения текущего состояния невозможно продолжить с места сбоя
Всё это про спецов уровня миддл и выше, многие владеют инструментами, но плохо владеют техниками решения проблем. Также многие декларируют длительный опыт разработки на Python, но не знают многих особенностей языка которые не то чтобы редко встречаются.
По моему опыту довольно бессмысленно расспрашивать про инструменты, ими несложно овладеть. Неважно есть ли у человека опыт в Polars или DuckDB если он владеет Pandas, к примеру, но problem solving однозначно выходит на первый план для все кто не совсем джуниоры.
Почему? Потому что сейчас все используют ИИ для разработки, так или иначе. Это несложно и этот же ИИ делает ревью кода очень хорошо, почти все наиболее современные ИИ агенты уж точно. Но чтобы использовать ИИ для генерации кода надо понимать какие проблемы возникнуть и как решать. Это важнее чем знание промптов, это принципиальное понимание того что делаешь ты и что делают другие.
#thoughts #hiring
Поделюсь некоторыми наблюдениями:
1. От многих собеседуемых есть ощущение что они свою ожидаемую ЗП оценивают по средней/верхней планки по рынку и по минимальной сумме при которой им комфортно жить, но никак не по собственным навыкам. С одной стороны это очень понятно, а с другой, в общем-то навыки часто не соответствуют запросу. Это такой естественный конфликт работодатель-работник, но в целом видно что не все могут оценить свою реальную рыночную ценность. Раньше тоже такое бывало, но что-то в этом году я наблюдаю это чаще чем раньше.
2. Мои задачи на технинтервью состоят из проведения ревью кода, либо старого кода одного из проектов, либо небольшого куска искусственно созданного примера кода с заведомыми ошибками. Часто оказывается что собеседуемый прекрасно говорит, идеально рассказывает про свой опыт, но с простым ревью кода не справляется.
3. Самые частые "затыки":
- непонимание приоритетов. Вместо поиска ошибок, которые вполне очевидны, увлечение стилем кода и форматированием. Это реально какое-то массовое явление, многие сбиваются в стилистику кода вместо фокуса на решении проблем.
- незнание асинхронности в Python. Для дата инженерных задач, особенно при работе наиболее популярными инструментами оркестрации конвееров данных хотя бы базовые принципы асинхронности надо если не знать, то уметь понимать.
- невнимательность. В каждом техинтервью есть задача в которой есть вполне понятные вводные на основе которых можно понять где могут быть ошибки и как их можно увидеть. Многие игнорируют существенную часть задачи и бегут смотреть код.
- недостаток архитектурного восприятия. У Python'а есть какое-то количество шаблонных способов решения задач (как и в большинстве языков) и хороших и плохих практик, например, использование глобальных переменных без четкого понимания зачем это делается - всегда плохо. Или же когда функции перегружены большим числом операций и выполняются долго то при выбросе исключения при отсутствии сохранения текущего состояния невозможно продолжить с места сбоя
Всё это про спецов уровня миддл и выше, многие владеют инструментами, но плохо владеют техниками решения проблем. Также многие декларируют длительный опыт разработки на Python, но не знают многих особенностей языка которые не то чтобы редко встречаются.
По моему опыту довольно бессмысленно расспрашивать про инструменты, ими несложно овладеть. Неважно есть ли у человека опыт в Polars или DuckDB если он владеет Pandas, к примеру, но problem solving однозначно выходит на первый план для все кто не совсем джуниоры.
Почему? Потому что сейчас все используют ИИ для разработки, так или иначе. Это несложно и этот же ИИ делает ревью кода очень хорошо, почти все наиболее современные ИИ агенты уж точно. Но чтобы использовать ИИ для генерации кода надо понимать какие проблемы возникнуть и как решать. Это важнее чем знание промптов, это принципиальное понимание того что делаешь ты и что делают другие.
#thoughts #hiring
1👍18❤3🌚3✍2⚡1