Чтобы признать, что ты не можешь решить задачу, нужно уже обладать уровнем, достаточным для ее решения.

Если уровня понимания сложности не хватает, то задача обычно решается криво, но человеку кажется, что все хорошо. Если понимание сложности задачи есть, то чаще всего проблема не в нехватке знаний или опыта. Обычно не хватает другого: времени, внимания, сосредоточенности, упорства, чтобы дойти до сути и не свернуть раньше времени, учловий работы, чтобы не дергали (ну сам себе не создал таких условий).

Так что, берите тех людей, которые говорят, что "не могут" и помогайте, их предел обычно ближе к реальности. А вот уверенность тех, кто сразу заявляет, что все элементарно, означает, что они не видят глубины.

Axios Supply Chain Attack

кто там не слушался? я уже 6-7 лет говорю, что нужно выкидывать бяку, быстро переходим на fetch api, undici, node.js built-in api

https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html

На хорошем собеседовании человеку должны разрешать спросить у AI, смотреть документацию, гуглить, да любые инструменты, которые он использует в ежедневной работе. Собеседование должно проверять не память и даже не экспертизу, а эффективность. Способность решать задачи, принимать решения, отличать рабочее решение от маразма и не плодить говнокод.

Многие думают, что если дать кандидату доступ ко всему, то он сразу покажет высокий уровень. Нет. Наоборот, очень быстро становится видно, кто умеет думать, а кто просто выучил слова. Человек может идеально рассказать про event loop, garbage collection, паттерны и другие вещи, но в реальном коде не способен принять ни одного зрелого решения.

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

Что реально нужно?
- Насмотренность, кругозор, проактивность.
- Доброжелательность, а не токсичность в работе.
- Умение писать простой, понятный, надежный код.
- Умение быстро освоить любые знания и инструменты.
- Парадигмы, понимание модулности, декомпозиция, зацепление и связность.
- Умение изолировать то, что должно меняться независимо.
- Способность донести мысль в понятной форме.
- Принятие ответственности, а не перекладывание ее.

Проблема почти всегда не в инструментах. Один и тот же язык, один и тот же фреймворк, один и тот же стек дают у разных людей совершенно разный результат. Один делает продукт, который можно развивать годами. Другой делает хрупкую конструкцию, которая рассыпается от любого изменения. Дело в инженерном подходе.

То же самое с оптимизацией. Прикладному разработчику не нужно играть в исследователя виртуальной машины. Его задача в том, чтобы решать проблемы предметной области, вникать в задачу. В прикладной разработке стремление к низкоуровневому коду часто просто маскирует нежелание разбираться в реальной сложности продукта.

Тезис простой: на собеседованиях надо проверять мышление, вкус, зрелость решений и способность добиваться результата с любыми доступными инструментами. В обучении надо больше учиться чтению кода и анализу (в том числе после AI), на код-ревью, рефакторинг, контракты и поддерживаемость, на коммуникацию с коллегами и заказчиками.