Чел(собеседующий) просто выступает в роли экзаменатора. Выглядит так будто цель лишь бы поспрашивать, а не найти хорошего сотрудника. Мне на собеседовании хватает 5-7 ответов чтобы понять уровень кандидата и его желание развиваться.
По-моему, слишком много теоретических вопросов и мало тех ,которые показали бы реальный опыт кандидатов. Я когда проводил собеседования, предпочитал обратный подход. Так можно взять ботана или гуглильщика.
3 собес: интервьюер приебался что получение элемента по индексу долго работает хотя это константа и это быстро. Не факт что перезапись переменной для хранения предыдущего значения будет быстрее чем за константу. Надо было спросить у него че замеры есть? Что за идиоты собесят аж тошнит от таких. Да и в принципе вторая задача в 3 собесе была идиотская))
собеседующего понять можно. Ему деньги платят, сиди и задавай вопросы. Потом тебе за это время заплатят. Но лично мое мнение, что так глубоко спрашивать не надо. Лучше наверно понять какой у человека тип мышления, сможет ли он разобраться в чем-то, если срочно нужно. А тут да, как на экзамен пришел и тебе вместо 3 вопросов попался билет, где все 150. В любом случае, ты приходя в компанию, в первый день не будешь лезть на прод и что-то менять. Недельку тебе дадут осмотреться и если с чем-то не знаком, как раз будет время ознакомиться
На счёт poetry не соглашусь - pip сейчас сам хорошо справляется с выбором нужной версии библиотеки. Основная и главная фишка poetry, pipenv, pdm и прочих подобных пакетных меннаджеров - это избегание ситуации, когда какой-нибудь малолетний дебил в твою зависимость версии берёт и форспушит. lock-file - это то, ради чего стоит использовать эти штуки. И по этому, когда в какой-то момент на проде у тебя не собирается пакет из-за проблем с зависимостями - не поленись и посмотри что там отъебнуло, вместо удаления и создания заново локфайла, анон!
Со всем уважением, но как по мне, так все заданные вопросы должен знать мидл. С сеньором стоит разговаривать на более фундаментальные темы или про интересные фишки.
Автор красава. Судя по интонации интервьюров - токсичный климат в комманде. Не особо хочется им этим всем заниматься и новых людей в комманду набирать. Ну раз уж начальство из-под палки заставило то что поделать....
Я уже кидал год назад задачку от Сбера, привожу один из ответов, который на данный момент не был описан. "# Задача: найти 1 уникальное значение, дубликатов всегда по 2: values = [1, 1, 2, 2, 3, 3, 4, 5, 5, 6, 6]" Как многие догадались, можно и через dict, counter, дополнительные структурки для временного хранения (в тот же список добавлять элемент, если его в списке нет, убирать если есть), и всё идёт к вопросу алгоритмической сложности. Сам виноват с условием, что не указал про элементы - исключительно цифры (со строками не сработает) Один из ответов - использовать xor (^, крышечку): values = [1, 1, 2, 2, 3, 3, 4, 5, 5, 6, 6] def find_unique(values: list) -> int: result = 0 for elem in values: result = result ^ elem return result print(find_unique(values)) Прикол данного решения заключается в том, что написав такой ответ можно показать себя "шибко умным" в контексте собеса на определённую должность, и из-за этого не пройти, т.к. написанный вами код должен понимать другой разработчик, а не все вспомнят про XOR. Так что необходимо будет хотя бы обозначить этот момент при прохождении интервью
@@python_interview если нужны такие интервью, можем слелать колл, думаю ответы будут хорошего качества. Посмотрим докуда можно планку повысить. Я senior, пишу 15+ лет
@@python_interview гоу к вам приду на собес, чисто для контента. обещаю качественные ответы, хочу посмотреть до каких рамок можно себя толкнуть. Senior Python Engineer, 15+ опыта
не смотрел все, тыкнул случайно, на 1:01:00 . ну как сказать в чем проблема? видно, что спрашивающие сами несильно дотягивают до уровня сеньоров ибо в этой шаблонке куча проблем и намеренный мистайпинг, это малая часть этих проблем. там с ООП все очень плохо, зачем-то передается структура данных со свойствами, которая внутри размазывается на публичные поля (что создает потенциально сильную связность, если у вас прям логика завязана на эти данные ну так запихните их в класс, как это стандартно делается в питоне). класс Dog без особых на то причин нарушает интерфейс публичный Animal добавляя новое свойство , при этом нигде не описывается, что такое новое поведение добавлено, аля какое-нибуль breedable . Вершина ужаса это класс Коровы, которая вообще ничего не делает только добавляет публичные методы несовместимые с интерфейсом (базовым классом). т.е. написана ниочемная логика, а уже поломано поведение т.о. что придется на каждом участке программы писать кучу проверок, что за класс, и что он умеет. подобный код сразу в помойку. совет новичкам - когда пишете сразу думайте о двух вещах - как вы это тестировать будете (пускай даже гипотетически) и как вы этим пользоваться будете в разичных сценариях программы. данным кодом пользоваться нельзя, тут ООП (наследование) не помогает , а делает все только хуже, ибо написано криво
Обратная связь от меня, раз уж вам компания ничего не дала :) 2. 01:05 Плаваете в поведении стандартных методов, но имхо, это не то, что должно от зубов отскакивать 3. 02:31 Ошибки. Интервьювер рассказал про обе. 4. 05:00 Объяснение с фактическими ошибками, без указания на ключевые отличия разных моделей выполнения 6. 08:21 Второй запрос не заработает, если там просто айдишник на имя заменить 9. 13:16 Мне кажется интервьювер дал задачу не на архитектуру, а на общий проблем солвинг и хотел узнать как ты бы подошёл к решению, не уверен мне послышалось или нет, но вроде он упомянул SQL, возможно он хотел узнать, как бы ты подошёл к отладке и оптимизации запроса. В целом я думаю норм, я бы взял, но даю моменты для развития: - Пробежаться ещё раз по Лутцу, чтобы знать как работают условные extend / and и т.д. - Подтянуть asyncio, можно написать свой реактор на генераторах например, чтобы лучше разобраться во внутренностях и особенностях - Docker тоже хорошо было бы подтянуть - Не совсем уверен в текущем уровне, но рекомендовал бы поботать system design (или хотябы подтоговиться к system design интервью)
Я в начале непонял, разница между изменяемыми и неизменяемыми, он сказал что первые передаются по ссылке а вторые по значению(это как вообще)? А разве не все данные из памяти передаются по ссылке? З.Ы. Слушаю собес, думаю чет както сложноваты вопросы, я большую часть знаю но некоторые прям заставляют задуматься, тяжеловато для собеса на Джуна.. и тут я вижу что я оказывается на90% вопросов собеса Синьера знаю ответы XD
так вопросы в большинчтые одинаковы, отличие джуна от сеньора в глубине ответа либо заучивается, для cpu bound юзайте multiprocessing, а для io - asyncio/threading, либо рассказывается а почему, почему дороги контекст свичи в тредах и выгоднее запустить один тред , который будет из event loop таски для выполнения брать(механизм , что asyncio реализует) также для сеньора архитектурные вопросы задают, как задизайнить систему, а почему ты выбираешь эту бд, а не ту и тд
Привет, у меня такой вопрос, коммерческого опыта нет, знаю C, люблю Computer Science. Хочу в backend, выбираю между Python, Java, C#, Golang что посоветуете, чтобы легче было устроиться на работу, слышал, что Python-программистов уровня Junior слишком много и труднее будет устроиться?
Привет, я к сожалению не специалист в этой теме. Скорее всего да, много джунов на питоне, т.к. язык простой для входа в IT. Но лучше посмотреть статистику) Если есть знания, то я бы посоветовал смотреть в сторону GO. Он щас активно развивается, и будут открываться новые вакансии. Плюс он достаточно новый, а значит у всех небольшой опыт работы с ним, и меньше конкуренция)
Извените, Я бы хотел узнать ваше мнение. Как вы относитесь к накрутки опыта в разработке? Если другие варианты? У меня сейчас 2 резюме и единственное, что в них различается, это количество опыта, но на одном 2 отлика (о опыта), а на другом 26 (1.6 опыта).
Зависит от ситуации. Если у тебя год опыта, но знаний на 3 года, то не будет ничего плохого, если ты эти 2 года накрутишь, чтобы пройти отбор в лице HR. Если ты знаешь больше своего опыта, то работодатель не расстроится) Другое дело, если знаний на 1 год, а пишешь, что опыт 5 лет. Тогда тут тебя раскроют на собеседовании, и получится, что зря потратил время интервьювера.
@@python_interview спасибо за ответ. Я не хочу накручивать более 2 лет, это не очень:) Я просто хочу сделать своё резюме, где 1.6 - основным и подаваться по нему. Не очень кайфово, когда проходишь интвью во 'фейку', а по реальному тупо не зовут. Как вы считаете это можно сделать?) Извените за обилие текса. Спасибо!