Меркулов Андрей (Красноярск). Python разработчик. Большой собес.

[@УлановАлександр-м4е]

Беседа за жизнь - было интересно послушать )

[@AndyPronin]

а мне было интересно поговорить с умным человеком)

[@7IdE]

В целом, по общению - достаточно комфортно. По БД - прям почти хорошо: были некоторые помарки, но некритичные. Но вот первая задача - это просто швах: 1. Задача не решена. Представленное решение в половине случаев будет порождать аномалии. 2. Вообще не уточнил у заказчика точные требования. 3. Сам что-то себе надумал - и начал решать другую задачу у себя в голове. 4. Корнеркейсы вообще не рассмотрел. 5. Зачем-то добавил список с предлогами - причем неполный список. Ну и это все выльется в 1 вещь - когда прилетит задача, то он будет решать ее так, как сам поймет, а не так, как этого хочет заказчик. Ну а потом это все придется переделывать. Это при условии, что эти аномалии получится сразу найти. Кароче, вообще хз. С одной стороны - "алгосы не нужны" и тд. С другой - тут было много нехороших аспектов.

[@Chel1k7]

Мне кажется или все программисты решают задачи именно так, как сами сначала поняли?))))

[@AndyPronin]

@@Chel1k7 что бы программист решал задучу правильно, нужет проджект)

[@albukerke3322]

Расскажите как бы вы решили эту задачу, с примером решения, возможно и у вас будет не лучший подход Хотя учитывая что у вас не 5 минут и вы решаете пост-фактум должно быть все ок)

[@А_если_так_подумать]

Фууухх, я испугался, подумал капец мне бы столько вопросов понадобилось чтоб начать, а он сразу понял. А оказывается вот как... успокоили)

[@mikeofs1304]

Пора вводить название подкаста -Антилиткод)) Опять хорошо получилось - реальные задачи тащат

[@onlybestmusic4185]

решил посмотреть дальше задачки, а значит и критиковать продолжу :) имена таблиц в единственном числе - ошибка. существует индастри стэндард и его надо знать. незнание того что many-to-many идет через association/pivot таблицу - очевидное не знание 51:30 а теперь про связь Учитель-программа-дисциплина товарищ Меркулов абсолютно верно УГАДАЛ что учителя надо добавить в таблицу "program_discipline" но поскольку он угадал, то он не смог отстоять свою точку зрения )) если вы предлагаете добавить "discipline_id" в "teacher_program" "потому что это логично", тогда с таким же успехом можно добавить "program_id" в "teacher_discipline" потому что это "равнозначно" если следовать той же логике. в "teacher_program" совсем НЕ логично добавлять дисциплину потому что меняется вся суть этой таблицы которая связывает Учителя и программу. и после такого добавления она начинает связывать УЧИТЕЛЯ + ПРОГРАММУ + ДИСЦИПЛИНУ и перестает соответствовать своему предназначению и названию "teacher_program". а вот в "program_discipline" как раз то очень логично добавить "teacher_id" потому что по условиям задачи "program_discipline" связывает Программу и Дисциплину, и Учитель идет как дополнение к этой связке... программа + дисциплина останется, а вот преподаватель тут идет как уточнение ... сегодня Иванов, а завтра Петров... если мы добавим препода в таблицу "program_discipline" это нам открывает возможности: 1) допустим поменялся учитель - можем просто сменить учителя оставив program_discipline.id неизменным 2) можем сохранить препода и просто отключить старую запись "program_discipline.id" - для истории (лучше через лог конечно но просто рассуждаем о вариантах) и создать новую запись с новым преподом... 3) это позволяет нам делить 100 студентов в рамках одной программы и дисциплины на 2 разных учителя по 50 студентов каждому 4) и т.п. то есть это нам дает логическую гибкость. если мыслить категориями реальной жизни (мы же аддепты ООП?) и дальнейшей имплементации в коде: для простоты мышления на примере универа: у нас есть Группа А и Группа Б студентов (наши программы, на пример одни программисты а вторые Физики-ядерщики) и тем и другим надо преподавать дисциплину "Высшая Математика", то есть связка Программа+дисциплина = нерушимая связь = обязательное условие ... а вот Будет это преподавать Иванов или Петров - это пофиг веники - они взаимозаменяемы, они есть дополнение к обязательному условию... если прям совсем нормализовывать то надо еще одну таблицу "program_discipline_teacher" - но для данной задачи это явно излишне, добавляет излишнюю связь, усложняет и замедляет запрос... а теперь попробуем применить тот же подход к таблицам "teacher_program" и "teacher_discipline". а) teacher_program: учитель преподает некой группе студентов (нашу программу, курс)... если сюда добавить discipline_id как некоторое уточнение к основной связке оно не легко заменяемо ... не может препод у этой группы вести любую дисциплину... то есть вами предложенный вариант добавить "discipline_id" прям совсем не катит. б) teacher_discipline: учитель преподает какую то дисциплину - это основная связка в таблице... если мы добавим уточняющее поле "program_id" ... а может ли препод по высшей математике преподавать в любой группе/программе ? наверное нет ... с) вы мне возразите: погоди, а с чего ты взял что в "program_discipline" может преподавать любой препод ... "а не может" и тут я соглашусь. может преподавать только тот препод у которого teacher_discipline совпадает... здравствуй композитный внешний ключ - нежданчик явно не для джуна, ну и програмная проверка от греха подальше )) но на практике я бы от такого ключа наверное отказался и оставил только програмную проверку. и этот вариант по любому более логичен. в рамках реализации: все 3 таблицы ( "teacher_program", "teacher_discipline", "program_discipline") "равнозначны" и можно впихнуть третье поле в любую из них что бы она отображала связь программа+дисциплина+препод в рамках логики: 1) "teacher_program", "teacher_discipline" - равнозначны, вы мне не сможете объяснить чем "discipline_id" внутри "teacher_program" лучше чем "program_id" внутри "teacher_discipline" и в том и в другом случае теряется логический смысл и первой и второй таблиц 2) а вот почему добавить "teacher_id" внутрь "program_discipline" более логически верное решение я вам объяснил выше так что ИМХО учителя надо добавить в таблицу "program_discipline" и товарищ Меркулов угадал, но не смог защитить и обосновать свою догадку и сразу сдался согласившись с вами )) а мог бы и взять время на поразмыслить или порассуждать в слух как это сделал я... я когда собеседую люблю "вбрасывать" такого рода несостыковки и смотреть человек сразу согласится или начнет рассуждать или начнет тупо спорить неаргументированно и к чему мы по итогу обсуждения придем :) ПС: я допускаю что я не прав всегда и во всем, но меня в этом надо аргументированно убедить :)

