✔️ 10 грин-флагов в вакансиях, которые реально стоит искать

На собесе мы оцениваем компанию не меньше, чем она — нас. И вот чеклист, по которому сразу видно: тут уважают специалистов и не будут устраивать цирк.

👉 Что внутри статьи

— Как формулируют обязанности, чтобы ты понимал, куда идешь
— Что значит здоровый испытательный срок
— Какие формулировки про график реально работают
— Как выглядит прозрачная информация о ЗП
— Что пишут про стек и команду, если всё по-честному

Это статья, которую стоит держать под рукой перед тем, как отвечать на оффер. Или перед тем, как составлять его, если ты HR.

🔗 Читайте по ссылке

Proglib Academy #буст

Что выведет код?

👾 — 1
👍 — 0
❤️‍🔥 — 2
🌚 — None
😄 — Error

Proglib Academy #междусобойчик

📊 Чек-лист: что спрашивают на техсобесе в Data Science

Вот основные блоки, к которым стоит подготовиться:

🔵 SQL
✓ JOIN’ы, GROUP BY, оконные функции
✓ Подзапросы и CTE
✓ A/B-анализ в SQL
✓ Запросы на оптимизацию и масштабируемость

🔵 Pandas
✓ Группировки, агрегации, merge
✓ Работа с датами и строками
✓ Feature engineering руками
✓ Детект пропусков и аномалий

🔵 ML
✓ Алгоритмы: регрессии, деревья, бустинги
✓ Метрки: ROC AUC, RMSE, logloss
✓ Пайплайны и кросс-валидация
✓ Интерпретация моделей и фичей

🔵 A/B-тесты
✓ Формулировка гипотез
✓ Выбор метрик
✓ Статистическая значимость (t-test, U-test)
✓ Ошибки 1 и 2 рода, power analysis

🔵 Формат подачи
✓ Решения оформлять в Jupyter
✓ Комментарии к коду и шагам
✓ Отдельный README или блок «как запускать»
✓ Данные — по возможности в .csv, .zip, Google Drive

Если вы можете не просто решить, а объяснить почему именно так — это уже middle, а не junior.

🔵 Чтобы получить оффер-мечты в Data Science, забирайте наш курс → «Математика для Data Science»

Proglib Academy #оффер_мечты

🛠 SOLID: база архитектуры, которую должен понимать каждый разработчик

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

🔵S — Single Responsibility Principle
Каждый класс должен отвечать только за одну вещь.
Пример: если класс парсит JSON и пишет в базу — это две ответственности, значит, пора разбить.

🔵O — Open/Closed Principle
Код открыт для расширения, но закрыт для изменения.
Пример: добавление новой фичи не должно требовать переписывания старого кода — лучше через интерфейс или абстракцию.

🔵L — Liskov Substitution Principle
Подклассы должны работать вместо родительских, не ломая логику.
Пример: если унаследованный класс внезапно бросает исключения или ведёт себя иначе — нарушен LSP.

🔵I — Interface Segregation Principle
Много маленьких интерфейсов лучше одного большого.
Пример: не заставляйте класс реализовывать методы, которые ему не нужны.

🔵D — Dependency Inversion Principle
Зависимости строятся на абстракциях, а не на конкретных реализациях.
Пример: не завязывайтесь на конкретный класс базы данных — работайте через интерфейс, который можно заменить.

SOLID — это основа хорошей архитектуры, которую стоит освоить как можно раньше.

🔵 Для полного понимания Архитектуры, забирайте наш курс → «Архитектуры и шаблоны проектирования»

Proglib Academy #буст

📌 Разбор Python-задачи

Если вы ответил 2 — это ловушка

def func(a, b):
    res = a + b

res = func(1, 1)
print(res)

На первый взгляд кажется, что res = 2. Но нет.

➡️ Что происходит

1. Функция func(a, b) складывает a + b и сохраняет в переменную res внутри функции.

2. Но! Функция ничего не возвращает. В Python по умолчанию любая функция без return возвращает None.

3. Следовательно, res = func(1, 1) присваивает None.

