Собеседование Junior C++

Всем привет!
Провели тренировочное собеседование с Евгением на позицию
Junior C++ Developer.
Приятного просмотра!
POD-типы: learn.microsoft.com/en-us/cpp...
Правило 3-х или 5-ти: ru.wikipedia.org/wiki/%D0%9F%...
Таймкоды:
00:00 Вступление. Рассказ о себе
01:23 ООП
06:05 Виды полиморфизма
07:32 Наследование
09:55 protected наследование
16:58 Задача: максимальный элемент в массиве.
25:07 Зачем нужны std алгоритмы
29:12 Исключение в деструкторе
37:39 POD типы
42:16 Размер пустого класса
44:03 Умные указатели
51:25 Выводы, заключение

[@bartonby-3976]

Можешь сделать видео на тему: чем занимается junior c++, какие его задачи и типичные задания для джуна. Может с примерами из своего опыта

[@user-ji5vu2ln1j]

Спасибо большое Дмитрию и Евгению за видео!) Евгений большой молодец!!!

[@user-yx5nj4fw2x]

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

[@ha1578]

Огромное спасибо, то что нужно сейчас. Не останавливайся. Ты главное делай, хоть иногда...)

[@user-il5ly5iv6z]

Спасибо за контент

[@wladislavj1053]

крутая тема контекта) продолжай и дальше) спасибо)

[@user-nd4sl1lp9b]

Спасибо за очень интересный диалог.Ещё бы несколько раз бы пересмотрел!

[@drowndream7761]

Спасибо тебе за все что ты делашь, это очень полезный контент как для начинающего разработчика. Я сам уже давно ищу работу на позицию Junior C++ и был на многих собеседованиях. Это очень полезные видео, как для меня так точно. Жду в будущем стримов по разбору каких-нибудь легких и сложных задач с реализацией самой простой семантической сложности задач. Это было бы очень полезно.

[@user-bq7zb2oj2m]

На какую зп рассчитываешь?

[@drowndream7761]

@@user-bq7zb2oj2m 30-50к. Но на самом деле хоть бесплатно готов работать, очень нужен опыт работы для дальнейшей более песпективной зарплаты, но собеседования на которые я ходил предлагали 30-40 к

[@user-de8fm3hx5i]

@@drowndream7761 ну как? нашёл ?

[@user-db2mk5dq3k]

Как успехи?

[@nirvandgupshob5476]

смог?

[@nikitafamily5341]

Спасибо обоим! Сложное интервью было конечно… Молодцы. Хорошо отвечал и вопросы хорошие 👍 Отличная идея с добавлением статей в описание, очень упрощает поиск!

[@user-yr9rq7we2n]

Я изучал С++ 15 лет назад и почти все забыл, так как перешел на PHP, но все равно посмотреть это видео было интересно ))

[@immickful]

28:34 - шта? Велосипед, реализующий поиск максимального элемента, будет компактнее max_element?

[@fander8929]

Жду ещё роликов

[@user-xm5zl9up4r]

Спасибо

[@evgenydarichev5683]

36:40 Догадался чуть раньше, но ситуации "что имел в виду интервьювер/экзаменатор" всё же часто вводят в ступор. Общий ответ: "создать вторую исключающую ситуацию" порождает бесчисленное множество правильных, но частных ответов. Так можно перебрать тысячи вариантов, все из которых будут правильными, но не предполагаемыми второй стороной. Помню, давным-давно сдавал медицину, как дополнительный вопрос получил "признаки желтухи", из которых важнейшим экзаменатор посчитал цвет дерьма и поставил 4.

[@ambushedraccoon6408]

Ну, бывают такие ситуации, мне же не исключать какой-то вопрос только потому, что на него может быть несколько вариантов ответа. Ну и четверки я тут никому не ставлю) Был отличный уровень продемонстрирован.

[@lonchakovav]

9:21 Вы не правы - все public и protected поля базового класса, от которого наследуются через private, становятся private в дочернем классе, и доступны в его методах. P.S. Много полезного узнал из ваших роликов, спасибо.

[@ambushedraccoon6408]

Здравствуйте! Все верно по поводу наследования, спасибо за информацию. Спасибо за отзыв)

