Я работаю программистом последние 11 лет: первые 5 лет как PHP-разработчик, а последние 6 лет как Go-разработчик. Недавно я сходил на с десяток собеседований, и они меня очень сильно разочаровали.

Хватит спрашивать тонкости языка программирования

Вопросы вроде: "Вот у нас есть слайс в Go, мы передадим его в функцию, там вставим 3 элемента - что мы получим?" Да ерунду вы получите! Есть best practices. Если в функции модифицируете слайс - нужно возвращать новый слайс, а не играть в угадайку. Синьоры последние 5 лет своей работы так и делают. Этот вопрос максимум джуниор знает, потому что он это изучал на прошлой неделе. Синьор это изучал 5 лет назад и в реальной жизни не использует. Максимум он специально для собеседования повторил.

Хватит спрашивать тонкости фреймворка

Самый бесполезный вопрос, который я встречал в своей карьере: "А какой метод авторизации используется по умолчанию в Symfony?" Что этот вопрос скажет о человеке? Что он помнит каждую деталь фреймворка? Или что он помнит то же самое, что и собеседующий? Или вы думаете, что синьор не загуглит это за 10 секунд?

Хватит спрашивать книжные термины

"А что значит буква D в аббревиатуре SOLID? А в ACID?" Вы хоть раз в жизни за пределами собеседования этой информацией пользовались? Нет? Так к чему эти вопросы? Даже если человек и знал эту информацию - он её забыл лет 10 назад.

Алгоритмы и структуры данных

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

Программист - это не специалист одной технологии

Синьор может выяснить требования у бизнеса, придумать архитектуру, спроектировать БД. И потом всё это реализовать на ЛЮБОМ языке программирования. Не работает так, что если до этого синьор работал 5 лет на Go, то завтра он не сможет написать проект на Java. Да, загуглит он, как создавать функции, классы и т.д. Но это не те знания, которые стоит проверять.

Мы не ракеты строим

Я бы понял, если бы все эти вопросы задавали в компании, где разрабатывают компилятор или свою базу данных - тогда вопросов нет, тогда все эти тонкости работы сборщика мусора, алгоритмы и т.д. - нужны. Но обычно бывает совершенно другая ситуация: приходишь на работу и слышишь: "Смотри, у нас тут есть табличка в БД, её надо вывести в CRM".

Чтобы пройти собеседование - надо проходить собеседования

Все эти вопросы вроде "как работает map в Go под капотом" лично у меня забываются через месяц после собеседования. А знаете почему? Потому что эта информация никак не применяется в реальной жизни. И если человек до этого работал 5 лет и не менял работу - он не ответит на этот вопрос с ходу. А знаете, кто ответит? Человек, который ходит на собеседования 24/7. Как все эти вопросы отражают твой опыт? Если для ответа на них тебе нужно специально готовиться. Никто не знает ответы на них "по умолчанию".

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

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