4. На экран выводится None.

📎 Пост с задачей

Proglib Academy #буст

📌 Азбука фронтендера: шпаргалка по JavaScript

Если вы начинаете учить JavaScript или уже пишете, но забываете синтаксис RegExp, методы массива или Date, держите в закладках — шпаргалка от Cheatography.

PDF на 2 страницы: удобно распечатать, удобно держать в открытой вкладке.

🔵 Забирайте курс по Фронтенду и углубляйте свои знания в JavaScript → «Frontend Basic: принцип работы современного веба»

📎 Ссылка

Proglib Academy #буст

🦔 Всё так плохо, что уже смеёшься над шуткой «электро кар»

Proglib Academy #развлекалово

💬 DFS vs BFS на Python

Если хотите разобраться, как алгоритмы поиска в глубину и поиска в ширину работают на практике, то вот минимальный пример, который покажет разницу.

graph = {
    'A': ['B', 'C'],
    'B': ['D', 'E'],
    'C': ['F'],
    'D': [], 'E': [], 'F': []
}

def dfs(node, visited=set()):
    if node in visited: return
    print(node)
    visited.add(node)
    for neighbor in graph[node]:
        dfs(neighbor, visited)

def bfs(start):
    queue = [start]
    visited = set()
    while queue:
        node = queue.pop(0)
        if node in visited: continue
        print(node)
        visited.add(node)
        queue += graph[node]

➡️ Что делает

— dfs проходит глубоко: A → B → D → E → C → F
— bfs — по уровням: A → B → C → D → E → F
— Обе функции показывают порядок обхода графа

🔵 Чтобы знать об алгоритмах все, забирайте наш курс «Алгоритмы и структуры данных»

Proglib Academy #буст

🧐 Как устроены AI-модели для работы с изображениями

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

📍Ось Recognition: чем левее модель, тем хуже она распознает объекты

📍Ось Localization: чем левее модель, тем хуже она распознает местоположние объекта

А теперь на пальцах моделях:
• SAM — отлично знают ГДЕ, но не знают ЧТО
• SEEM/DINO — неплохо определяют положение, базово распознают объекты
• CLIP/BLIP — знают ЧТО видят, но не всегда точно ГДЕ это находится
• RAM — универсальный солдат, который знает и ЧТО, и ГДЕ

🔗 Подробнее об универсальном солдате — в статье

🔵 Чтобы получить оффер-мечты в Data Science, забирайте наш курс → «Математика для Data Science»

Proglib Academy #буст

🏗 Архитектурное ревью: как не утонуть в хаосе большого проекта

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

➡️ В статье

📍 Когда приходит время для архитектурного ревью
📍 Какие вопросы стоит задавать, чтобы не собирать техдолг
📍 Как избежать дублирования и держать архитектуру под контролем
📍 Что помогает масштабировать решения и соблюдать стратегию
📍 Почему метрики и наблюдаемость — часть архитектуры, а не бонус

🔗 Читать на Proglib

Proglib Academy #буст

📊 Как СУБД на самом деле выполняет SQL-запрос

Когда Вы пишете SQL-запрос, может показаться, что всё выполняется сверху вниз — SELECT, FROM, WHERE…
Но это не так. Под капотом запрос исполняется в совершенно другом порядке:

FROM — сначала выбирается основная таблица

JOIN — затем к ней присоединяются другие таблицы

ON — указывается, как именно таблицы связываются

WHERE — происходит фильтрация строк до группировки

GROUP BY — строки группируются по указанному полю

HAVING — фильтрация уже сгруппированных данных

SELECT — выбираются нужные столбцы

ORDER BY — сортировка результата

LIMIT — ограничение количества строк

Обратите внимание: оператор SELECT выполняется почти в самом конце, а WHERE работает до GROUP BY. Именно поэтому нельзя ссылаться в SELECT на столбцы, которых нет в GROUP BY или агрегатах.

🔵 Собрали полезные материалы для старта в целый курс → «Основы IT для непрограммистов»

Proglib Academy #буст