Решение должно быть реализовано на принципах ООП. Необходимо реализовать базовые классы, применить наследование, полиморфизм и инкапсуляцию. То есть решение исключительно на функциях не будет принято, но вспомогательные функции использовать можно. Часть задания проверяется автоматическими тестами на базе Pytest (что есть определенные в задании классы, есть наследники этих классов и так далее), а финальная проверка и решение о принятии работы после доработок в зоне ответственности ревьюера.
На самом деле именно так и сделано: студентам на базе шаблона генерируется индивидуальный репозиторий, который уже содержит базовый прекод, тесты, настройки линтера и прочее. В итоге ревьюер получает работу, в которой уже не надо тратить время на замечания по поводу форматирования или на проверку ключевых пунктов из задания, а можно сфокусироваться на самом коде и на лучших практиках.
"Нам разработчики нужны или стрессоустойчивые теоретики?" - это именно тот вопрос, который и должен задать себе интервьюер перед собеседованием кандидатов! :)
Люблю такие комментарии. И да, статья именно об этом! Мы никогда не знаем что нас могут спросить на интервью и зачастую интервьюеры начинают фокусироваться на каких-то частных деталях конкретной реализации отдельно взятого языка. Так конечно не стоит делать (если конечно это не относится напрямую к будущим задачам). А тут я как раз таки и попытался собрать и показать подобные примеры из практики прохождения интервью студентами.
Ага, это ещё один очень хороший и яркий пример из списка подобного рода вопросов. Конечно, это полезно знать и понимать и для кругозора и в целом, но к реальным задачам по написанию кода и решению задач при помощи кода зачастую не имеет никакого отношения.
Всё так! Об этом и речь! Современные интервью зачастую наполнены вызовами, которые мало коррелируют с реальными задачами на рабочем месте. Искусственные задачи и запоминание мелких деталей, которые легко можно найти в документации, не демонстрируют реальный уровень компетенции кандидата. В конце концов, в реальных рабочих ситуациях успех зависит не от того, сколько мелких фактов вы помните наизусть, а от вашей способности понимать суть задачи и находить решения, опираясь на доступные ресурсы.
Добрый день! Начальная часть курса Python-разработчик плюс состоит из тем и уроков курса Python-разработчик. Поэтому обновленные модули будут доступны и тут.
Да, это важное уточнение. Действительно, ранее было недостаточно уделено внимания объяснению того, каким вообще может быть фронтенд, как можно с ним взаимодействовать и что происходит под капотом такого взаимодействия. Мы учли этот момент и дополнили теорию новыми уроками и темами, в которых на простом и понятном учебном проекте теперь подробно разбираем что такое SPA и как взаимодействует фронтенд и бэкенд через API. Более того, для диплома была специально создана и добавлена в прекод коллекция Postman, в которой уже есть примеры всех необходимых запросов к API бэкенда. Если Вы уже закончили курс, то все изменения должны быть Вам доступны. Будет здорово, если получится перепройти новые уроки и оставить нам обратную связь.
Это очень хорошее замечание. Проблемы перевести курс на 4 или 5 версию Django нет, однако мы осознанно не делаем это. Дело в том, что в большинстве реализованных Django-проектов сейчас используется версия фреймворка 3.2. Если на работе вам достанется Django-проект, то с большой вероятностью его версия будет ниже или равна 3.2.
При выходе новой версии фреймворка разработчики, как правило, не пытаются сразу перевести свои проекты на неё:
зачастую это технически сложная задача, которая стоит времени и денег,
переводить работающий проект на новую версию фреймворка бывает нерационально: добавленные возможности не стоят затрат, которых потребует переход на новую версию.
И это относится не только к фреймворкам, а, например, и к версии интерпретатора. Вы удивитесь, но довольно много проектов всё ещё разрабатываются на Python второй версии.
Поэтому мы учим наших студентов не на старой, а на актуальной версии Django, на которой они скорее всего и будут работать.
Спасибо за обратную связь! Подмечено верно, метафоры и примеры из жизни часто вызывают эмоции, создавая эмоциональную связь с материалом. Это помогает увлечь читателя и заинтересовать его. Кроме того, часто бывает проще запомнить информацию, если она представлена в виде истории или примера. Метафоры и живые примеры помогают информации "застревать" в памяти. В своих уроках я всегда стараюсь использовать подобные приёмы, особенно когда нужно объяснить сложные сущности простым языком. Но везде важен баланс. Если образ будет очень ярким, либо если будет использовано избыточное количество метафор, то иногда этим можно больше навредить, чем помочь - это может сбить с толку или отвлечь читателя.
Приятно читать и отвечать на аргументированные комментарии внимательных читателей. Вдвойне приятно когда такое общение приносит продуктивный результат. Действительно сложность алгоритма заливки на основе рекурсии зависит от размера изображения или сетки, которую необходимо заполнить.
Когда необходимо заполнить всю сетку, сложность можно оценить как O(n * m). Это объясняется тем, что в этом случае каждая ячейка сетки должна быть обработана, и каждая ячейка занимает постоянное место в стеке вызовов.
Цель статьи не столько в том, чтобы научить читателя делать оценки сложности или показать чем отличаются понятия "наихудший и наилучший случаи" и "случаи, максимизирующие или минимизирующие какую-то метрику" - эти вопросы разбираются на соответствующем курсе по алгоритмам, а больше в том, чтобы показать пример реальной задачи из алгоритмической части интервью, показать возможные варианты её решения, а также предложить обсуждение темы. Тем не менее спасибо, что обратили внимание этот действительно важный момент!
Ну это же прекрасно, когда одновременно и интересно и непонятно. Это значит, что впереди вас может ждать много интересных открытий и, надеюсь, приятных моментов на пути освоения новой области знаний, если конечно есть время и желание разобраться в этом вопросе :)
А у меня не было ZX Spectrum, но был его отечественный аналог "Дуэт" :) Это было прекрасное время.
Ну и конечно существуют разные алгоритмы заливки, кроме упомянутой рекурсивной заливки есть еще breadth-First Flood Fill, заливка по глубине, итеративная заливка, seed Fill и другие. Многие похожи друг на друга, отличаются некоторыми оптимизациями. На собеседованиях об этом достаточно часто спрашивают, поэтому даже как минимум учебную рекурсию стоит разобрать тем, кто планирует алгоритмическое собеседование.
Решение должно быть реализовано на принципах ООП. Необходимо реализовать базовые классы, применить наследование, полиморфизм и инкапсуляцию. То есть решение исключительно на функциях не будет принято, но вспомогательные функции использовать можно. Часть задания проверяется автоматическими тестами на базе Pytest (что есть определенные в задании классы, есть наследники этих классов и так далее), а финальная проверка и решение о принятии работы после доработок в зоне ответственности ревьюера.
На самом деле именно так и сделано: студентам на базе шаблона генерируется индивидуальный репозиторий, который уже содержит базовый прекод, тесты, настройки линтера и прочее. В итоге ревьюер получает работу, в которой уже не надо тратить время на замечания по поводу форматирования или на проверку ключевых пунктов из задания, а можно сфокусироваться на самом коде и на лучших практиках.
"Нам разработчики нужны или стрессоустойчивые теоретики?" - это именно тот вопрос, который и должен задать себе интервьюер перед собеседованием кандидатов! :)
Люблю такие комментарии. И да, статья именно об этом! Мы никогда не знаем что нас могут спросить на интервью и зачастую интервьюеры начинают фокусироваться на каких-то частных деталях конкретной реализации отдельно взятого языка. Так конечно не стоит делать (если конечно это не относится напрямую к будущим задачам). А тут я как раз таки и попытался собрать и показать подобные примеры из практики прохождения интервью студентами.
Ага, это ещё один очень хороший и яркий пример из списка подобного рода вопросов. Конечно, это полезно знать и понимать и для кругозора и в целом, но к реальным задачам по написанию кода и решению задач при помощи кода зачастую не имеет никакого отношения.
Всё так! Об этом и речь! Современные интервью зачастую наполнены вызовами, которые мало коррелируют с реальными задачами на рабочем месте. Искусственные задачи и запоминание мелких деталей, которые легко можно найти в документации, не демонстрируют реальный уровень компетенции кандидата. В конце концов, в реальных рабочих ситуациях успех зависит не от того, сколько мелких фактов вы помните наизусть, а от вашей способности понимать суть задачи и находить решения, опираясь на доступные ресурсы.
Добрый день! Начальная часть курса Python-разработчик плюс состоит из тем и уроков курса Python-разработчик. Поэтому обновленные модули будут доступны и тут.
Да, это важное уточнение. Действительно, ранее было недостаточно уделено внимания объяснению того, каким вообще может быть фронтенд, как можно с ним взаимодействовать и что происходит под капотом такого взаимодействия. Мы учли этот момент и дополнили теорию новыми уроками и темами, в которых на простом и понятном учебном проекте теперь подробно разбираем что такое SPA и как взаимодействует фронтенд и бэкенд через API. Более того, для диплома была специально создана и добавлена в прекод коллекция Postman, в которой уже есть примеры всех необходимых запросов к API бэкенда.
Если Вы уже закончили курс, то все изменения должны быть Вам доступны. Будет здорово, если получится перепройти новые уроки и оставить нам обратную связь.
Это очень хорошее замечание. Проблемы перевести курс на 4 или 5 версию Django нет, однако мы осознанно не делаем это. Дело в том, что в большинстве реализованных Django-проектов сейчас используется версия фреймворка 3.2. Если на работе вам достанется Django-проект, то с большой вероятностью его версия будет ниже или равна 3.2.
При выходе новой версии фреймворка разработчики, как правило, не пытаются сразу перевести свои проекты на неё:
зачастую это технически сложная задача, которая стоит времени и денег,
переводить работающий проект на новую версию фреймворка бывает нерационально: добавленные возможности не стоят затрат, которых потребует переход на новую версию.
И это относится не только к фреймворкам, а, например, и к версии интерпретатора. Вы удивитесь, но довольно много проектов всё ещё разрабатываются на Python второй версии.
Поэтому мы учим наших студентов не на старой, а на актуальной версии Django, на которой они скорее всего и будут работать.
Спасибо за обратную связь! Подмечено верно, метафоры и примеры из жизни часто вызывают эмоции, создавая эмоциональную связь с материалом. Это помогает увлечь читателя и заинтересовать его. Кроме того, часто бывает проще запомнить информацию, если она представлена в виде истории или примера. Метафоры и живые примеры помогают информации "застревать" в памяти.
В своих уроках я всегда стараюсь использовать подобные приёмы, особенно когда нужно объяснить сложные сущности простым языком. Но везде важен баланс. Если образ будет очень ярким, либо если будет использовано избыточное количество метафор, то иногда этим можно больше навредить, чем помочь - это может сбить с толку или отвлечь читателя.
Именно на такие вещи и надо обращать внимание перед принятием решения о необходимости обновления или при выборе версии фреймворка для проекта.
Приятно читать и отвечать на аргументированные комментарии внимательных читателей. Вдвойне приятно когда такое общение приносит продуктивный результат. Действительно сложность алгоритма заливки на основе рекурсии зависит от размера изображения или сетки, которую необходимо заполнить.
Когда необходимо заполнить всю сетку, сложность можно оценить как O(n * m). Это объясняется тем, что в этом случае каждая ячейка сетки должна быть обработана, и каждая ячейка занимает постоянное место в стеке вызовов.
Цель статьи не столько в том, чтобы научить читателя делать оценки сложности или показать чем отличаются понятия "наихудший и наилучший случаи" и "случаи, максимизирующие или минимизирующие какую-то метрику" - эти вопросы разбираются на соответствующем курсе по алгоритмам, а больше в том, чтобы показать пример реальной задачи из алгоритмической части интервью, показать возможные варианты её решения, а также предложить обсуждение темы. Тем не менее спасибо, что обратили внимание этот действительно важный момент!
Ну это же прекрасно, когда одновременно и интересно и непонятно. Это значит, что впереди вас может ждать много интересных открытий и, надеюсь, приятных моментов на пути освоения новой области знаний, если конечно есть время и желание разобраться в этом вопросе :)
А у меня не было ZX Spectrum, но был его отечественный аналог "Дуэт" :) Это было прекрасное время.
Ну и конечно существуют разные алгоритмы заливки, кроме упомянутой рекурсивной заливки есть еще breadth-First Flood Fill, заливка по глубине, итеративная заливка, seed Fill и другие. Многие похожи друг на друга, отличаются некоторыми оптимизациями. На собеседованиях об этом достаточно часто спрашивают, поэтому даже как минимум учебную рекурсию стоит разобрать тем, кто планирует алгоритмическое собеседование.
Хорошая книга и автор, особенно мне нравится его стиль изложения и подходы в решении задач, тоже рекомендую её всегда.