Поделюсь своими мыслями о том, как проходят интервью и что на них обсуждается. Подчеркну, что я буду рассуждать в проекции веб‑разработки, но, вероятно, это можно применить на любую область.
Оговорюсь сразу — у меня нет огромного опыта прохождения интервью: всего довелось присутствовать на 7–10. К этому добавляются интервью знакомых, которыми они поделились, а также те, что лежат на просторах интернета (например, на YouTube).
Типы вопросов
Я предпочитаю делить вопросы на некоторые категории.
Теоретические вопросы
Обычные вопросы по теории, на которые надо дать определенный ответ или точно описать технологию или подход. Так проверяются знание и понимание основных концепций и принципов разработки, и всё это обычно можно погуглить или прочесть в Википедии.
Это может быть:
Что такое ООП?
Что такое паттерн MVC?
Что такое event loop?
Что такое http?
Что такое атака типа XSS?
Что такое DOM/BOM/Telebom загорелся кошкин дом?
Задачки-забиячки
Задачи с подковырками на знание специфического поведения языка или библиотеки. Встречаются вопросы о том, как использовать определенные функции, методы или конструкции языка. Как правило, 95%-99% из того, что будет представлено кандидату, он никогда не увидит в продакшн коде. А самое бесячее — это когда на экране происходит миллиард всего, и где‑то на какой‑то строчке хитро спрятана ловушка (неправильный синтаксис или внезапная операция над переменной). Эдакие задачки на внимательность.
Это может быть:
Что выведет console.log() в N ситуации?
Что будет содержать переменная в данном случае?
Будет ли здесь ошибка?
Промис с цепочкой в 100 вызовов then, catch, finally, что будет в последнем then.
Адский экспрешен, который в жизни не встретить, по типу ('aboba' ==!typeof '123'!= 123), и что он даст.
Что будет, если два раза сделать bind на функции с разными объектами?
И тому подобная ересь на знание всех пограничных случаев.
Вот пример сборника подобных задач: (гитхаб)
Алгоритмические задачи
Обычно вам предлагается решить определенную задачу или проблему с использованием алгоритмов и структур данных. Это может быть алгоритм на обычную сортировку массива, бинарный поиск или алгоритм на поиск узла связанного списка, на котором происходит зацикливание списка. Сложность задач сильно варьируется от компании и интервьюеров. Также здесь не исключены задачи, которые вы никогда в жизни не встретите: на практике такие бывают 1 к 100. Просто вчера интервьюер увидел вот такой прикольный алгоритм и пошел спрашивать его у кандидатов.
Задачи в контексте какого-то фреймворка или библиотеки
Эти вопросы представляют собой задачи, связанные с использованием определенного фреймворка или библиотеки. В основном это задачи в вакууме и придуманных ситуациях. Также задачки-забиячки не исключены и тут. Но иногда просят сделать действительно что-то похожее на мини-таску на 15-20 минут, чтобы посмотреть, как вы пользуетесь данным инструментарием.
Вопросы о решении проблем
Вас просят рассказать о том, как бы вы решали определенную проблему или ситуацию, возникающую в процессе разработки. Обычно придумывать что‑то абстрактное и не нужно (хотя и можно), поэтому в ход идут проблемы, которые возникали у людей, вас собеседующих.
Это может быть:
Нам надо хранить много данных на стороне клиента, что будем делать?
Надо организовать хранение паролей в БД, как сделаем?
Нужно сделать красивую анимацию, как реализуем?
Нужно сделать много вычислений на стороне клиента, как поступим?
Оценка реакции на нестандартные ситуации
Суперредкие вопросы. Вас ставят в определенную ситуацию и слушают, как бы вы ее разрешали и что делали. Скорее всего, эти вопросы направлены на то, чтобы понять, как вы действуете в команде, знаете ли вы, к кому можно обратиться.
Это может быть:
Случился баг на проде и теперь сайт полностью лежит. Что вы будете делать?
Каждые 5 минут падает сервер или база данных, что делать?
Не работает конкретное поведение, как предполагалось в браузере/интерфейсе, что делать?
Тестировщик Василий завел 100 багов без описания и прикрепил к вам, ваши действия?
А в чем, собственно говоря, проблема-то?
Проблема для меня в том, что выглядит это всё, как какой‑то тест, экзамен вроде ЕГЭ. То, где мы выбираем ответ, ставим галочку. И можем либо ответить правильно, либо неправильно. Эти тесты не похожи на то, с чем вы столкнетесь в реальности. Мы в вебе даже шутим: «Есть два вида JavaScript — для собеседований и для работы».
Это похоже на конкурс «Кто больше всего зазубрил». Возникает такое чувство, что все эти справочники и документации нужны для того, чтобы их один раз выучить и не открывать никогда, а делать всё по памяти за отведенное количество времени.
Но ведь главное, чтобы у разработчика было пассивное знание о том, какие бывают проблемы, разновидности API, методологии, библиотеки и т. д.. И когда он будет перебирать в голове варианты решения, он вспомнит, что вроде бы такой‑то инструмент это делает или такой‑то API может то‑то, обратится к документации и применит его.
В реальности абсолютное знание всех аспектов труднодостижимо (невозможно!). Всегда с чем‑то придется столкнуться впервые и пойти в гугл, с нуля изучая вопрос.
Как пример. Я предполагаю (когда‑то читал доку или по логике вещей догадываюсь), что в библиотеке React Router Dom есть какой‑то способ взаимодействовать с параметрами поиска в строке состояния браузера. Я иду, открываю документацию и уже конкретно ознакамливаюсь с подробностями использования и применения данного функционала, заодно это попадает в мою память на определенное время.
Зачем держать в голове всё‑всё, когда есть справочники, документации и заметки? Мы запоминаем только то, с чем мы чаще всего взаимодействуем. Если мне надо сделать какую‑то навигацию по DOM дереву, а я уже 100 лет этого не делал, конечно же, я не вспомню всех методов навигации, я открою справочник, посмотрю и выберу нужные мне вещи, заодно и в памяти это освежится.
Люди ходят в разные компании именно на интервью, чтобы набить руку на прохождение собеседований, решают сотни задач на литкоде, чтобы префайром бахнуть любой алгоритм, который его попросят написать. Есть разные сборники вопросов и типичных задач для собеседований не только для разных языков и технологий, но и для разных компаний. Вот шуточное (или нет?) видео про то, как программисты чрезмерно готовятся к собеседованию: (видео).
Я, конечно, не против того, чтобы люди решали алгоритмы и что‑то учили, но чтобы это не выглядело, как бездумное запоминание ради прохождения собеса, без осознания того, для чего вообще всё это придумывалось и зачем всё это нужно. Это не похоже на диалог двух инженеров, которые используют определенные инструменты для решения определенных задач, обсуждают проблемы и их решения (за исключением двух последних категорий вопросов, и то не всегда они есть или являются таковыми).
Я понимаю: данные типы вопросов никуда не денутся; они нужны для проверки, что человек не полный ноль, если вы собеседуете стажера или джуниора. Но и в таком случае нужно вести диалог, который бы раскрывал понимание языка/инструмента/подхода кандидатом.
Поэтому, когда в описании позиции для разработчика с 3–6 годами опыта написано: «...для вас event loop и потеря контекста не должно быть пустым звуком, а конкретными терминами...», это для меня выглядит, как если бы в описании вакансии водителя говорилось: «Для вас педали газа и тормоза не должны быть пустым звуком, а конкретными частями автомобиля». Ну, тут еще, возможно, HR описание делал без консультации, такое встречается регулярно.
Конечно, нужен отдельный разговор про накручивание опыта работы и про то, что на интервью с опытом работы в 5 лет тебя спрашивают: «Что такое коллекция Set?». Да и в принципе никто не гарантирует, что человек с 3–6 годами реального опыта работы будет знать на этот опыт работы. Можно же не развиваться и не учиться, кто заставляет‑то?
Так, а как надо-то тогда?
Еще раз оговорюсь, что всё это мои мысли и мое мнение. И вообще, кто я такой, чтобы кому-то что-то говорить, как им нужно делать, подумаешь, ферзь тут нашелся.
В первую очередь, нужно больше разговорных вопросов, где можно что-то обсудить и понять, как кандидат мыслит, как он пытается найти решение какой-то проблемы или рассуждает, проблема ли это вовсе.
Вместо вопроса «Что такое event loop?», можно задать вопрос: «Как ты думаешь, зачем нам вообще нужен этот event loop? Без него никак вообще? Какие проблемы он решает?». Вы не будете слушать очередное до смерти зазубренное определение про очереди макротасок и микротасок и стек выполнения, а вы услышите, как видит это кандидат, понимает ли он концепцию event loop'а.
Вместо вопроса «Как нам установить куки?» - «Для чего нам нужны куки? Зачем их придумали? Какой пласт потребностей они закрывают?».
Вместо вопроса «Что такое http протокол?» - «Зачем нам нужен http протокол? Зачем там какие-то хедеры, зачем там какие-то еще методы http существуют? Для чего его вообще придумали?»
Вместо вопроса «Что такое связный список? Напиши мне реализацию связного списка» - «Использовал ли ты связный список? Зачем нам нужен связный список? Где его можно применить, в каких ситуациях?»
Принцип понятен. Разговариваем с кандидатом и слушаем, как он рассуждает и какие решения предлагает, какие выводы делает. Ясное дело, что кандидат с какими-то ситуациями мог и не сталкиваться и что-то не знает, невозможно всё постичь. Тут важнее понять ход мыслей человека: просто ли он зазубрил какие-то определения или осмыслил то, что использует.
Конечно же, не все вопросы должны быть такими. Тут надо держать баланс. Главное, спросить кандидата по всем аспектам, а не завершать собеседование после первого вопроса на решение сложного алгоритма, который интервьюер и сам никогда в жизни не использовал. Знаю людей, которые проходили подобные алгоритмические интервью в серьезные компании, предварительно прорешав пару десятков задач (подготовясь, так сказать). Но это были слабые кандидаты в простом использовании технологий/библиотек/фрейморков, хотя их особо по ним и не спрашивали. Алгоритм решили, а значит, и так норм. Нет, не норм. Нельзя делать акцент на конкретно одной вещи.
Насчет алгоритмов тут отдельная история. Весь смысл же в том, чтобы посмотреть, как кандидат размышляет и как он пытается решить этот алгоритм, а не как быстро он его решит и каким у него выйдет так называемая Big O. Или я чего-то не догоняю, и все классные люди пишут легко любые алгоритмы, не используя никакую справочную информацию? По-моему, некоторые алгоритмы годами придумывались и улучшались, а не за 15-20 минут.
Также не понимаю, зачем спрашивать узконаправленные вещи и требовать их знание. На каком-то проекте N есть неосновная библиотека Х, и мало того, что требуют ее знание в вакансии, так еще и могут пару вопросов о ее использовании задать на собеседовании. Я понимаю еще спрашивать про основную используемую библиотеку или фреймворк (а-ля React, Angular, Vue и тд.), но требовать знание кучи библиотек с работой с глобальным состоянием, формами, запросами и т.д.? Я же не учу в свободное время все библиотеки подряд и могу просидеть на проекте с определенным набором инструментов долгое время, а потом начать искать другой проект с другим инструментарием. Получается, мне надо обязательно быть знакомым со всем, что использует искомый мной проект?
Логика должна быть в том, что я в первую очередь — инженер, который ознакомится и начнет использовать любой инструмент. Как я могу овладеть каким-то инструментом, не поработав с ним? Идти пилить пет-проект? Так некоторые требуют именно коммерческий опыт. А потом проходит время и никто уже не пользуется таким инструментарием, и твои знания устарели, иди новый пет-проект собирай. Так может важнее база и умение адаптироваться, а не погоня за бесконечно выходящими библиотеками?
А как же осуществляется переход внутри компаний на новые инструменты? Ищут людей с улицы сразу со знаниями? Нет. Знаю, что берут людей внутри компании (конечно, речь не про все компании), кто хотел бы поработать с новым инструментом, дают им какое-то время на подготовку, и потом они делают проект. Предварительно отдельный человек проводит исследование инструментов, взвешивает их плюсы и минусы и потом помогает остальным, если у них возникают трудности в использовании. Тут скорее требование к знаниям диктуется бизнесом, потому что кому интересно платить за человека, который потратит время на изучение инструмента и дальнейшее его использование (даже во время онбординга), если можно сразу найти того, кто с ним работал.
Как по мне, надо спрашивать самые основы, а со второстепенными инструментами разработчик ознакомится по ходу дела. Если он хороший инженер, для него не составит труда прочитать документацию и посмотреть примеры использования в документации/кодовой базе проекта. Ситуация похожа на замкнутый круг с требованием к новичкам коммерческого опыта работы, когда для такого опыта нужно сначала устроиться в компанию.
Надо отметить, что из 10 кандидатов выберут того, кто знает больше остальных, тут уже ничего не поделать. Или нет? Смотря какие вопросы задавались кандидатам. Если вопросы по типу, что я описал выше - в виде экзамена-теста, то да, выбор будет сделан очевиднейшим образом. А если вопросы с рассуждением и логикой, то тут можно и посмотреть, действительно ли кандидат понимает, что он использует, или просто выучил синтаксис.
Так и к чему это всё?
Это всё больше поток мыслей. Но и также просьба к разработчикам, чтобы они не забывали: в первую очередь они — инженеры, которые решают проблемы, а не болванки по типу чата GPT, в которые загрузили определенные знания и больше они ничего не могут, кроме как бездумно их использовать.
Комментарии (37)
Platow
25.07.2023 12:37-4Вместо вопроса «Как нам установить куки?» - «Для чего нам нужны куки? Зачем их придумали? Какой пласт потребностей они закрывают?». - Ну это уже бизнес требования по сути)
dsh2dsh
25.07.2023 12:37+6А кто будет задавать такие вопросы, если собеседующий сам на них ответить не может? Или если и ответит, то что-то вроде: потому, что best practice / так написано в книге какого-нибудь Мартина или банды четырёх.
Femistoklov
25.07.2023 12:37Как ни странно, в маленьких компаниях с этим дела лучше обстоят. Там обычно самый главный тимлид собеседует. А в больших конторах, где рядовым сотрудникам (пусть даже в звании "старший сениор") дополнительно вменяют обязанности проводить собесы (может даже за доплату), эти сотрудники как раз среднего уровня. Единственно, на "архитектурном собесе" может быть матёрый (если собеседование многоэтапное).
Nialpe
25.07.2023 12:37толковый собеседующий - редкость, увы. чтобы задавать вопросы, исходя из повествования кандидата, самому собеседующему необходимо иметь знания. поэтому зачастую встречаются любители опросников, прикрывающие свои опросники козырной шестеркой под названием "ну нам же нужна единая шкала для оценки?". так и находят друг друга любители цифровизации умений кандидата и кандидаты-манчкины. плохо это или хорошо покажет только время.
9982th
25.07.2023 12:37+1Адский экспрешен, который в жизни не встретить
Вот вам экспрешен (без полного контекста, ибо тот слишком велик), который мне в жизни не просто встретился, но и отнял у меня некоторое количество этой самой жизни:
v = (0, o[w(109)]) (function (e) { const t = w; var n; return (null !== (n = e[t(427)]) && void 0 !== n ? n : 'GET') [t(218)]() }(t)Хорошее знание синтаксиса, позволяющее подобные вещи распарсить в уме, может сохранить немало времени и нервов если с ними придется (а за пять лет опыта хоть раз да придется) столкнуться.
sergiodev
25.07.2023 12:37+4А зачем? Исходники потерялись?)
aamonster
25.07.2023 12:37Бывает, что их не подтянуть :-(
В смысле, по какой-то причине браузер, в котором вы на это смотрите, не жрёт нормально sourceMaps или делает это настолько криво, что проще отключить их вообще, и приходится вот это вот сопоставлять с исходниками самостоятельно.
piton_nsk
25.07.2023 12:37+1Классный кусок кода про который можно спрашивать на собеседовании "что с ним не так". Даже можно без контекста.
aamonster
25.07.2023 12:37Странно как он у вас скомпилился – с минификацией, но без оптимизации.
ЗЫ: А вообще вы этим комментом, наверное, сделали больно всем, кому по какой-то причине доводилось подобный выхлоп вебпака дебажить)))
zubrbonasus
25.07.2023 12:37+1Вопросы нужно строить в прямой зависимости от предполагаемого уровня квалификации сотрудника. Так если человек отлично мыслит, а по трудоустройству ему накидают задач на решение которых не нужно думать или размышлять, тогда проявятся прелести неудачного найма. Но если у сеньора спрашивать только теорию и термины, тогда найм будет также неудачным. Чтобы найм был удачным важно соизмерять требования к кандидату с предполагаемыми задачами и выстраивать на этом стыке интервью.
TPbIHTPABA
25.07.2023 12:37Если строить вопросы от уровня предполгаемой квалификации то не получится подтвердить эту самую квалификацию, так как мы сознательно упускаем необходимый пласт знаний и навыков.
Jack444
25.07.2023 12:37+1Кто бигдатой занимается, в курсе что недообучение лучше чем переобучение так как всегда можно дообучать на новых данных.
kh0
25.07.2023 12:37[ирони]все дураки - один я умный, ща я докажу[/ирони]
дайте гражданину на код ревью код из репозитория, который писал джун, а потом сеньор все перечеркал пока объяснял почему джун-обезьяна. Бывают ситуации, когда одно взгляда достаточно чтобы понять дичь. соотв. подготавливаем пачечку таких кейсов и начинаем их обсуждать.
тут все нормально? если нет, то почему? чем это грозит и не грозит? что надо исправить?
если чувак заметил все лулзы джуна - значит чувак мидл.
если мидла успешно поправил - значит он сеньор.
если сеньора поправил - зовите Джигурду - пляшите джигу! Ущипните себя, возможно вы спите или под кайфом.
vadimr
25.07.2023 12:37+5Вопросы вида “зачем нам нужен...” – это когнитивная пропасть для человека с философским складом ума. Если верить Будде, в конечном итоге – чтобы увеличить страдания живых существ.
Рассуждая поближе к материальному, это ж не тестируемый придумал и ввёл в обращение, например, протокол http. Может, он ему и вовсе не нужен. И даже скорее всего.
Я утверждаю, что нас в значительной степени окружают вещи, придуманные не очень умными людьми из совершенно ошибочных соображений. Не надо искать в этом высший смысл. (Другое дело, куда эти вещи кто потом приспособил. Вот Колумб, скажем, стремился убить и ограбить побольше индусов, а в результате открыл путь в Америку; если бы он занимался программированием, наверняка до сих пор мы бы прокладывали путь в США, обращаясь к методу toIndia (2)).
Короче, вопросы о побудительных причинах для того или иного решения обычно не имеют не то чтобы верифицируемых, а хотя бы просто общепринятых ответов. Поэтому я думаю, что это плохие вопросы. “Зачем” – вообще самый когнитивно токсичный вопрос.
Вопрос “что будет содержать переменная в данном случае?” имеет однозначный ответ, этот ответ легко проверяем, а результат теста поэтому справедлив. А все философские рассуждения о целях программирования могут по сути показать только то, на одной или на разных волнах мыслят спрашивающий и отвечающий, что непонятно зачем нужно.
Last but not least. В ответах на вопрос “Зачем” наивысший балл всегда получит GPT. А вот на конкретике простым резонёрством не проедешь.
DMGarikk
25.07.2023 12:37А вот на конкретике простым резонёрством не проедешь.
да запросто ;))
я однажды затроллил интервьювера тем что начал сним спорить о том задаваемый им глупый вопрос некорректен и такая ситуация должна быть исправлена и не допущена в принципе, и смысла искать костыльное решение под такую задачу это очень плохо и пощряет омнокод, по этому нет смысла даже рассуждать о причинах и способах решения подобных вещейсобственно на любую тему можно так выехать при небольшим опытом в риторике
кстати очень спасает на тупых собесах где интервюверы сами не знаю зачем задают академические-синтетические вопросы не имеющие смысла в реальной разработке
Dolios
25.07.2023 12:37Регулярно таких кадров собеседую, которые мне рассказывают про миры розовых пони и про то, как всё должно быть по букварю. В ответ на просьбу подумать и придумать решение в конкретной специально созданной искусственной ситуации. Собеседование они не проходят, как не способные к мыслительной деятельности. Не проблема, когда программист чего-то не знает, проблема, когда программист не способен думать и искать решение в рамках поставленных условий.
DMGarikk
25.07.2023 12:37-1В ответ на просьбу подумать и придумать решение в конкретной специально созданной искусственной ситуации
Задания надо давать реальные, а не синтетически-тупые, очень сильно нервирует
обеседование они не проходят, как не способные к мыслительной деятельности
отлично, нечего работать в конторе где интервьювер не может придумать на собесе задачу которая не имеет адекватного решения в рамках бизнеса
Грубо говоря если я приду устраиваться админом и меня будут просить например сделать тулзу которая насильно подавляет обновления у винды и динамически блочит в фаерволле сайты апдейтов… я буду спорить в рамках того что это задача решается совершенно другим способом НЕЗАВИСИМО от того как технически решать конкретно эту задачу, просто потому что эта задача — бред сумасшедшего, и если в конторе есть такие задачи то мне с ней не по пути если "мыслительный процесс" подразумевает исполнение таких задач без попыток эскалировать решение ситуации которая вызывает такие задачи и решать ей другими методами.
А если интервьювер не в состоянии объяснить почему он предлагает решить бредовую задачу и начинает отмазываться "специально созданной ситуацией, инопланетяне прилетели и украли ИДЕ, вы должны помнить синтаксис языка наизусть, и не доступна половина системных либ простопотомушта" (с) — то он тупо профнепригоден
во вспомнил, спорил на интервью, когда мне сунули кусок кода с sql injection и начали просить его улучшить, причем решение существенно ухудшало этот самый injection, на что я резонно указал что именно та задача нерешаема, на что инервьювер начал говорит "та это норм, мы закроем на это глаза, надо решить такую задачу!" — прям рукалицо
искать решение в рамках поставленных условий.
решение бывает административное или архитектурное, а не тимлид/рп сказал ты обязан сделать так как он сказал, тимлид и РП могут ошибаться и важно уметь им на это указать
Dolios
25.07.2023 12:37Да, примерно такой же поток бреда я получаю от как-бы "синьоров" неспособных распечатать словарь в консоль. Они надувают щеки, стучат ножкой и брызжут слюной, прямо как вы сейчас. И всё это потому, что они балаболы, а не программисты, программировать не умеют и могут только пыль в глаза пускать.
DMGarikk
25.07.2023 12:37программировать не умеют и могут только пыль в глаза пускать.
ну я в менеджмент и пошел в итоге ;)
а если серьезно, если бы я не умел программировать, я бы наверное не был бы сейчас сеньором-лидом с ЗП по верхней планке для РФ и опытом работы в разных конторах, я чисто рядовым сеньором года 4 проработал… в разных конторах и в очень крупных и в стартапах и в забугорных в т.ч.
хотя да, именно как программист я вероятно буду слабоват по вашим меркам, по этому я ушел в лиды и менеджмент
но вот смотря в разных конторах на разных людей, тупое умение программировать — это очень мало, надо еще о проекте и бизнесе немного думать, а не печатать словарь в консоль. и я скорблю что подавляющее число коллег вообще не думают за рамками описанной задачи слово в слово
вот у меня есть сотрудник в команде, неплохой миддл, но ему задачи надо описывать прям скурпулезно… вплоть до тупейших деталей в стиле "построил дом, сделай лестницу и дверь и лесенку к ней и чтобы в дверь можно было войти"… оставил его тут одного на две недели, описал задач… он наваял огроменный крутой модуль, с тестами, с доками и… даже не удосужился подумать что его надо было интегрировать вместо старой реализации… хотя в задаче это было
уже год с ним мучаюсь… вот он никогда сеньором не станет, хоть 20 лет опыта у него будет
wolfer
25.07.2023 12:37мне кажется вопрос "зачем?" один из важнейших в IT и вообще в жизни. Сколько раз он меня спасал он придурашных задач, которые решение исходной проблемы клиента, протащив её через жернова аккаунт-менеджеров, ПМов, аналитиков и прочих, превращали в сущий ад.
Dolios
25.07.2023 12:37Это всё, конечно, хорошо, но примерно половина тех, кто приходит собеситься на синьора не справляется с заданием: распечатайте в консоль словарь в виде строк "{ключ} = {значение}", все значения скаляры. Я не шучу. Мне начинают рассказывать, что в работе такое не нужно и вообще можно просто весь словарь сразу вывести и т.д.
Так что, неча на зеркало пенять, коли рожа крива. Пока кандидаты будут нагло врать в резюме, я буду долбать их задачками, которые позволяют понять, что они из себя представляют и умеют ли они кодировать хотя бы на уровне студента.
А что касается алгоритмов, 90% "синьоров" в принципе не знает теорию сложности и что такое "O". Давать им какие-то алгоритмические задачи вообще бессмысленно.
AUser0
25.07.2023 12:37в принципе не знает теорию сложности и что такое "O"
"Моя прелесть"? Да знают они, знают, все это кино смотрели.
dsh2dsh
25.07.2023 12:37, 90% "синьоров" в принципе не знает теорию сложности
90% сеньёров это за последние 20 лет ни разу не понадобилось. А то, что не нужно SQL select писать внутри цикла - они и без этой теории знают. А ещё они знают, что тормоза будут вовсе не от того, какой именно алгоритм сортировки используются, а от того, в каком месте он используется. И для этого не нужно знать теорию сложности или О. Для этого нужно иметь опыт и думать головой.
Dolios
25.07.2023 12:37Ага, а потом такие опытные квадраты пишут там, где можно за линейное время. И это ещё не самый плохой вариант, бывает и хуже. Просто потому, что не знают, как оценить сложность написанного ими.
dsh2dsh
25.07.2023 12:37-1Эти опытные понимают, что не нужно заниматься преждевременной оптимизацией, пока в этом не появилась необходимость. Потому, что знают, что скорее всего оптимизировать придется совсем не тут, где сейчас кажется. Поэтому тут и сейчас лучше написать так, что бы было максимально понятно. А всякие хитрые и скоростные алгоритмы понадобятся потом, но это не точно.
Dolios
25.07.2023 12:37Речь не про оптимизацию, а, например, про линейный поиск по массиву в цикле, когда можно было set использовать. Т.е. про изначально неправильный выбор структуры данных от незнания.
Хватит натягивать сову на глобус, оправдывая лень и безграмотность. Специалист, который отказывается изучать азы своей профессии, плохой специалист. Обычно к такому склонны те, кто не получил профильное образование (но это не всегда так, конечно же).
Это именно то, что отличает инженера (SWE) от ремесленника-кустаря.
dsh2dsh
25.07.2023 12:37-1например, про линейный поиск по массиву в цикле, когда можно было set использовать
А можно и не использовать, если в предполагаемом массиве будет всего лишь два элемента. Я же написал, головой думать надо, а не верить в святого мартина и банду четырех.
Dolios
25.07.2023 12:37Если бы у бабушки был член, то это был бы дедушка. Я пишу про ситуацию, когда нужно использовать. Не надоело демагогией заниматься?
dsh2dsh
25.07.2023 12:37-1Вам бы опыта поднабраться, а то туда же, собеседовать лезете. Бедная компания, для которой вы собеседуете, и бедные кандидаты. Впрочем компанию не жалко - сами виноваты. А вот кандидатов всё же жалко.
Dolios
25.07.2023 12:37Рекомендую вам читать ваш же совет регулярно. Тогда, возможно, вы когда-нибудь соберетесь освоить базовые для професии знания и вырастите из
говнокодеракустаря-любителя в инженеры.Уже только тот факт, что вы в интернете решили писькой померяться с незнакомым человеком, достаточно красочно вас характеризует.
aamonster
Емли интервьюер достаточно квалифицирован, чтобы задать такие вопросы – скорее всего, либо разговор дойдёт и до них, либо он оценит способность кандидата на них ответить косвенно.
Это как с маленьким тестовым заданием – конечно, на решение смотрят (совсем уж негодные кандидаты отсеиваются сразу), но в первую очередь это тема для обсуждения: если у нас такие-то изменения в задаче – как поменять код, ну и т.п.