За последние несколько лет я провел много собеседований. На масштабе начинают проявляться паттерны, и кандидаты часто сводятся к некоторым архетипам, если это так можно назвать.
Один из таких архетипов — «инфраструктурный решала». Извините, лучше названия нет и не будет. Так вот, такой разработчик отлично разбирается в СУБД, очередях, кэшах и прочих хранилках и молотилках. Он знает, как строчки в табличке мапятся на страницы на диске. Он может рассказать всё про блокировки и уровни изоляции. Он действительно решал все эти проблемы на практике, по крайней мере он так звучит и может так же уверенно отвечать на вопросы, уходящие вглубь. Нередко от таких кандидатов возникает ощущение, что они знают и умеют больше меня.
Но вот кандидату задается вопрос не про СУБД или что-то вокруг, а про, внезапно, программирование. Причем вопрос необязательно про специфику конкретного языка. Тут-то вся уверенность куда-то исчезает. Теперь почти все ответы строятся на робких предположениях и на том, что кандидат где-то когда-то прочитал или услышал.
Когда я столкнулся с инфраструктурным решалой впервые, я не очень понимал, как его оценивать. Вроде бы человек задачи закрывает, сложные кейсы разруливает, кажется, даже умеет в архитектуру. Но, например, найти баг в конкурентном коде — уже проблема.
У меня долго это не укладывалось в голове. Потом я понял: дело в том, что мы как индустрия планомерно переносили сложность из разработки в эксплуатацию. Это хорошо, поскольку так мы можем победить сложность один раз, спрятать её и больше об этом не думать. Но бывает так, что сложность победили не до конца или спрятали, но так, что уши всё ещё торчат.
Мой любимый пример — постгрес. С одной стороны, это самая популярная, народная СУБД. С другой — полиэтиленовый пакет с абстракциями, вытекшими наружу из-за того, что пакет дырявый. Причина, по которой на любом техническом интервью есть секция, посвященная отдельно постгресу, — сложность, которую он должен как бы скрывать, но в итоге просто превращает в другую сложность. Нельзя просто создать индекс и рассчитывать, что постгрес будет его использовать. Почему? Потому что постгрес умный и может решить, что индекс ему не нужен, и пройти сексканом будет быстрее и лучше. Что? Да! И как бы да, часто он в этом прав. Но это лишь один пример одной из множества неочевидных деталей внутреннего поведения СУБД, о которой необходимо знать, чтобы не попасть впросак. Да и насчет «прав» я погорячился — быстрее всё равно не стало, зато появилось что расследовать. И в конце концов, его никто не просил этого делать.
Сумма всей сложности в замкнутой системе остаётся постоянной — как ни старайся её перекладывать из одного угла в другой.
Поэтому в глазах индустрии умение именно программировать больше не имеет такого значения. Точнее, может, и имеет, но сам процесс происходит в большей степени не в коде, а в других местах: базе данных, кубернетесе, очереди или слаке. Плохо ли это? Я не знаю. Опять же, какая разница, если задачи решаются, цели достигаются и при этом качественно? А что если нужно будет сделать всё то же самое, но вместо WhoopSQL будет нужен PoopSQL? Пока опыт подсказывает, что в таких случаях решалы чаще всего впадают в ступор — в отличие от тех, кто учился программировать, а не быть оператором.
Под умением программировать я, конечно, не имею в виду вещи типа «чем инт отличается от флоата», «как работает наследование» и т.п. Скорее речь про системное мышление, умение переносить концепции и абстракции из одной области в другую. Ну и, конечно, те самые «фундаментальные знания».
Короче, я что сказать-то хотел. Изучайте постгрес, кафку и кубернетес — это вам сильно поможет тактически. Но не забывайте про само программирование, чтобы не проиграть стратегически.
Один из таких архетипов — «инфраструктурный решала». Извините, лучше названия нет и не будет. Так вот, такой разработчик отлично разбирается в СУБД, очередях, кэшах и прочих хранилках и молотилках. Он знает, как строчки в табличке мапятся на страницы на диске. Он может рассказать всё про блокировки и уровни изоляции. Он действительно решал все эти проблемы на практике, по крайней мере он так звучит и может так же уверенно отвечать на вопросы, уходящие вглубь. Нередко от таких кандидатов возникает ощущение, что они знают и умеют больше меня.
Но вот кандидату задается вопрос не про СУБД или что-то вокруг, а про, внезапно, программирование. Причем вопрос необязательно про специфику конкретного языка. Тут-то вся уверенность куда-то исчезает. Теперь почти все ответы строятся на робких предположениях и на том, что кандидат где-то когда-то прочитал или услышал.
Когда я столкнулся с инфраструктурным решалой впервые, я не очень понимал, как его оценивать. Вроде бы человек задачи закрывает, сложные кейсы разруливает, кажется, даже умеет в архитектуру. Но, например, найти баг в конкурентном коде — уже проблема.
У меня долго это не укладывалось в голове. Потом я понял: дело в том, что мы как индустрия планомерно переносили сложность из разработки в эксплуатацию. Это хорошо, поскольку так мы можем победить сложность один раз, спрятать её и больше об этом не думать. Но бывает так, что сложность победили не до конца или спрятали, но так, что уши всё ещё торчат.
Мой любимый пример — постгрес. С одной стороны, это самая популярная, народная СУБД. С другой — полиэтиленовый пакет с абстракциями, вытекшими наружу из-за того, что пакет дырявый. Причина, по которой на любом техническом интервью есть секция, посвященная отдельно постгресу, — сложность, которую он должен как бы скрывать, но в итоге просто превращает в другую сложность. Нельзя просто создать индекс и рассчитывать, что постгрес будет его использовать. Почему? Потому что постгрес умный и может решить, что индекс ему не нужен, и пройти сексканом будет быстрее и лучше. Что? Да! И как бы да, часто он в этом прав. Но это лишь один пример одной из множества неочевидных деталей внутреннего поведения СУБД, о которой необходимо знать, чтобы не попасть впросак. Да и насчет «прав» я погорячился — быстрее всё равно не стало, зато появилось что расследовать. И в конце концов, его никто не просил этого делать.
Сумма всей сложности в замкнутой системе остаётся постоянной — как ни старайся её перекладывать из одного угла в другой.
Поэтому в глазах индустрии умение именно программировать больше не имеет такого значения. Точнее, может, и имеет, но сам процесс происходит в большей степени не в коде, а в других местах: базе данных, кубернетесе, очереди или слаке. Плохо ли это? Я не знаю. Опять же, какая разница, если задачи решаются, цели достигаются и при этом качественно? А что если нужно будет сделать всё то же самое, но вместо WhoopSQL будет нужен PoopSQL? Пока опыт подсказывает, что в таких случаях решалы чаще всего впадают в ступор — в отличие от тех, кто учился программировать, а не быть оператором.
Под умением программировать я, конечно, не имею в виду вещи типа «чем инт отличается от флоата», «как работает наследование» и т.п. Скорее речь про системное мышление, умение переносить концепции и абстракции из одной области в другую. Ну и, конечно, те самые «фундаментальные знания».
Короче, я что сказать-то хотел. Изучайте постгрес, кафку и кубернетес — это вам сильно поможет тактически. Но не забывайте про само программирование, чтобы не проиграть стратегически.