Всем привет! Это IT Пингвин 🐧.

Сейчас, как никогда, популярно создавать айтишные Telegram-каналы, и я тоже решил попробовать свои силы. Мне действительно есть чем поделиться, и я думаю, что мой канал будет полезен многим. 💡

О себе:
Мне 25 лет, и я - главный разработчик озера данных в одном из топовых банков России. 🏦 За плечами - опыт работы в крупных IT-компаниях (телеком и банки), а в трудовой книжке есть записи: инженер КХД, ETL-разработчик, Data Engineer. 💻

За последний год я прошел около 30 собеседований, и многие из них подробно задокументировал и разобрал. 📝 Кроме того, я сам проводил собеседования для стажеров, был ментором на стажировках и помог десятку ребят попасть на проекты топовых банков РФ.

Я также занимаюсь менторством: обучаю SQL, Oracle, немного Python, помогаю готовиться к собеседованиям и делюсь лайфхаками из личного опыта. 📚 Еще у меня есть опыт подготовки студентов из ВШЭ и МГУ к экзаменам и выполнения лабораторных работ. 🎓

Несколько фактов обо мне:

• Учусь на работе. Даже будучи главным разработчиком, я продолжаю учиться и развиваться. 📖

• Неосознанно крутил опыт в резюме. Сделаю об этом пост. 🤫

• Играл (и иногда играю) в доту в рабочее время. Ну а кто не играл? 😅

Цели на будущее: хочу попробовать работать параллельно на двух работах и, возможно, на валютной удаленке из РФ. 🌍

Что ждет на канале:
Этот канал - это место, где я делюсь тем, что было бы полезно и интересно мне самому. Здесь будет много полезной информации: от базовых основ для новичков 🐣 до продвинутых лайфхаков и хардкорных инсайдов. 💥

Я буду прикреплять крутые пет-проекты, рекомендовать статьи, книги и бесплатные курсы, которые сам прошел и проверил на себе. 📂
Расскажу о своем пути в IT, поделюсь личным опытом и лайфхаками, которые помогли мне расти. 📈

Будет много информации с собесов: как составить резюме, которое заметят, какие вопросы задают на собесах, как решать задачки, торговаться за оффер и на что обращать внимание при выборе компании. 💼 Буду делиться своими кейсами прохождения собесов (привет реджектику) - от первых шагов до успешных офферов. 🎯

Но самое главное - этот канал будет правдивым и искренним. Да, я многое знаю, и на всех работах мною были довольны: меня ценили за результат, не хотели отпускать и перебивали офферы . Но я всегда помню, что мне еще очень многому нужно научиться. Поэтому я постоянно учусь, ошибаюсь, и (добавим пафоса) падаю и снова встаю. 💪

Я буду писать не только о своих успехах, но и о неудачах, банальных открытиях, провалах и даже конфликтах. Потому что именно через ошибки мы растем.

Этот канал - для тех, кто хочет развиваться в IT, учиться на реальном опыте и не боится быть искренним. Присоединяйся! 🐧✨

Чем отличаются WHERE и HAVING?

Это один из самых популярных вопросов на стажера, джуна и иногда мидла de/da. Я думаю, практически все знают что нужно отвечать.

Вот, например, в тг канале @data_analysis_it был дан такой ответ https://news.1rj.ru/str/data_analysis_it/83 :

Чем отличаются WHERE и HAVING?
WHERE
• GROUP BY не обязателен
• Применяется к отдельным строкам таблицы.
• Не может использовать агрегатные функции
HAVING
• GROUP BY обязателен
• Применяется к результатам агрегатных вычислений.
• Может использовать агрегатные функции

Все четко и понятно.

Deepseek даст такой краткий ответ:

Кратко:
1. WHERE:
• Фильтрует строки до группировки или агрегации.
• Работает с отдельными строками.
• Не может использоваться с агрегатными функциями.
2. HAVING:
• Фильтрует группы или результаты агрегации после группировки.
• Работает с группами строк или агрегатными функциями.
• Используется только с GROUP BY или агрегатными функциями.
Главное: WHERE — для строк, HAVING — для групп. 😊