[@victorkrasnov5576]

Про POD типы спросите сеньоров, удивитесь :)

[@user-cb8nc5to4z]

9:22 Какая-то путаница. Внутри методов дочернего класса будут видны поля и методы базового, но только public и protected. Т.е. private - наследование сделало все private из базового класса, но только для пользователя дочернего класса. Т.е. снаружи их не будет не видно. Самому дочернему классу будет видно все, что не в private-секции базового. Ну иначе тогда вообще смысла нет в таком наследовании) 16:20 Я понимаю, что собеседующий, видимо, хотел услышать про friend. Но кажется, что более логично организовать публичный конструктор для Child и юзать уже тип Child в клиентском коде. Да, чтобы обойтись без ошибки компиляции приведения типов, надо создавать объект типа Child, а не B. Просто по сути как-то и не логично пытаться достучаться до класса B, если мы его приватим. Здесь приватим, здесь сразу же френдим. 41:21 Спасибо. Освежил в памяти POD-типы. 50:22 По make_shared докину еще пять копеек, кому интересно. Можно почитать Мейерса про это дело: "Эффективный и современный С++". Где он рассказывает, почему make_shared не только хорош, но и плох. А именно своим этим эффектом по выделению памяти единым куском он по сути будет удерживать всю память от освобождения до уничтожения всех weak-поинтеров. Как говорится, все недостатки - это логическое продолжение достоинств) А в целом огромное спасибо за ролик, за потраченные силы. Недавно начал посматривать ваш канал, многому учусь) Очень познавательно и интересно. Парни, это очень важная работа и крайне полезный контент для специалистов и начинающих. Искренне желаю всяческих успехов авторам канала. Евгений - молодец. Уверен, что все у него сложится, как надо.

[@victorkrasnov5576]

weak пойнтеры - это ж как раз для того чтобы shared пойнтер не держал память. По определению.

[@user-cb8nc5to4z]

@@victorkrasnov5576 ​ Это по какому-такому определению?) У нас тут одно определение - это плюсовый стандарт) Нет, weak-поинтер не для этого. А для того, чтобы позволить объекту под шаредом быть уничтоженным (вызов деструктора), когда все шареды выйдут из области видимости, он для этого. Вообще, Мейерса исключительно рекомендую.

[@billjohnes9380]

> Просто по сути как-то и не логично пытаться достучаться до класса B, если мы его приватим. Здесь приватим, здесь сразу же френдим. Для одной функции же только friend'им, не для всех. > А именно своим этим эффектом по выделению памяти единым куском он по сути будет удерживать всю память от освобождения до уничтожения всех weak-поинтеров. Иногда лучше самому выяснять такие вещи с помощью экспериментов, тогда будет понятно, что когда выгодно. Если поэкспериментировать с make_shared для классов различного размера и посмотреть, что происходит, станет понятнее, о чём я. Подавляющее большинство не проходили этот путь, поэтому принимают, в общем случае, неверный ответ, сами не понимая деталей, одну из которых вы упомянули.

[@phonkabuser3985]

виндертон решил реально заняться программированием

[@nullpointer4200]

Предлагаю дополнительно вводить 1-2 задачки с литкода

[@JingoBo]

Задача с поиском максимума описана не полностью, тут важно понимать - это ошибка использования или не корректные извне данные. В первом случае должен быть assert на размер массива, во втором случае должна быть проверка в вызывающем коде

[@Nandarion]

Собеседуемый junior: "знаю 11, 14 стандарт 100%, 17й отчасти... всякие новые фишки по типу any..." Сеньоры в крупной корпорации работующие с древним проектом, куда постучался 11й стандарт, но добрая половина кода использует malloc(), а треть new: "Oo", "Нифига себе, круто" Теорию Евгений ответил на отлично, даже больше чем на уровень junior. Если в компании будут спрашивать теорию по плюсам, то этот этап он пройдет. Хотя всегда остается рандом, из-за того, что соискатель случайно не угадает, какой ответ от него хотят слышать, телепатия ведь не всем дана. Только вот спрашивать скорее будут не только теорию по плюсам, а еще и по смежным технологиям. Ну какой смысл продолжать спрашивать по C++, когда понятно что человек выучил, знает, и при том есть еще десяток инструментов и технологий с которыми команда работает. Естественно попытаться узнать, работал ли человек с ними, может он на подобном стеке собаку сьел, и нужно срочно его нанимать, не любой ценой конечно, но нужно.

