Комментарии 214
Рынок меня избаловал, раньше я ходил только на те собесы, куда меня позвали из-за статей — чтобы не пришлось никому ничего объяснять.
Это статья чтобы опять позвали на интервью? Есть масса контор которые про Хабр вообще не слышали, так что можно париться по поводу блэклиста. Хотя конечно в таких конторах только за деньги и работать (и самое хреновое, что за небольшие деньги).

Ну и Хрюшек надо пожалеть, по сравнению с программистами, им реально будет плохо, но те кто останется, будут свой синдром вахтёра включать на полную.

В интересные времена живём. Куча стартапиков на жирных рынках схлопнулась (кричат SOS — Save Our Startups). Месяц назад, разработчиков с руками отрывали, а через пару недель по десятку на одно место будет стучаться.
через пару месяцев, или в худшем случае лет, все вернется.
Вернётся конечно, не через пару месяцев, но через годик должно. Но некоторым вкус смузи придётся на это время забыть, хотя мне он и так не очень нравился.
Да, вовремя я взял «Перерыв» на годик: Понял, что выгораю. Накопил денег на год вперед, уволился и сейчас просто отдыхаю… Понемногу офигивая от того, что происходит в мире…
Надо было уехать на острова для информационного детокса, и вернуться в совсем другой мир

Ну или лишние деньги инвесторов оттянут бонды, снова ставшие привлекательными после репрайсинга

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

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

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


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


Теперь правила изменились. Работа нужна мне как воздух

Работа и раньше всем нужна была как воздух (если ты не сын Рокфеллера). Ничего не изменилось. Кроме желания выехать на хайпе еще разок.


Простите, но мне кажется, что это еще одна статья написанная только ради хайпа. И, конечно, порекламировать свой подкаст.

Я не особо много искал работу, но вот пока искал — пришел к выводу, что когда ты сам реагируешь на вакансии — ты в основном не являешься кандидатом, а пополняешь всевозможные базы потенциальных работников. Т.е. очень нехилый процент холодных откликов, так ни до чего и не доходящих — это норма, а не особенность.

25 февраля — 18 марта — три отказа.


Это не доказывает даже то, что у Вас сейчас нет работы. Более того, отказы отказам рознь. Я могу выложить свое резюме с завышеной вилкой на линкедин и у меня будет отказов 10, наверное, и только за неделю.


Я не буду спорить с тем, что Вы могли (да и наверное попали) в плохую ситуацию. Я не буду спорить с тем, что когда есть дети и семья, которую надо кормить эта ситуация усугубляется.


Я спорю с тем, что Ваша статья нужна. Она не несет пользы, она пытается играть на трагизме, и ее основная цель — пиар. И, простите, но предыдущие Ваши статьи это только подтверждают.

Даже в моём мухосранском технаре был предмет «Технология поиска работы», где препод нам объяснил, что отказы это нормально, не стоит рассчитывать на удачу, а просто пытаться дальше пробовать несмотря ни на что.
Основная цель любой статьи — пиар. Ты пишешь на хабр, что бы люди про тебя узнали. про тебя, или про то что ты делаешь. Ну и в целом, сообщество решает, какие статьи ему нужны, а какие нет.
А как же желание поделиться чем-то, или помочь другим?

«Взгляни! Я пресытился своей мудростью, как пчела, собравшая слишком много меду; мне нужны руки, простертые ко мне.»
Желание конечно есть, но что-то я сомневаюсь, что его одного хватит. Особенно если никто и никогда не узнает, что это именно ТЫ поделился и помог другим
И да, не три отказа, а восемь — прошло много времени, фидбека нет — врядли они мне завтра напишут, что ждут меня на собеседовании
НЛО прилетело и опубликовало эту надпись здесь
ип, вылютный контроль, зато зп получается в нормальных деньгах, не подверженных курсу партии
НЛО прилетело и опубликовало эту надпись здесь
Это пока харя партии позволяет «в нормальных деньгах» получать, а не принудительно продать их в ВЭБ, а потом по курсу для электората физикам купить. А то, судя по новостям про конвертацию вкладов в ОФЗ или еще какую херню со сроком погашения до второго пришествия, дядя Вова и на источник валюты от физиков руку наложит.
Это пока харя партии позволяет «в нормальных деньгах» получать,

А можно валюту после ВК оставлять непроданной, на валютном счету и потом переводить на счет физлица? Как рассчитывают налог на доход в этом случае?
налог на доход считается как разница между курсом продажи валюты и курсом ЦБ на этот же день. т.е. если вы получили 1000 долларов при курсе 60р, а продаете их через месяц за 80р при курсе цб 81р, ндфл/налог на прибыль/доп усн платить не надо
Вы говорите про продажу валюты — это понятно, тут все стандартно. Выше речь шла про «оставить в валюте»:
Это пока харя партии позволяет «в нормальных деньгах» получать, а не принудительно продать их в ВЭБ, а потом по курсу для электората физикам купить

Я предполагал, что конвертация валюты в рубль обязательна. Просто не интересовался этим вопросом.
им просто не нужен сотрудник, а собес проводят ради интереса.

Довольно дорогостоящее развлечение. Откуда такие выводы?

Здесь часто пишут программисты, что временами проходят собеседования просто чтобы прощупать рынок труда на текущий момент.
Почему бы компании не сделать то же самое? Например, перед открытием нового отдела или проекта — чтобы оценить, стоит или не стоит.
Это может быть способо набить базу резюме и хрюше отчитаться перед начальником хрюш о свое продуктивности. Еще это может быть способом помониторить рынок, а потом своих работников позвать на разговор в кабинет face 2 face с предложением начать больше работать, а деньги — «ну ты ж видишь какая ж. в стране».
НЛО прилетело и опубликовало эту надпись здесь
Вы так написали, как будто получать зп в валюте это что-то плохое… Это огромный бонус, который позволяет вам максимально сгладить весь негатив, происходящий с нашими рублевыми фантиками! Я бы когтями вцеплялся в подобные вакансии!

В локальной валюте по более-менее нормальному курсу тоже достаточно неплохо, чтоб не заморачиваться ВЭД. Кстати, в России сейчас можно с валютного счёта ИП выводить на валютный счёт физлица без двойной конвертации?

Выводить можно, да. А с современным интернет банкингом никаких заморочек с ВЭД больше нет — пару кликов в мобильном приложении и готово.
Прям с транзита на валютный ФЛ? Как в этом случае рассчитывается налог на доход?

pnovikov
Разница, как вы можете видеть, РОВНО НА ПОРЯДОК. Ещё есть вопросы почему люди не пишут технические статьи?

