+7 При прохождении интервью в ВОТВАСЯ/MMANGA с очень большой вероятностью вы будете получать весьма двусмысленные задачки и вопросы, которые не подразумевают очевидный однозначный ответ или решение. И чаще всего такие задания не имеют ничего общего с обычной работой, с типовыми тасками. Они готовятся специально, топовые компании целенаправленно расставляют разные ловушки, чтобы проверить, кто вы такой на самом деле. Вы должны быть готовы к этому.

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

Но тут начинать надо с того, что уточнить -- используем ли стандартный (в экосистеме вашего языка) тип linked list? Если да, если гарантируется, что всегда есть связанные head и tail, то в нём циклов не может быть в принципе :)

Да и в нестандартном, если реализован аккуратно, тоже циклы не должны присутствовать. А искать циклы в заведомо кривой реализации, хм...

"Дайте кому-нибудь программу, и он будет мучиться целый день; научите кого-нибудь программировать, и он будет мучиться всю жизнь"
-- David Leinweber, глава Lawrence Berkeley National Laboratory Computational Research Division's Center for Innovative Financial Technology

то странное чувство, когда пишешь интерпретатор хаскеля на питоне, а на вопрос "почему на питоне-то, а не на самом хаскеле (ибо деды дали заповедь "лисп на лиспе")?" отвечаешь "он проще"...

Сегодня практически везде учат принципу DRY именно как "не повторяйся", или что ещё примитивнее, "не копипасти код". Сами по себе эти рекомендации безусловно хорошие, но оригинальная идея DRY в The Pragmatic Programmer была про "единственное истинное представление" ("single point of truth") каждой части кода в рамках системы, что ближе даже скорее к SRP.
DRY просто неудачным названием оказалось.

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

Например, две группы студентов решают на leetcode задачки уровня hard. Одну и ту же сильно сложную задачку можно решить множеством способов; первая группа решает одну и ту же hard-задачу три раза, вторая -- три разные hard-задачи. И на четвёртый раз вторая группа решает hard-задачу первой группы существенно лучше, чем сама эта группа, вроде бы уже её как следует изучившая!

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

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

"Функциональность а-ля инстаграм на минималках: показывать карточки, лайки, личный кабинет, соответственно регистрация и авторизация.
Моя оценка — это все задачи для человека как минимум с двумя годами реального опыта. Пройти путь с нуля когда не понимаешь что такое переменная и что функцию надо вызвать чтобы заработала, и до такого объема работы за 9 месяцев, очень и очень сложно."

Ужасность программирования очень быстро возрастает с увеличением порядка :)
Объекты первого класса (обычные функции, числа...) страшны совсем немного, и то лишь начинающим.
Объекты второго класса (функторы, map/fold/...) уже довольно сильно страшны всем императивным программистам.
Количество хорошо изученных объектов третьего класса можно пересчитать по пальцам одной руки (call/cc например), и их прикладное применение под силу лишь элите, топовым выпускникам Оксфорда Гарварда.
А объекты четвёртого класса убоюсь даже упоминать...

Какой язык программирования объективно лучше? Ну т.к. любой язык программирования -- это прежде всего синтаксис,
то требуется прежде всего
a) хорошая рефлексия (что подразумевает гомоиконичность (структура программы похожа на её синтаксис)), и
b) возможность манипуляции синтаксисом (макросы).

Так :) Прекращайте уже мне рассказывать, как вы "изучаете" Haskell, или как вы "изучаете" TAPL, или как вы "изучаете" "новый Розеттский камень", все эти карго-культы и умничанье на уровне детский сад штаны на лямках. Пока вы самостоятельно не сделали на нормальной работе за нормальную зарплату проект/подсистему хотя бы на 20,000 строк "ООП", забудьте вообще об этом всём.

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

Сегодня буквально за 3 года весь ваш опыт обесценивается на 100%, если вы не развиваетесь карьерно в плане требований рыночных вакансий.

Моего трека по ООАП вам абсолютно достаточно для проектов на десятки тысяч строк; вот как научитесь их качественно делать, потом и тратьте время на понты (хотя это всё равно глупо, если вы не понимаете чётко, что это вам даст, а просто тупо "интересненько", просто кривые от императивщины мозги запутаете ещё больше).

Вот ваш прямой трек в ИТ: вам надо научиться легко создавать рабочие (за которые вам платят) проекты (самостоятельно или с подчинёнными),
с полной ответственностью за результат:

100 строк - 1,000 строк - джун - 10,000 строк - миддл - 100,000 строк - хороший миддл - ...

Моего трека по ООАП вам абсолютно достаточно до этого уровня. Вот пока до него не доберётесь, вообще прекратите тратить ресурсы впустую на любые побочные темки.

+9 Если у вас нет внутреннего интуитивного знания про O-большое, что определяет, сколь качественно вы реализуете требования, чувствительные к производительности, то вы никак не программист (не говоря уже об инженере-программисте).