[@mrbibis7229]

а я вот очень скептически отношусь к людям, которые будут утверждать что знают хоть какой-то стандарт плюсов на 100%, уж тем более 11-й и будучи Джуном. Возможно имелось в виду STL библиотека дополняемая в этих стандартах, но все-равно это странно звучит...

[@Nandarion]

@@mrbibis7229 Знание стандарта, это как знание теории - это хорошо. Человек, знающий теорию легче осваивает практику, да и не тратит время на теорию.

[@mrbibis7229]

@@Nandarion знание стандарта новичку точно не нужно, это оверзубреш какой-то. Зачем ему знать новые виды UB в 23 стандарте, например?

[@s.g.7213]

В случае выброса исключения из деструктора произойдет утечка памяти, в случае удаления динамического объекта. Исключение вызовет разрыв цепи действий, которые нельзя разрывать. Вызов деструктора и освобождение памяти , если в деструкторе вылетит исключение, память останется не освобождённой. По этому всё деструкторы по умолчанию noexcept

[@billjohnes9380]

Это случится только для неисправного компилятора, то есть, не соответствующего стандарту. #include #include #include #include struct S { S() { std::cout

[@s.g.7213]

@@billjohnes9380 Круто. Но суть в том что тезис правдив, ибо имя им легион тех кто пишет по MS. GCC тоже не ясно с какой версии исправен. В ходу можно и 4 встретить ещё. Иными словами , не дёргай смерть за усы, и не делай исключений в деструкторах , тем более что язык на это явно намекает, что так делать не нужно.

[@billjohnes9380]

@@s.g.7213 Да пусть хоть вся Вселенная пишет, используя неисправный компилятор, -- это имеет строго нулевое значение. Тем более, что теперь есть исправная альтернатива (а раньше не было). Язык не намекает ни на какие смертельные усы, язык -- это стандарт, который ни на что не намекает. Более того, предоставляет средства для определения того, когда исключение безопасно выбросить, а когда -- нет. Стандарт и не может намекать, ибо программист -- царь и бог, и только он решает, что выбрать и как поступить. Возможно, вы слишком долго находились под властью Windows, и поэтому считаете нормальным, когда вам указывают, что выбрать. Это -- не нормально: только вы должны решать, и никто не может вас ограничивать в свободе выбора. Стандарт же задаёт рамки (описывает модель), в пределах которых вы можете решать.

[@s.g.7213]

@@billjohnes9380 Я никогда не писал под windows и более того никогда не имел его на домашнем компе. Тут мы приходим к философской теме, мы программируем для получения результата, то есть исправно работающей 24/7 программы, пусть даже собранной неисправным компилятором, или мы программируем ради программирования. В коммерческом коде не прокатит отмазка " у меня всё по стандарту, у вас компилятор неправильный" , никто не будет под разработчика менять компилятор, тем более в разработке встраиваемых решений . Мнение, что программист "царь и бог" ошибочно и применимо только в домашних проектах, "царь и бог" это coding standart. Сделаешь хитрый и интересный баг, найдём всей командой , и получим опыт. Навортишь лапшу с метками и исключениями в деструкторах , мотивируя что ты "царь и бог" , которая "внезапно" не всегда работает как ты задумал, получишь выговор , не поймешь , пойдешь искать работу.

[@billjohnes9380]