А потом еще получить слив кармы за какую-нибудь субъективную мелочь в политсраче. Это, пожалуй, должно сильно мотивировать писать сложные технические статьи.
НЛО прилетело и опубликовало эту надпись здесь
А почему hh, а не LinkedIn? Там и вакансий на удаленку больше, и сливки жирнее.
Отпишусь, меня заинтересовал автор в октябре 2019, думал пособеседовать и взять на работу (планы были набрать 40 разрабов), далее получил ценник в 4500$ (~300k) на руки чего ожидал автор, по вилке лида он прошел бы но рассматривал его в посл очередь, так как были ребята готовые катать в офис, а при старте нового проекта это гораздо важнее чем в середине или в конце когда команда устоялась. В итоге до собеседования так и не дошли так как нашел ребят с опытом лидов за 320 и 350. А на вилку сеньора ну никак не влезал. В целом по общению нормальный парень. Ну может оно и к лучшему счас тех ребят каких искали практически распустили а офис закрыли, проекты с туризмом были связаны.
Т.е если бы автор мог нормально катать в мск за 220-240 на руки (каждые 2 недели на 2-3 дня), то думаю после тех собеса взял бы ибо горело прям сильно.
* в рамках взгляда с той «темной» стороны менеджеров и CTO
Если код пишется с такой же скоростью, как ищется работа, то понятно, почему уволили из конторы.

Если до кризиса найти работу занимало от ~30-40 собеседований по нескольку этапов каждый, то в кризис надо бегать еще быстрее и планировать 100 собеседований, не меньше. Такими темпами как на картинке можно надеяться на работу к концу пандемии.
Этот темп в пять раз выше, чем мой обычный. Обычный такой — нашёл одну вакансию, понравилась, устроился
Работа и раньше всем нужна была как воздух (если ты не сын Рокфеллера). Ничего не изменилось. Кроме желания выехать на хайпе еще разок.

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

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

Ну, тут возразить нечего, абсолютно согласен. Но так Вы статью не напишите :)

Молодец правду написал, у меня такое было несколько раз, Бог даст — не повторится больше. Однако выход лежит не области программирования, а кардинальной смене мировоззрения — учиться нужно много, сменить точку опоры в жизни радикально, чтобы больше не падать!

Добро пожаловать в жизнь 50% работяг в мире. Говорят ощущения многократно усиливаются если денег нет настолько, что приходится брать микрокредит. А ведь самое интересное обещает быть впереди, если смотреть на США.

А если смотреть на ЕС? А на Австралию?
Не одними же Штатами живо IT.

Ну судя по всему сейчас следом пойдут Италия, Испания, Германия, Франция, Англия. Так что я думаю ЕС можно записывать туда же. Про Австралию пока непонятно, подождем, посмотрим. Ну и на США все смотрят потому что деньги там, и многие ИТ конторы работают на них в конечном итоге, пусть и через длинную цепочку посредников.

Куда пойдёт Германия и почему? Аналогично про Францию.
Испания и Италия — крупные игроки на рынке?
Многие, но далеко не все работают на Штаты.

В Германии 103к заболевших на 83 млн населения итого 0,13% от населения, во Франции 99к на 67 млн. итого 0,14% от населения. 4 и 5 места в мире соответственно. Население США 370к на 330 млн. итого 0,11% от населения.

И что из этого следует?
Вы в курсе, где самое большое количество тестов сделали?

я в одном там аутсорсере из топ-3 на прекрасном.ит — пока прогноз на 7-15% снижения активности клиентов в течение лета…
В Австралии и до эпидемии в IT работы почти не было (из-за переизбытка кандидатов).
По крайней мере, на порядок меньше чем в РФ.
10 резюме говорите? А 100 резюме без отклика не хотите?
forums.whirlpool.net.au/thread/9rpm2vv9

Такие ребята и в Штатах есть, но это не означает, что работы нет.

Сравнивать IT рынок в США и Австралии это всё равно что сравнивать Москву с Воронежом.
Если вы прочитаете вышеупомянутый thread и все аналогичные на австралийских форумах, то увидете что всё обсуждение идёт в ключе: «ну что же вы хотели, это же IT, надо в другую сферу переходить или переежать».

Вы делаете какие-то выводы основываясь на форумах.
Естественно, что рынок в Австралии меньше, но это не означает, что в Штатах нет таких же "счастливчиков", которым отказывают на сотнях резюме и предлагают переходить в другую сферу или валить куда подальше.

Вовсе нет, я знаю это из своего опыта и опыта знакомых. Форумы я привёл в качестве доказательства. Впрочем, если бы вы жили в Австралии вам не пришлось бы даже это объяснять — это как бы известный факт.

ИТ-это вообще не профиль Австралии. Основа экономики — это, прежде всего, майнинг, затем «образование», туризм и животноводство. ИТ тупо аутсорсится. Можно конечно попробовать найти снег в пустыне, но зачем?

Так что ответ на ваш вопрос пожалуй будет таким: да серьёзное ИТ это очень часто именно США. Есть ещё пожалуй оазисы в Китае, Израиле, Индии, Германии, Англии, Швейцарии…. Но ожидать что приехав в какой-нибудь Буркина-Фасо как тестер или разработчик будешь автоматом нарасхват по меньшей мере наивно.
Майнинг — это в смысле ценные ископаемые или биткоины?)
Пик пандемии коронавирусной инфекции COVID-19 станет для США вторым Перл-Харбором и вторым 11 сентября. Об этом, как сообщает The New York Times, заявил генеральный хирург США Джером Адамс.
Депрессия это слишком страшно, даже вспоминать не хочется. Уж лучше 11 сентября!
Ладно, IoC — объективно хорошая штука. Но объясните какого черта вы херачите эти репозитории без конца и края? Встраивание их друг в друга, делаете обёртки репозиториев над репозиториями, посыпаете это всё тоннами DTO… но я ни разу не видел, чтобы система на сервисах была хорошо протестирована с моками. Мокать эту вашу тучу репозиториев над репозиториями и тратить на это две рабочих недели...

Хотел бы вступиться за подход с DTO и репозиториями. Не берусь рассуждать о net, ибо не знаком, но буквально на днях закончил двухнедельный рефакторинг, который без заранее созданных репозиториев, DTO и тестов вылился бы во «взять и переписать всё». Очень благодарен тому безымянному программисту, который «херачил эти репозитории без конца и края, посыпал это всё тоннами DTO».

Как итог — увеличение предельных rps в полтора раза. Пресловутый менеджер был доволен.
А зачем рефакторили, если уже было хорошо (по вашим же словам) написано? :)
Вы подменяете тезис. Я не сказал, что было написано хорошо. Я сказал только, что крайне благодарен тому, кто выбрал репозиторий в качестве шаблона.

Если же говорить по существу, то реализация, которую я доделывал была разумным компромиссом между временем на минимально рабочий продукт и пригодностью для изменений в будущем (кстати, именно такой компромисс автор статьи и не смог найти). Изначально сложно было оценить нагрузку и ее распределение по проекту, а спустя два года мы точно знаем, что и как нужно оптимизировать и, более того, мы можем это сделать в достаточно короткий срок.
Поправьте меня, если ошибаюсь в интерпретации ваших слов, но выходит что репозитории — отличный плацдарм для рефакторинга, так? :) Очень запахло job-security driven development и по-прежнему непонятно — а зачем писать так, чтобы закладываться на факт, что придётся переписывать? Разве что вы целенаправленно делаете MVP, цель которого — быть выкинутым. Но в ситуации с MVP обычно архитектурные изящества кончаются гораздо раньше репозиториев.
Вы снова на основании подмененного тезиса делаете удобные для вас выводы.

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

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

