Собеседование C++
ฝัง
- เผยแพร่เมื่อ 28 ก.ย. 2024
- Всем привет!
Провели тренировочное собеседование со Станиславом на позицию Middle+ C++ Developer.
В конце видео важная часть фидбэка, не пропустите.
Приятного просмотра!
Не забудьте поддержать видео :)
telegram: t.me/AmbushedR...
twitch: / ambushedraccoontv
#interview #cpp #senior #middle
Видео было переименовано в Middle+, поскольку Станислав откликался на набор кандидатов на позицию Middle.
Однако в процессе нашего общения я оценил его навыки на уровень Senior.
Ну вы обсудили слишком мало тем чтобы оценивать его как сеньёра. ИМХО
Вообще странное собеседование. Вопрос про знание истории, что там появилось в 11 версии... Вы собеседовали пенсионера на должность экскурсовода в музей истории информатики?! ))) Тогда да.
Имхо, вопросы на сениора должны быть с архитектурой всей системы целиком. Вопросы про архитектуру конкретного класса локального, это уровень middle. Но вот про фрагментацию памяти, тут поверю, что уровень сениора. Всё же большая часть вопросов на мидла.
Ну не спец дядя по GC и что 🙂
проблема в том, что он даже на простые вопросы не мог толком ответить. куда там до сложных.
Когда Джуниор пробует собеседовать мужика из народа. А оказывается что мужик знает намного больше данного Джуниора 😅😂
да мужик похоже толком ничего не знает.
Как троечник на экзамене
У мужика все подсказки на потолке, я его спалил XD
Прошу прощения за критику. Я бы не пошёл в жизни к такому работодателю, который не может сформулировать задачу. А это значит, что он не может организовать как работу отдельного программиста так и коллектива. А это как нарастающий снежный ком. Если не может организовать работу коллектива, значит вообще не способен выпустить продукт сложнее, чем пример из книжки самоучитель C++.
Как и всегда интересно, но вопросы в этот раз подкачали для сеньора, и ответы тоже.
давно тебя не было
Сборку мусора реализовали в Unreal Engine.
Мне кажется она прекрасна работает
Не подскажите, чтобы в целом в разработку на ue закатить, кроме c++ и самого движка, много чего надо знать?
Не сказала бы что прям много, но все относительно.
Для начала предстоит изучить фреймворк движка.
Понять как все устроено, как построена архитектура, узнать возможности и функции движка (это касательно программирования).
Естественно другие аспекты (АИ, Материалы, Левел-дизайн, частички, анимация и т.п.) требуют дополнительного времени и являются частью движка.
Как только вы изучили Blueprints (визуальное программирование, которое позволяет быстро прототипировать механики и изучить возможности движка), можно переходить в С++.
С++ в анриале сильно упрощенный инструмент, который раз в 20 быстрее Blueprints по скорости выполнения и раз в 5 медленнее по написанию кода.
Во-первых тут есть сборщик мусора и следить за памятью вам не надо.
Из-за чего конструкторы не являются конструкторами.
Чтобы установить поля при создании объекта прийдется написать отдельную функцию.
(Хотя С++ анриала позволяет создавать свои объекты без использования сборщика мусора, чтобы в будущем руками их удалить, но это не выгодно и не удобно)
Во-вторых тут нет множественно наследования, и есть отдельная сущность интерфейсов (не стандартный абстрактный класс).
В-третьих тут используются свои коллекции: TArray, TMap, TSet, TQueue, TSet. Зачастую у них немного другая реализация внутри.
Например, TMap не добавляет сразу элемент если к нему обращаешься и его нет (m['a']++ выдаст ошибку если в TMap нет 'a')
В-четвертых тут нет исключений. Любое исключение - это краш. В играх принято, что ошибок не может быть.
В-пятых связь с блюпринтами(чтобы в них настраивать свои классы, а не перекомпиливать каждый раз всю игру) довольно интересная тема, особенно с правилами передачи аргументов в функцию.
Можно еще много перечислять, но суть вы уловили.
Знать С++ != уметь писать код для игры.
После изучения такого кастрированного С+# прийдется наверное изучить мультиплеер.
Я считаю это отдельной большой темой, которую я за 6 лет до сих пор не до конца знаю.
Касательно отдельных знаний - мне часто пригождается математика 9 класса (векторы).
Возможно знать паттерны и data structures поможет в будущем.
В анриале под капотом уже реализован Singleton, Observer и другие, а сама архитектура движка построена вокруг мультиплеерного сессионного шутера.
Архитектура игры - почти 50% работы. Плохая архитектура не позволяет дальше расширять игру.
@@1play2fun понял, спасибо огромное за развёрнутый ответ.
@@1play2fun А ещё, если можно уточнить, сам процесс разработки сильно требователен к железу или нет?
@@ВладиславРождественский-в9ъ очень требовательный. Особенно на анриале. Вся проблема в том чтобы протестить свой код, нужно закрыть движок, скомпилить, открыть движок, запустить игру.
Это занимает уйму времени.
Чем лучше процессор, тем быстрее компилим. На моем стареньком amd ryzen 5 1600 это около двух минут всегда. Представьте вы изменили одну строчку кода и чтобы ее проверить, надо ждать 2-7 минут.
Про hotreload и livecoding молчу.
Оператива улетает как бешеная.
У меня только райдер жрет 6-8гб. Ещё движок в чистом виде 2-4, а когда долго работаешь - все 18😂
Особенно если игна жрет прилично.
У меня процедурный мир на сервере весит 4гб.
SSD обязательно.
Желательно райдер, проект, движок и файл подкачки иметь на одном диске.
На счёт видеокарты - зависит от игры.
Если вы делаете ААА шутер и там 200к поликов у камня и 16к текстуры, то думаю GTX 1060 уже будет еле 30фпс выдавать. Особенно если это 5.0+ с новым освещением.
Я же сижу на 4.27 и делаю игру с простой графикой. Поэтому видюха слабенькая, 32гб оперативы мне для разработки достаточно
Вместо виртуального деструктора можно сделать приватный. Тогда никто не сможет вызывать ~Base(), что решит проблему.
«Прчему в c++ невозможно ввести сборщик мусора?», тем временем c++26 фактически вводит локальный сборщик мусора
а зачем? умных указателей вполне достаточно.
@@Pa36ouHuKпо сути это ещё одна разновидность умного указателя, для высоко нагруженных многопоточных систем, просто у него принцип работы как у локального сборщика мусора.
@@ihrfuhrer86 ок, посмотрю. Но я пока c++20 ниасилил ))
100 лет как существует Boehm (and Co) Garbage Collector
@@Pa36ouHuK Не достаточно.
7:40 на счет скорости кучи и стека - КР580ВМ80 передает привет, и удивляется слову "кэш" :) Проблема всех видео у этого автора - слишком специфично платформенные вопросы. C++ программа компилится не только для интелов и виндов (или линуксов), существует железо от условно нонейм производителей, которое живет и здравствует, и нас окружает. И для этого железа тоже пишутся программы.
Спасибо! Интересно. Есть вопросы которые стоит подтянуть интерьюируемому. Но по сравнению с синьорами которые мне попадаются, он очень сильно
Окси когда новый альбом
вчера когда начал смотреть вроде был сеньор помидор, сейчас уже понизили до мидла)
Ответ в закрепе. Грубить не обязательно.
@@ambushedraccoon6408 Никого не хотел обидеть, по знаниям он вполне senior
жестко, мужик с десятилетним опытом запинается и не знает ответов, а новичков вообще ломают на собеседовании поди
Отличное видео, будет ли еще собеседование на junior-middle позицию?
Автор канала сам-то точно Senior?
Сеньёр - помидор лол 🍅
ну какой же это сеньор? не многопоточность добавили, а memory model - что куда как более широкий сабж, атомики теже. про hash tables - вопрос ни о чем. Load factor ни тот ни другой не знает. про инвалидацию ссылок и итераторов похоже ни тот ни другой не слышал. про Move semantics слышал-слышал молодец. о чем вообще вопрос? сборщики мусора с generations похоже тоже мимо прошли. очень поверхностное собеседование. извините.
Честно сказать, не понял, почему нельзя увеличить размер стека и работать только с ним. Мог бы кто-нибудь объяснить.
Стек имеет фиксированную длину. Обычно стек используют для инициализации массивов заданной длины, там хранятся все строки. Грубо говоря стек не предназначен для работы с нагруженными проектами, которые будут потреблять, может быть, один гигабайт памяти. В стеке нет динамического выделения и стек неизменяем в плане того, что значения в стеке можно только перезаписать. Именно поэтому лучше отдать предпочтение динамической памяти.
наоборот, почему не выделить сразу кусок статической памяти и забить на динамическое выделение, ну и стек в помощь, так и делается на микроконтроллерах, там где нет никакой ОС.
@@IExSet Ты прав.
Стек используется при вызове функций и по этому постоянно изменяется. В него сохраняются адреса возврата и параметры функций. Если ты что то выделил на стеке, то оно станет невалидным когда функция завершится и произойдёт возврат в вышестоящую функцию. Поэтому стек это удобное место для локальных переменных. Если хочется просто статически аллоцированной памяти, то это лучше сделать другими способами, например аллоцировать в куче =)). Никто не запрещает сделать огромный глобальный преаллоцированный буфер в куче и использовать его на своё усмотрение.
На сеньора ожидал вопросов по паттернам (какие знает, когда уместно применять, плюсы/минусы), по стандарту побольше, важные аспекты производительности и изменения в стандарте (move-семантика, (N)RVO, ...), умные указатели (какие знает, принципы реализации), по шаблонам пробежаться. Понять насколько широк кругозор и глубина погружения в проблематику типовых проблем при разработке.
классный видос! очень интересно
Есть ли список вопросов по плюсам 100-200 самых не слишком тривиальных?
Таймкоды?
Что на x86, что на ARM (raspberrypi) под Linux'ом:
$ ulimit -s
8192
$
какой ответ на ваш вопрос про скорость обращения к данным в стэке и куче
Скорость наивысшая 👍 в обоих случаях 😏
Со стеком будет работа быстрее. Работа с кучей в большинстве случаев будет требовать больше операцией от процессора.
Вот неплохая ссылка:
ru.stackoverflow.com/questions/277295/%D0%9F%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BA%D1%83%D1%87%D0%B8-%D0%B8-%D1%81%D1%82%D0%B5%D0%BA%D0%B0
@@ambushedraccoon6408Можно лишь констатировать что вы не разобрались в вопросе. На стеке не нужна аллокация памяти, она ещё при компиляции закладывается или происходит мгновенно изменением регистра указателя на стек. Но доступ к памяти будет одинаков, независимо от того на стеке она или в куче. По ссылке там какой-то бармалей пишет про фрагментацию кучи, но во первых это не влияет на скорость доступа, а во вторых неправда. В системах с виртуальной памятью никакой фрагментации кучи быть не может. Фрагментация возможна только внутри отдельных страниц памяти, но это ведёт только к не оптимальному расходу памяти.
А может кто-нибудь подсказать что подразумевалось по connect to file?
Что появилось в 11 стандарте?
Правильный ответ: да кого это ебет? Тут что экзамен по истории с++? Какой смысл помнить все стандарты на память? Аж трясет
Мне задавали подобные вопросы.
Странная какая-то реакция. Причем тут помнить все стандарты на память? Полезно знать ключевые моменты стандартов, чтобы, например, на обсуждении с условным бизнесом вы могли сходу предложить пару идей, обосновывающих ваше желание перейти на более высокий стандарт и инвестировать время в технический долг.
День добрый, господа! Какой фреймворк на данный момент выглядит выигрышней для джуна, если выбор стоит между Qt и JUCE? JUCE сейчас явно обсуждается активнее, но Qt рекомендуют чаще, ибо он в принципе узнаваемее
Здравствуйте.
Мне сложно ответить ибо я работаю с Qt. По нему вакансий больше.
Можно и то и то попробовать и выбрать, что будет интереснее.
интервьюер прям няшка)
А в каком плане для него это первый опыт?
Скорость стека vs кучи: у стека ещё выделение/освобождение памяти должно быть быстрее, т.к. это всего лишь изменение значения адреса вершины стека в регистре, а у с кучей работает аллокатор, который в журнале учитывает участи или что-то в этом роде.
Я прав? (Я джаваскриптер вообще 😄)
Ты прав про стэк 😀а вот для работы с кучей требуется участие ОС, мы делаем системный вызов "ОС дай нам памяти", она смотрит что есть свободное и отдает. И тоже запрос к ОС для освобождения
Это верно, но вроде как Дмитрий имел в виду доступ к памяти, который по сути происходит за одинаковое время, как сам сырой доступ, так и возможный доступ с кэшированием
@@ReezonBeatbox если не требуется выделение доп. памяти, хватает имеющейся, менеджер не делает никаких вызовов ОС
@@IExSet да, согласен, в этом случае на linux будет просто вызов brk. А если еще есть кастомный аллокатор, то можно не идти на уровень ОС, но опять же от реализации зависит)
@@ReezonBeatbox Совершенно согласен. Зашёл в эти комментарии, поскольку не услышал правильного ответа от ведущего интервью.
Автор, а можете рассказать об упомянутом способе реализации корутин? Сделаете видео с разбором корутин из C++20 (stackless), boost::coroutine, boost::coroutine2 (stackful)? Покажите как сделать свою простейшую реализацию?
Здравствуйте, можно таймкод, где упомянул?
@@ambushedraccoon6408 Примерно 27:00
🔥🔥🔥
Планируется ли проведение стрима?
Мало понятно. Но интересно.
Спасибо за труд !!!
По поводу отличий стека и кучи:
А как собственно в стеке освобождать рандомные участки памяти? Сложных алгоритмов без этого не построить.
А загоны с кешами вообще ерундой считаю.
Да примерно так же как на куче. В ряде случаев можно ведь ничего фактически не освобождать, placement new делать или вовсе ставить флаг, что объект вакантный. Туда сюда дёргать участки памяти - это не очень хорошая идея в плане производительности.
Память в стеке освободится автоматически при выходе из функции. Если возникает потребность "освобождать" память в стеке, значит вы его как то не так используете.
Привет, недавно начал изучать c++, ищу себе напарника по изучению, если заинтересовались ответьте на мой комментарий и спишемся уже.
Я
@Dan4ik797 tg пиши
@@lstarbox3765 @maksimrushinskiu
Тоже хотел бы найти напарника
Странные вопросы человеку из НИИ, реально работающему в отечественной науке и приборостроении, а не над задачами автоманизации пицерии и поддержки порносайта. Даже сами сленговые джун, мидл и сеньор он переводит в человеческие "инженер", "старший инженер", "ведущий инженер" принятые в России. Это видно. Вы говорите на немного разных языках. Он больше на русском, а юноша на птичьем ))) Но я рад что друг-друга понимают.
Товарищ из НИИ как бы мало чего знает, плавает постоянно.
вау, впервые вижу senior на данном канале
должно было быть на мидла
@@СлаваАлександрович-ц3б просмотрев половину сам уже понял
Ага, ни один, ни другой нихера не знают, собеседование у них...
Станислав-то хоть уважения заслуживает, без образование (это явно видно) до таких вершин добраться.
Да, дядя мощный олдскул плюсист, но с 11-м стандартом он заплавал знатно 🙂 Я уж не знаю, можно ли без этого нормально жить C++11, но сегодня немыслимо жить без move-семантики, r-value ссылок. Если чел про это сразу не вспоминает, вопрос, как он пишет на современном С++ ???? "Чем он отличается то от других" - вообще то там на минуточку количество нововведений было больше, чем после Си с классами.
И constexpr попёр, то что раньше требовало пируэтов уровня Александреску сейчас пишется просто как функция, появились constexpr коллекции !!!
Вот он всё про итераторы STL постоянно говорит, значит это его главный инструмент, а ведь у них композиция прихрамывает, а про range и views ничего, значит не использует.
В unreal engine есть сборщик мусора. Так что можно сказать, что на плюсах уже его реализовали, хоть и под одно специфическое направление. Мне кажется, больше проблем возникает при многопоточке, когда для освобождения памяти мы должны быть уверены, что никакой поток не работает с этой памятью
shared pointers и hazard pointers решают эту проблему в многопоточных структур данных вроде как
@@rouchy_ да, в UE там смысл вроде как раз в счетчике ссылок на память) опять же вопрос перфоманса, если брать обычный shared_ptr, то там внутри атомик, который постоянно будет дергать кэши и синкать их. А hazard pointers хотят ввести только в 26 стандарте плюсов, а какую лучше реализацию сейчас использовать надо разбираться) но это все мелкодрочинг и вряд ли кто-то реально с этим столкнется и будет запариваться)
Да, я об этом написал тоже
Когда следующий стрим ?
Очень полезное интервью. А не скажите, в какой области предлагалась позиция (хотя бы примерно)?
Спасибо за отзыв) Это тренировочное интервью.
С++ это про 0-overhead, поэтому там и не будет сборки мусора - лишние тормоза для самого быстрого языка.
Unreal Engine: .__.
@@1play2fun причем тут UE и C++?
@@CaHe4ka123 UE написан на с++. В данном проекте, авторы реализовали сборщик мусора в рамках языка с++. Автор в видео сказал что это невозможно или затратно. Но Epic Games показали обратное
Это всё в вульгарном изложении, а по факту автоматическое управление памятью тоже может работать быстро и может быть быстрее чем на грёбанных счётчиках.
Когда Джуниор пробует собеседовать мужика из народа. А оказывается что мужик знает намного больше данного Джуниора 😅😂
Да где же ?
Ну, на самом деле дядька не сеньор. Это олдскул хороший))
должно было быть на мидла
@@СлаваАлександрович-ц3б да даже если мид, то вопросы слабые. почему не было вопроса по архитектуре? гтк это вообще достижение в си++)) на собесах для фронтенд разрабов вопросы для джунов сложней. что стало с си++?
@@sashabroslavskiy7904 так может подготовите воаросы и проведете собеседование? я готов поообщатся, и судовольствием это сделаю. Человек подготовился провел собеседование, вы же такого не сделали. непонравились вопросы, бывает. давайте список своих тогда.
вопросы вызвали удивление) причем тут мои вопросы?