​@@s.g.7213 Значит, что-то другое вместо Windows оказало на вас аналогичное влияние. Если под Windows вы не программируете, то почти наверняка используете gcc или нечто производное. В крайнем случае -- clang и очень маловероятно, что Intel'овский icpc. Если не используете Intel'овский компилятор, то проблем в этом месте у вас не должно быть: gcc и clang в это месте исправны. Разве можно быть уверенным в результате, полученном путём использования неисправного компилятора? Если кто-то не будет менять компилятор при наличии веских причин его поменять, -- зачем с этим кем-то работать? Зачем плодить bug'и и "лапшу", да ещё и с какими-то метками? Coding standard -- вещь изменчивая, а стандарт языка определённой версии -- незыблемая, причём ещё и являющаяся единственным первоисточником. Над стандартом языка в течение многих лет работают сотни людей, весьма искушённых в C++, а кем пишутся coding standard'ы? Тот же Google так опростоволосился со своим coding standard'ом, запретив использовать исключения в C++, что это ещё не каждый так сумеет. Страх отступать от "проверенных решений" по причине того, что можно "нарваться", может быть вызван недостаточно глубоким знанием языка. Согласен, первые 10-15 лет с C++ трудно, и всё может работать не так как ожидается, но потом с этим становится уже явно легче. И в дальнейшем понимание, что новые решения следует сначала очень глубоко прорабатывать, прежде чем использовать, формируется автоматически. Апелляции к интересам бизнеса бессмысленны, это не имеет отношения ни к языку, ни к программированию. Бизнес способен уничтожить всё, к чему прикасается, ничего удивительного здесь нет. Кстати, какое у вас отношение к выбросу исключения в конструкторе применительно к случаю динамического массива? То есть, через new[] выделяется массив из N объектов, и все объекты, кроме последнего, конструируются успешно. А при конструировании последнего объекта из конструктора выбрасывается исключение. Вы тоже думаете, что здесь будет утечка? Если вернуться к деструкторам и рассмотреть следующий случай: имеется базовый класс A и производный B, который унаследован от A. Где-то как-то был создан экземпляр класса B и в данный момент он уничтожается, что приводит к вызову деструкторов, сначала класса B, а затем класса A. Если в деструкторе класса B выбрасывается исключение, -- вы считаете, что здесь тоже произойдёт разрыв цепи действий, и деструктор A не будет вызван?

[@user-sm1pi4hj2o]

Здравствуйте, не могу дождаться стрима, хочу задать вопрос. Вы говорили, что при трудоустройстве в Европе, позарез нужен диплом, так вот вопрос, а насколько котируются дипломы Среднего Профессионального Образования (колледжи и т.п., не вышка)?

[@ambushedraccoon6408]

Здравствуйте. Сложный вопрос. У каждой страны свои законы, квоты и прочее. Надо изучать страны отдельно.

[@user-tr9rx9zp2o]

Наши дипломы не котируются.

[@KonovDS]

Сколько раз в реальном коде Вы видели protected наследование? И на 17:57 - парень сказал верно, в данном случае (как и для всех контейнеров стандартной библиотеки) будет итератор. POD на джуна 😂

[@yakobssaghatelyan1812]

Позавите на собес по плюсам пж, пж, пж, пж)

[@user-st3fm6bs5j]

Не видно нихера, что написано в этом CodeShare (((

[@angra_]

видео долго стояло на паузе, перед тем как начал смотреть и я думал что пареньку лет 16, а потом он начал говорить

[@dmitrydemis8981]

16:48. Здравствуйте, а почему у Child нет круглых скобок? B* b = new Child;

[@ambushedraccoon6408]

Это допустимый синтаксис, если конструктор по умолчанию или без параметров. Такой синтаксический сахар.

[@antonkulikov6726]

22:46 лучше вернуть std::optional и возвращать в случае отстутствия nullopt. И очень странно,что не рассматривается никак concurrency хотя бы базовые понятия, проблемы многопоточный синхронизации( deadlock,datarace,race condition, starvation, raii, conditional variable ). А так автор молодец,как и собеседуемый. Интересно собеседование middle c++)

[@Nandarion]

Многопоток это уже выше чем уровень джуна, хотя отвечал настолько хорошо что можно было и спросить.

[@user-ye1xy8sl6c]

А смотреть в шпоры это норм на собеседовании? Если все слепые или разрешают такое то это гуд

[@aidanhouk]

Это норм

[@dmitriibannikovasx]

Дмитрий на оксимирона похож)

[@Vascular11]

)) пошел учить html)).

[@user-jr1qc5je6f]

Написал python на html

[@mariyanban]

я думал ему 15