Это не рефакторинг а добавление новой фичи. Рефакторинг — это изменение структуры кода без изменения функциональности.

Кэширование с нормальной инвалидацией — это не изменение функциональности. Скорость работы — это не функциональные требования.

Да, мне надо было скопипастить из википедии:


"Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения "

Обычно в книжках по рефакторингу я видел "extract method" а не "introduce cache".

Кэширование с нормальной инвалидацией не затрагивает внешнего поведения.

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


Я не помню, чтобы кто-то из авторов книжек называл рефакторингом введения кеша. Так же стоит учитывать что оно находится в связи со словом factoring — декомпозиция, разбиение на кусочки.


Такое прочтение слова refactoring имеет ценность, так как рекомендуют отделять реструктуризацию кода от значимых изменений.


Возможно в разных прочтениях слова таится не понимание между pnovikov и marvin255 — если это так, то с точки зрения первого необходимость рефакторинга означает плохой факторинг кода, а с точки зрения второго, нет, так как рефакторинг это просто любое изменение кроме изменения связанного с функциональными требованиями. Хорошая декомпозиция (факторинг) на репозитории позволила просто добавить кеш.

Не соглашусь с вами. Новых функций у программы не появилось — она не стала решать на одну задачу от бизнеса больше. Старые тоже остались в полном объеме. Функциональность не поменялась. Даже контракты не поменялись. Так что не вижу противоречий с вашим определением.

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

Репозитории и прочие известные паттерны (примененные к месту), скорее наоборот, идут против job-security driven development, уменьшают порог входа других разработчиков. И да, это нормально писать так, закладываясь, что потом придётся переписывать-дописывать. А "цель — выкинуть" это, скорее про прототип, а не MVP.

Похоже, вы не сталкивались с оверинжениренными проектами. Когда всё строго по паттернам, но на деле такое гвно…

Знаете, по заветам Ильича: «формально правильно, а по существу — издевательство».
Ну это как утверждение «если все программисты будут квалифицированными». То есть редко имеет место в реальности.
Ну то есть чтобы подытожить нашу дискуссию: «шаблоны — хорошо, если применены правильно». А вас случаем не Капитан Очевидность зовут? :)

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

С мнением вроде "Но объясните какого черта вы херачите эти репозитории без конца и края? Встраивание их друг в друга, делаете обёртки репозиториев над репозиториями, посыпаете это всё тоннами DTO для того чтобы просто передать базе данных свой проклятый «SELECT TOP 1 FROM… WHERE Id = 10»" я согласен лишь частично. В части обёртки репозиториев на репозиториями, если речь не о случайном совпадении имён какой-то библиотеки и собственных абстракций.


А так, я из тех, кто по умолчанию делает репозитории при работе с хранилищами данных, инжектит их с помощью IoC/DI-контейнеров в сервисы, которые наружу отдают DTO, которые используются только в контроллерах. И считаю это применением к месте. Будет внутри репозитория прямой вызов SELECT TOP 1 FROM… WHERE Id = 10 или обёртка над репозиторием какойто билиотеки, или над ActiveRecord — деталь реализации, не интересная для пользователей этого CRUD-сервиса. Не всегда получается обходиться без протечки абстракций, но к этому надо стремиться пока овчинка стоит выделки.

Есть три варианта.
1) нужно отрефакторить, но невозможно и все терпят узкое место.
2) нужно отрефакторить и это возможно, отлично.
3) рефакторинг не нужен, т.к. код выкинули.


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

Я не считаю, что иок (по крайней мере в том виде сервислокаторов, как он сделать в популярных языках) это благо. Инверсия зависимостей — нужна, а вот DI контейнеры которые предлагают "решение" вместо ошибки компиляции вывалить "тип не зарегистрирован" или "не найдет конструктор, который принимает (Foo, Bar, Baz, Baz2, FooBar, Blah, BukBuk)". Бррр.

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

Способ конструировать его во время компиляции существует — называется TF энкодинг, и с ним достаточно удобно указывать зависимости. Но без нормальной системы типов (как минимум нужны HKT) удобно не получится.

А тайпскриптовая не потянет? И потом, это же наверное не единственный возможный способ.

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

Очень мощная. И да, там структурная типизация, и интересная система импортов экспортов, благодаря чему можно обходятся без IoC систем, не приколачивая при этом модули гвоздями друг к другу

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

Мощная в выразительности, слабая в реализации. Насчёт второго тейка про рантайм валидацию — у тс структурная типизация, так и должно быть. Но структуры данных, которая хорошо супортит номинативную, не хватает, это да.
Да, так и есть. Поэтому я восхищаюсь тайпскриптом, но избегаю его использования
Я чёт не вижу, как что-то «мощное» по способностям может быть «слабым». Не всегда удобно — да. Выводить типы иногда очень заморочено — тоже да. Но если б все писали только на удобном, ассемблера бы не существовало.

По крайней мере, библиотеки сложных типов к TS люди уже начали делать, так что не везде надо делать всё самому.
Действительно очень не удобно. Для меня самая большая проблема — интелисенс не вывозит на сложных типах. Ну и описание ошибок слишком сложное. Т.е. это круто, когда написал гарантирующий сложный констрейнт на функцию — но пользоваться ей очень тяжело, когда не знаешь, что это за констрейнт
Что-то вы в каждой статье красочно страдаете. Возможно вам лучше книги писать :)
Теперь вместе с arttom я веду подкаст «Мы обречены». Там все как в статьях — максимально напрямую о разработке, индустрии, бабле, собесах. Первый выпуск вот
Но ведь подкаст это в первую очередь звук, т.е.: Apple Podcasts/Google Podcasts/Spotify и т.п.
Будет?
Просто обычный нормальный кризис среднего возраста в своей перезрелой фазе.
Сейчас лучше оставить в покое социопатию и литераторство, философские рассуждения, и написать любым знакомым эйчарам (незнакомым тоже). Потому что они 100% знают, что КСВ длится годами и не факт что заканчивается в +, поэтому прямо сейчас сильно рискуют с таким кандидатом. Нужно смотреть их глазами на ситуацию.
А потом, с успокоенной деньгами семьей, будет время заняться собой.

Часть статьи про то, какой автор известный и его публичные выяснения отношений с HR мне не понравилась.


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


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

Присоеденяюсь, с удовольствием бы посмотрел на «правильную» реализацию crud c точки зрения автора. Казалось бы, автор приверженец мнения, что «Болтовня ничего не стоит. Покажите мне код.» © Однако, болтовня есть, а кода нет.

