Comments 307
Полностью согласен с автором. Хорошо, что не у меня одного это болит.
Согласен и поддерживаю. Может вот эти волки в IT которые ломают эту систему, с помощью них может наконец-то начнут спрашивать реальные кейсы, реальные решения проблем
Извините но нет, после того как мне пришлось объяснять своему 30-летнему лиду плюсовое правило 0-3-5 и почему виртуальная функция сломает деструктор в его комите, я буду спрашивать эти глупые вещи на собеседовании, хотя бы для того чтобы понять что кандидат в теме.
Прочитал про "правило трёх". Мне кажется это тоже относится к реальным кейсам, в отличии от таких вопросов как "что делает питон, когда ты аннотируешь функцию с помощью декоратора?". Я этот вопрос завалил, ибо он относится к "выдай мне то что пишут в учебниках", но никак не относится к реальным кейсам. Вот если бы спросили мол вообще зачем нужен декоратор - я бы ответил. И как пользоваться, и как создавать.
Так что конкретно ваш вопрос 0-3-5 это больше относится к жизни, к практике, и он вовсе не является глупым вопросом. Вы ж спрашиваете небось зачем вообще это правило, а не "выдай мне все 5 методов из правила и какой где применяется, перечисли и обоснуй" и потом ставите минус на кандидате когда хоть 1 метод не был перечислен.
Вот если вы про второе, типа просто перечисли и где какое правило применяется - вот тогда да, волки на такое аж сбегутся, вот у вас он посчитают легко пройти собеседование
Не было раньше такого названия "0-3-5". Связанные с ним практики, конечно, были. Человек просто может не знать термина :)
Можно перед собеседованием отправлять ссылку на статью с словами "Готов на собеседование, если у нас сходятся представления о неправильных собеседованиях". Чтобы не тратить ни свое время, ни время рекрутера.
Вы упускаете важный момент.
Вся эта теория и база требуется для того, чтобы отдельно взятый сеньор, команда в которой он работает, отдел/департамент генерировали шаблонный (имею ввиду, соблюдение практик, паттернов, теории и т.п.) код, легко читаемый/поддерживаемый.
Смотри, у нас тут есть табличка в БД, её надо вывести в CRM
Вы бы видели, какие кандидаты пишут запросы SQL/LINQ в тестовых заданиях. Например, select * в память и там уже сортировка по ключу. А вы, наверное, еще и противник тестовых заданий.
Синьор может выяснить требования у бизнеса, придумать архитектуру, спроектировать БД. И потом всё это реализовать на ЛЮБОМ языке программирования. Не работает так, что если до этого синьор работал 5 лет на Go, то завтра он не сможет написать проект на Java.
Сильное утверждение про "любой" язык и "завтра". Смочь-то, может, что-то и сможет. Но каково будет качество кода и результата на выходе?
придумать архитектуру, спроектировать БД
Как можно придумать архитектуру без знания технических деталей? Как можно спроектировать БД, коогда ты не можешь рассказать про ACID в контексте SQL, про сам SQL, про индексы, уровни изоляции, про профилирование запросов, про шаблоны работы с БД в контексте распределенной системы.
И как тогда, по резюме определить опыт?) 11 лет не говорит о техническом бэкграунде ровным счетом ничего.
Против тестовых кстати ничего не имею.
Вообще это было бы отличное решение, вначале дать тестовое(которое может отразить знания и опыт), а на собеседовании обсуждать почему были выбраны те или другие решения.
Но чаще всего тестовые отправляют просто как фильтр сделал/не сделал.
Проверяли мы про качество кода - будет нормальное. Особенно если он там не в вакууме, а есть кому посмотреть. Да и сейчас есть AI, который супертул по обучению, он отвечает даже на самые тупые вопросы и не устает.
Вся эта теория и база требуется для того, чтобы отдельно взятый сеньор, команда в которой он работает, отдел/департамент генерировали шаблонный (имею ввиду, соблюдение практик, паттернов, теории и т.п.) код, легко читаемый/поддерживаемый.
Отнюдь. Соблюдение модных сегодня в теории практик и паттернов не ведёт к качеству, читаемости и поддерживаемости кода.
Каноничный пример - посмотрите код любого fizzbuzz. Там и магические цифры/строки, и повторение одних и тех же чисел, и прочие антипаттерны. Но зато - максимальная читаемость и поддерживаемость. Этот код идеален для решения своей задачи.
А любители "базы" обычно приходят и начинают строить FizzBuzz Enterprize Edition. С выносом всех чисел/строк в константы, констант - в конфиги, конфигов - в БД, а раз БД, значит делаем через паттерн service-repository, шардирование, кеширование и т.д. пока сами же благополучно не задолбаются и не скажут, что весь проект нужно переписать с нуля. А пока не переписали, замена "Fizz" на "Jizz" будет требовать два дня работы опытного специалиста (новичок и за неделю не справится). Зато теперь и "специалиста" такого никто не посмеет уволить.
А вы можете развернуто и правильно ответить про уровни изоляции транзакций? Если да, то применительно к какой БД?
И, главное, сколько раз в год, работая на обычном проекте, вы эти знания будете использовать? Лично из моего опыта - ни разу. Обычно все это требуется либо при тонкой подстройке какой-то работающей БД, либо при ее начальной настройке. Этим обычно занимаются отдельные специально обученные люди, либо, если таких нет, то перед такой работой ты по любому будешь много гуглить и изучать вопрос, лезть в такие настройки с теми обрывками информации, которые остались после ВУЗа и кучи собесов, это просто глупо и опасно.
Так, может, вопрос в проекте, а не синьоре?
Есть у меня пара групп «сеньоров» — одни добавили read-committed чтобы не разбираться и не переписывать легаси, другие — пошли дальше и сказали, что для нашей аппки, которая подрубается к cdc базы нужен исключительно snapshot isolation. Первые хотят zero downtime deployment, а вторые непрерывную репликацию изменений, даже в случае DDL. Но ни одних ни вторых ничего не смущает, когда аппки конфликтуют, и, конечно же, решение от синьоров - никогда не деплоить обе аппки одновременно.
Синьор должен разбираться в тех технологиях, которые ему поручены чтобы а) не мешать другим, б) не решать одну проблему, создавая несколько новых. Поэтому я думаю, что базовые вопросы в некоторых случаях полезны
Я и не утверждаю что знать это все не нужно, просто одно дело знать что эти уровни изоляции существуют, примерно понимать как их изменение может "ударить тебя по голове" в будущем, но какие-то подробности обычно в голове нет просто смысла держать, они и не держатся, быстро рассеиваются после сдачи экзаменов или прохождения собесов. Если мне нужно будет создать какую-то БД с экстремально высокой производительностью, то я и заморочусь уровнями изоляции, почитаю теорию, возможно проведу разные эксперименты в тестовом окружении. Для, рядовых задач, с которыми сталкиваешься на практике, обычно хватает дефолтных настроек баз данных, они обычно представляют неплохой компромисс между скоростью и безопасностью.
11 лет не говорит о техническом бэкграунде ровным счетом ничего.
Более того, часто есть риск, что у человека всего лишь 1 год опыта, поторенный 11 раз.
Вы бы видели, какие кандидаты пишут запросы SQL/LINQ в тестовых заданиях. Например, select * в память и там уже сортировка по ключу.
О как категорично. И догматично.
Вот как раз 2 часа назад копался в плане запроса select и была мысль, а не перенсети ли order by на уровень прикладного процесса, что бы уменьшить нагрузку на сервер БД..
Ибо cost на select и order by по меньшей мере сопоставим и даже 2-5% экономии на массовых запроса будет ролять. А в объеме передаваемых данных по TCP/IP разницы нет.
А на хосте/рабочей станции клиента проц ресурсы - это не ресурсы хоста БД.
это просто пример. Не более.
У меня была ситуация, когда нужно было отдавать некие агрегированные отчетные данные, и честный SQL в нашей нормализованной таблице с пачкой join-ов, группировок, сортировок, аггрегирующих функций и т.д. на малом объеме данных работал дольше, чем "попиленный пополам" (т.е. часть запроса таки выполняется в БД, а часть - таки в памяти приложения). Понятно, что в таких кейсах нужно денормализовать, и вообще отчетные данные хранить не в условном MSSQL, и т.д. и т.п., но в моменте и в конкретном кейсе дешевле было вынести часть запроса в БД на уровень памяти приложения.
Например, select * в память и там уже сортировка по ключу. А вы, наверное, еще и противник тестовых заданий.
Пфф. Достаём из базы справочник. А дальше меняем сортировку на клиенте сколько угодно раз не трогая базу, накладываем поисковые фильтры и т.п. Актуально если база одна на очень много клиентов, справочник не очень большой, а база в этой системе наиболее нагруженное место.
Всяко лучше чем дёргать базу при каждом движении мышкой.
По поводу "*" есть попросы, но если все поля используются, то это косметика.
Вся эта теория и база требуется для того, чтобы отдельно взятый сеньор, команда в которой он работает, отдел/департамент генерировали шаблонный (имею ввиду, соблюдение практик, паттернов, теории и т.п.) код, легко читаемый/поддерживаемый.
В идеальном мире политика оформления кода должна быть оформлена отдельным документом и прилагаться к должностной инструкции.
В суперидеальном мире она должна быть доступна на собесе чтобы человек посмотрел и сказал готов ли он подстраиваться под такие паттерны. Вместо того чтобы методом тыка искить того, кто с вами на одной волне. А т.к. паттернов бывает очень много, а комбинаций паттернов еще больше, то шансы найти идеал околонулевые.
В корне не соглашусь. Вопросы, описанные в статье - как раз собирают в себе все антипаттерны. Никакой о какой ясности и читаемости кода в таком случае речи не идет. Если хотите углубится в техническую часть - дайте развернутое тестовое (без указания решения, но с указанием результата), пусть кандидат покажет себя там, по тестовому-же можно задать вопросы - а это зачем, а это почему. Увидите, как человек пишет код, пишет ли он вашими антипаттернами, которые вы хотели спрашивать. Если очень хочется можно спросить, почему он написал именно так и не иначе, может тут он про антипаттерн и скажет
В других сферах такая же ерунда, чел с регалиями и/или из топ компаний создаёт ажиотаж в офисе работодателя. А потом все удивляются почему он не может работать, выдаёт дичь. Потому что знать что-то это одно, а тащить работу изо дня в день это совсем другое. Это как статические и динамические навыки. Если вы способны меняться в нашем неспокойном мире, решать задачи принимая во внимание реальность, это динамический навык. А Хр-хр всё время пытаются оценивать статические.
Нужно начинать собеседование с обсуждения уровня зарплаты, а там, глядишь, других вопросов и не останется.
А что значит буква D в аббревиатуре SOLID
Если для Вас SOLID - это просто набор букв, представляю, какой говнокод Вы пишите.
Вы не поверите, но не нужно держать в голове все аббревеатуры, определения и паттерны. Не нужно знать DRY для того чтобы писать качественный код. Все и так знают что копипаста зло, а некоторые паттерны настолько очевидны, что "придумываются" сами по себе без банды четырех. Общая осведомленность - хорошо, но не зазубривание
То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Мне тут минусов накидали: я правильно понимаю, что соблюдать принцип единственной ответственности - это зло? Хм, странно. Весь мой опыт показывает, что несоблюдение этого принципа гарантировано приводит к проблемам, так же, как и несоблюдение DRY.
Ну ОК, возможно, некоторые любят боль...
Ваш коммент больше похож на снобизм и клоунаду, без обид. SOLID - это буквально на 90% паттерн, который сам собой приходит из ООП, так и DRY (ёлки-палки, мы в принципе пишем программы автоматизации, чтобы не было DRY), смекаете? Вам накидали минусов, что вы в очевидных вещах оперируете придуманными аббревиатурами, для знания которых мне нужно дополнительно что-то прочитать. Да 90% людей, который с пивком на 3 сдали ООП в своей шараге вам все принципы SOLID расскажут, просто они не знают что это за аббревиатура и какая буковка за что там отвечает (и мой пример даже не слишком утрирован)
Никакого снобизма и клоунады, всё абсолютно искренне.
сам собой приходит из ООП
Большинство разработчиков уровня джун/мидл, с которыми мне приходилось сталкиваться, не знали ничего про SOLID и в результате писали говнокод. После обучения становилось сильно лучше. Так что не надо про "сам собой".
что вы в очевидных вещах оперируете придуманными аббревиатурами, для знания которых мне нужно дополнительно что-то прочитать
Ещё раз - если Вы сами дошли до открытия этих принципов - Вы молодец (без сарказма), но таковые далеко не все. Но даже в Вашем случае допустимо не знать эти аббревиатуры, только если Вы работаете в полном одиночестве.
Знание всех этих аббревиатур, а также паттернов разработки, в первую очередь полезно тем, что создаёт для всех единый язык разработки. Если два человека знают принципы, но не знают эту терминологию, они очень долго будут друг другу объяснять, что же имеют в виду.
Вам уже написали, что многие паттерны на столько очевидны и естественны для опытного разработчика, что он будет их использовать, понятия не имея, как они называются и не прочитав книгу банды четырех. Я вот полистал ее на фоне двадцатилетнего опыта программирования, каждый второй паттерн оказывается сам переизобрел. Там половина паттернов абсолютно школьные. И нет, я ни черта не помню их названий.
Читал я книгу банды четырех. По молодости был в восторге и тоже всем ее пихал в нос. Потом понял, что эта книга - для продажи и заработка, а эти так называемые паттерны - архитектура ради архитектуры.
Неужели самого Вана Хунвеня читал?
@Cheddar1789- cпасибо за историческую отсылку, полазил, было интересно. Хотя сам Хунвень вряд ли что-то полезное писал (ну я не нашел) - он был не сильно высоко образованным, но зато очень успешным конформистом. Чему, кстати, многим можно у него поучиться.
Полностью поддерживаю. Только уже, наверное, поле лет пяти написания кода узнал, что я оказываетсяся использую паттерны программирования (причем до некоторых дошел сам) просто не знал, что они так называются.
Да 90% людей, который с пивком на 3 сдали ООП в своей шараге вам все принципы SOLID расскажут
Справедливости ради - не расскажут. Принимаю ООП почти 20 лет в своей шараге и знаю, о чем говорю. У меня ещё не было ещё таких людей, которые бы сдали на 3, но при этом рассказали бы SOLID.
Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Ради Internet Service Provider? In-system programming? Языка ISP?
Не, я, конечно, могу предположить, что имелась в виду четвёртая буква SOLID, но это будет далеко не первым предположением. Впервые в таком виде встречаю.
То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Единственное, для чего я видел применение названий паттернов и аббревиатур в разговоре - чтобы выпендриться. Понятнее это речь не делает, так как эти термины не содержат никаких деталей реализации, но на любой вопрос дают говорящему возможность по-снобистки ответить, мол ты дурак, даже базы не знаешь, книжку иди почитай.
Если человек не может простыми словами объяснить, что он делает и для чего, то он обычно и сам этого не понимает.
Странно топить за зазубривание SOLID, и при этом явно подразумевая интуитивное самопально определение ISP, которое не совпадает со смыслом, заложенным его создателями. Делить интерфейсы это хорошо, только это не имеет отношения к ISP в большинстве случаев.
Поправлю сам себя. Я тупанул и подумал, что имелся ввиду принцип единичной ответственности, когда там был принцип разделения интерфейсов. Впрочем, это лишь очередной аргумент в пользу того, чтобы не пользоваться этими аббревиатурами, потому что в живом общении при разработке их мало кто так употребляет.
DRY это вообще очень странная вещь, типа НЧЗ - "Надо Чистить Зубы". Ну надо, еще мама научила, чего повторять то?
DRY это еще безобидный пример, если копнуть глубже - всплывают всякие KISS, YAGNI (причем их даже в вакансиях пишут как обязательное требование наравне с SOLID). Сейчас вот еще TANSTAAFL откопал (There Ain’t No Such Thing As A Free Lunch)
Причем копипаста зачастую оказывается меньшим злом, чем нагромождение классов и связей между ними, которыми от этой копипасты пытаются избавиться.
Так и есть, и как раз в этом нетривиальность DRY, которая часто опускается его некритичными пропонентами.
Как раз недавно был живой пример - решал задачу, в которой сложный алгоритм обрабатывал две сущности в БД, которые были практически копиями друг-друга, но при этом они были логически разными вещами, при своей похожести. Сделал два отдельных сервиса, реализующие практически идентичный алгоритм, ну и да, было много копипасты в них. На ревью получил по этому поводу замечания, но сумел свое решение отстоять и убедить ревьюверов в своей правоте..
Позже другой коллега решил код "улучшить" и переделал все в абстрактный класс с парой реализаций, позже оказалось что алгоритм (ожидаемо) нужен все-же не одинаковый, в абстрактный класс напихали костылей, по определению конкретной сущности что-бы пойти по другой ветке алгоритма.. да и обрабатывал он совершенно не связанные друг-с другом сущности, в общем код превратился в воняющую кучу костылей.. А чуть позже я просто в итоге все это выкинул, и обработка ушла в БД (да, это не кошерно, но требовалась максимальная производительность, которую код на Яве просто не обеспечивал, он не успевал отработать в требуемое время).
Вы не поверите, но, чтобы общаться с другими профессионалами в рамках более-менее понятных терминов - надо. Паттерны банды четырех - это именно что "что-то что придумывается само и подходит для большого класса задач, но мы классифицировали его и назвали кратко одним словом". SOLID, ACID, разные принципы - это просто проверка на скорость коммуникации (ну не просто - это еще best practices и чуть-чуть казуистики, потому что цель у нас не код писать, а для бизнеса деньги все-таки зарабатывать).
Так то, 10-летний сеньор может сказать "ну эта, ты вон в ту хрень просто эту штуку прикорячь, и в продакшн".
Тащемта, solid - это довольно убогая формализация идеологии, которую разработал Дядя Боб. Причем, формализованная не им, а какими-то левыми людьми. Причем ТАК формализованная, и так неправильно понимаемая как формализаторами, так и большинством изучаемых solid, что Дядя Боб ругается (есть где-то видео). Если вы хотите хорошо программировать, то надо не solid по википедии или случайным статьям изучать, и тем более, ЗАЗУБРИВАТЬ, что означают буквы в этом акрониме, а почитать книги Дяди Боба.
В частности, эта S, сингл респонсибилити, понимается совершенно неправильно большинством. Большинство думает, что это значит, что класс должен делать что-то одно, и пишут буквально классы с одним-единственным методом Invoke. Сам же Дядя говорит, что классы могут содержать хоть триста методов, и тем не менее, они действительно удовлетворяют S-принципу.
И да, можно писать код, который формально удовлетворяет SOLID, и тем не менее - лютый говнокод.
Вот прям на последнем собесе у меня спросили про солид. И я ответил что принцип знаю но какая буква за что отвечает - не скажу. Теперь ситуация - нужен был специалист по хромиуму, в итоге взяли сильного сишника который знает что такое солид в надежде что он разберется и с хромиумом. Ок, никаких обид, их право выбирать, само собой. Но отвечая про ваш вы*ер про говнокод - знаете, есть такой уровень на котором код практически не пишешь. В хромиуме 32 миллиона строк кода и там надо не столько уметь писать (и это тоже надо, но не в первую очередь) а уметь читать и понимать паттерны. Не знать как они называются а понимать что они делают и зачем они нужны. И их гораздо больше чем любая методология описывает. Так, вот, а теперь к вопросу моей квалификации как программиста который по памяти не знает солид. Можете посмотреть в мой профиль тут и погуглить меня на реддите. То что я делаю - команды которые подобное вывозят можно по пальцам одной руки пересчитать. А я вывожу это в одну рожицу. Но SOLID не знаю, да беда.
Прочитал тут намедни впервые "Программиста-прагматика", замечательная книга, но написана она программистами "старой школы", теми, кто сперва изучал матан, а потом садился за клаву, носил узорчатые свитера и толстые очки. Так вот забавно было, как все эти принципы, которые вы, попугаи, не понимая сути, можете обозначить только этими аббревиатурами и никакими другими, они называли самовыдуманными терминами. Потому что настоящий программист, а не бест-практис-попугай с конференций, понимает суть этих парадигм, и ему плевать, как их называть. Они ведь простые, как полено, все эти солиды, драи и прочие киссы. Опытный прогер использует их даже не задумываясь, тк они очевидны, и только попугаи произносят их с придыханием, будто одно знание этих аббревиатур поможет им не писать говнокод. И поэтому да, прогер, особенно возрастной, может не знать, что означает какая-то буква в свежевыдуманном смузихлебами с конференций термине, обозначающем какую то простую и очевидную для профессионала вещь.
Собственно, все эти аббревиатуры - суть только попытка формализации того, что и так известно. Плюс еще возможность заработать на написании книг.
Все эти принципы очень хорошо понимаются на языках с низкой абстракцией, типа MASM или C. Когда ты сам первым параметром self передаешь всегда (или hWnd) и весь ООП эмулируешь сам. А потом выходитObject Pascal for Windows и так сразу хорошо.
Извиняюсь. Вы случайно не преподаватель?
"А что значит буква D в аббревиатуре SOLID? А в ACID?" Вы хоть раз в жизни за пределами собеседования этой информацией пользовались? Нет? Так к чему эти вопросы?
Все же стоит знать, что такое солид, как и где его стоит применять. Я не говорю о цитировании книги при ответе на подбный вопрос
Эту тему уже обсуждали много-много раз в тредах на сотни и тысячи сообщений. Ещё как-то можно понять, когда собеседование в форме экзамена по билетам проводит корпорация, где поток из тысяч людей на вход и тысяч на выход. Эдакое стандартизованное ЕГЭ, чтобы всё было честно и был минимальный bias.
Другое дело, когда более маленькие компании слепо перенимают эти практики из принципа "мы что, хуже, чем Google?".
Не принимаешь правила игры? Ну ок, в Google за тобой очередь из тысяч индусов и китайцев, у которых от зубов отскакивает нахождение цикла в односвязном списке, названия методов в популярных библиотеках и архитектурное описание сервиса по сокращению ссылок.
Ну дык, потому что есть бизнес-конвейер, есть мелкосерийка, есть кастом-шоп. Везде требования разные, но будем мерить все одним лекалом.
Ну ок, в Google за тобой очередь из тысяч индусов и китайцев, у которых от зубов отскакивает нахождение цикла в односвязном списке, названия методов в популярных библиотеках и архитектурное описание сервиса по сокращению ссылок
и, судя по качеству их сервисов, больше ничего
Задавать с порога абстрактные вопросы на архитектуру - как-то странно. Начать с пары вопросов на базу, на мой взгляд, напротив - полезно, потому что их при желании легко углубить и таким образом понять, какой у соискателя опыт (на самом деле). Ну и высокомерных истеричек мгновенно зашедших мне в карму заодно отсеиваем, которые может по хардам и правда сеньоры, но софтово всем плешь проедят, если их нанять.
А потом команда с горящей попой ночью чинит прод, потому что синьор написал для маленькой простой подзадачки не бинарный поиск а экспоненциальный алгоритм и все легло
Верим твёрдо и чётко!
А такое часто встречается? Да и почему это с горящей жопой?) Бред. Автор сказал, что нужно уметь решать таски, а не дрочить литкод
Бинарный поиск как частный случай встречается не часто. Вот зато мест, где программист не подумав сделал О(N*N), прямо сплошь и рядом.
А почему надо с горящей попой это на проде исправлять, потому что именно такие алгоритмы очень коварны: они не тормозят на тестовых данных, но кладут прод.
А такое часто встречается?
Я каждый божий день вижу O(n^2) вместо O(n) в code review. В подавляющем большинстве случаев люди вообще не понимают что с кодом что-то не так.
Приложение как-то шевелится, ибо N не столь велико. Плюс раз в квартал кто-нибудь исправляет этот квадрат (а иногда и куб) и наверное даже получает премию. Там прямо целое расследование проводится, с performance marker-ами. Отчёты пишутся. Графики "было\стало" рисуются. В ладоши хлопают и лайки под постами ставят. Смотрите как оптимизировали.
И лишь немногие смотрят на это со стороны с facepalm-ами. Стоит поднять эту тему - сразу слышишь про preliminary optimization is the root of all evil.
Вот банальщина, которую прочитал прямо сегодня. AI генерирует по токенам свой ответ. Надо этот ответ передавать с сервера на клиент. Передаём весь текст на каждое обновление. Квадрат на ровном месте. Обсудили. И кажется никто исправлять пока не хочет. "Не ну а чо, пока тянем же. Я проблему в DD не вижу".
Мне такое даже в репу пушить было бы стрёмно.
Иногда мне кажется, что software development проклят.
Вы когда лично последний раз с нуля поиск писали? Честно
простите, зачем писать бинарный поиск? Где? Можно начерно кейс обрисовать, когда и зачем это может понадобиться?
Patient Sorting. Когда нужно разложить пасьянс в картах ну или найти монотонную кучку в кучке. (21 21 1 2 3 1) -> (1 2 3)
На карточных объемах можно и пузырьком ;)
Это у вас в сервисе на проде пасьянс раскладывается?
Во-первых, это красиво...
а во вторых наверняка уже все и так готово, но надо часы списать, вторая работа сама себя не поработает.
как пример
https://learn.microsoft.com/ru-ru/dotnet/api/system.array.binarysearch?view=net-8.0
https://docs.python.org/3/library/bisect.html
Мне пригодился бинарный поиск год назад. Была gui программа, в которой была форма с парой десятков галочек настроек. Каждая галочка включала какую-то функциональность. Каждая функциональность весьма долго отрабатывала. Была одна конкретная функциональность, которую мне надо было найти, но она входила в одну из этих галочек и по названию функциональностей в этой форме нельзя было сказать, к какой конкретно галочке она подходит. Вот тут пригодился бинарных поиск (хотя я его не писал, я его руками проделывал). Вместо "выключу все галочки, включу первую, посмотрю, включу вторую, посмотрю" было "включу половину и посмотрю, если функциональность есть, то выключу половину из включенных"
Совсем недавно делал бинарный поиск для нахождения кадра анимации по указанному времени. Есть список keyframe'ов с полем time, и заранее известно, что все они отсортированы по возрастанию по времени. Бинарный поиск позволил значительно уменьшить количество итераций в цикле. Правда ещё на практике выяснилось, что современные компиляторы умеют автоматически векторизировать и параллелизировать циклы, а процессоры видимо не очень любят прыжки по памяти, и поэтому простой for (i..) в этом случае справлялся гораздо эффективнее бинарного поиска... упс.
А можно подробности? Мне вот ни разу не удавалось поймать ситуацию, когда бинарный поиск оказывался хуже последовательного.
Проект на Си, кусок кода с бинарным поиском выглядел таким вот образом:
int Animation_FindFrame(const Animation *animation, float time)
{
int left = 0;
int right = animation->frames_count - 1;
while (left <= right) {
int mid = left + (right - left) / 2;
if (animation->frame_timings[mid] > time) {
right = mid - 1;
} else if (animation->frame_timings[mid + 1] <= time) {
left = mid + 1;
} else {
return mid; // found the appropriate frame
}
}
return -1; // no suitable frame found
}
Мне и самому не совсем очевидно почему в бенчмарках он заметно просаживал fps, но я предполагаю, что это как-то связанно с особенностями работы процессоров. Бинарный поиск "прыгает" по памяти, что по идее должно нарушать предсказуемость доступа к ней, и это может приводить к cache miss. Или возможно if/else плохо предсказываются branch predictor'ом.
На небольших объемах данных (в среднем в анимациях всего по 30-50 ключевых кадров) бинарный поиск скорее всего просто не успевает окупить свою сложность - там ведь внутри цикла присутствует и деление, и несколько ветвлений.
А ещё код компилировался с /arch:AVX2. Бинарный поиск плохо параллелится, что могло тоже какую-то роль сыграть.
Прыжки по памяти и промахи кеша тут точно ни при чём, потому что бинарный поиск обращается к памяти заметно меньше чем последовательный. Загрузить из памяти 6 значений однозначно быстрее чем 25, даже с учётом локальности. Деление на 2 - так и вовсе быстрейшая операция. Вот абсолютно непредсказуемые переходы и правда могут быть проблемой.
Однако, алгоритм тут неоптимален - он экономит менее одной итерации цикла ценой удвоения каждой итерации. Внутри цикла должен быть один if, а не два - и уж точно надо проверять одну ячейку, а не две. Если есть возможность, проверьте вот этот вариант:
/*
* Возвращает номер последнего фрейма, который наступил в указанный момент,
* либо -1 если ни один фрейм не наступил
*/
int Animation_FindFrame(const Animation *animation, float time)
{
int left = -1;
int right = animation->frames_count - 1;
while (left < right) {
int mid = (left + right + 1) / 2;
if (animation->frame_timings[mid] > time) {
right = mid - 1;
} else {
left = mid;
}
}
return left;
}
PS однако, упоминание fps тут настораживает. Если вы делаете поиск фрейма в анимации на каждое обновление - вы явно делаете что-то не так. Почему бы не запоминать какой кадр является текущим, и не "плясать" уже от него?
Хорошие замечания. Мне сложновато будет замерить производительность вашего варианта в реальной программе, но из любопытства я замерил её простеньким бенчмарком:
Скрытый текст
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
typedef struct {
int frame_count;
float *frame_timings;
} Animation;
int Animation_FindFrame__BsearchOld(const Animation *animation, float time)
{
int left = 0;
int right = animation->frame_count - 1;
while (left <= right) {
int mid = left + (right - left) / 2;
if (animation->frame_timings[mid] > time) {
right = mid - 1;
} else if (animation->frame_timings[mid + 1] <= time) {
left = mid + 1;
} else {
return mid;
}
}
return -1;
}
int Animation_FindFrame__BsearchNew(const Animation *animation, float time)
{
int left = -1;
int right = animation->frame_count - 1;
while (left < right) {
int mid = (left + right + 1) / 2;
if (animation->frame_timings[mid] > time) {
right = mid - 1;
} else {
left = mid;
}
}
return left;
}
int Animation_FindFrame__ForiLoop(const Animation *animation, float time)
{
for (int i = 0; i < animation->frame_count - 1; i++) {
if (animation->frame_timings[i + 1] > time)
return i;
}
return -1;
}
int main(void)
{
// 5000 тысяч анимаций, каждая по 50 кадров
int animation_count = 5000;
Animation *animations = malloc(animation_count * sizeof(Animation));
for (int i = 0; i < animation_count; i++) {
animations[i].frame_count = 50;
animations[i].frame_timings = malloc(animations[i].frame_count * sizeof(float));
float time = 0.0f;
for (int j = 0; j < animations[i].frame_count; j++) {
animations[i].frame_timings[j] = time;
time += (float)rand() / RAND_MAX;
}
}
// 100 000 проходов
int samples = 100000;
clock_t start_time, end_time;
volatile int dummy_result = 0;
float animation_max_time = animations[animation_count-1].frame_timings[49];
printf("Elapsed time:\n");
// Test 1: old
start_time = clock();
for (int i = 0; i < samples; ++i) {
float time = (float)i / animation_max_time;
for (int j = 0; j < animation_count; ++j) {
dummy_result |= Animation_FindFrame__BsearchOld(&animations[j], time);
}
}
end_time = clock();
printf("- Binary search OLD: %.6f seconds\n", (double)(end_time - start_time) / CLOCKS_PER_SEC);
// Test 2: new
start_time = clock();
for (int i = 0; i < samples; ++i) {
float time = (float)i / animation_max_time;
for (int j = 0; j < animation_count; ++j) {
dummy_result |= Animation_FindFrame__BsearchNew(&animations[j], time);
}
}
end_time = clock();
printf("- Binary search NEW: %.6f seconds\n", (double)(end_time - start_time) / CLOCKS_PER_SEC);
// Test 3: fori
start_time = clock();
for (int i = 0; i < samples; ++i) {
float time = (float)i / animation_max_time;
for (int j = 0; j < animation_count; ++j) {
dummy_result |= Animation_FindFrame__ForiLoop(&animations[j], time);
}
}
end_time = clock();
printf("- fori loop: %.6f seconds\n", (double)(end_time - start_time) / CLOCKS_PER_SEC);
printf("Dummy: %d\n", dummy_result); // prevents optimization
free(animations);
return 0;
}Для сборки использовал только флаг /O2 и получил такие результаты:
Elapsed time:
- Binary search OLD: 2.714000 seconds
- Binary search NEW: 4.010000 seconds
- fori loop: 0.447000 secondsОчень контринтуитивно. Совсем не понятно откуда берется такая огромная разница в скорости, но это то, что я наблюдал и в реальной программе.
--
Поправка: В бенчмарке была ошибка в расчёте текущего времени анимации, в исправленном виде результат выходит следующий:
Elapsed time:
- Binary search OLD: 4.356000 seconds
- Binary search NEW: 4.934000 seconds
- fori loop: 12.515000 secondsБинарный поиск действительно быстрее, изначально я был не прав. Выигрыш в скорости происходит только во время начального этапа анимации, когда цикл fori совершает не слишком много итераций.
Почему вы animations передаёте параметром? Там разве не должно быть animations[j]?
PS у вас в Animation_FindFrame__ForiLoop цикл надо не с 0, а с -1 начинать. А если ничего не нашлось - возвращать индекс последнего элемента. Иначе ерунда какая-то получается с семантикой возвращаемого значения.
Да, соглашусь. На скорую руку наделал ошибок. С исправлениями результат выходит совсем иной. Этот бенч показал, что всё-таки бинарный поиск эффективнее даже на небольших данных и fori с ним сравняться по скорости удалось лишь при счётчике в 10 кадров. Это очень редкий сценарий и для усредненного случая бинарный поиск будет в большом выигрыше.
А причину того, что я решил, что fori эффективнее, скорее стоит поискать в тестовом окружении, в котором я всё это проверял изначально.
В почти каждом языке в стандартной библиотеке которого используется сортировка вставкой. Место для вставки можно искать бинарным поиском, но обычно ищут линейным, потому что так работает быстрее даже на массивах с миллионами элементов.
На массивах с миллионами элементов, во-первых, бинарный поиск безусловно быстрее. А во-вторых, сортировка вставками на таком количестве элементов умрёт независимо от того какой поиск в ней используется!
Сортировку вставками если и используют, то не более чем для 16 элементов.
Странно, тут какой-то нонейм-дурачек пытался ускорить реализацию сортировки в стандартной библиотеке C++, даже какие-то бенчмарки делал, Александреску его зовут. Прямо из его доклада я украл свое сообщение практически полностью и почти дословно, включая число элементов массива из его бенчмарка.
Сортировка вставками используется под капотом QuickSort. И трешолды он разные пробовал.
Ну и какой в итоге порог получился оптимальный? Неужто и правда миллион элементов вставками сортируется?
Ну и какой в итоге порог получился оптимальный?
Я же дал ссылку на его доклад, даже с таймстампом, там бинарному поиску посвящено минут пять максимум. Оптимальным получилось отказаться от бинарного поиска, которого в изначальной реализации тоже не было, потому что он замедляет QuickSort на 13%. Он даже пробовал разные его вариации, включая branchless. Конкретно в этом случае порог был 32, но он сказал, что пробовал и другие, в том числе больше, и становилось только хуже.
Неужто и правда миллион элементов вставками сортируется?
Еще раз. Сортировка вставками используется под капотом QuickSort. Само собой в стандартной библиотеке ни одного из языков не используется голая сортировка вставками как реализация sort.
Ютуб у меня видео не показывает уже полгода, так что вынужден полагаться на ваши слова.
И так, Александреску сравнивал линейный поиск с бинарным на массивах до 32 элементов, причём не напрямую, а в рамках оптимизации сортировки вставками.
Теперь возвращаемся к вашему комментарию
Место для вставки можно искать бинарным поиском, но обычно ищут линейным, потому что так работает быстрее даже на массивах с миллионами элементов.
…и видим, что ваше утверждение про то, что линейный поиск якобы быстрее бинарного на массивах с миллионами элементов, ничем не обосновано. 32 - это не миллионы!
Учтите контекст, я тут не утверждал что бинарный поиск по массиву в миллион элементов медленней. Я утверждал, что в большинстве языков где в стандартной библиотеке используется сортировка вставками (а это в QuickSort), используется линейный поиск, потому что его замена на бинарный делает хуже, даже на сортируемом массиве в миллионы элементов. А это именно то, что вы и просили - конкретный пример, где бинарный поиск показывает себя хуже.
На всякий случай ссылка на доклад на рутубе.
А на ревью все в команде указать на ошибку посте снялись?)
Даже интересно стало как поиск можно экспоненциально написать. Единственное что придумал -- случайно выбирать элемент массива и проверять тот ли это элемент, но чтобы такое писать нужно быть крайне упоротым.
Хватит спрашивать джуниорские вопросы у сеньоров. Спрашивайте сеньорские у джуниоров.
Иногда ощущение странно от таких вопросов из методички для первого года изучения IT и резолюций типа не умеет писать цикл for в блокноте )))
Примерно как зачисление в 10 класс, институт, магистратуру и асперантуру для всех всегда начинается с ОГЭ )))
П.С. когда то давно лет 30 назад угодил в психушку когда на вопрос психиатра в военкомате, солнце вращается вокруг земли или земля вокруг солнца, ответил, что они вращаются вокруг общего центра масс )))
П.С. когда то давно лет 30 назад угодил в психушку когда на вопрос психиатра в военкомате, солнце вращается вокруг земли или земля вокруг солнца, ответил, что они вращаются вокруг общего центра масс )))
Это как мягко с Вами... А всего 500 лет назад могли бы и сжечь. Впрочем есть подозрение, что вопрос про солнце и землю был финальным, а решение "отправить этого на коррекцию" появилось у психиатра несколько раньше.
Ну так понятно почему отправили, ведь это неправда, т.к. есть другие планеты, которые влияют на то как вращаются земля и солнце :)
Ну такое психиатру в военкомате реально только псих ответить мог.
Зачемсразу "псих". Может это призывник, в которого реинкарнировал Джордано Бруно. 😁😁😁
Впрочем, тогда перед обсуждением астрономических вопросов призывник, скорее всего, схлестнулся с медкомиссией и военкомом в каком-нибудь философском споре.
Я же в хорошем смысле. Просто, вспоминая психиатров из военкомата, хочу заметить, что лично я бы так с ними не рискнул. С ними осторожно надо, как на минном поле.
Если, конечно, твоя цель не подразумевает откосить по психическому нездоровью. :)
С ними осторожно надо, как на минном поле
— Засучите рукава.
— Знаете, а ведь это не единственное место, куда можно колоть.
— %поднимая голову% Ну, во-первых, раздевайтесь, во-вторых, вот вам направления на анализы.
С военкоматом-то мб, ещё и не так страшно, если только нет желания служить. А вот с правами или оружием так шутить действительно чревато.
Фигасе. Мне этот же вопрос (в виде: вокруг чего вращается Земля?) приблизительно в те же времена задали на вступительном в ВУЗ по физике. Услышав «барицентр», экзаменатор расплылся, поставил мне пятёрку и сказал — иди, вундеркинд! :)
по поводу дурацких вопросов и идиотских тестовых заданий тоже хочу поныть тем что эта шиза дошла и до около IT:
вот на робототехника-схемотехника мне предложили такое тестовое задание:
1. разработать малогабаритный умный блок питания, вход с литий железофосфатных батарей 8S, сотни ватт, мало потребляющий при простое/выключении, кпд овер 90% в широком диапазоне выходных токов и напряжений (возможность перестройки на лету от 12 до 24В), софтовое управление по сети, ручное и аварийное управление, резервирование. Разработать схему, топологию платы совместимую с 7pcb jlcpcb производством и сборкой, подготовить файлы заказа в эти две, при этом жесткий лимит по BOM листу и времени производства. при этом партия маленькая - скорее сотни а не тыщи.
2. дан другой блок питания с схемой платой и тд как в пункте 1, исправить ошибки (но там всё плохо и выкинуть проще и переделать с нуля) и подготовить к заказу
3. корпуса и механика для п1 и п2
4. и последующее задания тоже "изи", типа разработать архитектуру инф. беспроводной сети роя складских роботов, или же архитектуру нейронных сетей для фильтрации помех GPS и навигации по камерам где тот не ловит (уровень проработки не о "поговорить об" а конкретика весьма жёсткая под конкретные платформы и ТЗ там на много страниц).
срок неделя. сделать всё.
не РФ, Япония, модный молодёжный стартап
занавес. (нет слов)
Некоторые компании платят по триста миллионов долларов за хороших спецов в хайповой области.
Может этот стартап ищет своего героя супермена?
судя по тому что хотят готовое для заказа и последующего использования - они хотят на халяву получить часть или всю работу по своим ТЗ. там овер 10 страниц мелким текстом этих ТЗ...
обычно после выполнения тебе либо не отвечают либо "after careful consideration..." и потом находишь свой код/схемы на гитхабе. Особенно если домашка не литкод а прям на день и тем более на неделю задание.
удя по тому что хотят готовое для заказа и последующего использования - они хотят на халяву получить часть или всю работу по своим ТЗ
Абсолютно верно
@Mirn не помните, была ли в задании ремарка, типа: "В случае если не согласны выполнять тестовое задание просим всё равно сообщить об этом нам"?
Вы не поняли сути вакансии. С Вас требовался опыт работы с ChatGPT :)
Вспомнилась недавняя история с Яндекс. К собеседованию порешал литкод, но не больше десятка, конечно - не яндексом единым, как говорится. Первый собес отлично. Второй из двух задач - первая отлично всё, вторая про разбор строки - для сложности n нужно было знать какой-то замысловатый метод, который кроме как на литкоде не встретишь. Я вот не встретил. Получил отказ на втором этапе - поначалу думал, что лицом (или возрастом) не вышел. Типа ошибки вроде как нужны, чтобы посмотреть как думает кандидат. А если по памяти решить - то не интересно. Но это не про Яндекс, конечно. Следующий рекрутер пояснила, что в Яндексе типа в сапера играешь, ошибся - всё. И я вот в очередной раз разочаровался в людях.
Параллельно была задачка второго этапа ВК - там не литкод, а "сложные вводные", интервьювер сам путался в своей же задаче. Решил, даже во время уложился, но чем-то всё равно не угодил, но так и не узнал чем.
Имхо, "общий трек" только с голодухи можно пройти. Долбиться в стописот задач. И задрачивать собесы. Обычно рекрутеры и интервьюверы сами не знают "под кого" ищут. Потому "ищут волшебника - находят сказочника".
Мне вот любопытно, есть ли "не голодные" специалисты, которые хотят на новом месте делать тоже самое, что и на старом? Имхо, всегда лезешь в новое, где что-то точно не знаешь.
Сеньор не может написать алгоритм бинарного поиска? Серьёзно?
Серьезно. Вытащи сеньера за ногу ночью из под завалов разобранного прода и ни черта он поиск не напишет без гугления. А вот прод обратно соберет и к утру поднимет. Тем и ценен. А не бинарным поиском на память.
А не бинарным поиском на память.
А зачем на память-то? Это только вкатыши заучивают наизусть реализации однострочных алгоритмов. В чём проблема реализовать алгоритм - "поделить пополам, выбрать право или оево, повторять ло сатисфакции"? Если некто жто не осиливает, то, вероятно, он неправильно выбрал профессию.
прод обратно соберет и к утру поднимет
А, и точно. Это sre или девопс.
Сеньор должен написать бинарный поиск с помощью всего инструментария, который есть (включая гугление). И БПФ. И Дейкстру. И прод поднять. Он ценен не тем, что поднимает проды (которые легли, почему-то) - а тем, что автономно способен решать задачи.
Мне понравился собес, но я забыл название и быстро найти не смог - дается задача и полный карт-бланш на гугление и нейронки. Если человек дубовый и ничего не знает - его никакой гугл не спасет.
как по мне так это лучший вид собеса.
Так как от кандидата не требуется знать все наизусть и стрессуя от того что он что то забыл. А для собесещующего видно как человек думает и что гуглит. Если кандидат гуглит "как создать папку на Макос" то это одно, а если гуглит что то "умнее" то уже взгляд на кандидата другой.
Причем подойдет как для Джуна так и для Сеньора
"Вместо тысячи слов создай нам прототип Х"
Не вытащит он никакой прод, скорее сам ушатает. Это не то что не сениор, это не программист впринципе. Чтобы написать бинарный поиск вообще ничего знать не нужно, его любой программист хоть немного умеющий думать просто используя здравый смысл напишет. Да, возможно с ошибками в пограничных условиях или переполнением, но напишет.
Это жизненные наблюдения, по себе в том числе. Когда темы не касаешься годами, то даже и не вспомнишь толком, что это. Гугл посмотришь - а, ну да, элементарно. Но вот помнить весь этот неиспользуемый в жизни мусор - как, а главное, зачем? По собеседованиям ходить? А если такой необходимости нет?
А что вам надо "помнить"? То что в остортированных данных можно найти быстрее чем полным перебором? Вы видимо бумажных книг вообще никогда не читали? Или вы нужную страницу в книге ищете пролистывая по очереди каждую?
Бумажные книги по программированию последний раз читал лет 20 назад, пока джуном был. Мидлы обычно уже понимают, что книги - источник информации неэффективный, тем более в наше время.
И сеньор в большинстве компаний пишет все меньше низкоуровнего кода. Это просто неэффективное расходование ресурсов компании. Чаще его работа в качестве клея между множеством компонентов команды и процессов. Потому и не помнит он ни черта из вопросов по литкоду, ему это просто не надо в повседневной работе. Отчего и страдает в реалиях современных собеседований.
Вот так с разбегу, если это такого рода задачи не повседневные - совершенно нормальное явление.
серьёзно.
сеньор заюзает готовую библиотеку, коих тыщщи на любой вкус, и которые работают быстрее.
Ну мне кажется что вы либо литкод заучиваете либо давненько BinSearch написать не пытались, либо вам повезло проскочить одно узкое место.
Там весьма коварные граничные условия, которые нужно либо помнить, либо копипастить либо есть шанс 50% (как встретить динозавра) просто написать неверно с первого раза, а потом 30 минут отлаживать (как раз до конца интервью с нерешённой задачей).
Либо он как и я просто умеет работать с граничными условиями.
Скромный, не забудьте про мою потрясающую скромность!
Извините, но если человек говорит "я не ошибаюсь в граничных условиях, а ещё пишу код быстро", - а вы говорити по сути это, то я ему не верю.
Помимо того, что это крайне сложный навык у меня есть и практические наблюдения.
Мы пару раз в своей команде компиляторщиков проводили эксперимент: white-boarding задачек из собеса (когда выяснялось "что-то собеседуемые задачки решают плохо").
Меньше 50% справлялось, основные ошибки - на граничных условиях.
П.С.
Сейчас я уже восстанавливаю по памяти (дисклеймер: порядка 20% воспоминаний ложные), но ЕМНИП модный нынче exhausting проблемой не был. А вот ошибки ан +/-1 - были.
Либо он как и я просто умеет работать с граничными условиями.
Либо просто думает что умеет. А потом прод в 3 часа ночи и падает.
Прод чаще падает не из-за кода поисков. Причины обычно такие, которые проверяющие и не способны на собеседованиях потестить, ибо это материи порядков повыше или правее.
Понятно что не из-за кода поисков. Но граничные условия - они не только в алгоритмах поисков. Поэтому когда кто-то помпезно заявляет "да я всё знаю и умею" - сеньйор этот скорее всего ненастоящий. А настоящий как раз наоборот очень серьёзно призадумается над любой несвойственной/подзабытой задачей, и с шашкой наголо "я всё знаю и умею" не попрёт.
в программировании две проблемы: инвалидация кэша, именование сущностей и ошибка на единицу
Скорее всего он не напишет функцию std::midpoint (которая возвращает что-то вроде (a+b)/2, но правильно для всех числовых типов) с первого раза, без которой не обойдётся такой алгоритм. Если я правильно помню, даже у разработчиков libc++ это получилось раза с пятого, а разработчик java.util.Arrays тоже написал правильный аналог не с первого раза.
На 64-битной архитектуре эта проблема не существует, потому что память закончится раньше чем случится переполнение.
В Java и C# отдельная история, потому что там индексы массивов 32х-битные даже на 64 разрядах. Но и там подобных больших массивов принято избегать из-за особенностей работы с GC.
О, нам как-то в универе рассказывали подобное. Чтобы избегать переполнения нужно считать примерно так:
b + (a - b) / 2
И получить a/2 ?) Логичнее (a/2 + b/2) уж тогда)
Этот вопрос максимум джуниор знает, потому что он это изучал на прошлой неделе. Синьор это изучал 5 лет назад и в реальной жизни не использует. Максимум он специально для собеседования повторил.
Я бы насторожился, если бы сеньор забыл что такое "передача по значению" и как устроены слайсы. Достаточно знать устройство языка на котором пишешь, чтобы отвечать на такие вопросы, не обязательно все запоминать
Вот у нас есть слайс в Go, мы передадим его в функцию, там вставим 3 элемента - что мы получим?
Синьор это изучал 5 лет назад и в реальной жизни не использует.
Там же в Go всего две базовых простых структуры данных по сути - слайс и map. И собеседующий таким вопросом вероятно пытался выйти на вопросы по алгоритмам и структурам данных. Я не понимаю в чём тут проблема проблема?
Ладно это в структурах C++ можно забыть как красно-чёрное дерево балансируется, но вставка в слайс (минимальную обёртку над массивом) это ведь совсем базовые знания.
На счет слайса полностью согласен. За 3 года никогда так не писал, но на счет как там мапа внутри устроена, не согласен. А вы знаете сколько прикольных моментов в ядре гошечки? Начиная от структуры blackhole и заканчивая магией при работе с фреймами функций =)
type pcHeader struct { magic uint32 // 0xFFFFFFF1
Да ерунду вы получите! Есть best practices. Если в функции модифицируете слайс - нужно возвращать новый слайс
Это не ответ сеньора. Правила и бездумное следование им это этап джуна. Мидл уже начинает подозревать, что из правил есть исключения. А сеньор уже видит, что исключений вокруг много. И у каждого есть веская причина. И надо пользоваться ими, а не бубнить мантру про "best practices". Сеньоры это те, кто составляет и публикует эти best practices для джунов.
Если исключений много, то это странно... Зачем тогда правила? Точнее, тогда исключения и правила меняются местами)
Правила затем, что благодаря им можно быстрым и безопасным образом задать малообученному индивиду достаточно верное направление движения, даже если он не понимает происходящего. Феномен хорошо описан тут.
"...Недавно я сходил на с десяток собеседований, и они меня очень сильно разочаровали...Максимум он специально для собеседования повторил..."
Очень странно, что человек проходил десяток собеседований и не обратил внимание, что требует текущий рынок труда. Тут сразу возникнут вопросы, а как он может "выяснить требования у бизнеса", если есть такие проблемы с коммуникацией? Уже если не после первого, так после второго собеса должен сформироваться список "что хочет рынок, что надо подтянуть".
"...И потом всё это реализовать на ЛЮБОМ языке программирования...Да, загуглит он, как создавать функции, классы и т.д. ..."
Штука в том, что "загуглит" - это как раз про джуна, тут работодатель не ожидает, что чел быстро войдёт в проект и обычно делает скидку на то что чел не сильно бьётся по техстеку. А вот сеньёр должен максимально быстро войти в проект и сразу писать высокопроизводительный качественный код на техстеке работодателя, а не гуглить "что такое бин в спринге". Исключение это обычно, когда работодатель понимает, что с рынка на свой экзотичный техстек никого не возьмёт.
"А ведь хорошая идея - попросить программиста написать бинарный поиск."
бинарный поиск это не КМП. А вот показать что ты не имея в памяти решения в общем то не самой сложной задачи можешь написать кодик - это большой плюс для соискателя.
"Но обычно бывает совершенно другая ситуация: приходишь на работу и слышишь: "Смотри, у нас тут есть табличка в БД, её надо вывести в CRM"."
А потом (реальный случай):
--У нас всё тормозит, нужен срочно ДБА. Х, сделай, чтонить, индекс там какой или типа того!
--Какой индекс, когда у вас тут все запросы вида "селект звёздочка фром табличка" и вся работа влючая фильтрацию на бэке?
С вашим высказыванием хочется как согласиться, так и опровергнуть :)
А вот сеньёр должен максимально быстро войти в проект и сразу писать высокопроизводительный качественный код на техстеке работодателя, а не гуглить "что такое бин в спринге".
В моем мировоззрении работодателю не нужен никакой высокопроизводительный качественный код от сеньора, а нужно стабильное решение бизнесовых проблем до финальной точки. А уж решается это через высокопроизводительный код или через подметание полов - это дело десятое. Джун не понимает бизнес контекста, мидл понимает ограниченный контекст, сеньор его сам способен не то что понять, но и вернуть бизнесу в улучшенном виде на согласование.
А перечисленные вами характеристики, как и вообще понятие код - нужны, но в рамках решения поставленных задач.
Как собеседовать таких людей, кроме разговора по душам и надежде на честность - мне неизвестно :) Потратить пару часов своего времени на рассказы зазубренных вещей или разговоры про сортировку - такое себе.
Но при этом хочется сказать, что во всех компаниях есть испытательный срок, и обман достаточно легко вскрывается, если компания не утонула в бюрократии и не выдает доступы 1 месяц из 3...
В моем мировоззрении работодателю не нужен никакой высокопроизводительный качественный код от сеньора, а нужно стабильное решение бизнесовых проблем до финальной точки. А уж решается это через высокопроизводительный код или через подметание полов - это дело десятое.
Если мы говорим не полуподвальной конторе, где разработчик это автомотовелофототелерадиомонтёр, то между ним и бизнесом есть: продакт, аналитик, тимлид в конце концов. И они на вход выдают ему ТЗ на разработку. Если этого нет и разработчик получает на вход "нарисуй мне кунгуру" или "придумай чтобы на складе было чисто", это лишь говорит о качестве процессов разработки в конкретной организации. Конечно, он может съездить в поля, чтобы посмотреть что там вообще происходит или рассказать свой опыт на тему бизнеса, это только плюс для него. Но это прежде всего РАЗРАБОТЧИК. И он должен в первую очередь качественно выполнять свою основную функцию. Если он классно "трещит" с бизнесом, но для того чтобы закодить задачу ему надо изучать азы техстека компании, то он не на своём месте как разработчик.
Вы рисуете очень узкого специалиста в своей области :) Такое проецирование имеет место быть, но не все сеньоры равны узким специалистам.
Тем более специалист такого уровня обычно ищется для решения сложных комплексных проблем. Если перед ним есть аналитик, продукт, тимлид и они ему выставляют точное тз - то тут возникает какое-то несоответствие. Потому что примерно здесь уже можно менять такого специалиста на мидла либо на чатгпт, ради чего вся эта цепочка и затевалась :) Но сейчас, кстати, на мой взгляд из-за усреднения зарплат в айти (то есть их роста как раз во всех смежных от разработчика должностях) смысл ее потерялся - ведь все эти люди работали ради экономии времени самого дорогого человека в команде - разработчика. А теперь они едят х3 от него, а выхлоп остался прежним.
Если он классно "трещит" с бизнесом, но для того чтобы закодить задачу ему надо изучать азы техстека компании, то он не на своём месте как разработчик.
Не понимаю почему вы решает проблемы бизнеса привели к "трещит". От того, что вы нагородите кучу крутого кода там, где можно вовсе обойтись без его - вы не становитесь супер профи. Точно так же, как невозможно писать для проекта с размытыми требованиями (а бизнес он именно такой) сразу написать идеальный код. Преждевременная оптимизация, ага.
"Но при этом хочется сказать, что во всех компаниях есть испытательный срок, и обман достаточно легко вскрывается,"
Не надо надеяться на испытательный срок. Вы как нанимающий менеджер пропускаете время на адаптацию этого чела. положим это месяц. Дальше вам нужно тратить своё время, чтобы доказать что чел некомпетентен - если контора белая, а чел "опытный" - тот ещё гемор. Ну и потом вам надо начинать подбор заново - это время. В общем с квартальным планом завязаным на эту ставку пролетаем. оно надо? :)
оно надо? :)
Оно не просто надо, оно - единственный выбор разумного человека. Просто потому что найм - черная коробка с неизвестным результатом. Я нанимаю не много, но вокруг видел все возможные способы от тестирования до разговора по душам. Выхлоп примерно одинаковый. А с человеком, который наврал или завысил свой уровень лучше расстаться - так оно честнее. Вам потом много лет работать бок о бок, и наплевать на квартальные ставки - надо работу делать :)
Не надо квартальные планы такие завязывать. Вначале усиль команду, только потом планы на плечи взваливай.
Как собеседовать таких людей, кроме разговора по душам и надежде на честность - мне неизвестно :) Потратить пару часов своего времени на рассказы зазубренных вещей или разговоры про сортировку - такое себе.
Вот да, я в итоге к такому же выводу пришёл. Пока работает)
Ага, чел максимально быстро войдет в проект и сразу начнет писать, не смотря по интернетам, высокопроизводительный качественный код...
А потом выйдет и придет другой чел, и будет выгребать из вашей кодовой базы, его уникальные высокопроизводительные реализации бинарного, быстрого и прочих поисков и деревьев, заменяя их та то что есть в стандартной библиотеке :)
Хватит спрашивать у синьоров джуниорские вопросы
Мой любимый тест на собесе. Есть словарь, у которого ключи и значения строки. Распечатайте его в консоль в виде строк "ключ = значение", каждый такой элемент на новой строке. Около 30% тех, кто приходит собеситься на синьора не справляется. Поэтому, извините, но я продолжу задавать джуниорские вопросы. Кстати, вопросы именно задают, а не спрашивают.
А ведь хорошая идея - попросить программиста написать бинарный поиск. Только вот загвоздка: он писал его последний раз 10 лет назад в универе, и за 10 лет работы он не пригодился ни разу.
Я вас уверяю, если вы устроитесь в мою компанию, вы будете писать код, который до этого не писали ни разу. В этом как-бы смысл работы программиста. Если вы не можете написать простой код, который до этого ни разу не писали, вы нам не подходите.
Я бы понял, если бы все эти вопросы задавали в компании, где разрабатывают компилятор или свою базу данных - тогда вопросов нет, тогда все эти тонкости работы сборщика мусора, алгоритмы и т.д. - нужны.
Абсолютно любую систему можно привести в малопригодное для использования состояние с тормозами, если не знать "все эти ненужные алгоритмы".
В смысле не справляются? А в чем подвох задачи?
Нет подвоха, просто не могут. Это самозванцы.
Можно в ключи и значения добавить переводы строк ]:->
Тоже не уловил, а в чём подвох первой задачи-то?
Я даже в песок пошёл и проверил, а в чём загвоздка-то? Самое примитивное решение даже работает, хотя под сеньором всё-таки часто подразумевают специализацию не в одном ЯП (помимо 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)
}
}Нет подвоха, просто не могут. Это самозванцы.
Самозванцы - это те, кто не способны своим трудом бизнесу денег заработать. Процесса найма это тем более касается, когда отсеивают толковых людей из-за самоудовлетворения путем показной археологии.
Да, 100% тех, кто не смог распечатать словарь, очень красиво и складно рассказывали, как они решают задачи бизнеса :)
Хм, минусов в карму насовали неуспешные кандидаты, которые узнали себя? ))))
Да соглашусь, именно не знание техники порождает ужас, а бизнес потом вынужден искать спецов на стороне и получать заключение о необходимости рефакторинга
"А что значит буква D в аббревиатуре SOLID? А в ACID?" Вы хоть раз в жизни за пределами собеседования этой информацией пользовались? Нет?
Ээээ, вы не знаете что такое dependency inversion и ни разу в жизни ею не пользовались? Вы на пхп программировали, что ли? Ой, стойте!.. ))
А ведь хорошая идея - попросить программиста написать бинарный поиск. Только вот загвоздка
Да, нет тут никакой загвоздки. Если программист не может реализовать "алгоритм", описываемый одной строчкой текста, то программист ли он? У меня на курсе училась девочка, которая пыталась вот так вот зазубрить матан. Она его пересдавала 11 раз. Но даже она догадалась, что зубрёжка - путь в никуда и проще понять принцип. Кому нужны "программисты", которые ничего не могут за пределами вызубренного? Сеньоры, говорите? Сеньоры-зубрилки?
Не работает так, что если до этого синьор работал 5 лет на Go, то завтра он не сможет написать проект на Java. Да, загуглит он, как создавать функции, классы и т.д.
Серьёзно? А вы точно программист? Сеньор, говорите?..
Вообще-то правильный ответ должен быть: зачем вам бинарный поиск? У вас сколько данных: если мало - последовательный перебор может оказаться быстрее. Как минимум нам не надо сортировать коллекцию перед тем как делать бинарный поиск. Далее что делать. Если у нас насколько одинаковых элементов в коллекции? Нам подойдёт первый или надо вернуть все? Если коллекция большая, то как вы будете делать поиск? Хорошо если влезет в память, а если раскидана по всему диску, или по нескольким дискам/дата центрам ?
Так что прежде чем писать надо бы понять что вам надо и зачем.
Я тут кстати перечитал Маркса, вернее Кнута: Искусство Программирования том 3. Сортировка и поиск: «Хотя идея бинарного поиска достаточно проста, детали его реализации нетривиальны и много неплохих программистов ошибались при первой попытке написать соответствующую программу.»
Вообще-то правильный ответ должен быть: зачем вам бинарный поиск?
Ну, мы не знаем в каком виде было сформулировано задание. Возможно, формулировка была исчерпывающей. ))
сколько данных: если мало - последовательный перебор может оказаться быстрее. Как минимум нам не надо сортировать коллекцию перед тем как делать бинарный поиск.
Необходимые вопросы на систем дизайн интервью. Лишние на секции лайв-кодинга. Впрочем, почему нет? Это впечатлит интервьюера.
Если у нас насколько одинаковых элементов в коллекции? Нам подойдёт первый или надо вернуть все?
А вот тут совершенно согласен - сбор требований, втч неявных - наше всё. Недавно обидно как раз на этом прокололся - посчитал, что собрал всё и необоснованно неверно предположил самое главное что необходимо было согласовать - определение термина цели задания... ((
Так что прежде чем писать надо бы понять что вам надо и зачем.
всё так, но в данном случае товарищ борется явно не за это ))
Получив от бизнеса задачу отсортировать "хитровывернутым" способом список из 20..30.. и тд записей, синьор первым делом спросит - " а как часто это надо делать?" и если ответ будет "надо 1 раз, сегодня", он это сделает руками в екселе, а не бросится писать тулзу с покрытием автотестами и упаковкой в докер и все освободившиеся время он потратит на холивары на хабре.
Тоже никогда не понимал, что даст к пониманию уровня сеньора если он напишет на доске реализацию бинарного поиска...
Ну разве что у него уже заканчивается финансовая подушка и за еду он уже готов на все))
К уровню сеньора ничего не даст. А, вот если не написал даже такой простой код, даст понять, что точно не сеньор :). По крайней мере, не сеньор в программировании. Может в чём-то другом...
А зачем сеньору писать даже такой простой код для вас? Вы наверное обещаете ему много денег? Много денег за способность написать бинарный поиск?)
много денег за способность писать код вообще. Любой. Далеко не все те, кто претендует на место сеньора таковыми являются и умеют это делать.
Ну, а если сеньор считает себя настолько важным, что ему впадлу писать простой код, я не хотел бы узнавать на практике кем он посчитает себя, когда возникнет необходимость писать реальный код. А вдруг он тоже окажется проще, чем внутренние установки такого важного господина?
А вы не можете определить сеньор перед вами или не сеньор без определения способен ли он по вашему щелчку пальцев написать бинарный поиск?)
Еще два нюанса. Вы ищите себе послушного исполнителя, готового писать все что вы от него потребуете, а ваш работодатель высокооплачиваемого опытного специалиста. Вы ищете человека который без разговоров будет затыкать все ваши дыры, а ваш работодатель уверен что вы грамотно построили процесс разработки ПО и умело управляете приданым вам ресурсом)
И последнее, кто с большей вероятностью вывернется перед вами на изнанку, опытный сеньор, который проходит несколько собеседований параллельно кроме вашего. Или опытный дрочитель литкода, который ни дня не работал над реальными проектами? Да возможно вы определите и срубите литкодера на архитектурной секции, но и сеньор у вас не пройдет дальше первой секции. Итого, вы потеряли время. И если вы не из Яндекса, то уже к вам у вашего работодателя могут возникнуть вопросы, верно?)
Почему написание простейшего алгоритма вы приравниваете к выворачиванию наизнанку?
А почему нет?
По моему если сеньора гоняют по джунским темам, вместо того что бы понять насколько он силен в вопросах относящихся к компетенции старших разработчиков - это или модное местами стресс-тестирование или показывает отсутствие компетенции собеседующего.
Работать в компании со стрессом как частью рабочего процесса или с плохим руководителем можно только в том случае, если срочно нужно трудоустроиться из-за личных проблем. То есть человек вынужден "лезет из кожи вон", что бы получить место. И это будет скорее всего временно, ну разве что нанятым не заменят собеседующего)
По моему если сеньора гоняют по джунским темам, вместо того что бы понять насколько он силен в вопросах относящихся к компетенции старших разработчиков - это или модное местами стресс-тестирование или показывает отсутствие компетенции собеседующего
Или же это всего лишь попытка отсеять самозванцев.
Если вы не можете отсеять самозванца на позицию старшего специалиста, вопросом из компетенции старшего специалиста, то самозванец вы)
И кстати, это займет гораздо меньше времени, особенно если вы додумались и потребовали писать алгоритмы на листе бумаги или доске)
Умение писать простой код, представьте себе, проверяется задачей на написание простого кода, а не теоретическими вопросами.
Это все равно что выдавать права на автомобиль только за теоретическую часть не проверяя вождение. Или все равно что давать диплом хирурга не проверяя как он оперирует.
По вашему выходит, что водители на права пересдают всякий раз при устройстве на новое место работы?
А хирургов со стажем наверное не берут в больницы, пока они не покажут как вскрывают чирей, а отоларингологов, пока они не продемонстрируют как промывают уши?
Вы кому вот это все про права и про хирургов тут пишите?)
Писать в том числе и совсем-совсем базовый код вида "положить в словарь значение" - это тоже входит в обязанности старшего специалиста.
А вы не можете определить сеньор перед вами или не сеньор без определения способен ли он по вашему щелчку пальцев написать
Без предъявленной способности писать код я не могу определить этой способности, внезапно, да. А языком чесать - не мешки ворочать код писать.
кто с большей вероятностью вывернется перед вами на изнанку,
А давно писать код для программиста стало чрезмерно сложной задачей, заставляющей аж выворачиваться наизнанку? Я как-то пропустил этот момент и до сих пор программироваю как лошара. Не, я-то не против, чтобы на собесе меня спросили, - ты сеньор? - сеньор, - на тебе 100500 денег и иды сеньорствуй (кстати, однажды, так и правда случилось). Но действительность куда печальнее. Какие только удивительные чудаки не называют себя сеньорами. Особенно среди тех, кто картинно обижается на просьбу написать простейший код.
но и сеньор у вас не пройдет дальше первой секции
Всё так. А зачем мне человек, называющийся сеньором, который не способен написать даже простейший код? У меня нет для такого работы. Подметать им двор слишком дорого.
Я вашему коллеге написал уже
Если вы не можете отсеять самозванца на позицию старшего специалиста, вопросом из компетенции старшего специалиста, то самозванец вы)
К вам это похоже тоже относится, если вы не можете понять сеньор перед вами или нет просто поговорив с ним о его прошлых проектах, какую роль он их играл, и как решал возникающие задачи. То вы не компетентны как старший специалист. Если вы им себя считаете и реально участвуете в собеседованиях, а не просто холиварите на эту тему в комментах)
К вам это похоже тоже относится, если вы не можете понять сеньор перед вами или нет просто поговорив с ним о его прошлых проектах
А зачем мне это, если есть куда более простой тест?
и как решал возникающие задачи
Абсолютно верно. Вживую наблюдаю как решал простейшую задачку по программированию от которой у остолопов подгорает, а бестолочей выворачивают наизнанку. Увлекательнейшее зрелище, скажу я вам! Рекомендую.
А зачем мне это, если есть куда более простой тест?
Ну и кого вы наймете при этом, сеньора или лайтсоде дрочера?)
Не боитесь, что ваш работодатель читает тут ваши комменты?)
А зачем мне это, если есть куда более простой тест?
Для кого простой? Для сишного байтоёба, по роду деятельности имплементирующего алгоритмы, чуть ли не в машинных кодах - несомненно простой, и несомненно правильный тест. Но для писателя микросервисов на жаве в финтехе, по роду деятельности не занимающегося низкоуровневой инфраструктурой - так себе. Нет, он конечно быстро разберётся когда надо будет. Но не в ситуации собеса. И что такой тест проверяет тоже непонятно.
Конечно, проверяйте как хотите. Но не вопите потом какой якобы дифицыт специалистов, и вы три года никого найти не можете. Просто ВЫ НЕ УМЕЕТЕ ИСКАТЬ!
Для кого простой?
Для того, кто хоть раз писал код сложнее хелловорлда.
И что такой тест проверяет тоже непонятно.
Умение писать простейший код.
не вопите потом какой якобы дифицыт специалистов
Специалистов дефицит. А перекладывателей джейсонов, да, навалом. Только кому ж они нужны?
Просто ВЫ НЕ УМЕЕТЕ ИСКАТЬ!
Перекладывателей джейсонов искать? Да, зачем - они сами на свет лезут мириадами. Но толку от них никакого.
Умение писать простейший код.
Ещё раз, для кого он простейший? Вы похоже не различаете умение кодировать и владение предметной областью. Более того - сами ею не владеете: вам уже напихали в панамку что бинарный поиск это далеко не такая тривиальная вещь как кажется любому зазнайке типа вас.
Специалистов дефицит.
Нет никакого дефицита специалистов. Просто чтобы найти специалиста, нужно самому быть специалистом. А вы таковым, похоже, не являетесь.
Ещё раз, для кого он простейший?
Для любого, кто умеет программировать.
Вы похоже не различаете умение кодировать и владение предметной областью.
Отчего же? Различаю. И именно поэтому никогда не возьму на должность программиста балбеса не умеющего программировать. А незнающего предметную область - возьму.
Более того - сами ею не владеете
Всё так и есть. Как раз устроился на новую работу и совершенно пока что не владею их предметной областью. Более того вам скажу, за 30+ лет в отрасли и 10+ компаний от крохотных до транснациональных корпораций пересечение по домену случилось лишь единожды. А так никого не интересовало, что я до этого не работал с биржами. Или в банках. Или не проектировал системы удалённого доступа. Или нефтедобычу. Или заказы завтраков в отелях. Или CRM-ки. Или системы телефонных голосований для телепрограмм. Или сетевые протоколы. Или маркетплейсы. Или музыку. Или доставку. И тд. По-моему, владение доменом при поступлении на работу интересует лишь 1с-ников, да нелегальных криптанов. Но эти области как раз мне неинтересны.
бинарный поиск это далеко не такая тривиальная вещь как кажется любому зазнайке типа вас.
Если балбесу кажется нетривиальной "программа", состоящая из одного цикла, двух присваиваний и одной проверки условия на три варианта, то мы с таким болваном точно не сработаемся :)
нужно самому быть специалистом. А вы таковым, похоже, не являетесь.
Абсолютно точно не являюсь специалистом по надуванию щёк. Моё дело маленькое - спроктировать, реализовать и запустить какую-нибудь систему, которой пользуются миллионы. Знаете как приятно, когда на собеседовании расскаживаешь про предыдущие проекты, а тебе говорят, - о, а мы этим пользуемся - какая классная штука! :) - а классная она потому, что я её спроектировал и в неё код писал. Причём куда более сложный, чем бинарный поиск.
А незнающего предметную область - возьму.
Ещё, раз, по слогам. Бинарный поиск - это и есть "предметная область". Студент её отлично помнит, потому что вчера лабу сдавал. Сишный байтоёб её отлично знает - это то над чем он каждый день работает. А вот фронтендер или писатель микросервисов, вот так вот сходу запросто может уже и не вспомнить "да там всё просто, дели на два и влево да вправо". Кандидаты тупят не потому что якобы "не умеют кодить", а потому что не помнят ЧТО ИМЕННО надо кодить.
Ну и вполне ожидаемо что нет мазохистов работать с таким психопатом. Если он на собесе во всей красе показывает свою сущность, то что в реальной-то работе будет? Вот все от него разбегаются, новых он найти тоже не может.
Бинарный поиск - это алгоритмы, а не предметная область.
Алгоритмы это и есть предметная область. Современный программист занимается бизнес-логикой, пользуясь готовой отлаженной инфраструктурой. А не самопальной имплементацией бинарных поисков, как 30 лет назад. Вы ещё заставьте всех самопально рендерить кнопочки. Диды терпели, нам велели!
После того что вы тут написали очень хочется узнать название какой-нибудь системы, которую вы спроктировали, реализовали, запустили, и которой пользуются миллионы.
Думаю коллеги поддержат эту мою просьбу к вам)
А вот фронтендер или писатель микросервисов, вот так вот сходу запросто может уже и не вспомнить
Всё верно. Именно поэтому этот тест так легко отсекает тех кто программирует от тех кто не может вспомнить как это делать.
потому что не помнят ЧТО ИМЕННО надо кодить.
Ну, да, а зачем мне работники, которые забыли как надо кодить? Что именно кодить у них написано в техзадании. А ещё рядом интервьюер сидит у которого что-нибудь спросить можно. Ну, если конечно, надутого сеньора не аж выворачивает от необходимости открыть рот и издать звук (тоже уже запросто забыл? Ох, бедняжка!). Любой, кто кодить умеет с заданием справится. Креме болванов, которых аж выворачивает от необходимости написать несколько строк простейшего кода. И, да, у нас именно такая работа - что-то кодить. Забыл как кодить - иди канавы копай. Ну, вот правда, что у вас такие работнички делают? Пыль молча протирают? Не, если надо нанять молчаливого протирателя пыли я ни в коем случае не стану проверять его навыки программирования. Я стану проверять его навыки протирания пыли (но лучше куплю робопылесос). Но нанимать "программиста", которой забыл как программируют циклы, условия и присваивания - это надо быть чрезмерно одарённым вундеркиндером. Или чтобы подложить свинью работодателю.
Абсолютно точно не являюсь специалистом по надуванию щёк.
И при этом пишите про то какой вы молодец, спроектировали систему в миллион пользователей, а тажке принижаете и обесцениваете людей, которые могут затупить при написании бинарного поиска. Всё это выглядит так, как будто вы пришли посамоутверждаться.
Не хотите таких людей нанимать - ваше право. Один только маленький момент, точнее два, на подумать:
Эти "недоспецы" по вашей версии имеют лычку сеньора и что самое главное получают сеньорскую зарплату по рынку. Как же так вышло, что такой умный программист как вы, умеет в бинарный поиск сотней способов, а на рынке ему платят столько же?
Вот такой вот сеньор "балбес" по вашей версии может задаться целью и 2 месяца поупарываться в алгоритмы, посмотреть курсы от яндекса, понабивать руку на литкоде и, вуаля, он щелкается таки задачки как семечки. Внезапно он стал топовым спецом. Нехилый такой буст за 2 месяца? Как будто бы сильно большой скачок за столь короткий промежуток времени в вашей системе оценки?
принижаете и обесцениваете людей, которые могут затупить при написании бинарного поиска.
принижаю тех "программистов", кого аж выворачивает от просьбы продемонстрировать простейшие навыки кодирования.
Эти "недоспецы" по вашей версии имеют лычку сеньора и что самое главное получают сеньорскую зарплату по рынку.
Это не мои проблемы, а проблемы компаний, которые их нанимали. Судя по тому, как мой оппонент жалуется, что его отсеивают на кодинге, нанимают не очень.
Как же так вышло, что такой умный программист как вы, умеет в бинарный поиск сотней способов
Я не умею в бинарный поиск сотней способов, я умею программировать. Гораздо более сложные программы, чем бинарный поиск, поэтому закодировать такую элементарщину у меня не вызывает "аж выворачивания" ))
а на рынке ему платят столько же?
А вы уверены в этом утверждении? :)
Вот такой вот сеньор "балбес" по вашей версии может задаться целью и 2 месяца поупарываться в алгоритмы, посмотреть курсы от яндекса, понабивать руку на литкоде и, вуаля, он щелкается таки задачки как семечки. Внезапно он стал топовым спецом.
Неа. От того, что он зазубрит решения несколько задач он не станет спецом. Он останется ровно тем же балбесом, способным только подставлять зазубрнные им решения в задачу. А если решения задачи среди зазубренных отсутствует, он точно так же откажется её решать и будет обвинять работодатея, что у него задачи "неправильные".
Нехилый такой буст за 2 месяца?
Так считают вкатыши с двухмесячных курсов.
Как будто бы сильно большой скачок за столь короткий промежуток времени в вашей системе оценки?
См выше - вообще никакой.
Давайте уж совсем по полочкам разложу.
Смотрите, человек претендует на сеньорскую позицию. Что есть сеньор? Сеньор - это вполне автономная и изрядно самостоятельная боевая единица. Способная решать не только заученные им зачем-то задачи, но и открытые.
Что ожидается от сеньора, получившего открытую задачу? Там чуть выше уже написали. Если обобщить - сеньор собирает функциональные и нефункциональные требования к задаче. По ссылке частично расписано. Если что-то в требованиях неясно - собирает уточняющую информацию, начиная с ближайших доступных лиц. Если ему кажется, что задача противоречит бизнес-интересам, архитектурным решениям, принятым практикам, производитеьности, безопасности, его опыту, ещё чему-то, он пытается переговорами со стейкхолдерами прийти к разумному консенсусу. Но так делает "сеньор нормального человека". Возвращаясь к данному примеру, например, вы давно забыли алгоритм бинарного поиска. Что делать? Разумно спросить постановщика задачи, а не напомнит ли многоуважаемый джинн, алгоритм? - конечно, напомнит, у нас же не алгоритмическая секция, а простой кодинг. - Я, если приходится на интервью лайвкодить не в IDE, постоянно спрашиваю у интервьюеров точные названия библиотечных методов и/или последовательность аргументов - никогда их не помню. Ещё ни разу не отказывали. Да, собственно, даже на алгоритмических сессиях часто можно с помощью нужных вопросов получить хорошие подсказки куда двигаться. Сеньор - это вообще процентов на 80 про умение задавать вопросы, а не про зазубривание чего-то там на память.
Однако, вернёмся к нашим баранам - что делает "сеньор курильщика"? О! Во-первых, он неправильно понимает постановку задачи (помните, у нас не алгоритмическая секция, как он почему-то себе вообразил). Во-вторых, вместо уточнения и сбора требований он отказывается работать над задачей (какой-то другой, своей, но он этого не знает, поскольку даже не попытался этого выяснить и никак не прореагировал на пятикратные уточняющие намёки вплоть до прямого текста). В третьих, обвиняет в собственной некомпетентности постановщика задачи и работодателя. Разумное поведение сеньора, не правда ли? Вам точно нужен такой сеньор?
И, вот, вам, вуаля, такой простейший тест абсолютно точно отфильтровал самозванца, не удовлетворяющего требованиям компании по этой позиции.
Нет, я прекрасно понимаю, что где-то могут существовать компании в которых чудаков, способных решать только ограниченный круг заранее зазубренных задач и не способных взаимодействовать с коллегами, называют "сеньорами", но, кажется, это лесть. :)
Ох, еще раз: человек, который завалил бинарный поиск на собесе может вполне себе работать в компании программистом и поддерживать критически важную инфраструктуру. Вы можете сколько угодно гейткипить, мол он там ненастоящий программист, т.к. в бинарный поиск не умеет, а мы тут вообще трушные разработчики, т.к. ракеты строим, но зп у вас одинаковая по рынку, а это определяющий фактор. Говорю, основываясь и на своем опыте(я много таких секций завалил) и на опыте друзей, да и в сети примеров навалом.
Нанимать вы можете как хотите, возможно есть корелляция, что среди тех кто прошел лайвкод будет меньше самозванцев. Но при этом говорить, что те, кто не прошел точно самозванцы - это абсолютно неправильно, если вы, конечно, понимаете, что такое корелляция. Именно поэтому большие компании и устраивают лайвкод секции, у них большой поток кандидатов, поэтому большая выборка, а корелляция начинает работать на больших числах. Помимо этого у них это конвеер - наняли тех, кто решил лайвкод, потом онбоардинг, обучение, потом испытательный срок, потом уволили 30%, тех кто не вывез. И для них это ок, потому что выхлоп всё равно есть.
И самая большая глупость натягивать корелляцияю на одного человек - "не решил, не сеньор", чем вы и занимаетесь. Всё равно что сказать, если подкинуть кубик, то выпадет число больше двух(всегда).
Ох, еще раз: человек, который завалил бинарный поиск на собесе может вполне себе работать в компании программистом и поддерживать критически важную инфраструктуру
Вы, возможно, не очень внимательно прочли мой комментарий, но дело ВООБЩЕ НЕ в бинарном поиске :).
программистом и поддерживать критически важную инфраструктуру
Поддержка критически важной инфраструктуры дело не программиста-сеньора. И вообще не программиста. Вы ещё скажите, что он принтеры у вас там успешно заправляет. Сеньор "тыжпрограммист". Детский сад какой-то.
но зп у вас одинаковая по рынку
Повторю ещё раз - во-первых, это проблемы того, кто его нанял, во-вторых, я сильно сомневаюсь в достоверности этого утверждения.
потом уволили 30%, тех кто не вывез.
Ну, а таких уволят 90%. Пограммист без умения писать программы, угу.
Повторю ещё раз - во-первых, это проблемы того, кто его нанял, во-вторых, я сильно сомневаюсь в достоверности этого утверждения.
Я вам уже приводил примеры себя и своих друзей, да и в комментариях вам тоже люди пишут. Ну ваша позиция понятна это всё одни вкатыши пишут, мы все только что с курсов пришли и у нас подгорает, что нас на работу не берут :)). А если всё-таки мы работаем, да еще сеньорскую зп получаем, так это потому что в компаниях одни некомпетентные идиоты сидят, которые не разбираются приносит сотрудник пользу или нет :).
Когда люди не хотят признавать факты, тут уже я не знаю что делать. Поэтому на этом заканчиваю дискуссию.
принижаю тех "программистов", кого аж выворачивает от просьбы продемонстрировать простейшие навыки кодирования.
Вам уже 100 раз сказали что кодирование это полдела. Важно ещё ЧТО кодировать. Важен контекст в котором вращается человек. Если человек вращается в теме БД, он конечно с полпинка напишет любой хитроделанный SQL запрос. Если нет - вот тут вопрос - действительно ли он в теме. Но вот задача бинарного поиска совершенно не его контекст. Он конечно решит если посидеть спокойно и разобраться. Но вряд ли в стрессовом формате собеса! И что вам мешает давать задачи из контекста будущей работы и опыта кандидата? Сразу станет понятно в теме ли он, И может ли кодировать.
Это не мои проблемы, а проблемы компаний, которые их нанимали.
У компаний нет проблем. Проблемы у вас. Есть endpoint - человек справлялся с работой. Есть проблема - ваш тест отсеивает 100% годного кандидата. Но вы упорно не желаете замечать ВАШУ проблему. Поэтому очевидный вопрос вы-то сами точно квалифицированный сеньйор?
Вам уже 100 раз сказали что кодирование это полдела. Важно ещё ЧТО кодировать.
Да, хоть что. Вы ж ничего не межете написать.
Если человек вращается в теме БД, он конечно с полпинка напишет любой хитроделанный SQL запрос
Вы не поверите, но если мне нужет sql прораммист, я ему, внезапно(!), предлагаю написать именно sql запрос.
Если нет - вот тут вопрос - действительно ли он в теме.
А если нужен не sql прграммист, то, ещё внезапнее(!), простейший код на том языке, которым он владеет. Если гражданин не осиливает даже такой малости, то он идёт "сеньорить" на поднятиях продов и заправках принтеров. Но брать его прграммистом совершенно незачем.
И что вам мешает давать задачи из контекста будущей работы и опыта кандидата?
А это и есть задача из контекста программиста - может вы не знали, но у программиста именно программирование является контекстом. У сеньора контекстов больше и, как я описал в предыдущем комменте, они тоже все провалены напрочь. Там же написано, что они были даже важнее умения закодировать эту задачу безошибочно. Но вы даже после подробного объяснения ничего не поняли. Никому не нужен апш зазубренный "контекст".
Сразу станет понятно в теме ли он, И может ли кодировать.
Именно это я и увидел. Не в теме программирования, кодировать не может. И ещё увидел, что он даже если выучит зачем-то наизусть этот код, то и на джуна не тянет по остальным требованиям к позиции.
Есть endpoint - человек справлялся с работой
Он только что показал, что нет и даже близко не рядом. Может он умеет "поднимать прод", но у нас этим девопсы занимаются. Может, он умеет заправлять принтеры, но у нас этим... блин, я не знаю кто этим занимается (facepalm). Но решать задачи на сеньорском уровне он явно не может.
Есть проблема - ваш тест отсеивает 100% годного кандидата
Неа. Кандидат, не продемонстрировавший умение действовать на сеньорском уровне - 100% негоден для этой позиции. Может для какой другой годен.
Поэтому очевидный вопрос вы-то сами точно квалифицированный сеньйор?
Вы так настойчиво пытаетесь перейти на личности и доказать, что у меня кривые ноги? Это слабая позиция. Подумайте почему. Но гандикап вам могу дать - да, у меня ноги кривые. А, вдобавок, ещё и нос с горбинкой.
Продолжая ссылаться на Кнута, у него там как минимум 3 реализации двоичного поиска. Вы в курсе чем они отличаются?
Вот делать мне нечего кроме как 3 разные реализации двоичного поиска зубрить, да ещё и по Кнуту (книжка-то у него основательная, да вот идея писать в машинных кодах и считать такты несколько устарела).
Реализация алгоритма определяется требованиями.
Вы в курсе чем они отличаются?
Полагаю, способами работы с дублями (мой экземпляр третьего тома - зелёненький - куда-то промотался с переездами). Но, как выше уже написали - я тоже не настолько вкатыш, чтобы зазубривать реализации. На миксе, ага. ))
Это тихой сапой ответ на https://habr.com/ru/articles/911920/ ? :)
О чем не надо спрашивать на собеседовании - знают многие. О чем надо - никто не знает
а чем лично вас эти вопросы напрягают? вам лень отвечать? или вы боитесь что на какой-то не сможете ответить? уже была похожая статья и мнение подобно моему не нравится широкой аудитории, но я считаю что такие вопросы нужны, это проверка на вшивость, опыт, природную внимательность и мотивацию (когда вам лень и не интересно, вы такие вещи не повторяете и делаете работу кое-как, ну сломалось, ну погуглил, ну работает опять, ну да, сидел 3 дня вместо одного запланированного, но это не моя ж проблема, а тим лида теперь). Раз подобные вопросы спрашивают десятилетиями, значит их использование коррелирует с результатом, Билл Гейтс говорил что нужно нанимать отличников, они всегда тоже нанимают отличников, хорошисты же готовы брать троечников и в конечном итоге это плохо для компании. А у меня вопрос к вам: как можно человека считать синьором если он то не помнит, в том не уверен, а с этим никогда не имел дела? Просто за то, что он давно работает? Так он 5 лет мог делать джуновскую работу. Систем дизайн не предлагать, сегодня по нему много информации и это самая простая для джуна тема, а глубоко его нет смысла спрашивать, только если вы не стафа ищете.
Просто я знаю случаи когда языкастые и находчивые плыли на простых вопросах, их брали, ведь они вроде мотивированные и находчивые, хоть по итогу не справились с вопросом, но потом дальше фигово работали, ведь определенные вещи надо просто выучить и познать, чтобы быстро делать работу, а у них не было желания и потом когда зп уже платят их учить и постигать еще меньше желания.
В общем я за то, чтобы со всех спрашивать строго, а потом уже выбирайте как хотите, но скорее всего лучше будет работать тот, кто знает всякие скучные мелочи и нюансы, а тот кто пальцы загибает и корону поправляет, вместо дачи ответа, будет проблемным
Раз подобные вопросы спрашивают десятилетиями, значит их использование коррелирует с результатом
Очевидная логическая ошибка
А у меня вопрос к вам: как можно человека считать синьором если он то не помнит, в том не уверен, а с этим никогда не имел дела?
Просто я знаю случаи когда языкастые и находчивые плыли на простых вопросах, их брали, ведь они вроде мотивированные и находчивые, хоть по итогу не справились с вопросом, но потом дальше фигово работали, ведь определенные вещи надо просто выучить и познать
То же самое: из первого не следует второго
В общем я за то, чтобы со всех спрашивать строго, а потом уже выбирайте как хотите, но скорее всего лучше будет работать тот, кто знает всякие скучные мелочи и нюансы, а тот кто пальцы загибает и корону поправляет, вместо дачи ответа, будет проблемным
Если верить The Programmers stone, есть два общих подхода к решению задачи. Через использование существующих в голове знаний (человек-словарик) и через поиск новых. Одно не исключает другого, но на синтетических примерах проще понять, в чём разница.
Опыт для первого (packer) выливается в увеличенный размер словарика. Он быстро решает задачи, которые уже решал, но сильно тупит и не справляется с чем-то новым. Он знает много нюансов известных ему вещей, но даже простая смена языка или среды разработки - для него боль. Проверить, хороший ли packer ваш разработчик - просто. Спросите что-то из базы или попросите написать простенькую задачку вручную. Откажется или полезет в инет? Гоните в шею, он самозванец!
Опыт для второго подхода (mapper) выливается в повышенную скорость обучения. Он не так быстро решает типовые задачи, но способен разбираться с чем-то новым и сложным на регулярной основе. Он не знает или сознательно избегает нюансов, но в любой среде разработки или языке - он быстро поймёт, что к чему. Проверить, хороший ли mapper ваш разработчик - просто. Спросите что-то из базы или попросите написать простенькую задачку. Откажется или полезет в инет? Значит это он и есть) Берегите его.
Я тут недавно водителя нанимал, попросил его припарковаться у тротуара. Так он мне заявил, что автошколу 20 лет назад закончил, вот эти вот вопросы для новичков его напрягают, а по работе он обычно паркуется в подземном гараже и не обязан заучивать этот бред про параллельную парковку. Закончил он тем, что он профессионал и решает задачи клиента, а если мне нужен студент, который будет уметь парковаться у тротуара, так и следовало в вакансии писать. После чего он обиделся и ушёл.
Как-то год проводил собеседования, искали человека, знающего внутрянку операционок, кэширования, многопоточности, вот этого всего. За год и сотню собесов нашли двух (!!). Один отказался по вилке, другой - чел 18 лет, до сих пор работает, насколько знаю. А остальные да, либо готовые либы умеют, либо низкий уровень знают, но микроконтроллеры, а не ОС
Снова вопли о поломанном найме. Снова кому-то прищемили ЧСВ на собеседовании.
Я работаю программистом последние 11 лет. Недавно я сходил на с десяток собеседований.
При таком стаже толковый инженер не ищет работу. Она сама его находит. По сарафанному радио. По аккаунту на гитхабе и линкеде. По заслугам прошлых лет.
Очень самонадеянное утверждение.
В аккаунт на гитхаб может заглянуть кто-то из будущих коллег на последнем этапа собеседований, но и то не факт. Тем более что у многих его просто нет или там лежит что-то протухшее со студенческих времен) Никак не помогает на первом этапе, а на последнем (ваш ранний говнокод) может даже навредить.
Сарафанное радио в больших городах работает плохо, люди соседей своих не знают как зовут. А после ковида и всеобщей удаленки, оно, сарафанное радио, совсем сломалось.
Вы перечислили устранимые проблемы. Было бы желание.
То, что вас не хантят бывшие коллеги и работодатели говорит только о том, что вы не представляете особого интереса. Извините.
Также как и здороваться с соседями вам тоже никто не запрещает)
То, что вас не хантят бывшие коллеги и работодатели говорит только о том, что вы не представляете особого интереса. Извините.
Бывшие мои коллеги и работодатели живут в другом городе, и не думаю что я их сильно утомил, если они по первой просьбе дали отличную рекомендацию на новое место работы. Более того я поддерживаю с ними отношения (встречаюсь, если приезжаю) и всегда рад помочь им советом или делом. Так что извиняю)
Кстати это ваш репозиторий на гитхабе?)
Нет.
Мой github. Лет 10 назад завел. Но в 22-м переехал на гитлаб: 1, 2, и пара десятков других опен сорс репозиториев.
Уместно будет упомянуть и ТГ канал. В последнее время реклама такового считается вульгарным тоном, - но это все равно рабочий инструмент нетворкинга.
P.S. Если вы со студенческих времен не удосужились привести свои гитхабы, линкеды и прочие визитки привести в порядок, - то это же ваше решение. Бегайте по собесам и плачьтесь на глупые вопросы HR-ов и отсутствие красных ковровых дорожек.
P.P.S. Удаленка никак не препятствует нетворкингу. Даже наоборот.
Наши гитхабы более-менее, и даже линкедиты есть)
То что у вас в репе что-то есть это хорошо, но таких как вы единицы процентов, а советы вы даете всем.
И с советом про сарафаное радио тоже самое, какой мне толк что у меня есть друзья/знакомые, которые работаю в ИБ, иградельнях, и зовут к себе? У меня совсем другой прикладной домен, да и тех.стек у них совсем другой. А одного товарища, у кого что-то похожее, надо ездить в офис каждый день по 2 часа туда и обратно.
Так что не стоит натягивать на других свой случай, и еще таким поучительным тоном)
Смотрите.
Автора отсобесили, повозив лицом по мат части. Его потаскали туда-сюда на десяти собесах как юного джуна. Снова и снова. Он не провел анализ причин неудач, не предпринял попыток подтянуть матчасть. В статье он не предлагает ни единого решения проблемы. Ни теоретического, ни проверенного на практике. Он просто вопит, требуя у вселенной правильных вопросов на собесах.
Взрослый человек на проблему так не реагирует.
В комментариях я предложил один из немногих вариантов решения проблемы - это сводить потребность в собесах как таковых к нулю. Сеньору это под силу.
Если вас этот способ не устраивает, или он вам не подходит, или он не работает в вашем случае, - спасибо, что поделились своим мнением.
То, что вы в моих комментариях увидели поучения, что они обидели вас настолько, что вы побежали рыскать по гитхабу в поисках моего аккаунта - ну извините. Не знал, что вы ранимый. Надеюсь, вам стало легче, дизлайкнув мне комментарии и карму.
Если сеньор или лид не знает некоторых нюансов это может приводить к проблемам
Хорошая критикующая статья. Жалко, что взамен ничего не предлагает
ИТ вдруг узнали как реальная жизнь работает? Какой ужас. Все собесы всегда были дичной дичью. Причём по обеим сторонам баррикад. Это не только в ИТ, это везде. И чем глубже хрюши залезли в ширинку директората тем более дичная дичь творится на этих самых собесах. Да и не хрюшами едиными, Есть куча ситуаций когда техи которые собесят не хотят себе более умного "подчинённого", который за пол года может заместить этого самого начальника. Отсюда и вылазят эти странные вопросы про ретраградные меркурии у ХРов, про расшифровку аббревиатур от техов и прочее и так далее.
Давайте честно - програмерам с их зарплатами пережить отказ чуть попроще, есть куда упасть по ЗП если будет совсем всё плохо с работой, чем скажем какому то офиснику, у которого этой самой ЗП впритык хватает на месяц и двигаться вниз ему уже некуда. Хватит ныть про несправедливость мира и как он испортился. он всегда таким был, просто за тыквеным рафом и берёзовым фрешем его не так видно.
Если вы этого не знаете и не помните, то как других научите? Быть сеньором среди сеньоров очень легкая задача и под силу даже джуну.
Спорно) вроде и да, потому что сам устал на собесах отвечать про типы данных в моём языке. Но и нет, потому что не знаю, как в Go обстоят дела с вопросами
вроде "как работает map в Go под капотом"
а вот в JS стоит знать, как работает map, в чём его ограничения и в каких случаях предпочтительнее собрать новый массив через for, чем получить его на месте через map. И именно такие тонкости сеньор должен знать в числе прочих
Ну и первое, что приходит на ум, после прочтения окончания статьи - чувак впервые за много лет сходил на собес, не справился с базовыми вопросами, порвался и побежал на хабр. Так бывает, это нормально, и да, чтобы проходить собесы - нужно действительно проходить собесы, это тоже скилл. Я ещё на втором году работы понял, что первые несколько собеседований после их длительного отсутствия с шансом около 90% окажутся факапом. И, повторюсь, это нормально, вы ни в коем случае не становитесь от этого плохим специалистом, просто нужно подготовиться
На один и тот же вопрос джуниор и сеньер отвечают по разному.
Джуниор может вызубрить солид на википедии, а сеньер тебе расскажет примеры из практики этих букв, в том числе и примеры, когда следовало избегать слепого следования какой-либо буквы солида, и когда та же буква D в итоге незнамо как переусложнила код и поддержку из-за обилия интерфейсов, а подмены реализации этих интерфейсов в приложении так и не случилось ни разу.
Джуниор тебе напишет алгоритм бинарного поиска, а у сеньера есть пару случаев из практики, когда люди писали этот бинарный поиск, и его поддержка и последующее устранение заняло несколько недель возни с легасней, потому что изначально не использовали более подходящие для этого инструменты.
Джуниор расскажет про базовую авторизацию фреймворка, потому что недавно читал доку и знания освежил. Сеньер расскажет про опыт использования различных подходов к авторизации на этом фреймворке и расскажет про бандлы, которые лучше стороной обходить, если не хотите столкнуться с теми то и теми то проблемами.
В целом, когда я задаю подобные теоретические вопросы на собеседовании, всегда стараюсь по первичному ответу понять погруженность в конкретную тему, и копать дальше, если есть куда. Только так можно раскрыть опыт человека. И не ответ на некоторые вопросы не означает, что человек провалил собеседование, потому что оно состоит из нескольких теоретических частей, по которым ты в целом можешь понимать, на какой проект и роль можно определить человека, и какой у него технический кругозор, абмиции и т.д.
Да, есть некоторые очень душные вопросы и задачки, по которым пытаются понять, сможет ли человек сделать хоть что-то. Но в целом, вам задают эти вопросы, потому что на общих терминах в индустрии происходит общение внутри команды. И даже если вы сами пересобрали все паттерны проектирования и сами досмыслили базовые архитектурные принципы, вы будете очень долго доносить идею до команды. И в команде вам скорее всего ответят, что "да ты же предлагаешь такую-то аббревиатуру". Быстрая синхронизация с командой и общение на одном языке на самом деле нередко перевешивают харды человека.
буква D в итоге незнамо как переусложнила код и поддержку из-за обилия интерфейсов, а подмены реализации этих интерфейсов в приложении так и не случилось ни разу.
1) Каким образом закрытие класса интерфейсом усложняет код? Любая IDE дает возможность перейти к реализации в один клик, при отладке тоже наличие интерфейса никак не мешает. То есть вся проблема в том что рядом с классом появляется один лишний файлик с интерфейсом?
2) Интерфейсы нужны даже не столько для того чтобы реализацию можно было безболезненно заменить, а больше для того чтобы зависимости мокать в автотестах.
1) Помимо создания файлика (а в некоторых языках интерфейс не располагается в отдельном файле) есть еще регистрация этого интерфейса. Не все языки и контейнеры зависимостей поддерживают автовайринг. И часто изменения класса будет требовать изменения интерфейса, либо наоборот. За этим нужно постоянно следить. А если еще нет нормального компилятора или статического анализатора - пиши пропало и имей множество дебага, из-за того, что кто-то что-то не дописал или описал не так.
2) У интерфейсов есть преимущества и их пользу я не отрицал. Но далеко не все проекты требуют обмазывания интерфейсами со всех сторон по разным причинам. Есть mvp, есть ограничения языка и используемых библиотек, есть недостаток времени и давление со стороны менеджмента, есть внутрикомандные регламенты и т.д. и т.п.
Сеньер как раз побывал в разных ситуациях и не видит только черного и белого от использования того или иного подхода, и может сконфигурировать код в зависимости от внешних факторов для оптимальной доставки функционала, по пути решив, насколько его код будет углублен в академичную сторону.
Эм, ну так не честно, я думал мы говорим в контексте обычного среднего\крупного проекта, который разрабатывается и поддерживается группой разработчиков при помощи подходящих для этого инструментов.
А вы приводите какие-то частные случаи, когда объективные причины не позволяют или вообще убирают необходимость следовать принципам SOLID (или каким-либо другим).
Я-то не согласился исключительно с тем что DIP как-то переусложняет код в контексте какого-то усредненного проекта.
У всех свой усредненный проект. У кого-то говнокод приносит немалые суммы и кормит большие команды разработки десятилетями, у кого-то даже первого пользователя за два года разработки нет, а код продолжает вылизываться сжигая деньги инвесторов.
Эти два примера я привел из реальных проектов над которыми работал.
Лично мое мнение, что dip хорош только когда архитектурно продуманы точки роста проекта. И это обычно не любой класс под интерфейсом, а те части, которые действительно могут замениться на другие реализации или адаптеры. Совсем избегать интерфейсов не советую никому, но и доводить до того, что каждая дто может в себя имплементировать под пяток интерфейсов тоже не стоит.
Эти два примера я привел из реальных проектов над которыми работал.
И что эти примеры иллюстрируют? Что финансовый успех проекта напрямую не связан с архитектурной чистотой кода? Ну так это не новость, и что теперь, исключительно в процедурном стиле будем писать?
К слову, я так же могу привести в пример проекты, которые не дошли до точки окупаемости, потому что у них вместо кодовой базы был кусок лапши, который невозможно было ни масштабировать, ни даже банально поддерживать.
доводить до того, что каждая дто может в себя имплементировать под пяток интерфейсов тоже не стоит
1) Интерфейсы на DTO к DIP вообще никакого отношения не имеют. DIP (как следует из названия) про зависимости. DTO зависимостями не являются.
2) Если на DTO настолько много интерфейсов, что это усложняет понимание логики, значит есть какие-то проблемы в дизайне. Принципы проектирования в комплексе, как раз таки, учат как этого избегать.
Так если полностью соблюдать инверсию зависимостей, то весь граничный контекст должен общаться посредством интерфейсов, а не реализации. И мы не можем передавать эту реализацию напрямую. Тут и получается, что dto имплементирует интерфейс если мы хотим передать его соблюдая dip. И на выходе получаем интерфейс, который имплементирует уже другая часть граничного контекста, что чаще всего является тем же dto.
Рационально ли это? Далеко не всегда. По солидному? Да. Усложняет код и поддержку? В разы.
Так нет же, DIP никоим образом не утверждает что DTO должны обязательно прятаться за интерфейсами. В этом абсолютно никакого смысла нет.
Под "реализацией" обычно понимается какая-то бизнес-логика. В DTO бизнес логики не должно быть. Это просто контракт, который определяет какую именно структуру данных ждет принимающий его метод.
Вот пример:
class Service
{
private IRepository _repository;
public Service(IRepository repository)
=> _repository = repository;
public void DoSomething(DoSomethingDto dto)
{
}
}
class DoSomethingDto
{
public string Text { get; set; }
}Если мы вместо конкретной реализации Repository передаем его интерфейс IRepository в Service, то это добро и это по DIP -- мы так понижаем связанность кода, можем безопасно подменить реализацию при необходимости, можем подсунуть мок под видом IRepository и покрыть тестами наш сервис.
Если мы спрячем DoSomething за интерфейсом, то это никакой практической пользы не принесет и к DIP никакого отношения это не имеет.
У вас какое-то странное толкование dip. Там как раз и говорится про любую зависимость, а вы абстрагировали этот принцип только бизнес-логикой.
На практике мы можем извлечь выгоду от общения через интерфейсы вместо самих dto довольно просто. Потому что расположение dto может быть внутри модуля, и тогда при смене структуры или переносе этого dto в другой неймспейс нам придется адаптировать другие модули под новые реалии. Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет, т.к. они будут общаться через интерфейсы промежуточного слоя, и перенос реализации интерфейса в одном модуле никак не повлияет на другой модуль, использующий промежуточный контракт. Но тогда мы подпишемся на поддержку этого промежуточного слоя. На больших проектах помогает.
А если вы интерфейсы в другой неймспейс перенесете, то тоже все сломается. Я не вижу принципиальной разницы переносить DTOшки или интерфейсы.
Ну и есть мнение, что DTO, используемые снаружи, не должны лежать в глубине неймспейсов, а должны торчать на верхнем уровне.
Да, изменение промежуточного слоя контрактов потребует поддержки. Но иногда он дает выгоду, потому что бывает частая смена структуры дто, внутренние рефакторинги модулей и так далее. Если мы внутри отрефакторим модуль и поддержим контракты, другие модули ничего и не заметят. Если мы отрефакторим дто, другим модулям уже будет посложнее. Целесообразность использования зависит от многих вещей и в большинстве случаев избыточна, согласен.
DTO подразумевает, что логики и поведения в них нет. Поэтому я не очень понимаю, как можно отрефакторить DTO не зацепив интерфейс.
Перенести, переименовать, свойство со снейк-кейса на кемел по внутреннему регламенту отформатировать и т.д.
На самом деле, в ходе бурной работы над проектом могут быть самые непредсказуемые изменения, в том числе не всегда чистые и честные
Все равно мне кажется, что тут интерфейсы нафиг не нужны и добавляют ненужный слой абстракции. Если под капотом переименовывать поля, а в интерфейсе не трогать, то это все выльется спустя время в то, что вообще не будет нормального соответствия.
Ну и опять же, переименование поля в рамках одного проекта это вообще не проблема. Если это подключается как либа, то это тоже не проблема, потому что компилятор все это покажет и не даст скомпилить.
У вас какое-то странное толкование dip.
Ну не знаю даже что тут сказать. Это хрестоматийное толкование с хрестоматийным примером.
Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет
Почему тогда просто сам контракт в отдельный модуль не вынести?
Любая IDE дает возможность перейти к реализации в один клик, при отладке тоже наличие интерфейса никак не мешает. То есть вся проблема в том что рядом с классом появляется один лишний файлик с интерфейсом?
Нет, проблема — это когда 90% кода состоит из таких файликов, а переход к реализации требует 10 кликов. Я такое встречаю регулярно, и обычно авторы этих извращений обосновывают их SOLID‑ом и «Чистым кодом».
На практике чаще вижу обратную ситуацию -- когда разработчик утверждает что он пишет простой и читаемый код, а оказывается, что вся логика в одном классе на 10к+ строк. И что исправление бага в одном месте, ломает что-то в другом месте, а тестов нет и написать в текущем виде их невозможно, потому что логика гвоздями прибита к БД или внешним ресурсам. Зато весь код в одном месте и без лишних файликов ¯\_(ツ)_/¯.
Не, я не спорю, что оверинжениринг как явление существует, и что это тоже плохо. Короче, мы так скатимся в банальщину вроде того что код надо писать хорошо, а плохо писать не надо, что инструменты и принципы надо использовать по назначению и без фанатизма.
Ну в целом со всем согласен, разве что бинарный поиск (и ему подобные) может быть уместен чисто как защита от дурака - тут не столько про алгоритмы, сколько проверить что человек вообще видел язык по которому собеседуется (хотя на сеньорском уровне это, вроде как, должно подразумеваться со старта).
Из вопросов такого плана у меня есть один очень хороший, по моему мнению, пример. Мне его впервые задали на техсобесе на сишника в московский Samsung, и хоть в Samsung я в итоге не пошёл (а пошёл в SK hynix), этот вопрос мне хорошо запомнился и я сам не раз его использовал.
Звучит примерно так: написать функцию/макрос, которая в рантайме проверяет порядок байт (endianness) на машине на которой этот код выполняется. Под спойлером (на случай если кто-то захочет проверить себя) - пара возможных решений (верхнее дал я сам):
Скрытый текст
bool isLE()
{
uint16_t u16 = 1;
uint8_t* u8 = (uint8_t*)&u16;
return (u8[0] == 1);
}
bool isLE()
{
union {
uint16_t u16;
uint8_t u8[2];
} u;
u.u16 = 1;
return (u.u8[0] == 1);
}Почему я считаю это вопрос хорошим? Потому что по ответу, вмещающемуся буквально в 3-4 строчки (или даже в одну), можно вполне себе адекватно оценить насколько кандидат понимает что-то в С. И дело здесь не в решении конкретной проблемы, "практичность" которой можно оспорить (хотя лично мне оно не раз пригождалось), а в понимании как оно вообще всё устроено в этой жизни.
Гм, а ведь если я правильно помню, то запись в юнион в одно поле с последующим чтением из другого это UB
Это UB на плюсах, но на числом Си это совершенно корректный код.
Как отметил комментатор выше - в С++ это UB без исключений, но реализовано и работает в самых распространённых компиляторах.
В С - по идее могут быть приколы, если написать так:
union {
uint16_t u16;
uint8_t u8;
} u;
u.u8 = 1;
return u.u16 == 1; // байты u16 не влезающие в u8 - не определеныНо даже в этом случае - они называют это "unspecified", а не "undefined", а это, насколько я понимаю, немного разные вещи.
Ну и справедливости ради, до вашего комментария, о том что тут в принципе где-то может UB до я и знать не знал :) Получается, что из этого вопрос можно вытянуть ещё больше, чем я думал.
Первый вариант почти что UB, из-за TBAA. Спасает только, что uint8_t разрешено алиаситься с любыми типами.
Если бы каст был бы хотя бы между int16_t и int32_t (или например между флоатом и интом), то этот код был бы UB. И емнип, крайние версии кланга стали эксплуатировать это уб в подобном коде.
Знали ли Вы это или нет — хороший вопрос.
Чтобы правильно делать reinterpret, нужно делать memcpy в буфер и обратно в другой тип.
Почти - не считается :)
Но да, с подобным я, непосредственно, сталкивался на практике, когда на каком-то маленьком АRMе (к сожалению уже точно не помню, что конкретно там был за чип) каст байтового указателя, с адресом не кратным размеру слова, к указателю большего типа, с поледущим чтением из последнего, приводил к тому, что результат читался не из исходного адреса, а из ближайшего кратного. Иными словами:
uint8_t b[8] = { 0x01, 0x00, ... }; // допустим, b указывает на 0x00000000
uint8_t* pb = b + 1; // pb указывает на 0x00000001
uint32_t* pu = (uint32_t*)pb; // pu всё ещё указывает на 0x00000001
uint32_t u = *pu; // ожидаем, что u == 0, но u == 1Конкретно тот код изначально затачиваля под 32-битную Винду и MSVC, и корретно работал после портирования на десктопный Linux/GCC. А вот при портировании на этот АRМ, понадобилось проверять выравнивания исходных адресов (в местах, где мы не знаем этого изначально), и при необходимости, как Вы и сказали - кастить через буфер.
Поэтому да, всегда надо понимать что и к чему кастится, и особенно, если меньший тип к большему. В обратную сторону - чуть сложнее, но тоже можно нарваться на неприятности (если, конечно, делать это не специально).
и за 10 лет работы он не пригодился ни разу
И это плохо
По поводу бинарного поиска - меня ночью разбуди и попроси его написать - напишу. Не потому что я его на работе по 5 раз на дню реализую, а потому что помню в чём смысл, да и вообще в реальной жизни (не на работе) очень часто использую. А так конечно да, можно забыть и само определение, если хочется проверить, как шевелятся мозги - надо давать неизвестные задачи
Бесячие простые вопросы на собеседовании. Но надо же с чего-то начать разговор. Посмотреть, как человек рассуждает. На каком уровне можно продолжать. Будет ли вам вместе комфортно работать. Простой вопрос это подача, а если вас это бесит, наверное, да, собеседующий не смог построить диалог.
Мы не ракеты строим
Как будто ракеты делают какие-то другие люди. Сейчас бы обсудить на интервью, сколько платят за ракеты и как собрать Кассам в гараже =)
На мой взгляд, не надо отбиваться такими фразами, хотя я и понимаю ваши чувства. Сама один раз спросила иррелевантную фигню на собеседовании, ожидая, что нас всех одинаково учили, чувак сильно смутился и мне было стыдно. Больше не спрашивала.
Спорная статья. ACID - не джуны придумали, а лютые эксперты по СУБД. Там каждая буковка критична, совсем это не джуновская сфера знаний. С серьёром, который не знает как под капотом работают map/set и т.п. в каком-то языке, на котором он собрался что-то писать я бы рядом тоже ср*ть не садился, это не сеньёр, а быдла какая-то тяп-ляп и в продакшон.
Статья в целом выглядит так, как будто какой-то чел дослужился до сеньёра непонятно каким образом, по знакомству наверное или по софт-скиллам, а когда столкнулся с вопросами сел в лужу и обиделся, пожалейте меня, я же синьор.
Не, так не работает. Давили и будем давить таких самозванцев. Серьёр - это не армейские погоны, но и те слетают.
Воспользуюсь случаем узнать что-то новое - какие сеньорские вопросы должны задавать на собесе по Go? Я только знаю, что на нем twitch написан.
Про бинарный поиск на самом деле хороший вопрос. Банальный, но хороший.
Джун первым делом отсортирует массив, тем самым сделает трудоёмкость O(N log N), что в log N раз трудоёмче линейного поиска.
Сеньор же сперва уточнит, как гарантируется, что массив отсортирован, что делать, если в массиве есть одинаковые элементы, ищем ли мы по значению элемента или по значению поля и т.д. А уже потом с закрытыми глазами напишет на любом известном человечеству языке, хоть на Malbolge.
В целом согласен. Пока не появится реальная необходимость в качестве софта, найм не изменится в сторону проверки реально необходимых навыков.
-Что должен знать джун?
-Джун должен знать все!
-Что должен знать мидл?
-Мидл должен знать почти то же самое что джун и сеньер
-Что же должен знать сеньер?
-Сеньер должен знать в какой книжке написано то, что должен знать джун.
-А что же должен знать тимлид?
-Тимлид должен знать где лежит та книжка, в которой написано что все они должны знать
-Директор, что должен знать директор?
-Директор должен знать где тимлид :-)
PS. В оригинале джун = студент
мидл = аспирант
сеньер = доцент
тимлид = профессор
директор = декан
Хватит спрашивать у синьоров джуниорские вопросы на собеседованиях