[@TurboGamasek228]

а прошел он нет?

[@ZzzzZ-ky7hu]

ну чувак подкован

[@TurboGamasek228]

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

[@GOEchAWI]

ему 15 лет?

[@ambushedraccoon6408]

Это имеет какое-то значение? У меня на канале нет возрастного ограничения, любой человек может попробовать пройти собеседование, хоть в 5 лет, хоть в 105. Евгению 21 год и он показал отличный результат.

[@Sergey-dd4yl]

Какой же пассивно агрессивный собеседующий. Надеюсь он не проводит секции, это ужасно

[@FULLlouich]

вы серьёзно?

[@user-ih4ne2zx2i]

Это либо сарказм, либо вы не встречались с агрессивными собеседующими.

[@nikitafamily5341]

Он приятный и понимающий. Посмотри его другие собеседования, здесь может так кажется, я тоже заметил немного напряжения в нём, но я бы не назвал это пассивно-агрессивным поведением, у него могут быть свои трудности 😣. Он не грубил, был вежлив. Где-то подводил. Это очень профессионально. Особенно учитывая, что волнуются оба, то ведёт себя по человечески. Лично у меня он вызывает уважение. Приятно посмотреть. Я недавно проходил собеседование так там HR пассивно-агрессивно шутил, почти под каждым моим высказыванием. А тимлид вообще с надменным выражением лица сидел, а потом пошутил с улыбочкой на лице «ждите повестку» Может быть у каждого своё понимание «пассивной-агрессии». Но как по мне он очень хорош

[@mrbibis7229]

хз почему тебе так показалось, мб у него просто лицо серьезное и тебе так показалось. Вообще без духоты собесы у него

[@VoiCedml]

"знаю 11, 14 стандарт 100%" какой самоуверенный кандидат 9:18 Он же говорит про публичные и защищенные поля базового класса, при приватном наследовании у дочернего класса конечно же будет доступ к этим полям. Приватными они станут на уровне дочернего класса. В противном случае в таком наследовании не было бы никакого смысла, ведь дочерний класс не смог бы даже конструктор своего родителя вызвать. 17:34 ̶К̶а̶к̶о̶й̶ ̶c̶o̶n̶s̶t̶.̶ ̶Г̶р̶у̶б̶а̶я̶ ̶о̶ш̶и̶б̶к̶а̶.̶ ̶К̶о̶д̶ ̶н̶е̶ ̶с̶к̶о̶м̶п̶и̶л̶и̶р̶у̶е̶т̶с̶я̶. Все нормально. 32:10 Деление на ноль не бросает исключение на уровне языка.

[@iSammax]

С чего бы это const на 17:34 не скомпилируется?

[@VoiCedml]

Да, он все же скомпилируется. Мне представлялось, что range-for в данном случае развернется в такую конструкцию const auto& __begin = arr.begin() ; const auto& __end = arr.end() ; for ( ; __begin != __end; ++__begin) { const auto& it = *__begin; //loop-statement } Что очевидно не скомпилировалось бы, но с const для __begin и __end я погорячился, их не будет у них все же. Тем не менее практичней использовать запись for(auto&& it : arr)

[@decltruft2882]

@@VoiCedml сигнатура функции подразумевает, что внутри её теле рассматриваемый вектор будет lvalue, да и передают в нее аргумент через const lvalue reference

[@sashabroslavskiy7904]

Почему Карпов собеседует джуниоров?)

[@decltruft2882]

Или все таки Оксимирон?

[@flint2159]

Из садика подключился?

[@GOEchAWI]

аххахах

[@astkh4381]

🤡🤡🤡🤡🤡🤡

[@user-xm5mx1xn8r]

Можно конечно написать свои "велосипеды" и использовать их вместо стандартных алгоритмов в случае если нужно много поточное выполнение к примеру того же поиска. Гораздо быстрее будет написать функцию обертку которая внутри себя создаст несколько потоков и разобьет тот же массив на к примеру на пять потоков, найдет в них максимум (к примеру), и из этих пяти значений найти также максимум и вернуть. Это так на вскидку для чего можно писать "велосипеды". так сказать многопоточный std::find или std::min