Вы притворяетесь, что пишете код.

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

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

P.S. К тем, кто проходил мои курсы по АСД, не относится конечно.

Сегодняшняя популярность Python и Java -- примерно то же самое, что популярность Microsoft Basic и Borland Delphi лет 20 назад, когда они годами оставались на пике популярности, и казалось, что ничто не сможет поколебать их доминирование.
Не введитесь на "популярность" каких-то технологий, изучайте в первую очередь универсальные вечные вещи.

+10 Когда вам понадобилось в проекте что-то улучшить, не думайте об этом по схеме "что нового надо добавить" (какую очередную приляпку прифигачить :).

Думайте по схеме "как получить результат, удалив что-нибудь из проекта". Удалив лишние функции, лишние классы, лишний код...

+12 Стратегия развития в ИТ: формировать под профиль своей карьеры личную библиотеку абстракций, которые дают вам всё лучшие и лучшие результаты в ваших проектах, в вашем стеке, требуя при этом всё меньше и меньше ресурсов для реализации.

Только не жадничайте, не жмотьтесь, не таите их, наоборот, смело рассказывайте другим. Окружающие вас бедолаги всё равно в 97% случаев не смогут этим воспользоваться, потому что сами привыкли жадничать на своих ничтожных крохах "знаний", и просто не верят, когда им объясняют например, что оказывается можно добиваться тысячекратной компактности кода :)

Рекламные обещания Java: write once, run anywhere.

Реальность: переписываете проект каждый раз как выходит новая версия Java, и молитесь, чтобы ваши контейнеры после этого продолжали работать.

Чтобы не получалось вот так и не возникало желания сбежать из айти:

"Ночные релизы, бесконечные переработки, легаси код, невнятные баги, грубые разговоры в курилках и в коридорах, постоянные требования от менее технически подкованных коллег, иногда целые блоки кода, а то и сборки, отправленные в корзину… Выгорание? Жажда новой жизни?"

надо понимать прежде всего вот это.

Не выгорание и не жажда новой жизни, а просто вы следуете неверной карьерной стратегии. Поэтому помогаю теперь по этим темкам индивидуально каждому занимающемуся.

+13 В продолжение темы библиотеки личных абстракций -- как её формировать?

Отвечает Ричард Фейнман :) Когда его спрашивали, как стать гением, он советовал всегда держать в уме десяток отборных любимых задачек, и каждый новый лайфхак, каждый новый приём прогонять через все эти задачки и смотреть, как он сработает на них. Те, которые работают хорошо, и добавляете в свою библиотеку.

Это примерно как своя тщательно отобранная и сформированная колода карт в MtG например (хотя все карты вроде как самостоятельны, но в то же время связаны определённой логикой друг с другом). Вы встречаете очередную задачку, очередной вызов -- и легко бьёте их своей супер-колодой! На любую проблему у вас есть работающее решение.
А вокруг все офигевают: как он это делает? он гений!

Наблюдение: Python постепенно превращается в TypeScript 😁

Если вы активно работаете с базами данных, или серверным программистом на бэке, и при этом не слышали о проблеме N+1 , то сейчас где-то заплакал котик.

Eric Von Reinhard, работавший ведущим программистом в швейцарском Google, в качестве лучшего языка программирования на перспективу в 2022-м рекомендует изучать Python.

Отмечу только в дополнение к вот этому его аргументу

"Companies compete all the time and they look for fresh developers who know a modern language… not the old Java and C++."

что Python тащит сегодня с собой вообще всё, начиная с 1991 года, и почти всё из этого всего вам никогда не понадобится.

Ну, началось! А я уже не один год говорю -- нейросетки это хорошо, но мир таки захватит AI на формальной логике :)
В The NetHack Challenge 2021 (программы, мастерски играющие в легендарную рогульку) победил с ощутимым отрывом AutoAscend -- чистый символьный AI. Нейросетки тут не конкуренты, потому что они не умеют "думать стратегиями" и скорее всего никогда не научатся.

Я на нетхак потратил когда-то наверное тысячу часов :) До Амулета Йендора добирался...

P.S. И немного о грустном: в свежем Tortoise "The Global AI Index" Россия в мировой AI-гонке остаётся стабильно в третьем десятке, 32-е место.

Мир с помощью AGI (символьного :) через 2-3 десятилетия захватят США + Великобритания, или Китай, на 99%. Довольно внезапно с 12-го на 5-е место (за год!) поднялся Израиль. Впрочем, нифига не внезапно: он на первом месте в мире по относительному финансированию темы AI и на душу населения, и по исследовательским работам.

+15 "Разворачиваемость" вашего проекта (скорость лёгкость простота его деплоя) -- это одна из неотъемлемых, ключевых, абсолютно обязательных целей любого правильного проектирования.