[@onlybestmusic4185]

Ну в алгоритме уже вижу ошибку... 200 символов заканчиваются на пробеле или полноценном слове и предпоследний элемент не предлог. получается он удалит лишнее слово, собственно вопрос а зачем? А если заканчивается на полноценном слове и предпоследний элемент предлог то получится удалит два слова что ещё хуже... И это не какие-то эдж кейсы это прямо будет часто возникающая ситуация... То есть ничего не удалять в принципе не предусмотрено а это явная и грубая ошибка... Вопрос к собеседователю: Андрей вы же готовитесь к собеседованию и эту задачу придумали вы Но такую явную проблему вы каким-то образом упустили и в конце собеседования назвали что задача решена хорошо. Вы обратили внимание на проблему с хардкодом внутри функции но не обратили внимание на то что алгоритм кривой с явным багом, Я бы это назвал даже что задача совсем не решена... Потому что в задаче очень важным условием было заполнить 200 символов по максимуму а тут получается заполнение идёт не по максимуму.

[@AndyPronin]

Вообще, да. Затупил. Задачку из рабочих такое взял перед собесом, не готовился и не решал сам. Кажется Акелла промахнулся

[@sn3232]

53:35 здесь teacher_program и program_discipline повторяют информацию о связи программы и дисциплины с соответствующими возможными аномалиями: удаляем дисциплину из программы, а преподаватель в ней остаётся (если из program_discipline удалили). Табличка program_discipline лишняя.

[@AndyPronin]

Да отличное замечание. А где хранить информацию о дисциплинах в программе?

[@sn3232]

