Привет, Хабр!
Недавно команде разработки beeline cloud попалась вот такая статья. И оказалась она довольно дискуссионной. Настолько, что мы решили ее перевести и узнать мнение широкой аудитории — а кто же, по вашему мнению, достоин называться синьором?
Похвально, когда ради карьерного роста специалисты отваживаются пройти собеседования на инженерные должности. Достойно уважения и то, что они понимают сложность предстоящих им испытаний, сопряженных порой со стрессовыми ситуациями.
Уже несколько лет я провожу собеседования с инженерами для различных компаний. В последнее время, как никогда ранее, угрожающе выросло количество кандидатов, которым приходится отказывать в должности. Ничего не изменилось в методах тестирования — вопросы те же самые. Проблема в людях — они не имеют представления о том, что значит быть старшим инженером. И это при огромном спросе на подобных специалистов.
Десятилетний опыт в программировании на деле ничего не значит. Не время определяет статус senior’а.
Постараюсь описать, что для меня значит быть старшим инженером в области разработки программного обеспечения.
Так кто же ты такой, старший инженер?
ChatGPT (чат-бот с искусственным интеллектом) выдал следующую формулировку:
Старшие инженеры обладают глубоким пониманием языков программирования, принципов проектирования программного обеспечения и методологий разработки.
— изрёк чат-бот и тут же обесценил наше маленькое исследование
Рассмотрим пример классического собеседования.
Методологии разработки
Организационные методы, направленные на повышение эффективности работы команды специалистов, называются методологиями разработки. Они могут быть довольно нудными, но, тем не менее, вы должны уметь разбираться в них.
Годы работы привили мне неприятие методологий, лишённых гибкости. Более того — я считаю, что даже Scrum недостаточно гибок. Его чрезмерное использование в конечном итоге тешит самолюбие менеджеров проектов в большей степени, чем программистов.
В собеседованиях с разработчиками я ищу в них способность к критике. Недостаточно знать Scrum, важно также понимать его недостатки и уметь найти методы их устранения.
Знание разработчиком других методологий, кроме Scrum и Kanban (таких, как, например, RUP) говорит в его пользу. Оно свидетельствует о готовности учиться за пределами своей области.
Принципы проектирования программного обеспечения
Есть правила, которым профессиональные программисты следуют каждый день. Когда-то вы о них читали, затем благополучно забыли, но на уровне подсознания они всегда с вами.
Востребованность инженера уровня «рокзвезда» гораздо выше, чем у его коллег. Дело не только в программировании. Высококлассный инженер обладает невероятной креативностью и способностью видеть концептуальные закономерности, недоступные другим.
— Рид Хастингс, cоучредитель компании Netflix
Готов поклясться, я мог бы сделать клише и в отзывах кандидатам после окончания каждого собеседования впечатывать один и тот же ответ:
Рекомендую вам более внимательно ознакомиться с паттернами проектирования Python. В частности, советую обратить внимание на это руководство.
Кандидатов можно отфильтровывать в том числе и по паттернам проектирования, которых они придерживаются или просто знают. В очень редких случаях я получал ответы абсолютно на все свои вопросы.
Освоив паттерны проектирования, можно столкнуться со сложностью их применения на практике. Лично мне доводилось попадать в ситуации, когда при написании кода не удаётся их сразу вспомнить. Умение заставить себя при программировании каждый раз выполнять самопроверку, продвинет вас на шаг вперёд.
Языки программирования
Почему в Python принято использовать len(array), а в других языках – array.length()? Есть ли в этом какая-то логика?
А хорошо ли вы знаете этот язык и то, как он работает «под капотом»?
Литература по изучаемому языку программирования абсолютно необходима каждому, кто хочет приобрести фундаментальные знания. Лишь опираясь на полученную таким образом информацию, вы будете готовы к непременным каверзным вопросам собеседования.
Плохое впечатление губит многие собеседования
Ребята, нельзя ли побыстрее с ответом? У меня так-то есть предложения и от других компаний.
— Слова кандидата на собеседовании, когда ему предложили задать вопросы о предстоящей должности.
Предлагая огромные зарплаты, компании ищут незаурядных людей. Поэтому умение произвести хорошее впечатление на интервьюера сыграет вам на руку.
Оценивается не только уровень подготовки кандидата, но и его отношение к делу. Недавно, например, компания попросила нас искать в большей степени «хороших и честных» людей, нежели великих программистов.
Тщеславный человек оказывает негативное воздействие на коллектив. Рядом с ним слишком тяжело работать. И в долгосрочной перспективе ущерб, нанесённый им компании, может обойтись очень дорого.
Дурные манеры или заведомая ложь могут привести к немедленному исключению из конкурсного отбора.
«Как завоевывать друзей и оказывать влияние на людей» — одна из книг, которую должен прочитать каждый. Она поможет понять, как правильно устанавливать взаимоотношения в коллективе.
Опытные инженеры должны уметь руководить командой. Нужны высокие коммуникативные способности, чтобы занять эту должность. Не забывайте об этом.
Что нужно знать младшему/среднему звену, чтобы подняться на ступень вверх?
Несколько замечательных ресурсов помогут вам в этом:
А как же навыки работы с кодом?
Несколько месяцев назад я купил LeetCode Premium. Интересные математические курьезы, паттерны и оптимизации от других пользователей очень помогли мне. Благодаря этой подписке я сумел получить мою нынешнюю работу.
Имитация собеседования в крупной компании также не повредит. Она позволит получить представление о том, что ожидает вас в реальности.
Стремясь к звездам, вы, возможно, достигнете неба.
— Рейнгольд Нибур
Есть и другие сайты, подобные LeetCode, например, AlgoExpert и CodeSignal.
Суровая правда
Даже прочитав множество материалов, практикуясь каждый день и имея большой опыт, вы можете получить отказ, потому что не соответствуете профилю компании.
Несколько дней назад я слушал подкаст, где рассказывалось об эксперименте, в ходе которого детей заставляли решать задачи, а затем разделили на две группы:
первую группу похвалили за сообразительность;
вторая группа заслужила поощрение за упорство в поисках решений.
Когда им предложили более трудные задачи, дети, которых хвалили за упорство, справлялись с ними. В то время как дети, считавшиеся сообразительными, в конечном итоге отставали в их решении.
Как видите, главными вашими чертами должны стать упорство и настойчивость. Именно этих навыков все ожидают от старшего инженера. И они же обеспечат вам работу в будущем.
Что еще почитать инженер-программисту?
Автор объясняет, почему его компании нужен только Jmix: подробно об инструментах и интерфейсе
История о том, как обеспечить качество продуктов и фиксировать опыт работы.
Практический кейс о том, как переделать кастомный логистический продукт в облачное SaaS-решение и привлечь сотни клиентов.
beeline cloud — secure cloud provider. Разрабатываем облачные решения, чтобы вы предоставляли клиентам лучшие сервисы.
Комментарии (29)
VladimirFarshatov
11.12.2023 20:07Какой-то сборник ссылок и цитат, без какого-либо конструктива или связи с заговолвком.. Чат-гопоты писал статью или первод с его бредогенератора?
micronull
11.12.2023 20:07Со статьёй явно что-то странное.
Уже несколько лет я провожу собеседования с инженерами для различных компаний.
Благодаря этой подписке я сумел получить мою нынешнюю работу.
stef5636
11.12.2023 20:07Я согласен.
Последние 25 лет я работал сениором, управлял командами, нанимал людей, и это заставило меня задуматься, кто этот человек, который говорит мне, что я не сениор, если я не понимаю Scrum и Rup. Этот человек с 2016 по 2021 год работал фрилансером в студии геймификации. С тех пор он пробыл на одном месте не более года. Да, есть несколько 2000 подписчиков, но это не делает тебя старшим. :(
Не могу согласиться со многими высказанными мыслями
Чтобы стать старшим, нужно быть очень хорошо технически подготовленным, иметь большой опыт и уметь быстро учиться. Умение справляться с негативными моментами в команде.
Извините, русский не мой родной язык
dprotopopov
11.12.2023 20:07Умение справляться с негативными моментами в команде.
Это в точку - обычно айтишники - более-менее интелигентные люди - с канцелярскими ножами на тебя не бросаются - не то что обычные "рабочие" парни ))))))) (было)
aktuba
11.12.2023 20:07Рекомендую вам более внимательно ознакомиться с паттернами проектирования
Rly? Часто встречал (да и чего уж там - сам точно такой-же), когда человек не знает названия паттернов, но успешно их применяет. Но на собесах, чаще всего, необходимы именно названия...
Самый смешной случай был, когда собеседующий спросил про mvc, но именно для него mvc === ооп. Чуть ушел в сторону и он "поплыл" со словами "без ооп невозможно реализовать mvc".
Умение заставить себя при программировании каждый раз выполнять самопроверку, продвинет вас на шаг вперёд.
Тут точно подразумевается "вспомнить, как называется паттерн"?
А хорошо ли вы знаете этот язык и то, как он работает «под капотом»?
Ну раз уж выше про python: сколько, на вашем опыте, разработчиков смотрели исходники python?
Опытные инженеры должны уметь руководить командой
Нет. Сысоев сделал классный инструмент, не умея руководить - он плохой инженер? Я могу сотни таких примеров привести.
Благодаря этой подписке я сумел получить мою нынешнюю работу.
Т.е. не благодаря кругозору, "софт-скиллам" (о чем говорится прям пунктом выше), а благодаря алгоритмическим задачам? Это ли не показатель "нормального" "сеньор-инженера"?
Именно этих навыков все ожидают от старшего инженера.
Ммм... Нет.
Пост - странный... Ощущение, что человек случайно стал "сеньором" и теперь раздает советы (
dprotopopov
11.12.2023 20:07// ...
// xx.xx.2020 protopopov@narod.ru "KABAN"->"SCRUM"
var nameOfCurrentTechnology = "SCRUM";
aktuba
11.12.2023 20:07"KABAN"->"SCRUM"
Закончим на этом?)))
Rive
11.12.2023 20:07Ну может задачи складываются в сумочку (かばん ).
dprotopopov
11.12.2023 20:07Цель любой декомпозиции задачи - разбить её на мелкие, которые можно проигнорировать
akaddr
11.12.2023 20:07У меня был случай, человек ответил про логарифмическую сложность алгоритма, но не знал что такое логарифм
GospodinKolhoznik
11.12.2023 20:07А как вы это выяснили, если не секрет? Ну просто не могу себе представить, как могла пойти беседа. Не стали же вы его гонять по школьной математике?
panzerfaust
11.12.2023 20:07Но на собесах, чаще всего, необходимы именно названия
Постоянно это слышу, но буквально ни разу не встречал, чтобы именно на названиях фокусировались. Обычно показывают сниппет или просят рассказать про суть какого-то паттерна.
Ну и названия своих инструментов знать полезно - это показатель профессионализма. Кодить-то можно хоть как, а вот коммуницировать с коллегами нужно уже грамотно. Я не смог бы воспринимать серьезно человека, который не может выучить слово "прокси" - и вместо этого объясняется в стиле "ну короче когда вот это вызывает вот то, то на самом деле оно вызывает другое" и т.д.
Rishamogov
11.12.2023 20:07Я могу сказать, как работодатель, чего я ожидаю от сеньора: для меня это middle, который научился видеть не локальную задачу, а цель. Middle, который может считать не на ход вперёд, а на 2-3 шага. С кем можно обсудить архитектуру на высоком уровне и не объяснять почему в этом месте должен быть Rabbit, а в этом Redis.
dsh2dsh
11.12.2023 20:07и не объяснять почему в этом месте должен быть Rabbit, а в этом Redis
Если это действительно сеньор, объяснить придется. А то ведь может оказаться, что кролик там вовсе и не нужен.
panzerfaust
11.12.2023 20:07Почему в Python принято использовать len(array), а в других языках – array.length()? Есть ли в этом какая-то логика
Так почему же? Самое интересное осталось без ответа.
Мне понравился ответ JetBrains, когда их спросили, почему у них в котлине Deferred, а не Future или Promise. Future или Promise уже были заняты - ответили они. Некоторое языки и фреймворки целиком проектируются по принципу "ну такая конструкция уже есть у ХХХ - давайте извращение какое-нибудь придумаем".
SHLAKBAUM
11.12.2023 20:07Всё очень просто. Это для того, чтобы длину можно было легко вычислять при программировании в функциональном стиле.
ru5l4n
11.12.2023 20:07Я слышал другую версию. Чтобы вычисление длины можно было сделать одним способом, и для стандартных коллекций, и для кастомных классов, которые по функционалу напоминают коллекции
Вот, например
https://lucumr.pocoo.org/2011/7/9/python-and-pola/
igorzakhar
11.12.2023 20:07Почему len — не метод
Я задавал этот вопрос разработчику ядра Раймонду Хэттингеру в 2013 году, смысл его ответа содержится в цитате из «Дзен Python»: «практичность важнее чистоты» (https://www.python.org/doc/humor/#thezen‑of‑python). В разделе «Как используются специальные методы» выше я писал, что функция
len(x)работает очень быстро, еслиx— объект встроенного типа. Для встроенных объектов интерпретатор CPython вообще не вызывает никаких методов: длина просто читается из поля C‑структуры. Получение количества элементов в коллекции — распространенная операция, которая должна работать эффективно для таких разных типов, какstr,list,memoryviewи т. п.Иначе говоря,
lenне вызывается как метод, потому что играет особую роль в модели данных Python, равно как иabs. Но благодаря специальному методу__len__можно заставить функциюlenработать и для пользовательских объектов. Это разумный компромисс между желанием обеспечить как эффективность встроен ных объектов, так и согласованность языка. Вот еще цитата из «Дзен Python»: «осбые случаи не настолько особые, чтобы из‑за них нарушать правила».Лучано Рамальо, «Python. К вершинам мастерства» 2 изд., с. 45
panzerfaust
11.12.2023 20:07Я когда только начинал собеседовать, то тоже любил найти вот такой хитровыдуманный факт и превратить его в вопрос. Потом дурь эта ушла.
M_AJ
11.12.2023 20:07В последнее время, как никогда ранее, угрожающе выросло количество кандидатов, которым приходится отказывать в должности
Угрожающе для кого? Если в мире недостаточно людей, которые соответствуют вашим требованиям, то это не проблема этих людей, это проблема ваших требований – они оторвались от реальности. Другого глобуса у нас нет.
Chelyuk
11.12.2023 20:07Что-то много недосказанности. А как же сторона DevOps и тулов?
ИМХО - мидл, должен хорошо знать техническую предментную область - язык программирования, паттерны, архитектуры - это всё легко учится из теории. А старшой - должен уже обладать более широкими софт скилами, знать разницу гибких и строгих методологий. И главное уметь плясать от продукта, а не от того что он умеет. Не совать везде - я так 20 лет он-лайн магазины писал и UI на приборку авто так же буду делать. А уметь выбрать оптимальную методику, архитектуру, паттерны. Уровень документации от самодокументируемого кода, до Detailed Design, Software&System Architecture документов. Объяснять мидлам и джунам, почему их супер-навыки в Vim в данной команде будут только во вред и что он не просто так потратил время на конфиг для IDE и настроили pre-commit git hooks. И сколько дрвгоценного времени это экономит. Ну и опять же это всё если проект для команды или нескольких команд. А если проект на 2 недели на коленке в одно лицо что-то состряпать. То тут не стоит убиваться и поднимать CI/CD на 4 энвайронментах. И писать конфиги, ревью чек-листы и архитектурные документы.
pruginka_d
11.12.2023 20:07Статья как раз описывает типичную контору, куда не стоит пытаться пролезть. У них у всех типичная болезнь. Они думают, что они уже тоже почти Гугл или хотя бы Яндекс. И бесконечно ищут Нео, который спасет их маленький семейный бизнес. Причем, бывает, проходишь техническое интервью и все рады, но спотыкаешься на главном боссе, который начинает задвигать как раз про архитектуру. Причем, у него уже есть ключевое слово, которое ты должен произнести, например "Кафка" (Он недавно прочитал про нее что-то в интернете). Не произнес - все. На выход.
MrNutz
11.12.2023 20:07Много всякой фигни.
Всё эти скрамы и прочая должны быть к месту. Это ну очень редко встречается. Обычно скрам ради скрама.
Шаблоны тоже должны быть к месту.
Мого раз видел как всю эту теорию знают хорошо, а вот на практике фигня получается. В итоге приходится потом за этими спецами теоретиками доделывать и переделывать.
И да, не знаю этих скрамов и прочее. Теорию шаблонов тоже не особо. Мой ключевой навык это решение поставленной задачи. Для этого разберусь и изучу что требуется. Смогу организовать работу команды и наладить процессы. И мне не все равно. Т.е. к работе отношусь ответственно. И тут мне говорят что херня это все. Самое важное знать вот эту понтовую фигню.
jura-49
11.12.2023 20:07Очень правильная цитата в одном из комментариев к этой статье "Много всякой фигни". Я скажу даже, что "Все одна фигня". Формализованные вопросы собеседования не позволят найти хорошего программиста.
Начнем с трех составляющих старшего инженера, которые автор выпытал у ChatGPT.
Методология разработки вообще никак не связана с СКРАМ. Скрам – это плохая практика управления для "небольшой команды", но ни как не методология проектирования. Автор мог бы спросить у ChatGPT или Википедии. Например, ChatGPT выдал такое определение: "Методология проектирования (или проектирования систем) - это набор принципов, подходов, практик и процессов, используемых для разработки и построения технических и информационных систем". Оно в целом коррелирует с определением в Вики. И скрама в определении нет.
Принципы проектирования программного обеспечения. Автор снова путается. Для него принципы проектирования сводятся к патернам. Вероятно, он сам не знает что такое принципы KISS, YAGNI, dry, SOLID и пр.
Языки программирования. Знание нескольких языков программирования (включая любимый автором статьи питон) не делает из человека программиста. В лучшем случае (в сочетании со знанием патернов) – кодера. Можно провести аналогию. Много людей умеют писать по русски (английски, французски, …), но большинство из них не может написать даже небольшой рассказ. Кстати, такие известные писатели и поэты как, Пушкин, Баратынский, Маяковский, Кэрролл, Хемингуэй, Кристи и много других были безграмотными и писали с ошибками.
Наверное, более правильно определять уровень программиста поговорив с ним о тех проектах, в разработке которых он принимал участие и какую роль выполнял в них. Таки образом можно будет определить уровень сложности проектов, которые кандидат сможет разрабатывать. А если посмотреть как изменялась его роль в проектах, то можно оценить его амбициозность.
И еще раз. Статья плохая.
iggr63
Это не про упорство и настойчивость. А о том что если результаты работы оцениваются адекватно, то работающие будут прилагать больше усилий чтобы достичь результата и в следующий раз.