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

Original author: Adam Storm
  • Translation
Представьте себе, что вы директор маленькой средней школы, который ищет нового учителя. Поскольку у вас в штате менее 20 учителей, вы должны убедиться, что каждый человек, которого вы нанимаете, может преподавать во всех классах. Кроме того, вы недавно потеряли одного из своих лучших учителей, человека с 15-летним опытом и наставника для более молодых коллег. Как вы замените его? Вот тут-то и начинается занятное.




После неких размышлений вы придумываете то, что считаете творческим подходом к собеседованию. Когда кандидаты появятся, вы попросите их провести урок из учебной программы средней школы [от 5-6 до 14 лет]. Вы хотите убедиться, что кандидат хорошо подготовлен, так что не станете рассказывать ему о том, какой урок хотите увидеть, до начала собеседования. Если кандидаты поймут тему, вы сделаете вывод, что они смогут легко научить чему-либо, поскольку они явно хорошо проявили себя под давлением по случайно выбранной теме.

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

Затем наступает день собеседования, и ваш кандидат появляется в школе. Вы можете почувствовать, что она немного нервничает, а это странно, потому что она опытный учитель с безупречным резюме. Вы решаете не зацикливаться на этом и вместо этого приглашаете учительницу в один из ваших классов, чтобы начать собеседование. «Я бы хотел, чтобы вы провели урок по теории чисел». В этот момент её лицо опускается: вы не знали, что она не преподавала в 8 классе более 10 лет. Но как профессионал она идёт к доске и начинает урок. Рассказывает о множителях чисел и о том, как определить, делится ли данное число на 2, 5 и 10, но делает это с трудом. Когда вы спрашиваете о НОД и НОК, ей нужно разъяснение аббревиатур, а вы расцениваете это как плохой знак. Вы объясняете, что имеете в виду «наибольший общий делитель» и «наименьшее общее кратное», но теперь вы можете сказать, что её уверенность подорвана, а кроме того, улавливаете раздражение в её голосе.

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

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

Почему? Если говорить просто, сеньоры отличаются друг от друга, и типичное собеседование с программированием ставит их в невыгодное положение по ряду причин. Итак, такие собеседования:

  • Отнимают массу времени на подготовку — поскольку собеседования с программированием черпают вопросы из всей области разработки программного обеспечения, к ним очень трудно подготовиться полностью. Эта проблема усиливается для сеньоров несколькими способами. Прежде всего, по определению, они далеко отошли от первоначального обучения, при котором, возможно, в последний раз сталкивались с некоторыми эзотерическими аспектами разработки программного обеспечения, такими как динамическое программирование, красно-чёрные деревья или даже рекурсия. Обновление в памяти широкого спектра алгоритмов и структур данных может занять значительное количество времени на подготовку. Добавьте к этому тот факт, что сеньоры стеснены во времени (у них есть неотложные задачи и часто значительные личные обязанности), и всё это идеальный шторм. Я знаю несколько случаев, когда сеньоры интересовались процессом собеседования у работодателя и, услышав, что было собеседование с программированием, отказались от него.
  • Заставляют работать по-другому — сеньоры далеки от голых сред разработки, которые используются на собеседованиях с программированием. Как правило, их среда разработки хорошо настроена и совершенствовалась в течение многих лет для того, чтобы освободить их от ненужного труда. Отнять среду в тот момент, когда есть не менее значимые искусственные ограничения по времени, — значит, поставить их в весьма невыгодное положение. Кроме того, они, возможно, провели последние несколько лет, работая с собственными библиотеками (управления памятью, проверки ошибок, трассировки) у своего нынешнего работодателя. Собеседование с программированием резко выводит их из зоны комфорта, возвращая в мир стандартных библиотек и простых текстовых редакторов.
  • Не проверяют то, что вы хотите от разработчиков после найма — возможно, самая вопиющая сторона применения собеседования с программированием к сеньорам заключается вот в чём: такое собеседование проверяет только небольшую часть того, для чего вы их нанимаете. Сеньоры обычно делают в 3-5 раз больше (или даже ещё больше), чем свежеиспеченный выпускник. Ожидать, что сеньор напишет в 3–5 раз больше кода, чем выпускник, очевидно, неразумно: просто не хватит времени. На самом деле вы ищете их, чтобы они помогли команде джунов и мидлов, наставляли такие команды, выявляли системные проблемы, отлаживали самые сложные проблемы, понимали сложные системы и выполняли запутанную работу, необходимую при программировании внутри этих систем. Ни один из этих аспектов не проверяется на собеседовании с программированием, и это одна из главных причин, почему сеньоры ненавидят их.
  • Они сами по себе плохой сигнал — вы понимаете, что не нанимаете сеньоров для программирования, и они тоже это понимают. Но когда вы подчёркиваете важность собеседования с программированием в процессе найма, вы заставляете сеньоров сомневаться в роли, для которой нанимаете их. «Они что, просто хотят, чтобы я был кодирующей обезьянкой? Неужели я буду растрачивать здесь свои таланты? Это шаг вперед или шаг назад?» Меньше всего вы хотите, чтобы талантливый разработчик сомневался в своей роли или в вашей компании в процессе собеседования. Когда вопросом становится кодирование на собеседовании, происходит именно это.

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

Но, возможно, вы думаете о том, как сможете узнать, могут ли кандидаты программировать? Если вы с подозрением относитесь к найму разработчика такого уровня, не ощутив его способностей к программированию, я бы предложил вам дать очень короткое задание (которое занимает не более часа или двух и выполняется им дома). Большинство должны быть в состоянии найти небольшое количество времени для выполнения такого задания, особенно по той причине, что оно исключает работу по подготовке, необходимую для собеседования с программированием, и может быть разбито на временные отрезки, которые лучше вписываются в их напряженный график. Задание также позволяет им работать в своей родной среде IDE (если они этого захотят) и потратить любое количество времени для повторного знакомства со стандартными библиотеками.

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

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

А вам приходилось участвовать в таких проблемных собеседованиях?

image

Как обычно, промокод HABR — добавит 10% к скидке на обучение, отраженной на баннере.


SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Comments 435

    +58

    А еще дайте гуглить. Если у вас кто-то из сеньоров говорит, что работает без вечного гуглинга — увольняйте, он врет =)

      –33
      Весь вопрос что именно гуглить. Если «сеньор» лезет искать пример по поиску максимального числа в массиве… А это реальные случаи, между прочим.
        +36

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

          –24

          Такое не лучше гуглить. Задача поиска максимального числа в массиве решается в голове быстрее, чем открывается новая вкладка в браузере. Если кандидат действительно гуглит это, я боюсь, это red flag.

          • UFO just landed and posted this here
              –10

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

                +13
                Ну, допустим, что в C# с LINQ это будет что-то типа array.Sum()
                Это я помню. А почему я не могу глянуть в документацию, если мне нужно что-то чуть сложнее, например, Aggregate оттуда же? Я обязан помнить порядок всех аргументов?
                И это реальный кейс, который со мной случился вот прям сегодня. Я работаю как фулстэк и я помню, как в JavaScript сделать reduce, а что в шарпе у Aggregate начальное значение задаётся первым аргументом, а не последний, я забыл.
                Это всё, да, red flag?
                  +5

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


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

                    +3
                    Простите, я ошибся, нужно было использовать array.Max(), а не array.Sum(). Это уж точно red flag.

                    int max = 0;
                    
                    if (array.Length > 0)
                    {
                        max = array[0];
                    }
                    
                    for (int i = 1; i < array.Length; ++i)
                    {
                        if (array[i] > max)
                        {
                            max = array[i];
                        }
                    }

                    Нет проблемы это расписать. Но есть проблемы в реализации.
                      +1

                      Вот у людей есть проблемы с тем, чтобы это написать. Над такой задачей можно просидеть все 45 минут интервью и закончить решением за O(n^2). К сожалению, я не шучу.

                        +7
                        Если вы считаете, что алгоритм поиска максимального числа в массиве очевиден — возможно вы просто недостаточно квалифицированны чтобы задавать такие задачки на собеседовании? А?

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

                        Если уж вы тут заговорили о вычислительной сложности алгоритма сразу уточняющий вопрос — а какова длинна массива? А какой тип данных? А какой компилятор? На чё спорим, что при достаточной длине массива в C# будет эффективнее будет фикснуть массив и пройти по нему указателем в ансейфе? А если вы компилитесь через IL2CPP то лучше просто поставить директиву компилятора отключающую проверку границ массива, и которую я без гугла или подглядывания в своей проект ни в жизни не вспомню. А точно ли компилятор догадается, что два упоминания array[i] в теле цикла это одно и то же число и сунет его в регистр, или нужно ему на это указать.

                        А как должна обрабатываться исключительная ситуация когда элементов в массиве 0? Вы даже не обратили на это внимание, а между прочим такой код может подкинуть вам проблем.

                        А компилятор точно справится с оптимизацией прохода по массиву не с начала? А то вы рискуете нарваться на проверку Array bounds и доставание array.Length каждый раз из памяти.

                        И наконец самый главный вопрос, если вы рассчитываете составить о синьёре суждение на основании ответа на ТАКОЙ вопрос, может быть синьёру не стоит с вами работать?
                          0
                          А точно элементы в массиве не упорядочены хотя бы частично?

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


                          Если уж вы тут заговорили о вычислительной сложности алгоритма сразу уточняющий вопрос — а какова длинна массива?

                          Если мы говорим про C#, то input.Length, где input — это название переменной/параметра.


                          А какой тип данных?

                          Чаще всего в таких задачах пишут "целых чисел, вот пример — [3, 2, 5]". В любом случае, можно спросить, или же решить задачу для более общего случая, там где на вход передается IComparer.

                          А какой компилятор?

                          Мы про C#? Вроде, эта задача решается более-менее одинаковым кодом, начиная с .Net 2.0.


                          На чё спорим, что при достаточной длине массива в C# будет эффективнее будет фикснуть массив и пройти по нему указателем в ансейфе?

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


                          В любом случае — алгоритм-то будет тем же самым, просто реализация немного иная.


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

                          Если мы говорим про "синьора", то кандидат и так знает, что foreach оптимизирован так, чтобы не было проверки массива. Да и стандартные циклы до .Length тоже иногда оптимизируются.


                          А так — комментарий хороший, хоть и не влияет на сам алгоритм.


                          А точно ли компилятор догадается, что два упоминания array[i] в теле цикла это одно и то же число и сунет его в регистр, или нужно ему на это указать.

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


                          А как должна обрабатываться исключительная ситуация когда элементов в массиве 0?

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


                          А компилятор точно справится с оптимизацией прохода по массиву не с начала? А то вы рискуете нарваться на проверку Array bounds и доставание array.Length каждый раз из памяти.

                          Если интервьювера заботит этот вопрос, то он может спросить. Или же кандидат может ответить, если это действительно важно.


                          И наконец самый главный вопрос, если вы рассчитываете составить о синьёре суждение на основании ответа на ТАКОЙ вопрос, может быть синьёру не стоит с вами работать?

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

                            0
                            Если кандидат простые задачи начнет решать через unsafe, то вопрос, выявивший подобное, уже сразу становится хорошим классификатором

                            Зачем тогда в видеокартах делают много ядер, которые решают 'простые' задачи, ведь засунуть данные в неё зачастую отдельный кодинг, муторнее чем тот же unsafe?
                              0
                              1. В изначальном комментарии есть фраза "Допустим C# синьер к вам на собеседование пришёл". И нигде не говорится, что код пишется для видеокарту, или же что задача должна быть оптимизирована по-максимуму. И будем честны, что в большинстве случаев код на C# означает именно managed код, без дополнительных усложнений.
                              2. Если у кандидата есть опыт оптимизации ПО, то можно было бы так и сказать "а хотите я на unsafe код оформлю, плюс приложу benchmark, что такой код работает быстрее?" После решения основной задачи тогда можно было бы классно поговорить на эту тему, если требуется. Но, по моему опыту, чаще всего специалист от компании просто ответит "нет, спасибо".
                              3. Если кандидат вместо решения такой простой задачи как "поиск максимума в массиве" начинает говорить про космически корабли и видеокарты, то начинает создаваться впечатление, что или человек слишком сеньорный (и ему надо идти в Facebook/Google), или что человек просто не хочет писать сейчас код на собеседовании. В обоих случаях правильнее всего будет поблагодарить за потраченное время и распрощаться, чтобы не было неоправданных ожиданий.

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

                                0
                                Вы бы не наняли меня, а я бы не стал нанимать вас, только и всего. Причём это, на самом деле даже хорошо потому что если:
                                в большинстве случаев код на C# означает именно managed код, без дополнительных усложнений.
                                Значит у вас, скорее всего нет задач, ради которых следовало бы привлекать меня. А задачи которые встают передо мной вы, скорее всего, просто на сможете сделать.

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

                                ФАтальная ошибка — думать, что хороший код нужен только гуглу с фейсбуком. Я работаю на C# для Unity и там оптимизация необходима примерно всегда если ваш проект хоть чуть-чуть поднялся над уровнем Indi (но не во всех частях проекта безусловно), потому что FPS сам себя не алё.

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

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


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

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

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

                                    Вообще, по опыту найма с hh.ru я по виду резюме обычно мог определить тех людей, которых стоит приглашать. Но надо сказать, что шанс ошибиться тут больше, а времени и техлида на такую сортировку тоже уходило больше.
                                      0
                                      Просто если не написал простой код, то смысла гонять по архитектуре?

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

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

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


                                        Однако, вернемся к вопросу. В MBA практиках (если так можно сказать, так как литература там определена не совсем четко) есть разделение управленческих позиций на две группы — "исполнительный директор" и "управляющий директор". Первая группа — это не только управленцы, но и довольно неплохие спецы. То есть, условно, скрипт на питоне написать человек сможет, а потому человек способен разобраться в деталях того, что происходит. Вторая группа вообще не обязана быть специалистом в управляемой области. Но "управляющий директор" не выбирает способа, он обязан всегда полагаться на советы экспертов. По карьере получается так, что из специалиста сначала вырастает "исполнительный директор", который потом, после курсов MBA, может работать управляющим. Эти люди стоят очень дорого (насколько я смотрел в интернете — около £200.000 будет минимальная общая компенсация в год), а потому, если кто-то с зп менее 1млн рублей пытается выдавать себя за птицу высокого полета, то будет разумный вопрос — "а почему бы данной персоне не пойти на более высокий оклад в крупную компанию?"


                                        Другой важный вопрос, который Вы неявно подняли, это соответствие должностей в разных компаниях. Архитектор в небольшой компании на 50 человек запросто будет middle developer'ом в крупной компании, что по зарплате, что по уровню знаний (кстати, тут я привел реальный пример из жизни).


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

                          +2
                          Удалено, ибо я очень невнимателен этим утром
                            +5
                            По-моему, надо так
                            int max = int.MinValue;
                              +1
                              Метод .Max() в таком случае бросит исключение. И правильно сделает. Потому что по условию задачи совсем непонятно, что нужно делать, когда элементов в массиве вообще нет. И возвращать ноль или int.MinValue в данном случае — одинаково бессмысленно.
                                +2
                                И возвращать ноль или int.MinValue в данном случае — одинаково бессмысленно.

                                Нет, не одинаково. int.MinValue является единицей, и min и int.MinValue образуют моноид (точно так же, как ноль является единицей для сложения, и они вместе тоже образуют моноид). Возвращать int.MinValue осмысленно настолько же, насколько осмысленно возвращать 0 из гипотетического Sum() или 1 из Product(). Что, кстати, делает имеющаяся у меня под рукой реализация:


                                GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
                                ג> sum []
                                0
                                ג> product []
                                1

                                Вот кидать исключение (а лучше — возвращать Nothing или аналог) для функции расчёта какого-нибудь среднего арифметического для пустого массива уже логичнее, да.

                                  0
                                  Возвращать 0 в качестве максимального элемента, когда в массиве все элементы < 0, тоже неправильно.
                                  • UFO just landed and posted this here
                              0
                              Ваша задача требует некоторых уточнений — к примеру, оценки размера массива. Потому что поиск максимума в массиве гигабайт так на 50 — это несколько другой алгоритм. Будете потом удивляться что «кандидаты не знают классику».
                                +1
                                Ага, на 50 гиг уже можно юзать распаралеливание на шейдерах например, а ну кто там за 15 мин на псевдокоде набрасает) И как это потом оценивать? В том то наверно и разница джуна и сеньера. Первый без вопросов напишет этот стандартный код, второй вначале всесторонне обдумает, примет решения по всем возможным вариантам. И как вариант вообще обойдется без этого поиска ))))
                                  +1

                                  А смысл в параллелизме, если для такой задачи все равно все упрется в шину памяти?

                                    0
                                    Я ж и говорю, что для более опытного разраба такая задача встает в другом свете. В свете его опыта работы над другими проектами. Может упрется, а может и нет уже. Зависит от железа. А может этот функционал можно реализовать гдето в другом месте, например в АПИ доступа к данным и не «упирать» лишний раз. Это стандартное мышление опытного разработчика. Потому как если вопрос дошел до него, значит там есть реальная сложность. Боюсь что в реальной жизни сеньер на такую задачу потратит больше времени чем все интервью) Вначале все перегуглит в поисках ответа почему этот примитив еще не реализован, потом всю ночь в его мозгу будет вариться архитектура решения. И возможно в будущем это будет работать хорошо, но это не точно ) Студент же выдаст «правильный» ответ в пару минут.
                                      0
                                      Скорее, синьор даст ответ в той архитектуре, в которой ему приходится работать сейчас. Точно так же, как стандартные библиотеки для разных архитектур имеют довольно сильно отличающиеся реализации — при абсолютно одинаковых API.
                                    0
                                    Бог с ними, с шейдерами — давайте начнем с того, имеет ли смысл держать в памяти весь массив или лучше читать блоками, вспомним по дороге про отображение файлов в память и так далее.
                                0
                                Я работаю как фулстэк и я помню, как в JavaScript сделать reduce, а что в шарпе у Aggregate начальное значение задаётся первым аргументом, а не последний, я забыл.

                                А в шарпе типы разве не помогут?

                                  +1
                                  В шарпе типы конечно сразу все расставляют по местам, но тут то явно речь о написании кода «на бумажке», а не в IDE.
                              • UFO just landed and posted this here
                                  +4

                                  Первое может вполне попасться подзадачей в каком-нибудь гугле или фейсбуке.


                                  Топологическую сортировку в разных формулировках вполне задают в FANNG и FAANG-like конторах, да. Её при этом необязательно знать, чтобы суметь написать работающий алгоритм.

                                  • UFO just landed and posted this here
                                      +4

                                      Сказать слово (или даже фонему) — тоже. Продолжаете доводить до абсурда, да?

                                      • UFO just landed and posted this here
                                      0
                                      проблема в том, что это не показатель. И, как пример, там в соседней статье как раз бывший гуглопрограммист жалуется на жизнь, что они собрали систему и за день просрали 72килобакса. Ну зато все списки и мапы разложены как надо вместе со всеми деревьями.
                                      –3

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


                                      90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…


                                      Ну и читаем классиков.

                                        +12
                                        90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…

                                        наверное потому, что 90% людей за 20 лет работы ни разу не приходилось работать со связными списками

                                        Если для вакансии умение работать со связными списками критично — выставляйте в требованиях.
                                        Если нет — то зачем это проверять.
                                          +3

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


                                          Проверяют не умение работать с X а наличие каких-то знаний и умений позволяющих работать с X.


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


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

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

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

                                            Проверяют не умение работать с X а наличие каких-то знаний и умений позволяющих работать с X.

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

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

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

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

                                            Угу, и получите классическую среднюю температуру по больнице. Которая ничего не говорит о конкретике. Например, что у человека последняя стадия рака. Но градусник сказал что здоров — значит здоров.
                                              –1
                                              Хотите проверить понимание абстракций — спрашивайте про абстракции.

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


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

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


                                              Например, что у человека последняя стадия рака.

                                              Я не писал, что буду проверять только температуру.

                                                +1
                                                Мне хочется проверить навыки и умения.

                                                Вы уходите от темы.
                                                Мой комментарий был про возмущение про то, что
                                                90% приходящих людей с 20-летним опытом работы не понимают, что такое связный список…

                                                типа это п… ц, а не программист.

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

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

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

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


                                                  И не упомянули никакой другой проверки.

                                                  Навеяло

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


                                                  Проверки всегда комплексные. Обычно когда спрашивают "полезен ли X" имеют ввиду "есть ли контекст в котором X полезен" а не "всегда ли полезен только X".


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

                                                    +1
                                                    Одно дело, если он не знают, что означают эти слова «связанный список»

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

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

                                                    Тут был бы уместен пример общего знания :)
                                                      0
                                                      Уже упоминали те же массивы и списки, без которых не обходится ни одна более-менее сложная программа.

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

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

                                                        Что именно массивы и списки? Поиск максимального значения в массиве тут забраковали :)

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

                                                        Околореальные задачи бизнеса уж точно не являются общим знанием.
                                                          +2
                                                          Поиск максимального значения в массиве тут забраковали :)

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

                                                          Околореальные задачи бизнеса уж точно не являются общим знанием.

                                                          Зато позволяют оценить, как человек думать и работать будет.
                                                          Хз, что и в какой пропорции важнее — знание или практика. Серебряной пули точно нет.

                                                          Хотите проверять теорию и общие знания — берите «учебник информатики» и ковыряйте вопросы оттуда.
                                                          Но будьте готовы к тому, что выпускник без опыта эти на вопросы сможет отвечать лучше, чем чел с 10+ годами опыта.
                                                          Хотите полезного работника — проверяйте практическими задачами.
                                                          При этом оба параметры важны, и нужно как-то комбинировать, чтобы отсекать людей без опыта и с опытом гугления, но без понимания сути.
                                              +3

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


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

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

                                                Изначально речь шла про связный список. Который в индустрии используется ОЧЕНЬ редко из-за его специфичности.

                                                Цель — проверить умение программировать вообще — решать программистские задачи. Какие поставят — такие и решать.

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

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

                                                    +4
                                                    Не надо знать, как обращать связные список, но надо понимать, как он устроен

                                                    Ещё раз — неумение работать со связным списком говорит лишь о незнании связных списков. А не о том, сможет ли человек с ним работать.

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

                                                Гы. Требуется программист со знаниями: односвязных списков, поведением знаковых/беззнаковых целых при переполнении в (список языков), условий допустимости использования сортировки пузырьком.

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

                                                  условий допустимости использования сортировки пузырьком

                                                  Моей фантазии не хватает представить, зачем это знание нужно кому-то за пределами института. С таким же успехом можно о различии поэтов серебряного века порассуждать.
                                                  В 99% случае всё, что надо знать о сортировке — это что она вызывается из библиотеки Math или подобной. Всё остальное нужно либо в 1% случаев (если не меньше), либо ведёт к появлению костыльных велосипедов.
                                                    0
                                                    Сложилось устойчивое мнение, что для фронта это не надо никогда. Я про реализацию сортировки вручную, а не нативными методами .sort((el) => a — b).

                                                    На клиенте нет Big Data, и быть не должно.

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

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

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

                                                      Но в 1% это помогает и на фронте тоже иногда, когда он очень запутан. Не количеством данных, а сложностью алгоритма.

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

                                                      Мне в своё время сильно понравилось такое высказывание про квалификации программистов: джюниор умеет решать простые задачи простыми методами, мидл — сложные задачи сложными методами, сеньор — сложные задачи простыми методами.
                                                      По ощущениям, к вашему примеру это высказывание очень хорошо подходит.
                                                      При наличии хоть какого-то запаса времени лучше разобраться со структурами зависимых данных, чтобы с ними проще работать было, чем в имеющуюся сложность ещё свою сортировку запихивать.
                                                        0
                                                        Столкнулся как-то раз с необходимостью на C# выбрать 20 наибольших чисел из 300-10000. В готовых библиотеках ничего подходящего не нарыл. Может плохо копал, конечно. Но в целом иногда задачи на сортировку встречаются даже в реальности.
                                                          +1
                                                          Это задача на последовательное применение 2 операций: array.Sort().Take(20);
                                                          Никаких самописных велосипедов тут и близко не надо.
                                                            0
                                                            В первом прототипе в конце концов я так и оставил. Потому что для маленького исходного числа я так и не смог сделать лучше чем вот это. :) Но дело в том, что уже в следующей версии мне нужно было сделать это для, например миллиона чисел, и там решение близкое к o(n*log(n)) уже будет выглядеть немного не очень.
                                                              0
                                                              Для миллионов и более — могут быть ньюансы. Но для одномерных списков — скорее всего некритичные.
                                                              Но в любом случае — своей сортировки здесь не видно. Сортировать тут имеет только свой массив Топ20, чтобы последний(минимальный) его элемент сравнить с текущим значением из большого массива. Тогда сложность прохода по большому массиву будет o(n), а сложность сортировки массива 20 элементов, которая будет вызываться неопределённое кол-во раз (>=20, но по вероятности сильно < n) — скорее всего ничтожна, по сравнению с миллионами основного массива. Остаётся правда краевой момент с полностью отсортированным исходным массивом. Но кастомной сортировкой он всё равно не решится.
                                                              Но соглашусь, именно поиск максимумов тут получится самописный.
                                                              Хотя с точки зрения стоимости написания и отладки кастомного алгоритма, возможно можно пренебречь повышенной сложностью при использования стандартных методов, т.к. в рантайме даже при миллионах счёт, скорее всего, всё равно на доли секунды будет.
                                                                0
                                                                Всё так, но к сожалению пренебречь в рантайме я не мог. Основной вопрос, который интересовал — имеет ли смысл держать свой массив размером 20 в отсортированном состоянии или просто держать в отдельной переменной минимум и при каждой замене находить новый минимум и элемент который нужно заменить полным проходом. Этот вариант показал себя чуть лучше. Видимо за счёт того, что не нужно было сдвигать пол массива вниз каждый раз при добавлении нового элемента. Впрочем, это, возможно, особенности реализации.
                                                                  0
                                                                  имеет ли смысл держать свой массив размером 20 в отсортированном состоянии или просто держать в отдельной переменной минимум и при каждой замене находить новый минимум и элемент который нужно заменить полным проходом. Этот вариант показал себя чуть лучше

                                                                  Охотно верю.

                                                                  Но вернувшись к нашим баранам — весь этот алгоритм к кастомной сортировке пузырьком или как-либо по другому это не имеет отношения. Сортировка, в итоге, может использоваться стандартная из библиотеки.
                                                                  А можно вообще без неё обойтись, что, похоже, и получилось в итоге, т.к. задача свелась к поиску максимумов/минимумов в 2 массивах.
                                                                    0
                                                                    Ну при поддержании отсортированного массива там кроме первых 20 элементов тоже получается не коробочной сортировкой. Выгоднее поиск места для вставки за log(n) делением пополам и вставка сдвигающая пол массива вниз, o(n) но часто меньше, потому что очень быстро возникает ситуация, что новые элементы попадают в самый низ списка. Так получается меньше сравнений, которые не предиктятся процессором (что несколько не совподает с устаревшей логикой о-маленького).
                                                                      0
                                                                      ИМХО, экономия на спичках.
                                                                      Если остались какие-то цифры (хотя бы в голове) от итоговой (всего алгоритма) разницы с коробочной сортировкой — с интересом выслушаю.
                                                                  0

                                                                  Эту задачу, кстати, я спрашивал на интервью в гугл, пока ее не забанили за извесность.


                                                                  Тут не надо никаких 20 элементов много раз сортировать! Вот зачем нужно знать алгоритмы.


                                                                  Тут можно, например, вместо сортировки использовать pritority_queue какой-то (храните в очереди на минимум 20 максимальных пока найденных элементов. Новый элемент или вытесняет минимум, или идет лесом).


                                                                  Тогда вместо O(n log n) будет O(n log k) — при n=10^6 и k = 20, это ускорение в 4 раза. Плюс к этому оно сильно дружнее к кэшу и вообще константа у этого решения меньше. К сожаленю, в js нет встроенной структуры данных позволяющей реализовать priority queue малой кровью. Но структура весьма простая и так.


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


                                                                  Скажете: всего-то в 20 раз соптимизировали — фигня… Но тут 20 раз, там 2 раза, вот тут еще 20% скинули… Результат пользователю будет заметен.

                                                                    0
                                                                    Тут не надо никаких 20 элементов много раз сортировать! Вот зачем нужно знать алгоритмы.

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

                                                                    Скажете: всего-то в 20 раз соптимизировали — фигня… Но тут 20 раз, там 2 раза, вот тут еще 20% скинули… Результат пользователю будет заметен.

                                                                    Всё, что дольше 2-3 секунд ожидания пользователем ответа — оптимизировать надо. Разница более 30% заметна без секундомера, соот-но полезна к реализации при превышении тех самых 2-3 секунд.
                                                                      0
                                                                      Всё, что дольше 2-3 секунд ожидания

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

                                                                      Тут, кстати, ещё интересно, что в некоторых ленивых языках можно просто сконструировать take 20 . sort (сортируем и потом берём 20 первых), и это выражение сортировать весь список не будет именно за счёт ленивости. Правда, посчитать асимптотическую сложность уже будет куда сложнее.

                                                                        0
                                                                        некоторых ленивых языках можно просто сконструировать take 20. sort (сортируем и потом берём 20 первых)

                                                                        Я не в курсе за «некоторые» языки, но по логике — последовательность операций take + sort сначала возьмёт элементы, а потом их отсортирует. А надо наоборот — сначала отсортировать, потом взять из верхушки отсортированного.
                                                                        А о продвинутых языках, которые бы дали оптимизацию конструкции sort + sort я не слышал. Было бы прикольно, но боюсь в более-менее универсальном виде это нерационально трудоёмко для оптимальной реализации.
                                                                        • UFO just landed and posted this here
                                                                            0

                                                                            Ну, если все — функции, то Take20(Sort(array)) — как раз то, что надо.

                                                                              0

                                                                              Да, это хаскель, и это читается справа налево. В математике композиция функций записывается справа налево (g ○ f означает применение сначала f, а потом g), поэтому в хаскеле решили сделать так же.

                                                                          0
                                                                          Хотелось бы тогда спросить, если в Гугле все так «оптимизированно», почему админка gmail (для фирм) на каждое действие грузилась по 30 секунд?

                                                                          Может быть, чем алгоритмы оптимизировать (даже 1 млн элементов это немного) лучше подумать об общей архитектуре приложения?
                                                                            0

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


                                                                            Я не знаю испытывает ли админка gmail для фирм какое-то конкуретное давление по скорости. Скорее всего вряд ли, тот кто принимает решение о выборе поставщика решения для почты учитывает этот параметр, так как оно не так часто используется как основной интерфейс и его может использовать админ, а не ЛПР.

                                                                              0
                                                                              Очевидно, что облачная почта gmail используется лишь в маленьких фирмах. Все большие конторы как сидели на Exchange, так и сидят.

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

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

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

                                                                                Ну вот и я об этом.


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

                                                                                Тут мне непонятна связь между первой частью фразы и второй.

                                                                                  0
                                                                                  Посыл тут в том, что оптимизация «как в гугле» делается только для самоуспокоения. Она не влияет на качество получаемых продуктов. И это ответ на

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


                                                                                  Зачем спрашивать то, что потом вообще не будет использоваться в реальном мире? Может быть начать спрашивать о вещах, которые повысят качество продуктов и удовлетворенность пользователей?
                                                                                    0
                                                                                    Зачем спрашивать то, что потом вообще не будет использоваться в реальном мире

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


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


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

                                                                                      0

                                                                                      Это так не работает. Если вы находите какие-то примеры где это не используется это не значит что везде в гугле это не используется. Чтобы доказать, что что-то не используется, надо показать, что это нигде не используется. Т.е. вам надо не искать неоптимизированные продукты гугль, а перебрать все продукты или взять те продукты в которых оптимизация наиболее выгодна гуглу и показать на них

                                                                                        +1
                                                                                        Тут как в известном анекдоте:
                                                                                        Учиник: разве мне когда-нибудь пригодится эта ваша линейная алгебра?
                                                                                        Экзаменатор: Вы её так плохо знаете, что точно не пригодится.
                                                                                  0

                                                                                  Потому что бизнес во главе решений.


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


                                                                                  Technical debt, неподдерживаемые никем куски кода… Много ужасов промышленной разработки не обошли гугл стороной. Особенно гугл, в силу его размеров и обширности.

                                                                              0
                                                                              в следующей версии мне нужно было сделать это для, например миллиона чисел, и там решение близкое к o(n*log(n)) уже будет выглядеть немного не очень.

                                                                              Но вы в курсе, что log n от миллиона это 6?

                                                                              На практике, может оказаться, что алгоритм O(n*log(n)) будет работать быстрее O(n) и на миллионе, так как на каждую итерацию O(n) делает в 20 раз больше операций (например, постоянно держать массив из 100 000 наибольших чисел и сортировать его на каждой итерации — формально тот же O(n)).

                                                                              А на миллиарде оба алгоритима могут упасть с OutOfMemory и их в любом случае нужно будет заменять.
                                                                              То есть, не стоит ориентироваться только на O алгоритма в большинстве практических случаев.
                                                                                0
                                                                                Но вы в курсе, что log n от миллиона это 6?

                                                                                А логарифм 20 — 1.3 — более чем в 4 раза меньше. Сокрашение в 4 раза — плохо что ли?


                                                                                Потом, не надо забывать про константу. Логарифм вылезает из-за деления пополам и он двоичный. На самом деле, если тупо операции считать, то там будет не 6*n а 20*n. Потому что log_2(1000000)~20.

                                                                                  0
                                                                                  Сокрашение в 4 раза — плохо что ли

                                                                                  Смотря от какой цифры, если алгоритм работает 0.4 ms, а ответ нужно дать пользователю в течении 500 ms, сокращение в 4 раза до 0.1 ms не имеет большого смысла, намного важнее оптимизировать другие части системы.

                                                                                  Потом, не надо забывать про константу.

                                                                                  Да не стоит забывать про константу — не стоит забывать, что O(n) при равном n может выполняться и 1ms и один час, так как константа у O(n) при практическом применени может быть очень разной.

                                                                                  Например, формально ArrayList и LinkedList в java имеют одинаковый сумарный O, но на практике первый практически всегда быстрее, даже в тех случаях когда считая только O должно быть наоборот.
                                                                            0

                                                                            Ух ты, наконец-то стандартная либа плюсов в чём-то заруливает C#'ную! У нас тут есть std::nth_element.

                                                                              0

                                                                              Но если вам нужны n максимальных элементов, то надо что-то допиливать.


                                                                              Или еще один проход и разбираться с дубликатами, или писать через priority_queue/quickSelect.

                                                                                +1

                                                                                Нет, он их переупорядочивает достаточно для решения искомой задачи:


                                                                                All of the elements before this new nth element are less than or equal to the elements after the new nth element.
                                                                      0
                                                                      поведением знаковых/беззнаковых целых при переполнении в (список языков)

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

                                                                        Ага. И даже возникает подозрение, что этот блок требований можно описать короче. Системный программист, например.

                                                                          0

                                                                          Ага, именно поэтому не так давно мы с одним товарищем обсуждали особенности IEEE754 применительно к задаче генерации случайных чисел. При этом ни он, ни я не являемся системными программистами (я-то вообще уже полгода не писал код, который бы потом запускался), а IEEE754 ИМХО на порядки сложнее целочисленного переполнения.

                                                                      +1

                                                                      «Не приходилось работать»…


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


                                                                      Мне короч понравилось. Всяко лучше, чем в фаангах у доски скобочки балансировать.

                                                                        0
                                                                        Как понял, они тебя проверяли на программистику, архитектуру процессоров, радиотехнику, физику, электротехнику.

                                                                        На такие темы я могу пообщаться, т.к. ФРТК МФТИ в лохматые годы.
                                                                        Видимо, адресно ищут. Или по интересам.

                                                                        Senior должен знать всё ).
                                                                          0

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


                                                                          К счастью, я сам МФТИ, хоть и ФУПМ, так что что-то даже про физику распространения волн и всякие там скин-эффекты смог сказать.

                                                                      +1
                                                                      С интересом прочитал статью.
                                                                      Классик прямо говорит, что его цель — нанять звёзд, людей, которые для развлечения и удовольствия дома пишут на ассемблере. И строго предостерегает от найма людей, которые только похожи на звёзд или могли бы быть ими, но на самом деле не являются.
                                                                      Это не совсем стандартная ситуация найма. А вот вопросы про связный список хотят сделать стандартными для любых собеседований.
                                                                        0

                                                                        Ну по мне так в этом цель любой компании, нет? Нанимать лучших из имеющихся…

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

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

                                                                            0

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

                                                                              0

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

                                                                                0

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

                                                                                  0

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

                                                                                  0
                                                                                  Разве нет?

                                                                                  Нет, это очень наивно так полагать, обычно всякие дурацкие гуглы так и пытаются делать, потом огребают «программистов», которые год учились отвечать на вопросы интервью, больше ничего.
                                                                                  Нанимать надо людей которые лучше всего сделают требуемую работу. Обычно между рабочими требованиями и вопросами на интервью лежисть пропасть, иногда две.
                                                                                0
                                                                                Не всегда.
                                                                                Over skilled тоже не любят.

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

                                                                                Но сбежишь всё равно.
                                                                              +3
                                                                              А бывает и такое, что меня спросили как работает библиотека, которую я и написал. К слову ответить не смог, она мне нужна была именно в тот момент и вылетела из памяти сразу как только. И тут с конечно если компании так прям важно что бы я помнил все объекты и методы «прямо сейчас», то я им наверное и не нужен.
                                                                        +1
                                                                        Если язык программирования предоставляет 100500 способов найти это число, то можно и загуглить. Пожалуйста, без гугла найдите наибольшее число в тензоре PyTorch, который хранится в оперативной памяти GPU.
                                                                          +1
                                                                          Нагуглил за 10 секунд:

                                                                          int?[] grades = { 78, 92, null, 99, 37, 81 };
                                                                          int? max = grades.Max();
                                                                          
                                                                          +5
                                                                          В продакшене лучше не писать велосипедов, и использовать std::max_element, например.

                                                                          Но речь-то про собеседование, где ни один из ваших пунктов не актуален.
                                                                            0

                                                                            Вы серьезно гуглите как найти наибольшее число в массиве? А что вы не гуглите, простите?

                                                                              +4
                                                                              Ну, в джаве поиск максимального числа в массиве можно сделать несколькими разными вариантами, в зависимости от парадигмы. Если я такой велосипед напишу с циклом и сравниванием, мой пулл-реквест просто не пропустят, потому что есть, ну, например, Arrays.stream(decMax).max(Double::compareTo).get();. Я этот метод и не вспомнил бы, потому что использовал его за 5 лет работы, ну, раз или два. При этом нагуглив я точно вспомню, что он делает, как, какие грабли, подходит ли к текущей парадигме, итд.
                                                                                +10
                                                                                Вы очень сужаете задачу, заранее принимая по умолчанию никем и нигде неоговоренные условия. На уровне сеньора человек не думает «от сих до сих». Вам это, вероятно, представляется чем-то а-ля вот таким, написанным за 20 секунд
                                                                                std::vector<int> array;
                                                                                if (array.empty())
                                                                                {
                                                                                    throw std::exception("Array is empty");
                                                                                }
                                                                                
                                                                                auto maxValue (array[0]);
                                                                                if (array.size() > 1)
                                                                                {
                                                                                    for (auto index (1); index < array.size(); ++index)
                                                                                    {
                                                                                        if (maxValue < array[index])
                                                                                        {
                                                                                            maxValue = array[index];
                                                                                        }
                                                                                    }
                                                                                }
                                                                                

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

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

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


                                                                                      Что кстати, косвенный признак того, насколько вы будете хотеть понять собеседника на работе.


                                                                                      Как и что вышеописанный код скажет обо мне как о сеньоре?

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


                                                                                      А если не напишете что не обладаете и что не можете быть сеньором.

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

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

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

                                                                                        Написание алгоритма на уровне джуна в по одной-единственной теме дает понимание того, что у меня есть базовые навыки программирования? А вдруг я знаю массивы, но не знаю списки? А вдруг я знаю массивы, но вообще не знаю деревья? А вдруг я знаю массивы, но не знаю разницы между указателем и ссылкой? И еще 1024 подобных вопроса. Если уж так важна данная тема, то давайте тогда сделаем полную проверку на все базовые знания: вдруг я еще чего-то базового не знаю. Дабы быть правильно понятым: нет у меня корона с головы не свалится по причине ее (короны, а не головы) отсутствия, и мне несложно этот код написать, но данная задача абсолютно бесполезна для позиции сеньора. Более того она вызовет у меня недоумение и подозрение: если подобный код проверяется на позиции сеньора, то чем, собственно говоря, я там буду заниматься? Писать что-то подобное?
                                                                                          +2
                                                                                          что для позиции сеньора задача неполная

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


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

                                                                                          Ага. А ненаписание дает понимение что нет.


                                                                                          И еще 1024 подобных вопроса.

                                                                                          Конечно, собеседование не состоит из одной этой задачи.


                                                                                          Писать что-то подобное?

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


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

                                                                                    –1
                                                                                    «Вам это, вероятно, представляется чем-то а-ля вот таким, написанным за 20 секунд» — это ваше предположение :).
                                                                                    «И вот тогда начинается гугление, чтобы не изобретать велосипед, который к тому же скорее всего окажется менее эффективным, чем уже известное и отработанное решение» — а, что, в интернете есть решение именно под вашу задачу? :) Звучит еще менее правдоподобно, чем то, что я с первого раза напишу верное решение :).
                                                                                    «Собственно говоря, ваш вопрос как раз и показывает, что вы не видите разницы между сеньором и мидлом» — ну или вы ее не правильно видите. Тут одно из двух :).
                                                                                    «А у сеньора в этот момент голова взрывается от обилия возможных вариантов, про которые ему ничего не сказали.» — а, что задать уточняющие вопросы уже нельзя?:) Обычно в ответ говорят ограничиться простым случаем :). В реальной обстановке же часто нужно на основе известного классического алгоритма написать реализацию, которая не получается простым maxOf, например. По-моему это очевидно.
                                                                                +8
                                                                                Вот о том и речь. Я провёл последние 13 лет в С и С++ разработке тестирующего софта для железа. Два года назад собеседовался на позицию программера (сеньёром она не называлась, но фактически являлась). Проект — создание тестирующего софта для железа (как потом оказалось, на С#). Если бы меня на собеседовании попросили вспомнить С++ алгоритм поиска максимального числа в массиве, я бы очень плохо подумал о таком интервьюере. Я до этого с задачей поиска максимального в массиве встречался лет 20 назад, к тому же на Паскале.

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

                                                                                В реальности же я попал на ту работу. Сделал им систему тестировния, применив свой 10-летний опыт. Система работает на заводе. Все довольны.

                                                                                ЗЫ: максимальное в массиве в том проекте не искалось.
                                                                                ЗЗЫ: если компании нужен справочник по плюсам, надо купить справочник по плюсам, а не сеньёра.
                                                                                  +4

                                                                                  Вы это серьезно? Если у вас вызывает сложность написание поиска максимального элемента в массиве — что-то сильно не так, неважно сколько лет назад вы с этой залдачей встречались. Это элементарная операция. Вот просто элементарная — неважно, сколько у вас лет опыта и с какими языками.
                                                                                  Если же задача не вызывает сложности, то в чем проблема? Лень? Или корона давит?

                                                                                    +1
                                                                                    Однажды я проходил собеседование с кодированием, к своему стыду я ничего не смог написать — я очень сильно волновался — там была задача написать алгоритм вычисления чисел фибоначчи. Я чувстсвовал себя архиглупым. С тех пор на такие собеседования не хожу, т.к. боюсь завалить. Думаю, что я и поиск максимального числа напсал бы как-то не так — или медленно, или неправильным способом.
                                                                                      +1

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

                                                                                      +1
                                                                                      Ну на С — не вопрос, а на современных плюсах, возможно, задумался бы. Связано это не с незнанием, а с тем, что ещё с института терпеть не могу экзаменов. Забываю примитивные вещи: термины, например, или помню русский термин, а английский — нет. Или могу на листочке накосячить с каким-нибудь примитивным синтаксисом, который на клавиатуре уже в пальцах запомнен (например, написать что-то типа p* вместо *p).
                                                                                      При этом само по себе собеседование меня не напрягает. Проблема именно с тестированиями.

                                                                                      Кстати, тогда я без работы сидел полгода, а «для дома, для семьи» ничего не писал. Последний проект на старой работе был на С под голое железо.

                                                                                      А потом, уже на новой работе был год с лишним на C#. Тоже без практики на С и С++.
                                                                                        –1
                                                                                        Если у вас вызывает сложность написание поиска максимального элемента в массиве — что-то сильно не так, неважно сколько лет назад вы с этой залдачей встречались. Это элементарная операция.

                                                                                        Давайте рассмотрим типичную задачу выполнения свертки над изображением, превышающим размер доступной оперативной памяти, с варьируемым окном и ядром при использовании OpenMP/OpenMPI. Пусть ядро будет как раз функцией максимума. Покажите ваш код вычисления — не забудьте подумать, как совместно оптимизировать вычисления для набора заданных окон и так далее, ну да вы же сами все знаете. Заметьте, за плохой результат или его отсутствие вам ничего не будет, в отличие от рассматриваемой в статье ситуации:)

                                                                                          +1

                                                                                          А может быть всё-таки рассмотрим типичную задачу на собеседовании, которую дают с целью проверить, что собеседуемый вообще может код писать?


                                                                                          По задаче: арендовать инстансы с бОльшим объемом оперативки, чтобы нужные куски в память помещались и использовать стандартные функции BLAS.

                                                                                            +1

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

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

                                                                                        Пример
                                                                                        Напишите поиск в коллекции самой удаленной точки от центра координат.
                                                                                        • так-с, это уже отличается от поиска наибольшего числа, но все-равно школьная задачка, сейчас за пару минут напишем, главное не как в прошлый раз, до закрытия офиса;
                                                                                        • не забудь про тесты!
                                                                                        • сравниваются не сами точки, а расстояния, надо лучшее расстояние сохранять, а правильнее его квадрат — сэкономим на корне;
                                                                                        • надо хранить отдельно указатель на лучшего кандидата… его индекс? а если мы больше не сможем обратиться по индексу, может вообще коллекция с переопределенным this[] или выборкой из БД? значит надо локально сохранять точку в переменную, но в худшем случае будет N копирований в эту переменную, лучше хранить таки ссылку, зависит от размерности;
                                                                                        • можно начать не с 1го элемента, с 0го, а лучшее расстояние присвоим в FLT_MAX, тогда любой член будет априори лучше, но не забыть проверку пустой коллекции;
                                                                                        • если считаем с 0го тогда можно вообще перебирать по итераторам или что у этой коллекции есть. правда, тогда ссылка не получится;
                                                                                        • погуглим по-быстрому что там в библиотечных методах;
                                                                                        • блин! забыл спросить про размерность — пространство или плоскость, или вообще 12 измерений, а универсальный вариант с интерфейсом или наследованием сожрет больше памяти, чем сами координаты, особенно 64-битный vtable;
                                                                                        • а есть ли у них кофе в офисе?
                                                                                        • хорошая библиотека выходит, всего на 1000 строк, но столько вариантов покрывает!
                                                                                        • как это час прошел???
                                                                                        .
                                                                                          0
                                                                                          Он должен все эти вопросы задать перед началом решения задачи. Если вообще ничего из этого не требуется, написать просто алгоритм, без выкрутасов и «смотрите как я могу».
                                                                                            +1
                                                                                            Если «он должен» столько много да еще и за ограниченные деньги, то скорее всего новости для компании не очень…
                                                                                              0
                                                                                              Ну так грейд обязывает. На то он и сеньор, а не джун, чтобы знать, где можно на грабли наступить, где скрытая сложность притаилась.

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

                                                                                                  Бесконечно полное не требуется.
                                                                                                    +1
                                                                                                    Вот именно для этого скилл коммуникаций тоже нужен для Senior+.
                                                                                                    Не чувствуй себя гуру.
                                                                                                    Общайся с бэком (если ты на фронте).
                                                                                                    Выноси на общие обсуждения, с первого раза, со второго.
                                                                                                    Ты должен решить проблему в любом случае, и лучше, чтобы оптимально.
                                                                                              +1
                                                                                              В примере по-моему не сеньор, а перемудривший джун.
                                                                                              Единственный значимый вопрос — возможно ли сохранение ссылки на элемент, с гарантией последующего доступа, ну и про кофе, конечно
                                                                                              А вот разумный вопрос — можно ли возвращать FLT_MAX при отсутствии элементов не прозвучал.

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

                                                                                                0
                                                                                                Тут есть два подхода — решение проблем на момент «сейчас», когда Вас наняли по конкретному ТЗ за конкретную сумму. И решение проблем с прицелом на неопределенный срок, когда Вам же придется решать и проблемы, созданные текущим решением проблем, за заранее фиксированную и прописанную в договоре премию. Имеем бесконечное множество вариаций этих двух подходов, любое из которых, очевидно, таки да «решает проблемы бизнеса». Вот что Вы подразумеваете под «решением проблем»? Входит ли в Ваше понятие оценка соискателем этих самых «проблем» для выбора оптимального варианта решения или соискатель все таки должен быть телепатом?
                                                                                                0
                                                                                                Очень поддерживаю! А собеседующий, обычно, имеет ввиду одно правильное решение, и надеется, что найдёт того, кто угадает…
                                                                                                +1

                                                                                                Человек может решать задачу как ему удобно, главное качественно.


                                                                                                Вариантов решений море, и человек не должен знать ВСЁ, а должен уметь качественно использовать свои и ЧУЖИЕ знания (сообщество) и выдавать качественно решение.


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


                                                                                                Поэтому не вижу ничего такого в поиске решений через гугл, имхо J

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

                                                                                                  Его умение отлаживать и искать ошибки — тоже предмет проверки.

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

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


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


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


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

                                                                                                      0
                                                                                                      Есть разные подходы, этот тоже вполне имеет право на жизнь.
                                                                                                +1
                                                                                                Вот-вот, до сих пор помню собеседование лет десять назад, с вопросами на бумажке, типа «сколько битов в IPV6 адресе», без интернета.
                                                                                                  0
                                                                                                  Я… я правильно понял, 2010 год? Не 15 лет назад? А-то 10 лет назад у меня 60 мбит было за 450 рублей в месяц, причем не самый крутой тариф.
                                                                                                    0
                                                                                                    Это было не физическое отсутствие интернета, работодатель верил что ответы надо знать наизусть, а не гуглить :-)
                                                                                                      0
                                                                                                      А, ясно, но хоть это и смешно, но я сам могу нагуглить (и гуглю) практически любую проблему, но честно признаться, со стороны работодателю может казаться что он нас гуглить нанимает, поэтому я в чем-то понимаю тех из них, кто просит код писать на листочке :/
                                                                                                        +1
                                                                                                        Я уже семь лет как фрилансер, и вместо задачек-вопросов идет деловой разговор «у нас есть такие проблемы, можешь помочь?». Так что лично меня эта проблема уже не затрагивает к счастью.
                                                                                                        Но с обеих сторон барьера мне трудно понять зачем помнить сколько байтов в IP или MAC адресе, какие ключи у команды 'ls', или зачем в уме считать netmasc.
                                                                                                +33

                                                                                                Обидеть сеньора может каждый

                                                                                                  +8

                                                                                                  Во всем сервисы по подготовке к интервью виноваты и книжки типа как крякнуть интервью на изучениях которых у мид+ плюс нет ни времени ни желания, а вот у ребят которые только залетают предостаточно.
                                                                                                  На самом деле, проводя интервью, мне не важно как хорошо кандидат знает основы, алгоритмы, структуры данных, да даже язык на котором он пишет меня не очень волнует. Мне нужно понять может ли человек решать проблемы и я был бы рад дать ему написать объемное приложение чтобы оценить его со всех сторон, но у меня только час на интервью. Это значит что мне нужно придумать минимальную задачу в плане объема, за решением которой я смог бы проследить и понять, что из себя представляет человек, таких задач много на самом деле, и данный способ даже никого не бесил и всех устраивал какое то время…
                                                                                                  А потом настал бум взломщиков собеседований появились всякие leetcode, hackerrank и тп, которые просто дрессирую разрабов на решение таких задач. Что привило к ситуации которую мы имеем сейчас, сложные алгоритмические задачи с использованием разнообразных структур данных, задачи на разогрев и подобный треш, который конечно никому из мид+ сегмента не нравится.

                                                                                                    +6
                                                                                                    Мне нужно понять может ли человек решать проблемы

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

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

                                                                                                    Иногда самое сложное не выдать тут же и решения. Я это называю ежиным тестом по аналогии со статье йМосигры.

                                                                                                      +1
                                                                                                      Думаю, что одна из причин по которой на собеседовании дают тупую дичь сеньёрам/прошаренным — недостаток квалификации проверить сеньёра/прошаренного другим способом. Когда разговаривают два квалифицированных человека — они о насущных проблемах говорят, а не друг-другу первые вопросы из гугла задают и всякую виртуальную дичь друг у друга не спрашивают.
                                                                                                        0
                                                                                                        Мн целых два раза в жизни попались такие собеседования. Приятно провел время.

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


                                                                                                          Т.е. человек, работающий 10 лет в саппорте какой-нибудь CRUDной опердени, где основная проблема — составить внятное ТЗ из разрозненных фрагментов потоков сознания разных лет и разных источников мыслей, — автоматически лжец?
                                                                                                            0
                                                                                                            Я говорю о ребятах у которых пестрое резюме.

                                                                                                            Если за 10 лет одна строчка и человеку сказать нечего, то мне просто не подходит.
                                                                                                  +1
                                                                                                  Аналогия в этом случае не очень хороший аргумент, потому что тут непонятно, к чему сопоставить тестовый урок: к написанию факториала? К реализации тестового приложения целиком начиная с git init?

                                                                                                  Я например подумал про первый вариант и сделал вывод — сеньер — это тот, который круды шлепает, не вдаваясь в логику решения проблем.
                                                                                                  • UFO just landed and posted this here
                                                                                                      +3
                                                                                                      Как-то давно я устроился AngularJS разрабом, не имея вообще представления о том, что это такое, ваш AngularJS. Мне насиловали мозг основами, а потом, видимо, самим надоело, и собеседование закончили, а меня взяли. Уже в процессе трудовых будней втянулся в ангуляр)
                                                                                                      • UFO just landed and posted this here
                                                                                                          0

                                                                                                          Кстати, нередко вижу вакансии на сеньора, например, по питону с условием опыта работы более N лет с ± любым ооп языком.

                                                                                                      • UFO just landed and posted this here
                                                                                                          +5

                                                                                                          Это на самом деле завуалированное "а вы сами резюме писали, а помните что там насочиняли?" ;)

                                                                                                            0
                                                                                                            У меня пару раз спрашивали использую ли я Gradle (под андроид пишу), всегда спотыкался на этом вопросе, один раз чуть не начал им рассказывать что спрашивать такое это все-равно что спросить знаю ли я Android SDK :) Не, может они конечно таким вопросом хотели узнать что если вдруг я использую другую систему сборки, а не идущую из коробки, то почему. Но все-равно как-то странно, похоже на то, что для них это просто одна из новомодных технологий, ладно бы просто HR в текст вакансии ее вписал, но это на собесе прямо :)
                                                                                                          +16

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


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


                                                                                                          Кандидат выходит из машины и объясняет свою езду так: «Вы знаете, я вообще-то готовился к собеседованию. Мне не сказали, что будет практический тест».


                                                                                                          Источник: https://feldgendler.livejournal.com/2015/08/05/


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


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

                                                                                                            +16
                                                                                                            Приведу примеры задач и вопросов из интервью, которые были у меня. Итак собеседование на позицию Architec, Tech Lead, Senior TS/JS developer. Все что связано с фронтом короче.

                                                                                                            — напишите функцию замены строки ДНК на другой участок ДНК
                                                                                                            — напишите функцию фибоначчи
                                                                                                            — напишите сортировку массива
                                                                                                            — что такое замыкание
                                                                                                            — что такое промис
                                                                                                            -итд

                                                                                                            А теперь главный вопрос — это серьезно задачи для архитектора и тех лида? Таких интервью у меня были десятки только за последние 10 лет моей 20-летней карьеры.

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

                                                                                                            Когда таких интервью один или два — ты просто не обращаешь внимания. Когда десятки — это начинает раздражать.
                                                                                                            • UFO just landed and posted this here
                                                                                                                0
                                                                                                                Да. Кстати, почему вас это удивляет?
                                                                                                                • UFO just landed and posted this here
                                                                                                                –4

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


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


                                                                                                                Обычно вопросы про "организацию и архитектуру" имеет смысл задавать тем людям, которые минимальную планку берут. А если нет — то зачем вообще?

                                                                                                                • UFO just landed and posted this here
                                                                                                                    –3

                                                                                                                    Работодатель просто хочет увидеть, как будет писать код человек, которому, возможно, будут платить деньги за написание кода. Удивительное ЧСВ, да?

                                                                                                                    • UFO just landed and posted this here
                                                                                                                        +9

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


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

                                                                                                                        • UFO just landed and posted this here
                                                                                                                            +4

                                                                                                                            Из такого места и нужно вставать и уходить.

                                                                                                                              0
                                                                                                                              Так бывает в мелких аутсор конторах, им нужно подешевле и получше, но лучше подешевле. Так НЕ бывает в продуктовых компаниях или в аутсорс компаниях с серьезными проектами.
                                                                                                                              • UFO just landed and posted this here
                                                                                                                      +1
                                                                                                                      Если вы еще раз внимательно прочитаете мой пост, то увидите, что я написал — «Мне не сложно было написать эти функции и ответить на простые вопросы...» (с)

                                                                                                                      Так что, к чему ваши замечания?
                                                                                                                        –4

                                                                                                                        Ну так ответьте. К чему это нытьё?


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

                                                                                                                          +4
                                                                                                                          Боюсь вы видите то что хотите видеть.

                                                                                                                          Но все же повторю — мне не сложно было ответить и написать, что я и делал. И увы, придется делать в будущем.

                                                                                                                          И это не нытье, это разговор о полезности/бесполезности некоторых видов интервью.
                                                                                                                            +8
                                                                                                                            это разговор о полезности/бесполезности некоторых видов интервью.
                                                                                                                            Вы смотрите на это со своей колокольни, колокольни человека, который обладает знаниями сеньера и т.д., для Вас эти вопросы просты и пусты.
                                                                                                                            Проблема работодателя в том, что 9 из 10 кандидатов претендующих на позицию сеньера не осилят эти вопросы даже если они будут заданы им в виде домашнего задания с неделей на подготовку.
                                                                                                                            Такие вопросы это первичный фильтр откровенных самозванцев, которых действительно очень много.
                                                                                                                            Гитхаб и портфолио тоже не аргумент, т.к. неизвестно сколько там кода самого кандидата, а сколько заимствованного и как быстро и после скольких ошибок это было написано.
                                                                                                                              0
                                                                                                                              Почему бы им сразу нормальные «сеньёрские» вопросы не начать задавать? Не отсеят? А раз ваши «сеньёрские» вопросы не отсеят — значит они вам подходят.
                                                                                                                                +3
                                                                                                                                сразу нормальные «сеньёрские» вопросы

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

                                                                                                                                раз ваши «сеньёрские» вопросы не отсеят — значит они вам подходят

                                                                                                                                Проблема в том, что в реальной жизни нужно не на вопросы отвечать, а программировать. А многие «сеньёрские» вопросы можно просто выучить.
                                                                                                                                  +1
                                                                                                                                  Почему бы им сразу нормальные «сеньёрские» вопросы не начать задавать? Не отсеят?
                                                                                                                                  Во-первых, потому что это первый этап, который 9 из 10 не пройдут, и ни к чему тратить время сеньора для оценки ответов на сеньорские вопросы. На втором этапе — да, будут сеньерские.
                                                                                                                                  А во-вторых, как ни парадоксально звучит — могут и не отсеять. На должность сеньора нередко проще пройти собеседование чем на должность миддла, т.к. ответы на вопросы более расплывчатые, неоднозначные и их проще выучить. При этом когда дело дойдет до практической реализации — тут наступает оппаньки.

                                                                                                                                  Собственно не знаем как в россии, а на западе достаточно много «самозванцев» таки проходит все круги собеса прокачав скилл прохождения собеса, выучив базовую теорию и список типичных вопросов. А потом фиг их уволишь. А тестирование базовых практических навыков в реальной жизни их и срезает.
                                                                                                                          +4
                                                                                                                          Читал вчера ваши комментарии — задумался, а когда же я за 20 лет последний раз искал наибольший элемент в массиве? Вспомнить не смог. Нет, я безусловно отвечу на подобный вопрос, и скорее всего быстро напишу код. Но ценность работы в данной конторе для меня будет где-то между работой в Макдональдс и такси.
                                                                                                                          Могу предположить, что вы говорите с точки зрения «галеры», где позиция работника (с веслом в руке, и веслом в .....) определяется количеством проектов, которые он может закрыть своей тушкой.
                                                                                                                            0
                                                                                                                            Мне кажется, вопрос нужно было себе ставить не когда я искал элемент в массиве последний раз, а когда приходилось писать «алгоритм» последний раз. Нет, алгоритм не в том смысле, что я набиваю ежедневно код состоящий чисто из вызовов какого-нибудь API и рисование скажем результата на форме, а реальный такой алгоритм. Ну скажем например «Ускорение работы системы например в x раз». Поиск элемента в массиве как раз пример алгоритмичного мышления, а не мышления «машинистки» забивающей текст в редактор код, порой копируя куски другого кода со Stackoverflow.

                                                                                                                            PS: Без обид, тут я не пытался какой-то негатив в твою сторону пустить, наверняка, ты отличный программист и пишешь хорошие алгоритмы, тут скорее просто хотел отметить постановку вопроса :)
                                                                                                                              +2
                                                                                                                              Это при том, что «реальными такими алгоритмами» последние полгода как раз и занимаюсь. Я бы и рад со Stackoverflow — но там такого нет :( И повторюсь, нахождение наибольшего элемента массива никак не характеризует senior dev. От слова — совсем. Для начинающих — вполне себе нормальный вопрос. Нейрохирург скорее всего сможет удалить аппендицит. Но при приеме на работу у него не будут спрашивать — «Скальпель-то держать умеешь?»
                                                                                                                                0
                                                                                                                                А проблема в том, что senior dev и его резюме не характеризует и даже его рассказы о самом себе, тоже никак его не характеризуют. Задача уровня джуна (ну как про поиск элемента в массиве) как минимум характеризует кандидата в том что он умеет решать задачки уровня джуна и есть уже смысл идти дальше и разговаривать про то как бы он построил космические корабли, которые бы бороздили просторы вселенных.
                                                                                                                                • UFO just landed and posted this here
                                                                                                                                    +1
                                                                                                                                    Если честно, градация на джунов, сениоров, миддлов и прочих, лично для меня немного чуждая. Я больше ориентируюсь на градацию: хороший разработчик и говнокодер. Хороший разработчик для меня, это человек который может 1) мыслить алгоритмически и 2) мыслить, если угодно, архитектурно. Так вот первое проверяется обычно вот такими задачками по типу, вот тебе бумажка накидай алгоритмик. А второе проверяется уже обсуждениями по типу а как бы ты спроектировал бы систему при условии что…
                                                                                                                                    • UFO just landed and posted this here
                                                                                                                                        0
                                                                                                                                        Меня как тех.спеца, собеседующего, другого тех.спеца мало волнуют зарплаты. Я не знаю какие зарплаты сейчас у моих коллег. Они могут быть разными, даже при условии одинакового опыта. Так же бывает зп у чувака в 25 лет выше чем у сотрудника которому под 50, хотя естественно опыт работы сильно разный в данном случае, как и способность соображать и знание конкретных технологий к примеру. Поэтому ЗП это отдельная ортогональная тема.
                                                                                                                                  +1

                                                                                                                                  Характеризует. Если вы не смогли ответить, значит вы не senior dev

                                                                                                                            +7

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

                                                                                                                              0
                                                                                                                              Это отличный вопрос.

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

                                                                                                                              — Затратный. Нанимают людей или компанию, с подходящим уровнем, со стороны для аудита кандидатов.

                                                                                                                              — Дешевый или сарафанное радио. Ищем среди друзей, людей с уровнем знаний и договариваемся за пиво/кофе/пиченьки.

                                                                                                                              Но признаюсь, я такое в своей жизни не встречал.
                                                                                                                                0
                                                                                                                                Это очень странный подход. Может, как один из этапов интервью (поведенческое), но явно не техническое. В идеале, на техническую позицию нужен собеседующий на уровень-два выше кандидата. Иначе смысл в таком интервью пропадает. Ну или если на собеседовании собеседующий чувствует, что кандидат на уровень-два выше, то такого человека нужно брать. Но тут есть другая сторона — что, если собеседующий почувствует себя неуверенно, закомплексованно и не найдет в себе сил признаться в чьем-то превосходстве?
                                                                                                                                  +1
                                                                                                                                  Заменить такого собеседующего другим? И в компании объективно может не быть человека выше уровнем. Ну вот неоткуда. Новое направление, новые проекты, новые задачи, а человек нужен. Сам с таким сталкивался. И ничего страшного. Для этого к интервью готовятся просто обе стороны, а дальше в разговоре обычном можно понять, адекватный человек, и сможет ли он что-то рассказать сверх того, что вы сами изучили за пару часов гугления.
                                                                                                                                  0
                                                                                                                                  Для этого осуществляется элементарная подготовка к интервью.
                                                                                                                                    0

                                                                                                                                    По крайней мере он может проверит что кандидат не слабее его.

                                                                                                                                      +2

                                                                                                                                      Он может сделать это как раз тем способом, который раздражает сеньора-помидора.

                                                                                                                                        0

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

                                                                                                                                          +1

                                                                                                                                          Я тоже не знаю. Но об этом говорится в статье. Судя по ней сеньоров раздражают вопросы для джунов и мидлов.

                                                                                                                                        +2
                                                                                                                                        Сравнение сил квалифицированных специалистов заключается не в знании конкретных алгоритмов или порядке параметров в редкоиспользуемой функции, а в архитектурном понимании и опыта использования/настройки различных решений и инструментов. В этом случае «элементарно подготовиться к интервью» не выйдет.
                                                                                                                                        +2
                                                                                                                                        О чем он вас должен спрашивать? О том, что сам не знает?

                                                                                                                                        Честно говоря, не понимаю, а что в этом такого? Особенно если собеседуют на лида?
                                                                                                                                        По тому, как отвечают, можно понять, уверен человек в своих ответах или нет. Можно понять, сможет ли он объяснить это менее сильным коллегам. Самому, в конце-концов понять какой-то технический момент.
                                                                                                                                        Я вот в душе не гребу, что под капотом у async-await в C#. Но это не помешает мне понять, собеседуемый в этом разбирается или нет.
                                                                                                                                        И да, в идеальном мире надо брать на работу людей, которые сильнее тебя.
                                                                                                                                          0
                                                                                                                                          И да, в идеальном мире надо брать на работу людей, которые сильнее тебя.


                                                                                                                                          По моему скромному опыту, ближе всего к этому утверждению зарубежные работодатели. Но «заумность» ни в коем случае нельзя показывать в России. Я вот точно знаю пару моментов по которым я не прошел собеседования. Первый спросил у архитектора почему бы вам просто не масштабировать текущее java приложение через домен WildFly/JBoss. Второй раз спросив на собеседовании у представителя IBM/RedHat почему они рекомендуют Kubernetes, а не OpenShift. Я ни в коем разе не считаю себя сильнее интервьюеров, во всех случаях спрашивал из чистого любопытсва.
                                                                                                                                            0
                                                                                                                                            По тому, как отвечают, можно понять, уверен человек в своих ответах или нет

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

                                                                                                                                          Так это же очень хорошие вопросы, если на собеседовании у меня такое начинают спрашивать, я точно знаю, что мне в эту контору не нужно идти.
                                                                                                                                            +4
                                                                                                                                            Можно предположить, что такие вопросы задают дураки-дилетанты, с которыми вам работать не хочется. Но эта практика довольно распространенная, следовательно нужно допустить, что дилетантов-дураков очень много. Вы, кажется, не допускаете, что у подобной практики могут быть обоснованные причины. В чем ваша логика?
                                                                                                                                              +2

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