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

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

решил посмотреть дальше задачки, а значит и критиковать продолжу :) имена таблиц в единственном числе - ошибка. существует индастри стэндард и его надо знать. незнание того что 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" и товарищ Меркулов угадал, но не смог защитить и обосновать свою догадку и сразу сдался согласившись с вами )) а мог бы и взять время на поразмыслить или порассуждать в слух как это сделал я... я когда собеседую люблю "вбрасывать" такого рода несостыковки и смотреть человек сразу согласится или начнет рассуждать или начнет тупо спорить неаргументированно и к чему мы по итогу обсуждения придем :) ПС: я допускаю что я не прав всегда и во всем, но меня в этом надо аргументированно убедить :)

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

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

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

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

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

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

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

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

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