Начал серьёзно готовиться к техничке. Посмотрел, “что в мире делается”, почитал, собрал материалы. А не все технички плохи и бесполезны, хочу я сказать.

Сперва читаешь вопросы с собесов и думаешь: “Сколько проектов делал, с таким ни разу не сталкивался. Глупость какая-то…”, - а потом вспоминаешь какой-нибудь легаси, где именно вот этого вот знания и не хватило… Читаешь задачи и такой: “да это же фигня! Ща я её…”, - а там фишечка, что решить задачу может каждый, да вот не каждый может решить её отлично. Вроде все эти O(n) выглядят как академия, а потом у тебя проект, где авторы вообще полодили с самого начала на все подходы, правила и парадигмы и ты понимаешь, что такое плохой код. Когда у тебя между кликом и действием секунды времени - это плохо. А это плохо, в свою очередь, из-за того, что вместо O(n), взяли решение O(n⁴), да ещё напортачили с реактивностью, event loop и получилось как получилось.

Инженера от разработчика, разраьотчика от программиста, программиста от кодера отличает глубина контекста знания и даль горизонта планирования. Вопрос на обсуждение, но считаю, что ИНЖЕНЕР - это апогей процесса развития специалиста.

Если описать основной функционал: Кодер - пишет, просто пишет текст программы. Копирастит готовые блоки. Он не думает - он делает.

Программист - программирует. Он составляет последовательности команд. Моет быть думает, может быть не думает. Но его работа чуть сложнее и важнее работы кодера. Программист уже может принимать решения.

Разработчик - разрабатывает. Он думает, проектирует конкретное решение для конкретной задачи. Принимает конкретные решения в контексте задачи.

Инженер - планирует. Контекст его решения лежит в области, шире области задачи. Инженер - это уже разговор о системе.

А что нужно специалисту, что бы не просто писать разработанный код программы? Нужен контекст знания. И может быть никогда в жизни вы не столкнётесь с ситуацией, когда вам надо будет понимать разницу между куками и локальным хранилищем, но само это знание увеличивает ваши способности на принятие оптимального решения.

Есть ли глупые задачи на техничке? Есть. Являются ли они умышленными? Иногда (к сожалению). Нужно ли знать на изучить, что кроется под L в SOLID? Практически нет. Нужно ли уметь отличать DRY от DDD? Нужно. Как минимум для коммуникации.

И вот получаем, что: - готовиться к техничке нужно всю жизнь. Постоянно. Работа сужает контекст - это плохо; - глупые вопросы раскрывают вас и интервьюера как специалиста и человека; - порой вопросы, не относящиеся к вашей области компетентности, помогают решать задачи эффективнее.