Я работаю программистом последние 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. Я не думаю, что это тот человек, которого компании хотят нанять
Комментарии (250)
valera_efremov
30.07.2025 08:56Можно перед собеседованием отправлять ссылку на статью с словами "Готов на собеседование, если у нас сходятся представления о неправильных собеседованиях". Чтобы не тратить ни свое время, ни время рекрутера.
MEGA_Nexus
30.07.2025 08:56В таком случае придётся потом писать статью, "почему я получаю одни отказы и никто не хочет брать меня на работу" или "как я 5 лет жил под мостом, пока искал себе работу в IT".
y_akopov
30.07.2025 08:56Вы упускаете важный момент.
Вся эта теория и база требуется для того, чтобы отдельно взятый сеньор, команда в которой он работает, отдел/департамент генерировали шаблонный (имею ввиду, соблюдение практик, паттернов, теории и т.п.) код, легко читаемый/поддерживаемый.Смотри, у нас тут есть табличка в БД, её надо вывести в CRM
Вы бы видели, какие кандидаты пишут запросы SQL/LINQ в тестовых заданиях. Например, select * в память и там уже сортировка по ключу. А вы, наверное, еще и противник тестовых заданий.
Синьор может выяснить требования у бизнеса, придумать архитектуру, спроектировать БД. И потом всё это реализовать на ЛЮБОМ языке программирования. Не работает так, что если до этого синьор работал 5 лет на Go, то завтра он не сможет написать проект на Java.
Сильное утверждение про "любой" язык и "завтра". Смочь-то, может, что-то и сможет. Но каково будет качество кода и результата на выходе?
придумать архитектуру, спроектировать БД
Как можно придумать архитектуру без знания технических деталей? Как можно спроектировать БД, коогда ты не можешь рассказать про ACID в контексте SQL, про сам SQL, про индексы, уровни изоляции, про профилирование запросов, про шаблоны работы с БД в контексте распределенной системы.
И как тогда, по резюме определить опыт?) 11 лет не говорит о техническом бэкграунде ровным счетом ничего.
probeldev Автор
30.07.2025 08:56Против тестовых кстати ничего не имею.
Вообще это было бы отличное решение, вначале дать тестовое(которое может отразить знания и опыт), а на собеседовании обсуждать почему были выбраны те или другие решения.Но чаще всего тестовые отправляют просто как фильтр сделал/не сделал.
AlexeyPolunin
30.07.2025 08:56Проверяли мы про качество кода - будет нормальное. Особенно если он там не в вакууме, а есть кому посмотреть. Да и сейчас есть AI, который супертул по обучению, он отвечает даже на самые тупые вопросы и не устает.
MkIV007
30.07.2025 08:56Кстати - достали чуваки на собеседованиях, которые отвечают с помощью чата гпт. И все то они знают - пока не задашь вопрос, на котором чат сломается.
i86com
30.07.2025 08:56Вся эта теория и база требуется для того, чтобы отдельно взятый сеньор, команда в которой он работает, отдел/департамент генерировали шаблонный (имею ввиду, соблюдение практик, паттернов, теории и т.п.) код, легко читаемый/поддерживаемый.
Отнюдь. Соблюдение модных сегодня в теории практик и паттернов не ведёт к качеству, читаемости и поддерживаемости кода.
Каноничный пример - посмотрите код любого fizzbuzz. Там и магические цифры/строки, и повторение одних и тех же чисел, и прочие антипаттерны. Но зато - максимальная читаемость и поддерживаемость. Этот код идеален для решения своей задачи.
А любители "базы" обычно приходят и начинают строить FizzBuzz Enterprize Edition. С выносом всех чисел/строк в константы, констант - в конфиги, конфигов - в БД, а раз БД, значит делаем через паттерн service-repository, шардирование, кеширование и т.д. пока сами же благополучно не задолбаются и не скажут, что весь проект нужно переписать с нуля. А пока не переписали, замена "Fizz" на "Jizz" будет требовать два дня работы опытного специалиста (новичок и за неделю не справится). Зато теперь и "специалиста" такого никто не посмеет уволить.
Kahelman
30.07.2025 08:56А вы можете развернуто и правильно ответить про уровни изоляции транзакций? Если да, то применительно к какой БД?
vvbob
30.07.2025 08:56И, главное, сколько раз в год, работая на обычном проекте, вы эти знания будете использовать? Лично из моего опыта - ни разу. Обычно все это требуется либо при тонкой подстройке какой-то работающей БД, либо при ее начальной настройке. Этим обычно занимаются отдельные специально обученные люди, либо, если таких нет, то перед такой работой ты по любому будешь много гуглить и изучать вопрос, лезть в такие настройки с теми обрывками информации, которые остались после ВУЗа и кучи собесов, это просто глупо и опасно.
saaivs
30.07.2025 08:5611 лет не говорит о техническом бэкграунде ровным счетом ничего.
Более того, часто есть риск, что у человека всего лишь 1 год опыта, поторенный 11 раз.
mmMike
30.07.2025 08:56Вы бы видели, какие кандидаты пишут запросы SQL/LINQ в тестовых заданиях. Например, select * в память и там уже сортировка по ключу.
О как категорично. И догматично.
Вот как раз 2 часа назад копался в плане запроса select и была мысль, а не перенсети ли order by на уровень прикладного процесса, что бы уменьшить нагрузку на сервер БД..
Ибо cost на select и order by по меньшей мере сопоставим и даже 2-5% экономии на массовых запроса будет ролять. А в объеме передаваемых данных по TCP/IP разницы нет.
А на хосте/рабочей станции клиента проц ресурсы - это не ресурсы хоста БД.это просто пример. Не более.
RTFM13
30.07.2025 08:56Например, select * в память и там уже сортировка по ключу. А вы, наверное, еще и противник тестовых заданий.
Пфф. Достаём из базы справочник. А дальше меняем сортировку на клиенте сколько угодно раз не трогая базу, накладываем поисковые фильтры и т.п. Актуально если база одна на очень много клиентов, справочник не очень большой, а база в этой системе наиболее нагруженное место.
Всяко лучше чем дёргать базу при каждом движении мышкой.
По поводу "*" есть попросы, но если все поля используются, то это косметика.
Вся эта теория и база требуется для того, чтобы отдельно взятый сеньор, команда в которой он работает, отдел/департамент генерировали шаблонный (имею ввиду, соблюдение практик, паттернов, теории и т.п.) код, легко читаемый/поддерживаемый.
В идеальном мире политика оформления кода должна быть оформлена отдельным документом и прилагаться к должностной инструкции.
В суперидеальном мире она должна быть доступна на собесе чтобы человек посмотрел и сказал готов ли он подстраиваться под такие паттерны. Вместо того чтобы методом тыка искить того, кто с вами на одной волне. А т.к. паттернов бывает очень много, а комбинаций паттернов еще больше, то шансы найти идеал околонулевые.
dr_clinker
30.07.2025 08:56В корне не соглашусь. Вопросы, описанные в статье - как раз собирают в себе все антипаттерны. Никакой о какой ясности и читаемости кода в таком случае речи не идет. Если хотите углубится в техническую часть - дайте развернутое тестовое (без указания решения, но с указанием результата), пусть кандидат покажет себя там, по тестовому-же можно задать вопросы - а это зачем, а это почему. Увидите, как человек пишет код, пишет ли он вашими антипаттернами, которые вы хотели спрашивать. Если очень хочется можно спросить, почему он написал именно так и не иначе, может тут он про антипаттерн и скажет
Dick_from_mountain
30.07.2025 08:56В других сферах такая же ерунда, чел с регалиями и/или из топ компаний создаёт ажиотаж в офисе работодателя. А потом все удивляются почему он не может работать, выдаёт дичь. Потому что знать что-то это одно, а тащить работу изо дня в день это совсем другое. Это как статические и динамические навыки. Если вы способны меняться в нашем неспокойном мире, решать задачи принимая во внимание реальность, это динамический навык. А Хр-хр всё время пытаются оценивать статические.
A1WEB
30.07.2025 08:56Нужно начинать собеседование с обсуждения уровня зарплаты, а там, глядишь, других вопросов и не останется.
dedmagic
30.07.2025 08:56А что значит буква D в аббревиатуре SOLID
Если для Вас SOLID - это просто набор букв, представляю, какой говнокод Вы пишите.
positroid
30.07.2025 08:56Вы не поверите, но не нужно держать в голове все аббревеатуры, определения и паттерны. Не нужно знать DRY для того чтобы писать качественный код. Все и так знают что копипаста зло, а некоторые паттерны настолько очевидны, что "придумываются" сами по себе без банды четырех. Общая осведомленность - хорошо, но не зазубривание
dedmagic
30.07.2025 08:56То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Мне тут минусов накидали: я правильно понимаю, что соблюдать принцип единственной ответственности - это зло? Хм, странно. Весь мой опыт показывает, что несоблюдение этого принципа гарантировано приводит к проблемам, так же, как и несоблюдение DRY.
Ну ОК, возможно, некоторые любят боль...
NimuraF
30.07.2025 08:56Ваш коммент больше похож на снобизм и клоунаду, без обид. SOLID - это буквально на 90% паттерн, который сам собой приходит из ООП, так и DRY (ёлки-палки, мы в принципе пишем программы автоматизации, чтобы не было DRY), смекаете? Вам накидали минусов, что вы в очевидных вещах оперируете придуманными аббревиатурами, для знания которых мне нужно дополнительно что-то прочитать. Да 90% людей, который с пивком на 3 сдали ООП в своей шараге вам все принципы SOLID расскажут, просто они не знают что это за аббревиатура и какая буковка за что там отвечает (и мой пример даже не слишком утрирован)
dedmagic
30.07.2025 08:56Никакого снобизма и клоунады, всё абсолютно искренне.
сам собой приходит из ООП
Большинство разработчиков уровня джун/мидл, с которыми мне приходилось сталкиваться, не знали ничего про SOLID и в результате писали говнокод. После обучения становилось сильно лучше. Так что не надо про "сам собой".
что вы в очевидных вещах оперируете придуманными аббревиатурами, для знания которых мне нужно дополнительно что-то прочитать
Ещё раз - если Вы сами дошли до открытия этих принципов - Вы молодец (без сарказма), но таковые далеко не все. Но даже в Вашем случае допустимо не знать эти аббревиатуры, только если Вы работаете в полном одиночестве.
Знание всех этих аббревиатур, а также паттернов разработки, в первую очередь полезно тем, что создаёт для всех единый язык разработки. Если два человека знают принципы, но не знают эту терминологию, они очень долго будут друг другу объяснять, что же имеют в виду.
akod67
30.07.2025 08:56Вам уже написали, что многие паттерны на столько очевидны и естественны для опытного разработчика, что он будет их использовать, понятия не имея, как они называются и не прочитав книгу банды четырех. Я вот полистал ее на фоне двадцатилетнего опыта программирования, каждый второй паттерн оказывается сам переизобрел. Там половина паттернов абсолютно школьные. И нет, я ни черта не помню их названий.
DenSigma
30.07.2025 08:56Читал я книгу банды четырех. По молодости был в восторге и тоже всем ее пихал в нос. Потом понял, что эта книга - для продажи и заработка, а эти так называемые паттерны - архитектура ради архитектуры.
Cheddar1789
30.07.2025 08:56Неужели самого Вана Хунвеня читал?
danilovmy
30.07.2025 08:56@Cheddar1789- cпасибо за историческую отсылку, полазил, было интересно. Хотя сам Хунвень вряд ли что-то полезное писал (ну я не нашел) - он был не сильно высоко образованным, но зато очень успешным конформистом. Чему, кстати, многим можно у него поучиться.
TSEO1
30.07.2025 08:56Полностью поддерживаю. Только уже, наверное, поле лет пяти написания кода узнал, что я оказываетсяся использую паттерны программирования (причем до некоторых дошел сам) просто не знал, что они так называются.
i86com
30.07.2025 08:56Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Ради Internet Service Provider? In-system programming? Языка ISP?
Не, я, конечно, могу предположить, что имелась в виду четвёртая буква SOLID, но это будет далеко не первым предположением. Впервые в таком виде встречаю.
То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Единственное, для чего я видел применение названий паттернов и аббревиатур в разговоре - чтобы выпендриться. Понятнее это речь не делает, так как эти термины не содержат никаких деталей реализации, но на любой вопрос дают говорящему возможность по-снобистки ответить, мол ты дурак, даже базы не знаешь, книжку иди почитай.
Если человек не может простыми словами объяснить, что он делает и для чего, то он обычно и сам этого не понимает.
playermet
30.07.2025 08:56Странно топить за зазубривание SOLID, и при этом явно подразумевая интуитивное самопально определение ISP, которое не совпадает со смыслом, заложенным его создателями. Делить интерфейсы это хорошо, только это не имеет отношения к ISP в большинстве случаев.
gybson_63
30.07.2025 08:56DRY это вообще очень странная вещь, типа НЧЗ - "Надо Чистить Зубы". Ну надо, еще мама научила, чего повторять то?
positroid
30.07.2025 08:56DRY это еще безобидный пример, если копнуть глубже - всплывают всякие KISS, YAGNI (причем их даже в вакансиях пишут как обязательное требование наравне с SOLID). Сейчас вот еще TANSTAAFL откопал (There Ain’t No Such Thing As A Free Lunch)
gybson_63
30.07.2025 08:56KISS хороший аргумент против графоманов в программировании и травмированных JS. Ну не везде надо каждый раз 500 раз проверять тип.
vvbob
30.07.2025 08:56Причем копипаста зачастую оказывается меньшим злом, чем нагромождение классов и связей между ними, которыми от этой копипасты пытаются избавиться.
delicious
30.07.2025 08:56Вы не поверите, но, чтобы общаться с другими профессионалами в рамках более-менее понятных терминов - надо. Паттерны банды четырех - это именно что "что-то что придумывается само и подходит для большого класса задач, но мы классифицировали его и назвали кратко одним словом". SOLID, ACID, разные принципы - это просто проверка на скорость коммуникации (ну не просто - это еще best practices и чуть-чуть казуистики, потому что цель у нас не код писать, а для бизнеса деньги все-таки зарабатывать).
Так то, 10-летний сеньор может сказать "ну эта, ты вон в ту хрень просто эту штуку прикорячь, и в продакшн".
DenSigma
30.07.2025 08:56Тащемта, solid - это довольно убогая формализация идеологии, которую разработал Дядя Боб. Причем, формализованная не им, а какими-то левыми людьми. Причем ТАК формализованная, и так неправильно понимаемая как формализаторами, так и большинством изучаемых solid, что Дядя Боб ругается (есть где-то видео). Если вы хотите хорошо программировать, то надо не solid по википедии или случайным статьям изучать, и тем более, ЗАЗУБРИВАТЬ, что означают буквы в этом акрониме, а почитать книги Дяди Боба.
В частности, эта S, сингл респонсибилити, понимается совершенно неправильно большинством. Большинство думает, что это значит, что класс должен делать что-то одно, и пишут буквально классы с одним-единственным методом Invoke. Сам же Дядя говорит, что классы могут содержать хоть триста методов, и тем не менее, они действительно удовлетворяют S-принципу.
И да, можно писать код, который формально удовлетворяет SOLID, и тем не менее - лютый говнокод.
poxvuibr
30.07.2025 08:56В частности, эта S, сингл респонсибилити
S это single reason to change
понимается совершенно неправильно большинством
А большинство, да, понимает как сингл респонсибилити
gonzazoid
30.07.2025 08:56Вот прям на последнем собесе у меня спросили про солид. И я ответил что принцип знаю но какая буква за что отвечает - не скажу. Теперь ситуация - нужен был специалист по хромиуму, в итоге взяли сильного сишника который знает что такое солид в надежде что он разберется и с хромиумом. Ок, никаких обид, их право выбирать, само собой. Но отвечая про ваш вы*ер про говнокод - знаете, есть такой уровень на котором код практически не пишешь. В хромиуме 32 миллиона строк кода и там надо не столько уметь писать (и это тоже надо, но не в первую очередь) а уметь читать и понимать паттерны. Не знать как они называются а понимать что они делают и зачем они нужны. И их гораздо больше чем любая методология описывает. Так, вот, а теперь к вопросу моей квалификации как программиста который по памяти не знает солид. Можете посмотреть в мой профиль тут и погуглить меня на реддите. То что я делаю - команды которые подобное вывозят можно по пальцам одной руки пересчитать. А я вывожу это в одну рожицу. Но SOLID не знаю, да беда.
DDroll
30.07.2025 08:56Прочитал тут намедни впервые "Программиста-прагматика", замечательная книга, но написана она программистами "старой школы", теми, кто сперва изучал матан, а потом садился за клаву, носил узорчатые свитера и толстые очки. Так вот забавно было, как все эти принципы, которые вы, попугаи, не понимая сути, можете обозначить только этими аббревиатурами и никакими другими, они называли самовыдуманными терминами. Потому что настоящий программист, а не бест-практис-попугай с конференций, понимает суть этих парадигм, и ему плевать, как их называть. Они ведь простые, как полено, все эти солиды, драи и прочие киссы. Опытный прогер использует их даже не задумываясь, тк они очевидны, и только попугаи произносят их с придыханием, будто одно знание этих аббревиатур поможет им не писать говнокод. И поэтому да, прогер, особенно возрастной, может не знать, что означает какая-то буква в свежевыдуманном смузихлебами с конференций термине, обозначающем какую то простую и очевидную для профессионала вещь.
DenSigma
30.07.2025 08:56Собственно, все эти аббревиатуры - суть только попытка формализации того, что и так известно. Плюс еще возможность заработать на написании книг.
gybson_63
30.07.2025 08:56Все эти принципы очень хорошо понимаются на языках с низкой абстракцией, типа MASM или C. Когда ты сам первым параметром self передаешь всегда (или hWnd) и весь ООП эмулируешь сам. А потом выходитObject Pascal for Windows и так сразу хорошо.
gromyko21
30.07.2025 08:56"А что значит буква D в аббревиатуре SOLID? А в ACID?" Вы хоть раз в жизни за пределами собеседования этой информацией пользовались? Нет? Так к чему эти вопросы?
Все же стоит знать, что такое солид, как и где его стоит применять. Я не говорю о цитировании книги при ответе на подбный вопрос
andreyiq
30.07.2025 08:56Я тимлид и уже не помню, что такое SOLID, даже обидно
gromyko21
30.07.2025 08:56Советую освежить память)
Это один из классических подходов к написанию коду и его проектированию. Не идеальный, конечно, но по моему скромному мнению, лид должен знать эти принципы
andreyiq
30.07.2025 08:56Тут смысл в том, что в начале пути про все это читаешь, знаешь все эти термины, начинаешь применять на практике и от каждого берешь лучше и со временем уже вырабатывается свой подход к разработке и уже не задумываешься откуда это взялось и как называлось, просто на основе опыта знаешь как надо.
SukharevAndrey
30.07.2025 08:56Эту тему уже обсуждали много-много раз в тредах на сотни и тысячи сообщений. Ещё как-то можно понять, когда собеседование в форме экзамена по билетам проводит корпорация, где поток из тысяч людей на вход и тысяч на выход. Эдакое стандартизованное ЕГЭ, чтобы всё было честно и был минимальный bias.
Другое дело, когда более маленькие компании слепо перенимают эти практики из принципа "мы что, хуже, чем Google?".
Не принимаешь правила игры? Ну ок, в Google за тобой очередь из тысяч индусов и китайцев, у которых от зубов отскакивает нахождение цикла в односвязном списке, названия методов в популярных библиотеках и архитектурное описание сервиса по сокращению ссылок.Dick_from_mountain
30.07.2025 08:56Ну дык, потому что есть бизнес-конвейер, есть мелкосерийка, есть кастом-шоп. Везде требования разные, но будем мерить все одним лекалом.
Tony-Sol
30.07.2025 08:56Ну ок, в Google за тобой очередь из тысяч индусов и китайцев, у которых от зубов отскакивает нахождение цикла в односвязном списке, названия методов в популярных библиотеках и архитектурное описание сервиса по сокращению ссылок
и, судя по качеству их сервисов, больше ничего
ky0
30.07.2025 08:56Задавать с порога абстрактные вопросы на архитектуру - как-то странно. Начать с пары вопросов на базу, на мой взгляд, напротив - полезно, потому что их при желании легко углубить и таким образом понять, какой у соискателя опыт (на самом деле). Ну и высокомерных истеричек мгновенно зашедших мне в карму заодно отсеиваем, которые может по хардам и правда сеньоры, но софтово всем плешь проедят, если их нанять.
BALOBASTA
30.07.2025 08:56А потом команда с горящей попой ночью чинит прод, потому что синьор написал для маленькой простой подзадачки не бинарный поиск а экспоненциальный алгоритм и все легло
R3ndly
30.07.2025 08:56А такое часто встречается? Да и почему это с горящей жопой?) Бред. Автор сказал, что нужно уметь решать таски, а не дрочить литкод
n0isy
30.07.2025 08:56Бинарный поиск как частный случай встречается не часто. Вот зато мест, где программист не подумав сделал О(N*N), прямо сплошь и рядом.
А почему надо с горящей попой это на проде исправлять, потому что именно такие алгоритмы очень коварны: они не тормозят на тестовых данных, но кладут прод.
faiwer
30.07.2025 08:56А такое часто встречается?
Я каждый божий день вижу O(n^2) вместо O(n) в code review. В подавляющем большинстве случаев люди вообще не понимают что с кодом что-то не так.
Приложение как-то шевелится, ибо N не столь велико. Плюс раз в квартал кто-нибудь исправляет этот квадрат (а иногда и куб) и наверное даже получает премию. Там прямо целое расследование проводится, с performance marker-ами. Отчёты пишутся. Графики "было\стало" рисуются. В ладоши хлопают и лайки под постами ставят. Смотрите как оптимизировали.
И лишь немногие смотрят на это со стороны с facepalm-ами. Стоит поднять эту тему - сразу слышишь про preliminary optimization is the root of all evil.
Вот банальщина, которую прочитал прямо сегодня. AI генерирует по токенам свой ответ. Надо этот ответ передавать с сервера на клиент. Передаём весь текст на каждое обновление. Квадрат на ровном месте. Обсудили. И кажется никто исправлять пока не хочет. "Не ну а чо, пока тянем же. Я проблему в DD не вижу".
Мне такое даже в репу пушить было бы стрёмно.
Иногда мне кажется, что software development проклят.
DenSigma
30.07.2025 08:56простите, зачем писать бинарный поиск? Где? Можно начерно кейс обрисовать, когда и зачем это может понадобиться?
OldNileCrocodile
30.07.2025 08:56Patient Sorting. Когда нужно разложить пасьянс в картах ну или найти монотонную кучку в кучке. (21 21 1 2 3 1) -> (1 2 3)
Kuch
30.07.2025 08:56Это у вас в сервисе на проде пасьянс раскладывается?
DrGluck07
30.07.2025 08:56Во-первых, это красиво...
kreo_OL
30.07.2025 08:56а во вторых наверняка уже все и так готово, но надо часы списать, вторая работа сама себя не поработает.
как пример
https://learn.microsoft.com/ru-ru/dotnet/api/system.array.binarysearch?view=net-8.0
https://docs.python.org/3/library/bisect.html
40kTons
30.07.2025 08:56Мне пригодился бинарный поиск год назад. Была gui программа, в которой была форма с парой десятков галочек настроек. Каждая галочка включала какую-то функциональность. Каждая функциональность весьма долго отрабатывала. Была одна конкретная функциональность, которую мне надо было найти, но она входила в одну из этих галочек и по названию функциональностей в этой форме нельзя было сказать, к какой конкретно галочке она подходит. Вот тут пригодился бинарных поиск (хотя я его не писал, я его руками проделывал). Вместо "выключу все галочки, включу первую, посмотрю, включу вторую, посмотрю" было "включу половину и посмотрю, если функциональность есть, то выключу половину из включенных"
orenty7
30.07.2025 08:56Даже интересно стало как поиск можно экспоненциально написать. Единственное что придумал -- случайно выбирать элемент массива и проверять тот ли это элемент, но чтобы такое писать нужно быть крайне упоротым.
0Bannon
30.07.2025 08:56Хватит спрашивать джуниорские вопросы у сеньоров. Спрашивайте сеньорские у джуниоров.
Viacheslav01
30.07.2025 08:56Иногда ощущение странно от таких вопросов из методички для первого года изучения IT и резолюций типа не умеет писать цикл for в блокноте )))
Примерно как зачисление в 10 класс, институт, магистратуру и асперантуру для всех всегда начинается с ОГЭ )))
П.С. когда то давно лет 30 назад угодил в психушку когда на вопрос психиатра в военкомате, солнце вращается вокруг земли или земля вокруг солнца, ответил, что они вращаются вокруг общего центра масс )))
pavelsha
30.07.2025 08:56П.С. когда то давно лет 30 назад угодил в психушку когда на вопрос психиатра в военкомате, солнце вращается вокруг земли или земля вокруг солнца, ответил, что они вращаются вокруг общего центра масс )))
Это как мягко с Вами... А всего 500 лет назад могли бы и сжечь. Впрочем есть подозрение, что вопрос про солнце и землю был финальным, а решение "отправить этого на коррекцию" появилось у психиатра несколько раньше.
Viacheslav01
30.07.2025 08:56Да конечно с нами психами иначе нельзя, всегда надо добивающий про солнце и землю.
Duke_nukeum
30.07.2025 08:56Ну так понятно почему отправили, ведь это неправда, т.к. есть другие планеты, которые влияют на то как вращаются земля и солнце :)
Denwer_py
Полностью согласен с автором. Хорошо, что не у меня одного это болит.
kneaded
Согласен и поддерживаю. Может вот эти волки в IT которые ломают эту систему, с помощью них может наконец-то начнут спрашивать реальные кейсы, реальные решения проблем
dalerank
Извините но нет, после того как мне пришлось объяснять своему 30-летнему лиду плюсовое правило 0-3-5 и почему виртуальная функция сломает деструктор в его комите, я буду спрашивать эти глупые вещи на собеседовании, хотя бы для того чтобы понять что кандидат в теме.
kneaded
Прочитал про "правило трёх". Мне кажется это тоже относится к реальным кейсам, в отличии от таких вопросов как "что делает питон, когда ты аннотируешь функцию с помощью декоратора?". Я этот вопрос завалил, ибо он относится к "выдай мне то что пишут в учебниках", но никак не относится к реальным кейсам. Вот если бы спросили мол вообще зачем нужен декоратор - я бы ответил. И как пользоваться, и как создавать.
Так что конкретно ваш вопрос 0-3-5 это больше относится к жизни, к практике, и он вовсе не является глупым вопросом. Вы ж спрашиваете небось зачем вообще это правило, а не "выдай мне все 5 методов из правила и какой где применяется, перечисли и обоснуй" и потом ставите минус на кандидате когда хоть 1 метод не был перечислен.
Вот если вы про второе, типа просто перечисли и где какое правило применяется - вот тогда да, волки на такое аж сбегутся, вот у вас он посчитают легко пройти собеседование
VladimirLadynev
Не было раньше такого названия "0-3-5". Связанные с ним практики, конечно, были. Человек просто может не знать термина :)
mayorovp
"Правило трёх" - возможно, но вот "правило пяти" и "правило нуля" с самого своего появления назывались именно так.