Комментарии (90)


  1. Denwer_py
    30.07.2025 08:56

    Полностью согласен с автором. Хорошо, что не у меня одного это болит.


  1. valera_efremov
    30.07.2025 08:56

    Можно перед собеседованием отправлять ссылку на статью с словами "Готов на собеседование, если у нас сходятся представления о неправильных собеседованиях". Чтобы не тратить ни свое время, ни время рекрутера.


    1. MEGA_Nexus
      30.07.2025 08:56

      В таком случае придётся потом писать статью, "почему я получаю одни отказы и никто не хочет брать меня на работу" или "как я 5 лет жил под мостом, пока искал себе работу в IT".


  1. y_akopov
    30.07.2025 08:56

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

    Смотри, у нас тут есть табличка в БД, её надо вывести в CRM

    Вы бы видели, какие кандидаты пишут запросы SQL/LINQ в тестовых заданиях. Например, select * в память и там уже сортировка по ключу. А вы, наверное, еще и противник тестовых заданий.

    Синьор может выяснить требования у бизнеса, придумать архитектуру, спроектировать БД. И потом всё это реализовать на ЛЮБОМ языке программирования. Не работает так, что если до этого синьор работал 5 лет на Go, то завтра он не сможет написать проект на Java.

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

    придумать архитектуру, спроектировать БД

    Как можно придумать архитектуру без знания технических деталей? Как можно спроектировать БД, коогда ты не можешь рассказать про ACID в контексте SQL, про сам SQL, про индексы, уровни изоляции, про профилирование запросов, про шаблоны работы с БД в контексте распределенной системы.

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


    1. probeldev Автор
      30.07.2025 08:56

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

      Но чаще всего тестовые отправляют просто как фильтр сделал/не сделал.


    1. AlexeyPolunin
      30.07.2025 08:56

      Проверяли мы про качество кода - будет нормальное. Особенно если он там не в вакууме, а есть кому посмотреть. Да и сейчас есть AI, который супертул по обучению, он отвечает даже на самые тупые вопросы и не устает.


    1. i86com
      30.07.2025 08:56

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

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

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

      А любители "базы" обычно приходят и начинают строить FizzBuzz Enterprize Edition. С выносом всех чисел/строк в константы, констант - в конфиги, конфигов - в БД, а раз БД, значит делаем через паттерн service-repository, шардирование, кеширование и т.д. пока сами же благополучно не задолбаются и не скажут, что весь проект нужно переписать с нуля. А пока не переписали, замена "Fizz" на "Jizz" будет требовать два дня работы опытного специалиста (новичок и за неделю не справится). Зато теперь и "специалиста" такого никто не посмеет уволить.


    1. Kahelman
      30.07.2025 08:56

      А вы можете развернуто и правильно ответить про уровни изоляции транзакций? Если да, то применительно к какой БД?


  1. Dick_from_mountain
    30.07.2025 08:56

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


  1. A1WEB
    30.07.2025 08:56

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


  1. dedmagic
    30.07.2025 08:56

    А что значит буква D в аббревиатуре SOLID

    Если для Вас SOLID - это просто набор букв, представляю, какой говнокод Вы пишите.


    1. positroid
      30.07.2025 08:56

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


      1. dedmagic
        30.07.2025 08:56

        То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.

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

        Мне тут минусов накидали: я правильно понимаю, что соблюдать принцип единственной ответственности - это зло? Хм, странно. Весь мой опыт показывает, что несоблюдение этого принципа гарантировано приводит к проблемам, так же, как и несоблюдение DRY.
        Ну ОК, возможно, некоторые любят боль...


        1. NimuraF
          30.07.2025 08:56

          Ваш коммент больше похож на снобизм и клоунаду, без обид. SOLID - это буквально на 90% паттерн, который сам собой приходит из ООП, так и DRY (ёлки-палки, мы в принципе пишем программы автоматизации, чтобы не было DRY), смекаете? Вам накидали минусов, что вы в очевидных вещах оперируете придуманными аббревиатурами, для знания которых мне нужно дополнительно что-то прочитать. Да 90% людей, который с пивком на 3 сдали ООП в своей шараге вам все принципы SOLID расскажут, просто они не знают что это за аббревиатура и какая буковка за что там отвечает (и мой пример даже не слишком утрирован)


          1. dedmagic
            30.07.2025 08:56

            Никакого снобизма и клоунады, всё абсолютно искренне.

            сам собой приходит из ООП

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

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

            Ещё раз - если Вы сами дошли до открытия этих принципов - Вы молодец (без сарказма), но таковые далеко не все. Но даже в Вашем случае допустимо не знать эти аббревиатуры, только если Вы работаете в полном одиночестве.

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


            1. akod67
              30.07.2025 08:56

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


            1. DenSigma
              30.07.2025 08:56

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


              1. Cheddar1789
                30.07.2025 08:56

                Неужели самого Вана Хунвеня читал?


          1. TSEO1
            30.07.2025 08:56

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


        1. i86com
          30.07.2025 08:56

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

          Ради Internet Service Provider? In-system programming? Языка ISP?

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

          То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.

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

          Если человек не может простыми словами объяснить, что он делает и для чего, то он обычно и сам этого не понимает.


    1. DenSigma
      30.07.2025 08:56

      Тащемта, solid - это довольно убогая формализация идеологии, которую разработал Дядя Боб. Причем, формализованная не им, а какими-то левыми людьми. Причем ТАК формализованная, и так неправильно понимаемая как формализаторами, так и большинством изучаемых solid, что Дядя Боб ругается (есть где-то видео). Если вы хотите хорошо программировать, то надо не solid по википедии или случайным статьям изучать, и тем более, ЗАЗУБРИВАТЬ, что означают буквы в этом акрониме, а почитать книги Дяди Боба.

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

      И да, можно писать код, который формально удовлетворяет SOLID, и тем не менее - лютый говнокод.


      1. poxvuibr
        30.07.2025 08:56

        В частности, эта S, сингл респонсибилити

        S это single reason to change

        понимается совершенно неправильно большинством

        А большинство, да, понимает как сингл респонсибилити


        1. DenSigma
          30.07.2025 08:56


    1. gonzazoid
      30.07.2025 08:56

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


    1. DDroll
      30.07.2025 08:56

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


      1. DenSigma
        30.07.2025 08:56

        Собственно, все эти аббревиатуры - суть только попытка формализации того, что и так известно. Плюс еще возможность заработать на написании книг.


  1. gromyko21
    30.07.2025 08:56

    "А что значит буква D в аббревиатуре SOLID? А в ACID?" Вы хоть раз в жизни за пределами собеседования этой информацией пользовались? Нет? Так к чему эти вопросы?

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


    1. andreyiq
      30.07.2025 08:56

      Я тимлид и уже не помню, что такое SOLID, даже обидно


      1. gromyko21
        30.07.2025 08:56

        Советую освежить память)

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


        1. andreyiq
          30.07.2025 08:56

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


  1. SukharevAndrey
    30.07.2025 08:56

    Эту тему уже обсуждали много-много раз в тредах на сотни и тысячи сообщений. Ещё как-то можно понять, когда собеседование в форме экзамена по билетам проводит корпорация, где поток из тысяч людей на вход и тысяч на выход. Эдакое стандартизованное ЕГЭ, чтобы всё было честно и был минимальный bias.
    Другое дело, когда более маленькие компании слепо перенимают эти практики из принципа "мы что, хуже, чем Google?".

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


    1. Dick_from_mountain
      30.07.2025 08:56

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


    1. Tony-Sol
      30.07.2025 08:56

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

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


  1. ky0
    30.07.2025 08:56

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


  1. BALOBASTA
    30.07.2025 08:56

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


    1. NimuraF
      30.07.2025 08:56

      Верим твёрдо и чётко!


    1. R3ndly
      30.07.2025 08:56

      А такое часто встречается? Да и почему это с горящей жопой?) Бред. Автор сказал, что нужно уметь решать таски, а не дрочить литкод


      1. n0isy
        30.07.2025 08:56

        Бинарный поиск как частный случай встречается не часто. Вот зато мест, где программист не подумав сделал О(N*N), прямо сплошь и рядом.

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


    1. akod67
      30.07.2025 08:56

      Вы когда лично последний раз с нуля поиск писали? Честно


    1. DenSigma
      30.07.2025 08:56

      простите, зачем писать бинарный поиск? Где? Можно начерно кейс обрисовать, когда и зачем это может понадобиться?


      1. OldNileCrocodile
        30.07.2025 08:56

        Patient Sorting. Когда нужно разложить пасьянс в картах ну или найти монотонную кучку в кучке. (21 21 1 2 3 1) -> (1 2 3)


    1. barloc
      30.07.2025 08:56

      А на ревью все в команде указать на ошибку посте снялись?)


  1. 0Bannon
    30.07.2025 08:56

    Хватит спрашивать джуниорские вопросы у сеньоров. Спрашивайте сеньорские у джуниоров.


    1. dimaviolinist
      30.07.2025 08:56

      А вы уверены, что это такая шутка? ))


  1. Viacheslav01
    30.07.2025 08:56

    Иногда ощущение странно от таких вопросов из методички для первого года изучения IT и резолюций типа не умеет писать цикл for в блокноте )))

    Примерно как зачисление в 10 класс, институт, магистратуру и асперантуру для всех всегда начинается с ОГЭ )))

    П.С. когда то давно лет 30 назад угодил в психушку когда на вопрос психиатра в военкомате, солнце вращается вокруг земли или земля вокруг солнца, ответил, что они вращаются вокруг общего центра масс )))


    1. pavelsha
      30.07.2025 08:56

      П.С. когда то давно лет 30 назад угодил в психушку когда на вопрос психиатра в военкомате, солнце вращается вокруг земли или земля вокруг солнца, ответил, что они вращаются вокруг общего центра масс )))

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


  1. Mirn
    30.07.2025 08:56

    по поводу дурацких вопросов и идиотских тестовых заданий тоже хочу поныть тем что эта шиза дошла и до около IT:
    вот на робототехника-схемотехника мне предложили такое тестовое задание:
    1. разработать малогабаритный умный блок питания, вход с литий железофосфатных батарей 8S, сотни ватт, мало потребляющий при простое/выключении, кпд овер 90% в широком диапазоне выходных токов и напряжений (возможность перестройки на лету от 12 до 24В), софтовое управление по сети, ручное и аварийное управление, резервирование. Разработать схему, топологию платы совместимую с 7pcb jlcpcb производством и сборкой, подготовить файлы заказа в эти две, при этом жесткий лимит по BOM листу и времени производства. при этом партия маленькая - скорее сотни а не тыщи.
    2. дан другой блок питания с схемой платой и тд как в пункте 1, исправить ошибки (но там всё плохо и выкинуть проще и переделать с нуля) и подготовить к заказу
    3. корпуса и механика для п1 и п2
    4. и последующее задания тоже "изи", типа разработать архитектуру инф. беспроводной сети роя складских роботов, или же архитектуру нейронных сетей для фильтрации помех GPS и навигации по камерам где тот не ловит (уровень проработки не о "поговорить об" а конкретика весьма жёсткая под конкретные платформы и ТЗ там на много страниц).
    срок неделя. сделать всё.
    не РФ, Япония, модный молодёжный стартап
    занавес. (нет слов)


    1. sintech
      30.07.2025 08:56

      Некоторые компании платят по триста миллионов долларов за хороших спецов в хайповой области.

      Может этот стартап ищет своего героя супермена?


    1. DarkTiger
      30.07.2025 08:56

      Вы не поняли сути вакансии. С Вас требовался опыт работы с ChatGPT :)


      1. vvzvlad
        30.07.2025 08:56

        Он совершенно не умеет в схемотехнику


  1. vkomp
    30.07.2025 08:56

    Вспомнилась недавняя история с Яндекс. К собеседованию порешал литкод, но не больше десятка, конечно - не яндексом единым, как говорится. Первый собес отлично. Второй из двух задач - первая отлично всё, вторая про разбор строки - для сложности n нужно было знать какой-то замысловатый метод, который кроме как на литкоде не встретишь. Я вот не встретил. Получил отказ на втором этапе - поначалу думал, что лицом (или возрастом) не вышел. Типа ошибки вроде как нужны, чтобы посмотреть как думает кандидат. А если по памяти решить - то не интересно. Но это не про Яндекс, конечно. Следующий рекрутер пояснила, что в Яндексе типа в сапера играешь, ошибся - всё. И я вот в очередной раз разочаровался в людях.
    Параллельно была задачка второго этапа ВК - там не литкод, а "сложные вводные", интервьювер сам путался в своей же задаче. Решил, даже во время уложился, но чем-то всё равно не угодил, но так и не узнал чем.
    Имхо, "общий трек" только с голодухи можно пройти. Долбиться в стописот задач. И задрачивать собесы. Обычно рекрутеры и интервьюверы сами не знают "под кого" ищут. Потому "ищут волшебника - находят сказочника".
    Мне вот любопытно, есть ли "не голодные" специалисты, которые хотят на новом месте делать тоже самое, что и на старом? Имхо, всегда лезешь в новое, где что-то точно не знаешь.


  1. Anarchist
    30.07.2025 08:56

    Сеньор не может написать алгоритм бинарного поиска? Серьёзно?


    1. akod67
      30.07.2025 08:56

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


      1. avost
        30.07.2025 08:56

        А не бинарным поиском на память.

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

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

        А, и точно. Это sre или девопс.


      1. venanen
        30.07.2025 08:56

        Сеньор должен написать бинарный поиск с помощью всего инструментария, который есть (включая гугление). И БПФ. И Дейкстру. И прод поднять. Он ценен не тем, что поднимает проды (которые легли, почему-то) - а тем, что автономно способен решать задачи.
        Мне понравился собес, но я забыл название и быстро найти не смог - дается задача и полный карт-бланш на гугление и нейронки. Если человек дубовый и ничего не знает - его никакой гугл не спасет.


    1. sobeskiller
      30.07.2025 08:56

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


    1. mordotron
      30.07.2025 08:56

      серьёзно.
      сеньор заюзает готовую библиотеку, коих тыщщи на любой вкус, и которые работают быстрее.


    1. WASD1
      30.07.2025 08:56

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

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


  1. SiGGthror
    30.07.2025 08:56

    Этот вопрос максимум джуниор знает, потому что он это изучал на прошлой неделе. Синьор это изучал 5 лет назад и в реальной жизни не использует. Максимум он специально для собеседования повторил.

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


  1. ReanGD
    30.07.2025 08:56

    Вот у нас есть слайс в Go, мы передадим его в функцию, там вставим 3 элемента - что мы получим?

    Синьор это изучал 5 лет назад и в реальной жизни не использует.


    Там же в Go всего две базовых простых структуры данных по сути - слайс и map. И собеседующий таким вопросом вероятно пытался выйти на вопросы по алгоритмам и структурам данных. Я не понимаю в чём тут проблема проблема?

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


  1. SergeySlukin
    30.07.2025 08:56

    На счет слайса полностью согласен. За 3 года никогда так не писал, но на счет как там мапа внутри устроена, не согласен. А вы знаете сколько прикольных моментов в ядре гошечки? Начиная от структуры blackhole и заканчивая магией при работе с фреймами функций =)

    type pcHeader struct { magic uint32 // 0xFFFFFFF1


  1. sappience
    30.07.2025 08:56

    Да ерунду вы получите! Есть best practices. Если в функции модифицируете слайс - нужно возвращать новый слайс

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


    1. sci_nov
      30.07.2025 08:56

      Если исключений много, то это странно... Зачем тогда правила? Точнее, тогда исключения и правила меняются местами)


      1. slepmog
        30.07.2025 08:56

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


  1. XelaVopelk
    30.07.2025 08:56

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


    Очень странно, что человек проходил десяток собеседований и не обратил внимание, что требует текущий рынок труда. Тут сразу возникнут вопросы, а как он может "выяснить требования у бизнеса", если есть такие проблемы с коммуникацией? Уже если не после первого, так после второго собеса должен сформироваться список "что хочет рынок, что надо подтянуть".

    "...И потом всё это реализовать на ЛЮБОМ языке программирования...Да, загуглит он, как создавать функции, классы и т.д. ..."


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

    "А ведь хорошая идея - попросить программиста написать бинарный поиск."

    бинарный поиск это не КМП. А вот показать что ты не имея в памяти решения в общем то не самой сложной задачи можешь написать кодик - это большой плюс для соискателя.

    "Но обычно бывает совершенно другая ситуация: приходишь на работу и слышишь: "Смотри, у нас тут есть табличка в БД, её надо вывести в CRM"."


    А потом (реальный случай):

    --У нас всё тормозит, нужен срочно ДБА. Х, сделай, чтонить, индекс там какой или типа того!

    --Какой индекс, когда у вас тут все запросы вида "селект звёздочка фром табличка" и вся работа влючая фильтрацию на бэке?


    1. barloc
      30.07.2025 08:56

      С вашим высказыванием хочется как согласиться, так и опровергнуть :)

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

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

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


      1. XelaVopelk
        30.07.2025 08:56

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

        Если мы говорим не полуподвальной конторе, где разработчик это автомотовелофототелерадиомонтёр, то между ним и бизнесом есть: продакт, аналитик, тимлид в конце концов. И они на вход выдают ему ТЗ на разработку. Если этого нет и разработчик получает на вход "нарисуй мне кунгуру" или "придумай чтобы на складе было чисто", это лишь говорит о качестве процессов разработки в конкретной организации. Конечно, он может съездить в поля, чтобы посмотреть что там вообще происходит или рассказать свой опыт на тему бизнеса, это только плюс для него. Но это прежде всего РАЗРАБОТЧИК. И он должен в первую очередь качественно выполнять свою основную функцию. Если он классно "трещит" с бизнесом, но для того чтобы закодить задачу ему надо изучать азы техстека компании, то он не на своём месте как разработчик.


        1. barloc
          30.07.2025 08:56

          Вы рисуете очень узкого специалиста в своей области :) Такое проецирование имеет место быть, но не все сеньоры равны узким специалистам.

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

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

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


      1. XelaVopelk
        30.07.2025 08:56

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

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


        1. barloc
          30.07.2025 08:56

          оно надо? :)

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


  1. RulenBagdasis
    30.07.2025 08:56

    Хватит спрашивать у синьоров джуниорские вопросы

    Мой любимый тест на собесе. Есть словарь, у которого ключи и значения строки. Распечатайте его в консоль в виде строк "ключ = значение", каждый такой элемент на новой строке. Около 30% тех, кто приходит собеситься на синьора не справляется. Поэтому, извините, но я продолжу задавать джуниорские вопросы. Кстати, вопросы именно задают, а не спрашивают.

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

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

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

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


    1. onets
      30.07.2025 08:56

      В смысле не справляются? А в чем подвох задачи?


      1. RulenBagdasis
        30.07.2025 08:56

        Нет подвоха, просто не могут. Это самозванцы.


    1. NimuraF
      30.07.2025 08:56

      Тоже не уловил, а в чём подвох первой задачи-то?

      Я даже в песок пошёл и проверил, а в чём загвоздка-то? Самое примитивное решение даже работает, хотя под сеньором всё-таки часто подразумевают специализацию не в одном ЯП (помимо SQL само собой), мб об этом речь и таким образом свитчеров-халявщиков ловишь?

      package main
      
      import "fmt"
      
      func main() {
        myMap := make(map[string]string)
        myMap["privet1"] = "poka1"
        myMap["privet2"] = "poka2"
        myMap["privet3"] = "poka3"
      
        for k, v := range myMap {
        	fmt.Printf("%s = %s\n", k, v)
        }
      }


      1. RulenBagdasis
        30.07.2025 08:56

        Нет подвоха, просто не могут. Это самозванцы.


    1. RulenBagdasis
      30.07.2025 08:56

      Хм, минусов в карму насовали неуспешные кандидаты, которые узнали себя? ))))


  1. avost
    30.07.2025 08:56

    "А что значит буква D в аббревиатуре SOLID? А в ACID?" Вы хоть раз в жизни за пределами собеседования этой информацией пользовались? Нет?

    Ээээ, вы не знаете что такое dependency inversion и ни разу в жизни ею не пользовались? Вы на пхп программировали, что ли? Ой, стойте!.. ))

    А ведь хорошая идея - попросить программиста написать бинарный поиск. Только вот загвоздка

    Да, нет тут никакой загвоздки. Если программист не может реализовать "алгоритм", описываемый одной строчкой текста, то программист ли он? У меня на курсе училась девочка, которая пыталась вот так вот зазубрить матан. Она его пересдавала 11 раз. Но даже она догадалась, что зубрёжка - путь в никуда и проще понять принцип. Кому нужны "программисты", которые ничего не могут за пределами вызубренного? Сеньоры, говорите? Сеньоры-зубрилки?

    Не работает так, что если до этого синьор работал 5 лет на Go, то завтра он не сможет написать проект на Java. Да, загуглит он, как создавать функции, классы и т.д.

    Серьёзно? А вы точно программист? Сеньор, говорите?..


    1. Kahelman
      30.07.2025 08:56

      Вообще-то правильный ответ должен быть: зачем вам бинарный поиск? У вас сколько данных: если мало - последовательный перебор может оказаться быстрее. Как минимум нам не надо сортировать коллекцию перед тем как делать бинарный поиск. Далее что делать. Если у нас насколько одинаковых элементов в коллекции? Нам подойдёт первый или надо вернуть все? Если коллекция большая, то как вы будете делать поиск? Хорошо если влезет в память, а если раскидана по всему диску, или по нескольким дискам/дата центрам ?

      Так что прежде чем писать надо бы понять что вам надо и зачем.


      1. Kahelman
        30.07.2025 08:56

        Я тут кстати перечитал Маркса, вернее Кнута: Искусство Программирования том 3. Сортировка и поиск: «Хотя идея бинарного поиска достаточно проста, детали его реализации нетривиальны и много неплохих программистов ошибались при первой попытке написать соответствующую программу.»


      1. avost
        30.07.2025 08:56

        Вообще-то правильный ответ должен быть: зачем вам бинарный поиск?

        Ну, мы не знаем в каком виде было сформулировано задание. Возможно, формулировка была исчерпывающей. ))

        сколько данных: если мало - последовательный перебор может оказаться быстрее. Как минимум нам не надо сортировать коллекцию перед тем как делать бинарный поиск.

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

        Если у нас насколько одинаковых элементов в коллекции? Нам подойдёт первый или надо вернуть все?

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

        Так что прежде чем писать надо бы понять что вам надо и зачем.

        всё так, но в данном случае товарищ борется явно не за это ))


  1. Alesh
    30.07.2025 08:56

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


    1. avost
      30.07.2025 08:56

      К уровню сеньора ничего не даст. А, вот если не написал даже такой простой код, даст понять, что точно не сеньор :). По крайней мере, не сеньор в программировании. Может в чём-то другом...


      1. Alesh
        30.07.2025 08:56

        А зачем сеньору писать даже такой простой код для вас? Вы наверное обещаете ему много денег? Много денег за способность написать бинарный поиск?)


        1. avost
          30.07.2025 08:56

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


  1. slepmog
    30.07.2025 08:56

    Это тихой сапой ответ на https://habr.com/ru/articles/911920/ ? :)


  1. agoncharov
    30.07.2025 08:56

    О чем не надо спрашивать на собеседовании - знают многие. О чем надо - никто не знает


  1. yrub
    30.07.2025 08:56

    а чем лично вас эти вопросы напрягают? вам лень отвечать? или вы боитесь что на какой-то не сможете ответить? уже была похожая статья и мнение подобно моему не нравится широкой аудитории, но я считаю что такие вопросы нужны, это проверка на вшивость, опыт, природную внимательность и мотивацию (когда вам лень и не интересно, вы такие вещи не повторяете и делаете работу кое-как, ну сломалось, ну погуглил, ну работает опять, ну да, сидел 3 дня вместо одного запланированного, но это не моя ж проблема, а тим лида теперь). Раз подобные вопросы спрашивают десятилетиями, значит их использование коррелирует с результатом, Билл Гейтс говорил что нужно нанимать отличников, они всегда тоже нанимают отличников, хорошисты же готовы брать троечников и в конечном итоге это плохо для компании. А у меня вопрос к вам: как можно человека считать синьором если он то не помнит, в том не уверен, а с этим никогда не имел дела? Просто за то, что он давно работает? Так он 5 лет мог делать джуновскую работу. Систем дизайн не предлагать, сегодня по нему много информации и это самая простая для джуна тема, а глубоко его нет смысла спрашивать, только если вы не стафа ищете.

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

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


  1. RulenBagdasis
    30.07.2025 08:56

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


    1. Femistoklov
      30.07.2025 08:56

      Лишь бы не так:

      Я тут недавно гонщика в мою команду Формула-1 нанимал, попросил его припарковаться у тротуара.


  1. 15432
    30.07.2025 08:56

    Как-то год проводил собеседования, искали человека, знающего внутрянку операционок, кэширования, многопоточности, вот этого всего. За год и сотню собесов нашли двух (!!). Один отказался по вилке, другой - чел 18 лет, до сих пор работает, насколько знаю. А остальные да, либо готовые либы умеют, либо низкий уровень знают, но микроконтроллеры, а не ОС