@@AndyPronin Хмм... ну здесь 3 варианта есть: 1. Тот который в видео, недостатки уже описывал 2. Убрать табличку program_discipline и установить специальный правила для таблички teacher_program. Например, если преподаватель пока не назначен ставить teacher_id = NULL (и ON DELETE SET NULL у внешнего ключа с teacher) + если хотим список дисциплин программы обязательно использовать SELECT DISTINCT discpline_id WHERE program_id = (нужный id). Но тут возникает сразу проблема с удалением преподавателя из программы - нам нужно знать это последний преподаватель, который ведёт данную дисциплину или нет: если да ставим NULL, если нет удаляем строку из teacher_program (а если race condition?). Короче выглядит сложным... 3. Связать связью m2m таблицу teacher и program_discpline (соответственно teacher_program убрать). Вроде артефактов никаких возникать не должно. Правда установить на каких программах преподаёт преподаватель становится нетривиальной задачей)

[@mikeofs1304]

@@sn3232 Вообще если не нужны исторические данные (но для них в любом случае лучше сделать отдельную таблицу заполняемую тригером), то тичер пронрамм конечно удалить, а в програм дисциплин добавить столбец тичер внешним ключом на тичера (это начинал делать интерьюируемый но его отговорили). И накинуть уник на сочетание тичер , программ, дисциплин. Получаем вполе чистую сущность - в таблице программ дисциплин для курса. Это конечно не связь классиечкая многие к многим. Но опять же мы ведь тут не в ОРМке и можем сами придумывать свой дизайн

[@Pipdidalik]

Андрей у меня вот такой вопрос как к опытному программисту. Я учусь на курса по python у нас по программе курса только 1-н фрейм. Django, хватит ли мне только его для трудоустройства или ещё надо хотя бы 1-н?

[@Pipdidalik]

@@sleeepy26 я не вузе Python изучаю

[@amalshakov]

Если ты трудоустраиваешься туда - где работают на Django - то хватит. Если нет, то нет)

[@AndyPronin]

Просто, елоси требования будут не Джанго - пролетаешь. А так можно Фастапи выучить и с ним жить или с Фласком.

[@Pipdidalik]

@@AndyPronin спасибо

[@justpochta]

Хм. А это на джуна собеседование? Вроде норм отвечает.

[@AndyPronin]

Да. на джуна

[@theniska8583]

а можно как-либо на собеседование попасть?

[@AndyPronin]

Студент практикума?

[@Chel1k7]

@@AndyProninа без постели не пускают?)

[@ForeverNils]

а где плюсы, где си? почему какие-то недоязыки типа питона обсуждают так часто?

[@AndyPronin]

Пишете на плюсах?

[@ForeverNils]

@@AndyProninда

[@AndyPronin]

Отличный язык. У нашей компании стек - питон и яваскрипт. Поэтому так. Ну и ребята на курсе учили питон. странно их будет спрашивать про си.

[@DzafarSharifov]

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

[@onlybestmusic4185]

Не хочу начинать холивар но я как пхпэшник негодую... Объяснитесь сударь, что значит хотя бы ПХП а потом более высокий уровень питон... Если мы говорим о веб-разработке то расскажите мне а чём это питон настолько лучше чем PHP что он более высокого уровня? Только не рассказывайте эту сказку что я смотрю на код питона и мне сразу всё интуитивно понятно... Я не знаю питона я его второй раз в жизни вижу и мне ничего не понятно. мне понятны: c java JavaScript PHP perl c# Но я понимаю что это вкусовщина и пару недель надо на привыкание поэтому к этому не придираюсь даже... Я посмотрел штук пять-шесть интервью и я не увидел уровня джуниоров у ребят но услышал желание зарплат в пределах 1.000 долларов. Для понимания: на ПХП бэкенда джуниоров нанимают с пониманием принципов солид пусть базового, но понимания. чёткого понимания ооп ,mvc, rest, очень аккуратно могут спросить про паттерны проектирования знает ли какие-то слышал ли о них.. А здесь на собеседованиях я вижу ребята клепают классы и не используют интерфейсы... Бог с ним с интерфейсами где хотя бы абстрактные классы, даже на абстрактные классы закрою глаза, В питоне что области видимости отменили? А это всё база ооп... Ладно бог с ним просто для меня это небо и земля что требуют от джуниоров на ПХП и то что я вижу в собеседованиях на питон... У меня собственно к вам вопрос чем питон более высокого уровня чем PHP что надо "хотя бы PHP изучить" Надо хотя бы программированию для начала научиться без относительно языка программирования а потом просить зарплату 1.000 долларов

[@Сергей-ф2ъ7я]

я так понимаю, аргументов не будет?

[@AndyPronin]

Если можно, больше конструктива в комментариях.