/thk/ Стереотип, тянущий тебя в каменный век
За последний год я два раза менял работу, и участвовал примерно в пятнадцати собеседованиях. Не все из них были удачными. По итогу у меня, естественно, б̶о̶м̶б̶а̶н̶у̶л̶о появилось желание проанализировать свои просчеты и поделится с вами результатами.
Хочется сказать сразу, что я не буду советовать усерднее учить методы класса Object или расшифровку SOLID, но посредством рациональных логических цепочек докажу, что я Д’Артаньян, а наниматели — нет.
tl;dr — я не умею в алгоритмический задачки, не хочу уметь и уверен, что мобильным разработчикам следует игнорировать вакансии, требующие подобных умений
Будем выстраивать протекцию на основе двух конкретных заваленных собеседованиях. Хочется отметить, что мое дальнейшее мнение будет относиться только к освещенным в опусе событиям, а сами компании я, наверное, уважаю, потому что “сначала добейся”.
Первая компания — русский гугл. Я завалил последнее из четырех собеседований, которое было посвящено онлайн решению двух алгоритмических задач, уровня Easy/Medium c HackerRank. Час времени, онлайн редактор, тестов нет, написать, объяснить.
Вторая компания — русский фейсбук. Последовал ряд довольно специфичных, глубоких вопросов по iOS SDK. Говоря “специфичный” я подразумеваю нечто вроде: “В течении всего моего рабочего опыта я успешно решал все встающие на пути задачи, при этом не узнав даже такого вопроса, не говоря уже об ответе на него”. В число особо запомнившихся вопросов был: “А как устроен diff алгоритм git?”
Q: Не мог бы ты охарактеризовать задачи и их сложность, которые встают перед мобильным разработчиком?
Отмечу, что я не имею статистических данных, потому все дальнейшие ответы и рассуждения базируются только на опыте моем и моих знакомых, друзей. (здесь и далее не берем в расчет геймдев) 90% это верстка, простейшие REST запросы в сеть, парсинг и вывод json на ui. Если совсем откровенно, я тоже самое сказал бы и про веб.
Разумеется, я наслышан о существовании AR, блокчейна и машинного обучения. На них я и оставляю абстрактные 10%. Однако находясь в поиске вакансий, я перебрал их довольно много (около 200, полагаю) и видел только один раз видел слово AR (блокчейна и ml не было в помине).
Задачи мобильных разработчиков состоят в следующем:
- читать много чужого кода и понимать его
- вносить в него изменения, не затрудняя его понимание для коллег
- запрос к серверу, парсинг, вывод на ui, поменять шрифты, изменить цвет, выбрать тип выравнивания текста
“Чтение чужого кода — 80% времени программиста” — мысль очевидная и придуманная не мной. Само количество книг, статей и докладов на тему “Как писать чистый код?” лучше всяких слов доказывает, что это действительно очень важно.
Очевидно, что если большую часть времени занимает осмысление чужого кода, оптимизации стоит начинать именно с этого места.
Как оптимизировать (уменьшить) время, которое вам нужно, чтобы вдуплить, что за набор буквнаписал ваш сосед? Нужно сделать так, чтобы все писали код хорошо, где уровень “хорошо” задается непосягаемыми авторитетами и жаркими диспутами активных поборников чистоты.
Q: Но ведь сложные вещи в работе тоже есть! Послать данные по сети, обработать swipe-жест или сохранить данные в память телефона — это же очень сложно. Этим должны заниматься только люди с очень глубоко развитым алгоритмическим мышлением, разве нет?
Подобная точка зрения противоречит реальному положению дел. У меня есть определенный кругозор, я знаю не только историю мобильной разработки. Даже в рамках небольшого срока (3-х лет) очевидна тенденция развития в сторону упрощения, путем создания высокоуровневых абстракций:
Специальные люди работают над инструментами для ваших продуктов. Эти инструменты тщательно тестируются, валидируются. Если не их разработчиками, то пользователями. Если ваш молоток разваливается на части после двух ударов — никто не будет им пользоваться. Ваша фирма не будет популярна, это очевидно.
Просто подумайте над этим. Остановитесь на секунду и окиньте свою жизнь скучающим взором. Необязательно быть программистом, чтобы осознать, что идея “делать что-то, основываясь на достижениях других людей” — это благо.
Если же вы все таки въедливый вредный программист:
- Spring Boot — абстракция над абстракциями. Сама идея продукта в том, чтобы сделать конфигурации и настройки максимально простыми
- C++17 — надо ли знать виды блокировок и отличать lock от recursive_lock? Идите, ознакомьтесь
- JS — даже не хочу уточнять, что конкретно. Просто весь JS: vanillaJS+html -> React; callback -> promise -> async/await; css -> flexbox
Да все вокруг подчинено этой тенденции. Появление ООП. C -> С++. Автопилот в самолете. Конвейер. Макдональдс. Car-sharing.
Людям очень хочется уметь делать больше, затрачивая меньше усилий. Безусловно, можно натренировать супер-специалистов, и они будут выполнять ваши сложные задачи отменно, писать на ассемблере и не допускать ошибок. Можно вышколить пилота до безобразия, чтобы на любое событие был рефлекторный отклик. Но это займет больше времени, и больше денег при отсутствующей выгоде для вас.
Переиспользуйте чужой труд. Аутсорсите. Разделяйте обязанности. Это быстрее. Это качественнее. Так работает мир.
Когнитивное искажение людей заключается в обычном нежелании признать простую истину: программист не должен знать как устроены его инструменты. Он должен доверять им.
Q: Не зная того, как устроены ваши инструменты, вы не можете считать себя профессионалом. В случае возникновения проблемы, вы не сможете понимать, где искать ее корень.
Когда вы, забивая гвоздь молотком известной фирмы, херачите себе со всей дури по пальцу — у вас есть только два выхода:
Первый — вы начинаете разбираться в материалах молотка, изучаете сплавы, химический состав. Если понадобится, вы покупаете маленький учебник квантовой физики для чайников и узнаете, что атом — не самая маленькая частица. Вы начинаете понимать очень многое о том, как устроен молоток. Но палец по прежнему болит, а гвоздь не забит.
Второй — вы признаетесь, что вы криворукий фуфел, и со второго раза, соблюдая достаточный уровень осторожности, забиваете долбанный гвоздь.
Ладно, давайте без гипербол. Ситуация, в которой ваш инструмент действительно дал сбой, может произойти. Но, даже не зная, как именно молоток работает изнутри, вы поймете, что причина в нем. Умея читать и понимать код, вы также обладаете способностью локализовать место ошибки. Если в месте потенциальной ошибки есть ваш молоток — имеет смысл обратиться к производителю.
Опять же, должны ли вы лезть и править ошибку сами? Нет. Когда у вас ломается машина, вы идете в сервисный центр. Когда у вас ломается здоровье, вы идете к врачу. В этом и заключаются плюсы нашего времени — в любой момент вам могут оказать помощь профессионалы.
Очевидно, вы не сможете достигнуть даже приемлемого уровня умений во всех необходимых для жизни областях. Поэтому, единственный правильный выход — достигнуть его в одной и менять свои услуги на услуги других людей. Это даже не мои досужие доводы, это — эволюция.
Q: Так почему же тебе не нравится требование умения решать алгоритмические задачи и разбираться в глубинном устройстве твоих инструментов?
Потому что это контрпродуктивно. Регрессивно, если позволите. Повар может быть профессионалом, не зная устройства техники выплавки ножей. Стилист может быть профессионалом, не зная устройства швейного станка. Гонщик может быть профессионалом, не зная откуда берется бензин.
К этому нет предпосылок, это не нужно.
На мой взгляд, профессионал это человек, который знает, что сделать со своими инструментами так, чтобы на выходе получился качественный результат. Будь то вкусное блюдо, красивый наряд или лучшее время на трассе.
Штука в том, что умение решать алгоритмические задачи никак не поможет вам быстрее понимать код и писать его более понятно. И, есть мнение, что код решения алгоритмической задачи — это наименее понятный и читабельный код.
Поэтому, я бы сказал, что эти компании требовали от меня контр-продуктивных знаний. Знаний, которые, буквально, противоречат прогрессу, эволюции и рациональности. При этом умения, которые могли бы реально ускорить качество и скорость моей работы (использование сторонних инструментов без тщательного изучения их внутренностей), были проигнорированы и даже восприняты негативно.
Q: Но ведь надо же как-то проверять людей, отбирать лучших. Чем это — не критерий?
С тем же успехом можно было бы считать критерием умение решать интегралы. Или, например, паять свои платы. Ну а что, это же тоже про логику и компьютеры?
Не так страшно быть неправым, как прилюдно, уверенно именовать аксиомой гипотезу, являющуюся ошибочной.
