В целом мои мысли когда я слышу, что кто-то считает себя Senior можно выразить так: I don't care that you think you are a Senior. Show me the code. Prove yourself. Earn your stripes. Respect is earned, not given. Факт того что кто-то считает себя синьором мало о чем говорит (читайте “может вообще ни о чем не говорить / быть пустым звуком”).
- Можно считать что ты умеешь в JavaScript и в итоге писать на нем как ты писал в C#, не понимая примитивы, специфику языка (functions as first-class citizens, etc.), специфику платформы, апи платформы, флоу исполнения кода (как интерпретатор исполняет код). В лучшем случае это “натягивание одного языка на другой”, в худшем случае это неуместное использование либ типа deasync.
- Можно считать что ты умеешь в TypeScript и на практике иметь пол кодовой базы в any (все что сложнее базовых string, number, array, etc.). Про понимание дженериков вообще молчу.
- Не понимать акторную модель программируя на эликсире.
- etc.
- Можно взять GraphQL но остаться мыслить REST-ресурсами и в итоге ваше апи это REST в GraphQL.
- После изучения базовых примитивов типа actions, reducers думать что познал Redux. О чем тогда остальные буквально миллион страниц в доке?
- Можно иметь Реакт и мутировать стейт/пропсы, апдейтить дом ноды через рефки.
- etc.
А в итоге ставить пакеты глобально и не понимать за виртуальные окружения. Писать код в многоэтажные ифы, код в котором кроме тебя никто не разберется и чтобы его хоть как-то дорабатывать придется неделями изучать что же ты там написал.
Человек не понимает разницы в более критичных аспектах и менее критичных аспектах, не чувствует баланса complexity/simplicity, cost/value.
Например бэкендер который не понимает разницу в поддержке между внутренним и внешним/публичным апи. Что наличие публичного апи сильно ограничивает свободу его менять когда захочется, что есть клиенты и нужно их как-то мигрировать, продумывать эволюцию апи. Может именовать как попало, создавая не консистентное апи в плане нейминга/реализации (3 пагинации и все реализованы по разному), тут названо так, а там эдак. Отсюда так же может вытекать что человек демонстрирует свою зеленость, у него отсутсвует фильтр на complexity/simplicity, не понимает объема работы который берет на себя и накладывает на будущих людей кто будет это апи поддерживать. Бесконтрольно расширяет апи (если клиенту X надо добавить значит надо!), не является менеджером апи (не пытается понять что клиенту нужно и не оценивает можно ли его запрос решить текущим апи вместо добавления новых ручек). Не понимает что нельзя доверять инпуту от клиента, полагается на валидацию на фронте.
Максимум о чем это число говорит так это что человек должен был написать/видеть код хоть раз в своей жизни.
10 лет можно по-разному провести. Можно 10 лет прожить каждый год разнообразно, богато на опыт, языки, насмотренность, доменные области, занимаясь разной сложностью задачами в итоге имея солидную экспертизу написания и поддержки кода, принятия решений и сталкиваясь с последствиями своих решений, работы в команде с разными людьми. А можно прожить один и тот же год 10 раз делая тоже самое.
В общем N лет опыта - не аргумент.
В целом работа в какой-то (не)известной компании тоже мало о чем говорит. Компания - продукт, аутсорс это прежде всего бизнес, задача бизнеса - делать деньги, на пути к “делать деньги” у компании самой могут быть “проблемы”, например то что произошел резкий наплыв клиентов, либо пришел какой-то огромный клиент с объемом работы который не потянуть текущим штатом, но клиент важен для будущего компании поэтому компания берет на себя эту непосильную задачу и начинает активно нанимать людей, часто жертвуя профессионализмом чтобы получить больше свободных рук.
Мы не знаем в какой момент жизни компании человек был нанят: было это обычное, относительно стабильное время (запросы клиентов покрывались текущим штатом + компания открыта нанять одного-двух человек, компания действует по принципу better safe than sorry и лишний раз лучше откажет чем возьмет сомнительного кандидата), или это было критичное для бизнеса время, где он должен был выжить или выйти на новый уровень, в двух последних качество часто приносится в жертву в обмен на возможность оставаться на плаву / получить больше клиентов/более жирных клиентов, компания вынуждена идти на компромиссы, снижая планку требований к кандидатам.
Если компания была огромная, то чем этот человек занимался? Участвовал в более менее важных ключевых проектах или был где-то на периферии поддерживая какую-то админку по принципу “это внутренний инструмент, не нужно делать хорошо” которой от силы пользуется несколько человек? Сколько он за ней провел? год, два, три?
Кто собесил этого человека? Опять же ситуации бывают разные, но кто это были? Зеленые чуваки или условно head of frontend/backend/CTO?
Сам человек ушел или его уволили?
Кто такой Senior очень зависит от компании, в мире где мы пытаемся засунуть весь спектр в три/пять категорий (Junior, Middle-, Middle, Middle+, Senior) неизбежно будут искажения и человек может оказаться в почти любой группе. В одной компании ты Senior, в другой Middle-. Все зависит от того какие задачи вы решаете, средний уровень разработчиков внутри компании, какие требования предъявляются к Senior.
В целом справедлив факт что и наоборот, кандидат может оказаться и супер крутым (и его N лет опыта, работа в компаниях над проектами X, Y, Z, владение языками и технологиями действительно что-то значат), поэтому важно всем давать всем кредит доверия, разговаривать на равных и пытаться понять кто перед вами (крутой кандидат сам часто поможет вам в этом) и насколько он подходит для открытой позиции.
Учитывая что ключевая задача это решать задачи, нужно смотреть на ключевой аспект: умение в решение задач :). На практике задачи часто могут быть решены как чисто вербально так и чисто технически, а чаще всего это самый разнообразный микс этих двух элементов. Поэтому важно как посмотреть на техническое решение, так и важно наблюдать как проходит коммуникация от начала до конца реализации технического решения.
В процессе интервью:
- задавать вопросы с практическими нюансами, там где есть что-то что можно было прочувствовать только делая, только на практике (например, нюансы ошибок при работе с асинхронным кодом в JS/TS - какой из блоков в цепочке поймает ошибку, как прокинуть ее вверх по цепочке? разница в return vs await vs return await, что такое фрагменты в GraphQL и какие есть примеры юз кейсов с ними?)
- дать задачу перед интервью и обсудить код на собесе
- попросить отревьювить чужой код/код с проекта (посмотреть на какие вещи обращает внимание, а какие считает не важными, насколько часто и упорно спорит, может ли уступить, спорит по критическим моментам или просто на ровном месте?)
- попросить отрефакторить код (понимает ли что такое рефакторинг? without changing its external behaviour!)
- говорим ли мы на одном языке? Если мы договорились отрефакторить, то что это значит для человека? Важно ли для человека говорить на одном языке? Возможно для него это все "набор терминов" и он не понимает их связь и важность на практике. Я считаю что важно говорить на одном языке и понимать одинаково, иначе командная работа страдает, недопонимания начинают носить непредусказуемый характер в плане масштаба расхождения с тем что требуется сделать / ожидается на выходе и фактическим результатом. Еще один пример к выше с рефакторингом: человек может путать хеширование с шифрованием.
В целом человек который пишет код на постоянной основе будет виден сразу, как быстро он затипизирует что нужно, будет хотеть сокращать синтаксический шум там где это можно без потери смысла (типа использования короткого return, вместо того чтобы писать {return x;} в его коде преобладает => потому что так проще, ёмче, меньше шума потому что он знает что он может вернуться сюда и нужно будет быстро разобраться в том что там происходит). Сразу будет видно по тому как он именует, структурирует код. Если ты постоянно пишешь код, то набираешь определенную скорость думать, писать, держать в голове апи языка, то с тем же ты и на интервью придешь.
Тема с talk is cheap и что нужно смотреть на то что человек делает хорошо затрагивается в книге которую я сейчас читаю - Skin in the game. Там Талеб в ряде историй проводит параллели с Мафией, тем как Fat Tony подходит к людям, к пониманию что они представляют из себя на самом деле. Ее так же можно наблюдать в The Sopranos, в сезоне где появляется Фьюрио (серия commendatory). Тони летит в Италию, встречается с Фьюрио, и первый раз обращает внимание на то что как он себя проявляет в момент когда закрывает своим телом их итальянского босса от кажущегося начала стрельбы (в итоге это просто ребенок играет с бомбачками). Далее когда Тони устраивает вечеринку/празднование в честь приезда Фьюрио, Кристофер возвратившийся в очередной раз от проблемного чувака с которым Тони сначала ожидал что Кристофер разберется, а затем слыша в очередной раз что проблема не решена, говорит Кристоферу “а, забей”, понимая что вот еще одно дело для Фьюрио и решает проверить его еще раз. Дэвид Чейз делает на этом четкий акцент. Так же Тони обращает внимание на ценности Фьюрио (belives in the old ways, keeping silent, putting the family first, или переводя в программирование - user comes first, баланс simplicity/complexity, cost/value, high cohesion, low coupling, modularity, etc.)
Переводя это дальше на язык разработки, где стоит узнавать человека? В совместной работе, в коллаборации, в обсуждении технического решения, контракта/апи между бэкендом и фронтом, одним сервисом и другим, насколько нужно часто за него додумывать, упускает ли он важные детали, нужно ли его дообучать чему-то к чему он должен был сам прийти за эти N лет, нужно ли я его няньчить.
С реальным сеньором (который и агрументировать и договориться и написать код умеет) часто как с высокоуровнеивым языком, у тебя больше времени остается на фокус на разработку продукта, на бизнес задачи а не сражения с компилятором (c++) /интерпретатором который выбрасывает ошибки в которых чтобы разобраться нужны танцы с бубном.
Как ни странно, здесь стоит искать match с людьми по ценностям, пониманию что делает крутой проект крутым (фокус на крутом user experience & user comes first или на красоте технических решений? сможет ли человек пожертвовать технической красотой и элегантностью когда она будет конфликтовать с задачами бизнеса здесь и сейчас от которых может зависеть будущее продукта?), уровень тиммейтов, качество кода, темп работы, и т.п. Матч закладывает фундамент того что человек захочет остаться, зачем уходить куда-то если тебе классно на текущем месте, где есть like-minded люди с которыми тебе интересно и проект который тебе интересен?
Так же я считаю что менять людей это неблагодарное дело, и стоит того только в очень редких случаях. Люди инерционны в своем поведении, в качествах которые ими движут, так что стоит искать именно качества в людях, это то что в долгую позволит получать качественный результат.
- стремление к качеству / the determination to ensure that the design quality stays high.
- being thorough (thorough - (of a person) doing things very carefully and with great attention to detail)
- ...
Опять же, возвращаясь к идее что человека надо наблюдать на деле, нужно как раз наблюдать качества которыми вы хотите чтобы человек обладал. Здесь как раз помогает тестовый период в несколько месяцев (от 1 до 3), если в конце вы не довольны друг другом - вы расстаетесь.
В идеале в команде / среди людей кто отвечает за найм должен быть человек который ruthlessly (within reason, of course) будет "вести" этого человека, давая более простые задачи в начале помогающие окунуться в процесс и разобраться в доменке, и заканчивая бизнесовыми / продуктовыми задачами. Кто доведет / пронаблюдает человека до этапа (и оценит так ли это) где его можно считать универсальной боевой единицей которую можно кинуть на любую проблему и быть уверенным что человек закроет / решит проблему. Это промежуток времени (1 - 3 месяца) самый показательный и богатый на инсайты о человеке.
В конце концов, если формулировать в двух словах, то вам важно как и с какой скоростью человек деливерит фичи / задачи, если вас это устраивает - человек остается, если нет - вы с ним расстаетесь.
Еще заметки по другим темам здесь.