Как Лена в 29 лет бросила успешную карьеру в финансах и решила «вкатиться в айти»
Как всем известно, айтишники без труда зарабатывают $300кк в наносекунду, а также способны молниеносно релоцироваться в любую точку планеты, просто моргнув левым глазом. В этой статье мы разбираемся, насколько легко стать айтишником с нуля, а также чему вас научат (и научат ли) на распиаренных программистских курсах.
Так, меня, если что, зовут Пашей! На заре своей карьеры я более семи лет проработал аудитором в одной из так называемых компаний «Большой четверки». Как бы вас ни пытались убедить в обратном рекрутеры, большинство работающих там аудиторов мечтают оттуда уволиться и найти себя в чем-нибудь более интересном и доходном. (Я, кстати, был исключением – для моей занудной натуры было как раз норм копаться во всяких эксельках с циферками. Да и героиня этой статьи не сильно страдала.)
В итоге я продолжил свою карьеру в управленческом консалтинге и потом в инвестициях, – а несколько моих друзей смогли успешно перекатиться теми или иными путями в IT (дата-сатанизм, кодинг, мобильная разработка – вот это всё).
Я подумал, что в нынешние времена структурных изменений в российской экономике (если вы понимаете, о чем я) этот опыт может оказаться интересным и полезным для многих людей – так что я попросил одну из таких бывших коллег, Лену, написать про свою историю. Не ожидайте тут каких-то диких инсайтов и открытия Америк – нет, это просто рассказ одной конкретной истории карьерного пивота в IT из совсем не связанной сферы.
Лена не захотела самолично выгребать килотонны хейта из комментов (я в вас верю, не подведите!), так что я ее немного анонимизировал (наши общие друзья, конечно, догадаются, о ком речь – но это ок).
Также я везде вырезал название известной онлайн-школы, в которой героиня статьи постигала азы программистской профессии, потому что они мне не заплатили за рекламу. (Это, конечно, намек для компании: занесите мне чемодан денег – и я с радостью вас прорекламирую!!)
Прелюдия
Желание заниматься программированием появилось у меня ещё в младших классах школы: на уроках информатики мы изучали язык программирования для начинающих – Logo Writer (тот, где черепашка бегает по полю и рисует пером), мне тогда весь этот процесс показался жутко интересным.
Мне было интересно, как работает компьютер изнутри, но не в части «железа», а именно в плане ПО. Помню, что когда у меня только появился личный компьютер, я зашла в каждую папочку на диске, чтобы посмотреть что там лежит – открывала файлы и логи программ.
Позже я самостоятельно стала изучать html и в 10 классе школы преподаватель по информатике предложила мне сделать электронную версию учебника для младших классов по этому языку в виде локальных веб-страничек с уроками и заданиями к ним. Первое время я работала над учебником одна, а потом ко мне присоединилась моя одноклассница. Вместе мы даже участвовали с этим проектом на всероссийской конференции, на которой заняли третье место.
У меня тогда было желание пойти учиться в университет на программиста, но в силу ряда факторов (в том числе – сомнений в себе и своих способностях), выбор в итоге пал на специальность экономиста.
Завязка
В годы учебы в университете и дальнейшего трудоустройства по специальности жажда программирования периодически просыпалась во мне… В один из таких моментов у меня даже появились книги по С и С++, которые я выменяла у кого-то по объявлению, а потом не решалась с ними расстаться – хотя и не занималась по ним. Мне тогда почему-то казалось, что это всё очень сложно: чтобы работать программистом, нужно окончить университет по специальности и обязательно хорошо знать физику (?!).
На тот момент я работала в сфере финансов уже 5 лет – начинала аудитором в «Большой четверке», а потом ушла в индустрию составлять корпоративную отчетность. Характер работы, в целом, мне нравился; мою работу отмечали коллеги и начальство, я достаточно быстро росла в доходах и должностных обязанностях. [Павел: Подтверждаю, Лена была одной из самых толковых сотрудниц, с кем мне довелось поработать в аудите.]
Но стрессовые условия составления отчетности, ненормированный график в отчетные периоды и отсутствие гибкости не приносили радости. Также было ощущение, что эта работа не давала мне раскрыть свой полный потенциал: было мало каких-то задачек, над которыми интересно было бы поломать голову.
Первые зерна сомнения (или надежды?) в отношении программирования посадил во мне один из коллег-стажеров – он как раз заканчивал университет по специальности программиста и стажировался на разработчика известной бухгалтерской системы. С его слов оказалось, что физику знать совсем не обязательно, да и какая-то сложная математика нужна далеко не всем. Этот разговор дал мне пищу для размышлений.
В это же время я несколько раз натыкалась на рекламу [вырезано цензурой], посмотрела их сайт и программы обучения программированию: всё было так заманчиво и казалось не таким и сложным – всего год обучения на онлайн-курсах, и вот ты уже можешь устроиться полноценным специалистом на такую же зарплату, как после нескольких лет в сфере финансов.
Было сложно принять решение о смене профессии, так как было очень жаль потраченных усилий на предыдущий карьерный путь, в том числе на 13 сданных экзаменов на сертификат члена ACCA (международная ассоциация бухгалтеров). Ну и вообще, было страшно заново начинать с нуля свою карьеру, когда тебе уже не 20 лет.
Я долго размышляла, но я всё-таки скорее сторонник подхода «сделать и жалеть», чем наоборот – да и обучение само по себе ни к чему не обязывало, так как с работы я решила не увольняться, пока не будет какой-то определенности с новой сферой. А еще я подумала о том, что чем позже начинаешь, тем сложнее будет переквалифицироваться – так что я приняла решение начать обучение iOS-разработке.
Молодой человек меня в этом решении поддержал. Коллегам я, конечно, ничего рассказывать не стала, да и в целом старалась говорить только самому близкому кругу – не хотелось порождать лишние вопросы и какие-то чужие ожидания, ну и было страшно, что ничего не получится. Но в целом, все, кто знал, были приятно удивлены и поддержали меня.
Процесс обучения
Обучение состояло из нескольких курсов, разбитых по четвертям. Почти все курсы шли в формате двух онлайн-лекций в неделю, после каждой из которых необходимо было выполнить практическое домашнее задание в определенный срок, чтобы в дальнейшем (уже после окончания обучения) иметь право на помощь [онлайн-школы] в трудоустройстве.
Эту возможность мне терять не хотелось, и это стало главным испытанием для меня – совмещать обучение и сдачу в срок домашних заданий с моим ненормированным рабочим графиком и авральными периодами «закрытий» бухгалтерской отчетности.
Часто было мало сна, поначалу было очень сложно что-то понять и уложить в голове, хоть у меня и было представление о базовых концепциях программирования (переменных, функциях). Не представляю, как чувствовали себя те, для кого это было в новинку. Помню, как в самом начале обучения сидела 3 дня над одной из несложных задач по верстке интерфейса и раз за разом придумывала и пробовала различные варианты.
По ходу обучения студентов, посещающих вебинары и сдающих домашние задания на курсах, оставалось всё меньше – кто-то бросал обучение, кто-то за неуспеваемость шел на повторное прохождение курса. Время обучения тоже растянулось – вместо года получилось полтора из-за небольших перерывов между курсами, а также из-за нетипичной длительности некоторых курсов.
Преподаватели были разные (как и везде, наверное). Кто-то просто «отчитывал» свой курс и с трудом отвечал на вопросы – но нам повезло, и такие преподаватели встречались, в основном, на дополнительных курсах. А курсы, закладывающие основу профессии, у нас вел толковый специалист с релевантным опытом и способностями к преподаванию.
После каждого курса у нас получалось небольшое приложение в портфолио, на котором можно было продемонстрировать знание различных технологий. В конце обучения предполагался большой командный проект. С ним вышло не очень: за полтора года многие люди просто «потерялись», а те, кто остался, по большей части, были не очень заряжены на работу. Я присоединилась к одной из команд, у нас была идея и некоторый план (которого мы придерживались) – но по факту получилось, что свою часть cделала только я, командной работы не вышло.
В целом про обучение: на мой взгляд тот, кто действительно хочет научиться, сможет взять для себя необходимые знания. Информации давалось более, чем достаточно; уделялось внимание самым разным темам и технологиям. Кстати, как я потом узнала, Swift – не самый простой язык для знакомства с разработкой.
Вообще, изучение программирования, даже на курсах, требует достаточно много самостоятельного поиска информации (этот навык потом пригодится и в настоящей работе) – это не тот предмет, где можно просто присутствовать на занятии и внимательно слушать преподавателя, нужно быть готовым учиться самостоятельно.
Трудноустройство
По иронии судьбы, мое обучение закончилось в марте 2020-го, и тогда же я начала искать работу. За несколько недель с начала локдауна вакансий стало ощутимо меньше, так как все жили в состоянии неопределенности.
Свое резюме я составила по рекомендациям [онлайн-школы] и откликалась на вакансии отовсюду: hh, Хабр.Карьера, вакансии на сайтах самих компаний, и даже в Телеграм-каналах. Помощь в трудоустройстве от [онлайн-школы] заключалась в том, что их hr-специалист посмотрел мое резюме и дал дополнительные несущественные рекомендации, а также раз в неделю присылал мне подборку вакансий и спрашивал, как идут дела. Поскольку вакансии мы, вероятно, искали в одних и тех же местах, то большая часть моих ответов выглядела примерно так: «уже отправила резюме», «тут нужен старший специалист», «уже отправила резюме», «ответили отказом».
Я была не готова существенно терять в зарплате и обозначила для себя минимальную сумму, на которую ориентировалась при поиске работы. Вероятно, не будь у меня такого требования, работу получилось бы найти быстрее.
В апреле-мае я прошла несколько собеседований, что помогло мне выявить мои слабые стороны, подтянуть знания и лучше узнать язык. Я даже получила первый оффер – но, поскольку он отличался в два раза от моей ожидаемой зарплаты в меньшую сторону, не приняла его.
Дальше начался период отпусков и затишья, были какие-то редкие собеседования и тестовые задания, по некоторым из которых нанимающая сторона даже не утруждалась давать обратную связь после просьбы. Я снова почувствовала себя внутри «дилеммы выпускника»: для устройства на работу нужен опыт работы, чтобы получить опыт – нужно устроиться на работу. Я постоянно мониторила вакансии во всех известных источниках, но новых было мало, надежда на смену сферы деятельности понемногу таяла. Новый всплеск вакансий предполагался осенью, нужно было подождать.
В процессе собеседований я пару раз сталкивалась с предвзятостью в отношении пройденных мной онлайн-курсов: в открытую говорили, что для меня сделали исключение, а обычно выпускников [онлайн-школы] вообще не рассматривают – поскольку, в основном, на собеседования приходят «слишком самоуверенные люди, у которых в голове пусто». Но надо отметить, что личные вопросы про то, замужем ли я и собираюсь ли в декрет, мне не задали ни в одной компании (думаю, многие девушки знакомы с такими вопросами).
В начале осени 2020-го мне неожиданно поступил звонок от рекрутера частного университета: она предложила в ближайший час провести небольшое телефонное собеседование с их главным разработчиком. Мне пришлось общаться и отвечать на вопросы по разработке, стоя на улице, так как я в этот момент была на работе.
После нескольких телефонных переговоров я получила оффер на желаемую мной сумму (это оказалась как раз та сумма, которую указывала [онлайн-школа] в своей рекламе как будущую зарплату).
Предполагалось, что я займу вакансию младшего разработчика, а вместе со мной наймут старшего разработчика (моего наставника). В день выхода на новую работу я узнала, что старший разработчик в последний момент отказался от оффера и поэтому мой тоже хотели отменить… но, на мою удачу, не стали – им был очень нужен iOS-разработчик, поскольку оба работавших до этого уволились за короткий промежуток времени. Так я осталась без наставника – снова прокачивать навык самостоятельного обучения и поиска информации.
Эпилог
Сейчас я продолжаю развиваться в области разработки – спустя полтора года работы чувствую себя уже гораздо более уверенно и примерно понимаю области дальнейшего развития, а также что мне нравится и что не нравится делать (когда только начинала, такие вопросы на собеседованиях вызывали ступор).
В целом, работа в этой сфере для меня пока гораздо интереснее – в ней больше интересных и трудных, но развивающих задач (примерно как я себе и представляла во время обучения). Переход дался, конечно, тяжеловато, но я рада, что я это сделала и всё позади.
Когда я только начинала, то недооценила необходимое количество времени и сил – казалось, что будет проще. Потеря в доходах далась тоже непросто: при переходе я потеряла около 30% своей зарплаты – по сути, откатилась на четыре года назад, если считать по меркам моей карьеры в финансах. Но уже спустя полтора года работы на новой специальности я смогла отыграть всё назад и практически достигла того уровня зарплаты, с которого я уходила из финансов.
Если вы думаете о переходе в разработку «с нуля», будьте готовы по-настоящему вкладываться, полностью погружаться и посвящать этому много свободного времени – то есть, в прямом смысле, «пахать». Нужно много практики, ее можно нарабатывать только вложенным временем. Но есть и плюс – дальше будет проще, и усилия окупятся. После изучения одного языка общие концепции усваиваются, и другие языки даются проще.
Если сложно определиться с направлением и языком – можно сходить на бесплатные интенсивы по разным языкам, во многих онлайн-школах их проводят. Так можно узнать общие сведения о языке, что на нем пишут, его востребованность и популярность. После таких интенсивов иногда дают домашнее задание, на котором можно попробовать свои силы и подумать, хочется ли этим заниматься дальше.
Также, если есть возможность, как можно быстрее найдите себе ментора. У меня его не было, и сейчас я понимаю, что так было бы проще – если бы кто-то опытный со стороны мог оценить твои навыки, подсказать какие темы нужно подтянуть, подготовить к собеседованиям.
Ну и в целом, нужно быть открытым новому, быть готовым всё время чему-то учиться и не бояться начинать с нуля, на какой бы позиции вы до этого не работали. И подготовьте себе финансовую подушку!
[Павел: Спасибо всем, кто дочитал! Если у вас есть своя история перекатывания в IT из какой-то другой области, поделитесь ей в комментариях – уверен, для кого-то это окажется полезным. Лену только не обижайте плз. =)
Если статья показалась вам интересной, то буду благодарен за подписку на мой ТГ-канал RationalAnswer. Вообще, я там обычно пишу про разумные подходы к личным финансам и инвестициям, но про карьеру тоже иногда бывает – как вот сейчас.]
Программистишкой стать не так просто. Если есть способности к логике и мат анализу - нет проблем. Если их нет, а хочется модную профу и много денежек - то это мучение и разбитые мечты. Не все могут стать программистами, к сожалению. Тем более, погромист - это сидение на жопе по 10 часов в день с глазами в экране и постоянное самообучение программингу - для этого нужен особый мозг. Поэтому и платят хорошо, потому что не каждый сможет программировать и оперировать виртуальными объектами качественно, а один из 10000.
Первое, что нужно перед всякими курсами - понять, есть ли способности к логике и алгоритмам. Если нет, то в итоге такой онанизм с неприспособленным к профессии мозгом приведет к депрессии и крушению розовых мечт.
Еще страшный и укусить может..
Комментарий недоступен
Алгоритмы нужны на собеседовании чтобы собеседующий самоутвердился и смог понизить планку ЗП. А потом на рабочем месте нужно будет красить кнопки или перекладывать джонов
Было бы не так смешно, если бы не было правдой :)
Это не правда, алгоритмы - одни из ключевых знаний для профессии.
Умение вбивать код это примерно как для хирурга умение зашивать - т.е конечно надо и обязательно, но мягко говоря не самое важное.
Я не отрицаю нужность алгоритмов и прочего. Это тоже часть работы. Но и "перекладывание джонов" имеет место быть.
Про алгоритмы тоже отдельная история. Как часто используется именно написание алгоритма (с нуля) сортировка массива, например? Все равно же используются методы, которые реализованы уже для более простого использования.
Посмеялся просто с формулировки "перекладывать джонов"
Любая реализация бизнес логики - алгоритм, а на сеньорских уровнях вам нужно мигрировать и оперировать данными и как раз уже ПОНИМАТЬ как работают инструменты которыми вы пользуетесь. Сорян, на сеньорских позициях чтобы расти дальше без алгоритмов и структур данных вы не поедете никуда
Брехня.
До тех пор пока вы не писали алгоритмический софт: какие-нить индексы, деревья, поиски и т.д. можно считать, что алгосы вы не знаете.
Вы просто прочитали книгу.
Я вообще не понимаю дроча на алгоритмы, если нужны: возьми и разберись, а если не нужны, ну прочитай пару книг.
Мда... Интересная точка зрения. Прям даже вспомнился термин из юности - воинствующий ламер.
Алгоритмы и логика - это база. Без них невозможно предложить хорошее (элегантное, понятное и масштабируемое) решение путем унификации и абстрагирования логики и потоков данных.
Не зная методы оценки алгоритмов постоянно будут применять неправильные коллекции. И не правильные инструменты. Синхронизация потоков становится прям испытание. А некоторые задачи становятся просто не решаемыми.
Как-то сталкивался в кодом, который работает, вроде все правильно, но при работе с которым столько времени высасывает, а чувство тошноты не проходит. При этом сонар неистово матерится на безумные Cyclomatic Complexity. Один раз переписал небольшой класс, потому что невозможно было дальше с ним работать - количество строк снизилось раза в 2, а Cyclomatic Complexity раз в 5.
Комментарий недоступен
Вы видимо писали очень мало коммерческого софта. Если предметная область не предполагает написание чего-то алгоритмического - алгоритмы не нужны и знания о них практически бесполезны, т.к. там сложность и критерии оценки софта совсем другие.
Поделитесь сакральным знанием: это какая именно предметная область не предполагает использования алгоритмов?
Комментарий недоступен
Вы даете советы космического масштаба и космической же глупости, по таким заключениям можно сделать вывод, что коммерческой разработкой софта вы никогда не занимались. Если бы можно было ускорить отчет на два порядка просто его переписав - это все равно, что ничего не делать :)
Комментарий недоступен
Вы видимо не сталкивались с ситуацией, когда в коммерческом софте намечается успех и оказывается, что юзеров/данных становится на порядок больше.
И софт, писанный разрабом, знающим логику/алгоритмы такое переваривает, может с некоторыми допилами. А софт писанный разрабами без знаний математики - можно выкидывать на помойку, тк оптимизировать невозможно
Знание математики это сильно условно. Расскажите какие знания математики вы прям таки применяли в обычном софте, какие проблемы были решены конкретно вами?
90% проблем софта это дизайн, который не соотвествует вариантам использования, оверинженеринг, технический долг, ошметки от предыдущих переделок.
Если бы 80% проблем решались бы алгосами, не было бы такого количества говнософта.
И не факт что человек, который хорошо знает алгоритм может писать понятный и поддерживаемый код.
И да увеличение нагрузки решается маштабированием, и вот вам пример некорректного применения алгоритмов.
Ну во-первых, вы должны четко понимать когда нужно использовать джейсонов, а когда их использование приводит лишь к пустой трате ресурсов и времени на их перекладывание.
Во-вторых, "алгоритмы" это не сортировка массива. Это в общем случае образ мышления - как данную задачу решить наиболее оптимально.
Ну вот попробую описать ситуацию.
Есть задача поиска совпадений по 4-м параметрам. И есть сделанное когда-то решение - отдельные функции поиска совпадений по каждому из параметров (ну типа микросервисы такие).
Что характерно, каждая из четырех функций вызывает некую базовую процедуру (достаточно "тяжелую"), возвращающую некий набор идентификаторов с которыми потом идет работа.
Что делает джун? Он просто берет и пишет программу, получающую на вход 4 параметра, которая внутри последовательно вызывает все 4 функции - по каждому параметру проверяет отдельно. А в результате имеем 4 вызова "тяжелой" базовой функции и реакцию сопровождения - "да вы там офигели, все это ресурсы жрет как не в себя и тормозит".
Думающий же разработчик напишет все с нуля - один вызов "тяжелой" базовой процедуры, затем использование ее результатов для поиска совпадений по каждому параметру. А еще вникнет в то, в каком окружении все это будет работать, поймет что возможны последовательные вызовы при которых изменяется только один-два параметра (от предыдущего) и закеширует результат последнего вызова - если какой-то из параметров не изменился, то будет использовать результаты прошлого вызова.
В итоге получит примерно в 10 раз быстрее и во столько же экономичнее по ресурсам от решения джуна.
Но тут уже какая-никакая алгоритмизация потребуется.
Когда вы просто кликаете мышкой в браузере - отрабатывает алгоритм поиска оптимального активного блока, с учетом расположения элементов, слоев и тд.
Без понимания таких вещей вы не сможете например реализовать быстрый UI ни на каких технологиях.
'Все равно же используются методы, которые реализованы уже для более простого использования'
Потому что эти 'методы' далеко не кнопка 'сделать зашибись' , нужно четко представлять где и что применять.
А без О-нотации это нереально.
Вы явно не занимались коммерческой разработкой фронта, 99% фронт разработчиков не расскажут вам как работает алгоритм поиска оптимального активного блока, с учетом расположения элементов, слоев и тд, потому как это не нужно.
Кнопки красить и просто накидывать компоненты однотипные реальность для абсолютного числа разработчиков.
Я много чем занимался, а вы слишком сильно обобщаете.
Компоненты накидывать? Это закончится где-то на попытке сделать бесконечную ленту или сделать аналог Яндекс.Карт - тупо panning & zoom очень большой картинки с загрузкой по частям.
Вообщем не надо говорить за всех и так поверхностно относиться к веб-разработке, там все совсем не так просто как кажется.
Задачи которые вы описываете выполняют 5% разрабов остальные шлепают формы. По поводу бесконечно ленты не понял в чем сложность, сам делал ее не раз.
Я не говорю что фронт легко, там есть множество проблем в основном связанные с оптимизацией бандла, адаптивностью и работой в разных версиях браузеров разных весрий, но блин точно не в алгоритмах.
А как джун, скорее всего, вы будете выполнять оочень простые задачи бесконенчо далекие от алгоритмов, аля почему TS не принимает тут аргумент
воу, ребята. Тут старт ветки был про шутеечку и джонов ). А вас понесло в самоутверждение и доказательства ) Прям как на собесе в ойти :)
Прям повеяло душным собеседованием?)
Зависит от того где работать. У нас вот формами занимается те самые процентов 5. Остальное - логика. Которая вообще интерфейса может не иметь.
Команда равняется по самому слабому мемберу, к сожалению. Поэтому найм одного даже 'середнячка' приводит к деградации всех остальных в команде.
А если это core team в большом и сложном продукте?
Алгоритмы - один из способов отделить серьезных программистов от обычных, в других профессиях другие метки, но суть такая же.
Понимание аглоритмов, О-нотации и структур данных не означает их постоянное применение каждый день, просто человек работает с пониманием и осознанием сложности, поэтому меньше риска что он сделает какую-нибудь дурость.
И пожалуйста не нужно опять разводить срач про 99% процентов и формошлепство, в отрасли достаточно сложных задач где нужны именно профессионалы.
Не совсем - при приличном менеджменте - команда всё же постарается подтянуть середняка. Но если разница уровней слишком большая - тогда да, получится именно это.
для этого есть либы
Комментарий недоступен
Ни то ни другое, но в Яндекс вас врядли возьмут с таким подходом.
Комментарий недоступен
Если вы пишите фронт на WebAssembly, т.е. подключаете какой-нибудь С++, то, может быть, это и понадобится. Но в случае с тем же Реактом совсем другие компетенции нужны.
Никогда не понимал собеседующих программистов которые хотят занизить зп. Они же не из своего кармана платят. Наоборот, чем больше средняя тем выше они могут себе выбить. Но там реально больше желание самоутвердиться.
Сам я всегда ставил выше оценку и рекомендовал выше зп. Чтобы потом себе как старику больше выпрашивать
Так ФОТ ограничен же.
Те кто вас собеседуют на техническом интервью не имеют отношения к вашей будущей ЗП, если только не лично CTO вас собеседует.
ФОТ определяют тоже не технические специалисты, поэтому посыл про 'занизить зп' не очень понятен.
Насчет самоутверждения.
Само собой что интервью это стресс, так это устроено, вас и ваши навыки проверяют незнакомые люди. По-сути максимум за два часа интервью нужно понять можно с этим человеком работать или нет.
Но вот именно самоутверждаться за вас счет точно мало кому надо, хотя мудаков конечно везде хватает.
Вообще, вы должны выходить с интервью в нормальной компании с улыбкой и счастливым, вне зависимости от того взяли вас или нет, но негатива по отношению к компании точно не должно оставаться.
Просто ты хороший программист) который думает о будущем и стелит себе соломку)
Комментарий недоступен
Комментарий недоступен
Да я думаю всё сталкивались неоднократно на собесе с таким. При чем у меня 100 из 100 выборка - если собеседование назначается с технической части - значит впереди будут алгоритмы и вопросы по внутренней реализации методов, ака "под капотом"
Комментарий недоступен
Джун)
Комментарий недоступен
Ну не обязательно, у меня были собеседование тоже в виде беседы. Всё таки кто-то ищет сотрудника для работы в реальности, а не выдуманном мире. Спрашивали опыт, какие-то кейсы для уровня Джуна конечно.
Ну щас даже на ЕГЭ в задачах есть простые задачки на bfs/dfs, операции над списками и массивами и тд
Комментарий недоступен
потому что на джунов всем пофиг)
Будут недовольные - завтра придёт ещё 100 тыщ мильёнов
Плюсую. Знаю много примеров, как люди с далеко не математическим мышлением переходили в ойти. Не дата сайнс конечно. Но на фронтенде/бэкенде/автоматическом тестировании вполне комфортно себя чувствуют.
В программировании вообще больше гуманитариев, чем математиков. Где-то даже исследование проводили, что лингвистическое способности лучше коррелируют с успехами в разработке, чем математический образ мышления (если такой вообще существует).
Худший разработчик, с которым имел дело - был профильным математиком. Формулы действительно умел, неймспейсить классы было невыполнимо.
Комментарий недоступен
Предполагаю, что люди просто путают алгоритмы и шаблоны проектирования.
Использование готовых библиотек - уровень джуна. Расти разработчик начинает тогда, когда начинает понимать как эти библиотеки устроены внутри, чем они отличаются по реализации и когда какую эффективнее использовать. С этим пониманием он становится мидлом.
Чтобы стать сеньором нужно сверх того уметь написать свою реализацию под конкретную задачу, если это потребуется с точки зрения эффективности.
Так не все становяться сеньорами.
Да и пастить готовые бибилиотеки - это все делают от джуна до сеньора.
Просто сеньор может выйти на 500К р
А большинство не сможет и будет получать сидя в сибири 150-250К и чуствовать себя милионером
логика в программировании на уровне детского сада - не все лендосы на реакте бахают, большая часть разрабов решают нетривиальные задачи чуть чаще чем каждый день. Алгоритмы это проверка:
а) на живость ума - не обязательно знать все структуры, чтобы показать собеседующему, что ты "могёшь"
б) на силу заинтересованности в работе - не каждый чел сможет сидеть (скорее всего после полного рабочего дня) и разбираться в деревьях и связанных списках.
Комментарий недоступен
для написания лендоса на реакте - не нужно иметь логику, можно просто проследовать любому из многочисленных туториалов.
в основе написания кода лежат несколько простых принципов - серьёзно? Вы когда-нибудь слышали про функциональное программирование? Монады? Каррирование? Написание программы в одну функцию через композишн и пайпы? Даже если мы берём ООП, жду ссылку на исследование, сколько детсадовцев (на самом деле я понимаю, что это утрированно, поэтому можете повысить до старшеклассников - стата не изменится) разобрались в этих ваших полиоморфизмах, и что там ещё есть, и могут успешно применять эти знания в жизни. Спойлер: такой ссылки нету, потому что за прогой стоит абстрактное мышление, и для части людей это просто кирпичная стена, которую они никогда не пройдут. Они могут стать айтишниками, сеньёрами - многие компании кладут откровенный болт на то, что я написал выше - но суть в том, что с точки зрения ценности программирования эти люди будут плюс минус нулями (что может не мешать им быть успешными)
Комментарий недоступен
Архитектура машины имеет такое же отношение к программированию, как вы к умению аргументировать свою позицию в диалоге.
ФП не сложное - ок, спасибо за мнение - видно, что вы эксперт в данной области. Думаю, что на этом мы с вами закончили. Хорошего дня.
Комментарий недоступен
Загуглите, от меня вы сможете получить только одностороннее мнение. ФП это программирование по законам математики. Там гораздо меньше багов и абсолютно все крупные программы и системы сейчас сделаны с оглядкой на него. Каждый раз, когда у вас крашится какая-то прога или система - в этом виноват ООП и мутирование переменных.
Более простые альтернативы это что-то на уровне сравнения - зачем нам математика и её законы, чтобы копать огород нужна только лопата и сила. Кому-то достаточно огорода для жизни, а кто-то хочет покорять космос. Вот и всё.
Комментарий недоступен
Наличие "стейта" программы, который изменяется императивно из разных методов - основа любой ООП программы.
Комментарий недоступен
Комментарий недоступен
Программирование это про создание абстракций и построение моделей из этих абстракций, такое далеко не все умеют, в следствие чего рождается говномодель реализованная говнокодом.
Чел, завязывай. Какой мат анализ? :) У меня 90% знакомых кодеров не знают производную от x^2 и что такое логарифм, я уже не говорю о матане, который выходит за рамки вузовской программы при решении практических задач. Те кто знает мат анализ работают на таких работах, где больше требуется низкоуровневое программирование, связанное с вычислениями или машин лёрнингом (по естественным причинам).
Для всяких реакт жс разрабов, бекендеров пишуших круды и отчеты - матан нахер не упал
а что бекендерам не нужно логическое мышление и алгоритмы?
Ваша постановка вопроса уже показывает непонимание всей сути и проблемы.
поясните
Понимаете, есть бекендеры, которые пишут базы, а есть бекендеры, которые эти базы используют. Чувствуете разницу между этими бекендарами?
да. получаетсяя про тех кто использует
Ну вот им матан не нужен
да не про матан он тут говорит, а про технарный ум.
У меня есть знакомые, они не могут мысль свою кратко и последовательно сформулировать , как -то неструктурно у них это идет.
Вот таким точно не надо в ИТ . И им непонятно , как надо, и другим раздражаловка , потому что неконкретно.
Мне тоже так говорят, но проходя курс пайтон, я начинаю офигевать от задач, которые там нужно решить (всякие мантиссы и экспоненты). И для меня это реально темный лес. Нет задачи стать программистом, есть задача прокачать себя как сеошника. Во время решения таких заданий я уже начала сомневаться, насколько там не нужна математика...Но говорят, не нужна и все мол легко через библиотеки и прочее
Мантисса и экспонента - это не матан, а алгоритм. Если не понимаете что это такое или нет желания понять, то зачем себя мучать. Есть много других профессий, сварщики, крановщики - они неплохо получают.
Ну и то что вы питон начали учить чтобы познакомиться с программированием - это тоже говорит о том, что программирование как таковое вам не интересно.
Комментарий недоступен
потому что "оперировать виртуальными объектами качественно, а один из 10000". Сколько у нас процентов айтишников? Допустим, 5. Тогда 10000 превращается в 500. Т.е. один из 500 айтишников может в прогу "качественно". Остальным 499 заветные 100$к+ в год не светят
Комментарий недоступен
так это не противоречит тому, что я написал)
Серьёзное айти оплачивается большими деньгами, потому что очень немногие люди могут держать в голове объёмные абстракции и успешно ими оперировать. Например взять электронную жилу машин. Пару лет назад читал, что сейчас уже ни один человек не способен знать и понимать весь код, который там находится - настолько всё комплексно и распростёрто. В обычной инженерии люди не сталкиваются с таким (там другого уровня сложности), плюс её можно автоматизировать, а прога пока только беби степс делает к автоматизации
Комментарий недоступен
Рукожопов много везде) Много чего можно оптимизировать и автоматизировать. Но всеми любимый рынок диктует свои правила. Софтвейр девелопер - это то, что нужно любой компании в больших количествах. Вот и всё.
Код нужно комментировать! При написании оного.
Всё просто, качество кода это очень редкий KPI :)
Должна быть какая-никакая культура и вот это всё, чтобы думать про код как про модель в (хотя бы) трехмерном пространстве. Как правило такой культуры нет. И поэтому, если можно наговнокодить и через ~год (аккурат тогда, когда скорость доставки фич падает из-за предыдущих решений) сменить работу, то будут делать именно так.
Комментарий недоступен
А все просто , требования высокие, зп заявляют высокие, но по факту берут кучу джунов. которых стимулируют развиваться к высокой зп. Джуны в свою очередь гавнокодят и косячат. Но в конторе есть 1 топ программист который тянет важные проекты. В итоге проект из портфолио суперский, все остальное что делает средне статическая контора - шлак.
Комментарий недоступен
работа специфичная но за компом по 10 часов сидит весь офисный планктон.
про постоянное самообучение - хз откуда берется этот галимый фейк возможно джуны его распространяют ) реально может у 10% програмеров есть нужда в _постоянном_ изучении. либо у кузнечиков которые меняют галеры постоянно, либо у аутсорсеров в которых проекты тоже часто меняются вместе со стэком.
но в продуктовых конторах я не вижу вообще чтоб прямо обучение какое-то струилось, ну так в меру что-то новое понятно юзаешь, точно как и автослесать новые тулзы осваивает с годами. но это вообще не приоритет. куча продукта написано на стэке так сказать "средней" давности, не старый но и не cutting edge и никто никогда его не переписывает полностью.
а уж сеньоры / лиды так и вообще... аналитические способности делают 80% работы.
Так можно сказать про любую работу. Можно не учиться и сидеть на нагретом месте без каких-либо перспектив, а можно вкладываться в своё развитие и двигаться дальше.
херню сказал)
Можно не учиться и сидеть на нагретом месте без каких-либо перспективможно и так если хочется, но я не об этом случае )
я о более реалистичном варианте когда ты отлично работаешь на своем месте, просто именно _реалистично_ обновление стэка и кардинально тулзы обновляются может раз в 3 года например. это совсем не "постоянное самообучение".
это вполне комфортный уровень, стабильное проф. развитие.
собсно да, как на любой другой более-менее творческой работе.
айтишники в этом плане не особенные, вот в чем дело, но многие разносят фейк что именно в айти надо прямо бедным учиться сутками всю жизнь.
И как ваш пассаж доказывает, что я сказал херню? Вы сказали то же самое, только развернуто. Но да, непременно для начала нужно наехать на оппонента.
оппонент епта )
сидеть на нагретом месте без каких-либо перспективни одно слово здесь не то же самое что я сказал
Выдирать из контекста научились, а понимать суть самого сообщения нет. И ещё что-то поясняете за сложность профессии, обучение. Диванные аналитики они такие.
какая суть в той воде что ты написал - "можно так а можно вот так, 50/50%", охуенно ценная инфа.
я говорю как в реале в продукте все делается, для тех читает про некое "постоянное самообучение" которого не существует по большей части.
Комментарий недоступен
Прежде чем работать по 4 часа, нужно несколько лет проработать по 12 :)
Расскажите о своих пиздастраданиях хирургу или нефтнику на вышке где нибудь в ж... мира
Просидеть за компом 10 часов не вопрос. А вот интенсивно ворочать мозгами 10 часов уже не каждому дано. И при этом еще умудрится сохранить концентрацию и внимание к каждой мелочи.
Найти ошибку в 10 000 строках чужого кода с зубодробительной логикой (которую сначала понять надо) в следствии которой программа при определенном наборе данных на входе в каком-то месте пошла не по той ветке...
''Такой непосильный труд 10 часов в день за компом сидеть(нет).
Сидеть то как раз не очень сложно) А думать и работать все 10 часов попробуйте, тогда говорите) Видимо вы как раз «сидели» в удобном кресле, а если проанализировать тайминг, то мне кажется вас постигнет разочарование в своей производительности )
Комментарий недоступен
Это показатель не производительности, но количества денег в сфере где работаете.
К сожалению, далеко не все определяется трудозатратами.
Комментарий недоступен
Именно так. Но тут зависит от того, может себе работодатель позволить высокие зарплаты или нет. А это определяется рыночной стоимостью его продукта и прибылью.
Сталкивался с автоматизацией в сфере ЖКХ. Задачи очень сложные, поверьте - система мониторинга инженерного оборудования зданий (там и промконтроллеры и протоколы связи и софт верхнего уровня). Но больших денег там нет - отрасль очень жестко зарегламентирована.
Сейчас в банке. Не скажу что проще или сложнее. Примерно так же по уровню сложности, хотя есть и специфика и там и там. Но денег в разы, если не на порядок больше. При сравнимых трудозатратах.
все понятно Серега.
все по полочкам разложил этим айпишникам.
сидят там за своими компами и воображают, а как телефон там починить или утюг, так не могут.
Комментарий недоступен
не ненадо все так сложно
сидеть на шаблонных задачах - там нет математики
только копи-паста и немного мозгов
Комментарий недоступен
Как Сталин — Молотова)
Комментарий недоступен
😂
Эт оправдания) не везде в программировании нужен математический склад ума. В фронтенде где версткой занимаются вообще с математикой сталкиваться не приходиться. Нужно просто не полениться разобраться в синтаксисе
Про сложность работы и что она не всякому подходит я могу согласиться, т.к. работаю seo-специалистом и замахнулась на большее - изучение пайтон. Сначала все было норм, но потом начались жутко сложные задачи, что даже коллеги не могли понять, что от них хотят. Все еще продолжаю смотреть курсы пайтон для понимания что и как там работает. Нет уже желания менять сферу, но именно знать языки сеошнику все же будет +, особенно, когда в резюме идут требования по знанию бэкенд части (попадался php и я его не знаю, но думаю, разобраться на менее чем базовом уровне смогу, т.к. для остального будет помощь от программистов). В общем, я к тому, что не всем реально это дается + когда нет ментора или хотя бы того, кто мог бы объяснить - тоже сложно. Но изучить и работать можно, изменив мышление не в корне, но хотя бы на немного. Зависит от желания и собственных сил и помощи от реального человека, как по мне.
Для чего это нужно? Пусть сами и поддерживают проекты, они же с заказчиков за это деньги брали.
Разрабу лучше поддерживать только свои проекты.
Ну если он за всю жизнь не сделал ничего сложнее одностраничного сайта, то да.
А когда он работает в команде из 100+ человек, которая поддерживает, обновляет и дорабатывает архитектуру из десятков тысяч объектов, то разговор немножко другой будет.
Такой?
https://youtu.be/AWaL_1V9dEY
Нет. к фронтам это вообще отношения не имеет. И даже в к беку в том виде, в котором его видит большинство современных разработчиков.
Представляете что такое автоматизированная банковская система? Это голимая бизнеслогика. Десятки тысяч программных объектов. Десятки тысяч таблиц. Сотни миллионов операций в сутки. Терабайты изменяющихся данных в сутки.
Десятки внешних систем откуда приходят запросы и куда отправляются данные.
И все это постоянно меняется. Новые бизнеспроцессы, меняющиеся требования.
Все это работает на очень специфических серверах с очень специфической платформой.
Да, здесь много команд по различным направлениям. Но внутри команды и направления нет деления "это твой объект, это мой объект". И капризов "это не я писал, дорабатывать не буду" тут не бывает.
Грести быстрее никто не заставит. Хотя бы потому, что код в первую очередь должен быть качественным. Бывают задачи с жесткими сроками внедрения (т.н. "нормативка"), но на них ставят тех, в ком уверены что человека справится.
По вашему описанию выходит, что финтех это адовый ад.
Кмк лучше уж верстать лендосики на Тильде =))
Ну почему ад. Нормальная работа. Интересная. Хотя кому как, да.
Если привыкли левой ногой из готовых фреймворков лепить типовые сайты, то да. Ад. Потому что думать придется постоянно.
А если хочется чего-то нестандартного, то милости просим. Начиная с того, что сама платформа не похожа ни на что. Система где "все есть объект". И очень много весьма специфических сущностей, не имеющих аналогов в других системах (те же "группы активации", системные объекты типа user space, user index, user queue, data queue, data area) Погуглите что такое IBM i.
Все это просто нестандартно и интересно. И да, можно писать на разных языках, а потом разноязычные модули собирать в один программный объект. Система позволяет и такое.
Сейчас работаем вот на этом:
Модель: Power E980
• 120 процессорных ядра Power9
• RAM (Оперативная память) - 12Тб
• LAN (Сетевые контроллеры) - 10Гигабит
• Storage - 400Тб на SSD
• Operation System: IBMi 7.4
Это на проде, тестовый попроще.
А что нужно изучить в этой специализации?
Ну в первую очередь саму платформу IBM i. Повторюсь, она очень специфическая. Ни на винду, ни на никсы не похожа совсем. Даже файловая система своя. Ну и много очень специфических вещей. Например, когда в одном и том же задании программа запускается повторно, значения глобальных и статических переменных сохраняются с прошлого запуска. Часто это используется для всякого рода кеширования.
БД встроенная в систему (DB2). Вообще все необходимые средства встроенные - БД, включая SQL, компиляторы, отладчик.
На уровне системы поддерживаются языки CL (язык системных команд - там референс по командам на 2300 страниц плюс можно сои команды делать) - используется для общания с системой, но можно и программы несложные писать и компилировать. С/С++, RPG, COBOL (поддерживается, но не пользуемся). Для бизнеслогики используем RPG и SQL (SQL команды можно вставлять в RPG код), для низкоуровневых вещей - C/C++. Часто бывает так, что программа собирается из нескольких модулей - логическая часть на RPG, низкоуровневая часть на С/С++.
Но практически никаких готовых фреймворков (ну кроме той кодовой базы, что нами же написана да нескольких библиотек). Т.е. многое пишется руками.
Но в целом, готовых разработчиков по этой системе немного в стране. Преимущественно банки (точно знаю что райф, росбанк и альфа на ней сидят). Ну и несколько "вендоров" - контор кто по заказу работает с теми же банками. И все более-менее друг друга знают.
У нас обычно берут просто толковых разработчиков и обучают специфике (2-3 месяца). Или оплачиваемые стажировки открывают (6 месяцев).
Да-да. Я попав в продуктовые галеры после аутсорса тоже так думал. А потом после продуктового екома в банк и потом в другой банк.
Всегда вся ретроспектива проводится ТОЛЬКО по количественным показателям. Всем наплевать на качество.
Менеджерам и аналитикам важно закрыть как можно больше новых фич (бизнес-логика) и пофиг как они там внутри работают и покрыты ли тестами.
Для менеджмента важно сэкономить пару тысяч рублей на зарплате сотрудника, чем если этот сотрудник будет писать какие-то ненужные и непонятные юнит- и функциональные тесты чтобы предотвратить баг на продакшене из-за которого банк может потерять миллионы денег.
Если сотрудник тратит время на покрытие фичи тестами, то по мнению менеджеров он ничего не делает т.к. не закрывает другие фичи, а значит этот сотрудник должен быть уволен.
Если же вместо написания тестов сотрудник будет делать задачи на "тяп-ляп-хуяк-хуяк-и-в-продакшен", то он закроет больше фич, не будет уволен и даже получит премию.
Если же из-за отсутствия тестов в продакшене вылезет баг и банк потеряет миллионы денег, то менеджмент просто погрозит пальчиком техническому директору, а тот поставит новые задачи в джире проверить этот случай. Сотрудник закроет фичу и получит денег. В итоге никто не уволен и все довольны.
А как вы думаете, почему были ситуации когда в одном жёлтом банке заходишь в личный кабинет, а там отображается счёт совсем другого человека?))))
Вы про что-то другое. Личные кабинеты и вот это все - это не про нас. Это все внешние системы. Мы работаем на уровне ядра АБС. Того, что крутится на серверах. Час простоя - порядка $500К И вплоть до лишения лицензии "за неисполнение обязательств перед клиентами" (времена недоступности систем жестко регламентированы регулятором и по ряду mission criticlal систем допустимое время недоступности исчисляется минутами).
Тестирование многоуровневое - сначала компонентное, потом бизнес, потом интеграционное, потом нагрузочное. Только после этого в прод.
Про экономию на з/п - судите сами. С 15.03 по всему IT направлению был существенный пересмотр в сторону повышения. С 01.04 повышение на 15% всем сотрудникам. В итоге лично у меня вышло в два раза повышение (у остальных примерно также плюс-минус).
До этого раз в год пересмотры (там индивидуально, у меня получалось где-то +25% в год). З/п вся на 100% белая, прописана в ТД. Бонусы отдельно (раз в квартал, с учетом личного КПИ, в сумме за год еще пара з/п набегает.
Комментарий недоступен
Начать с какого нибудь Javascript для детей. Там поймешь нравится или нет.
Тогда уж с Go или Python, потому что JS в чистом виде мало кому нужен, а экосистема у него такая, что захлебнуться можно. В той же коммерческой разработке на чистом JS все меньше пишут, все чаще TypeScript.
Есть проекты и на vue. Особенно какой-то SPA-сайт. Пайтон по началу легкий, потом всякая жуть начинается, но интересно, несмотря на все это. Конечно, курс рассчитан на самоизучение, но без помощи реального программиста не обойтись(
Можете также посмотреть какие-то бесплатные курсы. Я смотрела по пайтон от Нетологии и там все так быстро объяснили (писали простого бота). Было очень интересно. В итоге я решила изучать этот язык и понимаю, что мне сложно. Работаю сеошником, хочу прокачать знания. Сначала все легко, а потом такие жуткие задачи( Но интересно, так что прохожу курс дальше
Комментарий недоступен
Если бы деньги измерялись литрами просиженной жопы, вынужденному самообразованию и количеством итераций одной и той же работы, то проектировщики бы жили не хуже, как минимум. Увы, подобного не наблюдается.
ну уж и не рокет саенс точно
поменьше гонора