Экзамен AWS Certified DevOps Engineer – Professional (DOP-C01). Как подготовиться и успешно сдать тест
Теперь настал черед поделиться с информацией о том, как я готовился и сдавал экзамен AWS Certified DevOps Engineer – Professional, это мой третий сертификат по AWS. О том, как я готовился и сдавал экзамен Solutions Architect – Associate можете прочитать тут, а о Security Specialty более подробно тут.
Почему я выбрал DevOps Pro?
Во-первых, потому, что это уже верхний (Pro) уровень в сертификации, нужно только выбрать Solutions Architect или DevOps Engineer, я выбрал второе, так как знания по архитектуре у меня уже были, а вот по CI/CD и сервисам для разработчиков – не так много.
Во-вторых, профессиональные сертификаты дают 3 балла в копилку для упрощенного ассессмента на основе сертификации (в EPAM возможно вырасти с System/DevOps Engineer до Senior и Lead позиции за счет получения сертификатов).
Подготовка
За основу для подготовки я взял курс от Stéphane Maarek, но не DevOps Pro, а просто Developer Associate (ссылка на курс здесь). Я решился на это по трём причинам. Во-первых, я уже купил его, когда готовился к SAA, но тогда руки до него просто не дошли из-за жёстких дедлайнов по программе от EPAM, о которой я писал в статье про SAA. Во-вторых, сравнив описание этого курса и Devops Pro у Stephane Maarek, я понял, что разница между ними не такая большая. Ну и в-третьих, сэкономил 13$ с учётом скидки. Что мне нравится в его курсах, так это то, что они разделены на модули по темам. Я изучал только модули из разделов, которые ещё не знал, начинающиеся на Code*, а также Step Functions и ещё раз прошёлся по Lambda, API Gateway, Elastic Beanstalk, Cloudformation и Auto Scaling Group (особенно Lifecycle Hooks). Подготовка разделилась на три этапа:
просмотр видео и параллельное выполнение практических заданий;
изучение White Papers и FAQ по сервисам;
поиск и прохождение тестов в интернете.
На подготовку у меня ушёл примерно месяц, после чего я забронировал экзамен.
Экзамен
Стоит он столько же, сколько и Specialty – 300$, я купил за 150, применив ваучер, который получил после успешного прохождения предыдущего Security Specialty. EPAM потом всё возместил.
По времени экзамен длится 180 минут (+30 минут для тех, у кого английский язык не родной), но в тесте уже не 65 вопросов, как в Associate и Specialty, а 75. Проходной балл такой же, как и для Specialty, – 750.
По сложности, на мой взгляд, этот экзамен превосходит SAA и Security. Было много длинных вопросов с большим количеством деталей, на которые нужно потратить пару минут только чтобы просто прочитать сам вопрос с ответами, а ведь ещё нужно решить какой из них наиболее подходящий. Тут тоже не обошлось без таких вопросов, где на первый взгляд, отсеяв наименее релевантные, подходят два варианта ответа. Было 3-4 вопроса, на которые я вообще не знал, что ответить и размышлял над ними минут по 5-7. Учитывая затянувшийся по времени прошлый экзамен, я старался, по возможности, отвечать на вопросы сразу, не оставляя их для дальнейшего ревью, но без этого всё равно не обошлось. Около 15-17 вопросов я пересмотрел второй раз, после того, как ответил на все. По времени тоже не получилось справиться быстрее, так как в этом экзамене на 10 вопросов больше. С учётом check-in у меня ушло примерно три с половиной часа.
Настал самый волнительный момент, нажимаю кнопку завершения и вижу PASS. Ещё один сертификат в копилку. Я конечно же очень обрадовался. Не только от того, что успешно сдал экзамен и набрал достаточно неплохие 860 баллов, а ещё потому, что за эти полгода узнал очень много нового для себя.
Если вы работаете с AWS, то сертификация позволит упорядочить ваши знания и приобрести новые. А если не работаете, то самое время окунуться в этот, без преувеличения, океан, так как облака сейчас активно развиваются и даже клиенты из развивающихся стран потихоньку туда переходят.
Несмотря на то, что экзамены теоретические, обязательно нужно выполнять практические задания. Так как в любом тесте попадается несколько именно практических вопросов. А ещё с практикой лучше усваивается теория.
Остальные выводы и советы я подробно описал в первых двух частях, тут и тут. Единственное, что я ещё бы хотел добавить, это то, что помимо бесплатных тестов, если есть несколько лишних долларов, вы можете купить практические тесты от Jon Bonso, они считаются одними из лучших на данный момент.
На этом пока всё, спасибо за внимание!
Кстати, сейчас компания набирает DevOps-специалистов в команду – проводит Hiring Week, если до 12 сентября примите оффер, то вы получите welcome-бонус. Регистрация здесь.
Собеседование в DevOps Engineering, как оценить свой опыт и сколько нужно знать?
Основное про DevOps и про обязанности
DevOps — это набор практик, которые помогают автоматизировать и интегрировать процессы между командой разработчиков и командой, ответственной за инфраструктуру, чтобы они могли быстрее и надежнее собирать, тестировать и выпускать релизы.
Основные практики DevOps это:
Infrastructure as Code
Некоторые практики разделяются между инженерами, например, QA может отвечать за Continuous Testing а Security за Continuous Monitoring. Как правило, инженер, который получил роль DevOps (не принято говорить «DevOps инженер», но рынок уже взял в оборот, звучит так же неопределенно, как «Scrum инженер») отвечает за все, что происходит с момента, как команда разработки пушнула код в репозиторий или выпустила релиз. Т.е за CI/CD пайплайны, энвайрменты проекта и базовый мониторинг.
Сколько инструментов в домене DevOps и что именно нужно знать?
В области технической экспертизы DevOps возникает вопрос: что именно выбирать, сколько вообще инструментов нужно знать и что показывать на собеседовании?
Инженеры, переходящие в DevOps, например, из системного администрирования при выборе технологий «для изучения» испытывают страх, что они будут привязаны к чему-то одному и для другого проекта их опыт будет не актуален. Тут можно немного успокоить: если вы научились писать код Terraform, вы справитесь и с Ansible, не потому что они похожи или близки в синтаксисе, нет, ваш мозг теперь умеет решать задачи автоматизации, а психика окрепла верой в себя. На собеседовании это будет заметно и в большинстве случаев вызовет адекватное доверие. Поэтому не стоит стремится выучить большое количество инструментов. Если вы просто учитесь, выберите инструменты, которые вам реально интересны, это даст позитивную энергию и удовольствие от процесса обучения.
Какое количество инструментов/платформ и насколько глубоко вам нужно знать
Чтобы облегчить задачу выбора, все инструменты DevOps можно поделить на домены:
На картинке представлено 30 наиболее популярных инструментов, разделенных по соответствующим доменам, вы можете добавить домены или инструменты по необходимости. Стараться выучить все бессмысленно и долго, лучше выбрать из каждого домена один или два инструмента и составить небольшую, личную матрицу компетенций, например:
IaC: Terraform
CM: Ansible
Cloud: AWS
CI/CD: CircleCI
Scripting: Python, Bash
Containerization: Kubernetes
Monitoring: ELK, Prometheus
OS: Linux
SQL: Postgres, MongoDB
Количество инструментов сильно сократилось, но все равно список большой. Есть риск, что на собеседование придут неопытные интервьюверы-инженеры и если в резюме вы укажете все из вашего проекта или опыта, они будут проверять знание по всем заявленным вами инструментам, ожидая от вас высокого уровня. Такое интервью получится сложным и разочаровывающим. Лучше управлять ожиданиями и указать уровень владения инструментом или платформой, разбив на относительно простые и условные категории:
*эти категории можно критиковать в комментариях, это позволит выработать более точную модель!!
Теперь получилась следующая матрица:
Таким образом мы сильно сузили область, если вы только входите в профессию, вам проще строить цели. Если вы идете на интервью, из этой матрицы видно, что нужно подтянуть и на какие темы общаться.
Можно указать уровень владения в CV, но я бы рекомендовал выделять основные инструменты, с которыми работаете на проекте, и отдельной строкой категорию Novice. Это нужно для того, чтобы состоялся разговор по конкретному опыту.
Тут можно добавить еще один уровень оценки: если вы претендуете на позицию Senior DevOps Engineer, нужно владеть 3-4 инструментами на Advanced уровне и одним инструментом как Expert. Для Middle DevOps достаточно работать с 2-3 на Advanced.
Итого, ваша матрица компетенций:
Middle DevOps Engineer
Конкретика в CV и на собеседовании избавляет от разочарования, вызывает доверие, и освобождает вас от траты времени на подготовку (например, если вы не хотите учить SQL), позволяя сконцентрироваться на том, что реально нужно подтянуть.
10 популярных вопросов и ответов на DevOps собеседовании
DevOps работает как мост между разработкой, тестированием и эксплуатацией в сфере IT, и чтобы стать таким специалистом, следует подготовиться к интервью.
А подготовиться стоит, ведь в стандартный перечень требований входит опыт системного администратора, разработчика и тестировщика. Командам с открытыми вакансиями нужен «швейцарский нож», поэтому и собеседование может носить специфический характер.
Ну что, хотите стать сертифицированным практиком DevOps?
В1. Что вы знаете о DevOps?
A1. Ваш ответ должен быть простым и понятным. Объясните растущую популярность DevOps в сфере информационных технологий. Уточните, что такой подход направлен на объединение усилий различных специалистов и ускоренную реализацию программных продуктов, начиная этапом проектирования и заканчивая развертыванием.
В2. Почему известность специализации возросла за последние несколько лет?
A2. Обсудите текущий отраслевой сценарий. Начните с некоторых примеров того, как крупные игроки, такие как Netflix и Facebook, инвестируют в эту отрасль для автоматизации и ускорения развертывания ПО, чем успешно развивают свой бизнес. Используя Facebook в качестве примера, уточните, что сотни строк кода реализованы без ущерба для качества, стабильности и безопасности ресурса. Следующим вариантом использования должен быть Netflix. Эта развлекательная компания следует аналогичной практике с полностью автоматизированными процессами и системами.
Также упомяните пользовательскую базу обеих организаций: Facebook насчитывает 2 млрд. пользователей, в то время как Netflix предоставляет онлайн-контент более чем 100 млн. пользователей по всему миру. Лучшая иллюстрация того, как DevOps помогает организациям добиться несравнимо высоких показателей, сократив время между исправлениями ошибок, оптимизацией и непрерывной доставкой через автоматизацию. Добавьте в копилку плюсов и общее снижение затрат на рабочую силу.
В3. Какие инструменты вы знаете? У вас есть опыт работы с любым из этих инструментов?
A3. Инструментарий DevOps включает в себя:
Тщательно описывайте инструменты, которые знаете. Затрагивайте их функции и преимущества. Например, если у вас есть опыт работы с Git, вы должны сказать, что это система контроля версий (VCS), которая позволяет отслеживать изменения кода и при необходимости возвращаться к предыдущим этапам. Расскажите о том, что разработчики имеют доступ ко всей истории проекта, содержащейся в локальных хранилищах Git, которые также могут передаваться другим членам команды.
Теперь, когда вы упомянули VCS, будьте готовы к следующему очевидному вопросу.
В4. Что такое контроль версий и для чего он используется?
A4. Дайте определение контролю версий и расскажите о том, как подобные системы записывают изменения в один или несколько файлов, а после сохраняют их в централизованном хранилище. Инструменты VCS помогут заглянуть в предыдущие версии и выполнить следующие действия:
Использование VCS делает работу с кодом более гибкой и менее затратной по времени, а все модификации могут быть объединены позже.
В5. Есть ли разница между Agile и DevOps? Если да, пожалуйста, объясните.
A5. Начните с описания общих черт. Затем перейдите к отличиям: Методика Agile предполагает создание и выпуск ПО, после чего разработчики за него формально не отвечают. С DevOps все обстоит иначе: эта методика направлена как раз на то, чтобы развернуть готовое ПО максимально надежным и безопасным способом.
В6. Почему так важны процессы и инструменты управления конфигурацией (CM)?
A6. Расскажите о нескольких версиях для каждого ПО на стадии разработки или тестируемого ПО. Перейдите к необходимости поддержки и хранения данных, отслеживания разработки и устранения неисправностей. Не забудьте указать ключевые инструменты CM, которые можно использовать для достижения этих целей. Расскажите о том, как Puppet, Ansible и Chef помогают автоматизировать развертывание и настройку программного обеспечения на нескольких серверах.
В7. Как Chef используется в качестве инструмента СМ?
A7. Chef считается одним из предпочтительных отраслевых инструментов Configuration Management. Например, Facebook перенесла инфраструктуру на платформу Chef. Объясните, как эта система управления конфигурациями, написанная на Ruby, поможет избежать задержек, автоматизируя процессы. Chef позволяет интегрироваться с облачными платформами, настраивать новые системы, а также предоставляет библиотеки, которые могут быть развернуты в рамках ПО.
В8. Как бы вы объяснили концепцию «инфраструктура как код» (IaC)?
A8. Опишите, как традиционный подход к управлению инфраструктурой «пасет задних», и почему ручные конфигурации, устаревшие инструменты и пользовательские сценарии становятся ненадежными. Далее подчеркните плюсы IaC и то, как изменения в IT-инфраструктуре могут реализовываться быстрее, безопаснее и проще с использованием IaC. Включите в ответ как можно больше преимуществ.
Это стандартный блок вопросов, а для AWS-сертифицированных инженеров предусмотрено еще несколько дополнительных.
В9. Какова роль AWS в DevOps?
A9. AWS – это платформа для облачных сервисов от Amazon. AWS предоставляет IT-компаниям разработку, поставку сложных продуктов и развертывание приложений в облаке. Некоторые из ключевых услуг включают Amazon CloudFront, Amazon SimpleDB, Amazon Elastic Computer Cloud и Amazon Relational Database Service. Обсудите различные облачные платформы.
В10. Как реализована IaC с использованием AWS?
A10. Подобно кодам, написанным для других сервисов, с помощью AWS IaC позволяет разработчикам писать, тестировать и поддерживать объекты инфраструктуры дескриптивным способом, используя такие форматы, как JSON или YAML. Это упрощает разработку и ускоряет развертывание изменений инфраструктуры.
Как инженер DevOps, вы должны знать процессы, инструменты, технологии, а также иметь целостное представление о продуктах, услугах и системах. Если ваши ответы по своей структуре соответствуют приведенным выше, эта должность с большой вероятностью станет вашей. Удачи!
Ультимативный гайд по собеседованию DevOps-инженеров — что спрашивать и к чему готовиться
Я начал заниматься сетями еще в школе, а работаю за деньги больше 16 лет. Я много куда устраивался, в большие компании и маленькие, потом открыл свой бизнес и регулярно сам нанимаю людей. С годами и опытом у меня, да и у многих, вырабатывается интервьюшная интуиция.
Это когда никакого четкого алгоритма нет. Ты просто разговариваешь с человеком и что-то для себя понимаешь. Спрашиваешь, что кандидат делал на прошлой работе, цепляешься за тему — и вот вы уже просто обсуждаете инженерные темы, примерно на том же уровне, что и с коллегами. Если беседа клеится и человек нравится, то все хорошо.
Такой интуиции вряд ли научишься по книгам и текстам, она приходит сама с опытом. Вместе с ней в мышление просачиваются фразы вроде «мне не так важны конкретные знания, как общий кругозор, способность искать информацию, понимание, сработаемся ли» и все такое.
Но иногда, чтобы не терять хватку, надо все же напоминать себе, какими знаниями должен обладать инженер и какими вопросами можно максимально объективно оценить человека, которого видишь впервые в жизни.
Сперва я быстро просматриваю все резюме
Пока я перебираю отклики, обращаю внимание на ключевые слова и места работы. Всегда читаю сопроводительное письмо — много соискателей отсеивается на этом этапе. Я размещаю вакансию о поиске DevOps-инженера, а ко мне приходит отклик от python-разработчика, от golang-разработчика или от нынешнего курьера, которому «очень интересно и он хотел бы попробовать».
Мимо идут резюме, в которых указан опыт работы в госструктурах, что-то в духе «администратор первого разряда в ЦБ РФ». Все эти многословные рассказы про «администрирование информационных систем» я отсекаю сразу без раздумий. Чем официозней и канцеляритнее описание прошлой работы, тем выше шанс, что ничего в своей жизни, кроме винды и бэкапов с помощью графического интерфейса, такой соискатель не видел.
В быстром отборе резюме помогает правило: чем больше технологий я встречаю, тем лучше. Если у человека в резюме написано MySQL, Linux, Postgres, Apache и так далее — шансы есть. Человек по крайней мере слышал о технологиях и, кто знает, возможно, даже сам с ними работал. Хотя будем честны — в резюме можно написать все, что угодно.
На собеседовании первым делом проверяю базу
Когда я стану немощным стариком и меня будет стремно бить в ответ, я начну колотить палкой по спине всех, кто не знает сети! Это маст хэв для любого инженера. Мы живем в мире, где все происходит в сетях. Даже в закрытом госсекторе найдется локальный контур. И там сидит разработчик, который пишет какой-нибудь proxy-сервис или сочиняет сервис, работающий с API-шкой, и ничего не понимает в API.
Я не требую особых знаний, я не прошу настроить мне MPLS. Но что такое маска подсети, что такое IP-адрес — в 21 веке должны знать все IT-специалисты. Я понятия не имею, что у человека в голове происходит, когда он не понимает, что такое 127.0.0.1. Он сидит на локальной машине, у него запущен сервис на виртуалке. У сервиса прописан эндпоинт 127.0.0.1, коннект к базе. От незнания наш герой вхреначивает то же самое. Как результат: «у меня не коннектится к базе». Конечно, блин, не коннектится!
Если у человека есть сертификат CCNA, окей, даже если он не сдавал его, не получал физически, но готовился — мне достаточно этого факта за глаза.
Вот, например, стандартная задачка из CCNA, на понимание того, как работают сети
Есть два свича из разных сетей, между ними стоит роутер. Компьютер А хочет отправить данные в компьютер Б.
Затем я спрашиваю по всем уровням модели OSI
Слышал ли что-нибудь человек про Spanning Tree протокол? Про корневой протокол, про IP-уровень? Хорошо, а как это все работает? Понимает ли он, как происходит роутинг? Ну и скопом: таблицы маршрутизации, динамический протокол маршрутизации, транспортный уровень TCP. И так далее, и так далее.
Я хочу услышать, чем отличаются TCP и UDP. Хороший спец ответит мне, почему критичные системы (например, Domain Name System) используют протокол без гарантированной доставки сообщений (UDP).
Ответ простой — так быстрее. Пока устраиваешь TCP-сессию, ты можешь 3 раза отправить UDP пакетик туда и получить его обратно. И никакого оверхеда.
Задаю вопросы про DNS
Какие бывают типы записи? Знает ли мой собеседник, что такое MX-запись, как работает spf или как работает DKIM.
Да, в работе эти знания могут и не пригодиться. Но мне важно знать, понимает ли человек суть технологии, было ли ему интересно прочитать про это. Вот добавлял он какие-то записи в DNS и загуглил, что такое spf-запись, или не загуглил?
Абсолютно везде сейчас используется HTTP-протокол, и я про него спрашиваю
Я начинаю со стандартных вопросов об отличиях http-версий 1.0, 1.1 и второй версии. Интересуюсь, что такое headers и зачем они нужны. Как веб-сервер понимает, что ему пришел запрос на определенный virtual host, а не на любой другой. И всегда задаю пару вопросов по Nginx.
Дальше плавно переключаю внимание на TLS-протокол
Как работает SSL\TLS? Инженеру нужно понимать это хотя бы на базовом уровне — есть корневой центр сертификации, он подписал сертификат, и сертификат где-то используется.
В TLS меня обычно интересует процесс установки соединения. Зачем нужны приватный и публичный ключи и как они взаимодействуют? Если человек шарит, то задаю вопрос с подвохом: можно ли иметь несколько разных сертификатов на одном IP-шнике?
Перехожу к Linux и BASH
Надо знать все юниксовое, все Unix-like системы. Нужно уметь работать с Shell и Bash, знать основные команды. ls-ы всякие, mkdir и т.д.
Хорошо, если кандидат может немного скриптовать на BASH — значит, он пробовал хоть как-то автоматизировать эту историю.
По Linux спрошу, как заменить в файле строчки другими строчками. Или как распарсить какой-нибудь access.log в Nginx средствами BASH. Чтобы человек рассказал про awk, про cat, про sort, про все, что помогает быстрой работе.
Там всюду текстовые файлы, надо с ними правильно работать. Если соискатель предложит копировать их в эксельку и уже там что-то делать, то мне станет неловко.
Потом надо выяснить, как дела с виртуализацией
Обычная виртуализация, виртуализация через гипервизор. Если кандидат заводит разговор про паравиртуализацию — значит, что-то знает.
Основной мой вопрос: чем отличается контейнерная виртуализация от обычной гипервизорной виртуализации? Хорошо, если человек сравнит что лучше, что хуже, где что подобает использовать.
Перемещаемся к контейнерам
Узнаю, работал ли собеседник с Docker? Собирал ли он образы, писал ли Docker-файлы, использовал ли Docker compose, деплоил ли с его помощью. Зачем вообще нужны эти контейнеры и как они работают? Поднимал ли наш соискатель систему оркестрации контейнеров Swarm или Kubernetes? Можно задать целый блок вопросов, но главное понять, делал человек работу своими руками с контейнерами или нет?
Спрашиваю про CI/CD deployment
Меня интересует огромный список вещей: как он настраивает автоматический deployment, как настраивает Continuous Integration? Как у него собираются приложения, использует ли он системы анализа кода (PVS-Studio, SonarQube). Как он пишет тесты или как интегрирует тесты, написанные разработчиками.
Делает ли он какое-то интеграционное тестирование этих сборок? Что дальше происходит с тем, что он собрал? Это как-то складывается в артфекаты или это упаковывается в docker-контейнеры, пушится в registry? Пусть расскажет, какие системы использовал для настройки CI/CD-процесса. Это могут быть и GitLab CI, и Circle CI, и какие-то облачные решения. А может быть, Jenkins, ну и про самописные скрипты на PowerShell не стоит забывать.
Скажи мне, как человек деплоит, и я все пойму. Он может деплоиться с помощью Helm в Kubernetes, Ansible, скриптами или чем-то еще самописным.
Про систему управления конфигурациями
Говорим чаще всего по Ansible. Поскольку его знают большинство. Итак, зачем нужны роли, как зашифровать и хранить секретные данные, как закидывать пароли на Git-репозиторий? И все в таком духе.
Узнаю про умение писать код
Разбираться в разработке важно, чтобы понимать, как взаимодействуют сервисы, зачем нужны API, протоколы аутентификации, авторизации. Славно, если кандидат что-то писал сам. Мне достаточно даже базовых скриптов на Python или Shell. Важен не код, а то, какие задачи хотел решить человек, чего хотел добиться.
Кодинг нужен для поддержки инфраструктуры, написания локальных скриптов для бекапа, кастомных мониторингов, чтобы спокойно вытаскивать метрики. Часто бывает в работе, что стандартного решения для какой-то задачи попросту нет.
Последние вопросы на собеседовании касаются хранилищ баз данных
SQL, NoSQL — в чем различия, с чем работали? Чаще встречаю людей с опытом работы в PostgreSQL, реже — MySQL. Задаю вопросы про индексы, может ли соискатель настроить реплику, может ли настроить логическую репликацию между табличками или просто данными. А что он будет мониторить в этом случае? А как ускорить базу?
Кстати, это хороший вопрос. Допустим, база сейчас сидит и упирается в диск. И с ней ничего не сделать — больше сервер никто покупать не будет. Как сделать так, чтобы оно работало быстрее прямо сейчас?
Все это позволяет составить полную картину о человеке
Самое критичное в моем списке — базовые знания. Не знаешь базу — пора заканчивать собес.
Если человек не может мне ответить, что такое маска подсети, или не понимает, зачем нужны headers в HTTP — в большинстве случаев такой соискатель получает наижирнейший минус в моей тетради. Разве тебе не любопытно было узнать, как работают все эти штуки, в которых ты тыкаешь курсором мышки?
Очень тяжело работать с людьми, которые просто механически повторяют заученное, вместо того, чтобы разобраться, как все устроено. Новичок, не знающий Docker, спокойно в нем разберется, если у него есть понимание, что такое HTTP, TLS и сети.
Но вот, наконец, самый важный момент — весь этот список нужен не для того, чтобы идти по нему на настоящем собеседовании. Этот список надо пройти самому перед тем, как нанимать людей.
И если все получится, зовите кандидата на собеседование и задавайте ему всего один вопрос — какой самый большой фейл ты совершил в работе, как чинил его и какие выводы сделал из своих ошибок.
Когда человеку есть, что рассказать, такой собес пройдет как дружеская беседа двух инженеров под пиво.
Ну и по традиции, приглашаю присоединиться к нашему сообществу в телеге — там регулярно разбираем все эти темы и многие другие, которые пригодятся и на собеседовании, и в работе.
