51:27 Здесь нужно иметь желание разобраться в нюансах C++ и потренироваться на своём проекте. Написать тесты. Запомнить тонкие моменты. Это не про написание shared pointer. Это про знание C++ и умение на нём писать работающий код. Простое чтение здесь вряд ли поможет. Нужно практиковаться и ловить ошибки. Нужно дебажить свой код на тестах, смотреть, где происходят проблемы и исправлять их. И так пока не научишься видеть все проблемы и писать работающий код.
14:50 Есть хорошее правило: все постфиксные унарные приоритетнее всех префиксных унарных, а все унарные приоритетнее всех бинарных. Но в данном случае префиксный минус-минус решил бы все проблемы, да ещё и повысил бы читаемость. 24:15 Объект oth, конечно, константный, но меняется-то в нём не указатель, а разыменованное значение, которое не является константным даже для константного oth. Написано, что инкрементируется указатель, но это собеседуемый не смог правильно написать, подразумевается, что инкрементироваться должно разыменованное значение.
Позволю себе немного покритиковать собеседующего. А именно начало критики реализации метода класса сразу же после написанием собеседуемого последней его строчки, тут есть несколько проблем: Во-перых само по себе обсуждение корректности отдельного метода не в контексте чисто языковых ошибок, а непосредственно логики класса - спорна, т.к. их работа де-факто завязана на общий сайд-эффект, которым являются состояния класса - о корректности методов полноценно можно говорить только после полной реализации их всех. Понятно, что всегда можно исходить из концепции, заранее предвидеть проблему или вовсе сказать, что это стандартная вещь и кандадат должен ее тупо знать, но если вы расчитываете, что человек реально должен что-то сам, своей головой, спроектировать в процессе интервью - рассчитывать, что он сходу реализует корректный метод без последующей итерации по остальным методам класса и анализа возможных проблем - странно. Во-вторых у людей разный стиль написания кода и многим намного проще исходить из некоторого "костяка" решения постепенно рефакторя и дополировывая код и решая "граничные" случаи. Я понимаю, что время ограничено, да и вы вполне могли воспринимать это как легитимную наводку к решению, но воспринимается это как моментальная критика того, что кандидат еще даже сам не пытался утвердить как правильное решение. В стрессовой ситуации собеседования это особенно болезненно и по кандидату это видно. Можно же хотя бы дождаться пока попытается перейти к следующему методу или хотя бы предложить вернуться к нему позже. А в остальном - отличное интервью и спасибо за видео)
Здесь, скорее, задача оказалась не по уровню собеседуемого, то есть, явно сложнее, чем следовало бы. Поэтому почти сразу возник цейтнот со всеми вытекающими, о которых вы пишете.
*(strong_counter)++; //wat? :) Приоритет, кстати, тут легко определить, достаточно вспомнить классическое сишное копирование памяти: *a++ = *b++. Ну и... можно же ++*strong_counter. Однако: int* obj, strong_counter; // счётчик же - простой int :)
Получил мощнейшие впечатления! Это -- особое умение, видеть абсолютную жесть и даже глазом не моргнуть! Хотя во второй половине собеседования во времена особой жести во взгляде замечалось нечто вроде либо лёгкого ужаса, либо офигения от увиденного. Жаль, что так вышло, джуну попроще что-то лучше было дать, с unique_ptr он бы справился явно лучше. Всё собеседование, кстати, прошло при неправильно объявленном strong_counter, который при таком объявлении -- типа int. Что, кстати, дополнительно подтверждает, что попался именно джун. Тип возвращаемого значения из перемещающего operator = тоже неверен. Какую функцию несут скобки в выражениях, где он пытается инкрементировать strong_counter? За всё время собеседования собеседуемому и в голову не пришло, что запись выглядит как-то слегка не так. Ещё есть моменты, тайминг себе записал, может, потом прокомментирую.
@@ozimandias1858 да, там есть требования к знанию алгоритмов. Но и помимо того много спрашивают об особенностях языка, компилятора и т.д.. Тут же очень поверхностно, что даже на джуна не тянет
@@vilture5706 это не нюансы shared pointer, это нюансы конструктора копирования, перемещения. Умение писать работающий код на C++. Это точно не про нюансы shared pointer.
@@wsxpocxeafxчтобы сделать игру на анрил тебе не нужно знать программирование вообще. Примеров куча, та же игра с поездом - только блюпринты. Если ты хочешь сделать большую игру с офигенной графикой, то нужна команда и бюджет, там плюсы нужны только при работе с графикой, вернее 1 плюсовик. Если вдруг что-то ещё кроме работы с графикой и памятью понадобится на плюсах написать, то можно конвертером с Шарпа на плюсы воспользоваться. Просто только в определенных случаях мощь плюсов понадобиться, в остальных это просто стрельба из пушки по воробьям.
Откуда такая любовь к этим онлайн редакторам кода? Там что удобно писать код или он полностью повторяет опыт разработки на реальной работе? Сомневаюсь.
Он показывает как человек пишет код без помощи анализатора в реальном времени. В идеешках или других платформах подсвечиваются не только синтаксические ошибки, но и логические. Самый банальным пример, при использовании алгоритмов из stl, редактор укажет на ошибку в духе : переданы итераторы на разные контейнеры, или один итератор конст, а другой не конст. В целом показывает уровень внимательности человека. Так сказать 2 в 1 проверка
@@alisii442 если ты давно работаешь с IDE, специально не тренировался, ты в любом случае будешь теряться. А второй кандидат придёт, который просто готовился. Не факт, что второй будет лучше в среднем. Пусть IDE помогает, на работе же в IDE будет писать.
@@alisii442 ничего это не показывает. Если дать задачу и он её сделает, вот это показывает уровень всего. Как он решил задачу, что использовал - его дело. А давай в прямом смысле в блокноте будут все кандидаты код писать и вручную командами вызывать компиляцию кода. Без гугления. Это покажет уровень памяти и пробовал ли человек работать с компилятором вручную 🤣
@@alisii442 написание кода без IDE и без заглядывания в справку заранее провальная идея. В любом случае нужно куда-то подсматривать. Весь SDK, всю стандартную библиотеку не запомнить наизусть. И хочется видеть результат работы написаного кода, а не писать нерабочий код, который непонятно вообще работает или нет. И даже ведущий собеседование может неправильно понять написанное в онлайн редакторе, проверить же нельзя.
@@wsxpocxeafx совершенно с тобой не согласен. На собеседованиях цель интервьюера не просто увидеть, что кандидат способен из точки А прийти к Б, а то как он это делает. Если ты обращал внимание, то в реальных собесах лайфкодинг всегда идет после теории, а там все отличие и появляется. Я по одной такой секции могу определить сколько реального опыта у человека. Если он сидит в простое или ему необходимо постоянно сверяться с документацией / гуглить, то это фулл интерн без доли реального опыта. И сразу есть понимание, что этот человек нам не подходит. Так как такие простые задачи должны быть на автомате, в голове. В таком случае ты вообще не теряешься от смены среды. Ты видел уже тысячи строк кода и тысячи своих написал ( да, это реалии современных джунов ) именно это и определяет чистый тхт редактор. Обобщаю: такой способ тестирования выходит немного за рамки решения конкретной задачи, а показывает как человек уверен в своем коде, и чувствует, вернее знает все тонкости тех или иных сущностей кода. Еще короче: это показывает, насколько человек опытен, и уверен в своем коде. Пишет и глазом не моргает - джун+ - мидл. Мешкается и допускает много мелких ошибок - интерн околоджун.
Круто. Было бы интересно посмотреть собеседование Junior C++
Круто. Спасибо. Критически мало собесов по С++ найти получается
Знак указателя относится к переменной, а не к типу. Так что счетчик тут далеко не указатель
Классный контент, делай ещё!:)
51:27 Здесь нужно иметь желание разобраться в нюансах C++ и потренироваться на своём проекте. Написать тесты. Запомнить тонкие моменты. Это не про написание shared pointer. Это про знание C++ и умение на нём писать работающий код. Простое чтение здесь вряд ли поможет. Нужно практиковаться и ловить ошибки. Нужно дебажить свой код на тестах, смотреть, где происходят проблемы и исправлять их. И так пока не научишься видеть все проблемы и писать работающий код.
14:50 Есть хорошее правило: все постфиксные унарные приоритетнее всех префиксных унарных, а все унарные приоритетнее всех бинарных.
Но в данном случае префиксный минус-минус решил бы все проблемы, да ещё и повысил бы читаемость.
24:15 Объект oth, конечно, константный, но меняется-то в нём не указатель, а разыменованное значение, которое не является константным даже для константного oth.
Написано, что инкрементируется указатель, но это собеседуемый не смог правильно написать, подразумевается, что инкрементироваться должно разыменованное значение.
Позволю себе немного покритиковать собеседующего.
А именно начало критики реализации метода класса сразу же после написанием собеседуемого последней его строчки, тут есть несколько проблем:
Во-перых само по себе обсуждение корректности отдельного метода не в контексте чисто языковых ошибок, а непосредственно логики класса - спорна, т.к. их работа де-факто завязана на общий сайд-эффект, которым являются состояния класса - о корректности методов полноценно можно говорить только после полной реализации их всех. Понятно, что всегда можно исходить из концепции, заранее предвидеть проблему или вовсе сказать, что это стандартная вещь и кандадат должен ее тупо знать, но если вы расчитываете, что человек реально должен что-то сам, своей головой, спроектировать в процессе интервью - рассчитывать, что он сходу реализует корректный метод без последующей итерации по остальным методам класса и анализа возможных проблем - странно.
Во-вторых у людей разный стиль написания кода и многим намного проще исходить из некоторого "костяка" решения постепенно рефакторя и дополировывая код и решая "граничные" случаи.
Я понимаю, что время ограничено, да и вы вполне могли воспринимать это как легитимную наводку к решению, но воспринимается это как моментальная критика того, что кандидат еще даже сам не пытался утвердить как правильное решение. В стрессовой ситуации собеседования это особенно болезненно и по кандидату это видно. Можно же хотя бы дождаться пока попытается перейти к следующему методу или хотя бы предложить вернуться к нему позже.
А в остальном - отличное интервью и спасибо за видео)
Здесь, скорее, задача оказалась не по уровню собеседуемого, то есть, явно сложнее, чем следовало бы.
Поэтому почти сразу возник цейтнот со всеми вытекающими, о которых вы пишете.
*(strong_counter)++; //wat? :)
Приоритет, кстати, тут легко определить, достаточно вспомнить классическое сишное копирование памяти: *a++ = *b++. Ну и... можно же ++*strong_counter.
Однако:
int* obj, strong_counter; // счётчик же - простой int :)
он простой да не простой он делится между всеми обьектами
Честно на интервью не натренирован и на нервах бы даже тут наверное накосячил, если бы дали внезапно. Но почему счетчик без std::atomic?
А как же кастомные делитеры. Без них не считается.
shared_int& operator=(shared_int&& oth) реализованный не верно.
Так че, взяли в итоге?
Если яндекс, то результат наверное не ясен. там же 4 интервью с разными людьми, потом еще отбор команд и тд тд
Куда его возьмут. Он примитивных вещей не понимает.
ничего не понимаю в плюсах, но это нормально, что лида гоняют по лайвкодингу?
В данном случае вы не поняли, кто кого гоняет.
Это Lead гоняет Junior'а, а не наоборот.
Понял, прошу прощения @@billjohnes9380
Какой return в деструкторе? В объяве счетчика звезду забыл. Не надо в строку объявлять, если не можешь. Да и вклассе это никчему.
Получил мощнейшие впечатления!
Это -- особое умение, видеть абсолютную жесть и даже глазом не моргнуть!
Хотя во второй половине собеседования во времена особой жести во взгляде замечалось нечто вроде либо лёгкого ужаса, либо офигения от увиденного.
Жаль, что так вышло, джуну попроще что-то лучше было дать, с unique_ptr он бы справился явно лучше.
Всё собеседование, кстати, прошло при неправильно объявленном strong_counter, который при таком объявлении -- типа int.
Что, кстати, дополнительно подтверждает, что попался именно джун.
Тип возвращаемого значения из перемещающего operator = тоже неверен.
Какую функцию несут скобки в выражениях, где он пытается инкрементировать strong_counter?
За всё время собеседования собеседуемому и в голову не пришло, что запись выглядит как-то слегка не так.
Ещё есть моменты, тайминг себе записал, может, потом прокомментирую.
Собеседование слишком простое и слабое для яндекса, на мое удивление
Собеседование в Яндекс - это литкод x3
@@ozimandias1858 да, там есть требования к знанию алгоритмов. Но и помимо того много спрашивают об особенностях языка, компилятора и т.д.. Тут же очень поверхностно, что даже на джуна не тянет
его бедного по ходу заставили пройти этот собес
В 2к24 кто-то еще учит эту кабаллу? 😅
Ты про с++, или про изучение нюансов shared pointer
А как быть, если ты хочешь, например, разрабатывать игры на известном игровом движке (там C++ и блюпринты)? Причин может быть много разных.
@@vilture5706 это не нюансы shared pointer, это нюансы конструктора копирования, перемещения. Умение писать работающий код на C++. Это точно не про нюансы shared pointer.
@@wsxpocxeafxчтобы сделать игру на анрил тебе не нужно знать программирование вообще. Примеров куча, та же игра с поездом - только блюпринты. Если ты хочешь сделать большую игру с офигенной графикой, то нужна команда и бюджет, там плюсы нужны только при работе с графикой, вернее 1 плюсовик. Если вдруг что-то ещё кроме работы с графикой и памятью понадобится на плюсах написать, то можно конвертером с Шарпа на плюсы воспользоваться. Просто только в определенных случаях мощь плюсов понадобиться, в остальных это просто стрельба из пушки по воробьям.
Кому то же надо интерператор питона поддерживать, чтобы такие как ты на крутых скриптовых языках кодили
Откуда такая любовь к этим онлайн редакторам кода? Там что удобно писать код или он полностью повторяет опыт разработки на реальной работе? Сомневаюсь.
Он показывает как человек пишет код без помощи анализатора в реальном времени. В идеешках или других платформах подсвечиваются не только синтаксические ошибки, но и логические. Самый банальным пример, при использовании алгоритмов из stl, редактор укажет на ошибку в духе : переданы итераторы на разные контейнеры, или один итератор конст, а другой не конст.
В целом показывает уровень внимательности человека. Так сказать 2 в 1 проверка
@@alisii442 если ты давно работаешь с IDE, специально не тренировался, ты в любом случае будешь теряться. А второй кандидат придёт, который просто готовился. Не факт, что второй будет лучше в среднем. Пусть IDE помогает, на работе же в IDE будет писать.
@@alisii442 ничего это не показывает. Если дать задачу и он её сделает, вот это показывает уровень всего. Как он решил задачу, что использовал - его дело. А давай в прямом смысле в блокноте будут все кандидаты код писать и вручную командами вызывать компиляцию кода. Без гугления. Это покажет уровень памяти и пробовал ли человек работать с компилятором вручную 🤣
@@alisii442 написание кода без IDE и без заглядывания в справку заранее провальная идея. В любом случае нужно куда-то подсматривать. Весь SDK, всю стандартную библиотеку не запомнить наизусть. И хочется видеть результат работы написаного кода, а не писать нерабочий код, который непонятно вообще работает или нет. И даже ведущий собеседование может неправильно понять написанное в онлайн редакторе, проверить же нельзя.
@@wsxpocxeafx совершенно с тобой не согласен. На собеседованиях цель интервьюера не просто увидеть, что кандидат способен из точки А прийти к Б, а то как он это делает. Если ты обращал внимание, то в реальных собесах лайфкодинг всегда идет после теории, а там все отличие и появляется. Я по одной такой секции могу определить сколько реального опыта у человека. Если он сидит в простое или ему необходимо постоянно сверяться с документацией / гуглить, то это фулл интерн без доли реального опыта. И сразу есть понимание, что этот человек нам не подходит. Так как такие простые задачи должны быть на автомате, в голове. В таком случае ты вообще не теряешься от смены среды. Ты видел уже тысячи строк кода и тысячи своих написал ( да, это реалии современных джунов ) именно это и определяет чистый тхт редактор.
Обобщаю: такой способ тестирования выходит немного за рамки решения конкретной задачи, а показывает как человек уверен в своем коде, и чувствует, вернее знает все тонкости тех или иных сущностей кода.
Еще короче: это показывает, насколько человек опытен, и уверен в своем коде. Пишет и глазом не моргает - джун+ - мидл. Мешкается и допускает много мелких ошибок - интерн околоджун.
Слабенький чувачок