Искали статеечку с жалобами джуна о несправедливости IT? Так вот же она!

Открытая к интерпретации история собеседования.

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

В этой статье я хочу описать (часть) моего опыта взаимодействия со структурой, именуемой в дальнейшем «яндекс», с точки зрения работника. Опишу собеседования и этап «входа».

Да, уже были статьи про собеседование и даже в эту же структуру, некоторые из них я видел, но не во всём с ними согласен, к тому же конкретно С++ разработчиков я там не видел.

Я закончил курсы "Fullstack разработчик на Python" от одной известной компании. Обучение завершено успешно, но не было ощущения полноценности — на курсах не учили, как сделать самостоятельно деплой приложения на Django. И никто из студентов не задавался эти вопросом 😁

Так что я решил закрыть этот вопрос и все-таки пройти путь по развертыванию django-приложения, так как, возможно, больше никогда такого случая не представится. Потом я уже могу не вернуться к этой теме, так как это потребует мучительного вспоминания и повторного прохождения материала. Все должно быть вовремя.

В этой статье я хочу дать небольшой гайд для выпускников подобных курсов и заодно рассказать про российский облачный сервис (еще раз внимательно прочитал их статью и увидел, что она опубликована буквально за 3 недели до моих тестов - то есть мне повезло).

За время работы в Google я провёл более двух сотен интервью. И главное, что я вынес из этой работы — проводить качественные собеседования очень непросто. Все дело в сигналах, которые мы посылаем и получаем. И у интервьюера, и у самого кандидата есть меньше часа, чтобы выложиться на полную. Порой, по разным причинам, мы получаем друг от друга ложные или неточные сигналы. Такова уж человеческая природа.

С годами я выработал вопрос по кодингу, который мне самому очень нравится. Это до жути простой и в то же время заковыристый вопрос. Решение занимает не более 30 строк кода, но зато даёт мне все нужные сигналы для вынесения верной оценки кандидату. Кроме того, мой вопрос отлично масштабируется и подходит как стажёрам, так и опытным инженерам. Здесь я не стремлюсь доказать, что мой вопрос лучше какого-то другого. Я лишь хочу объяснить, как он помогает мне как интервьюеру и на что я обращаю внимание на собеседовании по программированию.

В этой статье будут вещи, с которыми вы можете не согласиться. Это нормально. Это просто моё мнение, а так как я уже вышел на пенсию, то больше не представляю опасности ни для интервьюеров, ни для инженеров Google при принятии решений о найме! ;-)

Была у нас тут история, когда легкий перфекционизм помог привести в порядок конструкторскую документацию и регулярно экономить инженерам кучу дней на прохождение бюрократических процедур. В ее основе – создание системы управления расчетными данными и переход от трудночитаемых и трудноинтегрируемых отчетов Mathcad к гибкой связке Jupyter Notebook с Python и Teamcenter. Но основной рассказ будет про то, как преобразовывать и экспортировать математические формулы, таблицы и другие элементы из Jupyter в красивый и удобный вид.

Привет, Хабр! Меня зовут Павел Корсаков, я python-разработчик в облачном провайдере beeline cloud.

Почти на всех собеседованиях задают вопросы про SOLID: что это такое, зачем нужен, как его применяет кандидат, как понимает принципы из него?

Мы тоже спрашиваем кандидатов про SOLID. Чаще всего они рассказывают, что SOLID — это акроним, озвучивают все его принципы, но объяснить и привести примеры могут лишь для половины. На остальных либо плавают, либо сливаются.

Чтобы мой материал не получился очередной статьей про SOLID, я изменю формат подачи и последовательность объяснения принципов. Буду добавлять код небольшими инкрементами и на каждом из них указывать, какие принципы SOLID используются в том или ином случае. 

В жизни каждого инженера-фронтендера наступает момент, когда осознаёшь: далее не обойтись без кэширования данных из API. Всё может начаться с самых невинных вещей: сохраняем предыдущую страницу с данными, чтобы кнопка «Назад» срабатывала мгновенно; реализуем простенькую логику отмены действия или обеспечиваем слияние нескольких состояний от различных запросов к API. Но все мы знаем, чем такое кончается. Один за другим возникают запросы на новые фичи, и вскоре мы уже не покладая рук реализуем кэши данных, индексы для работы вручную, оптимистические мутации и рекурсивную инвалидацию кэша.