Примерно тоже самое.
Это база, ее обязательно надо знать. В целом такого ответа на собеседовании будет достаточно.

НО! Но я вам хочу рассказать о важном нюансе, о котором очень много инженеров не знает:

HAVING можно использовать без GROUP BY!

Пример:

select max(campaign_id) from public.costs
having max(campaign_id)>2
--Результат 100.

select count(campaign_id) from public.costs
having count(campaign_id)>1000
--Результат 39300

В примере HAVING применяется не к группам, а ко всей таблице в целом, в данном случае группой является вся выборка. То есть в select-e выполняется просто функция, допустим count(*) , ко всем данным, но и еще можно сразу добавить фильтр по этому значению.
Вроде ничего важного, вряд ли кто-то таким образом будет использовать having без group by, просто прикольная фишка.
На самом деле данная фишка используется.

На моей прошлой работе, в одном красном банке, в архитектуре ETL была настроена система Eventwait-ов (флагов) таким образом:

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

Каждые 5 минут запускается мониторинговый поток, который запускает кучу селектов и проверяет готовы ли источники.
Код там был примерно такой:

-- проверка логов за сегодня по каждой таблице
select count(t2.job_id)
from control.workflow t1 inner join control.log_loading t2 ...
where t1.workflow_name = t2.workflow_name
and t2.loading_id = ($$p_ loading_id)
and t2.status = 'succeeded'
...
and t1.table_name = 'table_name'
and t2.operation_day = to_date('$$p_operation_day","yyyymmdd')
having count(t2.job_id) >= 

-- смотрим сколько всего потоков должно грузить таблицу (число фиксированное)
(select count(workflow_name)
from control.md_workflow t1
where table_owner = 'table_owner'
and table_name = 'table_name')

В этом запросе у нас идет сравнение по каждой таблице-источнику за отчетный день – сколько отработало сегодня потоков для ее загрузки и сколько потоков вообще грузит таблицу. Пока у нас все потоки за сегодня не прогрузят таблицу, проверочный select выдаст 0 строк. И потоки в слое витрин данных не грузят свои таблицы, пока не готовы их источники (пока в результате запроса нет строк).
Если в результате какого-нибудь select-a у нас есть число ( чаще, просто 1, тк в основном одну таблицу грузит один поток), то значит этот флаг пришел. Как только все флаги для определенного потока пришли, запускается расчет таблицы из слоя витрин.

Я не скажу, что это хорошая система. Это скорее легаси, сейчас делается по-другому. Но примерная система есть во многих «старых» компаниях.

В общем, GROUP BY для HAVING-a не обязателен.


Кстати, если у deepseek-а спросить об этом напрямую, он скажет, что можно использовать having без group by, но с оговоркой:

В большинстве СУБД (например, PostgreSQL, MySQL) это допустимо, но в некоторых (например, Oracle) может вызвать ошибку»

От себя добавлю - в Oracle это тоже работает. Так что всего проверяйте ответы нейронки😊

#Вопросы_с_собесов

Предыстория: 📚

Книги я особо не читаю. Начал читать в 20+ лет и только в последний год читаю одну книгу в два месяца. Читаю художественную литературу (нравится больше всего), техническую и историческую.

Бизнесовую/саморазвития/психологическую литературу не очень люблю. Как-то начал читать всеми известную «Богатый папа, бедный папа». Прочитал страниц 15 и бросил. Банальщина... 🙄

Недавно купил еще одну классику «Думай и богатей» (авт. Наполеон Хилл), просто ради интереса. Это похоже на прародителя инфоцыган, там есть основные заповеди для достижения цели – мечтай, воображай, верь и перечитывай эту книгу каждый день.. 🫢
Но читается легко. Там приводятся в пример истории реальных людей, и это иногда интересно. 🧐

Зачем я об этом вообще пишу:
Книга 1937 года! И вот вчера я наткнулся на такой абзац ( фото в закрепе).

