Потренируйтесь проходить собеседования с разработчиками из ведущих компаний и получите подробный отзыв о том, на какую зарплату и грейд вы можете расчитывать, или над чем вам еще стоит поработать.
Я не GOшник, но во 2 задаче кандидат упомянул, что под переменные для if/for выделяются отдельные области памяти и эта память живёт только в блоке if/for. Раз мы в second кладем ссылки на v и после цикла область памяти для v умрёт, откуда тогда в println возьмутся значения?
Сколько не прорешивай литкод, фактор стресса никуда не денешь. Когда собеседующий каждые 30 сек. тебя торопит, просит рассуждать вслух при написании кода. Так можно поплыть на элементарных вещах. Вот бы на экз. по матану нужно было решать все задачи под тотальным надзором препода, я думаю процент несдавших увеличился бы напорядок
Видно что человек очень суетился и волновался. Против него сильно играло то, что на вопрос "Понял?" он говорил "Да", а потом на следующем шаге путался и начинал суету. А еще заметил, что интервьюер пытался подсказать ориентируясь на ответы собеседника "что тот все понимает", но похоже еще больше его сбивал т.к. у собеседника это любимая фраза "да да...., а точно..., понял понял...". Пожалуй это больше всего портило впечатление от собеседования. В любом случае собеседуемый молодец! Нужно тренироваться проходить собесы и решать задачки практически. Не страшно ничего не уметь! Страшно так ничему и не научиться!
Че за бред? Я думал на мид+ собесе просить будут написать сервис по тз, а тут алгоритмы, так еще и сложность никакая...первая задача это уровень даде не стажера
Это какой-то мазахизм заставить человека писать в ублюдском редакторе без нормальной подсветку и тыкать на каждую очепятку. Бог ж дал Goland + Code With Me
51:27 Здесь нужно иметь желание разобраться в нюансах C++ и потренироваться на своём проекте. Написать тесты. Запомнить тонкие моменты. Это не про написание shared pointer. Это про знание C++ и умение на нём писать работающий код. Простое чтение здесь вряд ли поможет. Нужно практиковаться и ловить ошибки. Нужно дебажить свой код на тестах, смотреть, где происходят проблемы и исправлять их. И так пока не научишься видеть все проблемы и писать работающий код.
Откуда такая любовь к этим онлайн редакторам кода? Там что удобно писать код или он полностью повторяет опыт разработки на реальной работе? Сомневаюсь.
контекст нужно отменять, когда один из запросов вернул ответ.. или notFound. Иначе другие запросы будут дальше идти. И можно было через sync.Once сделать обработку
Сколько смотрю собесы по сисдизу, еще ни один человек в тайминг 50 минут не уложился, даже если мок-интервью внутри одной компании. И по rps постоянно невнятки. Кто говорит DAU, кто DAU/86400. Мало кто задает вопрос про распределение внутри дня. Я так и не понял, как правильно.
Если честно, то не совсем понятно, чем так плоха хэш функция для обеспечения уникальности ссылки в шардах. Допустим у нас N шардов, и есть хэш функция, которая на любую шорт ссылку возвращает число от 0 до N - 1, т.о. определяя индекс шарда. На POST запросе мы рандомно генерим ссылку, считаем от нее хэш. Идем в нужный шард и проверяем занята ли ссылка. Кажется, что при такой длине шорт ссылки (8 символов) вероятность коллизий крайне мала (62^8 возможных вариантов). Если все же сгенерили случайно уже используемую ссылку, штош, придется еще раз сгенерить, пока не сгенерим свободную. Таким видится алгоритм. Возможно я что-то упускаю или неправильно понял проблему.
Почему в задаче на замыкания при выводе будут обращаться к памяти b102? Что происходит с памятью, когда программа выходит из ее области видимости? Понятно, что сама физическая память никуда не исчезнет, и second как ссылалась, так и будет ссылаться на эту ячейку, пока новое значение не присвоят. Но разве нет такого, что если память была очищена, то в результате ссылаться будет не на что, она будет помечена, как нулевой указатель. Или она все-таки будет доставать мусор, который лежит по этому адресу?
там просто эскейп анализ при выходе из функции производится и если он видит, что локальный указатель кому-то нужен, например, его возвращают из функции, то он его со стека в хип переложит и ничего не перетрется)
Правило хорошего тона выяснять знает ли кандидат "что это за проблема" (На 9:50), нужно чтобы он проговорил проблему и решение. Если кандидат плавает - рассказывать матчасть. Заодно зрители посмотрят и научатся. Я вот го не знаю и что за проблема там для меня так и осталось секретом.
Люди волнуются. Обычные задачи решаются при наличии текстового описания. Здесь тебе объясняют на словах что-то и вперед. Конечно, кандидат сам должен об этом заботиться. По хорошему, ему стоило основные тезисы задачи записать текстом, т.к. по ходу выполнения можно заблудиться. Я не знаю, на что тут расчет. Что человек за полчаса-час напишет надежный код под давлением? Ну разве что такое.
А не стоит ли писать в канал основываясь на контексте как сигнал? Если в канал уже была запись то срабатывает контекст отмены через селект и в канал не пишем?
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? За всё время собеседования собеседуемому и в голову не пришло, что запись выглядит как-то слегка не так. Ещё есть моменты, тайминг себе записал, может, потом прокомментирую.
@@vilture5706 это не нюансы shared pointer, это нюансы конструктора копирования, перемещения. Умение писать работающий код на C++. Это точно не про нюансы shared pointer.
"из яндекса". сразу вспомнился анекдот: - иван. я, конечно, не верю, но слухи идут. короче, твоя жена чуть ли не со всем городом переспала - пффф... тоже мне город
Ошибка во второй задаче 33 строка. for store[right] > 1. Пример строки, которая обработается с ошибкой: abcabbcd. Когда left будет 2, а right 5, нужно будет left довести до right, иначе две подряд идущие b создадут ошибку.
Позволю себе немного покритиковать собеседующего. А именно начало критики реализации метода класса сразу же после написанием собеседуемого последней его строчки, тут есть несколько проблем: Во-перых само по себе обсуждение корректности отдельного метода не в контексте чисто языковых ошибок, а непосредственно логики класса - спорна, т.к. их работа де-факто завязана на общий сайд-эффект, которым являются состояния класса - о корректности методов полноценно можно говорить только после полной реализации их всех. Понятно, что всегда можно исходить из концепции, заранее предвидеть проблему или вовсе сказать, что это стандартная вещь и кандадат должен ее тупо знать, но если вы расчитываете, что человек реально должен что-то сам, своей головой, спроектировать в процессе интервью - рассчитывать, что он сходу реализует корректный метод без последующей итерации по остальным методам класса и анализа возможных проблем - странно. Во-вторых у людей разный стиль написания кода и многим намного проще исходить из некоторого "костяка" решения постепенно рефакторя и дополировывая код и решая "граничные" случаи. Я понимаю, что время ограничено, да и вы вполне могли воспринимать это как легитимную наводку к решению, но воспринимается это как моментальная критика того, что кандидат еще даже сам не пытался утвердить как правильное решение. В стрессовой ситуации собеседования это особенно болезненно и по кандидату это видно. Можно же хотя бы дождаться пока попытается перейти к следующему методу или хотя бы предложить вернуться к нему позже. А в остальном - отличное интервью и спасибо за видео)
Здесь, скорее, задача оказалась не по уровню собеседуемого, то есть, явно сложнее, чем следовало бы. Поэтому почти сразу возник цейтнот со всеми вытекающими, о которых вы пишете.