Эти фичи явственно смахивают на внутренние механизмы баз данных. Действительно, в любом достаточно сложном клиентском приложении программисту непременно придётся реализовывать такое множество фич для управления данными, что эта работа будет напоминать построение предметно-ориентированной базы данных. Такая дополнительная сложность удваивается в каждом проекте, над которым мы работаем, поэтому приходится тратить время на решение бизнес-проблем, а радовать пользователя – уже как успеем.

Поэтому сегодня предлагаю вам составить мне компанию – и мы вместе рассмотрим распространённые паттерны работы с данными приложений, а также разберёмся, как они соотносятся с фичами баз данных. Далее мы рассмотрим решения, которые могли бы стать альтернативами этим паттернам – например, как сделать в клиентской части оптимизированный стек базы данных, который позволил бы нам сосредоточиться на разработке приложения, а не на мелкой возне с данными.

Привет, Хабр!

Каждая секунда простоя может стоить компании целое состояние, важно иметь надежные механизмы защиты от сбоев. Здесь и приходит на помощь паттерн Circuit Breaker.

Представьте себе обычный автоматический выключатель в вашем доме. Когда происходит перегрузка, он "выбивается", предотвращая возможные повреждения. Точно так же работает и Circuit Breaker в микросервисах. Он мониторит вызовы к внешнему сервису и при обнаружении слишком большого количества неудачных попыток временно "отключает" вызов, предотвращая тем самым падение всей системы.

Этот паттерн основывается на трех основных состояниях: закрытое, открытое и полуоткрытое.

Меня всегда тянуло к обучению людей и шарингу знаний. Когда я был разработчиком, то охотно становился ментором у стажеров. И даже сейчас, работая тимлидом, я являюсь пипл-менеджером уже у senior-разработчиков. Но у меня никогда не было опыта работы преподавателем или наставником сразу для большой аудитории. Мне всегда казалось это чем-то интересным и вдохновляющим. Но мои ожидания не оправдались, как вы уже поняли из названия статьи.

Как динамическое программирование может упростить нашу жизнь? Как можно оптимизировать решение задач?

Сегодня мы разберем динамическое программирование на пальцах с примерами на Python!

Усаживайтесь поудобнее, леди и джентльмены!

Перевод статьи подготовлен специально для студентов курса «Python Web-Developer».

Вы запускаете тесты командой manage.py test, но знаете ли вы, что происходит под капотом при этом? Как работает исполнитель тестов (test runner) и как он расставляет точки, E и F на экране?

Когда вы узнаете, как работает Django, то откроете для себя множество вариантов использования, таких как изменение файлов cookie, установка глобальных заголовков и логирование запросов. Аналогично, поняв то, как работают тесты, вы сможете кастомизировать процессы, чтобы, например, загружать тесты в другом порядке, настраивать параметры тестирования без отдельного файла или блокировать исходящие HTTP-запросы.

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

• R: Скачать R
• RStudio: скачать RStudio
• rmarkdown можно установить при помощи интерфейса установки пакетов в RStudio

Автор статьи обращает внимание на проблему, которая заключается в использовании метода __init__ для сложной логики создания объектов, что приводит к разрастанию и усложнению кода. Статья предлагает использовать вспомогательные методы, чтобы разделить логику создания объектов на более мелкие и понятные части. Это упростит код и облегчит понимание того, как объекты создаются и инициализируются.

Профилирование приложений — это процесс анализа программы для определения её характеристик: времени выполнения различных частей кода и использования ресурсов.

Для асинхронного python-кода существует конечное количество специфических "узких мест", которые лучше перечислить заранее.

Меня зовут Стас Гаранжа, я выпускник курса «Python-разработчик» в Яндекс.Практикуме. Я хочу помочь начинающим разработчикам, которые приступили к изучению Django Rest Framework (DRF) и хотят разобраться, как устроен этот фреймворк.

Я готовлю цикл статей, в которых расскажу о разных сторонах работы DRF. У меня пока нет значимого практического опыта для описания всех изюминок при работе с этим фреймворком, поэтому в основе статьи — исследование, обобщение и по возможности непротиворечивое изложение того, что у DRF под капотом.

В этой статье разберёмся, как сделать REST API на базе Django Rest Framework, чтобы получить по GET-запросу набор записей из базы данных (БД). Иными словами, рассмотрим, как DRF работает на чтение (о том, как с помощью него создавать, изменять и удалять записи в БД, поговорим в отдельной статье).

Общую схему решения этой задачи мы рассмотрим в первой части статьи. Вторая будет посвящена детальному разбору процесса сериализации данных.