С/С++: вопросы на собеседованиях

так я и не против давать практические задачи на ~30мин - 1 час :) Но какие? Я не смог найти ничего практического, реально применимого/интересного и что можно реально накодить за час.

Но я могу просто высказать своё мнение, что 99% задач с leetcode не имеют никакого отношения к промышленному программированию.

Смотря что считать «промышленным программированием». К формошлепству на java и прочим питонам не имеют.

Просто интересный пример - автор HomeBrew не прошёл первичный отбор в Google, не смог бинарное дерево инвертировать. Он плохой инженер, правда? :)

Он просто не подходит для работы в гугле. HomeBrew это, кстати, не какой-то rocket science.

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

Но светить ими тут не буду.

опенсорс жеж!

leetcode 283 это практическая задача

неплохо, но слишком просто. Не на час.

Он просто не подходит для работы в гугле

Это утверждение не имеет оснований, потому как я и говорил, никто не может доказать что алгоритмы а-ля Leetcode для программиста имеют какую-то статистически значимую важность. Эти же компании никогда этого не доказывали. Что они говорят? Мы нанимаем вот так ПАТАМУШТА. А вот интересная статья об обратном: No Correlation Between Interviewing and On-The-Job Performance

На первые 10-15 минут собеседования.

Смотря что считать «промышленным программированием».

Кстати да. Всякие Qt QML / GTK это тоже С/С++ программисты. Но там вообще вопросы совершенно другие будут.

Leetcode точно не нужен для фронтендеров.

Leetcode — это, да, совсем не олимпиадный уровень. Но и тоже не повседневный (9до5). Хотя таки при должном напряге, любой программист должен уметь такие задачки решать. Т.е. leetcode отсеивает тех, кто программировать на самом деле не умеет, но выдает себя за программиста (такое часто бывает).

Leetcode точно не нужен для фронтендеров.

Именно поэтому современный фронт это в 99% говно из-за которого браузер начинает выжирать cpu и память.

Такой вопрос - намек на то что возможен такой код в компании

Он такой, потому что менеджмент не дает времени на оптимизацию кода. Писать «с нуля» сразу оптимальный код нельзя. А писать выскопроизводительный код — это вообще отдельная история.

leetcode 283 это практическая задача

неплохо, но слишком просто. Не на час.

Очень хорошая задачка, вот именно такие и нужно искать, и давать для решения «на бумажке», в «интерактиве» сидя прямо перед Вами.

ПыСы. Понятно что конкретно эта в две строчки решается (remove + fill), но все ли увидели что fill можно избежать если и так все нули?

Он просто не подходит для работы в гугле. HomeBrew это, кстати, не какой-то rocket science.

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

Если не нравится история с HomeBrew, посмотри историю в WhatsApp.

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

Выскажу свое неудовольствие конкретно «задачками на время».

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

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

3. На задачи очень легко натренироваться, потому что они все по сути однообразные. Когда у меня была потребность пособеседоваться в Амазон, я пошарился по ютубу и нашел сразу несколько читшитов на тему прохождения технических интервью в FAANG. Фишка там в том, что большинство даваемых задач является вариацией на тему всего нескольких технических приемов. Именно владение этими приемами и нужно тренировать.

4. Leetcode score можно тупо купить. Так что, совсем не показатель. True story.

Суть задачек в том, чтобы:

(a) отсеять людей, которые только выдают себя за программистов;

(b) дать предмет для обсуждения на собеседовании.

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

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

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

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

Тут еще есть нюанс. Практики проведения интервью переносятся 1-в-1 из США на остальные рынки труда, которые очень даже другие. В РФ будет совсем другое распределение скиллов по кандидатам, чем в США. И один и тот же тест будет показывать совершенно разные вещи на разных рынках. Вот это не учитывается от слова «совсем».

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

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

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

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

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

Все верно. Периодически надо рефакторить старые решения.

Рискну прослыть «некрофилом» за ответ на старые комменты, но тем не менее. У нас работает примерно так:

Есть некий code-base несущий условные «золотые яйца» (десятки MLOC). В какой-то момент появляется use-case этим кодом не покрывающийся. Если есть возможность его «дёшево» покрыть добавив ложку го^wдёгтя - именно это и будет сделано. Потом наступает момент когда объем го^wдёгтя превышает критическую массу, и тогда принимается волевое решение этот конкретный кусок кода переписать. Он переписывается, аккуратненько релизится в прод, и цикл повторяется.

Условные «пионеры» пытающиеся переписывать всё подряд обычно посылаются (well, коммиты не пропускаются, и они лишаются премий которые сопоставимы с годовой зарплатой). Обычно люди после этого или сами одумываются, или «растворяются в тумане».

Мне вот просто интересно - а как ещё то? Кто-то делает по другому?

Кто-то делает по другому?

Нас учили модульному проектированию, каждый модуль решает свою и только свою задачу (буква S в методике SOLID). Связи между модулями - минимальны, например - микросервисы. И отлаженный и оттестированный код никогда не меняют, если в нем нет ошибок.

например - микросервисы

И в каждый микросервис содержит телеметрию - единственную выполняемую им задачу.

Мне вот просто интересно - а как ещё то? Кто-то делает по другому?

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

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

