Вопросы по SQL и Базам Данных на интервью
HTML-код
- Опубликовано: 28 июл 2021
- Поддержать меня: boosty.to/mflenov
Я в основном проходил интервью на должность Backend или Full-stack программиста, а эти интервью очень часто сопровождались вопросами по SQL. Может мне везет, а может я так уверенно всегда отвечаю на первые вопросы, что мне уже не задают более сложных, но на мой взгляд на интервью всегда были очень простые вопросы по базам данных SQL.
В этом видео расскажу о тех вопросах, которые мне регулярно задавали.
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.ru и www.flenov.info
Мой просто блог blo.moe
Tweeter: / flenov
Инстаграмм: / mflenov
Телеграмм: t.me/mflenov
Вторая часть видео здесь ruclips.net/video/ZdUiJImKyic/видео.html
В такую жару очень сильная жажда, спасибо тебе Автор !
Очень интересные комменты. Надо почитать, поучиться) Спасибо, кто пишет и спорит!! Михаилу огромное спасибо за материалы!
вода водичка... не досмотрел, уснул
Спасибо за видео. Ваша книга "Компьютер глазами хакера" в свое время перевернула моё представление о компьютерах, оказалось, что в них можно не только играть.
Спасибо тебе. Параллельно с шарпом начал учить еще и SQL и если с шарпом уже знаю какие вопросы задают и могу на них отвечать +- то по SQL понятия не имел о чем спрашивают
Спасибо за видео!)
Лично я когда делаю join для исключения всегда помечаю его как LEFT OUTER JOIN так наглядно понятно что мы именно исключаем включения
Спасибо за видео.
Очень познавательно :)
Спасибо
Классное видео и не понимаю, почему так мало лайков/просмотров/комментариев. Народ, напишите хоть что-то в поддержку
Спасибо за видео
Проходил интервью на разработчика БД. Вот там вопросы такие никто не задает. Там задачи - капец какие тяжелые. Даже CTE не обойтись. А еще и в целом требуют понимая внутреннего процессинга работы базы, что какие физические связи используются и пр...
Если именно баз данных, то возможно, я на фулстека/просто программиста в этом видео рассматривал, тут прям глубокие знания базы не нужны
Где это Вы так устраивались?) у нас на любую позицию нужны очень глубокие знания
@@jns8223 Ну для фулстека не нужно знать администрирование. Главное понимание основных вещей. Я чуть обрезал видео и чуть подробнее выложу вторую часть чуть позже
Вот такой вопрос, имею опыт и понимание как и что с чем связать чтобы получить нужную выборку, а вот по памяти создать запрос с подзапросом и вытащить данные не всегда получается, часто в инете подглядываю как правильно пишется выборка, так же касается и в принципе кодинга, ты логически понимаешь что должен сделать и какие скрипты написать, но базовые методы не все помнишь, ты знаешь что есть такой и что он делает, а как он пишется и сколько параметров на входе, не помнишь, к этому сильно придираются на собесах? Не знаю как у других, но сложно все запомнить, когда ты столкнулся с темой, прочитал, понял ее, порешал не сколько задач и побежал дальше, а позже появляется похожая задача, а ты уже забыл как ее делать, приходится тратить время и освежать память, поднимать материал чтобы снова решить... заниматься новым материалом по методу Германома Эббингауза - "кривая эббингауза" не всегда получается, продуктивность к вечеру снижается, куча дел и других занятий, так что после работы не всегда в кодинге... раскройте эту тему или поделитесь своим мнением и подходом к такой ситуации.
Это нормально помнить только базу и постоянно подсматривать. Я постоянно гуглю, потому что имея опыт работы с 10 языками программирования очень сложно помнить все нюансы даже после стольких лет программирования. Просто когда гуглишь не копируй решение, а пиши сам руками и вырабатывай машинальную память
@@Dev-lessons после выхода ChatGPT у всех резко ухудшидся память. после выхода ChatGPT у всех резко ухудшится память.
Спасибо за видос.
Подскажи ты с MS SQL работаешь на Маке?
Нет, для этого у меня MS Surface Pro, я его тут показывал ruclips.net/video/-s-5W_aoKeU/видео.html
Меня передёрнуло, что для фильтрации покупателей делается LEFT JOIN, т.к.при наличии более одного заказов кол-во Customer начинает множиться (придётся добавлять DISTINCT и указывать явно колонки Customer или c.*). С EXISTS() таких проблем нет, а так же оптимизатору запросов обычно не выносит "мозг".
По моему мнению если идёт отбор по какой-то связанной таблице, то его лучше сделать через EXISTS. С тормозами по NOT EXISTS не сталкивался, да и такое как правило в моих задачах не требовалось.
Можно еще косячный вариант для отбора заказов по городу: SELECT * FROM "Order" WHERE CustomerId IN (SELECT CustomerId FROM Customer WHERE City = 'London')
Косяк в том, что условие IN при большом кол-ве идентификаторов в условии (более 1000) начитает выполняться медленнее JOIN и EXISTS.
А в остальном спасибо.
таааааааааак....
Я только начал учить sql, что не так с country="London"?
Или имелось в виду что обязательно ставить перед ним алиас?
С точки зрения SQL все верно, а вот с точки зрения логики - Лондон не страна, это город
@@Dev-lessons понял, спасибо)
Ну мало ли кто базу создавал))) Может там Кипр - планета вне нашей галактики)
А можно подробнее про [Order] в квадратных скобках? Что это значит? Есть ли разбор? Спасибо за видео.
Любое имя таблицы или колонки может быть в квадратных скобках и это указывает на то, что перед нами объект базы данных, а не SQL. Просто в SQL есть ORDER BY и имя таблицы Order приводит к тому, что база данных думает, что хотим сортировать. Квадратные скобки [Order] помогают понять, что это точно не SQL, а колонка или таблица
@@Dev-lessons а, точно, спасибо большое)
Могу ли я поинтересоваться почему с left join используем условие where ? Думаю вы не обратили внимание на это
Это про какой момент?
Если ты про where c.City = 'London', то это можно делать, ведь я фильтрую по левой таблице. По правой не стоит, потому что это сразу изменит смысл запроса.
@@Dev-lessons смотрите при таком раскладе в вашем случае да и вообще полученный результат не изменился бы если вы в место left вставили бы inner я могу дальше пойти и разъяснить все ну или могу сослаться на человека на преподавателя международного статуса Microsoft certified master на Саморрдова Федора Анатолиевича
@@user-bt9iv7zz5b Изменился бы, потому что в Where я фильрую только по левой таблице. Если поставить inner, результат будет другой. Вот если в where фильтр идет по правой таблице, то это автоматом превращает в inner.
@@Dev-lessons я дописал свое предедущее сообщение я спорить щас не буду просто написав where фильтруя по левой хоть по правой результат равен тому что фильтровать при inner хоть левую хоть правую. + При левом джойне с условием where вы теряете данные а когда вся суть левого сохранить все что храниться в левой таблице
Меня обычно спрашивали про индексы, зачем они нужны, какие бываю, просят написать запрос, как оптимизировать запрос. Самый сок, как-то раз спросили про требования ACID и уровни изоляции транзакций
Это в какой стране? Просто я хотел показать, какие простые вопросы в Канаде
@@Dev-lessons В России. Очень разный уровень на собесах, зависит от интервьюера и компании
Название компании в которой вы работали какое-то знакомое. Ceridian? Если он - то довелось с ними поработать. К SQL были своеобразные требования -With(NoLock) обязателен и "* " категорически запрещены...
В командах, где были проблемы с производительностью, их решали за счет добавления NoLock. В нашей команде это было запрещено, потому что читать сырые данные это зло и проводит к проблемам. Вместо этого надо оптимизировать запросы.
@@Dev-lessons Правильно, оптимизация лучшее решение... иногда еще и рефакторинг базы с переосмыслением бизнес-логики (это павда больнее и сложнее). Увы указы начальства иной раз выше здравого смысла. Когда работаешь на аутстафе, очень часто, требования DBA компании, на которую работаешь, гораздо более значимо. За 20 лет работы со странностями DBA сталкивался много раз. (И хейтеры Left Join, и фанаты DTS package где надо и не надо)
вопросы какие не буду говорить" харош чел харош. крутой ролик
Во первых видео про канаду и про фулстекеров, а не БДшников. Просто уточнить и убедиться, что вы посмотрели видео.
А какие вопросы спрашивают у фулстекеров у вас?
Да, если бы я жил в Канаде, я бы прошёл все интервью) у нас в Украине намного сложнее пройти…
Ну помимо SQL у фулстеков спрашивают достаточно много других вопросов. Чисто админов и программистов баз данных думаю тоже будут спрашивать более серьезно
Спасибо за видос, очень кстати и как всегда, классная подача. Я сейчас столкнулся с задачей, решение которой пока не не нашёл. Суть в том, что есть 2 таблицы, одна с поездками, а другая с людьми. Так вот задача, хранить в одном из полей поездок список людей. Не одно значение, а именно много. Я пока нигде не нашёл толкового решения. В идеале бы вообще хранить массив объектов ... Это реально ?
В колонке список хранить не стоит, это плохо. Возможно нужно пересмотреть требования и решить как-то по другому, ввести дополнительную таблицу как при многие ко многим
это нарушение даже первой нормальной формы, не стоит так делать если ты точно не знаешь что делаешь
В чем проблема? Храните в xml ваш массив данных, тем более есть такой тип в ms sql например. Нет никаких нарушений 1 формы.
Вряд ли вам уже актуально, но может пригодится кому-то кто потом читать будет. У вас есть 2 таблицы - Поездки (в которых может быть список людей) и Люди(У которых в свою очередь может быть много поездок). Подобные связи, если делать напрямую, нарушают нормальные формы(Общепринятые стандарты построения таблиц. Погуглите первые три нормальные формы в sql), и что б сделать такое по нормальному, нужно использовать взаимосвязь "многие ко многим" - вынести наши повторяющиеся поля в отдельную таблицу (тут что б понять, желательно загуглить все три возможные связи между таблицами - один к одному, один ко многим и многие ко многим)
@@arahnid_9844 стоит уточнить что в отдельную таблицу выносятся только айди поездок и людей, то есть табличка будет с 2 столбцами, тогда если нам нужно вытянуть поездки с людьми то это делается через два джоина: таблица поездки - > join (по айди поездки) сводная таблица -> join (по айди людей) люди
Не скажу, не помню... Нет тайм-лайна. Остановил просмотр на 3-й минуте и закрыл окно
Ничего страшного
Подскажите, как правильно хранить N-е кол-во файлов в локальной БД(mssql)? Пример проблемы: Есть приложение на шарпе, для учета студентов. Есть таблица студентов, у каждого студента имеется папка с его документами (фотки паспорта, снилса, свидетельства о рождении...). Потом эти файлы будут использоваться для печати.
У MS SQL есть возможность хранить файлы прямо внутри базы данных (плохо) и как бы в базе, но в отдельном хранилище (лучше). Я же просто храню в файловой системе всегда, а в базе сохраняю только путь к папке
Я тоже не люблю программировать на интервью.
На рабочем месте так не ограничивают жёстко время и там можно гуглить. Никто не запрещает.
ну у меня на интервью гуглят, я не ограчичиваю
@@Dev-lessons если нужно показать умение кодить я бы например предпочёл задачу с готовыми 4-5 вариантами ответов. И соискатель должен выбрать правильный (-ые) ответы и объяснить почему именно эти варианты.
database designer online советую, схему рисовать куда удобнее
Меня спрашивали, что такое cursor.
Что это или предлагали использовать в задании? Если просто спросили зачем, то это норм, если было задание на использование курсоров, то я бы задумался, везде на работе была рекомендация - не использовать курсоры, потому что они медленные.
@@Dev-lessons Просто спросили, знаю ли. Я незнал и никогда не слышал)) Он сказал, что его не рекомендуется использовать, но просто знаю ли я. Интервью было на джуна разработчика. Потом конечно я почитал про это.
Ну это скорее на бегийнера =) а вот мидл+ я люблю играть в "васю". Звучит задача так. Есть таблица с именами. И есть в ней Вася. Запрос - найти васю. Тогда запрос будет типа select * from t where name = вася. Ок. А теперь собственно вопрос: А сколько вы сможете придумать конструкций любой степени извращизма что б найти в таблице васю, НО. Слово WHERE не должно встречаться в запросе =)
Кстати, сколько придумаете вариантов? =)
надо подумать. первое, что прилетело в голову:
select top 1, case when name = Вася then 1 else 2 end, * from table order by 1
@@Dev-lessons т.е. если топом окажется петя, то ой? )))
Подсказываю - иннер на себя. Селект константы. Интерсект. Кросс апплай. хэвинг. На самом деле это только нахрапом =) кейсом тоже можно. Но не так как вы указали. Кстати, а как оно заработает? ;)
почему Петя откажется на первом месте, если. а есть ордер? с case будет проблема если в базе больше одного или нет ни одного Васи
@@Dev-lessons О. Читал в пути и не вдумался. Точно ))) Что-ж, значит +1 вариант. Хотя этот кейс красивее б перенести в ордер и выбрать top 1 name =) Что-ж, значит ещё + 1 вариант.
Согласитесь - классная задача? ))) Обожаю её. И так жаль что очень редко получается в неё поиграть =(
А ещё, из любимого. Даже мидлы иногда ловятся:
Задача - я загружал в таблицу поля имя и отчество. И вот лошара я такой - перепутал их местами. Как мне написать запрос что б поменять их местами обратно?
Про все базы не знаю, а в MS SQL просто присваиваешь и не нужно выделываться update t set firstname = lastname, lasetname = firstname
Я не уверен, что такие задачи что-то скажут о том, как думает кандидат. Надо будет попробовать спросить кандидатов и посмотреть, что будет
order by надо во внешнем запросе писать, там где top (3) указан. Во внутреннем - можете словить "неожиданный баг" (Хотя очень даже ожидаемый)!!!!
Это с какой базой? top действительно может давать проблему с order by, но как раз во внешнем SQL. Я в реале это никогда не видел, но слышал. Смысл в том, что вроде как top выберет N записей и потом отсортирует. Когда order by во внутреннем запросе, то он возвращает отсортированный список и из него мы выбираем top.
Опять же, в MS SQL Server я только слышал о проблеме. Вот здесь есть пример народ обсуждает
stackoverflow.com/questions/58344541/sql-server-query-problem-with-top-and-order-by
@@Dev-lessons , нет. Сначала идёт сортировка и только потом отработает top. То что обсуждает народ по приведённой ссылке, как раз непонимание того, что top во внутреннем под запросе выберет случайные две записи, и только потом во внешнем отсортирует и выберет из ранее выбранных.
Опять таки у вас идёт join. Т. Е соединение двух дата сетов. В каком порядке (ордере) пойдёт это соединение? В порядке первого дата сета или в порядке второго? А почему вы так считаете?
Только чёткое указание ордера гарантирует порядок вывода строк. Топ работает ПОСЛЕ сортировки.
Как я сказал, у меня доказательств проблем нет. Единственное, о чем я слышал, но не имел доказательств - это обсуждается по ссылке. Так что не совсем понимаю, о каком баге ты говорил в комментарии.
@@Dev-lessons, Ну что ж, давайте попробую найти для вас доказательства и ссылки на документацию:
1) Система, которую вы назвали проблемной (MS SQL Server) не дает программисту совершать логические ошибки, какие показаны в видео. При попытке выполнить указанный запрос получим ошибку
Msg 1033, Level 15, State 1, Line 11
The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions, unless TOP, OFFSET or FOR XML is also specified.
2) Логически подумав самостоятельно (Наводящий вопрос я уже задал в предыдущем комментарии, но как-то он прошел мимо вас и остался без ответа), можно прийти к выводу, что не все так однозначно, как вы думаете. Выберете вариант ответа для следующего запроса:
select * from (select top (999999999) * from XXX order by Name) X inner join (select top (999999999) * from YYY order by Name) Y on ....
--Без "top" во внутренних подзапросах не сработает, поэтому добавив TOP "обманываем" сервер, чтобы смоделировать приведенный вами пример.
Вот этот запрос в каком порядке вернет строки? Варианты ответа, выберете свой:
а) В XXX.Name
б) YYY.Name
в) Как бог на душу положит
г) Как оптимизатору будет проще конкретно в данный момент времени.
Какой вариант вы выбрали?
3) Ну и наконец идем в документацию к любому SQL серверу, например к тому же MS, и читаем про логический порядок выполнения операций: docs.microsoft.com/en-us/sql/t-sql/queries/select-transact-sql?view=sql-server-ver15#logical-processing-order-of-the-select-statement
Документации по остальным СУБД искать лениво, но любые форумы и т.п. легко дают ответ, что top/limit/offset выполняются *ПОСЛЕДНИМИ* и никак иначе.
Например:
andreyex.ru/bazy-dannyx/baza-dannyx-mysql/poryadok-operatsij-sql-v-kakom-poryadke-mysql-vypolnyaet-zaprosy/
planshet-info.ru/kompjutery/porjadok-vypolnenija-operatorov-sql
Ну и куча других ссылок по поисковому запросу:
www.google.com/search?q=%D0%BF%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA+%D0%B2%D1%8B%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F+%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%B9+sql+%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%B0&newwindow=1&sxsrf=AOaemvLE_g3G6wIi0CeOjNCAHAY9tUCOXQ%3A1636167924917&ei=9PCFYdirN4a6kwX4oZSYCw&oq=%D0%BF%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA+%D0%B2%D1%8B%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F+%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%B9+sql+%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%B0&gs_lcp=Cgdnd3Mtd2l6EAMyBQgAEM0CMgUIABDNAjIFCAAQzQIyBQgAEM0CMgUIABDNAjoHCAAQRxCwAzoHCCMQsAIQJzoGCAAQDRAeSgQIQRgAUIJOWJ5aYMVfaAFwAngAgAGjAYgBsgqSAQMwLjmYAQCgAQHIAQjAAQE&sclient=gws-wiz&ved=0ahUKEwjY9dO_4IL0AhUG3aQKHfgQBbMQ4dUDCA4&uact=5
PS Чуть не забыл самое главное.. :))) В документации к тому же MS SQL четко сказано: "Упорядочение результирующего набора запроса по заданному списку столбцов и (дополнительно) ограничение числа возвращаемых строк указанным диапазоном. Порядок, в котором строки возвращаются в результирующем наборе, не гарантируется, если не указано предложение ORDER BY."
docs.microsoft.com/ru-ru/sql/t-sql/queries/select-order-by-clause-transact-sql?view=sql-server-ver15
Обратите внимание, что речь идет про *РЕЗУЛЬТИРУЮЩИЙ* набор, а не полученный внутренним подзапросом!!!!
Удачи.
я никакую систему не называл проблемной. я сказал, что единственная проблема, о которой я слышал , но сам не сталкивался ни разу.
1. синтаксическая ошибка возможна, но ты же и переписал запрос неверно, поэтому и ошибка. ничего неожиданного
2. ты опять же записываешь другой запрос, записываешь top в подзапрос, а изначально говорил про order by. не вижу, как связано с моим запросом. ты - взять топ записей из одной таблицы связал с топ другой таблицы и ты не говоришь как должен быть отсортирован результат. совершенно другая логика и конечно же как бог на душу ляжет и чаще всего по первичному ключу первой таблицы если он есть, но не факт, может и не по ключу.
я не могу понять какая проблема именно с моим запросом?
1 он вернёт неожиданный результат? нет.
2. ты можешь переписать его неверно? да
я же в видео даже указал, что необязательно делать подзапрос, можно сделать одним и объяснил почему я написал подзапрос - потому что просто превратить его в решение с partition by
Вторая часть видео интересная, первую половину можно отрезать.
Что-то как-то очень поверхностно. На нормальном собесе (если конечно это не собес на джуна) будут дрочить по индексам, внешним ключам, транзакциям и уровням их изоляции, блокировкам, дедлокам, порядку выполнения запросов, репликации, шардированию, партицированию, профайлингу, денормализации и много чему еще в зависимости от специфики СУБД. А типовой запрос любой более менее опытный разраб напишет, я бы это даже не проверял.
Я говорил из опыта интервью в Канаде, а тут меня ни разу не спрашивали подобные вещи.
Если это и реальные вопросы на собеседовании то только для джуна для которого знание sql идет плюсом и где то в конце списка скилов
Это в Канаде такие спрашивали даже на синьора.
👍👋✊
Существует не только два способа. можно еще и через IN написать
SELECT * FROM models m WHERE m.model_id NOT IN (select o.model_id from owners o where m.model_id = o.model_id);
Можно
Эм, я бы задумался на счет работы в компании, где над тобой стоит менеджер и смотрит) Это какое-то дно. Это значит, что всё горит и всё плохо, и надо быстро чинить или быстро дописывать какие-то куски. Короче дичЪ
Я с таким сталкивался и менеджер стоит не столько, чтобы контролировать, а чтобы даже помочь. Но это все равно, с какой целью он стоит, глаза за спиной по любому действуют
@@Dev-lessons Это в Канаде такое часто у вас было?
@@off6797 В консалтинге может раз в месяц приходилось работать с глазами на спине. Иногда это был даже клиент, подходил и говорил - хочу увидеть что-то на продакшине и сидел с ним что-то анализировал.
видео понравилось. лайк.
если бы автор не вспомнил на 19:23, пришлось бы предъявлять отсутствие сортировки😁
когда-то работал со скулем. нудная, тупая неинтересная работа. не знаю как вытерпел. год жизни в унитаз.
Можно сделать тайм код на первые 3 минуты видео с пометкой: я не помню? Чтобы не тратить время на то что вы не помните или о чем фантазируете. Спасибо
left join vs exists - если надо найти недостающие строки в второй таблице, то только left join, exists будет перебирать все строки, это долго и ресурсоемко
MS SQL Server в большинстве случаев выбирает идентичный план выполнения, он прекрасно понимает, что от него требуется и может вместо loop join без проблем выбрать hash join
@@Dev-lessons да, но если оптимизатор сработает неправильно и размер таблиц существенный - лютые тормоза гарантированы, проверено. Нам так раз аутсорсер подсуропил, в коде когда проверки на not exists увидели…
на больших базах и при сложных запросах сервер действительно может тупить, я сталкивался с таким, но, но были и случаи, когда exists наоборот работал быстрее, когда левая таблица выдаёт малое количество строк, а правая правильно проиндексирована, тогда очевидно напрашивается loop join и сервер с удовольствием это увидит
@@Dev-lessons есть такое, но я стараюсь exists использовать в простых запросах
Всё равно не возьмут... Какая разница знаешь ты нет и насколько хорошо... берут по возрасту внешнему виду и своих... а тебе сразу автоматический отказ. Эти собеседования они не выявляют знаний или понимания. А лишь знание терминологии. для этого надо иметь хорошую абстрактную память... а потом выяснится что человек ничего не понимает. Я всегда оч плохо прохожу собеседования потому что забываю 1 или 2 термина... В результате все считаю что я плохо пишу программы хотя это совершенно не так. реально я оч хороший программист. Только собеседования этого выявить не могут. Потому что для этого надо дать задачку решить. А так тебя обычно спрашивают знаешь ты это или нет. Ты не можешь вспомнить название или они это скажут как-то по новому для тебя и ты скажешь что нет. Потом выяснится что ты это хорошо знал и активно пользовался. Но они назвали это как-то не та как ты полагал... И так было не раз. Ты всегда лучше чем о тебе думают. Потом в процессе работы это становится очевидно. В результате такого собеседования они возьмут не того кто знает, а того кто выучил термины. Человек с такими способностями оч легко пройдёт собеседование. Но не сможет там работать. это люди с хорошей абстрактной памятью. Собственно программирование это не их дело... Их дело изучение иностранных языков. Это переводчики они знают не 1 иностранный язык но плохие программисты. Именно такая категория и выбирается при таком собеседовании. другие обычно не проводят. Хорошие программисты при этом обычно отсеиваются... Собственно на таком собеседовании знания и понимание выявить невозможно а только проверить память... Что вобщем и делается. Я даже не знаю что надо делать чтобы отобрать хороших программистов. а не людей с хорошей памятью. Наверное рекомендательные письма могут сыграть хорошую роль. А вот это интервью скорее плохую... Так получается ибо.
Разработчиков и так гораздо больше, чем нужно, поэтому и интервью сейчас - это способ отсеивания кандидатов.
Очень спорное заявление
А где врпросы то
В видосе
А это видео - это не шутка? Я не программист, я всего лишь консультант по информационной системе. Но те запросы, которые фигурируют в видео, даже для меня элементарны. Нам обычно приходится писать куда более емкие запросы с кучей соединений, подзапросами, временными таблицами. Такие видео посмотришь и не понимаешь, почему ты не можешь работать программистом (у меня нет диплома), если настоящие программисты плавают в простейших вопросах. Расскажите, где найти такие компании, где написание простейшего запроса с одним джоином - уже неплохой шанс попасть на работу ))))
Абсолютно не шутка, меня в Канаде ни разу не спрашивали ничего сложнее, чем в этом видео. Но тут нужно немного понимать, что я проходил на должность программиста и провожу интервью на должность Fullstack программиста. На DBA возможно спрашивают что-то сложнее
@@Dev-lessons Я на DBA точно никогда не целил, хоть что-то и смыслю в проектировании DB. Я в свое время пробовал пройти на должность junior в сфере web разработки, не более. Просто хотел сделать свою побочную деятельность основной. Не вышло.
@@phat80 я учился на джавараше, даже не полностью прошел и устроился трейни. На собеседовании тоже спрашивали запросы по типу показанных в видео. Прошел с первого же интервью, но это наверно повезло, у многих больше времени и попыток занимает. Возможно, вам просто стоило подтянуть другие направления для вашей вакансии. Во всех вакансиях важно знать английский и гитхаб, + кор того языка, на котором вы пишете и самые распространенные фреймворки (хотя я к моменту собеседования фреймворки и бд только начал учить и сильно в этом плавал. Видимо вытащило неплохо сделанное тестовое и хорошее знание кора). Ну и к интервью нужно отдельно готовиться - спрашивают часто такое, что в работе может ни разу не понадобится. Мне помогло то, что я параллельно с учебой перед сном смотрел прохождение интервью на ютубе - много вопросов в итоге знал благодаря этому. В общем, я к тому, что найти работу можно. Даже если вы в небольшом городе живете, и там нет вакансий, есть еще варианты с удаленкой либо с переездом после прохождения собеседования.
@@arahnid_9844 ну тут все дело в том, что вас пригласили на интервью. Меня на интервью не приглашали, так как в моем резюме не за что зацепиться. Опыт большой, но далекий от программирования.
@@phat80 так у меня ведь такой же нерелевантный опыт. Я свичнулся с наладчика станков вообще) Кстати, за резюме забыл - тоже лучше посмотреть как его нужно оформлять. Но вообще, по моему опыту - если в резюме указаны все нужные технологии, и оно нормально оформлено, как минимум некоторые будут присылать тестовое задание. А его без опыта однозначно лучше делать - как минимум будет что залить на свой гитхаб и будет о чем потом поговорить на собеседовании с той компанией что вас позовет. Ну и откликаться на все джуновские вакансии которые подходят по стеку. Мне тоже далеко не все компании писали, но если с вами не связывались вообще, скорее всего реально в резюме проблема. Может под вакансию его не адаптировали (сейчас в во многих фирмах, насколько я слышал, стоят программы, которые отсеивают резюме если нет ключевых слов. И если в вакансии указано SQL, а у вас, допустим MySQL - уже можно пролететь), может было много лишнего текста - вроде подробного описания предидущего нерелевантного опыта работы, вместо короткой выжимки. Может контакты не указаны, или фото стояло некорректное - сложно сказать не видя само резюме) Но если вы отправляли во много компаний, а обратной связи вообще не было, это прям 100500% что что-то не так с резюме. У меня из 25 рассылок, 3 тестовых пришли, из которых после 2х пригласили на собеседования. Опыта само собой было по нулям
Первый!!!
как обычно
@@Dev-lessons конечно. Только сегодня сначала ты написал, а потом увеломление пришло
"Я не помню", "Мне нельзя говорить" - повторили 15 раз. Видео не о чем))
Спасибо за отзыв
Блин, это рофл? У меня в вузе это первая лабораторная в курсе.
Жесть, это видать рофл какой-то.
Ты БДшник? Просто вопросы для фулстекеров и в Канаде. Их больше опрашивают про общие программистские вещи, решают ликтодерские задачи, а SQL спрашивать фулстекера - смысла особо нет.
@@Dev-lessons я студент пока, учусь на анализ социальных данных. Если это для фул стека, то понятно. У вас и так много других задач)
@@menstargan3238 Сравнил, анализ данных и фул стек вопросы
@@Dev-lessons хехе, я просто искал видео и нашел это. Наверное в начале немного прокрутил и не послушал контекст
3:59 судя по пареньку у него очень большой опыт в выдумывании себе опыта. Не знать как джойнить таблицы невозможно, если ты на бек метишь
Точно, ты разгадал меня
Возможно, собеседовал несколько людей из проектов ВКонтакте, ни один не смог ответить по джоинам, на вопрос как так получилось, отвечают что работают с простыми таблицами или готовыми представлениями 🤷 при этом они метят то в синьоры, то в тимлиды, все бывает, SQL он вообще достаточно гибкий инструмент, сейчас мода на микросервисы и узкие инструменты, вот и кандидаты становятся слишком узкого профиля
Блин.. Серьёзно на этом могут люди заваливаться? Я фронт-разработчик, но очевидны же связи между моделями один к одному, многие ко многим, один ко многим. Тут SQL даже видеть не надо. Без баз данных всё то же самое, когда начинаешь манипулировать структурами.
Да, заваливаются
Цунами
Не совсем понял, что значит этот комментарий
6:50 это уже нарушает постулат о нормальной форме БД
Я аж гугланул, потому что выражения постулата нормальной формы не слышал. Есть нормальные формы, но это не является постулатом.
Подписька
Всяк сюда входящий собственно тема вопросов начинает раскрываться только с 6 минуты. В начале очень много воды
20 минут потока блаблабла, нет структуры...
Какую структуру ты ожидал? Это же просто вопросы, которые меня спрашивали во время интервью.
@@Dev-lessons Из названия я ожидал "Здрасте, разберем вопросы, которые задают. И должно было быть "вопрос - ответ, объяснение, следующий". А тут в видео контент "Расскажу свою историю о собеседованиях sql". Название стоит сменить на "Собеседования SQL" или "Мой опыт в собеседованиях SQL", ну никак не первым словом в названии "Вопросы"
@@rikitarurikitaru7716 Я не знаю, почему ты ожидал и чем Собеседования SQL лучше. Я то думал будет реальная претензия.
Вопросы из видео скорее для trainee, чем для джуна на бэке. Вопросы для джуна бэк/фуллстек(0 - 1 год работы): обьяснить например, почему
SELECT * FROM T WHERE t.key + 1 = 4;
или
SELECT * FROM T WHERE (lastname + ' ' + firstname) = N'Слинко Михаил';
при условии, что для первого запроса есть кластеризованный индекс(key), а для второго некластеризованный (lastname) - плохо.
Предложить исправление.
Обязательно ACID, уровни изоляции, 1-3 формы нормализации, планы запросов, логические этапы обработки запросов, этапы выполнения запроса, типы данных, табличные выражения, хранимки и триггеры, различие триггеров INSTEAD OF и AFTER, структурированная обработка ошибок и их генерации посредством THROW. Частый вопрос - рекурсивные CTE, что это, зачем и как примерно пишется.
Зная вышеперечисленное можно не беспокоиться о том, что человек будет писать на SO вопросы или гуглить:
Почему у меня не работает запрос?
SELECT id, title, price, AVG(price) AS avg_price FROM Books
WHERE price > avg_price
и ждать ответа тратя свое рабочее время.
писать вопросы для такого запроса этого не придется, это гуглится за 5 секунд
вода какая-то
Родниковая?
@@Dev-lessonsнет
Ни о чем
Ok
посмотрел 5 минут чуши и выключил
Спасибо хоть за пять минут просмотра
какой смысл вообще задавать вопросы по сиквелю? язык простой как две копейки. если человек не может прочитать план запроса и объяснить как его выполняет конкретная СУБД - смысл тогда его вообще собеседовать по разделу БД? писать сиквель на уровне мартышки (данные получил да и ладно) любой может научится за пару часов.
Ну есть случаи, когда приходится писать достаточно сложные запросы, просто в большинстве случаев нужны простые.