Посмотрите на статьи автора, первую я еще по неопытности прочитал, вторую половину тоже, ну а дальше фраза "статья от 'короля' разработки" просто заставляет либо прокрутить к комментам, либо закрыть немедленно.

Посмотрите вот этот мой комментарий. Я думаю, он достаточно красочно показывает почему здесь вам никто ничего не станет рассказывать и спорить по техническим вопросам.
Поиск работы и собеседования хороши тем, что они возвращают программиста с небес на землю. Потому что когда устроен, то кажется, что ты знаешь все на свете, на всякие письма от рекрутов смотришь свысока и снисходительно и думаешь, что тебя с руками везде оторвут. А потом внезапно оказывается, что твои знания — это всего лишь крупинка в море того, что знать надо, а все умения и опыт — это частный случай. И надо срочно учиться, если не хочешь вообще остаться за бортом…
Видно, что достиг профессионального потолка, циничен, оттого и приятно читать, воспринимая повествование от первого лица как собственные переживания.
Кризис девальвирует все, и сеньор будет вынужден конкурировать за места мидлов, и при этом улыбаться.
Если senior _конкурирует_ с мидлами, значит это не senior, а мидл. Мастер спорта никогда не конкурирует с первым разрядом — он приходит и выигрывает.
Если судья не в ухо и не в рыло (хрюшечки) в виде спорта, то она судит по тому что доступно её извилинам. Например по знаку гороскопа или по тому насколько кругла крышка люка.

Ну и даже если судья знаком с прыжками в длину на газоне, то он может не всегда адекватно оценить специалиста по прыжкам в сторону или назад на асфальте.
Кажется, в такие заведения лучше и не устраиваться.
Если речь идёт именно о senior'e, то всегда есть крупные организации в которые стабильно нанимают на высокие позиции даже во время карантина. Но у некоторых возникает проблема, что «гадкие эйчары взяли мидла вместо меня» =)
Я провёл немало технических собеседований и нередко люди с претензией на senior позицию не могут даже простые вещи написать. А на senior претендуют потому что «в своей прошлой организации я делал кучу разных дел и был очень полезен».
Сеньоры будут конкурировать не с мидлами, а за позиции мидлов, кризиз приведет к компромисам во многих отраслях. Сеньорские позиции не будут подкреплены доходностью и опустятся до уровня мидл.

Если сравнивать будущие сеньорские и текущие миддл, то не исключено. Но и будущие миддл опустят до текущих джуновских, джуновские до трейни, а трейни, глядишь, ещё и доплачивать буду за право поработать на текущем проекте. Пирамида вся опустится, а не только её верхняя часть.

Кажется, в такие заведения лучше и не устраиваться.


Можно подумать, что организаций станет больше.

Не могу разделить тревоги автора — эйчерары все равно довольно часто пишут или звонят, хотя работу не ищу.

А это ни о чем — они базу резюме набивают на всякий случай чтобы потом, полгода спустя предложить Вам amazing job opportunity.
Никогда не нанимал fullstack разрабов, и не буду нанимать. Людей которые на высоком уровне знают фронт и бек единицы, а те кто при этом успевают следить за рынком еще в 10 раз меньше.

А если как техлидов и т. п.? Я вот слабо представляю как лидить команду из, например, 2 фронтов, 2 бэков, 2 qa и девопса, если не обладать хотя бы миддловыми хардскилами в каждой области.

Техлиды свои на каждом направлении. Лид команды обладает достаточными знаниями как работает web, а не о том как работает angular/react/vue/фрейморк 20ХХ года, этого достаточно чтобы контроллить требования и процесс, а код ревью и архитектуру может делать техлид фронтов, который может быть один на несколько проектов.
а те кто при этом успевают следить за рынком еще в 10 раз меньше.
Чтобы поскорее от вас убежать? Зачем за рынком то следить?

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


Угу, осталось только в этом хрюшу корпоративную с 3 извилинами, ПМС и вахтеризмом головного мозга убедить что баззворды из резюме не обязаны 100% соответствовать баззвордам в тексте вакансии.

Это задача не ваша, а лида/ПМа или кто там ещё дал им вакансию разделить её на "обязательно" и "будет плюсом". Я так иногда в "обязательно" писал вообще только общие слова типа "опыт разработки корпоративных систем", а все "баззворды" в "будет плюсом".

Это задача не ваша


Какая задача — попасть на интервью и получить job offer? От того, что задача формулировать требования к вакансии однозначно интерпретируемым образом является не моей, а хрюшиных коллег, мне ни горячо ни холодно. Но мне приходится преодолевать тот фильтр, который мне навязали.

В чём проблема с fullstack-ами? То, что кандидат не может без google-а как следует сверстать на grid-ах layout? Пффф, тоже мне проблема. В том что человек не может с первого раза воткнуть правильный index в СУБД? Ой бедааа. Покажем, 5 сек, какие проблемы.


Если у человека голова хорошо работает, он достаточно дотошный, у него широкий кругозор, он легко придумывает и реализует нетривиальные неочевидные решения… Ну это ли не сказка? А то, что он там не трогал какой-нибудь React.js последние года 3, потому что переключился на scala Play, так это всё мелочи. За месяц всё вспомнит, что знал, чего не знал, тому научим.

Практически все «обычные» фуллстеки (необычных я тоже видел, но они как единороги по распространенности) могут либо хорошо в бек и плохо во фронт, либо хорошо во фронт, и плохо в бек.

Итого если команда фуллстеков чего-то делает, и так случайно вышло, что они все повернуты в одну сторону (или хотя бы большинство) — они эту сторону делают хорошо, а на другой — полнейшее «тушите свет», и потом надо звать профильных специалистов просто чтоб разгрести.

И дело тут не в лейауте на гридах. А в том, что берутся устаревшие технологии, потому что фуллстеки не особо в тренде (я сейчас и далее про плохой фронт буду, потому что это то, куда я потом прихожу разгребать) — как насчёт фронта на Polymer или Angular1.x, начатого уже после того, как и Polymer и первый ангуляр были не просто застрелены гуглом, но и сняты с техподдержки? Легко!
Берутся плохие практики, потому что фуллстекам некогда сильно глубоко вчитываться в документацию и раздумывать над архитектурой, у них там БД стынет и тому подобные вещи. Итого UI-код выглядит как одна большая куча всего, и даже если фреймворк навязывает компонентный подход — не факт, что это должным образом было принято во внимание. Кнопочка, сама лезущая куда-то делать fetch()? А чё бы и нет! Портянка css, размер которой пошел уже на десятки килобайт, половина содержимого — дубляж, а треть вообще не используется? Мелочи! Сотни случаев копипасты банальных компонент по проекту, потому что организовывать грамотное переиспользование с сохранением необходимой настройки — долго и не хочется? Да запросто! Возьмём альфа-релиз Bootstrap, нафигачим кода, и потом спустя год будем чесать репу, потому что над обновлениями никто не задумывался, в альфа-релизе многого нет, а теперь просто так обновить не выходит, потому что где-то как-то стили наезжают друг на друга и всё разваливается (помним про одну большую портянку стилей без начала и конца)? Не, ну мы ж не знали, что так выйдет!