серьезный вопрос. Столкнулся недавно с проблемой когда кандидат на Senior отказался отвечать на технические вопросы, типа что это за вопросы для позиции. Может я не прав, но техническое собеседование для этой позиции должно быть сложнее всех. Среди вопросов must be: 1)Наследование и полиморфизм. Конструкторы, конструкторы копий, как это все создается компилятором, что значит семантика перемещения, перегрузка операторов и т.д. Сильное и слабое связывание между классами. Множественное наследование versus композиция. 2)Работа с памятью - как правильно укладываются структуры, в чем разница алокации в куче, в стеке, в постоянной памяти. Разные контейнеры stl - какова разница в скорости для разных операций. Как оптимизировать доступ к памяти, как вообще оптимизировать скорость кода, общие подходы. 3)Шаблоны - зачем нужны, в чем недостатки и преимущества, как специализировать шаблон. В чем разница между статическим и динамическим полиморфизмом. 4)Приведение типов. Ну тут понятно - все операторы приведения типов должны отлетать от зубов. 5)Многопоточность - примитивы, общие подходы к пониманию и исправлению проблем. 6)Паттерны - обычно предлагаю назвать кандидату любимое приложение на компе и пытаемся вместе осмыслить это приложение с точки зрения полезных паттернов для его создания 7)Опционально - алгоритмы, если кандидат чувствует силы на это отвечать. Но если отвечает - огромный плюс кандидату. Считаю, что хотя это и не часто используемый раздел знаний, но самый интересный. И если кандидат знает чем отличаются сортировки друг от друга, и знает что такое алгоритм Дейкстры или битоническая сортировка - значит любит свое дело и хочет разбираться в нем глубоко. Сами вопросы сформулированы в виде небольших задач с кодом, которые надо исправить или переписать. Абсолютно правильное решение не требуется, важнее - ухватил ли кандидат важные нюансы в своем решении. Даже если написал неверно, но ухватил важное - засчитывается в плюс. Зачем все это так много надо (по моему мнению). потому что Senior по своей должности очень часто должен ревьювить код. И тут «заглянем в Гугл если че» - не катит. Надо смотреть и видеть когда что-то не так. а для этого надо держать много всего в оперативной памяти. Как-то так.

хороший чеклист. надо бы еще добавить для тру синьера: понимание того какой асм код сгенерится от с++ кода и умение читать асм - дает больше инструментов дебажить оптимизированный код и крашдампы; понимание того как все укладывается в памяти - дает возможность фиксить/дебажить мемори корапшены.

Робяты не надоела языками чесать?
Все ведь просто

ДУРАКА, ВИДНО ИЗ ДАЛЕКА ...

Среди вопросов must be:

и ни одного вопроса по предметной области, …это вы лектора по курсу берете - «ооп вообще и на си++ в частности».

условно: расскажи мне все тонкости TCP

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

до каких-то диких тем с сокетами и каких-нибудь кэшей и как с ними работать в CPU

Ну, сокеты, ладно: может, человек с сетью толком и не сталкивался. Но кэши-то? Это же what every programmer should know about memory. Или знает, или не программист, а, так, клепатель…

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

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

Мне вот как-то один гражданин вместо добавления достаточно мелкой функциональности переписал весь код в своём стиле =) Что есть смертный грех в open source (золотое правило: в чужом монастыре пишешь в местном, монастырском стиле). До сих пор не уверен, правильно ли я сделал, что дал ему права на репозиторий.

какой асм код сгенерится от с++ кода и умение читать асм

Да там миллион строк и хрен ты чего поймешь, если мыслишь в терминах предметных абстракций, а иначе на с++ никто не пишет.

и знает что такое алгоритм Дейкстры или битоническая сортировка

Я знаю. Куда приходить на собес?

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

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

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

Звучит заманчиво, но половину слов я не поняла.

да я тоже. писал под диктовку синьера :3

Если есть возможность его «дёшево» покрыть добавив ложку го^wдёгтя - именно это и будет сделано.

Мне вот просто интересно - а как ещё то? Кто-то делает по другому?

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

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

Звучит заманчиво, но половину слов я не поняла.

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

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

Тогда такой проект не годится для оценки способности человека взаимодействовать с другими людьми. Очевидно.

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

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

Ты частное (свой безюзерный проект) распространяешь на общее (все проекты на гитхабе), что неверно.

Возможно уже такое советовали, но читать восемь страниц треда не осилю.

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

Кстати. Как в линукс загружать код библиотек во время исполнения программы? Это вообще что такое? Зачем? Никогда даже не слышал про такое. На собеседовании спросили.

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

https://man7.org/linux/man-pages/man3/dlopen.3.html

Зачем?

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

А это часто используется?

А это часто используется?

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

читай про «динамические библиотеки». они не только в линуксе, они везде есть.

Сильное и слабое связывание между классами.

Можно пояснить - это о чём?

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

И опять не понял, а разве мы занимаемся чем-то ещё?

понимание того какой асм код сгенерится от с++ кода и умение читать асм

Я не думаю что Вы этого много найдёте нынче. Выросло поколение которое привыкло ко «всему готовенькому». Увидите такого человека - берите сразу.

Я знаю. Куда приходить на собес?

Знать - мало. Нужно уметь применять на практике.

Но кэши-то? Это же what every programmer should know about memory.

Да ладно! Вы реально думаете многие эту статью читали, а главное поняли о чём там речь?

Мне нравится задачка из школьной геометрии, класс 8-й наверно.

Как по мне тут 8ым классом и не пахнет.

Её и спрашиваю: «Можно ли на бумажке в клеточку нарисовать правильный треугольник, так, чтоб все его вершины были в узлах клеток».

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