Почти 100 лет назад в Америке уже учили, как составлять резюме и продавать себя. Многое из рекомендаций сейчас, конечно, неактуально – печать резюме на дорогой бумаге, класть его в очень дорогую, красивую папку, делать фото в крутой студии и т.д.

Просто как факт, 100 лет назад в США уже была корпоративная культура, многие люди уже были заряжены на построение успешной карьеры. 💼✨

А до нашей страны это дошло недавно. Ну, наверное, лет 20 назад (можете поправить)..
В России всё только зарождается, и у нас есть большие перспективы преуспеть в корпоративной культуре. Но считаю нормальным и очень полезным перенимать опыт западных стран, модифицировать, улучшать и применять его у нас. 🌍🚀

Что думаете? 🤔 Может, у вас есть свои примеры или мысли на эту тему? 💭

#книги

Вопросы про джоины:

Буду делать серию постов про самые популярные вопросы по sql секции.
Я думаю, на любом собесе будут вопросы про джоины. Давайте разберем популярные вопросы/задачи:

1) Минимальное и максимальное количество строк в результате джоинов.

Допустим левая таблица t1 (поле id) – 100 строк, правая таблица t2 (id) – 10 строк

inner join:
Min – 0 строк. Если никаких пересечений нет, в двух таблицах нет одинаковых id.
Max – 1000 строк. Если в двух таблицах только одно значение (например, 1). Просто делаем перемножение.

left join:
Min – 100 строк. Если никаких пересечений нет, в результате будут все значения из левой таблицы.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

right join:
Min – 10 строк. Если никаких пересечений нет, в результате будут все значения из правой таблицы
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

full join:
Min – 100 строк. Вот этот момент важно понять, на нем часто допускают ошибки. Минимальное количество при full join будет – количество строк из большей таблицы. Например, в левой таблице значения от 1 до 100, а в правой от 1 до 10.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

cross join:
Min и Max – 1000 строк. Делаем перемножение.

2) Сколько строк вернет операция FULL JOIN, если известно следующее:
INNER JOIN - 6 строк
LEFT JOIN - 10 строк
RIGHT JOIN - 12 строк

Давайте попробуем ее решить без запоминаний и просто понять.
Если вспомнить круги Эйлера (о их корректности будет отдельный пост):
FULL JOIN – это левая непересекающаяся часть + средняя пересекающаяся часть + правая непересекающаяся часть. Просуммируем эти три части:
FULL JOIN = (LEFT JOIN - INNER JOIN) + (INNER JOIN) + (RIGHT JOIN - INNER JOIN)
FULL JOIN = (10 - 6) + (6) + (12-6)
FULL JOIN = 16

Также если раскрыть скобки, то можно понять, что по сути
FULL JOIN = (RIGHT JOIN) + (LEFT JOIN) – (INNER JOIN) = 10 + 12 – 6 = 16

3) Заполнение результата после всех видов джоинов.
Такую задачу тоже часто дают, здесь важно не запутаться. Я приложил скрин с результатами джоинов, внимательно изучите. Особенно обратите внимание на результат соединения дублей и null-ов.

Расскажите какие у вас были интересные вопросы про джоины: 💭


#Вопросы_с_собесов

Вакансия: Senior DWH разработчик
Компания: Магнит TECH
Предполагаемая вилка: от 270к на руки
Период собеседования: Декабрь 2024
Формат работы: Удаленная работа
Этапы собеседований:
HR -> Tech Interview -> Offer
Краткая справка о процессе интервью:
Собеседовал тех лид команды, который был очень технически подкован. Тех лид задавал интересные вопросы про опыт работы, моделирование, индексы, оптимизацию, план запроса и дал пару задачек. То есть он не просто задавал банальные вопросы, а копал все глубже и глубже, чтоб понять уровень знаний. И большой респект, что сам давал какие-то ответы и объяснял технические нюансы.

Более подробно:

Я рассказал о своем опыте. Тех лида заинтересовал опыт с созданием с нуля витрины данных. Он спрашивал про выбор модели, как я оценивал объем данных и прогнозировал что будет через год. Спрашивал про типы полей, размерности, индексы.