А уж что там на беке творится, если команда фуллстекеров была в основном сильна во фронте — мне даже и воображать не хочется, кошмары на ночь будут.

При этом я нисколько не против, если фуллстекера нанимают для того, чтоб он 98% времени работал либо на фронте, либо на беке, а свою широту кругозора применял для того, чтоб читать код и быстрее находить общий язык с теми, кто работает на другой стороне. Но обычно нанимают как раз для того, что двух человек нанимать «чёт дорого», наймем-ка одного, который нам сделает свалку из фронта или из бека.
Практически все «обычные» фуллстеки (необычных я тоже видел, но они как единороги по распространенности) могут либо хорошо в бек и плохо во фронт, либо хорошо во фронт, и плохо в бек

Дык в чём проблема? Хотите сильного спеца в конкретной области? Скажем архитектора в области фронтенда — ищите или чистого фронта или фулстека с уклоном во фронт. Хотите бакенд джедая — наоборот. Хотите сразу и там и там джедая? Ну "хотите" дальше.


Более того, всё давно идёт в сторону того, чтобы бакенд был простым, а фронт сложным. Далеко не каждый сервис это high-load. А crud-ы писать сильно много ума не надо. Большинству web-проектов даже транзакции не нужны.


а на другой — полнейшее «тушите свет», и потом надо звать профильных специалистов просто чтоб разгрести.

Ну вот я не считаю, что на backend-части пишу "туши свет". В транзакции умею, в миграции умею, сам dockerfile грамотно напишу, модели нарисую, валидацию прикручу, накрудошлёпю сколько надо. Надо — воткну и graphQL. Будет нужно — полезу в шардирование. При том, что бакенд уже давно почти не трогаю, основной упор во frontend. Сильно выпадаю из вашей статистики? Ну ок, у меня нет опыта анализа производительности SQL-запросов, только читал про это, в деле не применял. Мало опыта в написании сложных SQL портянок с кучей хитрых join-ов и вложенных select-ов. Всё — беда? В утиль?


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

Come on!? О чём мы говорим? На проекте нет вообще ни 1-го чистого опытного frontend-а и туда отправили первого попавшегося фулстека писать архитектуру? Получилось плохо? Ну а что вы хотели. Это ж просто глупо. Если у человека этот skill прокачан слабо, то ему можно доверить архитектуру нового проекта только если проект не важный. Но это не проблема человека. Это проблема конторы которая не умеет распоряжаться своими кадрами. Fullstack как явление тут не причём.

Более того, всё давно идёт в сторону того, чтобы бакенд был простым, а фронт сложным.

Что именно «всё»? Если вы работаете там, где достаточно простого бека — это не значит, что к этому идёт «всё». Далеко не каждый сервис хайлоад, но это не означает, что хайлоад вдруг перестанет быть хайлоадом, потому что на ваш взгляд сейчас «всё» идёт к простоте. А есть еще сферы, где код реально сложный. Машинное зрение не станет проще от того, что «всё идёт в сторону того, чтоб бэкэнд был простым».

Ну вот я не считаю, что на backend-части пишу «туши свет».

И давно вы писали что-то нетривиальное на бэке, что не начинается и не заканчивается на БД и крудах? БД поднять и круды нафигачить и я смогу, да, на какой-нибудь ноде. При том, что я не то, чтоб большой спец в ноде и этом всём — просто это настолько не rocket science, что сильно обломаться человеку с нормальным объемом опыта тут просто негде. От силы протормозить немного, читая гугл. От силы будет немасштабируемо в определенных точках (но это может долго прокатывать, потому что не везде хайлоад, как вы правильно заметили). Но работать как-то будет. Собственно, как и работает фронт у людей, сильных в беке. «Как-то». Потом дело доходит до серьезных изменений, скажем, рестайлинга на фронте и шардирования на беке, и всё встаёт колом, потому что раньше об этом никто не задумывался и не предусмотрел (если вы сможете так сразу в шардирование, чтоб без проблем и переписывания старого — здорово, а вот я например в себе настолько не уверен, впрочем, я на фуллстека и не претендую).

Но это не значит, что задач гораздо большей сложности на беке не существует.

Come on!? О чём мы говорим? На проекте нет вообще ни 1-го чистого опытного frontend-а и туда отправили первого попавшегося фулстека писать архитектуру?

Почему «первого попавшегося»? Он может быть крутым фуллстеком с медалями. Вот только сильным в беке и слабым в фронте. Сильно лучше от этого не будет, код будет более-менее организован, но в частностях скорее всего будет всё плохо.
А чистых спецов в таких ситуациях может и не быть, да, потому что повальный найм фуллстекеров идёт от (часто мнимой) экономии денег.
Если вы работаете там, где достаточно простого бека — это не значит, что к этому идёт «всё»

Не-не, у нас как раз хайлоад. Я туда не суюсь. Только робко любопытствую. Но это не мешает мне признать, что high-load-а очень мало. А вот сложного фронтенда с каждым днём всё больше и больше.


А есть еще сферы, где код реально сложный

У нас как раз сложный код на беке. Scala, FP, high-load и пр. Но это не мешает мне признать, что это большое исключение.


Машинное зрение не станет проще от того, что «всё идёт в сторону того, чтоб бэкэнд был простым».

Это конечно спор терминологии, но я бы не стал относить машинное зрение к backend-у. Эта технология не про server-а. Даже не знаю куда её лучше отнести.


БД поднять и круды нафигачить и я смогу, да, на какой-нибудь ноде.

В подавляющем большинстве проектов больше и не надо. Бинго!


А чистых спецов в таких ситуациях может и не быть, да, потому что повальный найм фуллстекеров идёт от (часто мнимой) экономии денег.

Тут мне сложно спорить. Т.к. на руках статистики нет. Скажу лишь что мой опыт противоположный, в тех конторах где мне недавно доволилось работать, ищут как раз либо backend, либо frontend специалистов.


В любом случае, возвращаясь к сути спора, то что где-то кто-то ставит на позицию архитектора человека, который в это не умеет, нисколько не умаляет того, что опытные fullstack разработчики могут быть очень полезными.


Я бы ещё поспорил о том, что вообще техн. стэк далеко не главное, и можно взять хоть C++-ика, но это пожалуй лучше оставить для будущих холиваров.


Я собеседую регулярно народ. Обычно лет по 7-10 опыта. С трудом решают элементарные задачи и отвечают на элементарные вопросы. Не понимают основ того, на чём пишут. Тут волей не волей начинаешь ценить действительно ценные навыки, а не "писал ли ты на React последние 3 года". Мы вообще про React и пр. сопутствующие вопросы спрашиваем уже в самом конце.

