Идти с этим на собесы и считать квадраты остатков :)

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

Тратить, набивать опыт, снимать страхи

При том, что можно на это потратить от 30 мин до 1 часа и даже не получить задание, если рекрутер думает, что он видет всех насквозь

Конечно не каждый рекрутер такой

В крупных компаниях, как правило, рекрутёры довольно адекватные и особо не будут по предметной области гонять - у них несколько другие задачи. Вот в компаниях помельче могуТ сидеть в кадрах молоденькие девчушки лет 25-30, которые, честно говоря, не совсем адекватно кандидатов оценивают. Могу даже завернуть кандидата из-за отсутствия у него аккаунтов в соц. сетях.
А по поводу Ваших знаний, то, как по мне, главное - понимание мат. части, а вот технологический стек - вопрос уже вторичный и дело наживное. И, как уже ранее сказали - дерзайте, пробуйте, и, после нескольких собеседований у Вас появится более чёткое понимание того, на что стоит обратить внимание.

Да,  это точно. Как говорят, платон мне друг, а истина дороже

Честно больше ставку делал на прогу. А пришел к тому, что нужны методы, как например, решение исходов цикла через уравнение как в задании ЕГЭ, где нужно подобрать такое s при котором n будет равно 64.

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

Языки, фреймворки, библиотеки - это всё вторично. Понимание принципов, алгоритмов, архитектуры - гораздо важнее.
Просить написать на собеседовании программу - это вообще зло, я считаю.
Даже отличные специалисты тут могут запнуться, поскольку у каждого свой стиль и темп работы, которые далеко не всегда
может нормально встроиться в формат собеседования.
Поэтому, подход всяких Гуглов и Яндексов мне, честно говоря, совсем не близок,
поскольку так можно потерять действительно ценных специалистов, которые посмотрят на всю эту ерунду и плюнут.
Как я сам не раз делал, да и мои коллеги, в профессионализме которых не приходится сомневаться.
Но это, конечно, всё субъективно.

👍👍👍

Код на листочках - довольно стрессово, если честно. Тем не менее, многие компании практикуют. Что мне попадалось на этапе лайв-кодинга (мне "свезло", в последних двух местах, куда я собеседовалась, был отдельно этап теории, отдельно этап лайв-кодинга) - много SQL с джойнами, group by, having, оконки. Python - написать свои функции с поиском значений в столбце, apply(), разобрать json, визуализация. В общем-то, все подъемное.

Кстати, я писал тест на бумаге по Sql, 4 простых запроса)

Да, про это и говорил. Во-первых - стресс, а во-вторых - совершенно не показатель, как показывает практика.

Признаюсь, ещё в 2000-х, когда собеседовал на рядовые, да и не очень, позиции,
часто спрашивал про принципы оптимизации SQL-запросов (индексы, партиции и т.п.).
Поскольку очень часто была проблема, что аналитик, зная базовый SQL, но совершенно
не разбираясь в основных принципах написания запросов и базовых принципах проектирования физической структуры таблиц,
писал запрос, который мог работать полдня и больше. Потом подходишь, вносишь в запрос небольшие правки и - вуаля, - запрос работет секунды вместо часов.
Поскольку тогда практически всегда работали на SAS-е, то эта проблема очень сильно мешала работе.
Честно говоря, я часто в императивном порядке запрещал своим сотрудникам использовать proc sql в SAS.

Это как с
Order by author
having Max(price) and author = 'Булгаков'?

Да, примерно так.
Вот за что люблю SAS, особенно, если в нём не использовать SQL,
так это за то, что там  надо сначала думать над тем, что собираешься сделать,
продумывать физическую структуру, индексы или сортировки,
потому, что без этого data step в SAS-е просто не будет работать.
А вот на SQL написал, что душе угодно, а потом ждешь - когда же это отработает?

А потом думаешь - почему же такой результат получился.

Приходи на бесплатный вебинар от школы TIME IT и сделай первые шаги в сферу IT 👨🏼‍💻👩🏻‍💻

Выбирай свой уровень, переходи в бот и жди завтра👇🏻

1️⃣ Базовый (для новичков)

✅ t.me/Python_Bazovyj_bot

На вебинаре мы обсудим, где и для каких задач используется Python, а также установим среду разработки и НАПИШЕМ ПЕРВЫЕ ПРОГРАММЫ.

⏰ Дата вебинара: 19 сентября в 18:00, подробности в боте после регистрации


2️⃣ Продвинутый (для тех, кто уже в теме)

✅ http://t.me/Python_ProfessionalBot

На вебинаре мы обсудим профессию Data Engineer: какой спрос на специалиста этой профессии на рынке; достоинства профессии; чем занимаются эти специалисты; как стать дата-инженером с нуля.

+ УЖЕ решим простейшую задачку (загрузить "csv" из апи; залить "csv" в базу  sqllite; написать sql запрос к базе; сохранить результа в "json")

⏰ Дата вебинара: 19 сентября в 19:00, подробности в боте после регистрации

"понимание мат. части, а вот технологический стек - вопрос уже вторичный и дело наживное."
да истинно звучит, но одно другому не мешает, мне кажется, если понимать как работает np.dot(A,B) - лишним не будет знание как реализовать функцию или алгоритм или регрессию.