Блок про моделирование. Снежинка/звезда/ - где что используются, плюсы и минусы. Data vault- что это и за счет чего достигается гибкость.

Большой блок вопросов про внутренности БД - про план запроса, статистику, кардиналити, какие бывают методы доступа к таблицам. Индексы – что это и какие виды знаю, чем отличается бинарное дерево от сбалансированного, сколько уровней в сбалансированном дереве, битмап индекс. Методы физического соединения – какие есть виды(по каждому виду задавал много вопросов), какой метод соединения предпочтителен при соединении больших таблиц (важно учитывать какая СУБД), что такое хэш мапа, почему по ней быстрый поиск.

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

Через неделю пришел отказ, так как магнит тех переезжает в облако и им нужен более опытный инженер (ближе к архитектору), который также шарит за S3 и желательно Impala.

Люблю такие собесы – получается бесплатная проверка знаний + собеседующий много всего сам объяснил и сказал, что можно изучить. Отношение к компании улучшилось.
Еще из интересного вакансию нашел не на hh, а на их сайте и сам отправил свое резюме.

*идея позаимствована у https://news.1rj.ru/str/get_rejected

#Собес

Недавний пост про джоины набрал много просмотров и репостов. Значит такая информация интересна.
Продолжим наваливать базу 🤝

Популярные вопросы с собесов (lvl junior):

1) В какой последовательности СУБД на самом деле выполняет команды запроса:

select distinct
from
join
where
group by
having
order by
limit

Ответ:
Порядок выполнения SQL-запроса:
1. FROM (и JOIN) – выбираются таблицы и соединяются
2. WHERE – фильтруются строки
3. GROUP BY – группировка данных
4. HAVING – фильтрация групп
5. SELECT – выбор полей (включая вычисляемые)
6. DISTINCT – удаление дубликатов
7. ORDER BY – сортировка результатов
8. LIMIT / OFFSET – ограничение вывода

Более удобный вид:

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT

2) UNION ALL vs UNION - в чем разница?

UNION ALL:
• Не удаляет дубликаты
• Работает быстро (простое объединение)
• Сохраняет исходный порядок строк
• Используется, когда важна скорость и нужны все данные

UNION
• Удаляет повторяющиеся строки
• Работает медленно - требует сортировки (ресурсозатратно)
• Может изменить порядок строк
• Используется, когда нужны уникальные записи


Также могут дать простую задачку:

Даны таблицы T1(col1, col2), T2(col1, col3).
Наполнение таблиц:

T1
(13, 15)
(13, 15)
(13, 15)

T2
(13, 15)
(13, 14)

Будет ли работать запрос? Если будет работать, то сколько строк вернет?

SELECT * FROM T1
UNION
SELECT * FROM T2

Ответ:
Будет работать если тип полей в таблицах одинаковый (но возможно некоторые СУБД итак могут сделать неявное преобразование).
Вернется 2 строки:
13 14
13 15

3) Отличие UPDATE TABLE от ALTER TABLE.
Немного странный вопрос, но в этом и прикол. Некоторые джуны на нем тупят 😄

UPDATE TABLE:
• Изменяет сами данные в таблице (строки)
• Пример: UPDATE users SET age = 30 WHERE id = 1;
• Тип операции - DML (Data Manipulation Language). Поэтому операции нужно COMMIT-ть или при необходимости можно откатить - ROLLBACK
• Блокирует строки (зависит от СУБД). *Про блокировки сделаю отдельный пост, тема непростая.

ALTER TABLE:
• Изменяет структуру таблицы (добавить/удалить/изменить поле, ограничение, партицию, переименование таблицы и тд.).
• Пример: ALTER TABLE users ADD COLUMN email VARCHAR(100);
• Тип операции - DDL (Data Definition Language). Авто COMMIT, откатить нельзя (но есть нюансы, зависит от СУБД)
• Может блокировать всю таблицу


Подскажите плз вам интересна эта тема? Предлагайте свои варианты по чему можно навалить базы?


#Вопросы_с_собесов #база #sql #jun