Это конечно спор терминологии, но я бы не стал относить машинное зрение к backend-у. Эта технология не про server-а. Даже не знаю куда её лучше отнести.

Тут можно спорить, но всё, что не является непосредственно взаимодействующим с пользователем кодом — это «бек». Понятно, что ML и прочий датасотонизм — это штука, достойная своей собственной категории, но всё равно это всё бек: этому тоже надо скармливать вполне себе обычные причёсанные данные из всяких баз и прочего.

В любом случае, возвращаясь к сути спора, то что где-то кто-то ставит на позицию архитектора человека, который в это не умеет, нисколько не умаляет того, что опытные fullstack разработчики могут быть очень полезными.

Ну я с этим и не спорил. Я спорил с тем, что фуллстеков можно прям так брать и писать их руками весь проект, с этим часто случаются проблемы. А что они полезные — конечно полезные.

Тут волей не волей начинаешь ценить действительно ценные навыки, а не «писал ли ты на React последние 3 года». Мы вообще про React и пр. сопутствующие вопросы спрашиваем уже в самом конце.

Это здорово. Но где-то добрая треть контор (а может и больше, может мне просто неадекват удаётся раньше отсекать) всё равно с кандидатами беседует в ключе «у нас сложно, нам надо чтоб 3 года опыта на реакте, и ни днем меньше». Архитектура? Оптимизация рендера и презентации? Компонентная организация? Не, это всё фигня — главное чтоб на реакте много фигачил и хуки смог на техсобеседовании изобразить.
Хорошо, если вы пишете это в описании вакансий. что бы люди не тратили время, сражаясь с вашими стереотипами

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


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

Госструктуры тоже будут вполне себе и те кто раньше нос воротил, с удовольствием вольётся в ряды бюрократов, чтобы пересидеть смутные времена. Надо только поторопиться, а то скоро не пробиться будет.

В этом "удовольствии" будет очень уж много чувства облегчения, что не остался на улице, такое себе удовольствие.
Но наверное можно себе позволить немного посидеть и на скучном месте, когда вокруг кровь льется.

Вопрос скоре не в том, чтобы «посидеть в скучном месте», а в том, чтобы не деградировать там и не потерять привлекательность на рынке труда, когда он воскреснет. А в таких местах работа — это не о развитии, это бери больше, кидай дальше.
Ну ты зря так про шаблоны. Да, они — не панацея, но помни, что твой «умный код» рано или поздно станет легаси)
Legacy кстати может отлично стать и любой «шаблонный на сегодня» код. Причем поддерживать его может быть даже труднее, т.к. документация к используемым фреймворкам или библиотекам может просто в будущем оказаться недоступной. Сама же Microsoft этим часто грешит в отношении своих разработок. Так что здесь нет какого-то универсального подхода.
А может пора свою компания запилить, с «Пасьянсом и секретаршами»?

Даст ему заказчик задание сделать простой круд в 3,5 таблицы, а автор уйдёт в рекурсию по построению гениальных архитектур, а то и в запой от творческого кризиса. Все сроки провалит.

Написано хорошо.
Количество неологизмов зашкаливает, если код такой же то это мрак.

Что касается тестового задания:
  1. Это чисто русский подход, сломать и построить заново
  2. Я знаю как лучше. Вопрос: для кого лучше? Для Вас?
  3. Хочу посмотреть на того парня кто будет работать с этим «лучше» после Вас. (Подсказка: сломать и построить заново, я знаю как лучше


Удачи
Я знаю как лучше. Вопрос: для кого лучше? Для Вас?


Конечно для меня. Я же тестовое делаю, что бы показать, какой я разработчик
Опубликуйте репозиторий где делается это тестовое. Это решит большинство проблем в обсуждение ваших способностей как программиста.
Не буду, оно мне не нравится. Но на днях закончу статью про подходы в сишарпе, и уже к ней я код опубликую.
Можно опубликовать с ремарками, что, где и почему не нравится. Будет даже интереснее.
Я кстати подумывал отправить тестовое работодателю с ремарками. Ну что бы и за идиота не приняли, и сделать можно было бы как мне хочется. Но я этого не сделал, потому что в итоге хорошее решение у меня так и не получилось, и мне пришлось бы писать ремарки в стиле «я продублировал валидацию, потому что я тупой, и не придумал, как этого избежать»
> Я быстро понял, что с таким подходом я никогда не доделаю тестовое.

Очень знакомо, тоже как-то прошлепал сроки ТЗ, когда решил сделать его в соответствии с лучшими практиками. Постепенно из простого веб-приложения вырастал какой-то монстр, который при своих чрезмерно больших объемах был крайне хрупок и неуклюж: добавил новое свойство — не забудь поддержать его на всех уровнях абстракций, тем паче если для Entity наделано несколько вариантов его отображения/редактирования, не забудь про все DTO и ViewModel-ы, добавь во все автомапперы, валидацию и там и сям — любое незначительное изменение сопровождается его поддержкой на всех уровнях, в процессе которой фокус внимания тонет в деталях реализации.

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

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

Ваша проблема в том, что вы применяете не те паттерн, не там, где надо. Иначе такой проблемы бы не возникало

вы применяете не те паттерн, не там, где надо


Отчего же не те? Вполне себе те, если за главную ценность проекта держать job security driven development.
Написано хорошо для программистов, но не для тим-лидов и HR.

Правильное решение любого HR или тим-лида, который собеседует такого нереализованного страдальца — это отказ. Ибо он со своим «уникальным» подходом и проект попортит и ребятам мораль уронит.

Не переживайте так. Если в РФ начнется тоже самое, что сейчас происходит на Украине, то очень быстро под нож пойдут некомпетентные и «тяжелые». Так что это ваш личный выбор — остаться на работе или пойти на мороз.

То же самое хотел сказать про отказ. Неясно, какой он программист (хотя "король разработки" в профиле как бы намекает ;-)), а что людям с ним работать будет тяжело – заметно сразу.

Если в РФ начнется тоже самое, что сейчас происходит на Украине, то очень быстро под нож пойдут некомпетентные и «тяжелые».
Раскажите что на Украине происходит, а то звучит уж очень нуарно.

Ну а «король разработки» в профиле это стёб/самоирония/троллинг (как мне кажется).
Взрослый бородатый дядя, а ноешь как баба, уж прости. То, что тебя уволили перед новым годом это чьи проблемы? Тем более мы не знаем как было это увольнение, может ты ничего не делал и грубил начальнику и отказывался делать качественно свою работу. Или ты крутой и скилловый быстро и качественно делал задачи, а злой начальник решил такого крутого работника уволить ради лулзов? Такие быстрые и внезапные увольнения бывают за серьезные косяки или если давно уже достал всех.

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

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

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

Как с английским? Ты уже удаленный кажется. Бомбардируй удаленных западных коллег, просись к ним. Если английский плохой — тоже вопрос — почему раньше не качал его, когда работал.

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

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

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

