Риторический вопрос: почему программистам так много платят, ведь их работа весьма лёгкая и при этом весьма интересная, и даже печеньки выдают бесплатные (я сам всю жизнь работал программистом, и да, это всегда было довольно легко и увлекательно :) ?
Чтобы стать в ИТ успешным, надо работать прежде всего не тактически -- внутри своей карьеры, а стратегически -- над своей карьерой.
Внутри своей карьеры вы решаете типовые проблемы на работе, и если встречаются такие, которые вы не решали раньше, вы немного растёте, но не сильно. В следующий раз вы просто решите их быстрее.
Это в целом улучшает вашу карьеру, но ненамного. Выгодно это вам на 20%, а вашему работодателю на 80%.
Если же вы хотите улучшить свою карьеру намного, вы должны работать над своей карьерой. Вы должны делать работу, которая умножает ценность прежде всего вас самих в ИТ глобально, а не только вашу рабочую ценность и ценность вашего окружения внутри одной небольшой команды.
Это должно быть уже не столько непосредственное написание кода, сколько мета-деятельность -- регулярный блог, аккуратный и активно развиваемый гитхаб, комиты в известные проекты, активное участие в конференциях etc
Внутри своей карьеры вы решаете типовые проблемы на работе, и если встречаются такие, которые вы не решали раньше, вы немного растёте, но не сильно. В следующий раз вы просто решите их быстрее.
Это в целом улучшает вашу карьеру, но ненамного. Выгодно это вам на 20%, а вашему работодателю на 80%.
Если же вы хотите улучшить свою карьеру намного, вы должны работать над своей карьерой. Вы должны делать работу, которая умножает ценность прежде всего вас самих в ИТ глобально, а не только вашу рабочую ценность и ценность вашего окружения внутри одной небольшой команды.
Это должно быть уже не столько непосредственное написание кода, сколько мета-деятельность -- регулярный блог, аккуратный и активно развиваемый гитхаб, комиты в известные проекты, активное участие в конференциях etc
Как вам как программисту получить повышение/прибавку?
1. Спросите своего тимлида/менеджера/нач.отдела, что конкретно вам нужно сделать (чему научиться, чего добиться...), чтобы получить повышение в должности или прибавку к зарплате, и в какой срок?
2. Попросите его прислать вам ответ по электронной почте или в корпоративном чате.
3. Пашите.
4. За месяц до окончания срока напомните тимлиду, что близится время повышения вашей зарплаты. Покажите в доказательство его оригинальное письмо и все-все-все документы/комиты/тикеты, объективно подтверждающие, что вы действительно добились и теперь полностью соответствуете всем критериям повышения.
1. Спросите своего тимлида/менеджера/нач.отдела, что конкретно вам нужно сделать (чему научиться, чего добиться...), чтобы получить повышение в должности или прибавку к зарплате, и в какой срок?
2. Попросите его прислать вам ответ по электронной почте или в корпоративном чате.
3. Пашите.
4. За месяц до окончания срока напомните тимлиду, что близится время повышения вашей зарплаты. Покажите в доказательство его оригинальное письмо и все-все-все документы/комиты/тикеты, объективно подтверждающие, что вы действительно добились и теперь полностью соответствуете всем критериям повышения.
Однажды Каспаров давал сеанс одновременной игры со 100 шахматистами. На одной доске он забрал ферзя, и игрок сказал: "вы скушали моего ферзя, я думаю, что теперь проиграю" :)
Каспаров ответил: "ты проиграл, едва только сел играть со мной".
Каспаров вообще не сомневался, что выиграет.
Это отличный критерий знания вами какой-то темы: когда вы в ней действительно хороши, вы просто будете знать, что у вас всё получится, ещё до того, как начнёте, у вас вообще не будет никаких сомнений.
Я например абсолютно уверен, что могу спроектировать и запрограммировать любую игру, любой сложности. Почему именно игру? Потому, что вообще разработка игр (особенно реального времени) -- пожалуй самое трудное, сложнее разве что всякие embedded-системы, программно-аппаратные комплексы, но это довольно специфическая область сама по себе. В современных онлайн-играх сотни тысяч запросов в секунду не редкость, и ведь это моделируется сложный физический мир (хотя в 3D-шутерах сервак грузится в основном тем что коллизии считает :). В сравнении с тем же WoW бизнес-проекты смотрятся как детский сад. На гитхабе например пиковая нагрузка всего 55k rps, да и логика примитивная.
А главное, что абсолютно уверен, что могу обучить этому всему любого мотивированного миддла.
Сомневаюсь же пока например, что смогу доказать на каком-нибудь прувере (вроде Lean) первую теорему об изоморфизме с помощью гомотопической теории типов. Но это временно.
Найдите тот уровень в программировании, в котором вы абсолютно уверены, что справитесь, и неважно насколько он высок или низок (написать простую консольную игру или клон kings bounty; перерешать все задачки из "Cracking the Coding Interview" или с codeforces.com; ...).
Используйте этот уровень как прочную стартовую площадку, и смело взбирайтесь выше на следующую ступеньку.
Каспаров ответил: "ты проиграл, едва только сел играть со мной".
Каспаров вообще не сомневался, что выиграет.
Это отличный критерий знания вами какой-то темы: когда вы в ней действительно хороши, вы просто будете знать, что у вас всё получится, ещё до того, как начнёте, у вас вообще не будет никаких сомнений.
Я например абсолютно уверен, что могу спроектировать и запрограммировать любую игру, любой сложности. Почему именно игру? Потому, что вообще разработка игр (особенно реального времени) -- пожалуй самое трудное, сложнее разве что всякие embedded-системы, программно-аппаратные комплексы, но это довольно специфическая область сама по себе. В современных онлайн-играх сотни тысяч запросов в секунду не редкость, и ведь это моделируется сложный физический мир (хотя в 3D-шутерах сервак грузится в основном тем что коллизии считает :). В сравнении с тем же WoW бизнес-проекты смотрятся как детский сад. На гитхабе например пиковая нагрузка всего 55k rps, да и логика примитивная.
А главное, что абсолютно уверен, что могу обучить этому всему любого мотивированного миддла.
Сомневаюсь же пока например, что смогу доказать на каком-нибудь прувере (вроде Lean) первую теорему об изоморфизме с помощью гомотопической теории типов. Но это временно.
Найдите тот уровень в программировании, в котором вы абсолютно уверены, что справитесь, и неважно насколько он высок или низок (написать простую консольную игру или клон kings bounty; перерешать все задачки из "Cracking the Coding Interview" или с codeforces.com; ...).
Используйте этот уровень как прочную стартовую площадку, и смело взбирайтесь выше на следующую ступеньку.
Причина N1, по которой программистов увольняют внезапно, и это может случиться с вами в любой момент, и это не то, что вы предполагаете, это вовсе не потому что вы накосячили, уронили прод и т. д., N1 совершенно вне вашего контроля. Это глобальные финансовые проблемы в компании, сокращение штатов или реорганизация.
Так что вы можете просто придти на работу в один прекрасный день, и сесть писать идеальный код, но колесо судьбы уже остановилось на вашем ID, и они случайным образом выбрали именно вас, и решили вас уволить и взять на вашу позицию кого-то другого с меньшим окладом, кто не справляется с работой даже близко к вашему классному уровню.
Но, всем пофиг.
Гарантий нету нигде и никогда не будет. Вот почему так важно непрерывно развивать свои навыки программиста за пределами текущих рабочих обязанностей, и всегда иметь несколько (а лучше много) вариантов трудоустройства про запас.
Но это нереально, если вы не рекламируете себя в ИТ как программиста. Если вы не рекламируете себя, если вы не развиваете личный бренд, вы так и будете всю жизнь тусоваться по мутным вакансиям, униженно вымаливая очередную работу в толпе таких же бедолаг, когда очередная ваша контора закроется.
У вас всегда будут подобные проблемы просто потому, что на самом деле совершенно неважно, насколько вы хороши как специалист в техническом плане.
Вы должны регулярно, всю жизнь развивать блог, зеркалить его в соцсетях, прокачивать гитхаб, вести канал на ютубе, или в инсте, или даже в тiктоке (извините). Эти каналы будут автоматически продвигать вас, будут рассказывать другим людям, кто вы есть и что хорошего вы реально умеете делать -- чтобы в случае любых траблов на текущей работе вы могли бы получить новую хорошую работу немедленно.
Так что вы можете просто придти на работу в один прекрасный день, и сесть писать идеальный код, но колесо судьбы уже остановилось на вашем ID, и они случайным образом выбрали именно вас, и решили вас уволить и взять на вашу позицию кого-то другого с меньшим окладом, кто не справляется с работой даже близко к вашему классному уровню.
Но, всем пофиг.
Гарантий нету нигде и никогда не будет. Вот почему так важно непрерывно развивать свои навыки программиста за пределами текущих рабочих обязанностей, и всегда иметь несколько (а лучше много) вариантов трудоустройства про запас.
Но это нереально, если вы не рекламируете себя в ИТ как программиста. Если вы не рекламируете себя, если вы не развиваете личный бренд, вы так и будете всю жизнь тусоваться по мутным вакансиям, униженно вымаливая очередную работу в толпе таких же бедолаг, когда очередная ваша контора закроется.
У вас всегда будут подобные проблемы просто потому, что на самом деле совершенно неважно, насколько вы хороши как специалист в техническом плане.
Вы должны регулярно, всю жизнь развивать блог, зеркалить его в соцсетях, прокачивать гитхаб, вести канал на ютубе, или в инсте, или даже в тiктоке (извините). Эти каналы будут автоматически продвигать вас, будут рассказывать другим людям, кто вы есть и что хорошего вы реально умеете делать -- чтобы в случае любых траблов на текущей работе вы могли бы получить новую хорошую работу немедленно.
Лаборатория Математики и Программирования Сергея Бобровского pinned «Причина N1, по которой программистов увольняют внезапно, и это может случиться с вами в любой момент, и это не то, что вы предполагаете, это вовсе не потому что вы накосячили, уронили прод и т. д., N1 совершенно вне вашего контроля. Это глобальные финансовые…»
Интересное наблюдение, что плавно переучивать людей переходить к более продвинутым парадигмам программирования практически невозможно. Рассуждаешь о формальной логике приложения, как её "запрограммировать" на HoTT, а человек не хочет отрываться от примитивной императивщины, даже в ООП правильно не хочет проектировать, абстрактными (даже не алгебраическими) типами данных, не говоря уж о ФП. Ты изучил сотни книг по математике и computer science, а человек смотрит программирование (смотрит! программирование!) на ютубе и не читает вообще.
Мудрецы кстати в таком случае рекомендуют не плавный переход, а резкую смену вообще всего контекста, всей парадигмы. Не вымучивать плавное использование LINQ в C# или functools в Python, а сразу принудительно заставлять писать код исключительно на F# например. В университетах уровня Оксфорда кстати так и делают прямо с первого курса.
Выпущены тысячи (!!!) учебников по программированию, в которых людям навязывается фактически ложная парадигма обучения и понимания. Это всё обман по большому счёту, это гарантированно тупиковый путь.
Потому что внутри такой ложной реальности, ложной парадигмы любые знания фактически не имеют никакой ценности, их КПД крайне невысокий. От того, что вы прочтёте сотни книг по технологиям, фреймворкам и императивному программированию, не станете в информатике умнее. А вот даже всего от двух-трёх книг по профильной математике, по математической логике, по теории типов -- очень даже.
Мудрецы кстати в таком случае рекомендуют не плавный переход, а резкую смену вообще всего контекста, всей парадигмы. Не вымучивать плавное использование LINQ в C# или functools в Python, а сразу принудительно заставлять писать код исключительно на F# например. В университетах уровня Оксфорда кстати так и делают прямо с первого курса.
Выпущены тысячи (!!!) учебников по программированию, в которых людям навязывается фактически ложная парадигма обучения и понимания. Это всё обман по большому счёту, это гарантированно тупиковый путь.
Потому что внутри такой ложной реальности, ложной парадигмы любые знания фактически не имеют никакой ценности, их КПД крайне невысокий. От того, что вы прочтёте сотни книг по технологиям, фреймворкам и императивному программированию, не станете в информатике умнее. А вот даже всего от двух-трёх книг по профильной математике, по математической логике, по теории типов -- очень даже.
Смартфоном компании S пользуются миллиарды людей, однако у самой S почти нулевая власть, потому что они не могут влиять на тех, кто использует их смартфоны.
У многих людей есть телевизоры S, но властью обладает именно Netflix, потому что это они решают, какие шоу на экранах S рекламировать.
Люди, работающие в музыкальном бизнесе, ошеломлены сегодня количеством новых исполнителей, которые являются из ниоткуда, и их незамысловатые песенки становятся хитами на TikTok. Они говорят что дескать ого, как могуществен этот тикток!
Но это совсем не так. Тикток просто передаёт другим, что делают люди, но никак не участвует в создании контента. Реальная власть тиктока случайная, очень неустойчивая и почти нулевая.
Может казаться, что владельцы Facebook или Google невероятно могущественны, но это не так. Реальной властью обладают анонимные инженеры, настраивающие поисковые алгоритмы; математики, разрабатывающие продвинутые AI; программисты, непосредственно кодирующие блокчейны электронных выборов ))) Все остальные просто ходят к ним на поклон. Как например в 8-й серии первого сезона Миллиардеров -- когда вычисляли крота, то космический босс сам пришёл "в серверную" к айтишнику, у которого хранятся все-все-все цифровые ниточки.
И все эти айтишники -- в отличие от всех остальных вроде бы обладающих "властью" в своей конторе -- совершенно не привязаны к этим громким корпоративным именам, в любой момент могут из них уйти; и такая незримая власть самой могущественной в мире секты, огромной пиринговой сети независимых it-анонимусов, связанных профессиональной солидарностью и языком общения, доступным лишь немногим посвящённым, по мере оцифровывания мира, стремительного роста числа балбесов :) и движения к технологической сингулярности будет только расти и расти.
Сообщать о погоде -- это совсем не то, что создавать погоду.
Создатели погоды существуют, но это совсем не те люди и не те компании, которых мы знаем.
У многих людей есть телевизоры S, но властью обладает именно Netflix, потому что это они решают, какие шоу на экранах S рекламировать.
Люди, работающие в музыкальном бизнесе, ошеломлены сегодня количеством новых исполнителей, которые являются из ниоткуда, и их незамысловатые песенки становятся хитами на TikTok. Они говорят что дескать ого, как могуществен этот тикток!
Но это совсем не так. Тикток просто передаёт другим, что делают люди, но никак не участвует в создании контента. Реальная власть тиктока случайная, очень неустойчивая и почти нулевая.
Может казаться, что владельцы Facebook или Google невероятно могущественны, но это не так. Реальной властью обладают анонимные инженеры, настраивающие поисковые алгоритмы; математики, разрабатывающие продвинутые AI; программисты, непосредственно кодирующие блокчейны электронных выборов ))) Все остальные просто ходят к ним на поклон. Как например в 8-й серии первого сезона Миллиардеров -- когда вычисляли крота, то космический босс сам пришёл "в серверную" к айтишнику, у которого хранятся все-все-все цифровые ниточки.
И все эти айтишники -- в отличие от всех остальных вроде бы обладающих "властью" в своей конторе -- совершенно не привязаны к этим громким корпоративным именам, в любой момент могут из них уйти; и такая незримая власть самой могущественной в мире секты, огромной пиринговой сети независимых it-анонимусов, связанных профессиональной солидарностью и языком общения, доступным лишь немногим посвящённым, по мере оцифровывания мира, стремительного роста числа балбесов :) и движения к технологической сингулярности будет только расти и расти.
Сообщать о погоде -- это совсем не то, что создавать погоду.
Создатели погоды существуют, но это совсем не те люди и не те компании, которых мы знаем.
Типичный ньюбский вопрос "почему AAA-игры пишут на C++ а не на Java?", и на него часто дают ньюбский ответ "потому что Java медленнее (нет)", или "потому что Java не умеет работать с графическим процессором (нет)".
Единственная причина в том, что плюсы позволяют очень качественно контролировать работу с памятью.
В Java же единственная реальная проблема в этом плане фактически в том, что в JVM по дефолту есть сборщик мусора, который автоматически очищает память. И для обычного софта это вполне приемлемо, и работает хорошо, но в играх динамически создаётся и уничтожается множество довольно больших объектов. Их детальное описание (ну, вертексы, текстурные координаты...) хранится в больших нативных буферах, которые непосредственно в программе представлены маленькими объектами, содержащими лишь ссылку на эти буферы. И вот сермяга в том, что сборщик мусора не знает, сколько байт реально занимает родной буфер, так как он находится вне зоны компетенции сборщика. Он видит лишь маленький объект, думает, что в памяти всего лишь несколько таких маленьких объектов, и поэтому не вычищает их. А в результате получается OutOfMemoryException, потому что её всю забили здоровенные буферы.
Но есть способы обойти эту проблему (например, созданием специализированных JVM), и для многих задач Java даже превосходит C++. Так, многие игры, написанные на C++, часто падают :) ага, из-за нарушения доступа к памяти, а в Java этого не может произойти в принципе, потому что в ней нету арифметики указателей. Время выполнения благодаря JIT-компилятору иногда даже превосходит время выполнения программ на C++. Ну вот довольно старые тесты, с тех пор Java ещё больше ускорилась: https://stackoverflow.com/questions/145110/c-performance-vs-java-c
Ну и Minecraft написан на Java например, а популярнейший игровой движок Unity3D использует C# в качестве основного языка программирования, а C# очень похож на Java (свой сборщик мусора, байткод, нет указателей...).
Резюме, что язык программирования под проект надо выбирать не из его ТТХ, а из удобства и качества разработки на нём. Соответственно, под Windows/.NET идеальным будет F# для основной логики, например.
Единственная причина в том, что плюсы позволяют очень качественно контролировать работу с памятью.
В Java же единственная реальная проблема в этом плане фактически в том, что в JVM по дефолту есть сборщик мусора, который автоматически очищает память. И для обычного софта это вполне приемлемо, и работает хорошо, но в играх динамически создаётся и уничтожается множество довольно больших объектов. Их детальное описание (ну, вертексы, текстурные координаты...) хранится в больших нативных буферах, которые непосредственно в программе представлены маленькими объектами, содержащими лишь ссылку на эти буферы. И вот сермяга в том, что сборщик мусора не знает, сколько байт реально занимает родной буфер, так как он находится вне зоны компетенции сборщика. Он видит лишь маленький объект, думает, что в памяти всего лишь несколько таких маленьких объектов, и поэтому не вычищает их. А в результате получается OutOfMemoryException, потому что её всю забили здоровенные буферы.
Но есть способы обойти эту проблему (например, созданием специализированных JVM), и для многих задач Java даже превосходит C++. Так, многие игры, написанные на C++, часто падают :) ага, из-за нарушения доступа к памяти, а в Java этого не может произойти в принципе, потому что в ней нету арифметики указателей. Время выполнения благодаря JIT-компилятору иногда даже превосходит время выполнения программ на C++. Ну вот довольно старые тесты, с тех пор Java ещё больше ускорилась: https://stackoverflow.com/questions/145110/c-performance-vs-java-c
Ну и Minecraft написан на Java например, а популярнейший игровой движок Unity3D использует C# в качестве основного языка программирования, а C# очень похож на Java (свой сборщик мусора, байткод, нет указателей...).
Резюме, что язык программирования под проект надо выбирать не из его ТТХ, а из удобства и качества разработки на нём. Соответственно, под Windows/.NET идеальным будет F# для основной логики, например.
Часто спрашивают что почитать при подготовке к собеседованиям, ну прежде всего рекомендую вечную классику "Карьера программиста. Как устроиться на работу в Google, Microsoft или другую ведущую IT-компанию" ("Cracking the Coding Interview: 150 Programming Interview Questions and Answers") Гейл Макдауэлл/Лакман.
Это действительно хорошая книга, действительно очень рекомендую её, это одна из тех книг, которые вам просто необходимо изучить, если вы собираетесь проходить собеседование в программисты.
Потому что знание того, как решать подобные алгоритмические проблемы и как использовать структуры данных и алгоритмы эффективно, действительно очень важно для прохождения собеседований (и да, это может быть совершенно неважно в реальной работе, ну просто вот так устроен мир). Понимаю, что вам не нравится идея писать сложный код на собеседованиях, вам может не понравиться тот факт, что и Яндекс, и Сбер, и Мэйлру, и Microsoft, и Google, и Apple, и многие другие крупные компании используют подобные задачи на интервью, но это не меняет того факта, что вам нужно очень хорошо знать и уметь решать подобные задачи. Если вы хотите пробиться в такие компании, как Яндекс или Google, Мэйлру или Microsoft, вам придется выучить все эти вещи, так что вы можете просто взять эту книгу и изучить на практике то, что в ней рассказано.
И в целом в ней даётся много хороших советов. Начинается она с разбора некоторых софт-скиллов, которые полезны в плане того, как вести себя себя на собеседовании, какие бывают виды интервью, как оформить своё резюме и т. п. Затем в ней начинаются непосредственно технические темы, так что она охватывает практически всё, что я могу представить, что вам нужно знать -- от структур данных до различных типов алгоритмов, основных их не так уж и много на самом деле, хотя это всё несколько поверхностно, так как изложено слишком (иногда чрезмерно) компактно. Но зато как только вы узнаете, как решать подобные задачи, тогда вы станете уверены в себе и сможете пойти на собеседование и решить такие или подобные задачи, независимо от того, что они предложат вам, потому что существует очень много вариаций фактически одних и тех же типов данных и задач.
Я определенно рекомендую пройтись по всей книге, в ней собрано много типовых задачек. Конечно, правильный способ сделать это -- писать код решения всех задач по мере того, как вы продвигаетесь по книге вперёд. И если вы действительно сделаете это, то получите реальную способность успешно пройти техническое интервью по программированию. Так что эту книгу я очень рекомендую просто из-за этого.
Конечно, вам потребуется определённое время, чтобы пройти все задачи в книге, но почти гарантированно вы сможете проходить интервью, связанные с алгоритмическими темами и навыками решения задачек. Такие интервью характерны прежде всего для крупных компаний МЯСО/FAANG, потому что чем примитивнее компания, тем больше в ней требуется знания всякой технической фигни и веб-фреймворков, и тем менее ценится в ней абстрактное мышление, так как заниматься придётся в основном шаблонной реализацией довольно простых и скучных фич.
Так что эти усилия стоят того, если вы серьёзно настроены получить работу в Яндексе или Сбере или Google, или IBM, Facebook ...
Непосредственно перед каждым таким собеседованием пробежитесь по книге очередной раз, освежите знания, это отлично окупится в итоге.
Это действительно хорошая книга, действительно очень рекомендую её, это одна из тех книг, которые вам просто необходимо изучить, если вы собираетесь проходить собеседование в программисты.
Потому что знание того, как решать подобные алгоритмические проблемы и как использовать структуры данных и алгоритмы эффективно, действительно очень важно для прохождения собеседований (и да, это может быть совершенно неважно в реальной работе, ну просто вот так устроен мир). Понимаю, что вам не нравится идея писать сложный код на собеседованиях, вам может не понравиться тот факт, что и Яндекс, и Сбер, и Мэйлру, и Microsoft, и Google, и Apple, и многие другие крупные компании используют подобные задачи на интервью, но это не меняет того факта, что вам нужно очень хорошо знать и уметь решать подобные задачи. Если вы хотите пробиться в такие компании, как Яндекс или Google, Мэйлру или Microsoft, вам придется выучить все эти вещи, так что вы можете просто взять эту книгу и изучить на практике то, что в ней рассказано.
И в целом в ней даётся много хороших советов. Начинается она с разбора некоторых софт-скиллов, которые полезны в плане того, как вести себя себя на собеседовании, какие бывают виды интервью, как оформить своё резюме и т. п. Затем в ней начинаются непосредственно технические темы, так что она охватывает практически всё, что я могу представить, что вам нужно знать -- от структур данных до различных типов алгоритмов, основных их не так уж и много на самом деле, хотя это всё несколько поверхностно, так как изложено слишком (иногда чрезмерно) компактно. Но зато как только вы узнаете, как решать подобные задачи, тогда вы станете уверены в себе и сможете пойти на собеседование и решить такие или подобные задачи, независимо от того, что они предложат вам, потому что существует очень много вариаций фактически одних и тех же типов данных и задач.
Я определенно рекомендую пройтись по всей книге, в ней собрано много типовых задачек. Конечно, правильный способ сделать это -- писать код решения всех задач по мере того, как вы продвигаетесь по книге вперёд. И если вы действительно сделаете это, то получите реальную способность успешно пройти техническое интервью по программированию. Так что эту книгу я очень рекомендую просто из-за этого.
Конечно, вам потребуется определённое время, чтобы пройти все задачи в книге, но почти гарантированно вы сможете проходить интервью, связанные с алгоритмическими темами и навыками решения задачек. Такие интервью характерны прежде всего для крупных компаний МЯСО/FAANG, потому что чем примитивнее компания, тем больше в ней требуется знания всякой технической фигни и веб-фреймворков, и тем менее ценится в ней абстрактное мышление, так как заниматься придётся в основном шаблонной реализацией довольно простых и скучных фич.
Так что эти усилия стоят того, если вы серьёзно настроены получить работу в Яндексе или Сбере или Google, или IBM, Facebook ...
Непосредственно перед каждым таким собеседованием пробежитесь по книге очередной раз, освежите знания, это отлично окупится в итоге.
Самый главный недостаток любого разработчика -- это неумение качественно протестировать свой собственный код. Это самая худшая, стратегическая ошибка, которую только разработчик может сделать, в частности потому, что в программной инженерии она относится к классу ошибок, которые приносят проекту максимальный стратегический вред.
О чём думает тимлид в течение дня?
- Сколько тикетов за сегодня закроет Олег?
О чём думает Олег в течение дня? (т.н. "обезьяний ум")
- Приехать вовремя на работу к митингу... Как бы смыться с работы пораньше? Как там детишки дома? Когда там у Ленки день рождения? Надо бы вечером на велосипеде покататься... Новенький за соседним столом какой-то странный... Надо бы в обед заскочить в магаз за покупками, едой... Когда кофемашину сменят? Пора детально продумывать маршрут на зимний отпуск и уже заказывать билеты... Интересно, кто у Оксаны новый парень? Надо бы за интернет и телефон заплатить... Пора продумывать планы на выходные...
- Сколько тикетов за сегодня закроет Олег?
О чём думает Олег в течение дня? (т.н. "обезьяний ум")
- Приехать вовремя на работу к митингу... Как бы смыться с работы пораньше? Как там детишки дома? Когда там у Ленки день рождения? Надо бы вечером на велосипеде покататься... Новенький за соседним столом какой-то странный... Надо бы в обед заскочить в магаз за покупками, едой... Когда кофемашину сменят? Пора детально продумывать маршрут на зимний отпуск и уже заказывать билеты... Интересно, кто у Оксаны новый парень? Надо бы за интернет и телефон заплатить... Пора продумывать планы на выходные...
Смешно: в Кембридже формализовали модель параллельной работы памяти в С++ (!) -- описали семантику многопоточных программ и доказали в Isabelle/HOL корректность процесса компиляции
https://www.cl.cam.ac.uk/~pes20/cpp/popl085ap-sewell.pdf
А потом оказалось, что в стандарте C++20 она была внезапно переделана более чем наполовину, и теперь надо начинать всё с нуля.
Вообще, поразительно конечно, какой бардак творится в мировом IT даже на топ-уровне ведущих комитетов по стандартизации :)
https://www.cl.cam.ac.uk/~pes20/cpp/popl085ap-sewell.pdf
А потом оказалось, что в стандарте C++20 она была внезапно переделана более чем наполовину, и теперь надо начинать всё с нуля.
Вообще, поразительно конечно, какой бардак творится в мировом IT даже на топ-уровне ведущих комитетов по стандартизации :)
Судьба неайтишника 😂😂😂
"Мало работать на 100 процентов, надо, чтобы твою работу замечали. Это не значит, что нужно безудержно заниматься самопиаром, но важно хотя бы просто общаться с коллегами, налаживать связи. Удаленка этому очень помешала, на удаленке сложно себя продвинуть. Офис превращается в привилегию, люди будут сражаться за то, чтобы в него попасть , а удаленка станет уделом для тех, кто находится в карьере на периферии"
Офис -- это оказывается привилегия. А удалёнка оказывается мешает развивать нетворкинг.
Немало знакомых программистов, c удалёнки, которая и не привилегия и не периферия, а просто норм формат работы, любят периодически заезжать в офис в совершенно свободном режиме, чтобы спокойно пообщаться за кофе в приятном коллективе вживую.
сражаться чтобы попасть в офис == унижаться чтобы попасть в офис
"Мало работать на 100 процентов, надо, чтобы твою работу замечали. Это не значит, что нужно безудержно заниматься самопиаром, но важно хотя бы просто общаться с коллегами, налаживать связи. Удаленка этому очень помешала, на удаленке сложно себя продвинуть. Офис превращается в привилегию, люди будут сражаться за то, чтобы в него попасть , а удаленка станет уделом для тех, кто находится в карьере на периферии"
Офис -- это оказывается привилегия. А удалёнка оказывается мешает развивать нетворкинг.
Немало знакомых программистов, c удалёнки, которая и не привилегия и не периферия, а просто норм формат работы, любят периодически заезжать в офис в совершенно свободном режиме, чтобы спокойно пообщаться за кофе в приятном коллективе вживую.
сражаться чтобы попасть в офис == унижаться чтобы попасть в офис
Некоторые люди боятся собеседований потому, что опасаются, что "под давлением" будут делать больше ошибок.
Но разве это давление? Это детский сад.
Вот например случай, как 17-летняя (!) девушка после полётов с инструктором отправилась в тренировочный полёт в одиночку, и вдруг диспетчер сообщает: "От вашего самолёта отвалилась правая часть. Скажите, что вы собираетесь делать?" (!). Мэгги что-то отвечает, вроде "надо посадить самолёт", не разбираюсь в авиатехнике, и диспетчер уточняет: "У вас отвалилась именно та штуковина, которая необходима для посадки самолёта (вроде, колесо?). Сообщите, что вы собираетесь делать?".
https://www.youtube.com/watch?v=B229-KLudTo
Вот это действительно давление.
Но Мэгги оставалась предельно спокойной и сконцентрированной до самого конца, действовала очень хладнокровно, мастерски применяла все изученные навыки, и в итоге успешно посадила разваливающийся в воздухе самолёт!
И то, что её не убило, безусловно, сделало её существеннее сильнее.
На 1:30 она начала волноваться, но когда потом спустя минуту подключился её инструктор, опытный пилот-ветеран, который начал подсказывать ей, как надо приземлиться, она успокоилась и поверила, что всё будет хорошо.
Мэгги уже знала конечно, как управлять самолетом, поэтому ей не нужны были детальные инструкции, она сразу перешла к тактике посадки поломанного самолета.
Намного, намного легче преодолевать сложные ситуации, вызовы, когда вы уже хорошо знаете основы, как следует проверили их практикой, и можете сразу перейти к тактике, которая поможет вам уверенно справиться с ситуацией. Например, если справляетесь, пусть и трудно, на медленном мышлении, с задачками по алгоритмам -- вспомните, как легко уже вам на текущем уровне решать более простые задачки. Если на собеседовании будут просить закодить поиск подстроки в строке или нахождение второго максимального в массиве, вы будете абсолютно спокойны, потому что точно знаете, что решите это без проблем. Ну вот точно также надо просто и далее повышать своё мастерство кодинга, на самом деле, потолок от уровня алгоритмов тут уже очень близко :)
А для учителя, инструктора, ментора, тренера самое приятное -- это видеть, как ученик идеально выполняет реально сложное задание. Именно так и понимаешь, что сам хорошо выполнил свою работу по обучению.
Но разве это давление? Это детский сад.
Вот например случай, как 17-летняя (!) девушка после полётов с инструктором отправилась в тренировочный полёт в одиночку, и вдруг диспетчер сообщает: "От вашего самолёта отвалилась правая часть. Скажите, что вы собираетесь делать?" (!). Мэгги что-то отвечает, вроде "надо посадить самолёт", не разбираюсь в авиатехнике, и диспетчер уточняет: "У вас отвалилась именно та штуковина, которая необходима для посадки самолёта (вроде, колесо?). Сообщите, что вы собираетесь делать?".
https://www.youtube.com/watch?v=B229-KLudTo
Вот это действительно давление.
Но Мэгги оставалась предельно спокойной и сконцентрированной до самого конца, действовала очень хладнокровно, мастерски применяла все изученные навыки, и в итоге успешно посадила разваливающийся в воздухе самолёт!
И то, что её не убило, безусловно, сделало её существеннее сильнее.
На 1:30 она начала волноваться, но когда потом спустя минуту подключился её инструктор, опытный пилот-ветеран, который начал подсказывать ей, как надо приземлиться, она успокоилась и поверила, что всё будет хорошо.
Мэгги уже знала конечно, как управлять самолетом, поэтому ей не нужны были детальные инструкции, она сразу перешла к тактике посадки поломанного самолета.
Намного, намного легче преодолевать сложные ситуации, вызовы, когда вы уже хорошо знаете основы, как следует проверили их практикой, и можете сразу перейти к тактике, которая поможет вам уверенно справиться с ситуацией. Например, если справляетесь, пусть и трудно, на медленном мышлении, с задачками по алгоритмам -- вспомните, как легко уже вам на текущем уровне решать более простые задачки. Если на собеседовании будут просить закодить поиск подстроки в строке или нахождение второго максимального в массиве, вы будете абсолютно спокойны, потому что точно знаете, что решите это без проблем. Ну вот точно также надо просто и далее повышать своё мастерство кодинга, на самом деле, потолок от уровня алгоритмов тут уже очень близко :)
А для учителя, инструктора, ментора, тренера самое приятное -- это видеть, как ученик идеально выполняет реально сложное задание. Именно так и понимаешь, что сам хорошо выполнил свою работу по обучению.
Хорошая заметка, что такое сильный программист с т.зр. СЕО, у которого работает 50 разработчиков. Брали парня на Android-сеньора, при этом он также был экспертом в node.js и в облачных технологиях, на гитхабе три полноценных проекта, и одна из его программ в гугл маркете была скачена 100,000 раз без какой-либо рекламы. А на вопрос "ваше хобби?" он ответил -- спортивное программирование :) в частности на codeforces.com
И вдобавок у него были отличные софт-скиллы -- он например любил помогать другим.
И вдобавок у него были отличные софт-скиллы -- он например любил помогать другим.
Наблюдаю, как сеньоры регулярно проваливают собеседования за собеседованием.
Они приходят такие, просидевшие 5-10 лет на одном месте, самодовольные (официально в должности "старший инженер-программист"), с внушительным многолетним опытом.
"Я работаю в крупной компании! Я заслуженный сеньор! Я буду тренироваться на этих ваших крошечных стартапах, чтобы попрактиковаться в прохождении интервью".
...
-- Спасибо, что пришли сегодня, Олег! Расскажите пожалуйста нам о проекте, которым вы гордитесь?
Минута молчания. Горжусь? Эммм...
-- Ну, понимаете, был один проект, в котором я участвовал... мы разработали бубулятор...
-- Отлично! Бубуляторы важны для основной деятельности вашей компании?
-- Ну.... думаю, да... ммм..
-- А почему вы его создали?
-- Ну, тимлид сказал мне... В общем, мы создали этот бубулятор, который использовал джавалайзер, и мы...
-- Джавалайзер? Странный выбор. Как же так получилось?
-- Ну, тимлид прочитал статью на хабре, в которой говорилось, что Шмандекс использует джавалайзеры...
-- Понятно. И ваша компания размером с Шмандекс?
-- Нет, примерно в тысячу раз меньше. Кроме того, бубулятор предназначен для крошечной доли наших пользователей...
-- Хорошо, давайте двигаться дальше, Олег. Что вы делали в этом проекте?
-- Я помогал.
-- Как помогал?
-- Ну, я был вовлечен в это всё...
-- Что именно вы делали, Олег? Писали код? Проектировали классы? Решили сложную архитектурную проблему? Может быть, в свободное время написали промотрщик котиков?
Неловкое молчание.
...
Это не сеньор, а даже до стажёра не дотягивает. Не может внятно рассказать о своем вкладе, не думает о последствиях своей деятельности для всей организации, не хватает элементарного понимания, как делаются правильные технологические выборы. Ну штош...
Вот почему годами стратегически развиваю курс карьеры, где уже около 70 материалов с разбором всех ключевых моментов.
Настоящий инженерный талант выходит далеко за рамки технических навыков. Речь идет о мудрости, о проницательности, о боевых шрамах.
Это мышление взрослого.
Они приходят такие, просидевшие 5-10 лет на одном месте, самодовольные (официально в должности "старший инженер-программист"), с внушительным многолетним опытом.
"Я работаю в крупной компании! Я заслуженный сеньор! Я буду тренироваться на этих ваших крошечных стартапах, чтобы попрактиковаться в прохождении интервью".
...
-- Спасибо, что пришли сегодня, Олег! Расскажите пожалуйста нам о проекте, которым вы гордитесь?
Минута молчания. Горжусь? Эммм...
-- Ну, понимаете, был один проект, в котором я участвовал... мы разработали бубулятор...
-- Отлично! Бубуляторы важны для основной деятельности вашей компании?
-- Ну.... думаю, да... ммм..
-- А почему вы его создали?
-- Ну, тимлид сказал мне... В общем, мы создали этот бубулятор, который использовал джавалайзер, и мы...
-- Джавалайзер? Странный выбор. Как же так получилось?
-- Ну, тимлид прочитал статью на хабре, в которой говорилось, что Шмандекс использует джавалайзеры...
-- Понятно. И ваша компания размером с Шмандекс?
-- Нет, примерно в тысячу раз меньше. Кроме того, бубулятор предназначен для крошечной доли наших пользователей...
-- Хорошо, давайте двигаться дальше, Олег. Что вы делали в этом проекте?
-- Я помогал.
-- Как помогал?
-- Ну, я был вовлечен в это всё...
-- Что именно вы делали, Олег? Писали код? Проектировали классы? Решили сложную архитектурную проблему? Может быть, в свободное время написали промотрщик котиков?
Неловкое молчание.
...
Это не сеньор, а даже до стажёра не дотягивает. Не может внятно рассказать о своем вкладе, не думает о последствиях своей деятельности для всей организации, не хватает элементарного понимания, как делаются правильные технологические выборы. Ну штош...
Вот почему годами стратегически развиваю курс карьеры, где уже около 70 материалов с разбором всех ключевых моментов.
Настоящий инженерный талант выходит далеко за рамки технических навыков. Речь идет о мудрости, о проницательности, о боевых шрамах.
Это мышление взрослого.
Что бы вы ни готовили, если навалите в кастрюлю слишком много некоторых ингредиентов, блюдо не получится вкусным.
Очень немногие проекты масштабируются "естественно".
Самый трудный момент для прекращения масштабирования проекта -- это момент, когда проект работает лучше всего, и начинаешь планировать его эпическое расширение кучей новых фич.
Именно в этот момент нам как раз нужно набраться смелости и перестать механически делать проект ещё больше.
Очень немногие проекты масштабируются "естественно".
Самый трудный момент для прекращения масштабирования проекта -- это момент, когда проект работает лучше всего, и начинаешь планировать его эпическое расширение кучей новых фич.
Именно в этот момент нам как раз нужно набраться смелости и перестать механически делать проект ещё больше.
Поразительно конечно, насколько ИТ-мэйнстрим далёк от понимания самых элементарных принципов computer science.
Что любой язык программирования -- это прежде всего средство моделирования предметных областей, с различной степенью универсальности, и только математика и мат.логика даёт нам тут лучшие инструменты,
и соответственно, та же гомотопическая теория типов -- это самый сильный на сегодня такой инструмент моделирования.
А не эти ваши "наглядные" картиночки, "пояснительные" слайдики, диаграммки с текстами, и прочее хипстерство с нулевым формализмом...
"Types can also provide exact bounds on the number of evaluation steps and result size associated with lambda terms."
The Little Prover
Хотя этому подходу в лучших университетах учат многими десятилетиями, но сегодня уже и университетское образование в мэйнстриме не ценится ...
Что любой язык программирования -- это прежде всего средство моделирования предметных областей, с различной степенью универсальности, и только математика и мат.логика даёт нам тут лучшие инструменты,
и соответственно, та же гомотопическая теория типов -- это самый сильный на сегодня такой инструмент моделирования.
А не эти ваши "наглядные" картиночки, "пояснительные" слайдики, диаграммки с текстами, и прочее хипстерство с нулевым формализмом...
"Types can also provide exact bounds on the number of evaluation steps and result size associated with lambda terms."
The Little Prover
Хотя этому подходу в лучших университетах учат многими десятилетиями, но сегодня уже и университетское образование в мэйнстриме не ценится ...
Джун-Книга.
Глава 1
Я писал код. Я сделал ошибку в коде. Прод упал. Я не виноват. Мне никогда не стать программистом.
Глава 2
Я писал код. Я сделал ту же ошибку в коде, но сделал вид, что не замечаю её. Прод упал. Опять. Я не могу поверить, что прод снова упал из-за той же самой ошибки! Но я опять не виноват. Мне придётся долго становиться программистом.
Глава 3
Я писал код. Я сделал ту же ошибку в коде. Я видел её, и прод снова упал (это уже его привычка!), но я чётко заметил её. Я знаю, в чём она заключается. Я признаю, что это моя вина. Я немедленно покрыл ошибочный код тестами.
Глава 4
Я писал код. Я сделал ту же ошибку в коде. Я написал тесты, и ошибка НЕ ПОПАЛА в прод.
Глава 5
Я писал код. Я НЕ СДЕЛАЛ той ошибки.
Глава 1
Я писал код. Я сделал ошибку в коде. Прод упал. Я не виноват. Мне никогда не стать программистом.
Глава 2
Я писал код. Я сделал ту же ошибку в коде, но сделал вид, что не замечаю её. Прод упал. Опять. Я не могу поверить, что прод снова упал из-за той же самой ошибки! Но я опять не виноват. Мне придётся долго становиться программистом.
Глава 3
Я писал код. Я сделал ту же ошибку в коде. Я видел её, и прод снова упал (это уже его привычка!), но я чётко заметил её. Я знаю, в чём она заключается. Я признаю, что это моя вина. Я немедленно покрыл ошибочный код тестами.
Глава 4
Я писал код. Я сделал ту же ошибку в коде. Я написал тесты, и ошибка НЕ ПОПАЛА в прод.
Глава 5
Я писал код. Я НЕ СДЕЛАЛ той ошибки.
15-20 лет назад, если ты умел пользоваться компьютером, а уж тем более интернетом, большинство окружающих считало тебя волшебником.
Вопрос не в том, станем ли мы продуктивно использовать компьютерные технологии сегодняшнего поколения; вопрос лишь в том, как скоро нас принудит к этому жизнь?
Мы можем выбирать: жить позади колокола нормального распределения, или впереди него. Оказывается, есть значительное вознаграждение, если преодолеваешь дискомфорт и становишься (намного) лучше во всех тех сильных технологиях, которые внезапно стали свободно доступны -- будь то программирование или онлайн-обучение, датасайнс или финансы, и т. п.
Что, если, вместо того, чтобы сопротивляться State of the Art до тех пор, пока у нас не останется никакого выбора, мы наоборот решим стать первопроходцами?
P. S. Это верно и для любых других наших навыков, и хард- и софт-. Например, уже сейчас про профилю "киберспорт" выдаются сотни вакансий и будет только веселее. Бумерам действительно это сложно принять :) но это факт.
Вопрос не в том, станем ли мы продуктивно использовать компьютерные технологии сегодняшнего поколения; вопрос лишь в том, как скоро нас принудит к этому жизнь?
Мы можем выбирать: жить позади колокола нормального распределения, или впереди него. Оказывается, есть значительное вознаграждение, если преодолеваешь дискомфорт и становишься (намного) лучше во всех тех сильных технологиях, которые внезапно стали свободно доступны -- будь то программирование или онлайн-обучение, датасайнс или финансы, и т. п.
Что, если, вместо того, чтобы сопротивляться State of the Art до тех пор, пока у нас не останется никакого выбора, мы наоборот решим стать первопроходцами?
P. S. Это верно и для любых других наших навыков, и хард- и софт-. Например, уже сейчас про профилю "киберспорт" выдаются сотни вакансий и будет только веселее. Бумерам действительно это сложно принять :) но это факт.