Справочник по собеседованиям для тех программистов, которые их не понимают


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

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

    Собеседование в мировую it компанию


    Пример Яндекс, Гугл, Майкрософт, Амазон
    Количество кандидатов сотни (тысячи)
    Тип собеседования вступление в армию
    Ожидаемые вопросы алгоритмические задачи

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

    Потому что это:

    • Стандартизировано. Все задачи известны, их много, все решения заранее не заучишь, требуется хорошая теоретическая база.
    • Унифицировано. Все интервью можно проводить одинаково: 40 минут на решение задачи кандидатом, разбор и оценка его типичного решения.
    • Просто и эффективно. Поверьте, если бы можно было как-то иначе найти хорошего кандидата из сотни посредственных, то крупный бизнес бы искал по-другому.

    Резюмируем


    «Вас много, а я одна!» — кричит нам крупная контора, которую мы дружно закидываем своими резюме. Нам дают сложный, скучный и бесполезный в работе фильтр из задачек. Кто-то проходит, а кто-то — нет (я — нет).

    Хотите, чтобы отбор был без задачек? Ну… Давайте сговоримся и будем подавать от всех нас лишь одно резюме в месяц, уверен, тогда уж точно найдется время спросить у кандидата про его прошлые проекты. :)

    Собеседование в аутсорсную компанию


    Пример Епам, Люксофт
    Количество кандидатов десятки
    Тип собеседования отбор дойной коровы
    Ожидаемые вопросы справочные материалы и чуть-чуть задачек

    Давайте сразу проясним: цель любой аутсорсной компании — продать ваше время разработчика задорого, а потом забирать себе часть вашей зарплаты (половину). Это основная бизнес модель.

    А значит:

    • Вы должны выглядеть круто для продажи.
    • Вас можно легко перекидывать с проекта на проект.

    Отсюда и вытекают вопросы на собеседованиях. Вас будут гонять в хвост и в гриву по всем технологиям, которые вы указали в резюме. Потому что от этого зависит, как быстро вас можно будет пристроить к новому заказчику, какие сладкие эпитеты ему можно будет рассказать про вас, какие именно сокращения технологий можно будет вписать в ваше внутреннее резюме, чтобы оно выглядело «пожирнее» (Spring, EJB, Node.js, Kafka, Redis, Mongo, MySql, JMS, MMQ, UPR, ABCDEFG, ну вы поняли).

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

    Резюмируем


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

    Собеседование в небольшую компанию


    Пример смотри вакансии в своем городе
    Количество кандидатов единицы (десятки)
    Тип собеседования отбор для дела (или души)
    Ожидаемые вопросы всегда по-разному

    В небольших и средних компаниях, которые выпускают свой продукт или занимаются автоматизацией на заказ, обычно нет общих для всех правил отбора новых кандидатов.
    Всё зависит от конкретных людей, проблем, фазы луны. Где-то вас попросят решать задачки (потому что так делает Гугл), где-то будет тестирование на знание всех методов библиотек (потому что так делает Люксофт). А где-то вам предложат разобрать ваш код, поспрашивают о ваших предыдущих проектах, и вообще, вы мило побеседуете обо всем на свете на 2 часа, а потом эти ребята станут вашими лучшими коллегами на много лет вперед (слезы умиления).

    Резюмируем


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

    Спасибо за потраченное на статью время и удачных собеседований, коллеги!
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 335

      +7
      Про Люксофт и.т.п. — все сильно упрощено. Бывает и не так, и совсем не так. Я как работал в первом, так и нанимал из второго на проекты. Но как ориентир чего следует ждать — наверное годится.
        +5
        для меня в Люксофте основным перпятствием был английский язык. С письменным у меня хорошо, но проверяли устный по телефону на бытовые темы (проверяли не программисты, а преподавательницы английского). А по телефону, с низким качеством звука, не очень-то разберешь, о чем спрашивают.
          +25
          ну как бы и в реальной жизни довольно много общения будет по каналам связи, так что обстановка приближена к боевой
            +6
            Это все решается на раз два, вам нужна неделя-две практики и воспринимать на слух станет куда проще. (если компания международная то внутри нее наговорить не проблема) Кстати это вам никак не поможет если у вас не было опыта разговора с индусами или англичанами, с ними еще плюс столько же.
              +1
              Ищутся онлайн курсы, где лектор — индус и воспринимать становится значительно проще.
              Вот то, что с английским делают французы, это действительно боль.
                +1
                Большинство англоязычных бесплатных курсов по BigData читают индусы, причём с разными акцентами — отличная практика (практически всегда — с субдитрами на английском).
                Заодно и расширить границы познания.
                  +1

                  Испанский и китайский варианты английского, имхо, ещё грустнее.

                    0
                    Испанский не слышал, но японский вариант куда хуже китайского, вживую довелось пообщаться с японцем и китайцем, с китайцем мы довольно быстро нашли общий язык и примерно в равной степени не понимали английский друг друга, а вот что говорит японец я ну никак не мог понять, сказывается их привычка перекладывать английский на звуки японского алфавита.
                      0
                      Они серьезно говорят что-то вроде «Са-ба», или это из разряда городских айтишных баек?
                        +2
                        Да, server — сарва (ну или са-ва, да), database — дэтабейсу, client — кураянт и т.д. и т.п. Еще сильно мешало то, что начинаешь переспрашивать — входит в ступор, но это может особенность конкретного японца :)
                          0
                          если они говорят на японском — да, так слова заимствуются.
                            +3
                            Если два класса японцев: те, которые общались с нэйтив спикерами, и те которые не общались.

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

                            И при этом английские слова они любят… но странною любовью. Вот возьмите To Love-Ru. Что это вообще может значить? А это, оказывается «Trouble».

                            Вот для вас «To Love-Ru» и «Trouble» похожи? Хотя бы отдалённо? А для японца — они вообще одинаково читаются…

                            Но это если они в японской фирме работают. Если они найтив спикеров слышат (работают в Google или Microsoft), то уже через год говорят почти без акцента.
                            0

                            Все японцы, с которыми я общался, принципиально говорили только на японском. Возможно. повезло.

                          0
                          del
                            0

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

                            –1
                            Индусы вполне нормально говорят. Самое сложное было с итальянцами, т.к. они и на английском говорят очень быстро и ты просто не успеваешь осознавать что он говорит. Помогает только полное отключение мозга и полное забывание всех остальных языков, ибо на это уже времени не остается.
                              0
                              Индусы — нормально? Это шутка или издевательство?
                                +1
                                Захотелось поговорить с итальянцами, на фоне которых индусы говорят нормально.
                                Или имеется в виду
                                это?
                                для лиц 18+, понимающих английский

                                  0
                                  Примерно такое
                                  0
                                  Это привычка
                            +1
                            а меня как-то собеседовала по телефону рекрутер из Великобритании. А у них как будто совсем другой телефонный кодек используется и звук в телефоне звучит очень непривычно.
                            В общем, не взяли меня туда.
                            +3
                            Для Люксофта собеседование велось (по состоянию на два года назад, как сейчас обстоят дела — не знаю) на конкретный проект его менеджером и тимлидом (или старшим специалистом). Технические интервью были по технологиям, использующимся на проекте, и о том, насколько кандидат ими владеет. Спрашивали о конкретных задачах, которые решал кандидат на прошлых проектах. Впрочем, какие вопросы задавать решал интервьюер. На некоторых проектах могли и по теории погонять, и задачки позадавать.

                            Что важно — в компаниях такого рода собеседование ведется руководством проекта и на конкретный проект. Переброска между проектами, о котором здесь говорилось (т.н. Internal Mobility) по сути мало отличается от приема на работу внешнего кандидата: те же собеседования и с теми же людьми.
                              +2
                              Я примерно это же и имел в виду. Просто мой опыт с Люксофтом был в 2005, поэтому ссылаться на него сегодня мало смысла. Но суть в том же — брали на проект, и только на него, и ни в коей мере не для того, чтобы куда-то продавать.
                              0
                              Зависит:
                              1. от проекта (нужен конкретный спец, не срочно, а может и не нужен в данный момент времени, ищут про запас)
                              2. от ситуации (человек нужен вчера, нужно взять хоть кого-то но уже)

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

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

                              Ну и по собеседованию, маленький совет: берут не за то что вы умеете, а за то что вы рассказываете. То же самое и с зарплатой, сможете продать себя подороже, ну и молодец, базар есть базар, ничего личного. Для этого только нужно нагуглить набор типовых вопросов-ответов и вызубрить их наизусть. Конечно, желательно чтобы вы были в теме, то есть если собеседуемся на С++ то желательно иметь хотя бы пол-года опыта в этом самом С++. Дальше — просто, сперва записываемся на собеседования в совершенно неинтересные конторы. Первую неделю вам нужно пройти как минимум 10 собеседований. Цель: не попасть в собеседующую контору, а отточить свой разговорный талант и уверенность в себе плюс иногда задают нетиповые вопросы, и у вас будет шанс заучить ответы и на эти вопросы. Иногда доходит до смешного: ошибочный ответ на вопрос считается правильным. Не обращайте внимания на подобные казусы, вы все равно это все забудете через 2 дня на новом месте. После недели тестовых собеседований, можно переходить на продакшен. Начинаем пробовать конторы, которые нам интересны. Кстати хочу заранее предупредить: известные конторы часто выглядят привлекательно снаружи и смертельно скучно внутри. В любом случае вы это узнаете только влившись в коллектив. И возвращаясь к Люксу, в первый месяц вы можете не работать, от слова совсем. У вас будут всякие корпоративные тренинги и «все вот это вот». Если не нравится, то как вариант тяните резину, получайте зарплату и берегите себя для новой работы. А там по ситуации. Да, и кстати, в некоторых проектах английский не нужен. Совсем.

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

                              Ну и чтобы закончить на веселой ноте: нормальные адекватные конторы с интересными задачами и хорошим коллективом встречаются хоть и не часто. Хотя программирование превратилось в ремесло (а когда-то было искусством) это не значит что все так печально. Когда я в последний раз устраивался на реально интересный проект, мне почти не задавали технических вопросов и не спрашивали про алгоритмы. Мы просто поговорили с прожект менеджером за жизнь, и меня взяли на проект. Хотя контора была ноунейм, но проект пилили реально крутой и выкладывались на все 100. До сих пор есть чем похвастаться в портофолио.
                              +9
                              с завидной периодичностью возникают посты от возмущенных программистов, которые справедливо (наверное) негодуют, почему на собеседовании никто не спросил про их прошлые проекты, не посмотрел их код,

                              Код который программист выложит для просмотра работодателем, может быть написан кем угодно. И даже если написан самим кандидатом то может в корне отличатся от того что тот заливал в прод каждый день.
                              … но задавал шаблонные справочные вопросы или заставлял решать алгоритмические задачи, которые, скорее всего (в 99%), не будут применяться на вакантной работе.

                              Я вот очень долго над этим думал и пришёл к выводу что тут всё логично. Вопросы по алгоритмам задаются не от хорошей жизни. Работодатель может не знать того фреймворка с которым работал кандидат. Потом, у работодателя скорее всего другой фреймворк. Получается что работодатель не может правильно оценить кандидата в немного другой сфере, которую он не знает. А кандидат скорее всего не ответит на вопросы о фреймворке работодателя. Итого, рассказывать\спрашивать что то о вещах из повседневной работы рискованно. Можно не найти общий язык.
                              Поэтому, среди возможных остаются вопросы по тонкостям языков программирования и по теоретической базе, которая должна быть у любого кто серьёзно изучал программирование. А те кто изучал несерьёзно нафиг не нужны. ФормоШлёпов и своих обычно хватает.
                              Большинство того что спрашивают на собесах это не rocket science, а умещается всего в 2-х книгах на темы: паттерны ООП, алгоритмы. Надо всего лишь осилить две книги, чтобы пройти 60-70% собеседований. И это не обязательно должны быть самые сложные книги в своём роде.
                                +22
                                Код который программист выложит для просмотра работодателем, может быть написан кем угодно.

                                Да ладно? Три уточняющих вопроса на собственно собеседовании прояснят это за 60 секунд.


                                И даже если написан самим кандидатом то может в корне отличатся от того что тот заливал в прод каждый день.

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


                                Работодатель может не знать того фреймворка с которым работал кандидат.

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


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

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

                                  +2
                                  Я не представляю себе фреймворк (да, даже язык, если честно), на котором я не смог бы разобрать и оценить код, предоставленный кандидатом, которого я собеседую.

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

                                  Было бы неплохо если все они будут знать сложность алгоритмов. Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.
                                    +21
                                    Было бы неплохо если все они будут знать сложность алгоритмов. Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.

                                    Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело, но напишу еще раз тут: для фронтэндера, например, вопрос знания сложности алгоритмов в лучшем случае примерно третий по важности, и на собеседовании особо не значим. Почему? Потому что высокая алгоритмическая производительность на фронтэнде иногда нужна, но весьма редко; а вот знать, как браузер грузит ресурсы и рендерит страницу — нужно практически для любого реального проекта. Быстродействие будет определяться именно этими двумя вещами, а не тем, что вы где-то там внутри дуболомно изобразили O(n!), вот только n всё равно выше десятка не вырастет даже в теории.

                                    ЗЫ: Я, к слову, уже встречался в реальности со свидетелями Священного Big O, которые ради того, чтоб нарисовать таблицу ячеек так на 10К, фигачили собственные хешмапы (дело еще было до того, как в JS появился стандартный) и прочую порнографию. Таблица при этом нещадно тормозила, потому что в big O пацаны смогли, а в оптимизацию рендера нет. И перерисовывали все 10К ячеек по любому изменению.
                                      0
                                      Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело,

                                      Я по большому счёту не утверждаю хорошо это или плохо. Мой поинт был в том что всё это вполне можно осилить даже несмотря на очевидную ненужность.
                                        +5
                                        Мой поинт был в том что всё это вполне можно осилить даже несмотря на очевидную ненужность.

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

                                          Эх, как с языка сняли!

                                            +6
                                            Лично у меня было около 20-и собеседований по теме С++ за последние три года. На английском, русском, заочно, с работодателями, заказчиками и всяким мудачьём, которое просто хотело получить консультацию бесплатно.
                                            Большинство этих собеседований успешно прошёл. И на основании этого сделал выводы, что нужно знать что бы пройти. Собсно этими выводами я и поделился выше.
                                            А вы мне пытаетесь доказать как оно должно быть. Да мне оно без разницы, как это всё должно выглядеть. Я не собираюсь изменять мир трудоустройства к лучшему и кого то персонально убеждать.
                                            Не нравится моё личное мнение — пожалуйста.
                                              +4
                                              Большинство того что спрашивают на собесах это не rocket science, а умещается всего в 2-х книгах на темы: паттерны ООП, алгоритмы. Надо всего лишь осилить две книги, чтобы пройти 60-70% собеседований. И это не обязательно должны быть самые сложные книги в своём роде.
                                              Ну вот вы написали «умещается в 2-х книгах». Можете хотя бы назвать, в КАКИХ книгах? Или это некие гепотетические книги, которые мог бы написать человек с уже имеющимся 10-летним опытом?
                                                +1
                                                Про «паттерны ООП» это одна книга — ru.wikipedia.org/wiki/Design_Patterns на худой конец можно и википедию поштудировать.
                                                Про алгоритмы и структуры данных книг много. Есть даже видеолекции на английском. Это тема сложная, поэтому попробуйте все что найдете. Самой простой книгой считается «Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих»
                                                Я бы НЕ советовал книги Седжвика по алготитмам. У него язык изложения и переводы ИМХО читаются очень плохо.
                                                В процессе изучения можно подглядывать на youtube по отдельным темам, если совсем тяжело доходит.
                                                  0

                                                  Что про Скиену скажете? Кнута я не осилил, искал лайт-версию.

                                                    0
                                                    Что про Скиену скажете?

                                                    Даже не слышал про такого. А «лайт-версий» вполне достаточно. Надо только найти, которая из них влезает в голову.
                                                      0

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

                                                  0
                                                  Вообще говоря, применительно к собеседованиям все в одной книге помещается: «Cracking the Coding Interview» Gayle Laakmann McDowell. Плюс несколько сотен задач с leetcode.com.
                                            +2
                                            свидетелями Священной Big O

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

                                            И перерисовывали все 10К ячеек по любому изменению.

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

                                            Может быть как раз изза того, что ребятки, которые ваяют классные фронты, не проходят собеседования с выкрутасами вроде: «отсортируйте пузырьком имея только каменный топор и березу», расплодилось такое дикое количество сайтов с фронтом, писанным левой пяткой пушистых тапочек.
                                              –2
                                              отсортируйте пузырьком имея только каменный топор и березу

                                              Мощно задвинул! :)

                                              Как-то я эти страхи не разделяю, о том что вот кандидата не спросим ничего по алгоритмам и он нам повесит весь прод. Если у вас код ревью в принципе нет, то так, конечно, может случиться, но в реальной жизни, с нормально поставленной разработкой такого не стоит бояться.
                                              Да и подавляющее большинство задач, которые реально решаются, не требует оптимизации. Выгрести данные запросом, протащить их по всем слоям сервиса, отмаппить их в DTO и отдать через API наружу… Обычно там все шаблонно и данных на каждом этапе немного (ибо пагинация) — сложно так налажать что-бы все ну совсем плохо стало.
                                                0
                                                Насчет «большинства задач»… Ну не знаю… Сильно зависит от предметной области. Мне в этом смысле «везло» (или везло — тут как посмотреть). Долгое время работал в промавтоматизации — там постоянно сталкиваешься с жесткими таймаутами. Не уложился — тебя послали. Разрыв соединения, реконект, перепосылка пакета и все такое прочее. Посему — будь добр извернуться, но все необходимые действия уложить в отведенное время.

                                                Сейчас работаю с высоконагруженными системами. Не сказать что 100%, но есть отдельные задачи, которые должны быть оптимизированы до предела. Иначе… Ну вот из недавнего — у одного из банков в период предновогоднего пика транзакций на пару часов перестали проходить платежи по пластику.
                                                Хорошо это для банка? Очень нехорошо. Нет, денег ни у кого не пропало. Ни копейки. Все в конечном итоге отработало, но репутационные потери налицо. Клиенты недовольны — пришел в магазин перед НГ закупиться, а расплатиться картой на кассе не можешь…
                                                И там тоже вопрос был в оптимизации одного модуля.

                                                Понятно, что такое не везде и не всегда, но есть области где налажать неоптимальным кодом можно запросто и достаточно серьезно. И этот момент приходится постоянно держать в подсознании когда что-то пишешь. Т.е. первый проход — как написать чтобы работало, второй — а можно написать чтобы работало быстрее и с меньшим ресурсопотреблением?
                                                  0
                                                  Ну, оно очевидно, что там, где жесткие таймауты и требования к быстродействию, есть смысл спрашивать и про большое О и про аппаратные заморочки всевозможные и про опыт оптимизаций…
                                                  Мой спич был о том что все это часто требуют на вакансиях, где будешь месяцами перенаправлять байты из БД в REST, с помощью фреймворков, и где даже постаравшись будет очень сложно все это сильно замедлить использованием кривого алгоритма.
                                                    +1
                                                    Согласен, что на собеседованиях часто просто тупо лупят по взятому откуда-то шаблону, абсолютно не задумываясь насколько этот шаблон применим к специфике работы в данной конторе.

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

                                                    Было у меня такое один раз…
                                                +1

                                                Ой, можно у Вас стащить "левую пятку пушистых тапочек"? https://cv1.pikabu.ru/video/2020/01/26/1580040782263219333_458x658.webm

                                                  0
                                                  Да ради бога) Классная картиночка)
                                                +4
                                                И перерисовывали все 10К ячеек по любому изменению.

                                                Но ведь это и называется "не смогли в Big O".

                                                  0
                                                  Это классическое «к пуговицам претензии есть?!». У них в коде — всё прекрасно и минимальная алгоритмическая сложность, а что происходит за границами их кода — им не очень интересно было. Самое забавное, что я одного из этих прошлых авторов лично спрашивал — мол, а зачем это всё, если у вас перерисовка кривая? На что мне было сказано, что чёт всё медленно было, а значит надо было улучшить сложность! Ну и улучшили, только быстрее не стало. Отчитались, что они молодцы, а проблемы все на стороне браузера.
                                                    0

                                                    Ну так и проблема-то, получается. именно в этом подходе "к пуговицам претензии есть?!", а не в Big O.


                                                    Тем более что на самом-то деле именно их код был алгоритмически неоптимален.

                                                      0
                                                      Вот я знаю про Big O, а при этом уже сколько времени работаю, но каждый раз когда на проде обнаруживается какой-то завтык — у меня инстинктивное желание вопить про «неэффективную структуру данных» и что нам нужно немедленно всё останавливать и денормализовать всю структуру в БД для оптимизации под чтение (прямо как нас в универе учили!), а опытные коллеги вместо этого просто вставляют очередной индекс, получают 10-кратный прирост к производительности и спокойно работают дальше. Уже сколько раз себя по рукам бил, а до сих пор желание не проходит.

                                                      Так что да, алгоритмы в вакууме — это хорошо, но практическое понимание мест, которые *имеет смысл* оптимизировать — всё-таки важнее.
                                                        +7

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

                                                          0
                                                          И в них немало от оптимизации сложности алгоритмов )
                                                          0
                                                          и что нам нужно немедленно всё останавливать и денормализовать всю структуру в БД для оптимизации под чтение (прямо как нас в универе учили!)

                                                          Извиняюсь, за глупый вопрос, последний раз базы трогал именно в универе. А как там можно ускорить чтение, помимо индексов?
                                                            +1

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


                                                            Ps: Это не руководство к действию. Это тема для поговорить.

                                                              0
                                                              Спасибо за ответ. Что джойны лучше убрать, где можно, это понятно. Под денормолизацией понимается ввиду хранение не 2 таблиц, которые нужно джойнить, а сразу сджойненную? Извиняюсь за ещё один глупый вопрос.
                                                                +1

                                                                К слову, у SQL Server есть индексированные представления, которые как раз и позволяют хранить сразу сджойненную таблицу. А в Enterprise-редакции он ещё и использует такие представления при оптимизации запросов, что превращает их во что-то вроде индекса по двум таблицам.

                                                                  0
                                                                  если это тема поговорить — то partitioning, clustering, parallel reading from different nodes, etc…
                                                                  в некоторых базах данных нет явных индексов вообще, что не мешает читать со скоростью много гигабайт в секунду…
                                                                    0
                                                                    Типовой случай из Википедии да. На практике иногда достаточно одно поле перенести из одной таблички в другую. Или как уже написали materialized view сделать (если ваша база позволяет)
                                                          +1
                                                          Как я понимаю, stanislav888 говорит не об умении работать с красно-чёрными деревьями, а о базовом понимании, что for внутри for внутри for это плохо.
                                                            +1
                                                            Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело, но напишу еще раз тут: для фронтэндера, например, вопрос знания сложности алгоритмов в лучшем случае примерно третий по важности, и на собеседовании особо не значим. Почему? Потому что высокая алгоритмическая производительность на фронтэнде иногда нужна, но весьма редко; а вот знать, как браузер грузит ресурсы и рендерит страницу — нужно практически для любого реального проекта. Быстродействие будет определяться именно этими двумя вещами, а не тем, что вы где-то там внутри дуболомно изобразили O(n!), вот только n всё равно выше десятка не вырастет даже в теории.


                                                            Главное, чтобы потом не надо было отобразить табличку, в которой более 100 элементов. А ведь иногда ещё и 1000 может прийти. Очень не каждый выдержит такое. Jira и confluence вот не всегда справляются.
                                                              +1
                                                              Я даже не представляю, как при отображении таблички получить что-то хуже n^2. А n^2 отобразит сколько угодно информации, сколько вообще имеет смысл показывать человеку за один подход; и узкое место опять таки будет не в n^2, а в рендере, если только вы каждую ячейку не заполняете чем-то вычислительно сложным, рассчитываемым прямо в клиенте. Впрочем, для этого уже даже wasm завезли.
                                                                +1

                                                                Так в том-то и дело, что для рендера это самое n^2 на каждую перерисовку — это уже много. Даже n — и то иногда может оказаться много.

                                                                  +1
                                                                  Скажу еще проще: в браузере рендер DOM-дерева таблицы на N ячеек в общем случае имеет очень плохую вычислительную сложность (потому что допускает многократный ре-рендер части таблицы, в максимально плохом случае при рендере каждой новой строчки произойдет ре-рендер всех предыдущих) с очень большой константой, против чисто вычислительных операций в JS. В частном случае (table-layout: fixed) — линейную, со всё так же большой константой. Чтоб ваши вычисления со сложностью m*N^2 стали более узким местом, чем браузерная перерисовка со сложностью M*N (M сильно больше m) — вам придётся очень сильно постараться. И это только table-layout: fixed, что уместно далеко не всегда.
                                                                    0
                                                                    Это всё, конечно, прекрасно, но я работал с табличками на 10000 строк. Да, грузятся они долго, конечно — но зато потом их листать можно быстро и нужное место находится легко.

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

                                                                    А ведь там всего-навсего порядка 2000 картинок.

                                                                    Так что, может, и нужно «очень постараться» — но почему-то людям, не умеющим в Big O это удаётся с трогательной регулярностью.

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

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

                                                                    Про фибоначчиевы кучи и алгоритм Шёнхаге — Штрассена при этом знать, в общем, необязательно…
                                                                      +1
                                                                      А вы зайдите, пожалуйста, сюда и попробуйте пролистать вот это вот… не хочу ругаться матом.

                                                                      Мы уже обсуждали это — убогая бесконечная лента на патреоне убогая как раз потому, что авторы не смогли в понимание, что там у них и как перерисовывается. И перерисовывается оно всё каждый раз с нуля при каждой догрузке ленты. Вот вы нажали на кнопочку «Load more» — и у вас вся лента сверху донизу перерисовывается, просто чтоб вместо кнопочки load more показать спиннер. А потом оно догрузится — и еще раз столько же.

                                                                      При этом я почти уверен, что авторы не без основания считают, что в их собственном коде с алгоритмической сложностью всё прекрасно. Там наверняка ничего сложнее O(n) ;-)
                                                                        0
                                                                        При этом я почти уверен, что авторы не без основания считают, что в их собственном коде с алгоритмической сложностью всё прекрасно. Там наверняка ничего сложнее O(n) ;-)
                                                                        А вот это как раз и есть «неумение в Big O», как вам уже писали.

                                                                        Вот вы нажали на кнопочку «Load more» — и у вас вся лента сверху донизу перерисовывается, просто чтоб вместо кнопочки load more показать спиннер. А потом оно догрузится — и еще раз столько же.
                                                                        Что, собственно, и является классическим «Шлемиэлем». И если уж люди такое допускают — то это действительно, не люди, умеющие в алгоритмы, а «свидетели Священной Big O».

                                                                        Да, мне от «знания алгоритмов» нужно, чтобы человек умел избегать алгоритма маляра Шлемиэля (или умел доказывать что это невозможно там, где это невозможно). И все задачи, которые я даю — всегда именно на это.

                                                                        А вовсе не на знание хитромудрых алгоритмов из вумных книжек.
                                                                          0
                                                                          А вот это как раз и есть «неумение в Big O», как вам уже писали.

                                                                          Я бы не называл это «неумением в big O», потому что вполне может статься что при попытке это выяснить (каким-нибудь условным собеседованием или экзаменом) вы от такого человека услышите про big O в её академическом понимании больше, чем сами знаете.
                                                                          Это неумение пользоваться выбранными инструментами — процессором, про что пишет Джоэл, или реактом, что наблюдается в ленте патреона. При этом совсем даже не стоит исключать того, что какими-то другими инструментами все эти же люди умеют пользоваться гораздо лучше. И еще не стоит забывать о том, что в зависимости от инструментов и создаваемого софта — будет вполне допустимо определенными инструментами не владеть или владеть крайне плохо, без каких-либо видимых последствий.
                                                                            0
                                                                            Я даже не представляю, как при отображении таблички получить что-то хуже n^2.

                                                                            Ну уже n^2, в начале было факториал. :)
                                                                            А вообще всё зависит от задачи и сценариев использования. Допустим у нас данных даже 10000, допустим даже таблица строится за квадрат (т.е. 10^10), это для процессора, который может выполнять десятки миллирдов операций (как раз таки 10^10) несколько секунд (если не считать рендеры, я не знаю, как они работают, туда не лезу). А потом кому-то надо с этой таблицей работать и на каждой перезагрузке получаем уже k*N^2, где k — число перезагрузок, что вызывает уже боль. А не дай бог, потребуется сделать операцию над каждой ячейкой и она будет перересовываться именно после каждой ячейки. Уже получаем куб. В общем я согласен с вами, что знание рендера очень важно, но квадраты пихать тоже не стоит.
                                                                              0
                                                                              Ну уже n^2, в начале было факториал. :)

                                                                              Факториал был как абстрактный пример крайне плохой сложности, которая, однако, на малых n едва ли будет значима.

                                                                              А потом кому-то надо с этой таблицей работать и на каждой перезагрузке получаем уже k*N^2, где k — число перезагрузок, что вызывает уже боль.

                                                                              Лично у меня глагол «работать» не вызывает никаких ассоциаций с «давайте заново перестроим таблицу по квадратичной сложности». Что вы имеете в виду?
                                                              0

                                                              Глас вопиющего в пустыне… Людям, которые работают с простыми, очевидными, и прекрасно контролируемым условиями в back end, никогда не понять хаоса и дикого Запада front end.

                                                                +2
                                                                Вы так говорите, как будто я front end не делал. Делал. И не раз. Нет там никакого хаоса. Хаос есть только в одном, всем известном месте — и он не имеет никакого отношения ни к back end'у, ни к front end'у.

                                                                До back end'а он недобирается исключительно в силу того, что люди, способные его устроить о его сушествовании не знают…
                                                                  0
                                                                  До back end'а он недобирается исключительно в силу того, что люди, способные его устроить о его сушествовании не знают…

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

                                                                    При всём уважении, ваши слова только подтверждают разницу между "делал, и не раз" и "занимаюсь этим постоянно". Вы этот хаос или намеренно игнорировали, или просто не успели заметить.


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


                                                                    • Различных браузеров, разных версий
                                                                    • Различных платформ и устройств
                                                                    • Абсолютно неконтролируемых сетевых условий
                                                                    • Абсолютно неконтролируемых условий среды в браузере

                                                                    … и т.д., и т.п., поверхность потенциально проблемной области в front end разработке в разы больше, чем в back end. Если не на порядки.


                                                                    Просто для примера, из свежего: у вас в практике часто бывало, чтобы на серверной стороне в код без спросу внедрился случайный третьесторонний модуль и начал блокировать вызовы к каким-либо микросервисам? И его не убрать никак. А у нас это норма жизни, ad blockers или какие-нибудь расширения в браузере могут в любой момент поломать что угодно. И объясняй потом бизнесу, почему их интеграция с каким-нибудь Appcues не работает и как её починить (а починить нетривиально).


                                                                    И таких ситуаций, факторов, ошибок, особенностей, да просто багов — сотни, тысячи их. И каждый день что-то новое.


                                                                    Мы из Хаоса (tm).

                                                                      0
                                                                      Просто для примера, из свежего: у вас в практике часто бывало, чтобы на серверной стороне в код без спросу внедрился случайный третьесторонний модуль и начал блокировать вызовы к каким-либо микросервисам?

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

                                                                        0

                                                                        Это всё же не совсем то, о чём я говорил. Прокси-сервисы и middleware тоже ломаются иногда, настройки слетают, и всё такое.


                                                                        Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.


                                                                        А на frond end — легко. Домен третьесторонней интеграции кто-то добавил в чёрный список, и привет. Узнать об этом, кроме как из разъярённых воплей обиженных клиентов, вообще никак нельзя. Это не хаос?

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

                                                                          А если этих пользователей — полпроцента и, в принципе, всё равно всё работает… то так ли уж важно и нужно на это реагировать?

                                                                          Гугл какой-нибудь отлично «забивал» на пользователей Opera даже тогда, когда Opera была лидирующим браузером, а Гугл отчаянно боролся за российский сегмент (у них тогда даже пара центров разработки в России была).

                                                                          И ничего — это не помешало ему вытеснить сначала Рамблер, а потом и Яндекс.
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                              +1
                                                                              В России Яндекс как лидировал, так и остаётся лидером.
                                                                              Проснитесь, посмотрите на календарь, вдохните, выдохните… Уже довольно давно Яндекс не лидер.

                                                                              Не без помощи ФАС, но даже на мобильниках стали.
                                                                              Уже нет. У вас сведения устарели. Идут споры о том когда Гугл обошёл Яндекс (в 2018м или 2019м), но факт уже зафиксирован фактически всеми.

                                                                              Причём тут Рамблер, тоже непонятно.
                                                                              Рамблер вообще-то был лидером до Яндекса. А потом отошёл на второе место в списке поисковиков. И Google вначале должен был обойти его, потом уже только Яндекс.
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  +1
                                                                                  Вот вот одна ссылка из моей вселенной в вашу. Вторая.

                                                                                  А вы откуда берёте статистику?
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                            0
                                                                            Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.

                                                                            Да регулярно. Просто на фронте — это адблоки и сотоварищи, а на бэке — это сисы, баги и кривые деплои у сторонних сервисов, проблемы у облаков, ДЦ, хостеров и т.п. В последний раз поперло куча падений по таймауту при обращении к базе в облаке на обновление записей, последний релиз за месяц до, последний деплой за неделю до. Ничего не делали, примерно 10% запросов падают по таймауту.
                                                                              0

                                                                              Нет, не то. Я не об этом говорю. Баги бывают, таймауты, переполнение базы, всё что угодно. Но это контролируемые условия. Есть проблема — вы её решаете, и всё работает взад. Баг можно пофиксить, базу можно подчистить или ещё ноду накатить, в сети QoS подвинтить или в чём там проблема была.


                                                                              В front end нормой жизни является непредсказуемое и неконтролируемое изменение условий. Вот как с тем примером с Adblock. Вы на самом деле ничего не делали, правда! — а оно бац, и поломалось. Совсем. И не починить, потому что юзера не заставишь отказаться от Adblock, а домен не убрать из списка. Это не баг и не проблема с сетью. Это именно изменение ТЗ, на лету, постоянно.


                                                                              Я же не пытаюсь выпендриться крутизной, я просто объясняю, что front end это очень особенная область в разработке софта. Тут царит хаос и непредсказуемость, которая требует выдержки и определённого склада характера. Если вам нравятся чётко поставленные задачи в CS стиле: ввод -> алгоритм -> вывод, а изменение ТЗ вызывает беспричинную раздражительность, то лучше во front end не заходить. Шишек набьёте, ЧСВ синяками покроется, и будете потом всем с умным видом рассказывать, какие они идиоты и как надо было всё делать вообще не так.

                                                                                +2
                                                                                Но это контролируемые условия. Баг можно пофиксить, базу можно подчистить или ещё ноду накатить, в сети QoS подвинтить или в чём там проблема была.

                                                                                Вы меня не поняли. На бэке неконтролируемые условие — это тоже обыденность, и по влиянию они точно такие же, как и adblock. Где-то кто-то что-то поменял и больше оно у вас не работает. И вы тоже не можете просто починить это, ибо чужой сервис не заставишь работать так, как хочется вам, приходится пложить костыли, вплоть до лютых извратов. Вся фишка в том, что баг может быть не у вас, база лагает по совершенно неопределенным причинам (с подозрением, что что-то наконфигурировали чужие админы, но никто в этом никогда не признается), а у вас на всем этом завязано куча десктпного софта, который пользователи обновляют когда рак на горе свиснет.
                                                                                я просто объясняю, что front end это очень особенная область в разработке софта

                                                                                Но вам все равно кажется, что на бэке трава зеленее, ибо там нет адблока. Забывая про других личностей, которые делают ровно ту же грязь, и имя им легион.
                                                                                Если вам нравятся чётко поставленные задачи в CS стиле: ввод -> алгоритм -> вывод, а изменение ТЗ вызывает беспричинную раздражительность, то лучше во front end не заходить.

                                                                                Неужели вы думаете так только на фронте? Даже когда софт пишется внутри компании, ровно те же самые проблемы: алгоритмы недодуманы, одна фича конфликтует с другой, таски переписываются и перетасовываются, требования меняются прямо на релизе, и т.д.
                                                                                Шишек набьёте, ЧСВ синяками покроется, и будете потом всем с умным видом рассказывать, какие они идиоты и как надо было всё делать вообще не так.

                                                                                Поздно советовать, был я там. И не только там был, и везде проблемы по независящим от тебя причинам. А сейчас рад быть там, где даже консольное окошко вижу не каждый день. Поверьте, любая третья сторона создает абсолютно одинаковые проблемы, хоть адблоком она называется, хоть админом Йоханом из Дели, хоть юзером Мартой из Бостона.
                                                                                  0
                                                                                  Вы меня не поняли. На бэке неконтролируемые условие — это тоже обыденность, и по влиянию они точно такие же, как и adblock. Где-то кто-то что-то поменял и больше оно у вас не работает.

                                                                                  В таком случае я не вижу, как это противоречит заявлению "front end это хаос". Даже более: поздравляю, у вас тоже хаос. :))


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

                                                                                  Дался вам этот adblock, это просто один пример был. :) Мысль-то была очень простая: в front end разработке настолько часто встречаются неконтролируемые изменения условий, приводящие к кардинальным изменениям в софте и процессах, что это является нормой вещей. Делали приложение для десктопа и современных браузеров? Поздравляю, мы вчера подписали контракт на $1005000 с XYZ и им надо IE11. Упс, а Chrome пять минут назад обновился и теперь скроллинг не работает, срочно фиксить. А что, у вас сайт на телефонах не работает? Какая разница, что в ТЗ было, это вчера было! Что? Гугл поднял расценки на внедрённые карты, а у нас на них весь интерфейс завязан?


                                                                                  Ну и т.п. Куда уж тут до чуточку недопереоптимизированных алгоритмов, выкатить бы что-нибудь. :)


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

                                                                                  Я вам даже больше скажу: так вообще везде. Помнится, в начале 2000х, когда ВТБ по случаю прикупил себе Гута-банк, мне пришлось разворачивать колл-центр ВТБ24 с оборудования Гуты, но на площадке ВТБ. Сроки сжатые, нужное количество E1 пробросить не успевали, поэтому можно было только Voice-over-IP, новинку по тем временам. За неделю прошли все инстанции (в ВТБ! представляете?!), всё подписали, всё согласовали — стыковали сети, пограничку настроили, всё работает. Ещё за неделю телефоны развернули, сценарии прописали, всё готово к сдаче.


                                                                                  А потом накануне запуска безопасники ВТБ такие: а мы тут вот затылок почесали, короче, не нравится нам RTP этот ваш, небезопасный он. Вы там что-нибудь придумывайте, а мы вам порты на файрволле зарубили. Всего хорошего.


                                                                                  Вот 15 лет назад было, а до сих пор помню. Потому что такое резкое и несовместимое с разумом изменение внешних условий всё же не такое частое явление… Вне front end. :)


                                                                                  Поверьте, любая третья сторона создает абсолютно одинаковые проблемы, хоть адблоком она называется, хоть админом Йоханом из Дели, хоть юзером Мартой из Бостона.

                                                                                  Да ладно, ну что вы в самом деле. Проблема же не в разнородности проблем, а в их количестве. Как кто-то когда-то сказал, Quantity is a quality of its own. :)


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

                                                                                    +1

                                                                                    Если бекэнд просто подготавливает статику для показа в витрине — наверное, вы правы.


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


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


                                                                                    Поэтому проблемы визуализации — это неприятно, но гораздо проще и безопаснее, чем проблемы бизнес-логики на бекэнде.

                                                                                      0
                                                                                      У нас бекэнд общается с овердохрена сторонних сервисов, каждый из которых тоже апдейтится и может вдруг повести себя неадекватно.

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


                                                                                      А если мы вдруг курс валюты не проверим (по эвристикам и прочим ИИ) перед совершением транзакции — можно влететь на десятки миллионов евро.

                                                                                      Ну вот именно об этом я и талдычу уже который день: вы контролируете эти условия. Вы можете реагировать на внешние события и нейтрализовать их в своём коде или ещё как-нибудь. Что-то сломалось? Починили. Ненадёжный источник данных? Обложили эвристиками, проверками и перепроверками. Это контроль над средой. Не идеальный, но контроль.


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


                                                                                      Поэтому проблемы визуализации — это неприятно, но гораздо проще и безопаснее, чем проблемы бизнес-логики на бекэнде.

                                                                                      Эту старую песню о главном можно продолжать очень долго, но front end это не только визуализация данных.


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

                                                                              +1
                                                                              Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.


                                                                              Да ну?

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

                                                                                Бывает, конечно бывает. И так бывает, и сяк бывает, хаос и энтропия никого не оставят в покое. Просто я всё время наблюдаю со стороны, как жизнь идёт у наших back end/platform/devops товарищей, которые всё время ужа с ежом скрещивают… Спокойнее у них там, гораздо. :)


                                                                                Иногда даже подумываю, а не плюнуть ли на всё, натянуть Golang какой-нибудь на голову и податься через забор. Но скучно там всё же, когда привык к адреналину, размеренная жизнь как-то не цепляет уже. Да и плюшки с этой стороны вкуснее. :)

                                                                                  0
                                                                                  Ну я не знаю за ваш бэк, а у нас голангом не обойдешься. Будте любезны для начала RPG освоить, да еще научиться читать свободно чужой RPG код на древнем fix формате, потом желательно C/C++ потом вникнуть во все «нефункциональные требования» — что можно а что нельзя сточки зрения эффективности.
                                                                                  А чтобы стать действительно хорошим рабаботчиком на бэке, забдте про все фреймоворки — из тут нет и учите потроха AS/400 — что там и как работает. Ибо одним языком тут не обойдешься, придется вникать в системные API.
                                                                                  Ну и примите во внимание, что на сервере кроме вашей еще тысячи задач крутятся и все они между собой взаимодействуют так ли иначе. Один журнальный монитор чего стоит…
                                                                                  Ну и внешние сервисы, да… Скажем, получили некоторую строку, закинули ее в таблицу, она оттуда автоматом через очередь улетает на парсинг в некйи внешний сервис, оттуда опять через очередь прилетает обратно вам… И не дай бог в этом внешнем сервисе что-то поменялось… Вдруг. Разгребать придется опять вам.

                                                                                  Так что везде свои тараканы. Эт только со стороны кажется что все тихо и спокойно.
                                                                            –1
                                                                            А у нас это норма жизни, ad blockers или какие-нибудь расширения в браузере могут в любой момент поломать что угодно. И объясняй потом бизнесу, почему их интеграция с каким-нибудь Appcues не работает и как её починить (а починить нетривиально).
                                                                            И вот мы снова возращаемся к источнику хаоса. И нет, это не ad blockers и не расширения. Это бизнес (или, вернее, менеджеры), который всё время «хочет странного». Нет проблем в том, чтобы составить список браузеров, которыми пользуются 95% пользователей и список расширений, которыми, суммарно, пользуются не более 10-15% пользователей — и забить на них. Вот просто забить большой болт и всё.

                                                                            Но почему-то заявление о том, что наш back end работает с MySQL или PostgreSQL, но никак не с mSQL — воспринимаются нормально… а заявления о том, что HuyanPinyanBrowser не поддерживается — приводят к истерике. Хотя доля у того HuyanPinyanBrowser'а меньше, чем у mSQL… но он предустановлен на любимом ноуте директора — и потому получает самый высокий приоритет.
                                                                              +1
                                                                              Это бизнес (или, вернее, менеджеры), который всё время «хочет странного».

                                                                              С точки зрения этого бизнеса (или, вернее, менеджеров), вы тоже всё время хотите чего-то странного. Зарплаты, например.


                                                                              Вот просто забить большой болт и всё.

                                                                              Я хочу вдаваться в подробности на тему, почему "забить большой болт и всё" нельзя. Это отдельная большая тема.


                                                                              Я вам о другом говорю: забить большой болт не работает. Можно забивать сколько угодно, это не поможет. Никак. Потому что у 95% пользователей всё равно будут разные браузеры, разные платформы, и разные устройства. От мощных десктопов до туповатеньких Chromebook, от последних iPhone до дешёвых китайских клонов какой-нибудь младшей модели Samsung Smartwatch. Какие критерии вы предлагаете использовать для исключения тех и этих, чтобы ваша жизнь была попроще? Назад в будущее, к This site is best viewed in IE6?


                                                                              По вашим словам мне очевидно, что вы просто не владеете предметной областью. Так и должно быть, front end не ваша специализация. Это моя специализация, и я отлично знаю из опыта и толстой мозоли на лбу, почему нельзя "просто взять и сделать" сайт, чтобы всё работало и все были довольны.


                                                                              Я стараюсь не вспоминать о битвах с нативным скроллингом документа, который есть сущее, адское зло — а виртуальный скроллинг это тоже сущее, адское зло. У меня в печёнках сидят поля ввода в HTML, обработка фокуса, маски и валидирование значений. Меня тошнит от touch events, от распознавания жестов по таймауту и ловли утёкших таймеров (ручками, всё ручками!). Я молча посылаю пламенные лучи ненависти и поноса в сторону HP, Lenovo и прочих умников, выпускающих лаптопы с тачскринами, которые никак особенно не определяются в браузере и потом к чертям ломают всю обработку событий, потому что смешать pointer events и touch events это — а чо, у нас в Windows работало? Я плачу кровавыми слезами каждый раз, когда мне нужно лезть в caniuse.com и подтверждать, какие фичи из CSS3 работают в последнем мобильном Сафари, а какие нет. И т.д. и т.п., конца и края этому нет (и не будет).


                                                                              Можно всё это игнорировать, для личных проектов сойдёт — кому они нужны, кроме вас. А для коммерческих проектов не сойдёт, и игнорировать уже не получится. Добро пожаловать в добрый, светлый мир front end. :)

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

                                                                                Так с какого перпугу я должен перед этими людьми бить чечётку?

                                                                                Я хочу вдаваться в подробности на тему, почему «забить большой болт и всё» нельзя. Это отдельная большая тема.
                                                                                Ну так если хотите — так и сделайте. Кто мешает? Вдавайтесь…

                                                                                Потому что с одной стороны — я вижу рассказы про то, что нужно вот обязательно делать всё «феншуйно» с использованием кучи костылей, а то, не дай бог, отпадут три с половиной пользователя, который пользуются странным антивирусом на ноуте Lenovo с тачскриром… с другой стороны — наблюдаю не работающий уже неделю в Firefox ESR 68.4 интерфейс перевода денег с карты на карты в Yandex.Money… ну и как это сочетается, извините?

                                                                                Я работал в конторах, которые стремились поддерживать все эти «странные» браузеры и «странных пользователей»… и таких, которые этого не делали.

                                                                                Практическая разница — во вторых работать гораздо спокойннее… и не скажу, чтобы с сильной потерей зарплаты. А если они существуют «в количестве» (а они таки существуют) — то «забивать болт» вполне можно.

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

                                                                                Назад в будущее, к This site is best viewed in IE6?
                                                                                То, что реально нужно для реализации функциональности большей части сайтов отлично отрендерит и IE6. Напоминаю что в 2004м, когда появился GMail — это был самый популярный браузер… и уже тогда там был и приличный интерфейс и загрузка писем в фоне и многое другое.

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

                                                                                Это моя специализация, и я отлично знаю из опыта и толстой мозоли на лбу, почему нельзя «просто взять и сделать» сайт, чтобы всё работало и все были довольны.
                                                                                И почему же? Вот конкретно: почему в 2004м со всеми этими MS IE 5 и Netscape 4.8 это было сделать можно, а потом вжух — и сразу стало нельзя?

                                                                                Ответ: потому что в те времена ответ от службы поддержки на тему «ваш сайт работает на моей загаженной системе со 150 расширениями и кучей добра» был простым: «пожалуйста, воспроизведите проблему на чистой установке Windows и без установленных расширений в браузере». И всё. Нет никакого хаоса.

                                                                                Просто все забыли старую истину:
                                                                                If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy.


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

                                                                                А для коммерческих проектов не сойдёт, и игнорировать уже не получится.
                                                                                А почему не получится, собственно? Вы так уверенно про всё это рассказываете, как будто я не могу зайти на какой-нибудь lwn.net с этого самого вашего ноутбука с тачскрином и почитать там новости. Могу прекрасно.

                                                                                А вот на сайты, сделаннаые профессионалами типа вас — не могу. Они разваливаются и глючат.

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

                                                                                Вот, собственно, и всё.

                                                                                На бекэнде можно такой же бардак и гемор себе устроить. Легко. Разрешите вашим контрагентам присылать данные в .xlsx и трахайте бекондерам (а не контрагентам) мозги, когда что-то работает неправильно… только почему-то этот подход — непопулярен, а вот десять слоёв костылей, нужных для того, чтобы документ вёл себя не так, как хочет разработчик браузера, а так, как хочет левая пятка младшего помощника — это нормально.
                                                                                  0
                                                                                  Зарплата была моим условием при заключении контракта, извините.
                                                                                  Так с какого перпугу я должен перед этими людьми бить чечётку?

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


                                                                                  Ну так если хотите — так и сделайте. Кто мешает? Вдавайтесь…

                                                                                  Это очепятка была. Не хочу я вдаваться в эти подробности.


                                                                                  с другой стороны — наблюдаю не работающий уже неделю в Firefox ESR 68.4 интерфейс перевода денег с карты на карты в Yandex.Money… ну и как это сочетается, извините?

                                                                                  Да легко: кто вообще пользуется этим дурацким Firefox? Полтора пользователя, которые никому не нужны?


                                                                                  То, что реально нужно для реализации функциональности большей части сайтов отлично отрендерит и IE6.

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


                                                                                  Нет, ну ей-богу, скучно. На том давайте и закончим, всего хорошего.

                                                                                    0
                                                                                    В вашем контракте не написано, что вы работаете работу за зарплату?
                                                                                    Нет — про «работать работу» там не написано. И про «исполнение всех хотелок» — тоже.

                                                                                    Вам ставят задачи, вы их решаете. Не будете решать — уволят, наймут другого.
                                                                                    Вы знаете — в контору, которая так ставит вопрос я и сам работать не пойдут. Потому что, как я уже сказал, 90% «хотелок» — просто бессмысленны. И нужно не думать как их сделать, что сделать вместо них. Как в в известной статье:
                                                                                    Хороший дизайнер интерьера постоянно приносит эскизы клиенту и вещи, из которых он может выбрать. Но они никогда не обсуждают с клиентом расположение посудомоечной машины. Она находится рядом с умывальником и не важно, чего хочет клиент. Нет смысла тратить время на обсуждения, где должна находиться посудомоечная машина — она должна быть рядом с умывальником, даже не начинайте разговор об этом; пусть клиенты изливают свои дизайнерские потуги делая какие-то безвредные вещи вроде изменения своего мнения 200 раз о том, нужно ли использовать для столешницы итальянский гранит или мексиканскую плитку, или норвежскую древесину.

                                                                                    Вот то же самое и с фронтэндом (да и с бекэндом и с чем угодно): если у заказчика возникают странные идеи (типа установки этого этой самой машины на чердаке), потому что он вычитал что это будет клёво — вы это просто игнорируете. Через неделю он всё равно всё забудет. Если клиент дотошный и всё перепроверяет — делаете так, чтобы всё было по спецификации, но работать с этим было невозможно. Он сам откажется.

                                                                                    Делать нужно то, для чего вы понимаете какова будет конечная цель. И нет, «так написано в документе, который мы согласовали после трёх совещаний» — это нифига не конечная цель. Конечная цель — она от бизнеса зависит. От того, как он деньги зарабатывать собрался. Если у вас нет цепочки, связывающей заработанные деньги с теми требованиями, что у вас на столе — то это всё вообще не требования, которые нужно исполнять, а «хотелки».

                                                                                    Это очепятка была. Не хочу я вдаваться в эти подробности.
                                                                                    А надо бы. Потому что хаос возникает там и только там, где вы допускаете его возникновение.

                                                                                    Да легко: кто вообще пользуется этим дурацким Firefox? Полтора пользователя, которые никому не нужны?
                                                                                    Принимается. В рамочку и на стену. А теперь посчитаем: Firefox пользуются 9.92% пользователей. И на них забили. То есть «порог отсечения» у нас — что-то в районе 3-5%. Теперь вы тут рассказываете про «мозоль на лбу»… у какого процента пользователей эти самые ноутбуки с тасчринами от HP или Lenovo? 0.1%? 1%? Вряд ли больше.

                                                                                    Ну а тогда они отлично идут туда же, куда и пользователи Firefox. И всё. И нет хаоса.

                                                                                    Если бизнес принесёт статистику, где покажет, что вот конкретно у вас таких пользователей 50% (ну например вы делаете сайт для школ, а им централизованно такие лапотомы закупили) — тогда да, придётся корячиться.

                                                                                    Но у вас не могут быть одновременно 50% пользователей с лаптопами HP или Levono, 50% пользователей iPhone и 50% пользователей Android. Математика, знаете ли.

                                                                                    Так что снова никакого хаоса.

                                                                                    Разруха — она не в клозетах, разруха — она в головах.

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

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

                                                                                    Если вы относите в категорию «не осилил» отказ от игры в игру «чего изволите» — то вы на 100% правы.

                                                                                    А так — я и фронтэнд делал, для стартапа, который потом купили за неплохие деньги и Win32 GUI (для другого стартапа) и пролжоения для мобильных устройств (нет, не для сотовых), лет пять назад пилил порт GCC на одну интересную архитектуру… и нет, «не осилил» — нигде не было. Но и «чего изволите» — не было тоже.

                                                                                    Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели (потому что её мог налисовать, там где этого хотел заказчик, только драйвер, а он не имел доступа к GUI, а API изначально не предполагал передачу данных в эту сторону по инициативе приложения, так что его пришлось менять… в общем много чего там было).

                                                                                    Когда я это всё обсудил с заказчиком, то он, конечно, мне всё это оплатил (совестливый был человек, мы с ним потом ещё много лет работали), но задал разумный вопрос: «а почему, когда выяснилось, что это — задача не на два часа, а на две недели… я, чёрт побери, не обсудил это со мной

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

                                                                                    Чуть позже я обнаружил, что есть-таки случаи, когда заказчик твёрдо уверен в том, что он знает что ему нужно… это тогда, когда заказчик — это не конечный заказчик, но посредник (ваш менежер или продажник или, может быть, менеджер со стороны закачика)… но тут ещё смешнее: все эти люди продают мою, ещё не сделанную работу — и берут за это деньги.

                                                                                    Ну так в этом случае это они у меня на крючке, а не я у них: деньги-то они уже получили (или считают, что получили), а работу-то я не сделал. И если я её не сделаю — то вся их долгая деятельность по уговору реального заказчика и подписанию договоров — полетит коту под хвост.

                                                                                    Единственный вариант, когда с заказчиком в принципе никак нельзя договорится, потому что он может вас уволить и нанять на ваше место «дядю Васю с улицы» — это когда то, что вы делаете, может сделать любой дядя вася надёргав кусков куда со StackOverflow… но стоит ли за такую работу держаться?
                                                                                      0
                                                                                      Вот интересно, вы призываете игнорировать требования заказчика и сами выбираете, что делать, а что нет (зачастую втайне от него). Но когда у Вас кто-то написал sql запрос не за логарифм, а за O(n), то это мгновенно повод для увольнения. Как так то?
                                                                                        0
                                                                                        «Друзья мои, делайте как я говорю, а не как я поступаю» ©

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

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

                                                                                          Sql-запрос за логарифм, а не зна O(n) — это в 99% случаев существенное замедление программы на ровном месте. И да, нужно уметь замечать, когда такое происходит и исправлять. И про это Джоел писал (он вообще, похоже успел описать все «банальные истины», какие существуют в мире IT… но они их можно крутить как угодно — но это всё равно истины).

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

                                                                                          Иногда можно убедить плотника сделать «что-то странное» произнеся магические слова «под мою ответственность» и дав ему чертежи… но в целом отказ делать вещь, которая потом принесёт ему только головную боль — в случае с плотником сомнений не вызывает.

                                                                                          С другой стороны, если тот же плотник сделает табуретку использовав для этого золотые гвозди или, наоборот, какою-нибудь дешёвую, но токсичную деревеплиту — вряд ли он заслужит эпитета «хороший», ведь так?

                                                                                          Так почему тот же самый подход к программированию вызывает вопросы?
                                                                                            +1
                                                                                            Вы хорошо описали, почему не стоит слушаться заказчика (с этим я в принципе согласен), но не описали, почему нужно слушаться Вас.

                                                                                            > Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели

                                                                                            А если бы вы sql запрос 2 недели оптимизировали, это было бы правильнее?

                                                                                            Просто поймите, что для рядового программиста Вы и есть тот самый заказчик. И естественно, этот программист Вам как заказчику не верит. Ну не верит он, что в этом sql нужен O(logn), что делать? Также, как Вы не верите, что в этом месте нужна красивая кнопка.

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

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

                                                                                              Просто поймите, что для рядового программиста Вы и есть тот самый заказчик.
                                                                                              А! Вы в этом смысле. Я даже как-то не подумал, что тут можно так понять.

                                                                                              Ну не верит он, что в этом sql нужен O(logn), что делать?
                                                                                              Делать свою версию, если он в ней уверен. Только потом ему нужно будет доказать, что она лучше.

                                                                                              Понимаете — у любого заказчика (и у меня в том числе) всегда есть в запасе опция «не принять работу». И мне это сделать гораздо проще, так как в отличие от менеджера с его семью красными линиями я могу это всё сделать и сам.

                                                                                              Ну а если у вас не примут работу раз, два, три… десять… то тут уже и об увольнении можно говорить — так ведь?

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

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

                                                                                              И обнаружить закладки такого рода — было бы очень неприятно.

                                                                                              Да и не нужно это: если у вашего компонента никогда ничего не ломается без этих ваших закладок, то я вам завидую белой завистью.

                                                                                              Вот, из свеженького: наши очередные правки подобрали… и наш компонент поломал всем, кто его использует, билд. Ну кто мог предположить что макрос CHECK можно использовать в constexpr-выражении… но только если ты не используешь clang-tidy?

                                                                                              Пришлось забивать костыль. Upstream, надо сказать должное, отреагировал быстро, в следующей версии костыль можно будет убрать.

                                                                                              И вот такого… хватает безо всяких искусственно вставленных проблем.
                                                                                                0
                                                                                                А с этим всё проще — меня не нужно слушаться если со мной не работать. А если работать — то вопрос, как бы, отпадает.

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


                                                                                                Страна должна знать своих героев. :)

                                                                                                  +2

                                                                                                  Как единственный человек в этом треде с подробно заполненным профилем, имею сообщить: анонимность не может влиять на качество аргументации; если вам кажется, что влияет — вы на полшишечки от использования ad hominem.

                                                                                                    0

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


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

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


                                                                                      Золотые слова.

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

                                                                                      Править только дефекты, допиливать только те фичи, которые реально необходимы.

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

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


                                                                                      Ну на бэке свои проблемы, поверьте :-) И их хватает.
                                                                          +3
                                                                          Например если вы не работали с Qt то вам будет сложно с разбегу понять всякие делегирования, модели данных и пр. залёты. Это всё даже разрабы с опытом иногда не понимают.

                                                                          Давно работаю с Qt, но не смог расшифровать ваше сообщение.
                                                                          О каком делегировании речь?
                                                                          Модель данных — это про Qtшную реализацию ModeViewAdapter? Так вроде такие вещи надо знать безотносительно Qt или не Qt…
                                                                            +1
                                                                            «Делегирование» и «делегаты» это про один из паттернов ООП, который применяется в Qt виджетах. Там много классов которые кончаются на *Delegate. Например QAbstractItemDelegate.
                                                                            Модель данных — это про Qtшную реализацию ModeViewAdapter? Так вроде такие вещи надо знать безотносительно Qt или не Qt…

                                                                            Да, надо. Это «паттерны ООП», о которых вполне логично спрашивают на собесах. Но вот рассказать хотя бы про Model (которые наследники QAbstractTableModel)из всего этого набора, для большинства будет проблемой.
                                                                            Собсно я об этом и говорю, не надо обижатся на вопросы, надо вего лишь изучить всё это заранее.
                                                                              +1
                                                                              Ясно. ТО есть речь про базовый(он даже в википедии первый в списке) паттерн для коллбэков. Есть специалисты, которые не умеют в делегаты?
                                                                                +1

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


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

                                                                              0

                                                                              Ну всё. Собеседование не пройдено.

                                                                                0

                                                                                Скорее всего речь идет о реализации MVC в QML, там в дополнение к стандартному ModeViewAdapter есть концепция делегатов, таких элементов, которые сначала где-то описываются, а потом экземплярами создаются во вьюхе, тогда вью становится чем-то вроде контейнера для делегата.

                                                                                +1
                                                                                Было бы неплохо если все они будут знать сложность алгоритмов. Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.

                                                                                Все они… Хаскелисты, значит, тоже...


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


                                                                                Часто такие вещи на интервью спрашиваете?

                                                                                  0
                                                                                  Если внимательно прочитать мои посты то несложно догадаться что я вообще никого не спрашиваю. Я писал не о том что нужно спрашивать, а что надо делать чтобы на вопросы отвечать.
                                                                                  Хотите поменять пагубную практику вопросов по алгоритмам?! Пишите тому кто это делает.
                                                                                  +1
                                                                                  ну так если нужен спец на Qt, может лучше спрашивать кандидата про его опыт именно с Qt, а не про эти сферические алгоритмы?
                                                                                    0
                                                                                    Насколько я понимаю логику работодателей. Иногда конторе работающей с Qt проще взять просто C++ программиста, который освоит этот Qt за пару месяцев. Ну и что в этом случае остаётся спрашивать кандидата? Если ему ещё только предстоит работать с Qt?
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                        0
                                                                                        А всё это и спрашивают. И с этим проблем нет. Но если вы хотите значительно повысить свои шансы, то надо будет ответить и на самые противные темы.
                                                                                      +1
                                                                                      Qt достаточно простой и отлично документированный, спрашивать про него особого смысла нет. Максимум — поинтересоваться сталкивались/не сталкивались.
                                                                                      +2
                                                                                      Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.

                                                                                      А как же code review? Ведь то, что человек знает алгоритмы, еще не гарантирует, что в нужный момент он их в нужном месте применит.

                                                                                        +1

                                                                                        Предлагаете для тех, кто кнопку «аппрув» в ревью нажимает собеседовать отдельно, и уже их гонять по алгоритмам и Биг-О?

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

                                                                                          Впрочем, если ведется именно набор, то логично для будующего апрувера подготовить несколько задач, где нужно провести код ревью и найти потенциальные затыки, а не просто заставлять цитировать сложности алгоритмов на память.
                                                                                        +1
                                                                                        Чаще проблемы и фризы возникают вообще без всякого O. Мой личный топ:
                                                                                        1. Context.SaveChanges для EF (и прочих ORM) внутри цикла: типичная история из цикла «хорошо висим». Часто бывает при сложной цепочке внутренних вызовов.
                                                                                        2. Грузим весь CSV/Text в память и там его уже парсим. Типичная история падений по памяти и «хорошо висим». Тестовые файлы были мелкими, в таске ни слова, а в реале летают монстры. Про потоковую обработку файлов и буфферы чтения половина разрабов не слышала, вторая половина пользовалась ей в последний раз еще в школе. А для WebAPI и WWW вообще обычная история с их таймаутами и тенденцией переносить туда десктопный софт.
                                                                                        3. Сложные табличные fixed-size файлы запихиваем в БД для простой работы с ними (привет от файлов в гигобайт с миллионами записей). Фризы на импорте, фризы на экспорте, да еще и базой носителем часто бесплатная ограниченная версия выступает и падает по размеру файла базы.
                                                                                        4. У нас многоядерность, все надо параллелить! В итоге пара тысяч потоков сидят на ботлнеке с монитором, в лучшем случае с семафором.
                                                                                        5. Мой любимый маркетинговый фриз: эта операция выполняется слишком быстро, надо обязательно сделать задержку и повесить иконку ожидания!
                                                                                          0
                                                                                          Context.SaveChanges для EF

                                                                                          Где же тут "без всякого O"?


                                                                                          Грузим весь CSV/Text в память и там его уже парсим

                                                                                          То есть не учли "O" по используемой памяти.

                                                                                            0
                                                                                            Где же тут «без всякого O»?

                                                                                            Так сложность как была O(N), так и остается O(N). Сложность операции сохранения одной записи там O(1) получается, т.к. задержки на обращение к бд фиксированны для каждого запроса. Для сохранения всех записей сложность O(N). O(N)+O(N)=O(N).
                                                                                            То есть не учли «O» по используемой памяти.

                                                                                            С одной стороны:
                                                                                            В первом случае оно О(N).
                                                                                            Во втором случае оно O(N): N < K, O(1): N >= K
                                                                                            Пока размер файла не превышает K записей, обе реализации идентичны.

                                                                                            С другой стороны:
                                                                                            Для предупреждения этой проблемы вычислять O совершенно не нужно (не считая того, что далеко не все разработчики вообще помнят про кусочно-непрерывные функции и что такие вообще бывают), просто надо заранее бить шлангом по пяткам за использование потоков данных для затаскивания всех данных в память, когда этого можно избежать. А если при поточной обработке памяти все равно не хватает, то скорее всего проблема с утечками, а не с О.
                                                                                              +2
                                                                                              Все же, сделать File.LoadToString несравнимо проще, чем правильно собрать потоки. Потом ещё окажется, что нужен случайный доступ к записям и придётся ещё что-то изобретать. Конечно, когда речь идёт о миллиардах записей, это все имеет смысл. Но бывает что там файлец-то в пару килобайт, а вы человека шлангом отмудохали. Неудобно как-то.
                                                                                                0
                                                                                                Где файл на пару килобайт, в один момент запихнут файл на гиг-другой. Проверено на практике. Как и где ждешь файлов на диске, обязательно подсунут либо сетевой путь, либо примонтируют папку с внешнего сервера.

                                                                                                А правильно собрать тот же StreamReader для поточной обработки — это дело минуты. Ничего сложного там нет, даже логика обработки данных не изменяется. Это так же естественно, как триммить строки и проверять их на null.
                                                                                                  0
                                                                                                  А потом вам запихнут файл из одной строки на пару гигабайт.
                                                                                                  Совершенно реальный случай.
                                                                                                    0
                                                                                                    Такие случаи — это чаще работа QA по вправлению мозгов юзеров. От Zip — бомбы мы тоже не должны прикрывать пользователей, если нам надо ZIP распаковать.
                                                                                                    На серверной стороне согласен, там лучше быть больным на всю голову параноиком и продумывать все самые бредовые случаи. А еще лучше, когда данные для сервера готовит десктопный софт, пусть даже это свои проблемы создает, за-то защищает сервак от камикадзе.
                                                                                                      +1
                                                                                                      Не защищает. Я помню лет 10 назад мы декомпилировали клиент Утконоса и написали свой, так как штатный был неудобен — не скриптовался и всё такое.

                                                                                                      Там было много интересного, но так как занимался этим не я, то врать не буду про внутренности.

                                                                                                      Но просто как пример: наличие клиента ни от чего не защищает.
                                                                                                        0
                                                                                                        Я согласен, что от целенаправленного стремления положить, ничего не спасет. Защищаться надо прежде всего от глупости обычных пользователей.
                                                                                                        0
                                                                                                        Юзеру надо показать разумную ошибку в таком случае. А не ронять по ООМ весь сервис. С zip бомбой аналогично. QA тут вообще при чем?

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

                                                                                          Не мог не вспомнить в ответ вот это.

                                                                                            +2
                                                                                            Во мой знакомый, синьёр, переходил с core power management одного широко известного в мире производителя мобильных процессоров на отладку видеокарт другого не менее известного производителя (а здания у них через дорогу). И о чём с ним можно было говорить на собеседовании? Без нарушения всех подписок о нераспространении? Только алгоритмика.

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

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

                                                                                            Надо отметить, что решать эти задачи в ходе собеседования не требовалось. Это было задание на дом. Решение, с описанием найденного алгоритма на разговорном языке, отправлялось по электронной почте.
                                                                                              +7
                                                                                              И о чём с ним можно было говорить на собеседовании?

                                                                                              Если ко мне лично придет человек, про которого мне столько известно (в нашем мире все немного иначе, тут нет «три года в core power management в гиганте через дорогу», но аналогий построить можно овердофигища) — я с ним буду разговаривать о жизни за ланчем.


                                                                                              Возможно ближе к кофе мы придумаем вместе три новых «алгоритма на разговорном языке», ему даже писать ничего не придется. Так же, как и я, — выбрасываю, не читая, предложения, отличающиеся от: «Здравствуйте, я — CTO, давайте поговорим за обедом».


                                                                                              Но тут в топике, вроде, речь шла про соисканта без известного в сообществе имени?

                                                                                            +7
                                                                                            Код который программист выложит для просмотра работодателем, может быть написан кем угодно.

                                                                                            Если код выкладывается регулярно на протяжении многих лет, то вряд ли.

                                                                                              0
                                                                                              Согласен. Но не у всех проекты где надо писать открытый код. Скорее у большинства всё по другому.
                                                                                                +2

                                                                                                Ну, в рабочих проектах у меня тоже открытый код писать не надо.

                                                                                              0
                                                                                              del
                                                                                                0
                                                                                                А можно уточнить про книги. Можно и погуглить, но может вы, что то конкретное имел в виду.

                                                                                                Интересно для себя почитать.
                                                                                              +11
                                                                                              Многие программисты хотят попасть в такие компании, потому что там сухо и тепло (и корпоративные ипотеки под низкие проценты). Поэтому компании просто завалены резюме от кандидатов со всех концов страны (или мира). Чтобы хоть как-то отбирать кандидатов, компании приходят к фильтру по алгоритмическим задачам.

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

                                                                                              «Вас много, а я одна!»

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

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

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

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

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

                                                                                                Но тут через Linked-In на меня вышла рекрутер от Яндекса и в качестве испытания предложила тестовое задание, которое нужно было сделать с свободное время и выслать им результат. Неужели они изменили подход к отбору кандидатов? Ведь так работать я умею! Здесь-то я могу развернуться. Потратив пару вечеров я отправил им код и стал ждать ответа. Ждал, кстати, долго: 2-3 недели. Уже даже подумал, что никакого ответа не будет. Но в конце-концов получаю письмо: мол, ваш код нам понравился… И вы выиграли право пройти собеседование. Когда вам было бы удобно пройти тестирование по алгоритмам по Скайпу? Блин, раньше я мог хотя бы провалит собеседование без тестового задания.
                                                                                                  +1
                                                                                                  хахаха :)
                                                                                                  Да сейчас та-же ерунда, сразу вызывают решать задачки, меня недавно без тестового позвали, и да, я теперь так-же теперь их предложений не принимаю (а они продолжают звать) только время терять впустую.
                                                                                                    +1
                                                                                                    Меня как-то HR из Я через L-In пыталась схантить. Объясняю что не ищу работу в настоящее время. Не отстает. «Ну хотя бы просто поговорить, может интересно станет...» Ну ладно, поговорить согласился, вдруг действительно интересно.

                                                                                                    Назначили время на скайп разговор. Так мало того, что «переговорщик» из Я на полчаса перенес разговор, так еще и начал его со слов «я вам сейчас тестовое задание подготовлю...» Сразу ответил, что тестовые задания мне неинтересны, я не ищу работу в настоящее время, и договоренность была исключительно смогут ли ли они меня чем-то заинтересовать, а уж потом, если да, то смогу ли их чем-то заинтересовать я. На том и расстались.
                                                                                                      0
                                                                                                      Как забавно, тут все рассказывают, как они закрываются от назойливых HR Яндекса. А от меня, наоборот, Яндекс закрылся — сначала отвечали мол «вы нам не подходите», а потом просто совсем перестали отвечать.
                                                                                                        0
                                                                                                        Так и мне они говорят: «вы нам не подходите». Только те, кто говорит и те кто хантят — это разные люди.
                                                                                                          +2
                                                                                                          Ниже правильно сказали — это разные люди. А еще ниже тоже правильно — хантеры получают плюсик за каждого, кого они доведут до собеседования.
                                                                                                          Именно с яндексом была полностью аналогичная ситуация — когда искал работу, отправлял им резюме. Ответ «сейчас вы нам не нужны, будем иметь ввиду...» в общем, стандартное «пошел ты...» в вежливой форме.
                                                                                                          А вот когда уже работу нашел и в LinkedIn появилась текущая позиция, так из того же яндекса полезли хрюшки с призывами пособеседовать…
                                                                                                            0
                                                                                                            У меня тоже с ними была подобная ситуация: оттуда обращались ко мне по LinkedIn, когда я не искала работу. Когда искала, то увидев вакансию, которая мне подходила, обратилась к одной из рекрутерок, которые ко мне стучались, и спросила у неё актуальна ли эта вакансия. Она сказала, что да, и попросила резюме у меня. Очень быстро она ответила, что я им не подхожу. Ладно. Процесс поиска работы не затянулся надолго. Уже через пару месяцев после того, как я обновила свой LinkedIn с новой записью, ко мне снова постучались из Яндекса :).
                                                                                                      +6

                                                                                                      Очень хорошая классификация, на мой взгляд.

                                                                                                        +29
                                                                                                        Средний срок жизни разработчика в Гугле — 1 года 1 месяц. Это как бы показатель того, что люди там особо не задерживаются. Причины:

                                                                                                        1) За счет «магии» бренда получают большой поток наивных разработчиков. Вроде деньги предлагают неплохие, но условия всякие типа: вот тебе небольшая зп, вот там раз в год будет бонус огромный (если пройдешь перфоманс ревью), вот тебе акции (которые сможешь получить через 5 лет). Как итог, пообещали много, и по факту хрен это все возьмешь. Как итог, разработчики прикидывают, что лучше свалить в какой-нибудь стартап, который делает мобильные игры и лутать деньги, чем работать в гугле.

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

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

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

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

                                                                                                        __

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

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

                                                                                                              0

                                                                                                              А больших это сколько? Года 3-4 назад HR Я мне предлагал около 300к. Но я к тому времени уже наелся их собеседованиями...

                                                                                                              +20
                                                                                                              Средний срок жизни разработчика в Гугле — 1 года 1 месяц.

                                                                                                              Эта статистика верна только для Mountain View.


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

                                                                                                              ЗП в Google зависят от региона. В Цюрихе, к примеру, вполне можно получать 165.000 CHF на старте (что уже ощутимо выше рынка). Плюс ежегодный бонус 15-20% от зарплаты. Акции выдают не через пять лет, а каждый квартал. В сумме может запросто получится в 2 раза выше рынка уже через год.


                                                                                                              Как правило, в больших компаниях куча своих каких-то инструментов.

                                                                                                              Инструменты в Google такие, что индустрии до них ещё десятилетие расти. К примеру, после Critique (код-ревью тула в Google) от код-ревью на GitHub просто люто, бешено бомбит.


                                                                                                              при переходе в другую компанию твой опыт просто обнуляется

                                                                                                              Я бы не сказал. Умение готовить Protobuf и gRPC много где нужно. Ну и C++ в Google хороший.


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

                                                                                                              Краски сильно сгущены. Политики много, но по ночам никто не работает, и зарплаты никто не снижает.


                                                                                                              Вот такие компании, на всяких собеседованиях относятся к тебе, как говну.

                                                                                                              У меня такое только с Amazon было. От собеседований в Facebook и Google впечатления были очень положительные.


                                                                                                              Яндекса

                                                                                                              Я работал в Яндексе (в Картах), мне там очень понравилось. Много умных талантливых коллег и интересные задачи.

                                                                                                                0
                                                                                                                В Цюрихе, к примеру, вполне можно получать 165.000 CHF

                                                                                                                А есть ли публичное подтверждение? Это не к тому, что я сомневаюсь. Мне хочется ссылку для торговли по зарплате.
                                                                                                                  +1

                                                                                                                  Какого подтверждения вы хотите? Бумагу от гугла что да мы столько платим?


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

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

                                                                                                                      Ну, ориентироваться на Гугл когда тебя приглашают не в него довольно странно :)
                                                                                                                      В среднем по больнице я думаю уровень в 140-150к нормальный, но сильно зависит от.

                                                                                                                        0
                                                                                                                        Ну надо же с каких-то чисел начинать. А так — у всех на слуху. И ожидания и зарплаты подтягиваются к лидерам рынка :)
                                                                                                                    +1

                                                                                                                    Публичного официального нет, есть публичное неофициальное: https://www.levels.fyi/salary/Google/


                                                                                                                    Там после раздела "о компании" и графиков есть фильтрация, можно ввести Zurich и указать L3 или L4 в зависимости от самооценки. :)

                                                                                                                      0
                                                                                                                      Спасибо большое за ссылку.
                                                                                                                      +3

                                                                                                                      165000 франков — скорее всего, L5 в среднем по сложности проекте, или L4 в суровом, серьёзном. L3 (самый массовый уровень) вряд ли будет получать больше 130 тысяч.
                                                                                                                      Ах да, в Яндекс меня не взяли — видимо, я плохо решил задачку на тервер и фигово ответил олимпиаднику-интервьюверу.

                                                                                                                      +1
                                                                                                                      Инструменты в Google такие, что индустрии до них ещё десятилетие расти. К примеру, после Critique (код-ревью тула в Google) от код-ревью на GitHub просто люто, бешено бомбит.


                                                                                                                      Я объективно понимаю, что мой уровень программиста даже близко не дотягивает до уровня гугл, но дико интересно, что такого может быть в коде, что индустрии расти ещё десятилетие.

                                                                                                                      Может вы смогли бы пояснить, дать ссылку или привести примеры, что так координатно выделяет инструменты гугл.
                                                                                                                        +2
                                                                                                                        Ну тут сложный вопрос. Но можно показать на примерах. Ничего не буду говорить про Critique (ибо не сталкивался), но можно показать примере открытых вещей.

                                                                                                                        Как известно Gerrit — это отстой, качмар и ужас. «Новое поколение» так считает, по крайней мере — ибо там с градиентами и модными стилями всё плохо (недавно, правда, сделали новый UI… который безбожно томозит… MaximKulkin будет доволен, я так понимаю — раньше всё работало шустро, хотя выглядело как «привет из 90х», да).

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

                                                                                                                        Ну вот давайте на примере. Вот, например, такое изменение. Что можно увидеть сразу. Две группы CL'ей в правом верхнем углу. Один из них (самый верхний) помечен красным словом «Merged», ещё четыре — чёрным словом «Merged». Почему такая разница? Потому что эти четыре (пять, но об этом дальше) — объединены в общий «topic». Что обозначает, что они должны включаться в репозиторий вместе (или не включаться вместе). А последний CL (с тестом) — он отдельный, его необязательно «подбирать» вместе с другуми.

                                                                                                                        Теперь о том, почему я говорю про про пять CL'ей, хотя вроде как их там четыре? Потому что пятый — вот он. Он идёт в другой репозиторий, но при этом он связан с четырьмя другими — и боты не будут пытаться брать версии в которых его нет (а четыре других есть).

                                                                                                                        Как это сделать в GitHub? Ну вот как мне сделать связанные изменения в Vulkan-Docs, Vulkan-Headers, и в Vulkan-Samples? Я таких способов не знаю. Максимум — можно в описаниях перекрёстные ссылки добавить. Но их GitHub корректировать не будет.

                                                                                                                        Ладно. Идём дальше. Смотрим дальше на то же самое изменение. Обратите внимание на строчку «Patchset 13». Это вообще что такое? А очень просто: этот набор CLей не сразу так, мгновенно, появился. Его долго обсуждали. Если глянуть на «Patchset 1», то видно что вся эта история началась аж в ноябре месяце. И всё это время рассматривалась не большая «каша», а несколько, связанных друг с другом, изменений.

                                                                                                                        Ну обсуждалось, ладно… комментарии друг другу писали, да. Кстати на главной странице вы можете увидеть сразу же и замечания от Lint'а и результаты работы тестов и кучу всего ещё.

                                                                                                                        Из интересно — можно увидеть вот подобные вот ссылки.

                                                                                                                        Где можно обнаружить отдельную, «вложенную» дискуссию даже не по поводу отдельной строки, а по поводу отдельного слова на этой строке (если нужно, конечно).

                                                                                                                        Ну и, конечно, если изменение будет включено не только в одну ветку, а куда-то ещё, то это тоже будет видно (вот пример).

                                                                                                                        Ну вот как-то так. Посмотрев на это — понимаешь: у Гугла — это код-ревью тул. Для того, чтобы аккуратно и вдумчиво обсуждать изменения в код.

                                                                                                                        А вот GitHub и прочием модные штуки… это «социальная сеть», «клуб по интересам», собственно код там дотошно обсуждать не получится. Лишь чуть-чуть более удобно, чем просто в переписке по почте это сделано.

                                                                                                                        Но зато градиенты, стили… это да. Тут всё у GitHub'а отлично.
                                                                                                                          +2
                                                                                                                          Потому что эти четыре (пять, но об этом дальше) — объединены в общий «topic».

                                                                                                                          Угу. В GH «топик» называется «пулл реквест», но это слишком молодежно, наверное.


                                                                                                                          Ну вот как мне сделать [в GH] связанные изменения в Vulkan-Docs, Vulkan-Headers, и в Vulkan-Samples?

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


                                                                                                                          Посмотрев на это — понимаешь: у Гугла — это код-ревью тул.

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


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

                                                                                                                            0
                                                                                                                            (Если обязательно нужно, чтобы это решала система контроля версий — зонтичный проект с подмодулями пойдет).
                                                                                                                            И как в этом «зонтичном проекте» увидеть как изменения в разных проектах между собой связаны?

                                                                                                                            GH далек от идеала, но вот эту кашу из ста восьмидесяти пяти разных типов информации, впихнутых на один экран просто потому, что можем (я удивлен, что температура в Антананариву там не указана где-нибудь в уголочке) — я искренне мечтаю не увидеть больше никогда в жизни.
                                                                                                                            Увидите ещё. Когда-то этот же путь прошли IDE. От лаконичных редакторов без излишеств — вот к примерно такому же нагромождению тулбаров и панелей.

                                                                                                                            Например, обсуждение внезапно может не быть привязано к коду.
                                                                                                                            Если, внезапно, ваше обсуждение не привязано к коду — то его можно хоть в WhatsApp вести. А вот если привязано — то Gerrit (и вышеопомянутый Critique, я думаю) — такие средства предоставляет, а вот GitHub — нет. Ну или, по крайней мере я не нашёл таких способов, чтобы можно было ткнуть в конкретную строчку и спросить «а что, собственно, тут происходит?»… ну или сравнить 5й patch в наборе в той версии в какой он был год назад с тем, что случилось сейчас.

                                                                                                                            Что самое забавное — ведь изначально именно под это Git был заточен. Ради подобных обсуждений Линус его вообще сделал. Хотя у разработчиков ядра всё заточено под работу через почту, что несколько, слишком хардкорно всё же.

                                                                                                                            Вместо того, чтобы ткнуть в конкретное непонятное место приходится устраивать дискуссиию… чего на практике мало кто делает, потому что для подхода «тяп-ляп и в продакшн» — этого действительно не нужно.
                                                                                                                              +2
                                                                                                                              Увидите ещё. Когда-то этот же путь прошли IDE.

                                                                                                                              Лишняя причина никогда не использовать никаких IDE.


                                                                                                                              по крайней мере я не нашёл таких способов, чтобы можно было ткнуть в конкретную строчку и спросить «а что, собственно, тут происходит?»

                                                                                                                              Ну так вы попробуйте разок-другой code review в GH сделать, сразу и найдете, это не рокетсайнс.

                                                                                                                                0
                                                                                                                                Ну так вы попробуйте разок-другой code review в GH сделать, сразу и найдете, это не рокетсайнс.
                                                                                                                                Ссылок, я так понимаю, не будет? Следов от этой деятельности не остаётся?

                                                                                                                                Что это за код-ревью система тогда такая тогда?

                                                                                                                                P.S. И нет, я не говорю, что в GH это сделать невозможно. Вопрос в том — насколько это удобно и насколько легко человек может потом что-то с этим замечаниями сделать. Ведь если это code review (в переводе «пересмотр кода») — то, логичено, что после дискуссии что-то с этим кодом нужно делать (а иначе зачем его reviewить?).
                                                                                                                                  +1
                                                                                                                                  Ссылок, я так понимаю, не будет?

                                                                                                                                  Мне неохота, знаете ли, ради каждого невежды — скриншоты ходить делать, да ссылки аккуратно выискивать. Но вот там ниже товарищ не такой ленивый, пользуйтесь.

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

                                                                                                                                    Возможность комментария к каждой строчке помечена «New!» — значит, для них действительно рокетсайнс ещё совсем недавно. Когда оно появилось-то?

                                                                                                                                    Как насчёт получить разницу между несколькими версиями предложения одного и того же изменения (patchsetʼами в терминах Gerrit; например, 3-м и 8-м), и с комментариями к ним?

                                                                                                                                    Как насчёт автоопределения типа изменения (по сути, rebase, поправлено только сообщение...) сервером? (писать это в commit message самого автора — не просить)

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

                                                                                                                                    Найдётся кто-нибудь достаточно неленивый, чтобы хотя бы сказать «нет, не умеем» или «это будет через год»?
                                                                                                                                      0
                                                                                                                                      Возможность комментария к каждой строчке помечена «New!»

                                                                                                                                      Не уверен, что значит «помечена», но я ей пользуюсь уже несколько лет точно.


                                                                                                                                      получить разницу между несколькими версиями предложения одного и того же изменения

                                                                                                                                      WAT? Зачем? Если это нужно, то весь процесс разработки никуда не годится, менять надо всю команду, а не систему контроля версий.


                                                                                                                                      автоопределения типа изменения

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


                                                                                                                                      В сложных случаях это очень критично.

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


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

                                                                                                                                        0
                                                                                                                                        > Не уверен, что значит «помечена», но я ей пользуюсь уже несколько лет точно.

                                                                                                                                        «Помечена» — тыкаю и появляется «New! Suggest specific code changes that the pull request author or assignees can immediately commit. You will be attributed in the commit.»

                                                                                                                                        «Несколько лет» это сколько? Я последний раз активно смотрел где-то года 4 назад — ещё не было, в то время как в Gerrit это давно стало банальностью.

                                                                                                                                        > WAT? Зачем? Если это нужно, то весь процесс разработки никуда не годится, менять надо всю команду, а не систему контроля версий.

                                                                                                                                        Прошу объяснить причины такого вывода. Я, наоборот, считаю, что без этого нормальной работы нет. Например, к patchset 1 сделано несколько орфографических замечаний. Я пишу «всё ok, кроме орфографии, исправьте», помечаю места. Автор выкатил patchset 2. Я открываю дифф между ними и вижу, что орфография исправлена и больше ничего не трогалось => мне не нужно его пересматривать заново.
                                                                                                                                        Что вы плохого видите в таком подходе? Почему вдруг это «процесс разработки не годится»? Объясните.

                                                                                                                                        > Не очень понял, что это, и зачем. Никто в здравом уме ребейзы пустыми обратно не коммитит, это очевидный антипаттерн.

                                                                                                                                        Что значит «обратно»? Есть цепочка, например, из 3 коммитов. Первый надо было править, 2 и 3 — не нужно, там всё нормально. В новом предложении 2 и 3 оказываются только rebased, изменений в их сути нет.

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

                                                                                                                                        Сейчас это выглядит как чистейшая религия. У вас есть обоснование этому тезису?
                                                                                                                                          0

                                                                                                                                          «Suggest specific code changes» ≠ «Возможность оставлять комментарии к каждой строке кода».


                                                                                                                                          Я открываю дифф между ними и вижу

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


                                                                                                                                          2 и 3 оказываются только rebased

                                                                                                                                          Кошмар какой. А сто человек вокруг уже черри-пикнули коммит 2. Я бы убил человека, который так делает.


                                                                                                                                          У вас есть обоснование этому тезису?

                                                                                                                                          Нет.

                                                                                                                                            0
                                                                                                                                            > Это пожалуйста, «изменения, которых вы не видели» называется, с незапамятных времен есть.

                                                                                                                                            Оно само определяет, какие изменения я видел? Это же не фейсбук, для которого AI с функцией «этого котика он ещё не видел, давайте покажем» помогает в 99% случаях, а на 1% можно и наплевать.

                                                                                                                                            > Сравнивать третий и восьмой патчсеты не нужно никому.

                                                                                                                                            Использую несколько раз в неделю при анализе чужих ревью, потому что нормально, например, что 4 и 5 возникли как rebase от автора, а остальные — в ответ на комментарии других ревьюеров, а я в это время был занят чем-то более важным/срочным и не мог реагировать на каждый новый патчсет (хотя я его открыл и увидел, что идёт какая-то полезная возня).

                                                                                                                                            > Кошмар какой. А сто человек вокруг уже черри-пикнули коммит 2. Я бы убил человека, который так делает.

                                                                                                                                            Зачем им черипикать чужой коммит, который ещё только на рассмотрении и не одобрен? Вы вообще пытаетесь понять контекст?

                                                                                                                                            > Нет.

                                                                                                                                            Ну тогда от меня только соболезнования, но вы ничего не смогли доказать. Спасибо за участие.
                                                                                                                                              0

                                                                                                                                              Я не пытался ничего доказывать.


                                                                                                                                              Я отвечал на бессмысленные (с моей точки зрения) вопросы, местами неверные (как про построчные комментарии, которым сто лет), местами требующие от кофеварки умения бегать за пивом (у вас rebase собственных коммитов → вызывает нужду сравнивать 3 и 8 патчсеты, и вы спрашиваете, почему ни то, ни другое не доступно в GH).


                                                                                                                                              Зачем им черипикать чужой коммит, который ещё только на рассмотрении и не одобрен? Вы вообще пытаетесь понять контекст?

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


                                                                                                                                              Оно само определяет [...]

                                                                                                                                              Оно показывает изменения с момента вашего последнего ревью. Этот кейс покрывает 99% нужд при правильном использовании инструментов.


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

                                                                                                                                                0
                                                                                                                                                > Я просто не вижу смыс