Да большинство в таких было, но на хабр никто не бежал

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

Вам надо к психологу походить.

Если вы не вводите нас в заблуждение относительно вашего профессионального уровня, то вам необходимо брать на себя задачи сильно круче, чем тимлидство или просто разработка всякой фигни. Например, лидство в отделе с 20-40 разработчиками, а то и свой бизнес на какой-нибудь трудном рынке.
Да будет вам известно, что подобные должности и такую ответственность людям с порога не отдают. А то тут половина хабра бы уже техдирами была. А на свой бизнес нужен вообще-то стартовый капитал, что не так просто когда у тебя семья с детьми, которых кормить надо вотпрямщас и богатых родственников не предвидится.

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

Не дают — возьми сам. Качественно новый уровень ответственности тем и отличается от традиционной корпоративной безответственности.

нужен вообще-то стартовый капитал

Множество компаний практикуют «внутренний стартапинг». Это когда тебе все дают, лишь бы деньги приносил.

Да и автор, судя по тектсу, не дурак, стартовый капитал имеет. Чтобы сделать MVP нужно два спринта, а два спринта — относительно не дорого. И даже после первого спринта все равно есть что показать. И даже до всяких спринтов ведь как-то удалось зажечь команду идеей.
Два спринта? Мы с друзьями пол года не можем MVP сделать — всё время передумываем, переделываем и т.д.
Верхнего предела нет, конечно. Два спринта — это минимальный объем, после которого понятно стоит продолжать или нет.

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

пол года не можем MVP сделать

Ну, надо разбираться. То ли он у вас не Minimal, то ли не Viable. И правильно ли вы понимаете «сделать». Если вы пока не готовы сделать релиз — это одно и не страшно. Но если у вас продукта не появилось — это другое.
Может быть слишком умный не в значении умный, а в значении слишком дохрена думающий. Я точно недостаточно хорош, что бы договорится с собой, что я делаю ровно вот это, без малейших изменений, за две недели. Всё перерешается на следующий же день.
что бы договорится с собой

Надо не с собой договариваться, а брать на себя обязательства перед другими людьми.

без малейших изменений

В плане реализации, или в смысле что фичи перепридумываете? Если реализацию — это даже хорошо. До тех пор, пока вы все-таки делаете коммит с работающей задачей и остается время его протестировать и поправить замечания. А если фичу перепридумываете — единственная причина — она у вас не достаточно провалидирована. Фичи берутся не из головы, а подтверждаются рынком. Метода называется «оторви жопу от стула и поговори с клиентом». Прежде, чем взять фичу в разработку, вы должны быть в ней достаточно уверены. И вот если вы знаете, что фича кому-то нужна и за нее готовы заплатит и все равно ее не делаете — у вас проблема.
Надо не с собой договариваться, а брать на себя обязательства перед другими людьми.


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

Поэтому мы постоянно придумываем новые фичи, и выбрасываем старые
Ну, понятно. Заняли свое время очередной развлекаловкой. Поэтому, я и говорю, что вам надо больше ответственности брать — вам так всегда и будет скучно.

Нет, конечно. Есть метода, по ней все делается. Смысл в том, что вы вначале находите клиента, а уже для этого клиента делаете. Формулы там будут, конечно, но они очень простые. Там целая пирамида валидации. Вначале вы валидируете идею в разговоре с коллегами, потом выходите на потенциальных клиентов, с ними два вида интервью: проблемное и глубинное, и только потом уже валидация гипотезы масштабирования — идете в сеть или обзваниваете массу людей. В этом деле всякие там корреляции, критерии стьюдента не принципиальны — и так все понятно. Если вам несколько человек говорят одно и то же и готовы платить за решение проблемы, значит ее стоит попробовать решить.
У нас комьюнити-ориентированный проект, нет и быть не может никаких клиентов. Потенциальные пользователи — этом мы сами, и такие же как мы
А со сколькими из них вы говорили? Какая у них проблема? Сколько они готовы заплатить денег за ее решение?
Я понимаю ваше желание поучить меня управлять продуктом, но я разработчик, мне интересно разрабатывать

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

К психологу!

Выглядит так, что проще запилить прототип, найти инвесторов, запилить MVP, зарелизиться и дать реальному рінку провалидировать гипотезу.

Ну, надо разбираться. То ли он у вас не Minimal, то ли не Viable.

За две недели сделать Minimal Viable Core Bank System (АБС) разве реально?

За две недели сделать Minimal Viable Core Bank System (АБС) разве реально?

Не знаю, может и реально. Зависит от много всего.

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

"Нашему" клиенту нужна система для ведения банковских счетов всех видов, удовлетворяющая требованиям, если говорить про Россию, ЦБ РФ. Если умеет считать всё правильно, слать отчёты в ЦБ РФ, участвовать в платежных системах, межбанковских операциях, клирингах и прочем (уже довольно давно в этой системе не вращаюсь, что-то мог обязательное опустить), предоставляет API для интеграций с CRM, пользовательскими приложениями и т. п. — это Viable, чего-то одного нет — not Viable

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

Сильно сомневаюсь. Смотрите, как это работает. Продукт делается не просто так, а ради того, чтобы проверить какую-то гипотезу. Minimal Viable — это не имеется в виду, что он готов деньги заколачивать, а что его можно кому-то показать потрогать и получить фидбек, достаточный для опровержения этой ключевой гипотезы.
Для того, чтобы показать клиенту и получить фидбек не обязательно соблюдать требования всех регуляторов. В релиз, конечно, с таким не уйти, но цель MVP — не улететь в бой, а проверить ключевую гипотезу.

Какая ключевая гипотеза вашего продукта?

У нас разные понимания MVP, продукт для "показать потрогать и получить фидбек" в моём мире называется прототип. С ним, прежде всего, бегаешь по потенциальным пользователям/клиентам/спонсорам/инвесторам, проверяешь нужно ли вообще что-то подобное хоть кому-то.


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


Ключевая гипотеза была "малые банки готовы платить меньше за более качественное ядро всех своих систем". К сожалению, с прототипом её проверить не получилось, а на MVP ресурсов не нашлось. Как оказалось постфактум, оно и к лучшему было: через относительно короткое время ЦБ РФ начал чистку банковской системы. И даже стали понятны некоторые намёки со стороны малых банков, почему их не интересует длительный горизонт планирования.

У нас разные понимания MVP, продукт для «показать потрогать и получить фидбек» в моём мире называется прототип.

Да. В каком-то смысле, MVP — это прототип для бизнес-идеи.

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

Что-то вы не по тем бегаете. По-идее, если вы сделали MVP и подтвердили ценность, то все инвесторы будут рады вам дать денег — новые работающие идеи большая редкость. А если опровергли, значит расслабьтесь — это не нужно. Начинайте придумывать новую идею.

малые банки готовы платить меньше за более качественное ядро всех своих систем

Какие именно качества ядра проверялись?
Вы сами когда-нибудь занимались непосредственно тем, о чём говорите?
Нет. Реквизировали ли вы когда-нибудь рычаги управления в команде? Или убеждали начальство выделить бюджет или людей под какую-нибудь свою идею?
Потому что вы не адекватны.

«Он адекватный» == «Он такой же, как я. Я всегда могу предсказать, что он сделает, подумает и скажет»

Нет уж, извините
К психологу! Срочно к психологу!

«Он адекватный» == «Он действует исходя из объективных факторов и не додумывает ничего сам» == «Я ему доверяю, потому что он справедлив и рассудит по-существу».
«объективных» => «объективных для меня, ведь я-то точно адекватный»

«Я ему доверяю, потому что он справедлив и рассудит по-существу» => «Я ему доверяю, потому что он справедлив и рассудит по-существу с моей точки зрения, потому что только я знаю, какое существо адекватное».

Ну и кому тут надо к психологу по вопросу завышенного самомнения?
Честно говоря, забавно такое читать сейчас, когда всего еще месяц назад любые паникерские комментарии на хабре задавливали кучей ответов в стиле «мыбогомпомазанныеайтишникибезнасмиростановится, так что нечего паниковать, это обычныелюдишки боятся должны!». Сейчас заглянул в линкедин — куча народу резко остались без работы и ищут ее. Причем среди них и HRы и мидлы…

Я просто напомню то, что Фил писал в прошлом году:


Когда меня нанимают, то покупают мою способность проходить собеседования, потому что мой работодатель уже на следующий день будет продавать меня корпорациям. Важный аутстафный скилл — я очень хорошо умею быть тем человеком, который нужен команде. Им нужен парень, который на каждый чих рассылает десятки имейлов с вопросами? Базару ноль, будут вам имейлы. Нужен агрессивный кодревьювер? Подержите мое пиво. Команда нуждается во внимательном менторе? Присаживайтесь поудобнее, я вам сейчас все расскажу за дотнет и системы типов. Нужно делать фичи в бешенном темпе? Я машина, которая будет фигачить код днем и ночью, пока аджайловый график фич не придет в нужное состояние. Делать все то же самое в продуктовой фирме я не могу. Мои проектные личности живут очень недолго, и уже через три месяца мозг требует перемен. Я начинаю выгорать и писать слезливые статьи.
К сожалению я не чувствую себя достаточно скилловым, чтобы писать статьи, поэтому в основном потребляю то, что пишут другие люди. И очень благодарен этим людям.

Соответственно и к вам обращаюсь с призывом написать несколько крепких технических статей, которые более детально отражали бы то, что в ваших статьях обычно называется чем то типа «правильного подхода».

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

Технические:
VDOM — 8 плюсов/7.5к просмотров
SQL в EF — 22 плюса/12.6к просмотров.

(намеренно не упоминаю статьи про свой фреймворк)

Развлекательные:
Сатира про JavaScript — 84 плюса/48.5к просмотров.
Типажи программистов — 216 плюсов/167к просмотров.

Разница, как вы можете видеть, РОВНО НА ПОРЯДОК. Ещё есть вопросы почему люди не пишут технические статьи?
Тут бы ещё не помешало вспомнить, сколько времени было потрачено на эти статьи
поверьте — ничего не меняется в мире, по крайней мере с людьми… Абстрактным мышлением обладает очень и очень небольшой процент людей, системным мышлением еще меньше, что уж говорить про их комбинацию. А без этого ты погромист, а не программист… Началась фаза перехода к новому миру, а там нету таких профессий, как фулстек и т.д. — опа придет ко всем, не надо волноваться. Новые профессии очень сложны, но кто может — нужно их осваивать…
Перфекционизм (вне разумных пределов) это болезнь и об этом нужно помнить.
Еще помни, что всех денег не заработать и к зарплатным ожиданиям нужно подходить осторожно (даже если работодатель прямо таки кидает в тебя пачки денег).
Как там про студента, который решил подготовиться к экзамену максимально возможным образом. Утром вырываясь из рук санитаров, он кричал что зовут его «лямбда Пи».
Если тебя не приперли к стенке кредиторы, то найди себе хобби (только не деструктивное), отправь всех говорящих про успех в жизни в далекое эротическое путешествие.
И еще обязательно каждые 3-5 лет меняй работу, вот прям так: Добил проект, получил премию и написал заявление об уходе (и прямо завтра дома сидишь — пока финансы или здоровье не закончатся).

Если есть возможность, то я иногда для таких тестовых делаю два, а то и три варианта:


  • решение в лоб
  • решение по "лучшим практикам"
  • архитектурный оверинженеринг
А не жирно ли ради пары-тройки тысяч долларов в месяц?

Вариант «жрать захочешь — сделаешь» не рассматриваем, ибо на эту тему уже вся статья.

Может ради пяти :) Ну и для меня в таких вопросах не деньги главное, а интерес. Есть интерес (не важно откуда) — делаю два-три варианта, нет — так и одного не делаю.

Крайней редко. Когда время тестового ограничено, а задача оказывается сложнее чем предполагалось. Ну или просто завтыкал на какой-то мелочи.

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

Ну уж какой есть. Не знаю насчёт выучить, но я применял F# в коммерческой разработке

По поводу HR я разделяю мнение автора. Я работаю на пару компаний через другие фирмы. И ради интереса, подал резюме в те компании, на которые работаю. Сюрприз… Я не прошёл собеседование. Но они с радостью платят деньги за мои работы тем фирмам.

В данный момент тоже нахожусь в поисках (уволился в феврале, ~10 марта открыл резюме).
Подобных проблем нет. За это время пришло куча предложений пообщаться, порядка 20-30. Интересных для меня из них штук 5-10 было. Собеседования прохожу вяло (в плане частоты). Получил 2 оффера и 1 отказ пока. Имеются в запасе еще пара собесов забитых. В принципе все как и год назад. Не заметил каких то проблем с кол-вом вакансий… а вот с фактическим устройством — да) Один оффер очень заинтересовал, вроде пошло дело. Но изза карантина «сори парень, физически не можем сейчас устроить, давай пообщаемся после карантина если ты не найдешь до этого работу».

ЗЫ Бэкенд, 2,5 года опыта.
Тут или синдром звезды, или оверскиллед, с этим всегда сложно.
Простых пахарей кода как искали, так и сейчас ищут, звездам сложно, да, на 20 пахарей нужны одна звезда.
Так же возможны завышенные финансовые ожидания, которые тоже сужают возможности поиска.
Определенно что-то не так с входными данными. Как шарпист, который не так давно сменил работу, могу сказать что таких проблем как у автора у меня не было от слова совсем. И кризис точно не помеха так как мне даже сейчас на почту приходят предложения от разных компаний.
Тогда пишите код который предсказывает будущие данные и графики.
И зарабатывайте миллиарды, зная ТОЧНО БУДУЩЕЕ
У меня есть такой код. Если нужно, дам бесплатно. Пишите.

image

vk.com/id526958216
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.